Optional "accept" for write/read
Currently, user logic can not stall the register file, as soon as a read/write happens, the strobe will go high and one cycle later go low. If the user logic is not ready to take in/provide a value, the value might be lost. I think it would be nice to have an optional flag to have a handshake like AXI:
During a read, the strobe would go high, the statemachine would go into a READWAITREADY state, where the strobe is held high until ready is asserted from user logic. Only once that happens, the statemachine goes into READ_RESPONSE mode. This simple implementation would introduce an additional cycle in the statemachine, but a proper solution should be logically equivalent to the current state, assuming that ready is fixed to high.
Similarily, in the write logic, the statemachine waits for a ready from the user logic and holds the strobe high and stalls the module as long as the user logic is not ready.
Logically, this proposed feature would be equivalent to the current implementation if the ready from user logic is forced high, but would enable a way to provide back pressure into the AXI network.
Thanks for suggesting this feature. For further analysis, it would be very helpful if you could provide a concrete application example for this. Thanks, Guy.
-
Christian Lanius commented
Dear Guy,
I received your answer per mail, but it somehow does not show up here. The proposed solution of using a write only plus an interrupt register does work, and if it was a conscious design decision to not allow the AXI bus to stall, I will work with such an approach. I see the advantage of being able to guarantee that the bus does not stall indefinitely.
For us the downside of that approach is that we need to generate at least 3 AXI requests (write, polling read from interrupt register, write to clear).
Kind regards
Christian -
Christian Lanius commented
Dear Guy,
Thank you for taking your time to have a look at this. I do not want to burden you with any work.
Assume I have some custom memory, that takes many (possibly indeterminate number of) cycles to write. During that time, the address and data have to be constant. Note that the actual application that I have is too big to show here. I have written a minimum example gist here, where such an accept flag would be useful: https://gist.github.com/christian-lanius/2f321e363c21b9ef22f14e0b508feb96. Currently, the AXI master has to wait long enough with the next transaction that we can guarantee that the write has taken place, or we have to add a large enough FIFO in the user code to make sure that on average we are fast enough.
Similarly if the memory has a random delay to access, the currently supported fixed delay is not enough to handle that case.
Kind regards
Christian