Hi all,
I was trying to extract this information from the AXI specification but I didn't find any clear answer.
I wonder how should an AXI component behave if an input xREADY signal is never asserted.
Example 1: a master starts a write transaction by asserting AWVALID (and the other needed signals). That should be legal since the AWVALID is not allowed to depend AWREADY. And is also legal for the slave (even if not recommended) to assert AWREADY after AWVALID has been asserted. What happens now if AWREADY is never asserted?
Example 2: a master starts a write transaction by asserting AWVALID and the slave acknowledges it with AWREADY. Then the master asserts WVALID to write the data, but the slave hangs and never asserts WREADY. Should the master timeout? Is it possible to abort a transaction after it's started?
Thanks for the help
A
Hi A,
In both your examples you are looking at having to reset one or both components involved in the transfer.
For example 1 where the AWVALID transfer is stalled by the slave not asserting AWREADY, if that is the only transfer ongoing you could think of just resetting the slave, and then hopefully when it comes out of reset it will accept the AW transfer still waiting to be acknowledged. However if the slave has other write transfers ongoing (for an earlier accepted write address), either WDATA transfers or BRESP responses still to complete, or if the slave also has read accesses ongoing, you wouldn't be able to reset just the slave as other transactions would then be lost, so you could wait for those other transfers to complete before resetting the slave, or just reset both master and slave.
For example 2 where the slave now has an active write transfer, you would then need to reset both the master and the slave (the slave because it has hung, and the master because it has issued a transaction that will never be completed).
The AXI protocol doesn't have any concept of "timeout", if a channel source asserts xVALID, that xVALID indication must remain asserted until the corresponding xREADY is asserted. If the channel destination component has failed for any reason, the transfer will remain pending indefinitely, so reset is the only solution.
Note that in anything other than the simplest master connected directly to a slave scenario, there will be some sort of interconnect structure involved to connect multiple masters and slaves. In that sort of scenario it is much more difficult to determine when it might be safe to reset just one component, so when one component hangs you usually have to be looking at resetting all components.
So basically validate your components so that there is no possibility of them ever hanging
JD
Hi JD,
thank you very much for the answer. Really clear and complete.
In your opinion what would be the best solution to handle the resets? To use some sort of arbiter, or to let the master/slave self reset on some timeout?
I definitely agree with you on designing the components so that they never hang. But unfortunately it's not 100% up to me: I'm implementing an AXI4 bridge over optical fiber, and I can bet someone is going to unplug the cable during a transition sooner or later
Ok, pretty clear.
Thank you very much for all the information.
You could just put a big yellow notice on the cable saying "Do not unplug", that would be guaranteed to work
Maybe not
I would guess it would have to be a timeout counter on the suspect connection, monitoring delay from xVALID to xREADY assertion, and then performing a warm reset of the component(s) if the timeout period is exceeded. If the cable is disconnected, would you need to reset the destination component at the end of the cable (has it been powered down) ?
Part of that "warm reset" handler code could be to determine which system slaves are present, and if you are then able to detect the physically missing cable, map that address range to a default slave so that an ERROR response could be returned to any future access attempts (I'm thinking more of the system before your AXI4 bridge rather than just the bridge alone).
Sounds like an interesting problem to work round, but unfortunately nothing in the AXI spec that directly addresses your concern. Hope you manage to find a solution.