The short answer: UVM (Universal Verification Methodology) is a standard library of SystemVerilog base classes and rules for building reusable, constrained-random, coverage-driven testbenches. It gives every team the same building blocks (sequence items, sequences, drivers, monitors, agents, environments and tests), plus a factory for swapping classes, phases for ordering the simulation, TLM ports for communication, a configuration database and a register model. It’s standardised as IEEE 1800.2 and maintained by Accellera.
When I first opened a UVM testbench, it looked like a wall of macros and base classes. The trick is to see that UVM doesn’t add new verification ideas; it standardises the layered testbench you’d build anyway, so that verification IP from different teams and vendors fits together.
This is the first post in my UVM series. If classes and randomisation are new to you, start with my SystemVerilog series, especially testbench architecture.
- Where UVM fits
- Why UVM exists
- The core classes
- A minimal UVM test
- Is UVM worth learning?
- This series in order
Table of Contents
Part 1: Where UVM fits
Part 2: Why UVM exists
- Reuse: an agent written for one block works unchanged at subsystem and chip level, and VIP from vendors plugs straight in.
- A common language: any verification engineer can open any UVM testbench and find the driver, the sequences and the scoreboard.
- Control from tests: the factory and configuration database let a test change behaviour without editing the environment.
- Tool support: simulators and debuggers understand UVM phases, sequences and messages.
UVM grew out of earlier methodologies (OVM and VMM), was released by Accellera in 2011, and became IEEE 1800.2 in 2017, with later revisions.
Part 3: The core classes
| Class | Role |
|---|---|
| uvm_sequence_item | A transaction: the data for one operation |
| uvm_sequence | Generates a stream of items |
| uvm_sequencer | Arbitrates and passes items to the driver |
| uvm_driver | Turns items into pin activity |
| uvm_monitor | Turns pin activity back into items |
| uvm_agent | Packages sequencer, driver and monitor for one interface |
| uvm_scoreboard | Checks results |
| uvm_env | Builds and connects agents and checkers |
| uvm_test | Configures the env and starts sequences |
Components (the static testbench structure) derive from uvm_component; data and sequences derive from uvm_object.
Part 4: A minimal UVM test
import uvm_pkg::*;
`include "uvm_macros.svh"
class base_test extends uvm_test;
`uvm_component_utils(base_test)
my_env env;
function new(string name, uvm_component parent);
super.new(name, parent);
endfunction
function void build_phase(uvm_phase phase);
env = my_env::type_id::create("env", this);
endfunction
task run_phase(uvm_phase phase);
my_seq seq = my_seq::type_id::create("seq");
phase.raise_objection(this);
seq.start(env.agt.sqr);
phase.drop_objection(this);
endtask
endclass
module tb_top;
initial run_test(); // test chosen with +UVM_TESTNAME=base_test
endmoduleEvery piece of this (the factory call, the phases, the objection, starting a sequence on a sequencer) gets its own post in this series.
Part 5: Is UVM worth learning?
For a design verification career, yes: almost every DV job description asks for it. But learn it on top of solid SystemVerilog, and build a small testbench by hand first. Engineers who understand what UVM is doing underneath debug much faster than those who only know the macros.
Part 6: This series in order
- What is UVM?
- UVM testbench architecture
- Sequence items
- Sequences and sequencers
- Drivers, monitors and agents
- Phases and objections
- The UVM factory
- Configuration and uvm_config_db
- TLM and analysis ports
- Scoreboards
- Coverage and assertions in UVM
- The register model (RAL)
- Callbacks
- Reporting and messaging
Practise this on VLSI Forge
I built VLSI Forge so you can write RTL in your browser, run it on a real simulator and check every signal in the waveform. Free, nothing to install.
Next: UVM testbench architecture.
FAQ
What does UVM stand for?
Universal Verification Methodology, a standard SystemVerilog class library and methodology for building reusable testbenches.
Is UVM a language?
No. It’s a library written in SystemVerilog, standardised as IEEE 1800.2.
Do I need UVM for small designs?
Not always. A simple class-based testbench is fine for small blocks, but UVM pays off when testbenches are shared or reused.
What should I learn before UVM?
SystemVerilog classes, inheritance, virtual methods, randomisation, interfaces and virtual interfaces, and basic functional coverage.
