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
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.
The only "duplicate" information signals are the AxLEN and xLAST signals. Both tell you when the final transfer in the transaction will be. As Chris explained, for write transfers this gives the subordinate designer the choice of whether to count AWLEN number of transfers, or just accept transfers until WLAST is asserted.
As I tried to explain, the ONLY signals that define how much data a write transaction can contain are AWLEN and AWSIZE. Together they tell you the length and width of the transaction boundaries. This is the MAXIMUM amount of data that could be transferred.
WSTRB is a secondary signal that then tells you which of the byte lanes in each write transfer contain valid data. So in the AWLEN x AWSIZE bounded transaction, some of the data bytes might be tagged valid (WSTRB=1), some might be invalid (WSTRB=0), but those bytes whether valid or invalid will be what are passed on the bus in each data transfer, making up one of the AWLEN number of data transfers.
So WSTRB is irrelevant when considering when a data transaction is ending. That is only on the (AWLEN+1) data transfer, when WLAST is asserted.
Looking at extremes, you could have a write transaction with AWLEN indicating 8 transfers, with AWSIZE indicating 4 bytes per transfer, so a total maximum of 32 bytes possible, but WSTRB=4'b0000 for every one of the 8 transfers. So no valid data has been transferred, but there were 8 W channel transfers, and WLAST was asserted for that 8th data transfer. All perfectly legal from an AXI perspective, so no protocol violation or error.
Yes, that last example is pointless, but I am just trying to show that WSTRB is not relevant when it comes to determining when a write transaction ends. It is only AWLEN and WLAST that will indicate when a write transaction ends.
In the last question in your post you state AWLEN says only 2 bytes are valid on each transfer. I guess you meant AWSIZE as this indicates the maximum number of valid bytes per transfer. I think your misunderstanding here is that if you had a 32-bit (4 byte) data bus, and AWSIZE indicates 16-bit (2 byte) transfer widths, the protocol states that you can only assert WSTRB bits within the AWSIZE/AWADDR/AWBURST defined byte lanes.
So if you had an incrementing burst signaled on AWBURST, AWSIZE was 2 bytes, AWADDR indicated a starting address of 0x2, and AWLEN indicated 4 transfers, all on a 32-bit data bus, the possible maximum valid byte lanes indicated on WSTRB could only be 4'b1100, 4'b0011, 4'b1100 and 4'b0011 for the sequence of writes (first transfer to the upper half of the 32-bit bus, the second to the lower half, and alternating for the duration of the transaction).
As you can then see, the maximum number of WSTRB bits that could have been asserted in the transaction's 4 transfers is 8, which matches the AWLEN x AWSIZE (4x2) value. You cannot ever have the "factual transfer being larger that what was initially booked to be allocated".
Thanks for the detailed response. Yes, this is indeed where my confusion is. Looking at your example:
<<
>>
Now, say, the WSTRB came as 4'b1111, 4'b1111, 4'b1111 and 4'b1111. This is a non-sense, but let's keep this extreme for the sake of understanding. Is not this more that was initially booked to be allocated?
Or you are saying the originator must do it as 4'b1100, 4'b0011, 4'b1100 and 4'b0011 and never the way I shown above?