Having Your Cake and Eating It Too: Programming UVM Sequences with DPI-C

Many verification environments today are developed using SystemVerilog¹ UVM². They include UVM sequences, sequence items, environments, and tests. Many other verification environments today are developed using C. Often the C environments are used initially for architectural development and performance modeling.

Unfortunately, those C verification environments – really “workloads” must be redesigned or rewritten for an RTL or gate-level simulation testbench. This paper explains a way to have both UVM SystemVerilog and C – and enjoy the benefits of both.

In this paper, we take an existing UVM verification environment³ and add code in various places to achieve our C test programs. The added code is denoted by being in a “box” in the source code listings.

The UVM

Using the UVM involves many steps. Normally a verification architect designs the testbench architecture and devises the interfaces. Then a second, larger team writes tests that exercise the DUT by using the testbench architecture and the various interfaces. Additionally, the testbench checks for correctness using coverage and checkers.

^{Figure 1: Typical UVM Agent Used in Verification on an Interface}

In this paper, an example UVM testbench will be designed with multiple interfaces. Those interfaces will have APIs – like read() and write(). Any API that is supported could be used - postedwrite(), read_register(), write_register(), etc. These APIs are really helper tasks or functions or transactions that the verification system can use to encapsulate larger or more complex sets of functionality.

A randomized testbench can be written strictly in SystemVerilog that exercises these interfaces (APIs) and the DUT underneath, but two things make the approach of this paper more helpful. First, a random testbench isn’t always exactly what is needed. Often a “program” needs to be written that programs the registers and loads memory a specific way. Second, there are many more C programmers available than SystemVerilog UVM programmers.

Randomization is one key to effective tests – the ability to create more tests simply by changing the seed value of the randomization. Our SystemVerilog UVM plus SystemVerilog DPI-C testbench will have randomization and will also reuse the pre-existing C tests. One way to think about how it might be useful is to let the UVM randomized environment generate “random traffic”. Then the C test program runs at the same time – testing deadlocks and delays due to the random traffic.