Easy Testbench Evolution: Styling Sequences and Drivers

The SystemVerilog¹ UVM² naturally supports object-oriented programming. One of the hardest parts of object-oriented programming for new users is polymorphism and the factory pattern. Yet, polymorphism and the factory pattern combine to improve productivity³ while with just a minimal amount of work. This productivity leverage will be explored in this paper for sequences, drivers and transactions, with a focus on changing behavior while changing only small amounts of code.

The factory in the UVM supports overriding a type or overriding an instance of a type. Overriding a type causes that type to be replaced with the override. Overriding an instance of a type only replaces that instance of the type.

By using the factory with a type override for a driver, when the driver is constructed a different type – the “extended_driver” will be constructed. This means that with no change to the source code of the “regular” UVM testbench, it can be changed or evolved to do new things. The replacement types must derive from the specific base classes. But the power of this technique is shown within this paper. With just a few changes, the simple testbench is processing out-of-order transactions.

There are multiple ways to build productivity with the UVM. Using randomization with different seeds allows many different combinations to be run with a single testbench. Using parameterization, a testbench can be resized easily. This factory-based approach can change the structure and behavior of the testbench significantly. It’s a powerful tool to add to randomization and parameterization.

Basic UVM Testbench

The basic UVM Testbench will be outlined and reviewed, including transactions, sequences, drivers, sequencers and tests. A transaction is constructed in a sequence and sent to the sequencer and on to the driver. The driver sends it for processing to the device-under-test via the virtual interface. That’s the beginning of most UVM testbenches, and it is the beginning in this paper as well. The testbench is easy to write, concise and readable. It generates transactions and can be used effectively for verification as-is.

The diagram below will help explain these structures and how they interact. Each piece of the UVM Agent will be described, along with virtual interfaces, tests and UVM Environments.

This summary will provide a background for both a beginner and experienced UVM verification engineer.