The short answer: design verification interviews test three things: methodology (verification plans, constrained-random testing, coverage closure, when you’re done), testbench building blocks (drivers, monitors, scoreboards, assertions, and the UVM classes that wrap them), and debugging (how you find the root cause of a failure). Expect at least one “how would you verify this block?” question, usually a FIFO, an arbiter or a protocol interface.
Verification is the biggest job market in VLSI, and the interviews are different from design interviews. Language questions matter, but what really separates candidates is how they think: what they would check, how they would know they’re done, and how they debug.
For the language side (classes, constraints, covergroups, SVA syntax), read my SystemVerilog interview questions first. This post covers methodology, UVM and debugging.
- Methodology
- Building a testbench
- UVM
- Debugging
Table of Contents
Part 1: Methodology
1. What goes into a verification plan?
The features to verify (taken from the spec), how each will be stimulated, how it will be checked (scoreboard, assertion, reference model), what coverage proves it was exercised, and the sign-off criteria. A good plan is reviewed with the designers and architects, because it’s the contract for what “verified” means.
2. Directed or constrained-random testing?
Directed tests are quick to write and great for bring-up and specific corner cases, but they only find bugs you thought of. Constrained-random tests explore combinations you didn’t think of, and need self-checking and functional coverage to be useful. Real projects use both: directed for bring-up and known corners, random for the bulk of the bugs.
3. How do you know when verification is done?
- Every item in the verification plan has passing tests.
- Functional coverage meets the agreed targets, and remaining holes are reviewed and waived.
- Code coverage is high, and every unhit line is explained.
- Regressions are stable and the bug discovery rate has flattened.
There is never a mathematical “done” in simulation; it’s a reviewed judgement backed by these metrics.
4. What types of code coverage are there?
Line (statement), branch, condition or expression, toggle, and FSM state and transition coverage. They’re collected automatically by the simulator.
5. You have 100% code coverage, but a bug escaped. How?
Code coverage only shows that lines were executed, not that the result was checked, and not that the right combinations or sequences happened. A missing check in the scoreboard, a missing scenario (two events in the same cycle), or a missing feature in the RTL itself won’t show up in code coverage. That’s what functional coverage and good checkers are for.
6. What is the difference between simulation and formal verification?
Simulation checks the behaviour for the stimulus you give it. Formal tools prove properties for all possible inputs, within a bound or completely. Formal is excellent for control logic, arbiters, FIFOs, protocol rules and finding deadlocks, but struggles with wide datapaths and very deep sequential state.
7. Why do we still run gate-level simulations?
To catch what RTL simulation can’t: problems in the netlist from synthesis or DFT insertion, reset and X-initialisation issues, and timing behaviour with SDF back-annotation. They’re slow, so teams run a small, targeted set.
Part 2: Building a testbench
8. What are the parts of a self-checking testbench?
A stimulus generator, a driver that converts transactions to pin wiggles, a monitor that converts pins back to transactions, a reference model or predictor that computes expected results, a scoreboard that compares actual with expected, plus assertions and coverage collectors.
9. How would you build a scoreboard for out-of-order responses?
Store expected transactions in an associative array (or a queue per ID) keyed by the transaction ID. When an actual response arrives, look up its ID, compare, and delete the entry. At the end of the test, check that nothing is left, which catches lost transactions.
10. How would you verify a synchronous FIFO?
- Data integrity and ordering: everything written comes out once, in order (scoreboard with a queue).
- Flags: full, empty, and almost-full/empty at the exact right counts.
- Corner cases: write when full, read when empty, simultaneous read and write at full and at empty, reset in the middle of traffic.
- Assertions: no write accepted when full, no read when empty, count never exceeds depth.
- Coverage: occupancy levels, back-to-back operations, each flag transition.
11. How would you verify a round-robin arbiter?
Check that a grant is only given to a requester, that grants are one-hot, that every requester gets a grant within N cycles while it keeps requesting (fairness and no starvation), and that the priority rotates correctly after each grant. Formal is a great fit here, because the state space is small.
12. Where would you put assertions?
On interfaces, to check protocol rules (valid stays high until ready); inside the design, for invariants (FIFO never overflows, FSM never reaches an illegal state); and on handshakes between blocks. Designers often write internal assertions; verification engineers usually own interface ones.
Part 3: UVM
13. What is the difference between uvm_object and uvm_component?
uvm_component is the static structure of the testbench: drivers, monitors, agents, environments, tests. Components exist for the whole simulation, have a place in the hierarchy and take part in phases. uvm_object is for data and configuration that comes and goes, such as sequence items, sequences and config objects.
14. Explain the UVM phases.
build_phase creates components (top-down); connect_phase connects TLM ports; end_of_elaboration and start_of_simulation are for final checks and printing. run_phase is the only time-consuming phase, and it runs in parallel for all components. After that, extract, check, report and final collect and report results. All phases except build run bottom-up.
15. What is the UVM factory, and why use create() instead of new()?
The factory lets a test replace a class with a derived class without editing the environment, using a type override (everywhere) or an instance override (one path). It only works if objects are created with type_id::create(); calling new() directly bypasses it.
16. What is uvm_config_db used for?
Passing configuration down the hierarchy without hard-coded handles: virtual interfaces from the top module to drivers and monitors, config objects to agents, and settings like “is this agent active”. set() stores a value for a hierarchical path; get() retrieves it, usually in build_phase.
17. How do the sequence, sequencer and driver talk to each other?
// in the sequence
req = my_item::type_id::create("req");
start_item(req);
assert(req.randomize());
finish_item(req);
// in the driver
forever begin
seq_item_port.get_next_item(req);
drive(req);
seq_item_port.item_done();
endstart_item waits for the sequencer to grant access; finish_item sends the item and waits until the driver calls item_done.
18. What are objections?
They decide when run_phase ends. A test raises an objection before starting its sequences and drops it when they finish; when all objections are dropped, the phase ends. Forgetting to raise one ends the test at time zero; forgetting to drop one makes it hang until the timeout.
19. What is an analysis port?
A one-to-many broadcast port. The monitor calls write() on it with each observed transaction, and every connected subscriber (scoreboard, coverage collector) receives a copy. The monitor doesn’t need to know who is listening.
20. Active vs passive agents?
An active agent has a sequencer, driver and monitor, so it drives stimulus. A passive agent has only the monitor; it’s used to observe interfaces driven by another block, which is common when you reuse a block-level environment at subsystem level.
21. What is a virtual sequence?
A sequence that doesn’t generate items itself but starts and coordinates sequences on several sequencers, for example configuring through APB while sending traffic on AXI.
22. What is the UVM register model (RAL) for?
It mirrors the DUT’s registers in the testbench, so tests can read and write by register name instead of address, and the model can predict and check register values. Front-door access goes through the real bus; back-door access reads and writes the RTL signals directly, which is fast but skips the bus logic.
Part 4: Debugging
23. A random test fails. How do you debug it?
- Re-run with the same seed to reproduce it.
- Find the first point where actual and expected diverge, from the scoreboard message or assertion, not the last error.
- Go to that time in the waveform and work backwards: was the input legal, did the DUT do the wrong thing, or did the testbench predict wrong?
- Decide if it’s a DUT bug, a testbench bug or a spec ambiguity, and file it with the seed and a short explanation.
24. A test passes alone but fails in regression. Why?
Usually a different seed, a different test order affecting shared files or static variables, a timeout that’s too tight on a busy machine, or a dependency on simulator command-line options. I’d first check the seed and the exact command used in the regression.
25. What is X-propagation, and why does it matter?
An x in RTL simulation can be optimistic: an if (x) takes the else branch, hiding a bug that real hardware would show. Gate-level simulation can be pessimistic instead. Teams use X-propagation modes in the simulator, reset checks and assertions on key control signals to catch these issues.
Practise this on VLSI Forge
I built VLSI Forge so you can write RTL in your browser, run it on a real simulator and check every signal in the waveform. Free, nothing to install.
FAQ
Do I need UVM to get a verification job?
For most industry DV roles, yes, at least the basics: components, phases, sequences, config_db and the factory. For entry-level roles, strong SystemVerilog and one solid testbench project can be enough.
What project should I build to prepare?
A self-checking testbench for a FIFO or a simple bus like APB, with constrained-random stimulus, a scoreboard, assertions and a covergroup. Be ready to explain every design choice.
How deep do interviewers go into UVM?
For freshers, structure and phases. For experienced engineers, expect factory overrides, sequence arbitration, RAL and debugging stories from real projects.
Is formal verification worth learning?
Yes. It’s increasingly common for control logic, and knowing when to use it is a strong signal in interviews.
