Avoiding Redundant Simulation Cycles for your UVM VIP with a Simple Save-Restore Strategy
In many verification environments, we reuse the same configuration cycles across different testcases. These cycles may involve writing and reading from different configuration and status registers, loading program memories, and other similar tasks to set up a DUT for its targeted stimulus. In many such environments, the time taken during these configuration cycles is very long. Also, there is a lot of redundancy as verification engineers have to run the same set of verified configuration cycles for different testcases leading to a loss in productivity. This is especially true for complex verification environments with multiple interfaces which require different components to be configured.
Here’s where you can find more information on our Verification IP.
Verilog provides an option of saving the state of a design and its testbench at a particular point in time. We can restore the simulation to the same state and continue from there. This can be done by adding appropriate built in system calls from the Verilog code. VCS provides the same options from the Unified Command line Interpreter (UCLI).
However, it is not enough for us to restore simulation from the saved state. For different simulations, we may want to apply different random stimulus to the DUT. In the context of UVM, it may be preferable to run different sequences from a saved state as show below:
In the above example apart from the last step which varies to large extent, the rest of the steps once established need no iterations.
Here we explain how to achieve the above strategy with the simple existing UBUS example available in the standard UVM installation. Simple changes are made in the environment to show what needs to be done to bring in this additional capability. Within the existing set of tests, the two of them, “test_read_modify_write” and “test_r8_w8_r4_w4”, differ only w.r.t. the master sequence being executed: “read_modify_write_seq” and “r8_w8_r4_w4_seq” respectively.
Let’s say we have a scenario where we want to save a simulation once the reset_phase is done and then begin executing different sequences post the reset_phase the restored simulations. To demonstrate a similar scenario through the UBUS tests, we introduced a delay in the reset_phase of the base test (in a real test, this may correspond to the PLL lock, DDR Initialization, Basic DUT Configuration).
The following snippet shows how the existing tests are modified to bring in the capability of running different tests in different ‘restored’ simulations:
Here, we have made two major modifications:
- Shifted the setting of the phase default_sequence from the build phase to the start of the main phase.
- Got the name of the sequence as an argument from the command-line and processed the string appropriately in the code to execute the sequence on the relevant sequencer.
As you can see, the changes are kept to a minimum. With this, the above generic framework is ready to be simulated. In VCS, one way to enable the save/restore flow is:
Thus above strategy helps in optimal utilization of compute resources with simple changes in your verification flow. Hope this was useful and you manage to easily make changes in your verification environment to adopt this flow and avoid redundant simulation cycles.
Authored by Parag Goel
Here’s where you can find more information on our Verification IP.
