[SOLVED] An AXI4 full question

[dpaul]

The AXI channel signals interact via the handshake mechanism. The *VALID and *READY signals are involved in this mechanism.
If a slave is busy, the *VALID is asserted after a delay.

My question is, what is the max amount of delay in usec that might be expected in the assertion of *VALID from a slave?

Example:
From my simulation results, for my design, an AXI4 master accessing the DDR3 Ctrl core AXI4 slave over an Interconnect IP core takes about 20 usec.

Background for my question:
If a *VALID assertion never happens (the AXI bus gets in to a stall state), I want to flag this AXI error to the higher processing system. Hence i want to build a mechanism inside the AXI4 master such that if the *VALID is not seen whith a duration of xz usec, an error will be flagged.

Hence I want to get an idea regarding the maximum value of this delay.

 

[TrickyDicky]

AXI4 defines no timeouts. If the system is "locked up", then its likely a design fault.
Also, the slave should never flag that it is busy. It is against AXI spec to use the READY signal to assert the VALID. The Master should asert valid when it has data ready and wait for the READY from the slave. It is legal for the slave to assert READY after VALID has been asserted.

--- Updated Oct 1, 2021 ---

For the full AXI4 Write: the WDATA MUST send the correct volume of data specified in AWADDR
AXI4 Read: the RDATA channel MUST contain the correct amount of data requested on the ARADDR channel.

 

[dpaul]

@TrickyDicky ,
Yes those are AXI rules and I am adhering to them.
But as I understand it the AMBA AXI spec defines how the signals behaves at the interface. How a module implementing AXI as its interface behaves on certain conditions is "out of bounds" for the spec.
The AXI Slave in question is a uChip DDR Ctrl core. In simulation all AXI transactions are working fine. Device prototype level tests are yet to be performed (I still do not know if something can go wrong there). But as a designer I want to be sure that all error conditions, however unlikely they are, are correctly handled and reported. Hence I wanted to implement this handshake timeout feature in the AXI master.

Hence I want to get an idea regarding the maximum value of this delay.
So I know very well this does not belong to the AMBA spec. My intention was to get a feedback from various members regarding a max delay time (in usec) observed during simulation , when AXI masters have interact with various types of AXI slaves. I mean most of us who have simulated an AXI based design have probably measured how long it takes for the *READY to arrive at the master interface.
My AXI simulation experiences say a handshake delay of 20 us is very normal, 30us is also observed in many cases. Near to 50 usec of delay can also be observed in some scenarios. But in my opinioin something near to 50 usec will contribute significantly to system latency and if such high handshake delay is observed, then I believe something is wrong with the design and needs to be investigated.

AXI4 defines no timeouts. If the system is "locked up", then its likely a design fault

Is the above mentioned somewhere within the AXI spec?

 

[TrickyDicky]

Any timeout will have to be built in by you, and well documented, but then it MUST still be AXI compliant. So if you put in a read request, and it takes too long, you still need to know to handle the response that comes back "late". The AXI spec requires that all requests come back the order they were requested - regarless of turnaround time. This could be 1us, 1s, 1 week. The order MUST be maintained and they MUST conform to the original request. So if you request 100 words, it must respond with 100 words. Even if they are 100 words of read failed.

I have a system with a DDR connected via an AXI4 interconnect. The way I ususally lock it up is by sending AWLEN that does not match the number of words on the WDATA bus. If this happens its game over.
For me, I dont care about whether a write was successful or not as a retry is not possible. I simply throw the writes at the RAM and throw away the bresponses
As for reads, I simply wait for them to arrive. They are NEVER out of order. I have no timeout and I have never measured the turnaround. I cannot work with a timeout.

If you implemented a timeout, you would need to generate a "fake" failed request, but still handle the real response coming back from the ram.