AHB Pipelined Transfers: Address and Data Phase Overlap in Multi-Slave Systems
In Advanced High-performance Bus (AHB) systems, pipelining is a fundamental feature that allows for efficient data transfer between masters and slaves. The scenario described involves a single AHB master initiating back-to-back transactions to two different slaves, Slave1 and Slave2. The first transaction targets address A (Slave1), and the second transaction targets address B (Slave2). The key question revolves around the timing of the address and data phases, specifically whether the address phase of the second transaction (address B) can begin in the second clock cycle while the data phase of the first transaction (address A) is still ongoing.
In AHB, the address phase of a transaction can overlap with the data phase of the previous transaction, provided that the slaves and the bus fabric support this pipelining. The address phase of the second transaction (address B) can indeed start in the second clock cycle, even if the data phase of the first transaction (address A) is still in progress. This is because AHB is designed to handle such pipelined transfers, where the address phase of one transaction can be initiated while the data phase of the previous transaction is being completed.
The behavior of the HREADY signal is crucial in determining the timing of these phases. HREADY is driven by the slave that is currently in the data phase. If Slave1 (address A) decides to insert wait states by deasserting HREADY, the data phase of the first transaction will be extended, which in turn will delay the start of the data phase of the second transaction (address B). However, the address phase of the second transaction can still proceed independently, as long as the bus fabric and the slaves are designed to handle such pipelined operations.
The timing diagram in Figure 3-5 of the AHB specification (AHB, AHB-lite, or AHB5) provides a clear illustration of this behavior. It shows multiple transfers with the second transfer (address B) experiencing wait states during its data phase, which delays the completion of the address phase of the subsequent transfer (address C). This diagram is a valuable reference for understanding how pipelined transfers work in AHB systems.
HSELx Signal Behavior During Overlapping Address and Data Phases
The behavior of the HSELx signal in the described scenario is another critical aspect that needs to be understood. HSELx is the slave select signal that indicates which slave is being addressed during the address phase of a transaction. In the first clock cycle, HSEL1 will be high, indicating that Slave1 is being addressed for the first transaction (address A). However, in the second clock cycle, both the address phase of the second transaction (address B) and the data phase of the first transaction (address A) are occurring simultaneously.
During the second clock cycle, HSEL2 will be high for the address phase of the second transaction (address B), while HSEL1 will remain high for the data phase of the first transaction (address A). This is because the HSELx signal is asserted during the address phase to indicate which slave is being targeted, and it remains asserted during the data phase to ensure that the correct slave is responding to the data transfer.
The HSELx signal behavior can be summarized as follows:
- Clock Cycle 1: HSEL1 is high for the address phase of the first transaction (address A).
- Clock Cycle 2: HSEL2 is high for the address phase of the second transaction (address B), while HSEL1 remains high for the data phase of the first transaction (address A).
This overlapping of HSELx signals is a normal behavior in AHB systems and is handled by the bus fabric, which ensures that the correct slave is selected for both the address and data phases of each transaction.
Implementing and Verifying HSELx Signal Behavior in AHB Systems
To implement and verify the correct behavior of the HSELx signal in an AHB system with multiple slaves, the following steps should be taken:
-
Design the Bus Fabric to Handle Pipelined Transfers: The bus fabric must be designed to support pipelined transfers, where the address phase of one transaction can overlap with the data phase of another transaction. This involves ensuring that the HSELx signals are correctly generated and routed to the appropriate slaves during both the address and data phases.
-
Implement the HREADY Signal Logic: The HREADY signal logic must be implemented to handle wait states inserted by the slaves. The HREADY signal is driven by the slave that is currently in the data phase, and it must be correctly propagated to the master and other slaves to ensure proper timing of the address and data phases.
-
Verify HSELx Signal Behavior Using Simulation: The behavior of the HSELx signals should be verified using simulation. This involves creating test cases that simulate the scenario described, where a master initiates back-to-back transactions to two different slaves. The simulation should verify that the HSELx signals are correctly asserted and deasserted during the address and data phases of each transaction.
-
Check for Timing Violations: The simulation should also check for any timing violations that may occur due to the overlapping of the address and data phases. This includes ensuring that the setup and hold times for the HSELx signals are met and that there are no glitches or incorrect assertions of the HSELx signals.
-
Validate the Design with Real Hardware: Once the design has been verified in simulation, it should be validated with real hardware. This involves testing the AHB system with actual masters and slaves to ensure that the HSELx signals behave as expected in a real-world scenario.
-
Document the Design and Verification Process: Finally, the design and verification process should be thoroughly documented. This includes documenting the bus fabric design, the HREADY signal logic, the simulation test cases, and the results of the hardware validation. This documentation will be valuable for future reference and for ensuring that the design can be easily modified or extended if needed.
By following these steps, the correct behavior of the HSELx signals in an AHB system with multiple slaves can be ensured, and the system can be verified to handle pipelined transfers correctly.
Conclusion
In conclusion, the behavior of the HSELx signals in an AHB system with multiple slaves is a critical aspect that must be carefully designed and verified. The overlapping of the address and data phases in pipelined transfers requires that the HSELx signals be correctly asserted and deasserted to ensure that the correct slave is selected for each transaction. By following the steps outlined above, the correct behavior of the HSELx signals can be ensured, and the AHB system can be verified to handle pipelined transfers efficiently and correctly.
