UVM architecture, phasing, and end of test interview questions

Question 1

What is the difference between uvm_component and uvm_object?

Accepted Answer

A uvm_component is a persistent, hierarchical testbench element that participates in phasing. A uvm_object is a non-hierarchical data or behavior object used for items, sequences, and configuration. Components have a parent, a hierarchical path, phase callbacks, and report context. Drivers, monitors, agents, environments, scoreboards, and tests are components. Objects have names but no component parent or phase callbacks. Sequence items, sequences, register transactions, and configuration objects are typical examples. Call components structural and objects transactional, but do not call components compile-time static. Both are SystemVerilog class instances; their ownership and lifecycle contracts differ. Watch for: Saying every object is short-lived is too strong. A configuration object may live for the entire test, and a component can create many objects.

Question 2

What belongs in a UVM agent, and what changes in passive mode?

Accepted Answer

An agent packages protocol-specific configuration and observation. In active mode it also builds a sequencer and driver; in passive mode it must not drive the interface. The monitor should exist in both modes so checking and coverage see the same protocol abstraction. The agent usually reads an is_active setting during build_phase, conditionally creates the driver and sequencer, then connects them only when active. A passive agent is useful on DUT outputs, shared buses, or interfaces driven by another master. Passive means no stimulus, not no checking. Watch for: Do not connect a null driver or sequencer in passive mode. Build and connect must use the same is_active decision.

Question 3

Why is UVM a methodology rather than only a class library?

Accepted Answer

UVM supplies classes, but the methodology is the shared architecture, lifecycle, communication style, and reuse contract used to assemble those classes. Phasing gives teams a common construction, run, and cleanup lifecycle. Agents, monitors, analysis paths, factories, and configuration objects create stable seams between reusable verification IP and project-specific tests. Sequences separate scenario intent from signal-level driving, while scoreboards and coverage separate observation from stimulus. Watch for: The env-agent-driver-monitor structure is a common pattern, not a rule that excuses poor ownership or unnecessary hierarchy.

Question 4

How does UVM phasing work, and why is it necessary?

Accepted Answer

Phasing gives every component a deterministic lifecycle for construction, connection, time-consuming activity, checking, and teardown. build_phase executes top-down so a parent can create its children. Connection and most later function phases execute bottom-up so children exist and can contribute before their parent summarizes. Time may advance only in task phases. The common run_phase executes concurrently with the ordered run-time schedule from pre_reset through post_shutdown. extract, check, and report consolidate results after run-time activity. final_phase executes top-down for final teardown. Watch for: Do not describe run_phase as the parent that contains the twelve subphases. The run-time schedule runs concurrently with the global run phase.

Question 5

When should you use run_phase versus the twelve run-time subphases?

Accepted Answer

Use run_phase for always-on transactors and observers. Use reset, configure, main, and shutdown subphases only when the environment needs those explicit synchronization points. Drivers, monitors, and scoreboards often remain alive for the full common run phase. Scenario-level stimulus can use the ordered subphases when reset, configuration, traffic, and drain must be synchronized across components. Choose one project policy. Mixing objections across run_phase and main_phase without a clear ownership model is a common source of early exits and hangs. Watch for: The twelve subphases are sequential within their run-time schedule, but component tasks within one subphase execute concurrently.

Question 6

How do objections control when a UVM test ends?

Accepted Answer

A task phase may end only after its objection count returns to zero. The code that owns a finite scenario should raise before starting it and drop after all required work is complete. Objections keep a phase alive; they do not stop forever loops. When a phase ends, UVM terminates the phase threads that are still running. Centralize objection ownership in the test or root sequence when possible. Low-level drivers and monitors should not usually decide test duration. Use +UVM_OBJECTION_TRACE when the count never reaches zero, and use a drain time only for a defined final latency, not as a substitute for completion tracking. Watch for: A missing drop hangs the phase. A missing raise can end the phase before the first transaction. Both failures come from unclear ownership.

Dimension	`uvm_component`	`uvm_object`
Primary role	Persistent testbench structure	Data, policy, or scenario
Hierarchy	Has parent and full path	No component hierarchy
Phasing	Receives phase callbacks	Does not participate directly
Examples	agent, driver, monitor, env	item, sequence, config

Choice	Best use	Main risk
`run_phase`	Always-on drivers, monitors, scoreboards	Manual scenario synchronization
run-time subphases	Reset/config/main/shutdown coordination	Mixed objection domains

Questions for Architecture + lifecycle

UVM Testbench architecture Know what lives where.

UVM component hierarchy and object flow

Reason it through

Reason it through

Reason it through

UVM Phasing and end of test Know when time may pass.

The UVM lifecycle has order and concurrency

Reason it through

Reason it through

Reason it through

Architecture + lifecycleUVM architecture, phasing, and end of testInterview guide

UVM Testbench architecture Know what lives where.

UVM component hierarchy and object flow

What is the difference between uvm_component and uvm_object?+

Reason it through

What belongs in a UVM agent, and what changes in passive mode?+

Reason it through

Why is UVM a methodology rather than only a class library?+

Reason it through

UVM Phasing and end of test Know when time may pass.

The UVM lifecycle has order and concurrency

How does UVM phasing work, and why is it necessary?+

Reason it through

When should you use run_phase versus the twelve run-time subphases?+

Reason it through

How do objections control when a UVM test ends?+

Reason it through