Handling Resets in a UVM-Based AXI Testbench
Despite being a common requirement, handling hardware resets in a verification environment has always been beset by a host of challenges, including:
- Reset behavior has to be propagated to all testbench components.
- All UVM components such as driver monitor and scoreboard should be capable of reacting to the reset (i.e., they should be made reset aware).
- All pending sequences already scheduled by the test should be removed from all sequencers and virtual sequencers.
- Once the system comes out of reset the traffic should be re-generated to the DUT.
When a reset happens, special reset handling capabilities are especially important for the driver. This problem gets further exacerbated in AXI environments for two reasons.
- The AXI interface has multiple channels, each of which work independently, and /li>
- the AXI protocol supports out-of-order responses and multiple outstanding transactions.
In this project, we modeled all the UVM testbench components for an AXI-based environment, with a capability to handle on-the-fly resets
For more information about this project, or if you are interested any VIP development, please contact us email@example.com