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 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.
Hi A,
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.
JD