Fixed Arbitration Breaking AHB Burst Transfers: Analysis and Solutions

AHB Burst Transfer Interruption Due to Fixed Arbitration

In ARM AMBA AHB (Advanced High-performance Bus) systems, burst transfers are a fundamental mechanism for efficient data movement between masters and slaves. A burst transfer allows a master to perform multiple data transactions in a sequence without repeatedly requesting the bus, thereby improving system performance. However, when fixed arbitration is employed in an interconnect or BusMatrix, burst transfers can be interrupted, leading to non-compliant behavior on the slave interface. This issue arises when a higher-priority master requests access to the same slave during an ongoing burst transfer from a lower-priority master.

The AMBA AHB protocol defines specific signaling for burst transfers, including the use of the HSEQ (sequential) and HNONSEQ (non-sequential) signals to indicate the start and continuation of a burst. When a burst is interrupted due to fixed arbitration, the slave may observe an unexpected HNONSEQ transfer in the middle of a burst sequence. This behavior can cause confusion in the slave’s state machine, leading to incorrect data handling or protocol violations.

The problem is particularly pronounced in systems using the AMBA Design Kit BusMatrix, which supports three arbitration modes: BURST, ROUND, and FIXED. While BURST and ROUND arbitration modes respect the integrity of defined-length bursts, the FIXED arbitration mode can break ongoing bursts to prioritize higher-priority masters. This interruption must be managed carefully to ensure that the AHB protocol remains compliant and that the slave can correctly process the remaining burst transfers.

Fixed Arbitration Overriding Burst Continuity and Slave Expectations

The root cause of this issue lies in the interaction between the arbitration logic in the interconnect or BusMatrix and the AHB protocol’s burst transfer rules. When a higher-priority master requests access to a shared slave, the interconnect must decide whether to interrupt the ongoing burst from the lower-priority master. In the case of fixed arbitration, the interconnect prioritizes the higher-priority master, leading to the interruption of the burst.

From the perspective of the original master, the burst transfer appears to be stalled due to wait states (HREADY being low). However, the interconnect internally switches to the higher-priority master, causing the slave to see an unexpected HNONSEQ transfer. This behavior violates the slave’s expectation of a continuous burst sequence, as defined by the AHB protocol.

The interconnect must ensure that the remaining burst transfers from the original master are presented to the slave in a protocol-compliant manner. This requires the interconnect to override the HBURST signal and restart the burst with a HNONSEQ transfer. Typically, the interconnect simplifies this process by converting the remaining burst into an INCR (incremental) burst type, which does not require a predefined length.

Additionally, the interconnect must handle the address and control signals correctly to ensure that the slave can process the remaining burst transfers without errors. This includes maintaining the correct address sequence and ensuring that the HTRANS (transfer type) signals are set appropriately for each transfer.

Implementing Protocol-Compliant Burst Handling in Fixed Arbitration Systems

To address the issue of burst interruption in fixed arbitration systems, the following steps should be taken to ensure protocol compliance and correct operation:

1. Interconnect Logic for Burst Handling: The interconnect must include logic to detect when a burst transfer is interrupted due to fixed arbitration. When this occurs, the interconnect should save the state of the original burst, including the remaining transfer count and the current address. This allows the interconnect to correctly restart the burst when the original master is re-granted access to the slave.

2. Override HBURST Signal: When the original master is re-granted access to the slave, the interconnect must override the HBURST signal to indicate the remaining transfers. Typically, this involves setting HBURST to INCR to simplify the burst handling. The interconnect must also ensure that the HNONSEQ signal is asserted for the first transfer of the remaining burst.

3. Address and Control Signal Management: The interconnect must correctly manage the address and control signals to ensure that the slave can process the remaining burst transfers. This includes incrementing the address correctly for each transfer and setting the HTRANS signal to SEQ for the remaining transfers in the burst.

4. Slave State Machine Handling: The slave’s state machine must be designed to handle unexpected HNONSEQ transfers during a burst. This may involve adding logic to detect and recover from burst interruptions, ensuring that the slave can continue processing the remaining transfers correctly.

5. Verification and Testing: Comprehensive verification and testing should be performed to ensure that the interconnect and slave handle burst interruptions correctly. This includes creating test scenarios that simulate fixed arbitration interruptions and verifying that the system remains protocol-compliant.

By implementing these steps, the system can ensure that burst transfers are handled correctly in the presence of fixed arbitration, maintaining protocol compliance and preventing errors in data handling.

Detailed Analysis of Fixed Arbitration and Burst Handling

To further understand the issue and its resolution, let’s delve into the detailed behavior of fixed arbitration and burst handling in an AHB system.

Fixed Arbitration Mechanism

Fixed arbitration is a priority-based arbitration scheme where each master is assigned a fixed priority level. When multiple masters request access to a shared slave, the interconnect grants access to the highest-priority master. If a higher-priority master requests access while a lower-priority master is performing a burst transfer, the interconnect may interrupt the burst to grant access to the higher-priority master.

Burst Transfer Interruption

When a burst transfer is interrupted, the interconnect must ensure that the remaining transfers are handled correctly. This involves:

• Saving Burst State: The interconnect must save the state of the original burst, including the remaining transfer count, the current address, and the burst type. This allows the interconnect to correctly restart the burst when the original master is re-granted access.

• Restarting the Burst: When the original master is re-granted access, the interconnect must restart the burst with a HNONSEQ transfer and override the HBURST signal to indicate the remaining transfers. Typically, the burst type is set to INCR to simplify the handling of the remaining transfers.

• Managing Address and Control Signals: The interconnect must correctly manage the address and control signals to ensure that the slave can process the remaining transfers. This includes incrementing the address correctly for each transfer and setting the HTRANS signal to SEQ for the remaining transfers in the burst.

Slave State Machine Handling

The slave’s state machine must be designed to handle unexpected HNONSEQ transfers during a burst. This may involve:

• Detecting Burst Interruptions: The slave’s state machine should include logic to detect when a HNONSEQ transfer occurs during a burst. This may involve monitoring the HTRANS and HBURST signals to detect unexpected changes.

• Recovering from Burst Interruptions: The slave’s state machine should include logic to recover from burst interruptions. This may involve resetting the burst state and continuing to process the remaining transfers correctly.

Verification and Testing

Comprehensive verification and testing should be performed to ensure that the interconnect and slave handle burst interruptions correctly. This includes:

• Creating Test Scenarios: Test scenarios should be created to simulate fixed arbitration interruptions. These scenarios should include cases where a higher-priority master interrupts a burst transfer from a lower-priority master.

• Verifying Protocol Compliance: The system should be verified to ensure that it remains protocol-compliant during burst interruptions. This includes verifying that the HNONSEQ and HBURST signals are set correctly and that the address and control signals are managed correctly.

• Testing Slave State Machine: The slave’s state machine should be tested to ensure that it can detect and recover from burst interruptions correctly. This includes verifying that the slave can continue processing the remaining transfers correctly after an interruption.

Conclusion

Fixed arbitration in ARM AMBA AHB systems can lead to the interruption of burst transfers, causing non-compliant behavior on the slave interface. To address this issue, the interconnect must include logic to handle burst interruptions correctly, ensuring that the remaining transfers are presented to the slave in a protocol-compliant manner. The slave’s state machine must also be designed to handle unexpected HNONSEQ transfers during a burst. Comprehensive verification and testing should be performed to ensure that the system remains protocol-compliant and handles burst interruptions correctly. By implementing these steps, the system can ensure efficient and correct operation in the presence of fixed arbitration.