Introduction to UVM

📋 What is UVM?

UVM (Universal Verification Methodology) is a standardised SystemVerilog class library for building structured, reusable, and scalable verification testbenches. It is defined by the Accellera IEEE 1800.2 standard and is the dominant verification methodology in the semiconductor industry — used across ASIC, FPGA, and IP verification at every level from block to chip.

At its core, UVM is a collection of base classes — around 100 — that you extend to create testbench components. The library provides infrastructure that you would otherwise have to build from scratch on every project: component lifecycle management, a phase execution engine, a factory for component construction, a configuration database, a TLM connection framework, a register abstraction layer, and a reporting system.

UVM does not verify your design for you. It gives you a consistent, proven framework inside which your verification code lives. Every engineer who knows UVM can pick up any UVM testbench and understand its structure immediately — the same way any C++ engineer can navigate any C++ codebase.

📋 Why UVM — The Problem it Solves

Before UVM, every verification team built their own testbench infrastructure from scratch. The result was thousands of incompatible, non-reusable frameworks across the industry. An IP block verified at one company could not have its testbench reused at another company using a different framework.

UVM solves three specific problems:

• Reusability. A UVM Verification Component (UVC) built for an APB interface can be reused across every project that uses APB — at block, integration, and chip level. No rewrite needed, just plug in.
• Scalability. UVM testbenches scale from a single-agent block-level environment to a multi-agent chip-level environment using the same structural patterns. Adding an interface means adding an agent — the rest of the infrastructure stays the same.
• Configurability. The factory and config_db mechanisms allow the same testbench to behave differently for different test scenarios without modifying any testbench source. A test override changes component behaviour; the infrastructure is untouched.

📋 Module vs Class Based Testbenches

To understand why UVM structures testbenches the way it does, you need to understand the fundamental difference between a module-based testbench (Verilog style) and a class-based testbench (UVM style).

📋 The UVM Class Library

The UVM library contains around 100 classes organised in a deep inheritance hierarchy. In practice, a complete testbench uses around a dozen base classes. The key structural split is between two branches of the hierarchy: uvm_component and uvm_object.

📋 uvm_component vs uvm_object

The single most important design decision in UVM is which base class to extend. Every class you write derives from one of these two.

// ── uvm_component — persistent infrastructure ─────────────
class my_driver extends uvm_driver#(my_seq_item);
  `uvm_component_utils(my_driver)   // register with factory

  function new(string name, uvm_component parent);
    super.new(name, parent);        // parent is mandatory
  endfunction

  task run_phase(uvm_phase phase);  // components have phases
    // drive DUT signals forever
  endtask
endclass

// ── uvm_object — transient data ───────────────────────────
class my_seq_item extends uvm_sequence_item;
  `uvm_object_utils_begin(my_seq_item)
    `uvm_field_int(addr, UVM_ALL_ON)
    `uvm_field_int(data, UVM_ALL_ON)
  `uvm_object_utils_end

  rand logic [31:0] addr;
  rand logic [31:0] data;

  function new(string name = "my_seq_item");
    super.new(name);               // no parent — it's an object
  endfunction
endclass

📋 Standard Testbench Topology

UVM defines a standard topology for a block-level testbench. Every component has a specific role and a specific place in the hierarchy.

📋 Stimulus and Observation Flow

Two separate data flows run concurrently during the run_phase. Understanding these flows is essential before writing any code.

These two flows run concurrently and are completely independent of each other. The stimulus flow is active — it drives the DUT. The observation flow is passive — it only observes. This separation is why a monitor can be reused in a passive agent: remove the sequencer and driver, keep the monitor.

📋 Your First UVM Component

The minimum viable UVM testbench — a test that prints a message and exits cleanly. This introduces all the mandatory boilerplate you will write for every component.

// ── Import and include — required in every UVM file ──────
import uvm_pkg::*;
`include "uvm_macros.svh"

// ── Minimum UVM test ──────────────────────────────────────
class my_test extends uvm_test;
  `uvm_component_utils(my_test)   // ① register with factory

  function new(string name, uvm_component parent);
    super.new(name, parent);       // ② mandatory constructor
  endfunction

  task run_phase(uvm_phase phase);
    phase.raise_objection(this);   // ③ keep sim alive
    `uvm_info("TEST", "Hello from UVM!", UVM_LOW)
    #100ns;
    phase.drop_objection(this);   // ④ allow sim to end
  endtask
endclass

// ── SV top module ─────────────────────────────────────────
module tb_top;
  import uvm_pkg::*;
  `include "uvm_macros.svh"
  `include "my_test.sv"

  initial run_test("my_test");  // construct and run my_test
endmodule

Three mandatory elements in every UVM component are highlighted with ①②③:

1. Factory registration — `uvm_component_utils registers the class so the factory can create it by name. Without this, run_test("my_test") fails silently.
2. Constructor — must call super.new(name, parent). The parent argument wires this component into the hierarchy so it has a path name and participates in phases.
3. Objection — without raise_objection, the run_phase ends immediately. The simulation exits before your code runs.

What run_test() does step by step

1. Asks the factory to create an instance of the named test class
2. Calls build_phase top-down — test builds env, env builds agents, agents build driver/monitor/sequencer
3. Calls connect_phase bottom-up — TLM ports are connected, virtual interfaces assigned
4. Calls run_phase concurrently in all components that implement it
5. Waits until all objections are dropped, then runs post-run phases and calls $finish

📋 Quick Reference