uvm_component

UVM Base Classes · Module 4 · Page 4.3

The Engineering Problem

The previous chapter covered uvm_object — the base class for data. This one covers its counterpart, uvm_component — the base class for structure. Where a uvm_object is transient data that flows through the testbench, a uvm_component is a permanent node of the testbench: the test, the env, the agent, the driver, the monitor, the scoreboard — every structural piece you've built extends uvm_component.

The engineering question is precise: what does uvm_component add over uvm_object? Because a component is an object (it inherits the whole data toolkit), but it adds four things that make it structural rather than data: a place in the hierarchy (a parent, children, a full name), participation in phasing (build, connect, run…), integration with the configuration database (scoped to its path), and reporting (messages tagged with its name). And it adds a fifth, implicit property: it persists for the entire simulation, while objects come and go. Getting the distinction right is foundational — it determines which base class you extend, which constructor you write, and whether a piece participates in phasing at all. Extend the wrong one, or write an object's constructor on a component, and it won't build.

What is uvm_component, what does it add over uvm_object (hierarchy, phasing, configuration, reporting, lifetime), and why does everything structural extend it — including the constructor that must differ from an object's?

Motivation — why structure needs a different base class

The four additions of uvm_component are exactly what a structural node requires and a data object must not have:

• Hierarchy makes it addressable and composable. A component has a parent and children and a full path (Module 3.3), so it can be configured, found, and composed into a tree. Data has no business in the tree; structure has no business without one. The hierarchy is the difference.
• Phasing makes it execute. Components are phased — the framework calls build_phase, connect_phase, run_phase on every component in the tree. This is what makes a component do things in an orchestrated order; objects have no phases and never execute on their own.
• Configuration makes it adaptable. A component participates in the config database scoped to its path, so the test can configure it from above (Module 3.5). This is the mechanism of reuse, and it is keyed on the component's place in the hierarchy.
• Reporting makes it accountable. A component is a uvm_report_object, so its messages ( `uvm_info, `uvm_error, `uvm_fatal) are tagged with its name and routed through UVM's reporting system — which is how you trace which of dozens of components produced a message.

The motivation, in one line: data and structure are fundamentally different kinds of thing, so they have different base classes — and uvm_component is the one that gives a piece a place in the tree, a phased lifecycle, configurability, and a reporting identity, which is precisely what a structural node needs and a data object must not have.

Mental Model

Hold uvm_component as a building with an address, a schedule, and a nameplate:

A uvm_component is a uvm_object that has moved into the building permanently and gotten an address, a daily schedule, a mailbox, and a nameplate. It still has the object's data toolkit (it inherits copy/compare/print, though it rarely uses them), but now it also has: an address (its place in the hierarchy — a parent, a full path), a schedule (phases — it shows up for build, then connect, then run, in lockstep with every other component), a mailbox (the config database — the test sends it settings scoped to its address), and a nameplate (reporting — every message it sends is signed with its name). And unlike the transient objects that visit (transactions passing through), the component lives there for the whole simulation. A data object is a visitor; a component is a resident.

So the model for choosing a base class is: is this a permanent resident of the testbench (a node that builds, connects, runs, and persists) or a transient visitor (data that flows through)? Residents extend uvm_component; visitors extend uvm_object. And residents get the two-argument constructor — a name and the address (parent) they move into.

Visual Explanation — what uvm_component adds over uvm_object

uvm_component inherits everything from uvm_object and layers structural capabilities on top. The picture is one of addition: the data toolkit at the base, the structural machinery above it.

Read the stack as inheritance plus addition. The base (greyed) is the uvm_object data toolkit — a component has it but a driver almost never copies or compares itself. Above it, the four structural layers are what make it a component: hierarchy (it's a node with an address), phasing (it executes in orchestrated phases), configuration (the test adapts it from above), and reporting (it has a logging identity). The implicit fifth property — persistence — runs through all of them: because it's in the tree and phased, it exists from build_phase to the end of simulation. This is the precise answer to "what does uvm_component add": four capabilities and a lifetime, layered over the inherited object.

RTL / Simulation Perspective — a component uses all four additions

A single component touches all four structural capabilities, and the code shows each — including the constructor that distinguishes a component from an object.

class my_driver extends uvm_component;       // a component (uvm_driver extends uvm_component too)
  `uvm_component_utils(my_driver)            // factory registration for a COMPONENT
  virtual my_if vif;
 
  // CONSTRUCTOR: name AND parent — this is the component signature (objects take name only)
  function new(string name, uvm_component parent);
    super.new(name, parent);                 // hand the parent up → placed in the tree
  endfunction
 
  // PHASING: the framework calls this (objects have no phases)
  function void build_phase(uvm_phase phase);
    super.build_phase(phase);
    // CONFIGURATION: the config database, scoped to THIS component's path
    if (!uvm_config_db#(virtual my_if)::get(this, "", "vif", vif))
      `uvm_fatal("NOVIF", "virtual interface not set")   // REPORTING: tagged with this component
    // HIERARCHY: ask the component its own address
    `uvm_info("DRV", $sformatf("built at %s", get_full_name()), UVM_LOW)
  endfunction
 
  task run_phase(uvm_phase phase);
    // ... persists and runs for the whole simulation ...
  endtask
endclass

Every line maps to one of the additions. The constructor new(string name, uvm_component parent) is the component signature — note the parent argument, absent from an object's constructor, which is what places the component in the tree via super.new(name, parent). Phasing: build_phase and run_phase are framework-called methods an object doesn't have. Configuration: uvm_config_db::get(this, ...) retrieves a setting scoped to this component's path. Reporting: `uvm_fatal and `uvm_info emit messages tagged with this component (it's a uvm_report_object). Hierarchy: get_full_name() returns its address in the tree. The factory registration is `uvm_component_utils (note: component, not object). One class, all four structural capabilities — which is what being a uvm_component means.

Verification Perspective — component vs object, side by side

The clearest way to understand uvm_component is directly against uvm_object: same library, opposite roles. The contrast determines which base class you extend for anything you build.

This side-by-side is the decision you make every time you write a class. If the thing is data — it carries values, flows through the environment, gets randomised/copied/compared, and is discarded — it extends uvm_object (or a data subtype like uvm_sequence_item), takes a one-argument constructor new(string name = "..."), and has no phases. If the thing is structure — it occupies a place in the testbench, builds children, connects, runs, is configured from above, and persists — it extends uvm_component (or a subtype like uvm_driver), takes the two-argument constructor new(string name, uvm_component parent), and is phased. The two columns never blur: a transaction is never phased, a driver is never randomised. Picking the base class is picking the column, and the column dictates the constructor, the lifecycle, and the capabilities.

Runtime / Execution Flow — a component's phased lifetime

A component's defining behaviour over time is its phased lifetime: it is constructed in build_phase, wired in connect_phase, runs in run_phase, reports in report_phase, and exists continuously throughout — a sharp contrast with an object's create-use-discard.

This lifetime is the runtime meaning of "persistent structure." Unlike an object, which is created on demand and dropped when no longer referenced, a component is created once at build_phase and remains — phased through connect, run, and report, present the entire time. That persistence is why a component can hold long-lived state (a driver's interface handle, a scoreboard's expected queue), participate in connections (it must exist for the whole run to send and receive), and accumulate results to report at the end. The phased lifecycle also enforces the construct-then-connect-then-run ordering (Module 2.6): because the framework phases the whole tree of persistent components in lockstep, every component is built before any is connected, and connected before any runs. The component's phased, persistent lifetime is the structural backbone the transient objects flow through.

Waveform Perspective — the resident and the visitors

The component-versus-object distinction is visible in time: the component is alive the whole simulation while transaction objects flow through it and are discarded. The resident persists; the visitors come and go.

The contrast between comp_alive (high the whole trace) and txn (brief pulses) is the entire chapter on one timeline. The component is the resident: built once, it persists from build_phase to the end, holding state and participating in connections throughout — which is why uvm_component needs hierarchy, phasing, configuration, and reporting, all of which are about a long-lived participant in the testbench. The transactions are the visitors: each uvm_object is created, used to drive the pins, and dropped, needing only the data toolkit. Seeing them together makes the base-class choice obvious: anything that must persist and participate (hold state, connect, be phased) is a uvm_component; anything that merely carries data through is a uvm_object.

DebugLab — the component that wouldn't build (wrong constructor)

uvm_object   constructor:  function new(string name = "x");          super.new(name);
uvm_component constructor:  function new(string name, uvm_component parent);  super.new(name, parent);
 
what was written (on a component):  new(string name = "my_monitor"); super.new(name);   // OBJECT form
the factory does:                   type_id::create("mon", this);    // needs new(name, PARENT)
result:                             no matching 2-arg constructor → create fails / won't compile
fix:                                new(string name, uvm_component parent); super.new(name, parent);

Common Mistakes

• Object constructor on a component. A uvm_component needs new(string name, uvm_component parent) and super.new(name, parent); the object form new(string name="x") makes the factory unable to create it. Match the constructor to the base class.
• Mismatched _utils macro. `uvm_component_utils for components, `uvm_object_utils for objects. Using the object macro on a component (or vice versa) registers the wrong kind of class and breaks creation.
• Extending the wrong base for the role. Structure (test, env, agent, driver, monitor, scoreboard) extends uvm_component (or a subtype); data (transactions, configs, sequences) extends uvm_object (or a subtype). Extending uvm_object for structure loses phasing and hierarchy.
• Forgetting super.build_phase/super.new. Omitting the super call skips base-class setup (placement, phase bookkeeping). Call super.new(name, parent) and super.build_phase(phase).
• Treating a component like data. Components are not meant to be randomised, copied, or compared as values — that's the object's role. Don't clone a component or put it in an analysis port; pass transactions (objects), not components.
• Building components outside build_phase. A component's children are created in build_phase (with the parent), so they're phased; constructing them elsewhere or without a parent makes orphans (Module 3.3).

Senior Design Review Notes

Interview Insights

Exercises

1. Object or component? For each, choose the base class and write its constructor signature: (a) a bus transaction; (b) a scoreboard; (c) an agent configuration; (d) a monitor; (e) a sequence.
2. List the additions. Name the four capabilities uvm_component adds over uvm_object, and for each, one line of code in a driver that uses it.
3. Fix the constructor. A monitor extends uvm_monitor but has new(string name="mon"); super.new(name); and fails to create. State the root cause and write the corrected constructor.
4. State placement. A teammate stores a scoreboard's running list of expected transactions as a field of the transaction class. Explain why this is wrong in terms of persistence, and where the list belongs.

Summary

• uvm_component is the base class for all persistent structure — test, env, agent, driver, monitor, sequencer, scoreboard. It inherits the uvm_object data toolkit and adds the machinery of a structural node.
• Over uvm_object it adds four capabilities — hierarchy (parent/children/full name), phasing (build/connect/run/…), configuration (the config database scoped to its path), and reporting (messages tagged with its name) — plus a fifth, implicit property: it persists for the whole simulation.
• Its constructor differs: new(string name, uvm_component parent) (and super.new(name, parent)), because the parent is what places it in the tree — versus an object's new(string name = "..."). The factory creates components via this two-argument constructor, so getting it wrong means it won't build.
• The component-vs-object choice is the structure-vs-data choice: residents that build, connect, run, hold state, and persist are components; transient data that flows through is objects. The two halves never blur — components aren't randomised, objects aren't phased.
• The durable rule of thumb: extend uvm_component for anything that must live in the tree, be phased, be configured, and persist — give it the (name, parent) constructor and `uvm_component_utils — and keep it in its lane: structure persists and participates, data flows through.

Next — uvm_transaction: with both halves of the library in view — uvm_object (data) and uvm_component (structure) — the next chapter zooms into the data side, to uvm_transaction: the uvm_object subtype that adds transaction identity and timing, and the base from which sequence items are built.