Hello,
I would like to confirm my understanding of the following transfer scenario:
What I Understand:
The slave requires the following information:
For a 4-byte data transfer, the lower 2 bits of the address are important. Therefore, "2'b01" is provided to the slave, and the valid data range is from 0x01 to 0x03, activating the corresponding strobe.
In summary, an unaligned transfer occurs only during the first transfer, while subsequent transfers are aligned.
Questions:
I would appreciate your clarification on this matter.
For write transactions the subordinate device doesn't actually need to check the AWADDR LSBs as WSTRB will tell it exactly which byte lanes contain valid data.
With the 0x01 start address and AWSIZE indicating 32-bit (4 byte) wide transfers, the first data transfer can only transfer a maximum of 3 bytes, so WSTRB can indicate any of 4'b0000, 4'b0010, 4'b0100, 4'b0110, 4'b1000, 4'b1010, 4'b1100 or 4'b1110 (any combination with WSTRB[0] low).
For the 2nd, 3rd and 4th write data transfers WSTRB can assert any bytes as only the first transfer is unaligned to the transfer size.
The subordinate can see that byte lane 0 will not be used for the first transfer because of what AWADDR[1:0] indicated, but it would also need to check WSTRB to see exactly which of the allowed byte lanes ARE being used, so AWADDR[1:0] is redundant information here.
For your second question, the first transfer can only transfer a maximum of 24 bits of data, and these will be driven on WDATA[31:8]. What you drive on WDATA[7:0] is not defined, and not relevant to the transfer.
Note that as I said, only the first transfer is unaligned, so if you had intended to transfer 16 bytes of data to 0x1 upwards, you would instead need to use a 5-beat burst (AWLEN=0x4), AWADDR=0x1, and WSTRB=4'b1110, 4'b1111, 4'b1111, 4'b1111 and 4'b0001.
For reference you should find that figure A4.6 in the current version K of the AXI specification covers what I think you are describing here. It shows the byte lanes being used for a series of aligned and unaligned transfers on a 32-bit data channel. The second example sequence is this unaligned 4-beat 32-bit burst to 0x01 that you are describing,
How are unaligned READ transfers handled as WSTRB can be used only for WRITE transfers? Can you explain with an example please?Also, who(manager or subordinate) do you think should take care of generating subsequent address in case of multiple beats unaligned transfer?
The reason the protocol needs a WRITE strobe signal is that the manager knows which byte lanes contain valid data, but the subordinate doesn't, so WSTRB gives the subordinate this information.
However for READ transactions, the manager already knows which byte lanes it actually wants data on, so the subordinate just needs to drive the ARSIZE requested amount of data, and the manager takes the actual byte lanes it is interested in (it can mask off the bytes it does not need).
The "unaligned" term in AXI is slightly misleading in that it only applies to the first transfers in an INCR transaction, so the AxADDR misalignment with the indicate AXSIZE transfer width tells you which byte lanes are not covered by the first "unaligned" transfer. All subsequent transfers in the INCR transaction are aligned to the AxSIZE value (for FIXED transaction types all transfers in the transaction keep the same unalignment).
For the address for multiple beats of an (initially) unaliged transfer, it would be the subordinate that needs to calculate each address in the transaction (AXI only ever sends the initial start address). So as covered above, only the first transfer in an INCR transaction is unaligned, and subsequent transfers are to aligned addresses, calculated by AxSIZE aligning the start address and then adding AxSIZE for each transfer.
So if you had an unaligned 4-transfer transaction to 0x1 with AxSIZE=0x2 (32-bit), the transfer addresses would be to 0x1, 0x4, 0x8 and 0xC.