Handling Early Burst Termination in AHB WRAP16 Bursts with INCR Completion

WRAP16 Burst Early Termination and INCR Burst Address Calculation

When dealing with the AHB protocol, one of the more complex scenarios involves the handling of early burst termination (EBT) during a WRAP16 burst. Specifically, the challenge arises when an EBT occurs partway through a WRAP16 burst, and the remaining beats need to be completed using an INCR burst. The primary question is whether the address calculation for the remaining beats should follow the WRAP burst addressing scheme or the INCR burst addressing scheme. This scenario is not explicitly covered in the ARM Technical Reference Manual (TRM), leading to ambiguity in implementation.

In a WRAP16 burst, the address wraps around at a boundary defined by the burst length. For example, in a WRAP16 burst with a 4-byte data width, the address will wrap every 64 bytes (16 beats * 4 bytes per beat). If an EBT occurs after a certain number of beats, the remaining beats must be completed using an INCR burst. The key issue is determining how the address should increment after the EBT. Should it continue to wrap as per the WRAP16 burst, or should it increment linearly as per the INCR burst?

This issue is critical because incorrect address calculation can lead to data corruption, misaligned memory accesses, or even system crashes. The ambiguity in the ARM TRM regarding this specific scenario necessitates a deep dive into the AHB protocol specifications and a thorough understanding of how WRAP and INCR bursts operate.

Early Burst Termination Before and After WRAP Boundary

The behavior of the address calculation after an EBT in a WRAP16 burst depends on whether the EBT occurs before or after the WRAP boundary. The WRAP boundary is the point at which the address wraps around in a WRAP burst. For a WRAP16 burst, this boundary is determined by the burst length and the data width. For example, in a WRAP16 burst with a 4-byte data width, the WRAP boundary occurs every 64 bytes.

If the EBT occurs after the WRAP boundary, the remaining beats can be completed using a single INCR burst. In this case, the address should increment linearly from the point of termination. This is because the WRAP boundary has already been crossed, and the address no longer needs to wrap around. The INCR burst will continue to increment the address linearly until all remaining beats are completed.

However, if the EBT occurs before the WRAP boundary, the situation is more complex. In this case, the remaining beats must be completed using two INCR bursts. The first INCR burst will complete the beats up to the WRAP boundary, and the second INCR burst will handle the beats after the WRAP boundary. This is necessary because the address needs to wrap around at the WRAP boundary, and a single INCR burst cannot handle this wrapping behavior.

The distinction between these two scenarios is crucial for correct address calculation. Failing to account for the WRAP boundary can result in incorrect memory accesses, leading to data corruption or system instability. Therefore, it is essential to determine whether the EBT occurs before or after the WRAP boundary and adjust the address calculation accordingly.

Implementing Correct Address Calculation for EBT in WRAP16 Bursts

To correctly implement the address calculation for EBT in a WRAP16 burst, the following steps should be taken:

1. Determine the WRAP Boundary: The first step is to calculate the WRAP boundary for the WRAP16 burst. This is determined by the burst length and the data width. For a WRAP16 burst with a 4-byte data width, the WRAP boundary occurs every 64 bytes. This boundary is critical for determining whether the EBT occurs before or after the WRAP boundary.

2. Check the EBT Position: Once the WRAP boundary is known, the next step is to determine whether the EBT occurs before or after the WRAP boundary. This can be done by comparing the current address at the time of EBT with the WRAP boundary. If the current address is less than the WRAP boundary, the EBT occurs before the boundary. If the current address is greater than or equal to the WRAP boundary, the EBT occurs after the boundary.

3. Calculate the Address for INCR Bursts: Depending on the position of the EBT relative to the WRAP boundary, the address calculation for the remaining beats will differ. If the EBT occurs after the WRAP boundary, the address should increment linearly from the point of termination. If the EBT occurs before the WRAP boundary, two INCR bursts are required. The first INCR burst should increment the address linearly up to the WRAP boundary, and the second INCR burst should start from the WRAP boundary and increment linearly until all remaining beats are completed.

4. Handle the Remaining Beats: Once the address calculation is complete, the remaining beats should be handled using the appropriate INCR burst(s). It is important to ensure that the address calculation is correct to avoid misaligned memory accesses or data corruption.

5. Verify the Implementation: Finally, the implementation should be thoroughly verified to ensure that the address calculation is correct in all scenarios. This can be done using simulation and formal verification techniques. The verification should cover all possible cases, including EBT before and after the WRAP boundary, to ensure that the implementation is robust and handles all edge cases correctly.

Example Scenario

Consider a WRAP16 burst with a 4-byte data width, starting at address 0x1000. The WRAP boundary for this burst is at address 0x1040 (0x1000 + 64 bytes). If an EBT occurs after 3 beats (at address 0x100C), the EBT occurs before the WRAP boundary. In this case, two INCR bursts are required. The first INCR burst should complete the beats up to the WRAP boundary (addresses 0x100C to 0x103C), and the second INCR burst should handle the beats after the WRAP boundary (addresses 0x1040 to 0x104C).

If the EBT occurs after 5 beats (at address 0x1014), the EBT occurs after the WRAP boundary. In this case, a single INCR burst is sufficient to complete the remaining beats. The address should increment linearly from 0x1014 until all remaining beats are completed.

Verification Strategy

To verify the correct implementation of the address calculation for EBT in WRAP16 bursts, the following verification strategy should be employed:

1. Testbench Development: Develop a comprehensive testbench that covers all possible scenarios, including EBT before and after the WRAP boundary. The testbench should include both directed and random tests to ensure that all edge cases are covered.

2. Simulation: Run simulations to verify that the address calculation is correct in all scenarios. The simulations should include checks for correct address incrementing, proper handling of the WRAP boundary, and correct completion of the remaining beats.

3. Formal Verification: Use formal verification techniques to prove that the address calculation is correct in all scenarios. Formal verification can provide a mathematical proof that the implementation is correct, which is especially useful for complex scenarios like EBT in WRAP16 bursts.

4. Debugging: If any issues are found during simulation or formal verification, debug the implementation to identify and fix the root cause. This may involve reviewing the address calculation logic, checking the WRAP boundary calculation, and ensuring that the INCR bursts are correctly implemented.

5. Regression Testing: Once the implementation is verified, run regression tests to ensure that the fixes do not introduce new issues. Regression testing should cover all previously tested scenarios as well as any new scenarios that may have been introduced during debugging.

Conclusion

Handling early burst termination in AHB WRAP16 bursts with INCR completion is a complex but critical aspect of AHB protocol implementation. The key to correct implementation lies in understanding the WRAP boundary and determining whether the EBT occurs before or after this boundary. By following the steps outlined above, you can ensure that the address calculation is correct and that the remaining beats are completed using the appropriate INCR bursts. Thorough verification, including simulation and formal verification, is essential to ensure that the implementation is robust and handles all edge cases correctly.