AXI4 Initiator-Target Data Misalignment During Narrow Burst Transfers
In an AXI4-based system, narrow burst transfers occur when the data width of the transaction is smaller than the width of the data bus. For instance, a 32-bit read request on a 64-bit data bus is a narrow burst transfer. The AXI protocol specifies that the data must be aligned according to the address (AxADDR), transfer size (AxSIZE), and burst type (AxBURST). However, in the described scenario, the AXI target (memory) is returning the entire 64-bit data bus content instead of aligning the 32-bit data to the lower 32 bits of the bus. This behavior is causing confusion for the initiator, which expects the data to be aligned to the least significant bits (LSBs) of the bus.
The issue manifests in three test cases:
- Case 1: Start address = 0x0,
ARSIZE= 2 (4-byte transfer). The received data matches expectations because the 32-bit data naturally aligns with the lower 32 bits of the 64-bit bus. - Case 2: Start address = 0x4,
ARSIZE= 2. The received data is 64’h77_66_55_44_33_22_11_00, but the expected data is 64’hxx_xx_xx_xx_77_66_55_44. The target is not aligning the 32-bit data to the lower 32 bits of the bus. - Case 3: Start address = 0x5,
ARSIZE= 2. The received data is 64’h77_66_55_44_33_22_11_00, but the expected data is 64’hxx_xx_xx_xx_77_66_55_44. The target is again not aligning the data correctly.
This behavior suggests that the AXI target is not adhering to the AXI protocol’s requirements for narrow burst transfers, leading to incorrect data alignment and potential functional errors in the system.
AXI Protocol Misinterpretation and Target Implementation Simplification
The root cause of this issue lies in a combination of protocol misinterpretation and implementation simplification. According to the AXI protocol, the target must use the AxADDR, AxSIZE, and AxBURST signals to determine which byte lanes are valid for the transfer. For narrow burst transfers, the target should only return data on the valid byte lanes corresponding to the address and transfer size. However, in this case, the target is returning data on all byte lanes, ignoring the AxSIZE parameter.
Protocol Misinterpretation
The initiator expects the target to align the data to the LSBs of the bus, but this is not a requirement of the AXI protocol. The protocol specifies that the data must be placed on the byte lanes corresponding to the address and transfer size. For example:
- In Case 2, the start address is 0x4, and the transfer size is 4 bytes. The valid byte lanes are 4, 5, 6, and 7. The target should return the data on these byte lanes, leaving the lower 32 bits (byte lanes 0-3) as "don’t care" (xx).
- In Case 3, the start address is 0x5, and the transfer size is 4 bytes. However, the address is unaligned, meaning only byte lanes 5, 6, and 7 are valid. The target should return the data on these byte lanes, leaving the remaining byte lanes as "don’t care."
Target Implementation Simplification
The target in this scenario is likely implemented to simplify the design. Instead of handling narrow burst transfers by aligning the data to the correct byte lanes, the target is returning the entire 64-bit data bus content. This approach reduces the complexity of the target design but shifts the burden of data alignment to the initiator. While this is not a protocol violation, it is not an optimal implementation, as it requires the initiator to perform additional data manipulation.
Implications for the Initiator
The initiator must store the AxSIZE information for all pending requests and use this information to extract the correct data from the received bus content. This adds complexity to the initiator design, as it must now include logic to shift and mask the received data based on the AxSIZE and AxADDR values. For example:
- In Case 2, the initiator must shift the received data right by 32 bits to extract the valid 32-bit data.
- In Case 3, the initiator must shift the received data right by 40 bits and mask the upper 24 bits to extract the valid 24-bit data.
Implementing Correct Data Alignment and Verification Strategies
To resolve this issue, both the target and initiator designs must be updated to ensure correct data alignment and handling of narrow burst transfers. Below are the recommended steps for implementation and verification.
Target Design Updates
-
Byte Lane Handling: The target must be updated to handle narrow burst transfers correctly. It should use the
AxADDRandAxSIZEsignals to determine the valid byte lanes for each transfer and return data only on those lanes. For example:- For a 4-byte transfer starting at address 0x4, the target should return data on byte lanes 4, 5, 6, and 7.
- For a 4-byte transfer starting at address 0x5, the target should return data on byte lanes 5, 6, and 7 (since the address is unaligned).
-
Data Masking: The target should implement data masking to ensure that invalid byte lanes are set to "don’t care" values. This can be achieved using a multiplexer or masking logic that selects the valid byte lanes based on the
AxADDRandAxSIZEsignals.
Initiator Design Updates
-
Data Extraction Logic: The initiator must be updated to include logic for extracting the correct data from the received bus content. This logic should use the stored
AxSIZEandAxADDRinformation to shift and mask the received data. For example:- For a 4-byte transfer starting at address 0x4, the initiator should shift the received data right by 32 bits.
- For a 4-byte transfer starting at address 0x5, the initiator should shift the received data right by 40 bits and mask the upper 24 bits.
-
Pending Request Tracking: The initiator must track the
AxSIZEandAxADDRinformation for all pending requests. This can be implemented using a FIFO or register file that stores the relevant information for each outstanding transaction.
Verification Strategies
-
Protocol Compliance Testing: Develop test cases to verify that the target adheres to the AXI protocol’s requirements for narrow burst transfers. These test cases should cover all possible combinations of
AxADDR,AxSIZE, andAxBURSTvalues.- Test Case 1: 4-byte transfer starting at address 0x0.
- Test Case 2: 4-byte transfer starting at address 0x4.
- Test Case 3: 4-byte transfer starting at address 0x5.
-
Data Alignment Verification: Verify that the initiator correctly extracts and aligns the data based on the
AxSIZEandAxADDRinformation. This can be done using scoreboarding or reference models that compare the received data with the expected values. -
Corner Case Testing: Test edge cases, such as unaligned addresses and maximum burst lengths, to ensure that the design handles all scenarios correctly. For example:
- Test Case 4: 4-byte transfer starting at address 0x7 (unaligned address).
- Test Case 5: 8-byte transfer starting at address 0x0 (non-narrow burst).
-
Performance Analysis: Analyze the performance impact of the additional data manipulation logic in the initiator. Ensure that the design meets the system’s timing and throughput requirements.
Example Implementation
Below is an example of how the initiator can implement the data extraction logic using SystemVerilog:
logic [63:0] received_data;
logic [2:0] arsize;
logic [31:0] extracted_data;
always_comb begin
case (arsize)
3'b010: begin // 4-byte transfer
if (araddr[2:0] == 3'b100) begin // Start address 0x4
extracted_data = received_data[63:32];
end else if (araddr[2:0] == 3'b101) begin // Start address 0x5
extracted_data = {8'hxx, received_data[63:40]};
end else begin // Start address 0x0
extracted_data = received_data[31:0];
end
end
// Add cases for other transfer sizes
default: extracted_data = received_data[31:0];
endcase
end
Conclusion
The AXI narrow burst misalignment issue arises from a combination of protocol misinterpretation and target implementation simplification. By updating the target to handle narrow burst transfers correctly and adding data extraction logic to the initiator, the issue can be resolved. Comprehensive verification strategies, including protocol compliance testing, data alignment verification, and corner case testing, are essential to ensure the design’s correctness and robustness.
