VIP Café

A place where the experts go to chat about verification IP.

5
Mar

In many verification environments, you reuse the same configuration cycles across different testcases. These cycles might involve writing and reading from different configuration and status registers, loading program memories, and other similar tasks to set up a DUT for the targeted stimulus. In many of these environments, the time taken during this configuration cycles are very long. Also, there is a lot of redundancy as the 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.

The Verilog language provides an option of saving the state of the design and the testbench at a particular point in time. You 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 you to restore simulation from the saved state. For different simulations, you may want to apply different random stimulus to the DUT. In the context of UVM, you would want 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 namely, “test_read_modify_write” and “test_r8_w8_r4_w4”, differs only w.r.t. the master sequence being executed – i.e. “read_modify_write_seq” and “r8_w8_r4_w4_seq” respectively.

Let’s say that we have a scenario where we would want to save a simulation once the reset_phase is done and then start 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.

As evident in the code we made two major modifications:

  1. Shifted the setting of the phase default_sequence from the build phase to the start of the main phase.
  2. Get the name of the sequence as an argument from the command-line and process 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 of the different ways, the save/restore flow can be enabled as follows.

Thus above strategy helps in optimal utilization of the compute resources with simple changes in your verification flow. Hope this was useful and you manage to easily make the changes in your verification environment to adopt this flow and avoid redundant simulation cycles.

Share and Enjoy:
  • Print
  • del.icio.us
  • Facebook
  • Twitter
  • Google Bookmarks
Category : IP Verification / VIP Design

2 Responses to “Avoiding Redundant Simulation Cycles with your UVM VIP based simulation with a Simple Save-Restore Strategy”


mpattaje June 12, 2014

Hi Parag,

For me, the initial configurations are not so generic. But after the configurations, my test takes a long time to wait for a ready signal to be asserted. Will the above method help to do that? Do you think that will make any sense?

Murali

Parag Goel June 20, 2014

Hi Murali,

The current solution available,
1. Run the simulation and save it to pre-defined time
2. Save the state
3. Run further till end of simulation

Now you can restore from beginning to a specified pre-defined time and then continue from there.

If I understand correctly, in your case, you are likely to save the intermediate cycles of a simulation while both the beginning and the end of simulation being variable.
This is not currently what is supported.

Also, as per my opinion this may have disastrous effect. You are making the assumption that in different configuration the assertion of the ready signal is happening in a pre-defined way which may not be the case, although the end result is assertion of signal. Secondly, restoring the states in the middle of simulation is hard to debug and can lead to bugs not exposed in simulation.

Regards,
Parag



You must be logged in to post a comment.