Verification Interview Questions

Verification prompts ask "how would you verify this?" — the checker, coverage, and UVM questions that test whether you can prove an AHB design correct, not just build it. The common prompts: a protocol checker / assertions (turn every AHB rule into an SVA assertion — HREADY eventually high, legal HTRANS sequences, control stable during waits, the two-cycle ERROR); a monitor (passively observe the bus and reconstruct transactions, anchored on the pipeline); a scoreboard (check data correctness against a reference model — every write read back, every read returns the expected data); a coverage model (measure what you've exercised — transfer/burst types, wait-state counts, responses, crosses); constrained-random stimulus (generate legal, varied traffic + directed corners); and a UVM agent (package a driver, monitor, sequencer into a reusable agent). The way to answer well is to frame verification as a closed loop: stimulate (constrained-random) → observe (a monitor reconstructing transactions) → check legality (assertions encoding every rule) → check correctness (a scoreboard vs a reference model) → measure (functional coverage) → close the holes (steer the next constraints). The single most valuable framing is to separate legality (the protocol rules, checked by assertions) from correctness (the data integrity, checked by the scoreboard), and to define "done" as coverage closure. And the monitor anchors on the pipeline — the verification mirror of the RTL pipeline capture. This chapter works through the loop with a real assertion set.

1. What Is It?

Verification questions ask you to prove an AHB design correct; answering them means framing the closed loop and separating legality from correctness. The prompts and the loop:

• The prompts — a protocol checker/assertions, a monitor, a scoreboard, a coverage model, constrained-random stimulus, a UVM agent.
• The closed loop — stimulate (constrained-random) → observe (monitor) → check legality (assertions) → check correctness (scoreboard) → measure (coverage) → close.
• Legality vs correctness (the key split) — legality = the protocol rules (checked by assertions); correctness = the data integrity (checked by the scoreboard). Different checks.
• The monitor anchors on the pipeline — reconstruct transactions by pairing each address phase with its data phase (the verification mirror of the RTL capture); define done as coverage closure.

So verification questions are the prove-it test — interviewers use them to confirm you can verify AHB, not just build it. The signal they're looking for is whether you frame the closed loop and separate legality from correctness — anyone can say "I'd write some tests"; a candidate who can verify AHB says: "I'd separate two kinds of checks. Legality — the protocol rules — goes in assertions: HREADY eventually high, HTRANS legal sequences, control stable during waits, the two-cycle ERROR. Correctness — the data — goes in a scoreboard against a reference model: every write read back correctly. Then I measure with functional coverage and close the holes with constrained-random steered by the gaps." The frame-the-loop, separate-legality-from-correctness is the differentiator: it shows you think in the verification methodology, not ad-hoc tests. And the meta-signal: the monitor anchors on the pipeline — the same discipline as the RTL. So verification questions are the prove-it test, framed as a closed loop. So they're where you prove the design correct.

2. Why Does It Exist?

Verification questions exist because most of a chip team's effort is verification (proving the design correct is harder and bigger than building it) — and the test of whether you can verify is whether you think in the methodology (the closed loop: stimulus, checking, coverage) and separate the kinds of checking (legality vs correctness) — because that is what systematic verification requires.

The verification is most of the effort is the root: on a real chip, verification is more than half the effort — proving the design correct is harder than building it. So a huge fraction of engineering roles are verification. So verification questions test the dominant skill. So they exist to test verification. So verification matters most. So prove it correct.

The think in the methodology is the test: ad-hoc tests don't scale — systematic verification needs a methodology (stimulus → observe → check → measure → close). So the test is whether you think in the loop — not "I'd write some tests" but "I'd stimulate, observe, check, measure, close." So verification questions test the methodology. So they exist to test systematic thinking. So frame the loop. So think methodically.

The separate legality from correctness is the key insight: two different things can be wrong — the design can violate the protocol (illegal) or corrupt the data (incorrect) — and they need different checks (assertions vs scoreboard). So a strong verifier separates them. So verification questions test the separation — do you know the two kinds of checking? So they exist to test the legality/correctness split. So separate them. So verification questions exist because: verification is most of the effort (the root); the test is thinking in the methodology (the closed loop — systematic thinking — the skill); and the key insight is separating legality from correctness (assertions vs scoreboard — the split). So verification questions are the prove-it test — passed by framing the closed loop and separating legality from correctness — demonstrating you can verify AHB systematically. So this chapter prepares you to verify AHB. So frame the loop, and separate legality from correctness.

3. Mental Model

Model an AHB verification answer as a building inspector signing off a new house, not the builder who built it. A weak inspector eyeballs it — "looks fine." A rigorous inspector works a system: they have a checklist of code rules (every wire gauge, every joist spacing, every smoke detector — the legality check, like assertions for every protocol rule); they test that things actually work (run every tap, flip every breaker, confirm the water that comes out is clean — the correctness check, like a scoreboard confirming the data); they track what they've inspected against the full plan so nothing's skipped (the coverage — every room, every system); and they probe the corners a casual look misses (the directed tests). They never just "look" — they check legality, verify function, and track coverage until every item is signed off. "Done" isn't "looks fine"; it's "every item on the checklist is covered."

A home inspection where a candidate is the inspector signing off a new house (verifying an AHB design), not the builder (who designed it — the previous chapter). A weak inspector eyeballs it: "looks fine" ("I'd write some tests" — ad-hoc). A rigorous inspector works a system (the closed loop): a checklist of code rules — every wire gauge, joist spacing, smoke detector (the legality check — assertions for every protocol rule: HREADY eventually high, legal HTRANS, stable control, two-cycle ERROR); testing that things work — run every tap, flip every breaker, confirm the water is clean (the correctness check — the scoreboard: the data that comes out matches what should); tracking what's inspected against the full plan (the coverage — every room, every system: every transfer/burst type, wait count, response); and probing the corners a casual look misses (the directed tests for the corner cases). The inspector never just "looks" — they check legality (code rules), verify function (run it), and track coverage (the checklist) until every item is signed off. And "done" isn't "looks fine" — it's "every item on the checklist is covered" (coverage closure). And critically, the inspector separates code-compliance (legality) from does-it-work (correctness) — two different inspections.

This captures AHB verification: the eyeballing inspector = ad-hoc testing; the rigorous inspector's system = the closed verification loop; the checklist of code rules = assertions for every protocol rule (legality); running every tap and confirming clean water = the scoreboard checking data integrity (correctness); tracking inspected rooms against the plan = functional coverage; probing the corners = directed tests for corner cases; "done" = every checklist item covered = coverage closure; separating code-compliance from does-it-work = separating legality from correctness. Check legality (assertions), verify correctness (scoreboard), track coverage (until closure), probe the corners — and you've verified the design, not just looked at it.

The loop that frames it all:

The model's lesson: check legality (assertions), verify correctness (scoreboard), track coverage (to closure), probe the corners — and the monitor anchors on the pipeline. In the figure, the monitor pairs D0 with A0 (the address one cycle earlier) — the same pipeline discipline as the RTL — and emits a transaction the scoreboard and coverage consume. That's systematic verification.

4. Real Hardware Perspective

The substance behind a strong verification answer is the verification structure from Module 9 (the verification module) — so each prompt maps to a chapter, and the answer builds that piece of the loop.

The assertions (legality) and the monitor (observe): build them — assertions encode every protocol rule (the protocol-checker mindset): HREADY eventually high, legal HTRANS, stable control in waits, the two-cycle ERROR. The monitor passively reconstructs transactions, anchored on the pipeline. So the answer builds the legality check and the observer (see Protocol-Checker Mindset, AHB Assertions, AHB Monitors). So it's legality + observation. So assert the rules, observe the bus.

An assertion set that encodes the legality rules:

// AHB protocol assertions — legality (the protocol rules), not data correctness.
// Bind this checker to the bus; each property fires on a violation, anywhere.
 
// 1. No hang: once a transfer starts, HREADY must eventually go high.
property p_hready_liveness;
  @(posedge HCLK) disable iff (!HRESETn)
  (HSEL && HTRANS[1]) |-> s_eventually (HREADY);
endproperty
assert property (p_hready_liveness);
 
// 2. Stable control during wait states: while HREADY is low, the
//    address-phase control must not change (the master holds it).
property p_control_stable_in_wait;
  @(posedge HCLK) disable iff (!HRESETn)
  (HTRANS[1] && !HREADY) |=> $stable(HADDR) && $stable(HWRITE) &&
                              $stable(HSIZE) && $stable(HBURST);
endproperty
assert property (p_control_stable_in_wait);
 
// 3. The two-cycle ERROR: HRESP==ERROR with HREADY low must be followed
//    next cycle by HRESP==ERROR with HREADY high.
property p_error_two_cycle;
  @(posedge HCLK) disable iff (!HRESETn)
  (HRESP == ERROR && !HREADY) |=> (HRESP == ERROR && HREADY);
endproperty
assert property (p_error_two_cycle);
 
// 4. Legal HTRANS: a SEQ/BUSY may only occur within a burst (after a
//    NONSEQ, never straight out of IDLE).
property p_seq_only_in_burst;
  @(posedge HCLK) disable iff (!HRESETn)
  (HREADY && HTRANS == IDLE) |=> (HTRANS != SEQ && HTRANS != BUSY);
endproperty
assert property (p_seq_only_in_burst);

The the scoreboard (correctness) and coverage (measure): build them — the scoreboard checks data integrity against a reference model (a shadow memory); functional coverage measures the transfer/burst types, wait counts, responses, crosses. The stimulus is constrained-random (legal, varied) + directed corners; done = coverage closure. So the answer builds the correctness check, the measurement, and the stimulus (see AHB Scoreboards, AHB Coverage, Constrained-Random AHB, UVM AHB Agent). So in practice, verifying an AHB design is building the closed loop — separating legality from correctness and closing coverage. So in practice, know the verification structure (Module 9) and frame the loop. So that's the preparation.

5. System Architecture Perspective

At the interview level, the verification round is the can-you-prove-it test — passing it (framing the loop, separating legality from correctness, closing coverage) proves you can verify AHB (the dominant skill on a chip team), and the separate-the-checks discipline signals methodology (you think systematically, not ad-hoc — the difference between a verification engineer and a test writer).

The the can-you-prove-it test: the design round tests building; the verification round tests proving — can you show it's correct? A strong verification answer (the closed loop, legality/correctness separated, coverage closure) proves you can verify; a weak one (ad-hoc tests, no coverage) reveals you can't (systematically). So at the interview level, the verification round is the can-you-prove-it test. So pass it. So framing the loop proves capability.

The separate-the-checks signals methodology: a test writer writes ad-hoc tests; a verification engineer thinks in the methodology — separating legality (assertions) from correctness (scoreboard), measuring with coverage, closing systematically. So the separate-the-checks discipline signals methodology — systematic over ad-hoc. So at the interview level, how you frame verification signals your level. So separate the checks. So the framing signals methodology. So at the interview level, the verification round is the can-you-prove-it test (passing it proves you can verify AHB) and the separate-the-checks discipline signals methodology (systematic thinking). So the verification round is where you prove you can verify AHB — making framing the closed loop, separating legality from correctness, and closing coverage the keys to proving verification capability and signaling methodology. So frame the loop, separate the checks, close coverage. So the verification round is the methodology bar.

6. Engineering Tradeoffs

Answering a verification question embodies the frame-the-loop, separate-legality-from-correctness, close-coverage approach.

• Frame the loop vs ad-hoc tests. Framing the loop (stimulate → observe → check → measure → close) signals methodology; ad-hoc tests don't scale. Frame the loop.
• Separate legality from correctness. Assertions for protocol rules, a scoreboard for data — different checks. Conflating them is a trap. Separate them.
• Coverage closure vs "I ran some tests". Coverage defines done (every type/cross hit); "I ran tests" can't say done. Define done as coverage closure.
• Constrained-random + directed vs one or the other. Constrained-random gets breadth; directed gets the corners random misses. Use both.

The throughline: verification questions ask you to prove an AHB design correct — by framing the closed loop (stimulate → observe → check legality → check correctness → measure → close). The prompts: assertions, monitor, scoreboard, coverage, constrained-random, UVM agent. The meta-signal: separate legality (assertions) from correctness (scoreboard), define done as coverage closure, and anchor the monitor on the pipeline. The common traps: conflating assertions with the scoreboard, forgetting coverage, a monitor that mispairs data. The verification round is the can-you-prove-it test — passing it proves you can verify AHB, and the separate-the-checks discipline signals methodology.

7. Industry Example

A typical verification round — the interviewer asks how you'd verify an AHB slave.

The interviewer says "how would you verify an AHB-Lite slave?"

• You frame the loop. "I'd build a closed verification loop: stimulate the slave with constrained-random traffic, observe the bus with a monitor, check legality with assertions and correctness with a scoreboard, measure with functional coverage, and close the coverage holes. Let me go through each."
• You separate legality from correctness. "Two different kinds of checking. Legality — the protocol rules — goes in assertions: HREADY eventually goes high so the bus can't hang, the address-phase control is stable while HREADY is low, the ERROR response is the two-cycle pattern, HTRANS sequences are legal. Correctness — the data — goes in a scoreboard against a reference model, a shadow memory: every write I later read back must match, every read must return what I wrote. These catch different bugs — a slave can be protocol-legal but corrupt data, or vice versa." (The #1 framing.)
• You describe the monitor. "A passive monitor samples the bus and reconstructs transactions, anchored on the pipeline — it pairs each HRDATA/HWDATA with the address from one cycle earlier, the captured address, not the live one. It emits transaction objects to the scoreboard and coverage."
• You define coverage. "Functional coverage: bins for each HTRANS type, each burst type, wait-state counts — zero, one, several — both responses, and crosses like burst-type × response, or write/read × wait-count. Coverage closure is how I know I'm done — every meaningful scenario exercised."
• You describe the stimulus. "Constrained-random sequences for breadth — legal, varied addresses, sizes, bursts, with constraints to keep them legal and weighted toward interesting cases. Plus directed tests for corners the random won't reliably hit — back-to-back transfers, max-length bursts, the error path, reset mid-transfer. I'd steer the random with the coverage holes."
• You mention UVM. "I'd package the driver, monitor, and sequencer into a reusable UVM AHB agent — active to drive, passive to just monitor — so the same agent verifies any AHB component."
• The meta-signal. You framed the closed loop, separated legality from correctness, anchored the monitor on the pipeline, and defined done as coverage closure. The interviewer sees you think in the verification methodology.

The example shows the verification round and a strong answer: framed the loop, separated legality from correctness, monitor on the pipeline, coverage closure, avoiding the traps (conflating checks, forgetting coverage, mispairing data). This proves verification capability and signals methodology. This is how you verify an AHB design.

8. Common Mistakes

9. Interview Insight

The verification round is the can-you-prove-it test — framing the closed loop, separating legality from correctness, and defining done as coverage closure are the signals.

The way to carry the verification round: frame the closed loop, separate legality from correctness, and define done as coverage closure. The interviewer is checking whether you can verify AHB systematically — the dominant skill on a chip team. The most valuable framing is to separate the two kinds of checking — legality (the protocol rules, in assertions) from correctness (the data, in a scoreboard against a reference model) — because they catch different bugs and conflating them is the classic tell of ad-hoc thinking. Anchor the monitor on the pipeline (the verification mirror of the RTL capture), measure with functional coverage, and define done as coverage closure — and you'll pass the verification round and signal the methodology the role requires.

10. Practice Challenge

Practice the verification round.

1. The loop. State the closed loop (stimulate → observe → check legality → check correctness → measure → close) and why framing it signals methodology.
2. Legality vs correctness. Explain what assertions check vs what a scoreboard checks — and a bug each catches that the other misses.
3. Coverage. List the functional coverage for an AHB agent (types, waits, responses, crosses) and define done (coverage closure).
4. The monitor. Explain why the monitor must anchor on the pipeline and what goes wrong if it doesn't.
5. Stimulus. Contrast constrained-random (breadth) and directed (corners) and why you need both.

11. Key Takeaways

• Verification questions ask you to prove an AHB design correct — assertions, monitor, scoreboard, coverage, constrained-random, UVM agent.
• Frame the closed loop — stimulate → observe → check legality → check correctness → measure → close. Methodology, not ad-hoc tests.
• Separate legality from correctness (the #1 framing) — assertions check the protocol rules; the scoreboard checks the data against a reference model. They catch different bugs.
• Define done as coverage closure — functional coverage (transfer/burst types, wait counts, responses, crosses) measures what's exercised and defines done.
• Anchor the monitor on the pipeline — pair data with the captured address (a cycle back). A mispairing monitor reconstructs the wrong transaction (the verification mirror of the #1 RTL bug).
• The verification round is the can-you-prove-it test — passing it proves you can verify AHB (the dominant chip-team skill); the separate-the-checks discipline signals methodology.

12. What Comes Next

You can now verify AHB designs. The next chapters cover the specialized rounds:

• Bridge Interview Questions (next) — the AHB-to-APB bridge prompts.
• Arbitration Interview Questions and Tricky Misconceptions — the arbitration-policy prompts and the myths candidates repeat about AHB timing.

To revisit the verification structure these answers build, see Protocol-Checker Mindset, AHB Assertions, AHB Monitors, AHB Scoreboards, and AHB Coverage.