BP131 AXI Downsizer Addressing and Data Width Conversion

AXI Downsizer Address and Data Handling in 64-bit to 32-bit Conversion

The BP131 AXI Downsizer is a critical component in ARM-based SoC designs, particularly when interfacing between AXI masters and slaves with differing data widths. One of the most common use cases involves converting a 64-bit AXI transaction into one or more 32-bit transactions. This process is not only about splitting the data but also involves careful handling of address generation, burst types, and timing considerations. The core challenge lies in understanding how the Downsizer processes addresses during this conversion, especially when dealing with burst transactions and different addressing modes such as INCR, WRAP, and FIXED.

When a 64-bit transaction is converted into two 32-bit transactions, the Downsizer must ensure that the address for each 32-bit transfer is correctly calculated and aligned. For example, if the original 64-bit transaction has a starting address of 0x8000_0000, the Downsizer must determine whether the second 32-bit transfer should use the same address (0x8000_0000) or an incremented address (0x8000_0004). This decision depends on the burst type and the alignment requirements of the AXI protocol. Misalignment or incorrect address generation can lead to data corruption, system crashes, or unexpected behavior in the SoC.

Additionally, the Downsizer must handle the timing of data transfers. In pass-through mode, where the transaction size is 32 bits or less, the data transfer can occur two clock cycles after AxVALIDS is asserted. However, in downsize mode, the first 32-bit transfer can also occur two clock cycles after AxVALIDS, but the first 64-bit transfer requires an additional clock cycle because it is split into two 32-bit transfers. This timing difference must be carefully managed to avoid data loss or protocol violations.

Misalignment Due to Incorrect Burst Type or Address Calculation

One of the primary causes of addressing issues in the BP131 AXI Downsizer is the incorrect handling of burst types and address calculations. The AXI protocol supports three burst types: FIXED, INCR, and WRAP. Each burst type has specific rules for address generation, and the Downsizer must adhere to these rules when converting 64-bit transactions into 32-bit transactions.

In FIXED burst mode, the address remains constant for all data transfers within the burst. This means that if a 64-bit transaction is converted into two 32-bit transactions, both 32-bit transfers will use the same address. However, this can lead to misalignment if the downstream slave expects the address to increment for each transfer. For example, if the original 64-bit transaction has a starting address of 0x8000_0000, both 32-bit transfers will also use 0x8000_0000. This can cause data to be overwritten or misaligned in the slave’s memory.

In INCR burst mode, the address increments for each data transfer. When converting a 64-bit transaction into two 32-bit transactions, the Downsizer must increment the address for the second transfer. For example, if the original 64-bit transaction has a starting address of 0x8000_0000, the first 32-bit transfer will use 0x8000_0000, and the second transfer will use 0x8000_0004. Failure to correctly increment the address can result in data being written to the wrong location or read from the wrong location, leading to data corruption or system errors.

In WRAP burst mode, the address wraps around after reaching a certain boundary. This mode is typically used for cache line accesses. When converting a 64-bit transaction into two 32-bit transactions, the Downsizer must correctly calculate the wrap boundary and ensure that the address wraps around as expected. For example, if the wrap boundary is 0x8000_0008, and the original 64-bit transaction has a starting address of 0x8000_0004, the first 32-bit transfer will use 0x8000_0004, and the second transfer will use 0x8000_0000 (wrapping around to the start of the boundary). Incorrect wrap boundary calculation can lead to data being written or read from the wrong location, causing data corruption or system crashes.

Another potential cause of addressing issues is the incorrect handling of unaligned addresses. The AXI protocol requires that addresses be aligned to the data width of the transaction. For example, a 64-bit transaction must start at an address that is a multiple of 8, and a 32-bit transaction must start at an address that is a multiple of 4. If the original 64-bit transaction has an unaligned address, the Downsizer must correctly align the address for the 32-bit transactions. Failure to do so can result in data misalignment, protocol violations, or system errors.

Implementing Correct Address Calculation and Data Alignment in Downsizer Mode

To resolve addressing issues in the BP131 AXI Downsizer, it is essential to implement correct address calculation and data alignment based on the burst type and alignment requirements of the AXI protocol. The following steps outline the process for ensuring correct address handling during 64-bit to 32-bit conversion:

1. Determine the Burst Type: The first step is to determine the burst type of the original 64-bit transaction. This can be done by examining the AxBURST signal. If the burst type is FIXED, the address will remain constant for all data transfers. If the burst type is INCR, the address will increment for each transfer. If the burst type is WRAP, the address will wrap around after reaching a certain boundary.

2. Calculate the Address for Each 32-bit Transfer: Once the burst type is determined, the next step is to calculate the address for each 32-bit transfer. For FIXED burst mode, the address will remain the same for both 32-bit transfers. For INCR burst mode, the address will increment by 4 for the second transfer. For WRAP burst mode, the address will wrap around after reaching the wrap boundary.

3. Handle Unaligned Addresses: If the original 64-bit transaction has an unaligned address, the Downsizer must correctly align the address for the 32-bit transactions. This can be done by rounding down the address to the nearest multiple of 4. For example, if the original address is 0x8000_0002, the aligned address for the 32-bit transactions will be 0x8000_0000.

4. Generate the Correct AxADDR Signal: The Downsizer must generate the correct AxADDR signal for each 32-bit transfer. This signal should reflect the calculated address based on the burst type and alignment requirements. For example, if the original 64-bit transaction has a starting address of 0x8000_0000 and the burst type is INCR, the AxADDR signal for the first 32-bit transfer will be 0x8000_0000, and the AxADDR signal for the second transfer will be 0x8000_0004.

5. Ensure Correct Timing: The Downsizer must ensure that the timing of the data transfers is correct. In pass-through mode, the data transfer can occur two clock cycles after AxVALIDS is asserted. In downsize mode, the first 32-bit transfer can also occur two clock cycles after AxVALIDS, but the first 64-bit transfer requires an additional clock cycle because it is split into two 32-bit transfers. The Downsizer must ensure that the timing of the data transfers is consistent with the AXI protocol to avoid data loss or protocol violations.

6. Verify the Downstream Slave’s Requirements: Finally, it is essential to verify the requirements of the downstream slave. Some slaves may have specific alignment or addressing requirements that must be adhered to. The Downsizer must be configured to meet these requirements to ensure correct operation.

By following these steps, the BP131 AXI Downsizer can correctly handle address calculation and data alignment during 64-bit to 32-bit conversion, ensuring that data is correctly transferred between AXI masters and slaves with differing data widths. This will prevent data corruption, system crashes, and other issues that can arise from incorrect address handling.

Example Implementation

To illustrate the correct implementation of address calculation and data alignment in the BP131 AXI Downsizer, consider the following example:

• Original 64-bit Transaction:

  • Starting Address: 0x8000_0000
  • Data: 0x1234_5678_abcd_feed
  • Burst Type: INCR
  • Burst Length: 1 (1-beat transaction)

• Downsizer Conversion:

  • The Downsizer converts the 64-bit transaction into two 32-bit transactions.
  • The first 32-bit transfer will have:
    • Address: 0x8000_0000
    • Data: 0x1234_5678
  • The second 32-bit transfer will have:
    • Address: 0x8000_0004
    • Data: 0xabcd_feed

In this example, the Downsizer correctly increments the address for the second 32-bit transfer, ensuring that the data is written to the correct locations in the downstream slave’s memory. This prevents data corruption and ensures that the system operates as expected.

Conclusion

The BP131 AXI Downsizer is a powerful tool for interfacing between AXI masters and slaves with differing data widths. However, it requires careful handling of address calculation and data alignment to ensure correct operation. By understanding the burst types, alignment requirements, and timing considerations, designers can implement the Downsizer in a way that prevents data corruption, system crashes, and other issues. The example provided demonstrates how to correctly handle address calculation and data alignment during 64-bit to 32-bit conversion, ensuring that data is correctly transferred between AXI masters and slaves.