UVM Interview Questions: What Verification Engineers Should Be Ready to Explain

You are asked to draw a UVM testbench on a whiteboard. You sketch a driver, a monitor, and a scoreboard. Then the interviewer asks who creates the driver, who tells the agent to build one at all, and what happens if the test never ends. Where does your picture stop being enough?

We do not know what any given company will ask, and we do not claim to. We can point at concepts a verification candidate should be able to explain. This guide uses the Accellera UVM 1.2 User's Guide and the Accellera-hosted UVM Tips and Tricks tutorial slides for the technical explanations. The practice prompts are ours, not questions reported from any employer.

Who owns what in a UVM testbench?

The User's Guide gives each component a short job description. The test is the top-level component. It typically instantiates the environment, configures it through factory overrides or the configuration database, and applies stimulus by invoking sequences. The environment groups related components, such as agents and scoreboards.

An agent groups the pieces that deal with one DUT interface: a sequencer to manage stimulus flow, a driver to apply it, and a monitor to observe the interface. The guide says an agent should work in active mode (generating stimulus) and passive mode (only monitoring). The driver turns transaction-level items into pin-level activity, pulling them from the sequencer with get_next_item() and signaling completion with item_done(). The sequencer arbitrates between sequences.

A good answer names the boundaries: "The sequence decides what to send, the sequencer decides whose turn it is, and the driver decides how it looks on the pins." Then say where checking lives. The guide describes the scoreboard as receiving input and output transactions through agent analysis ports, running inputs through a reference model (the predictor), and comparing expected output with actual output.

Factory, config_db, and the order things happen

The factory lets a test swap one type for another without editing the environment. The guide says that when the factory creates an object it checks for an instance override first, then a type override. Instance overrides are applied first-match, so more specific ones should be written first. The catch is that an override only takes effect if the object was created with type_id::create() rather than new(). The tutorial slides also flag a common mistake: passing null instead of this as the parent when creating a component.

The configuration database passes settings down the hierarchy, for example a virtual interface or an is_active flag. The guide says uvm_config_db is the right choice when hierarchical position matters, and that it sits on top of the more general uvm_resource_db.

Phases decide when each step is legal. The tutorial has a short example: calling factory.print() and print_topology() in build_phase is too soon because the lower hierarchy is not built yet, while end_of_elaboration_phase works. That is a good small story for why phase order matters.

Turn the documentation into a study plan

The distinctions below come from the two Accellera-hosted documents. The practice prompts are MockVise's suggested exercises, not an employer's rubric.

Topic	Documented distinction	Practice prompt
Agent modes	Active agents drive the DUT, passive agents only monitor and collect coverage	When would you instantiate a passive agent, and what do you leave out?
Analysis ports	write() returns in the same delta cycle and works with zero, one, or many subscribers	Why does the monitor not need to know whether a scoreboard exists?
Factory	Instance overrides are checked before type overrides, and creation must go through the factory	Your override has no effect. What do you check first?
config_db	Hierarchical settings, built on uvm_resource_db	How does a virtual interface get from the top module to the driver?
Objections	A phase ends when all raised objections are dropped	What could keep run_phase from ever finishing?
Coverage	Covergroups should be planned before implementation, including coverpoints and bins	What would you cover before you write the covergroup?

Our phone screen questions by hardware role shows how a simple "how would you verify an arbiter?" prompt can open this whole topic.

Randomization and coverage are the point

Constrained random stimulus and functional coverage are why the methodology exists, so expect to explain how they work together. The guide shows constraints added to a transaction class and layered through inheritance, such as a derived item that restricts addresses to word-aligned values. It also describes functional coverage as SystemVerilog covergroups, sampled when a transaction is collected by a monitor.

A reasonable answer connects the two: constraints shape what you generate, coverage tells you what you hit, and a hole sends you back to the constraints or to a directed sequence. Be honest about the limit, too. Full coverage only says your model of the interesting cases was hit, not that the model was right. For the other side, see our post on formal verification versus simulation.

How do you debug a UVM test that never ends?

Here is an illustrative scenario, our suggestion and not a company question. A regression test passes functionally but the simulation hangs after the last transaction.

The guide says every phase has a built-in objection and terminates once all raised objections are dropped. Our suggested approach:

1. Confirm which phase is stuck. The tutorial lists +UVM_PHASE_TRACE for phase execution.
2. Turn on +UVM_OBJECTION_TRACE and look at which component raised an objection and never dropped it.
3. Check whether a sequence or the test raised it, and whether every path, including early exits, reaches the drop.
4. Fix one cause, rerun, and record what changed.

Rehearse the reverse bug too. The guide notes that an "all dropped" moment can be temporary, since the last transaction may still be on its way to the scoreboard, and it mentions phase_ready_to_end() and drain time for that. A scoreboard mismatch has the same flavor: check the monitor sampling point and the predictor before blaming the DUT.

Prepare one story you can defend

Pick one testbench you worked on, or a small one you built yourself, and walk through it in order: interface, agent, sequence, scoreboard, coverage. If you have mostly used UVM from a template, say so, then explain what you traced and changed. Our guide to pre silicon verification versus post silicon validation can help you describe where this work sits, and our look at verification versus RTL design roles covers how the two paths differ.

You can also book a mock interview on MockVise to practice explaining a hang or a mismatch out loud. The aim is a clear chain of reasoning, not a recited definition.

Sources: Accellera UVM 1.2 User's Guide, Accellera UVM Tips and Tricks tutorial slides. This article provides general technical preparation guidance, not company interview questions. UVM versions and interview formats vary, so confirm the format with your recruiter and the behavior of your simulator and UVM release with its documentation. MockVise is not affiliated with or endorsed by Accellera, Doulos, or VerifWorks.

FAQ

Q: Which UVM concepts should a verification candidate be able to explain? Testbench architecture and agent modes, factory and config_db, phase order, objections, analysis ports, and how constrained random stimulus and functional coverage fit together.

Q: Why might a factory override have no effect? An override only takes effect if the object was created with type_id::create() rather than new(). The guide also says instance overrides are checked before type overrides.

Q: What can make a UVM simulation hang after the last transaction? Often an objection that was raised and never dropped, since a phase ends only when all raised objections are dropped. Use +UVM_PHASE_TRACE to find the stuck phase and +UVM_OBJECTION_TRACE to find which component never dropped its objection.

Q: How do constraints and coverage work together? Constraints shape what you generate and coverage tells you what you hit. A hole sends you back to the constraints or to a directed sequence, and full coverage only says your model of the interesting cases was hit, not that the model was right.