UVM Phases

Never create child components outside of build_phase. Creating them in connect_phase or later means they won't exist when other components try to connect to them.

The UVM topology printed by uvm_root reflects this hierarchy after build_phase completes:

// Typical build output from $cast or uvm_top.print_topology()
// uvm_test_top               [my_test]
//   e0                       [my_env]
//     a0                     [my_agent]
//       d0                   [my_driver]
//       m0                   [my_monitor]
//       s0                   [uvm_sequencer]
//     sb0                    [my_scoreboard]

Connect Phase: Wiring the Testbench

Once every component exists, connect_phase wires them together. This is where TLM ports are connected to exports, and where a driver's seq_item_port is connected to a sequencer's seq_item_export.

class my_agent extends uvm_agent;
  `uvm_component_utils(my_agent)

  my_driver     drv;
  my_monitor    mon;
  uvm_sequencer #(my_transaction) seqr;

  function void connect_phase(uvm_phase phase);
    // Connect driver to sequencer - both must exist before this runs
    drv.seq_item_port.connect(seqr.seq_item_export);
  endfunction

  // Rest of the code (build_phase, etc.)
endclass

Why Verilog Testbenches Don't Need Phases

A Verilog testbench is built entirely from modules, which are static constructs. All modules are elaborated before simulation time zero - every driver, monitor, and checker exists before a single clock edge occurs. There is no dynamic object creation, so there's no risk of one component referencing another before it exists.

// Verilog: all components exist at time 0, no phases needed
module tb_top;
  dut      d0   (...);
  driver   drvr (...);
  monitor  mon0 (...);
endmodule

Why UVM Testbenches Require Phases

UVM testbenches are built from class objects, not modules. A class object only exists after it has been constructed with new() or type_id::create(). This means it's entirely possible to reference a component handle that is still null if the construction hasn't happened yet.

class my_env extends uvm_env;
  my_driver  drv;   // Just a handle - drv is null until build_phase constructs it
  my_monitor mon;

  function void build_phase(uvm_phase phase);
    super.build_phase(phase);
    drv = my_driver::type_id::create("drv", this);   // Now drv is valid
    mon = my_monitor::type_id::create("mon", this);
  endfunction
endclass

Without a phase synchronization mechanism, a monitor could attempt to connect an analysis port to a scoreboard that hasn't been constructed yet, causing a null pointer access. Phases eliminate this entire class of bugs by enforcing a strict ordering: build everything first, then connect, then run.

Reusable verification IP (VIP) from different vendors can be plugged together reliably because they all follow the same phase contract. This is one of the key reasons UVM phases exist.

Run-Time Sub-Phases

The run_phase runs in parallel with a set of finer-grained run-time sub-phases. These sub-phases let you structure the stimulus sequence inside a component without using manual event synchronization. They run in the following order:

Most testbenches only use run_phase for simplicity. Use the sub-phases when you need fine-grained control over reset sequencing, DUT configuration ordering, or when integrating VIP components from different vendors that expect specific sub-phases.

What to Do in Each Phase

The table below summarizes the entry conditions, typical tasks, and exit criteria for each phase.

Overriding a Phase: Example

To perform work in a phase, simply override the corresponding method in your component. Here's a driver using both build_phase and run_phase:

class my_driver extends uvm_driver #(my_transaction);
  `uvm_component_utils(my_driver)

  virtual my_interface vif;

  function void build_phase(uvm_phase phase);
    super.build_phase(phase);

    // Retrieve virtual interface from config database
    if (!uvm_config_db #(virtual my_interface)::get(this, "", "vif", vif))
      `uvm_fatal("NO_VIF", "Virtual interface not found in config_db")
  endfunction

  virtual task run_phase(uvm_phase phase);
    forever begin
      seq_item_port.get_next_item(req);

      // Drive transaction onto the interface
      @(posedge vif.clk);
      vif.addr <= req.addr;
      vif.data <= req.data;

      seq_item_port.item_done();
    end
  endtask

  // Rest of the code (connect_phase, constructor, etc.)
endclass

Common Mistakes