Understanding AXI4 Unaligned WRITE Transfers and WSTRB Signaling
In the AXI4 protocol, unaligned WRITE transfers occur when the starting address (AWADDR) is not aligned to the data width specified by AWSIZE. For example, if AWSIZE is set to 2 (indicating a 32-bit transfer), the starting address should ideally be aligned to a 4-byte boundary (e.g., 0x00, 0x04, 0x08, etc.). However, if the starting address is 0x09, this constitutes an unaligned transfer. The AXI4 protocol provides two mechanisms to handle such unaligned transfers: using the low-order address lines to signal the unaligned start address or providing an aligned address and using the byte lane strobes (WSTRB) to indicate the unaligned start.
For a WRITE request with AWADDR = 0x09, AWSIZE = 2 (32-bit transfer), and AWLEN = 3 (indicating four beats in the burst), the WSTRB signal must be carefully managed. The WSTRB signal is a bitmask that indicates which bytes within the data bus are valid for the current transfer. In this case, since the starting address is 0x09, the first byte of the 32-bit data bus (corresponding to address 0x08) is not part of the valid data. Therefore, the WSTRB signal must reflect this by setting the first byte lane to 0 (invalid) and the remaining three byte lanes to 1 (valid). This results in a WSTRB value of 4’b1110.
It is important to note that the AXI4 manager must always provide a valid WSTRB signal that corresponds to the AWADDR, AWSIZE, and AWBURST combination. In this example, a WSTRB value of 4’b0111 would be a protocol violation because it incorrectly indicates that the first byte (corresponding to address 0x08) is valid, which is not the case for an unaligned transfer starting at 0x09.
The AXI4 fabric implementation must handle this WSTRB signal appropriately. The fabric should recognize that the first byte of the data bus is invalid and should not write it to memory. The remaining three bytes (corresponding to addresses 0x09, 0x0A, and 0x0B) should be written to memory as specified by the WSTRB signal.
Handling AXI4 Unaligned READ Transfers and Data Alignment
Unaligned READ transfers in AXI4 are handled differently from WRITE transfers because there is no read strobe signal equivalent to WSTRB. Instead, the unaligned READ transfer is signaled using the ARADDR signal. For example, if ARADDR = 0x09, ARSIZE = 2 (32-bit transfer), and ARLEN = 3 (indicating four beats in the burst), the AXI4 manager is requesting data starting from address 0x09.
In this case, the AXI4 subordinate (the device responding to the READ request) must handle the unaligned address appropriately. One approach is for the subordinate to align the address to the nearest lower natural word boundary (0x08 in this case) and return the full 32-bit data word. The AXI4 manager can then extract the relevant bytes (0x09, 0x0A, and 0x0B) from the returned data.
Alternatively, the subordinate could handle the unaligned address internally by fetching the required bytes from memory and returning only the relevant data. However, this approach is more complex and may not be supported by all AXI4 subordinates. In most cases, it is simpler for the subordinate to return the full 32-bit aligned data and let the manager extract the necessary bytes.
For the example of ARADDR = 0x09, ARSIZE = 2, and ARLEN = 3, the subordinate would return data starting from address 0x08. The manager would then ignore the first byte (corresponding to address 0x08) and use the remaining three bytes (0x09, 0x0A, and 0x0B) as the valid data for the transfer.
Implementing AXI4 to APB Bridge for Unaligned Transfers
When interfacing an AXI4 manager with an APB subordinate, special care must be taken to handle unaligned transfers, as APB does not natively support unaligned transfers. The AXI4 to APB bridge must convert the AXI4 unaligned transfers into aligned transfers that the APB subordinate can handle.
For WRITE transfers, the AXI4 to APB bridge must align the address to the nearest lower natural word boundary and adjust the WSTRB signal accordingly. For example, if the AXI4 manager issues a WRITE request with AWADDR = 0x09 and WSTRB = 4’b1110, the bridge must align the address to 0x08 and adjust the WSTRB to 4’b1111. The bridge must then handle the data appropriately, ensuring that the first byte (corresponding to address 0x08) is not written to the APB subordinate.
For READ transfers, the AXI4 to APB bridge must align the address to the nearest lower natural word boundary and fetch the full 32-bit data word from the APB subordinate. The bridge must then return the full 32-bit data to the AXI4 manager, which will extract the relevant bytes (0x09, 0x0A, and 0x0B) from the returned data.
The exact implementation of the AXI4 to APB bridge may vary depending on the specific requirements of the system. However, the key principle is that the bridge must handle the alignment of addresses and data to ensure that unaligned AXI4 transfers are correctly converted into aligned APB transfers.
Detailed Example: AXI4 Unaligned WRITE Transfer
Consider an AXI4 manager issuing a WRITE request with the following parameters:
- AWADDR = 0x09
- AWSIZE = 2 (32-bit transfer)
- AWLEN = 3 (four beats in the burst)
- WSTRB = 4’b1110
The AXI4 manager is requesting a WRITE transfer starting at address 0x09, with a 32-bit data width, and a burst length of four. The WSTRB signal indicates that the first byte (corresponding to address 0x08) is invalid, and the remaining three bytes (0x09, 0x0A, and 0x0B) are valid.
The AXI4 fabric must handle this unaligned transfer by recognizing that the first byte of the data bus is invalid and should not be written to memory. The fabric must write the remaining three bytes to the appropriate memory locations (0x09, 0x0A, and 0x0B).
If this WRITE transfer is being sent to an APB subordinate via an AXI4 to APB bridge, the bridge must align the address to 0x08 and adjust the WSTRB signal to 4’b1111. The bridge must then handle the data appropriately, ensuring that the first byte (corresponding to address 0x08) is not written to the APB subordinate.
Detailed Example: AXI4 Unaligned READ Transfer
Consider an AXI4 manager issuing a READ request with the following parameters:
- ARADDR = 0x09
- ARSIZE = 2 (32-bit transfer)
- ARLEN = 3 (four beats in the burst)
The AXI4 manager is requesting a READ transfer starting at address 0x09, with a 32-bit data width, and a burst length of four. Since APB does not support unaligned transfers, the AXI4 to APB bridge must align the address to 0x08 and fetch the full 32-bit data word from the APB subordinate.
The bridge must then return the full 32-bit data to the AXI4 manager, which will extract the relevant bytes (0x09, 0x0A, and 0x0B) from the returned data. The manager will ignore the first byte (corresponding to address 0x08) and use the remaining three bytes as the valid data for the transfer.
Conclusion
Unaligned transfers in AXI4 can be complex to handle, especially when interfacing with protocols like APB that do not natively support unaligned transfers. However, by carefully managing the WSTRB signal for WRITE transfers and aligning addresses for READ transfers, it is possible to implement a robust solution that handles unaligned transfers correctly. The key is to ensure that the AXI4 manager, AXI4 fabric, and AXI4 to APB bridge all work together to align addresses and data appropriately, ensuring that unaligned transfers are correctly converted into aligned transfers that the APB subordinate can handle.
By following the guidelines and examples provided in this post, HDL developers can implement AXI4 unaligned transfers with confidence, ensuring that their designs are both efficient and compliant with the AXI4 protocol.
