Skip to content
STIMSMITH

UVM Phases

Concept WIKI v1 · 5/27/2026

UVM phases are predefined execution points in a Universal Verification Methodology testbench. They provide a common structure for component behavior so independently developed verification components can interoperate and execute in a predictable order.

Overview

UVM phases are predefined stages in the execution of a UVM verification environment. They give verification components a shared understanding of what actions are expected at each point in the testbench flow, which helps independently developed components remain interoperable and makes testbench execution more structured and predictable.

The provided UVM phase diagram groups phases into build, run, and cleanup portions of execution. UVM components implement phase-related virtual methods according to the phases in which they participate.

Role in a UVM test

A UVM test is the top-level object in a UVM environment: environment objects are members of the test case object, and UVM requires tests to extend uvm_test. In the cited CV32E/CORE-V environment, the base test class uvmt_cv32_base_test_c directly extends uvm_test, and project test cases are expected to extend that base test to preserve the intended test flow and avoid duplicated boilerplate.

Example phase usage in a CORE-V/CV32E environment

The CORE-V/CV32E example describes three time-consuming tasks commonly extended by a UVM test:

  • Reset phase: often only calls super.resetphase(), which invokes the default reset sequence. A test-specific reset virtual sequence can also be invoked here.
  • Configure phase: in many UVM environments this is busy, but in the CV32E example the core CSRs may not require configuration before execution if the program running on the core performs what is needed. Tests that require pre-compiled programs to be loaded into instruction memory should do that in this phase.
  • Run phase: typically contains most procedural test code.

A typical run-phase flow in the CORE-V example is:

  1. Raise an objection.
  2. Assert the core fetch_en input.
  3. Wait for the core or environments to signal completion.
  4. Drop the objection.

Why phases matter

The phase mechanism gives testbench authors a common lifecycle for setup, execution, and cleanup. In processor-oriented UVM environments such as the CORE-V example, the run flow may also need to account for software executing on the core: the test program runs in an execution environment defined by the ISA, memory map, and virtual peripherals, while the UVM environment responds to that program as part of the run flow.

CITATIONS

7 sources
7 citations
[1] UVM phases are predefined stages that give components shared expectations, support interoperability, and create a structured, predictable testbench execution flow. [PDF] UVM based design veri cation of a RISC-V CPU core - POLITesi
[2] The UVM phase diagram in the evidence groups execution into build, run, and cleanup phases. [PDF] UVM based design veri cation of a RISC-V CPU core - POLITesi
[3] A UVM test is the top-level object in a UVM environment, and UVM requires tests to extend uvm_test. [PDF] UVM based design veri cation of a RISC-V CPU core - POLITesi
[4] In the CV32E environment, the base test uvmt_cv32_base_test_c directly extends uvm_test, and tests should extend it to maintain the intended test flow and reduce duplicate work. [PDF] UVM based design veri cation of a RISC-V CPU core - POLITesi
[5] A typical CORE-V UVM test extends reset, configure, and run phase tasks, with reset handling reset sequencing, configure handling setup such as loading instruction memory, and run containing most procedural test code. [PDF] UVM based design veri cation of a RISC-V CPU core - POLITesi
[6] The example CORE-V run flow raises an objection, asserts fetch_en, waits for completion, and then drops the objection. [PDF] UVM based design veri cation of a RISC-V CPU core - POLITesi
[7] In the CORE-V example, programs running on the core affect the usual UVM run flow because the software execution environment is defined by the ISA, memory map, and virtual peripherals rather than by the UVM environment itself. [PDF] UVM based design veri cation of a RISC-V CPU core - POLITesi