AXI read burst request and response

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.

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?

Thanks for all the responses. This was very helpful!