Say the Initiator did the read request with 16 beats. Does AXI standard require the response to come in the same response or it can come in 16 separate single transactions?
The question comes from the context of SoC architecture with say AXI4 Initiator is connected through the NOC to AXI-lite. Or another version is when the transaction turns to be a slit one between different Targets. Should the NOC combine all the responses to create the same burst size as Initiator requested or this is not mandatory?
Thanks,
Khach
Khach said:Say the Initiator did the read request with 16 beats. Does AXI standard require the response to come in the same response or it can come in 16 separate single transactions?
The AR request attributes describe exactly how the responses must be returned.
ARLEN specifies how many transfers are required, where the last transfer in the sequence will have RLAST asserted.
ARSIZE specifies how much data each transfer must carry.
For example, if ARLEN = 0x3, then you cannot return 4 read transfer each with RLAST asserted as this would be seen as 4 separate transaction responses to 4 different requests with ARLEN = 0x0.
Thanks for the response. What happens in case
1. the destination address is split into multiple targets, that can respond in different times
2. The Target does not support AXI, but just AXI-lite.
Is this the responsibility of NOC to collect all the data back from targets, align them and send the response back to the Initiator matching the same burst size as it was requested?
Thanks again.
Yes, it's the responsibility of the NoC in this case.
One way to think of AXI is that it's primarily defining the interface to interface connection. The connection from your manager to the interconnect is a single AXI interface that must obey the AXI rules.
Your manager doesn't necessarily have any knowledge of exactly what is happening within the NoC - all it knows is that it has made a request with specific attributes (e.g. a specific ARLEN and ARSIZE) and that it expects to get data back in this format.
Thanks a lot. That makes sense. Let me ask a final question, an unrelated one though.
Why do I need both ARLEN and ARSIZE. Can't one be deduced from the other?
Both are needed, and you cannot deduce one from the other.
An AXI transaction is made up of transfers.
ARLEN defines how many transfers are required for this transaction. ARSIZE defines how many bytes are in each transfer. ARLEN x ARSIZE gives the total amount of data being requested.
Thanks again. Does this mean that all the transfers within transaction must have the same number of bytes?
Yes, there is just one AR channel transfer for the transaction, so the same ARSIZE value applies for each read data transfer in the transaction.
Thank you. In context of write channel: the signals are AWLEN, AWSIZE and WSTRB. Say AWLEN says there are 16 transfers in the transaction, AWSIZE says 2 bytes in each, but WSTRB keeps only 1 byte enabled in the transaction. The other bytes are masked. According to address channel, within 16 transfers, the Target should receive 16x2=32 bytes. However is receives just 16. How should the system react to this scenario?
The system should only write the bytes that are indicated by WSTRB.
For a write, AWADDR, AWLEN and AWSIZE define the maximum number of bytes that could be written. WSTRB defines the bytes that are actually valid to write.
For reads, ARADDR, ARLEN and ARSIZE define which data bytes must be returned as valid.
AxADDR applies to the first transfer, where if the address is unaligned, then the bytes that fall outside of this are not written to.
As I mentioned in the previous example instead of promised 32 bytes only 16 has been provided.Is not this an error condition?
It seems you are saying this is a normal transfer type, is that right?
Yes, this is normal behaviour, and is not an error. The point of the WSTRB signal is to allow individual bytes within the stated transaction size to be written or not. This avoids having to issue multiple transactions to write sparse bytes.
Then how AWSIZE help in this example. Does it really signify any transaction attribute? Why should not one just carefully set AWLEN and WSTRB and leave AWSIZE to whatever?
AXI has a number of signals that carry duplicate information. For example, RLAST and WLAST are effectively duplicates of AxLEN. This can be useful for hardware to process a transaction more efficiently, or reduce the complexity of logic.
In the case of AWSIZE and WSTRB, this allows hardware to process the AW request without having to examine and buffer all the write data associated with the request. For example, this could be used to pre-allocate the maximum amount of write buffer space that could be used by the request.
Thanks Christopher for the clarification. I understand the need of duplication for the sake of making the hardware processing easier. The point I am trying to understand is what is the consequence when the duplicate signals are not matching the expectations. Based on your example with RLAST/WLAST and AxLEN: say ARLEN was setup to make 16 transfers. If RLAST came on 16-th transfer there is no question, everything is as expected. However, there can be some extreme cases: one of them is, if on 16-th transfer the LAST did not come. Another extreme is if RLAST came on 10-th transfer (or maybe multiple times). Should not the system give the preference to one of those duplicates (in case you insist this is not an error)?
WSTRB indicating a smaller number of active byte lanes than AWSIZE indicated is not an error as previously explained. AWSIZE and AWLEN together tell you the maximum number of bytes that this transaction can transfer, and then WSTRB tells you which byte lanes in each AWSIZE width data transfer contain valid data.
WLAST or RLAST being asserted for a transfer that isn't the final AWLEN or ARLEN indicated transfer IS a protocol violation. If you see this, the resulting system behaviour is undefined, and the source of the violation must be fixed. AxLEN and xLAST assertion must agree; neither has precedence.
You should detect this (and all other protocol violation) during system verification simulations using protocol checker tools so that silicon components do not need to include protocol checking logic that will unnecessarily increase gate count.
Colin, thanks for the explanation. The part I am not clear and trying to get an explanation is slightly different.
There are duplicates as it was indicated earlier: AWLEN/WSTRB, AWLEN/WLAST and some other. In case of the mismatch between AWLEN/WLAST this is a protocol violation. In case of AWLEN/WSTRB mismatch, for some reason this is not a protocol violation. What are the rationals behind this?
What if AWLEN says only 2 bytes are valid on each transfer, but WSTRB does not mask any, so all of them end up being enabled. The factual transfer ends up being larger than what was initially booked to be allocated. There must be a reason this is not considered a protocol violation and this is where I need your help.
Thank you.