I observed that every transaction on the AHB Bus Matrix encounters an initial !HREADY - even in the absence of any other master/contention.
I chased it down to the output stage arbiter. I tried both round-robin and fixed arbitration schemes.
Is this to be expected? Is there any way to avoid the initial arbitration delay on uncontested ports?
There isn't any way to avoid this delay using presumably the AHB-lite CMSDK BusMatrix, and you will see it for the "round", "fixed" and "burst" arbitration options.
This arbitration cycle is added each time a master attempts to access a new target slave, and was added to avoid this potentially long path through the BusMatrix becoming a critical timing path while the new transfer has to be address decoded, routed to the new output stage, pass any arbitration checks, and then be passed out to the new target to meet any setup requirements.
Although if the current target slave is returning a wait state for the final data phase transfer from this master, the added arbitration cycle will be masked by this wait state added by the BusMatrix, so it isn't always a latency penalty for the master.
Arm does have a newer BusMatrix design in their SIE-200 product which is AHB5 based. This BusMatrix adds some zero latency arbitration options to address this issue you are asking about, but you then have longer combinatorial paths to meet timing on.
Colin,
Thank you for the always knowledgeable response.
Does the same hold for nic400? I am observing a point-to-point connection in the absence of any other traffic experiencing delays when no such delays occur when nic400 is not in the path. Is there a hi perf nic400 option?
Thanks again, Tom