AMBA AXI · Module 18

AXI Verification Interview Questions

Answer AXI verification prompts — how you'd verify a slave, what goes in the checker vs. the scoreboard, the compliance-vs-correctness split, coverage closure, the UVM AXI agent, and buy-vs-build VIP — with the layered mental model (assertions, monitor, scoreboard, coverage) that turns any 'how would you verify X' question into a structured answer.

Where design questions (18.5) ask you to build AXI RTL, verification questions ask how you'd prove it correct — "how would you verify an AXI slave?", "what's the difference between an assertion and a scoreboard?", "how do you know you're done?". They test whether you hold the layered verification model (assertions, monitor, scoreboard, coverage) and the two ideas that organize it: compliance vs. correctness and checking vs. coverage. The strong answer to any "how would you verify X" prompt isn't a list of tools — it's the structured model: assertions for protocol legality, a monitor to reconstruct transactions, a scoreboard for functional correctness against a reference, and coverage to prove the scenarios were exercised. This chapter gives that model and the verification prompts it answers.

1. The Layered Verification Model

The answer to almost every AXI verification question is the same four-layer model, each layer with a distinct job. Assertions (SVA) check protocol legality per cycle (handshake, stability, encoding). Monitor passively reconstructs transactions from beats. Scoreboard checks functional correctness (data, ordering) against a reference model. Coverage measures whether the scenarios were exercised. Knowing this model — and which layer answers which concern — turns any "how would you verify X" into a structured answer rather than a tool list.

Figure 1 — the four-layer AXI verification model, the answer to almost every verification prompt. Assertions check protocol legality per cycle; the monitor passively reconstructs transactions from beats; the scoreboard checks functional correctness against a reference model; coverage measures whether the scenarios were exercised. Each layer has a distinct job, and a strong verification answer maps the question to the right layer(s) rather than listing tools — assertions for legality, scoreboard for correctness, coverage for completeness.

2. The Two Organizing Ideas: Compliance vs. Correctness, Checking vs. Coverage

Two distinctions organize the whole model and are probed constantly. Compliance vs. correctness: assertions prove the traffic is legal AXI (compliance); the scoreboard proves the design does the right thing (correctness) — a slave can be perfectly compliant and return wrong data, so you need both. Checking vs. coverage: checks (assertions/scoreboard) decide correctness when a scenario occurs; coverage measures whether it occurred — a perfect check never triggered protects nothing. Stating these two splits crisply is the signal that you understand verification as a system, not a pile of tools.

Figure 2 — the two organizing distinctions of AXI verification. Compliance vs. correctness: assertions prove legal traffic (compliance), the scoreboard proves the right behavior (correctness) — a compliant slave can still return wrong data, so both are needed. Checking vs. coverage: checks decide correctness when a scenario occurs, coverage measures whether it occurred — a check never triggered protects nothing. These two splits organize the four layers and are the distinctions interviewers probe most.

3. "How Would You Verify an AXI Slave?" — The Structured Answer

The canonical verification prompt. The structured answer walks the layers: (1) Protocol compliance — attach assertions (or a VIP) checking the handshake, payload stability, and legal encodings on every channel. (2) Reconstruct — a passive monitor assembling transactions by ID. (3) Functional correctness — a scoreboard with a reference memory model (apply WSTRB byte-wise), checking write-then-read data integrity and per-ID ordering, plus end-of-test checks for dropped transactions. (4) Stimulus + coverage — constrained-random traffic (legal by construction) driven to coverage closure across burst types/lengths/IDs/responses, plus negative tests for error responses. (5) Sign-off — clean assertions + closed coverage + scoreboard passing. This layered walk is the answer.

Figure 3 — the structured answer to 'how would you verify an AXI slave.' Protocol compliance (assertions/VIP) → reconstruct (passive monitor by ID) → functional correctness (scoreboard with WSTRB-aware reference memory, data integrity, per-ID ordering, end-of-test dropped-transaction checks) → stimulus + coverage (constrained-random to closure, plus negative tests) → sign-off (clean assertions + closed coverage + passing scoreboard). Walking the layers in order is the structured answer that beats a tool list.

4. UVM Agent, Coverage Closure, and Buy-vs-Build

Three more verification prompts round out the round. "What's the UVM AXI agent?" — the reusable unit bundling sequencer + driver + monitor for one interface, configurable active (drive+observe) or passive (observe-only), exporting transactions via an analysis port; checking lives at the env level. "How do you know you're done / coverage closure?" — when every meaningful coverage bin is hit (burst types/lengths/IDs/responses/corners) or justified as unreachable, with assertions clean and the scoreboard passing — coverage answers "did we test it?", checks answer "was it right?". "Build or buy VIP?" — buy for complex standard protocols (full AXI — the compliance layer is exhaustive vendor work); build for simple/custom interfaces or to learn; a VIP is a pre-verified agent + checker + coverage, and still needs your functional scoreboard.

Figure 4 — three more verification prompts. The UVM agent: sequencer + driver + monitor for one interface, active or passive, checking at the env level. Coverage closure / done: every meaningful bin hit or justified, assertions clean, scoreboard passing — coverage answers 'did we test it', checks answer 'was it right'. Buy-vs-build VIP: buy for complex standard protocols (exhaustive vendor compliance layer), build for simple/custom; a VIP is a pre-verified agent+checker+coverage but still needs your functional scoreboard.

5. Common Misconceptions

Myths to unlearn

"Verifying AXI is just attaching a protocol checker." A protocol checker proves compliance (legal traffic), not correctness (right data/behavior). A compliant slave can return wrong data — you also need a scoreboard against a reference. Compliance ≠ correctness.
"If the assertions pass, it's verified." Passing assertions means no protocol violation — but says nothing about functional correctness or whether the right scenarios were exercised. "Verified" needs clean assertions and a passing scoreboard and closed coverage.
"Coverage and checking are the same thing." Orthogonal: checking (assertions/scoreboard) decides correctness when a scenario occurs; coverage measures whether it occurred. A perfect check never triggered protects nothing; 100% coverage with weak checks proves you ran cases, not that they passed.
"100% coverage means bug-free." Coverage measures exercise, not correctness — and only of the scenarios you defined. 100% coverage with a passing scoreboard is strong evidence; 100% coverage alone, or with an incomplete coverage model, is not.
"The scoreboard checks protocol; the assertions check data." Backwards. Assertions check the per-cycle protocol (handshake/stability/encoding); the scoreboard checks functional data/ordering against a reference. Mixing up which layer does what signals you don't hold the model.
"A VIP verifies your design." A VIP provides the compliance layer (pre-verified assertions + coverage + agent) and stimulus — it does not verify your design's functional correctness, which still needs your scoreboard/reference model. A VIP is a powerful component, not a complete verification.

6. Debugging Insight

🔍 Debugging insight — a weak verification answer collapses a layer or a distinction

Diagnose a weak verification answer by what it conflated:

"Just attach a checker" (no scoreboard). Collapsed compliance into correctness — the most common miss. Fix: state that the checker proves legality, and a scoreboard against a reference proves the design does the right thing; both are needed.
"Assertions passing = done." Ignored coverage and correctness. Fix: done = clean assertions + passing scoreboard + closed coverage; name all three.
Conflated coverage with checking. "We hit 100% coverage so it works." Fix: coverage = did-we-test-it; checks = was-it-right; both required.
Put checking inside the agent. Misunderstood the agent's role. Fix: the agent drives/observes and exports transactions; the scoreboard/coverage at the env level do the checking.
"A VIP verifies it." Over-trusted the VIP. Fix: a VIP gives compliance + stimulus + coverage; functional correctness still needs your scoreboard.
Listed tools instead of a model. "We'd use UVM, SVA, coverage..." with no structure. Fix: walk the four layers (assertions → monitor → scoreboard → coverage) mapped to the concerns (legality, reconstruct, correctness, completeness).

The meta-skill: a strong verification answer holds the four-layer model and the two distinctions (compliance/correctness, checking/coverage) and maps the question to them. A weak answer collapses a layer (no scoreboard), conflates a distinction (coverage = correctness), or lists tools without the model — diagnose which and restore the structure.

7. Verification Insight

✅ Interview insight — hold the four-layer model and the two distinctions, and map every question to them

Verification prompts test whether you hold a mental model, not a tool list — and the model is four layers (assertions → monitor → scoreboard → coverage) organized by two distinctions (compliance vs. correctness, checking vs. coverage). The winning approach to any verification question is to map it to the model: "how would you verify an AXI slave?" → walk the layers (compliance assertions, monitor reconstruction, scoreboard with a WSTRB-aware reference and per-ID ordering, constrained-random stimulus to coverage closure, plus negative tests, then sign-off); "what's the difference between an assertion and a scoreboard?" → compliance (legal traffic, per cycle) vs. correctness (right behavior, against a reference); "how do you know you're done?" → clean assertions + passing scoreboard + closed coverage, because coverage answers did-we-test-it and checks answer was-it-right; "what's the UVM agent?" → the reusable seqr/drv/mon unit, active/passive, checking at the env level; "buy or build VIP?" → buy for complex standard protocols (the compliance layer is exhaustive vendor work), build for simple/custom, and a VIP still needs your functional scoreboard. The two distinctions are the most-probed because they're where shallow answers collapse: compliance ≠ correctness (a compliant slave can return wrong data, so a checker alone isn't verification) and checking ≠ coverage (a check never triggered protects nothing, so coverage closure is required). Stating these crisply signals you understand verification as a system. The connection to the job is direct: building a real AXI verification environment is assembling these four layers with these two distinctions in mind, so the interview answer and the actual verification plan are the same structure — which is why holding the model matters more than naming tools (anyone can say "UVM" and "SVA"; the signal is knowing which layer answers which concern and why). This is the verification-side complement to the design round (18.5): design produces the RTL, verification proves it correct, and a strong candidate can do both — describe how they'd build a slave and how they'd prove it works, mapping each to its structured model. The deeper through-line of Module 18 holds: articulating the model (not reciting tools) is the skill, and in the verification round the model is the four layers and two distinctions, applied to whatever "how would you verify X" the interviewer asks. Next, performance questions test reasoning about bandwidth, latency, and bottlenecks.

8. Interview Questions

9. Summary

Verification questions test whether you hold the layered verification model rather than a tool list: four layers — assertions (protocol legality per cycle), monitor (reconstruct transactions), scoreboard (functional correctness vs. a reference), coverage (scenarios exercised) — organized by two distinctions: compliance vs. correctness (assertions prove legal traffic, the scoreboard proves right behavior — a compliant slave can return wrong data, so both are needed) and checking vs. coverage (checks decide correctness when a scenario occurs, coverage measures whether it occurred — both required). The structured answer to "how would you verify an AXI slave?" walks the layers: compliance assertions → passive monitor → scoreboard with a WSTRB-aware reference and per-ID ordering → constrained-random stimulus to coverage closure plus negative tests → sign-off (clean assertions + passing scoreboard + closed coverage).

Three more prompts: the UVM agent (reusable seqr/drv/mon, active/passive, checking at the env level), coverage closure / "done" (every meaningful bin hit or justified, with checks passing), and buy-vs-build VIP (buy for complex standard protocols — exhaustive vendor compliance layer; build for simple/custom; a VIP still needs your functional scoreboard). The most-probed distinctions are compliance≠correctness and checking≠coverage, where shallow answers collapse. The model is complete for an interface's contract in simulation — the senior caveats are coverage-model completeness, system-level properties (deadlock/ordering/performance), reference-model independence, formal for provable properties, and monitor self-verification. Verification is the complement to design (18.5): the same models, mental and otherwise, viewed from the prove-side; a strong candidate articulates both building a slave and proving it correct. Next, performance questions test reasoning about bandwidth, latency, and bottlenecks.

10. What Comes Next

You can now describe how to verify AXI; next, reasoning about its performance:

18.7 — Performance Interview Questions (coming next) — bandwidth, latency, and bottleneck prompts, where you reason quantitatively about throughput and where it's lost.

Previous: 18.5 — Design Interview Questions. Related: 16.1 — The Protocol-Checker Mindset for compliance vs. correctness, 16.4 — AXI Scoreboards for the correctness layer, and 16.8 — UVM AXI Agent Overview for the agent.