AXI VIP Fails to Complete 128-bit Read Burst with ARLEN=0x7
The core issue revolves around an AXI Verification IP (VIP) acting as a memory model during a read burst transaction. The AXI master initiates a read burst with the following parameters: ARSIZE=0x4 (128-bit data width), ARLEN=0x7 (8 transfers), and ARBURST=0x1 (INCR burst type). The expected behavior is to read 512-bit data chunks from addresses 0x0-0x3F and 0x40-0x7F, with each chunk split into 4 valid data beats due to the 128-bit data width. However, the VIP incorrectly duplicates the data from addresses 0x0-0x3F across all 8 data beats, causing simulation failures. This issue is not observed in a similar design with identical AXI burst settings, suggesting a potential problem with the VIP configuration or implementation.
The AXI protocol mandates that for an INCR burst type, the address for each transfer within the burst is incremented by the data size (in this case, 128 bits or 0x10 bytes). The VIP should generate unique data for each transfer, but instead, it repeats the same data for the first four transfers across all eight beats. This behavior violates the AXI protocol and indicates a malfunction in the VIP’s address generation or data handling logic.
VIP Configuration Mismatch and Address Calculation Errors
The root cause of this issue likely stems from one or more of the following factors:
-
VIP Configuration Mismatch: The VIP might not be configured correctly to handle the specified ARSIZE and ARLEN values. The VIP’s internal logic for address calculation and data generation may not align with the AXI protocol’s requirements for INCR bursts. Specifically, the VIP might be misinterpreting the ARSIZE and ARLEN parameters, leading to incorrect address increments or data duplication.
-
Address Calculation Errors: The VIP’s address calculation logic might be flawed, causing it to generate the same address range (0x0-0x3F) for all transfers within the burst. This could occur if the VIP fails to increment the address by the appropriate amount (0x10 bytes for ARSIZE=0x4) after each transfer. Alternatively, the VIP might be resetting the address counter prematurely, causing it to restart from the initial address.
-
Data Buffer Misalignment: The VIP’s data buffer might be misaligned or improperly sized, causing it to reuse the same data for multiple transfers. This could happen if the buffer is not large enough to hold the entire burst data or if the buffer’s write pointer is not advancing correctly.
-
Protocol Compliance Issues: The VIP might not fully comply with the AXI protocol’s requirements for burst transactions. For example, it might not handle the ARLEN parameter correctly, leading to fewer or more transfers than expected. Additionally, the VIP might not support the specified ARSIZE value, causing it to default to a smaller data width and repeat data to fill the 512-bit bus.
Debugging and Resolving VIP Data Duplication and Address Calculation Issues
To address this issue, follow these steps:
-
Verify VIP Configuration: Double-check the VIP’s configuration settings to ensure they match the AXI master’s parameters. Specifically, confirm that the VIP is configured to support ARSIZE=0x4 (128-bit data width) and ARLEN=0x7 (8 transfers). If the VIP has separate settings for data width and burst length, ensure they are set correctly.
-
Inspect Address Calculation Logic: Review the VIP’s address calculation logic to ensure it increments the address by the correct amount (0x10 bytes) after each transfer. If the logic is implemented in RTL, simulate it independently to verify its behavior. If the logic is part of the VIP’s internal code, consult the VIP’s documentation or contact the vendor for clarification.
-
Check Data Buffer Implementation: Examine the VIP’s data buffer implementation to ensure it is large enough to hold the entire burst data and that the write pointer advances correctly after each transfer. If the buffer is implemented in RTL, simulate it independently to verify its behavior. If the buffer is part of the VIP’s internal code, consult the VIP’s documentation or contact the vendor for clarification.
-
Validate Protocol Compliance: Verify that the VIP fully complies with the AXI protocol’s requirements for burst transactions. Specifically, ensure it handles the ARLEN and ARSIZE parameters correctly and generates the expected number of transfers with unique data. If the VIP does not comply with the protocol, consider using a different VIP or modifying the existing one to meet the requirements.
-
Simulate with Different Parameters: Run simulations with different ARSIZE and ARLEN values to determine if the issue is specific to the current configuration. For example, try ARSIZE=0x2 (32-bit data width) and ARLEN=0x3 (4 transfers) to see if the VIP behaves correctly. This can help isolate the problem and identify any limitations in the VIP’s implementation.
-
Contact VIP Vendor: If the issue persists after verifying the configuration and implementation, contact the VIP vendor for support. Provide detailed information about the problem, including the simulation logs, configuration settings, and any relevant code snippets. The vendor might be able to identify a bug in the VIP or provide a workaround.
By following these steps, you can systematically identify and resolve the issue with the AXI VIP’s read burst completion and data duplication. This approach ensures that the VIP behaves correctly and complies with the AXI protocol, enabling successful simulation and verification of your ARM-based SoC design.
