Day 97: SystemVerilog for verification: classes and OOP basics
SystemVerilog for verification: OOP
Testbenches need abstraction that synthesizable RTL lacks. SystemVerilog adds a full object-oriented layer: classes (with data + methods), inheritance (extends), polymorphism (virtual methods), and dynamic objects on the heap. A transaction becomes a class; a driver, monitor, and scoreboard become classes. This OOP layer is non-synthesizable — it exists purely to build reusable, scalable verification.
class uart_txn;
rand bit [7:0] data; // randomizable field
rand bit parity_err;
constraint c_par { parity_err dist { 0 := 95, 1 := 5 }; } // mostly good
function void print();
$display("uart_txn data=%h perr=%b", data, parity_err);
endfunction
endclass
class base_driver;
virtual function void run(); endfunction // overridden by children
endclass
class uart_driver extends base_driver;
virtual function void run(); /* drive the DUT */ endfunction
endclassWhy OOP for testbenches
A transaction as a *class* can be randomized, copied, printed, and passed between components generically. Inheritance lets a base testbench be specialized per DUT without rewriting it. This reuse is the entire reason UVM (a class library) exists — and why DV engineers write more class code than RTL.
Key terms
- Class
- A SystemVerilog object type bundling data and methods; the unit of testbench abstraction.
- Inheritance (extends)
- Deriving a specialized class from a base, reusing and overriding its behavior.
- Virtual method / polymorphism
- A method a subclass can override, called through a base handle at run time.
- Transaction
- A class representing one unit of stimulus/observation (e.g. a bus transfer).
Before moving on, you should be able to
Why does SystemVerilog add classes and inheritance, which have no synthesizable meaning?
