Verification Interview Questions

A design interview asks whether you know the APB protocol; a verification interview asks whether you can prove a slave obeys it — and that is a different, harder skill. The single idea to carry: every APB DV question reduces to one of five checks — does the stimulus exercise the rule, does an assertion catch the violation non-vacuously, does the monitor sample on the right edge, does the scoreboard compare against a real reference model, and does coverage prove the space was hit. A candidate who can name which of those five a given question tests, and answer with real APB signal names and correct SVA, signals that they have closed coverage on a peripheral, not just read the spec. This chapter is the question bank for that conversation: the SVA properties, the agent topology, the sampling-edge traps, the scoreboard and coverage model, and the error-injection methodology — each as the model answer a verification lead is listening for.

1. What this chapter covers

This is the DV interview-bank chapter for APB. It assumes you already know the protocol from the rules catalogue and turns the focus to verification methodology: how you would build, run, and sign off a testbench that proves an APB slave correct.

The scope is the five layers an interviewer probes, top to bottom:

Assertions — writing correct SVA for the protocol rules (stable PADDR, PENABLE in ACCESS, bounded completion, PSLVERR validity), and the meta-skill of detecting a vacuous assertion that passes for the wrong reason. This builds directly on APB assertions.
The UVM agent — the driver/sequencer/monitor container, active versus passive, and the handshake discipline that keeps it from hanging. The full treatment is in the UVM APB agent.
The monitor — sampling-edge correctness, the difference between sampling in SETUP and at completion, and why a one-edge error silently corrupts every transaction. See APB monitors.
The scoreboard and reference model — what an APB scoreboard actually compares, where the golden data comes from, and why a memory model is not a free pass. See APB scoreboards.
Functional coverage — the address-range, response-code, wait-state, and cross-coverage model, and what "coverage closure" means as a sign-off gate. See APB functional coverage.

The chapter closes each loop with negative testing (error injection) and the corner cases that separate a passing testbench from a trusted one.

2. Why this matters now

You can recite the two-phase model perfectly and still fail a verification interview, because the verification questions are not "what does the protocol do" — they are "how do you know your testbench actually checked it." The gap between those two is where DV careers are made.

The reason this matters now is that the expensive APB bugs are not protocol-ignorance bugs; they are verification-escape bugs. The slave that corrupts write data under back-to-back wait-stated traffic, the error response that is never sampled, the address-decode hole that no test ever drove — these ship because a testbench reported green while never exercising the failing path. A design engineer who believes the wrong protocol answer writes a bug an assertion catches in the first sim. A verification engineer who writes a vacuous assertion, samples the monitor on the wrong edge, or leaves a coverage hole lets a real bug escape silently — and silent escapes are the ones that reach silicon.

So the interview tests a specific discipline: for any APB behaviour, can you (a) write the assertion that catches its violation, (b) confirm that assertion fires non-vacuously, (c) sample the transaction on the right edge, (d) compare it against a reference model, and (e) prove with coverage that you drove the case. Those five questions are this chapter.

3. Mental model — the verification stack

The model: an APB testbench is a five-layer stack, and every interview question lands on exactly one layer. Hold the stack in your head and each question announces which layer it tests and what the failure mode at that layer looks like.

From stimulus down to sign-off:

Stimulus (sequences → sequencer → driver) authors transactions and drives protocol-legal pins. Its failure mode is a handshake stall — a missing item_done hangs the agent — or under-stimulation, where a legal case is simply never driven.
Assertions (bound SVA) check every rule on every edge, live. Their failure mode is vacuity — an antecedent that never arms, so the property reads green while testing nothing.
The monitor reconstructs each transfer into an apb_seq_item. Its failure mode is a sampling-edge error — capturing PRDATA one edge too early silently feeds the scoreboard wrong data.
The scoreboard compares each transaction against a reference model. Its failure mode is a weak model — a memory that mirrors the DUT's own mistake, so a mismatch is never seen.
Coverage proves the space was exercised. Its failure mode is a coverage hole — an unbinned or unhit case that no one noticed was missing.

Figure 1 — the APB DV stack an interview probes, layer by layer, with what each layer catches. On the left, a sequence library feeds the sequencer, which hands items to the driver through the get_next_item / item_done handshake; the driver drives PSEL, PENABLE, PADDR, PWRITE, PWDATA onto the APB DUT and samples PREADY, PRDATA, PSLVERR back. The monitor taps the same pins read-only on the completion edge and reconstructs each transfer into an apb_seq_item, broadcasting it from one analysis port that fans out to the scoreboard (compared against a reference model) and the functional-coverage collector (address, response, wait-state bins plus crosses). A non-intrusive SVA protocol checker is bound to the bus and fires the instant a rule breaks. The legend names what each layer catches: the driver produces legal stimulus, assertions catch protocol violations live and must fire non-vacuously, the monitor catches sampling-edge errors, the scoreboard catches data and response mismatches, and coverage catches the unexercised space.

A refinement that makes the model interview-ready: the layers are independent, so a green run can hide a failure at any one of them. A passing assertion suite, a passing scoreboard, and 90% coverage can all coexist with a real escaped bug — if the assertion was vacuous, the scoreboard's model was wrong, or the 10% uncovered space was where the bug lived. Verification confidence is the conjunction of all five layers being honest, never any one of them reporting green.

4. Real SoC context

These layers are not academic — each maps to a real escape that has shipped. In a real SoC the APB fabric hangs dozens of peripherals (timers, GPIO, UART, control/status registers) off a bridge, and the verification environment instantiates one agent per interface, a bound assertion checker on every bus, and a register-model-backed scoreboard per peripheral. The five-layer discipline is what keeps that environment trustworthy across forty blocks instead of forty subtly-broken testbenches.

The classic escape is the vacuous stability assertion: a team signs off a slave with a full assertion suite, every property green, then integration shows the slave corrupting PWDATA under back-to-back wait-stated writes — exactly the failure the stability assertion was written to catch. Pulling the assertion's coverage reveals the antecedent had 0% hits: it gated on a read wait while write data only matters on writes, so it never armed. The assertion existed, compiled, and "passed" while testing nothing. The fix is mechanical — widen the antecedent, pair it with a cover — but the methodology lesson is the expensive one: a green assertion is meaningless until you confirm it fired.

The second is the sampling-edge escape: a monitor that samples PRDATA when PENABLE first rises rather than at the completion edge (PSEL & PENABLE & PREADY) reads the bus one edge too early on every wait-stated read, so it reconstructs the wrong read data — and then feeds that wrong data to a scoreboard that faithfully compares wrong-against-wrong-derived-golden and reports a match. The bug is in the testbench, not the DUT, and it makes a broken slave look correct. Both escapes share a shape: a layer that looks like it is working while quietly doing nothing useful, which is precisely what the interview is probing for.

5. Weak answer vs strong answer

This is the interview-grading table: each row is a DV question as a weak answer (what a candidate who memorised the spec says) beside the strong answer (what someone who has signed off a peripheral says) and the methodology tell that distinguishes them.

Question	Weak answer	Strong answer	Methodology tell
"How do you check `PADDR` is stable?"	"I look at the waveform."	"A bound SVA property: `(psel && !(penable && pready)) \|=> $stable(paddr)`, paired with a `cover` on its antecedent."	Names the operator (`\|=>` for held/next-cycle) and pairs the assert with a cover for non-vacuity.
"Is your assertion suite passing?"	"Yes, all green."	"Green and every antecedent `cover` HIT — a vacuous pass reads identical to a real one."	Treats vacuity as the dominant silent-escape mode, not an afterthought.
"Active or passive agent here?"	"Always active."	"Active at block level to drive the DUT; passive at integration to observe a real master — only `is_active` flips."	Knows the monitor is built in both modes and reuse is the point.
"When does the monitor sample read data?"	"When `PENABLE` is high."	"At the completion edge `PSEL & PENABLE & PREADY` — `PENABLE` high includes every wait state."	Distinguishes the access phase from its endpoint; the one-edge error is silent.
"What does the scoreboard compare?"	"Read data against write data."	"Each transaction against an independent reference model — a register model or memory model with its own state."	The model must not be able to echo the DUT's mistake.
"When is coverage done?"	"When it hits 100%."	"When the functional model — address ranges, response codes, wait bins, and their crosses — is hit, and the holes are reviewed, not just the number."	Coverage is a model, not a percentage; closure is a sign-off review.
"How do you test the error path?"	"I hope a transfer errors."	"Inject a protocol violation or an error address, then assert the slave responds with `PSLVERR` at completion — and cover that it happened."	Negative testing is directed and checked, not incidental.

The throughline: every weak answer stops at "I observe it" or "it's green"; every strong answer names the mechanism (the SVA operator, the sampling edge, the independent model, the coverage cross) and the proof that it fired (the cover HIT, the asserted response). The methodology tell is always whether the candidate closes the loop — from stimulus through a check to a coverage point — rather than trusting a single green light.

6. Red flags / common DV mistakes

DV mistakes that betray a thin testbench

Mistake — "A green assertion means the rule is checked." Wrong. A property whose antecedent never arms passes vacuously on every cycle while never evaluating its consequent — and in the log it is indistinguishable from a real pass. The fix: pair every assert with a cover on its antecedent and treat a 0% antecedent cover as a suite failure, not a pass. This is the single most common silent escape.
Mistake — "Sample PRDATA when PENABLE goes high." Wrong. PENABLE is high across every wait state; read data and PSLVERR are valid only at the completion edge PSEL & PENABLE & PREADY. Sampling one edge early reconstructs the wrong transaction on every wait-stated read — and the scoreboard then compares wrong data and may report a false match.
Mistake — "A passive agent still has a driver, just disabled." Wrong. In UVM_PASSIVE the driver and sequencer are never constructed; a passive agent is a monitor with no driver. Believing otherwise leads to two drivers on one bus at integration — contention — or to a "passive" agent that someone expects to drive.
Mistake — "The scoreboard compares read data to the last write." Often wrong. That only works for a plain memory; a register with side effects (a clear-on-read status, a write-1-to-clear bit) needs a reference model that mirrors the register semantics. A memory-mirror scoreboard silently passes a register that behaves wrongly.
Mistake — "100% coverage means done." Wrong on two counts. First, code coverage at 100% says nothing about whether the functional space (wait counts, error responses, address boundaries, their crosses) was hit. Second, a coverage number with unreviewed holes can be 98% while missing the exact case the bug lives in. Closure is a review of the model and its holes, not a percentage.
Mistake — "Negative tests just mean random with errors on." Wrong. Error injection must be directed and checked: drive a specific violation (an error address, a write to a read-only register, a protocol-illegal sequence) and assert the expected response (PSLVERR at completion, no state change), then cover that the case was reached. An un-checked error injection proves nothing.
Mistake — "bind assertions change the DUT." Wrong. A bound checker is a separate module attached to the interface; the DUT source is untouched and nothing reaches the netlist. The same checker binds to every APB slave.

Figure 2 — a vacuous APB stability assertion that passes for the wrong reason, beside the corrected non-vacuous property. Top (red): the antecedent is gated on (psel && penable && !pready && pwrite==0), so it only arms on a read wait; on a write transfer PADDR drifts during a wait state, but the antecedent is never true, so the property reports PASS with non-vacuous evaluations = 0 and the address-drift bug escapes a green regression. The diagnostic in the panel: an assertion whose antecedent cover is 0% never tested anything — a green pass is an unasked question. Bottom (green): the corrected property arms on every held beat, (psel && !(penable && pready)) |=> $stable(paddr), and is paired with a cover that HITs; when the same PADDR drifts the $stable consequent is evaluated, returns false, and the assertion FAILS — catching the bug. The figure teaches that a green assertion is meaningless until you confirm it fired non-vacuously, and that pairing every assert with a cover on its antecedent turns a silent vacuous pass into a visible reachability failure.

7. Interview framing

A verification interviewer is not testing whether you can recite UVM class names — they are testing whether you can be trusted to sign off a block. The framing that earns that trust is to answer every question by closing the loop from stimulus to a check to a coverage point, and to volunteer the silent-escape mode at each layer.

When asked "how would you verify X," do not stop at "I'd write an assertion" or "I'd add a scoreboard." Walk the loop out loud: "I'd drive X with a directed sequence, catch its violation with a bound SVA property — and confirm the property's antecedent cover HITs so it isn't vacuous — reconstruct the transaction in the monitor sampling at the completion edge, compare it against an independent reference model, and prove I exercised it with a coverage bin." That structure shows you think in the five-layer stack, not in isolated components. The strongest single move is to name the silent failure at the layer in question — "the danger here isn't a loud false-fail, it's a vacuous assertion / a one-edge sampling error / a model that echoes the DUT / a coverage hole" — because naming the silent escape is what separates someone who has debugged a green-but-broken testbench from someone who has only built one. Close with the line that lands every time: "a green run is the conjunction of five honest layers; any one of them lying reads identical to success."

8. Q&A

9. Practice

Write the stable-PADDR assertion from memory. Produce (psel && !(penable && pready)) |=> $stable(paddr), justify the |=> operator, and add the paired cover that proves it is non-vacuous. Then extend it to pwrite, pwdata, and pstrb.
Bounded vs ready-implies-valid. Write both properties for PREADY — the bounded-completion liveness property and the response-known-at-completion safety property — and state, in one sentence each, the distinct failure each one catches.
Spot the vacuity. Given (psel && penable && !pready && pwrite==0) |=> $stable(pwdata), explain why it passes vacuously on every write transfer, rewrite the antecedent so it arms on every held beat, and write the cover you would gate sign-off on.
Design the coverage model. Write a covergroup with coverpoints for direction, address range (including a decode-hole bin), response code, and wait-state count, plus the three crosses that catch the holes single coverpoints miss. State which cross would have caught a write-only-fails bug.
Inject and check an error. Describe, as a three-part loop (stimulus / check / coverage), how you would verify the slave returns PSLVERR on an address-decode hole — the directed sequence that drives it, the assertion and scoreboard prediction that check the response, and the coverage cross that proves the case was reached.

10. Key takeaways

Every APB DV question lands on one of five layers — stimulus, assertions, monitor, scoreboard, coverage — and a green run is the conjunction of all five being honest; any one of them lying reads identical to success.
Stable PADDR is (psel && !(penable && pready)) |=> $stable(paddr), anchored to completion with |=>, and always paired with a cover on its antecedent — because a vacuous assertion passes for the wrong reason and is indistinguishable from a real pass.
Bounded completion is liveness, ready-implies-valid is safety — the first catches a slave that never finishes, the second catches one that finishes with junk; a complete PREADY check needs both.
The monitor must sample the response at the completion edge (PSEL & PENABLE & PREADY), never when PENABLE first rises — a one-edge error silently reconstructs the wrong transaction on every wait-stated read.
Active vs passive is a build-time is_active config knob — active builds sequencer+driver+monitor and drives, passive builds only the monitor and observes; the same agent reuses from block to integration, and a mis-set passive agent fails silently.
The scoreboard compares against an independent reference model, never an echo of the DUT, and coverage closure is a reviewed functional model — address ranges, response codes, wait bins, and their crosses — not a code-coverage percentage. Negative tests are directed, checked, and covered, never incidental.