UVM concepts and 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.

Question 7

What problem does the UVM factory solve?

Accepted Answer

The factory separates the type requested by reusable code from the type actually created, so a test can substitute behavior without editing the environment. Factory registration supplies a type proxy. type_id::create() asks the factory to resolve that proxy using type and instance overrides. A type override affects every matching creation unless a more specific instance override wins. An instance override affects only a matching hierarchical context. The override must be installed before the target create() call. Factory debug output is the fastest way to prove what the resolver selected. Watch for: The factory does not change an object that already exists. It changes the result of a later factory creation request.

Question 8

How would you replace a default driver with an error-injecting driver?

Accepted Answer

Register both classes, install an override in the test before the environment creates the driver, and keep the environment's base_driver::type_id::create() call unchanged. Use a type override when every base driver should change. Use an instance override when only one agent instance should inject errors. The override class must be assignment-compatible with the requested base type. Print the factory or inspect the topology when the replacement does not appear; the usual causes are direct new(), a late override, or a mismatched instance path. Watch for: If a base test creates the environment in super.build_phase(), a derived test must install the override before calling that implementation.

Question 9

How is uvm_config_db different from a direct hierarchical reference?

Accepted Answer

uvm_config_db is a typed, scope-aware interface over the UVM resource database. It lets a producer configure a descendant without compiling against that descendant's exact handle path. A lookup is defined by the type parameter, instance scope, and field name. The consumer should fail clearly when required configuration is missing. Use it for virtual interfaces, agent configuration objects, and policy settings. Bundle related values into a typed config object instead of scattering many string keys. Direct env.agent.driver.value assignments create hard dependencies on a particular hierarchy and make verification IP harder to relocate. Watch for: config_db is flexible, not invisible magic. Set values before get(), keep paths narrow, and use +UVM_CONFIG_DB_TRACE when resolution is surprising.

Question 10

What do uvm_component_utils and uvm_object_utils actually do?

Accepted Answer

The utils macros declare the conventional factory registry and type-introspection plumbing for a user class. The begin/end variants can also add field automation. They provide the type_id proxy and methods such as get_type() and get_type_name() needed by the common factory workflow. They are conventional, not a SystemVerilog language requirement. Equivalent registry code can be written manually. Field macros can automate copy, compare, print, pack, and record operations, but explicit do_copy, do_compare, and related methods are often clearer for important classes. Watch for: Registration alone does not make overrides work if the environment still constructs the class with new(). The creation call must also go through the factory.

Question 11

How do a sequence item, sequence, and sequencer differ?

Accepted Answer

The item is one transaction, the sequence generates or coordinates transactions, and the sequencer arbitrates access from one or more sequences to a driver. A sequence item models the fields and constraints for one protocol-level operation. A sequence is an object whose body() creates items or starts child sequences to express a scenario. A sequencer is a component. It arbitrates requests and implements the transport contract used by the driver. Watch for: A sequencer does not drive DUT pins, and a sequence is not part of the component hierarchy.

Question 12

What is the exact sequence-driver handshake?

Accepted Answer

start_item() waits for a sequencer grant. finish_item() sends the prepared request and waits for driver completion. The driver receives it with get_next_item() and releases the sequence with item_done(). After start_item() returns, randomize or fill the item without consuming simulation time, then call finish_item(). get_next_item() blocks until a request has been sent. The driver converts the item to signal activity and calls item_done(), optionally supplying a response. finish_item() returns after completion. The sequence can then issue another item or retrieve a separate response when the protocol uses one. Watch for: start_item() does not wait for the driver to call get_next_item(). It waits for arbitration grant. Also, do not insert delays or delta cycles between start_item() and finish_item().

Question 13

What is a virtual sequence, and when is it useful?

Accepted Answer

A virtual sequence coordinates child sequences across multiple interface sequencers so a system-level scenario can express ordering and concurrency in one place. A configure-then-stream scenario can start a register-bus sequence, wait for completion, then start data-path sequences on other sequencers. Many environments use a virtual sequencer that stores typed handles to the leaf sequencers. A coordinator sequence may also receive those handles explicitly. The virtual sequence creates orchestration, not pin-level behavior. Each child sequence still runs on the sequencer for its protocol agent. Watch for: A virtual sequencer is a convenience, not a requirement. Avoid turning it into a global bag of unrelated component handles.

Question 14

What are m_sequencer and p_sequencer?

Accepted Answer

m_sequencer is the base-class handle set when a sequence starts. The uvm_declare_p_sequencer macro declares a typed p_sequencer handle and casts m_sequencer into it. m_sequencer preserves generic sequence behavior because its type is uvm_sequencer_base. p_sequencer gives convenient access to subtype-specific fields, especially leaf-sequencer handles in a virtual sequencer. That convenience couples the sequence to one sequencer subtype. Prefer an explicit config object or passed handles when the sequence should be portable. Watch for: p_sequencer is not itself a macro. It is the variable declared by uvm_declare_p_sequencer, and the cast fails if the sequence starts on an incompatible sequencer.

Question 15

How does an analysis port differ from put or get TLM interfaces?

Accepted Answer

An analysis port broadcasts a transaction through a zero-time write() function to every connected subscriber. Put and get interfaces model directed transfer and may be blocking or nonblocking. A monitor commonly broadcasts observations to coverage, a predictor, and one or more scoreboards. Subscribers must not consume time inside write() or modify the shared transaction. Clone it or use a uvm_tlm_analysis_fifo when deferred processing is required. The sequencer-driver path uses the specialized seq_item_port and seq_item_export pull interface, not an ordinary uvm_tlm_put_port or uvm_tlm_get_port. Watch for: Calling analysis connections strictly one-to-many and put/get strictly one-to-one oversimplifies legal TLM topology. Their interface semantics are the important distinction.

Question 16

Trace one transaction from a sequence to a scoreboard.

Accepted Answer

The sequence creates intent, the driver realizes it on pins, the DUT transforms it, and the monitor reconstructs a new observed transaction for the checking path. A leaf sequence sends a request through its sequencer to the driver. The driver applies the protocol to a virtual interface. The monitor samples signal activity independently and publishes a fresh actual transaction. It should not reuse the request handle. A predictor or reference model creates expected behavior from the appropriate inputs. The scoreboard aligns expected and actual streams, then compares them. Watch for: Comparing the original request directly with a DUT output is valid only when the DUT contract is truly identity and timing has been accounted for.

Question 17

What is the difference between UVM_ERROR and UVM_FATAL?

Accepted Answer

UVM_ERROR reports a recoverable test failure and normally lets simulation continue. UVM_FATAL reports an unusable testbench state and normally exits immediately. Use an error for a data mismatch or protocol violation when more evidence can still be collected. Use a fatal for missing required configuration, an incompatible topology, or another condition that makes later results meaningless. Severity, action, and quit-count policy can be configured or changed by a report catcher, but overrides should preserve a clear regression contract. Watch for: A fatal is not merely a larger error count. Its default action includes simulation exit.

Question 18

A UVM test hangs. What do you check first?

Accepted Answer

Start with phase control, then trace the sequencer-driver contract, topology, blocked waits, and finally clock or reset progress. Run with +UVM_OBJECTION_TRACE and +UVM_PHASE_TRACE. Identify the active phase, the source of every remaining objection, and whether another phase domain is still running. Check start_item/finish_item against get_next_item/item_done, confirm the sequence started on the intended sequencer, and verify the port-export connection and parameter types. Inspect waits, semaphores, events, response queues, clocks, and reset release. Add bounded timeouts around scenario-level waits so deadlock becomes a diagnostic failure. Watch for: A driver forever loop is normal and does not keep a phase alive by itself. An objection, blocked phase callback, or unsynchronized run-time domain does.

Question 19

What does the UVM Register Abstraction Layer provide?

Accepted Answer

RAL gives tests a named model of registers, fields, maps, access policies, desired values, and mirrored values, independent of the bus used to reach the DUT. A register map and adapter translate a model operation into protocol-specific bus items for frontdoor access. Backdoor access reaches the HDL path directly when configured. The model mirror stays trustworthy only when prediction is configured. Use auto-predict for simple frontdoor flows or an explicit predictor connected to the bus monitor. RAL improves portability and supplies standard access sequences and optional coverage, but it does not replace protocol checking or a correct predictor. Watch for: Frontdoor-versus-backdoor comparison is not automatic. The test must perform a mirror, read, or check operation with the intended prediction policy.

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

Type	Role	UVM base
Sequence item	One transaction	`uvm_object`
Sequence	Scenario or item stream	`uvm_object`
Sequencer	Arbitration and transport	`uvm_component`
Driver	Transaction to pins	`uvm_component`

Interface	Communication	Typical use
analysis	Broadcast `write()`, no time	Monitor fan-out
put/get	Directed, blocking or nonblocking	Producer-consumer transport
`seq_item`	Arbitrated request/completion	Sequencer-driver

Severity	Default intent	Example
`UVM_ERROR`	Record failure and continue	Scoreboard mismatch
`UVM_FATAL`	Report and exit	Required virtual interface missing

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

UVM Factory and configuration Swap behavior without rewiring.

Two late-binding paths, two different jobs

Reason it through

Reason it through

Reason it through

Reason it through

UVM Sequences and drivers Follow one request end to end.

A request moves; ownership changes

Reason it through

Reason it through

Reason it through

Reason it through

UVM TLM and checking paths Separate actual from expected.

Observation is a broadcast; checking is a comparison

Reason it through

Reason it through

UVM Reports, debug, and RAL Close the loop with evidence.

RAL frontdoor and prediction path

Reason it through

Reason it through

Reason it through

UVMConcepts and Interview QuestionsYou Should Master

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

UVM Factory and configuration Swap behavior without rewiring.

Two late-binding paths, two different jobs

What problem does the UVM factory solve?+

Reason it through

How would you replace a default driver with an error-injecting driver?+

Reason it through

How is uvm_config_db different from a direct hierarchical reference?+

Reason it through

What do uvm_component_utils and uvm_object_utils actually do?+

Reason it through

UVM Sequences and drivers Follow one request end to end.

A request moves; ownership changes

How do a sequence item, sequence, and sequencer differ?+

Reason it through

What is the exact sequence-driver handshake?+

Reason it through

What is a virtual sequence, and when is it useful?+

Reason it through

What are m_sequencer and p_sequencer?+

Reason it through

UVM TLM and checking paths Separate actual from expected.

Observation is a broadcast; checking is a comparison

How does an analysis port differ from put or get TLM interfaces?+

Reason it through

Trace one transaction from a sequence to a scoreboard.+

Reason it through

UVM Reports, debug, and RAL Close the loop with evidence.

RAL frontdoor and prediction path

What is the difference between UVM_ERROR and UVM_FATAL?+

Reason it through

A UVM test hangs. What do you check first?+

Reason it through

What does the UVM Register Abstraction Layer provide?+

Reason it through