Verification Engineer Interview Questions and Strong Answers

What is the difference between code coverage and functional coverage?

Code coverage measures which RTL structures were executed, while functional coverage measures whether the intended design scenarios were tested. High code coverage alone does not prove the verification plan is complete.

How would you verify a FIFO?

The invariants come first: data ordering (what goes in comes out, in order), no loss, no duplication, and flag correctness — empty and full assert exactly at the boundary depths, never one entry early or late. The high-yield corners: simultaneous read and write at empty and at full, write-to-full and read-from-empty (the design must either stall or flag, per spec), and pointer wraparound, because off-by-one bugs live at the wrap. Checkers split by nature: assertions for illegal states and flag protocol, a scoreboard for end-to-end ordering, functional coverage on the boundary transitions. For an asynchronous FIFO, add the CDC layer: pointers must cross domains gray-coded and synchronized, full and empty must be generated from the synchronized pointer copies (conservative flags are safe by design; comparing raw binary pointers across domains is the classic bug), and reset behavior across both domains needs its own checks.

How do you debug a failing regression?

Reproduce first — same seed, same configuration, same build — because a failure you cannot reproduce is a different (and worse) problem. Then find the first point of divergence from a passing run or the reference model, not the last error message: the root cause is at the divergence, while the visible failure is often thousands of cycles downstream. Check stimulus legality before suspecting the design, then isolate which component owns the bug: RTL, testbench, reference model, or constraints. Triage with an open mind about ownership — many regression failures, especially late in a project, turn out to be testbench or constraint bugs — which is why "the RTL is wrong" is a conclusion, not a starting assumption.

What is UVM used for?

UVM (see /topics/uvm-verification-explained) standardizes the structure of a verification environment so it can be reused and scaled: sequences separate what stimulus to send from the driver that knows how to send it, agents bundle driver, monitor, and sequencer per interface so the same agent verifies that interface on any design, and the configuration database lets one environment run in different modes (active or passive, block or system level) without rewrites. The phasing model coordinates build, connect, run, and cleanup across hundreds of components. The honest senior framing: UVM buys reuse and team-scale consistency at the cost of boilerplate — for a small block, a lightweight SystemVerilog bench is often the better tool.

When would you use assertions instead of a scoreboard?

Assertions are best for protocol and timing properties that should always hold, such as handshake rules or FIFO safety. A scoreboard is better for comparing expected versus actual end-to-end behavior over time.

What does it mean for coverage to close, and why is that not the same as being bug-free?

Coverage closure means every item in the functional and code coverage models has been hit. It proves the planned scenarios were exercised, not that the plan was complete or the checkers were correct. A design can reach full coverage and still ship a bug if the relevant scenario was never modeled or the checker never flagged the wrong result.

How do you verify clock-domain crossings?

Functional simulation alone can hide CDC bugs because it does not model real metastability. The standard approach combines structural CDC analysis to confirm every crossing has a recognized synchronizer, assertions on handshake and gray-code protocols, and metastability injection in simulation to confirm the design tolerates the resulting uncertainty.

What separates a good assertion from a weak one?

A good assertion states a spec property the design must always honor, fails loudly at the moment of violation, and cannot pass vacuously without anyone noticing. The vacuous-pass trap is the classic miss: an implication like "request implies grant within N cycles" passes trivially if no request ever fires, so a companion cover property on the antecedent belongs alongside every implication — vacuity has to be measured, not assumed away. Strong candidates also pick the right property shape — safety properties (nothing bad happens) for protocol rules, bounded-response properties for forward progress (grant within N cycles: the practical, simulation-checkable stand-in for pure liveness) — and they keep assertions local to interfaces, where a failure pinpoints the violator instead of flagging a symptom three blocks downstream.

How do you bring up a verification environment for a new block?

Plan before code: extract the verification plan from the spec — the features, the properties that must hold, the corner cases, and what coverage will prove. Then build in dependency order: interfaces and a smoke sequence first (one legal transaction through the design), checkers before stimulus scale-up — because constrained-random traffic against a design with no scoreboard finds nothing — then ramp randomization and add functional coverage against the plan. The discipline that pays off is making the checkers earn trust early: seed a known bug or two and confirm the environment catches them before believing any green run.

What is X-propagation, and why does it matter?

X represents an unknown logic value in 4-state simulation, and it matters because RTL simulation handles it optimistically: an if-statement with an unknown condition resolves to a deterministic branch (X is generally treated as not-true, so the else path runs) instead of propagating the uncertainty — masking the fact that real silicon could go the other way. That is X-optimism — bugs from uninitialized registers, memories, or incomplete resets can simulate clean and fail in hardware (the reverse, X-pessimism, wastes debug time on Xs that real hardware would resolve). The practical defenses: reset and initialization discipline checked deliberately, X-propagation-aware simulation modes, formal or structural checks on reset coverage, and gate-level simulation at sign-off, which exposes classes of X, reset, and timing issues RTL simulation can mask — while bringing its own pessimism.