 uvm_object – All components and transactions derive from uvm_object, which

defines an interface of core class-based operations: create, copy, compare, print,

etc. It also defines interfaces for instance identification (name, type name, unique id,
etc) and random seeding.
 uvm_component – The root base class for all UVM components. Every component
is uniquely addressable via a hierarchical path name, e.g.
“env1.csi2.txlane1.driver”. It is somewhat static as it exists throughout the simulation
unlike uvm_transaction. It also defines the test flow in phases that all components
follow during the course of a simulation. It also defines configuration, reporting,
transaction recording and factory interfaces.
 uvm_transaction – This is the root base class for UVM transactions that extends
uvm_object to include a timing and recording interface.
 uvm_root – This is a special type of uvm_component that serves as the top level
component for all UVM components, providing phasing control for all UVM
components and other global services.

UVM Phases

UVM Phases can be grouped into three main categories, namely

 Build phases
 Run phases
 Cleanup phases.

UVM Testbench Hierarchy

 A typical UVM testbench is built with a top level module which contains the DUT
and the testbench connections.
 The top level module contains an initial block which will contain a call to the UVM
run_test() method.
 This method start the execution of the UVM phases, which controls the order of
which the testbench is built, stimuli is generated and then reports on the results of the
simulation.
 The image below from Accellera’s UVM User Guide describe a typical UVM
Testbench structure.

UVM Testbench and UVM Test

You can think of the UVM Test component as the substitute to the stimulus traditionally
created using RTL and more. The UVM testbench a.k.a. Top instantiates this UVM Test
dynamically during run-time, allowing the UVM Testbench to be compile once and run with
many different tests.

The UVM Test component applied stimulus by invoking UVM Sequences and configures the
Env (Environment) using factory overrides or the config database. Usually there is one base
UVM Test with the UVM Env instantiation but we can then extend this base test and
configure it differently to cover other sequences to run.

UVM Environment

The UVM Environment is a grouping of other verification components that are typically
interrelated. For example, you might have an USB Environment that groups the verification
components targeting the USB portion of the DUT, alongside an Env for Memory Controller,
an Env for I2C controller, etc. A UVM Env typically contains UVM Agents, UVM
Scoreboards or even another UVM Environments.
 UVM Scoreboard & UVM Agent

The UVM Scoreboard is to check the behavior of a certain DUT while the UVM Agent
consists of a UVM Driver to apply stimulus to the interface of the DUT and a UVM
Monitor monitors this interface. The UVM Agent typically also consists of a UVM
Sequencer to manage the stimulus flow.

UVM Sequencer and UVM Sequence (not the same thing)

The UVM Sequencer serves and arbiter for controlling transaction flow of UVM
Sequence Items transactions.

A UVM Sequence is an object that contains a behavior for generating stimulus. It is

important to note that UVM Sequences are:

 Not part of the component hierarchy

 Can be transient
 Can operate hierarchically with one sequence (parents) or by invoking another
sequence (child sequence).