AMBA AHB · Module 21

AHB Verification Checklist

A sign-off checklist for AHB protocol and functional verification. Seven categories: (1) assertions for legality (every protocol rule encoded as an assertion, all passing); (2) a pipeline-anchored monitor (reconstructs transactions, pairing data with the captured address); (3) a scoreboard for correctness (data checked against a reference model); (4) functional coverage closed to target (transfer/burst types, wait counts, responses, crosses); (5) stimulus that is both constrained-random and directed for corners; (6) the corner cases actually exercised (waits, all burst types, the error path, back-to-back, reset); (7) sign-off criteria all met (assertions pass, scoreboard clean, coverage closed, regression green). The heart of it is the split between legality (assertions) and correctness (scoreboard) — both must be present — and coverage closure defines done.

The second checklist is the AHB Verification Checklist: the list to walk before signing off AHB protocol and functional verification. Where the design checklist confirms the RTL is correct, this one confirms the verification is complete — that you've actually proven the design correct, not just run some tests. It has seven categories: (1) assertions for legality — every protocol rule encoded as an assertion, all passing; (2) a pipeline-anchored monitor — reconstructs transactions, pairing data with the captured address; (3) a scoreboard for correctness — data checked against a reference model; (4) functional coverage closed — transfer/burst types, wait counts, responses, crosses, closed to target; (5) stimulus — both constrained-random and directed for corners; (6) corner cases exercised — waits, all burst types, the error path, back-to-back, reset; (7) sign-off criteria — assertions pass, scoreboard clean, coverage closed, regression green. The heart of it is the split between legality (assertions) and correctness (scoreboard) — both must be present — and coverage closure defines done. This chapter walks each item with the check to perform.

1. What Is It?

This checklist is the sign-off list for AHB verification — confirm each before sign-off. The seven categories:

(1) Assertions (legality) — every protocol rule as an assertion (HREADY eventually high, legal HTRANS, stable in waits, two-cycle ERROR), all passing.
(2) Monitor + (3) Scoreboard (correctness) — a pipeline-anchored monitor (pairs data with the captured address); a scoreboard vs a reference model (data integrity).
(4) Coverage (done) + (5) Stimulus — functional coverage closed to target (types/bursts/waits/responses/crosses); constrained-random + directed stimulus.
(6) Corners + (7) Sign-off — corners exercised (waits, bursts, errors, back-to-back, reset); sign-off: assertions pass + scoreboard clean + coverage closed + regression green.

Figure 1 — the AHB verification sign-off checklist, in seven categories. 1. Protocol assertions (legality): every AHB rule encoded as an assertion — HREADY eventually high, legal HTRANS sequences, control stable during waits, the two-cycle ERROR — and they pass. 2. The monitor: a passive monitor reconstructs transactions anchored on the pipeline, pairing data with the captured address, feeding the scoreboard and coverage. 3. The scoreboard (correctness): data checked against a reference model, every write read back and every read returning the expected value. 4. Functional coverage: transfer types, burst types, wait-state counts, responses, and crosses, covered and closed to target. 5. Stimulus: constrained-random for legal varied traffic, plus directed tests for corners. 6. Corner cases exercised: wait states, all burst types, the error path, back-to-back, reset — all hit. 7. Sign-off criteria: assertions pass, the scoreboard is clean, coverage is closed, the regression is green. The key split is legality (assertions) versus correctness (scoreboard) — both must be present; coverage closure defines done.

So the verification checklist confirms you've proven the design correct — systematically, completely, with both kinds of checking and measured coverage. The value is guarding against false confidence: "the tests pass" is not the same as "the design is verified" — which tests? covering what? checking what? The checklist forces the complete picture: legality (assertions) and correctness (scoreboard), measured by coverage, exercised by real stimulus, with explicit sign-off criteria. So this chapter is the verification sign-off. So walk the checklist before declaring done.

The AHB verification checklist (before sign-off): (1) assertions for legality (all pass); (2) a pipeline-anchored monitor; (3) a scoreboard for correctness (vs a reference model); (4) functional coverage CLOSED; (5) stimulus (constrained-random + directed); (6) corners exercised (waits, bursts, errors, back-to-back, reset); (7) sign-off (assertions pass + scoreboard clean + coverage closed + regression green). The heart: legality vs correctness — both required

The AHB verification checklist in one frame: the verification turned into a concrete sign-off — confirm each before declaring done. (1) Assertions (legality): every AHB protocol rule is encoded as an SVA assertion — HREADY eventually high (no hang), legal HTRANS sequences, control stable during waits, the two-cycle ERROR, one-hot HSEL — and they all pass (bound to the bus, firing on any violation). Check: the assertion set is complete and green. (2) Monitor: a passive monitor reconstructs transactions, anchored on the pipeline — pairing each data-phase value with the captured address (a cycle back), not the live one — feeding the scoreboard and coverage. Check: the monitor pairs correctly (else it feeds garbage downstream). (3) Scoreboard (correctness): a scoreboard checks data correctness against a reference model (a shadow memory / golden model) — every write read back correctly, every read returning the expected value. Check: the scoreboard is present, has a reference, and is clean. (4) Functional coverage (done): coverage of transfer types (IDLE/BUSY/NONSEQ/SEQ), burst types (SINGLE/INCR/WRAP*/…), wait-state counts, responses (OKAY/ERROR), and crosses — closed to the target. Check: coverage is closed (this defines done). (5) Stimulus: constrained-random (legal, varied traffic) and directed tests (for corners random misses) — both. Check: stimulus has breadth (random) and corner coverage (directed). (6) Corner cases exercised: wait states (zero, one, several), all burst types, the error path, back-to-back transfers, reset — all hit (not just the happy path). Check: the corners are actually exercised (coverage confirms). (7) Sign-off criteria: all four — assertions pass, scoreboard clean, coverage closed, regression green — or it's not signed off. Check: all four met. The heart: the split between legality (the protocol rules — assertions) and correctness (the data — scoreboard) — both must be present (they catch different bugs); and coverage closure defines done.

2. Why Does It Exist?

This checklist exists because "tests pass" is not "verified" (passing some tests under-claims completeness) — and because legality and correctness are different (you need both checks, and it's easy to have only one) — and because coverage is what makes "done" defensible (without it, done is a guess).

The "tests pass" is not "verified" is the root: running tests and seeing them pass tells you the scenarios you ran worked — but not which scenarios, covering what, checking what. So "tests pass" under-claims. A checklist forces the complete picture (assertions and scoreboard and coverage). So this checklist exists to distinguish "verified" from "tests pass". So passing isn't proof. So check completeness.

The legality vs correctness is the key split: a design can be protocol-legal but corrupt data (passes assertions, fails scoreboard) or correct data but protocol-illegal (passes scoreboard, fails assertions) — different bugs, different checks. It's easy to have only one (only assertions, or only a scoreboard) — a hole. So the checklist forces both. So this checklist exists to ensure both checks. So separate and require both. So cover both kinds.

The coverage makes "done" defensible is the closure: without coverage, "done" is "I ran a lot of tests" — a guess. Coverage closure makes "done" defensible ("every meaningful scenario was exercised"). So the checklist requires coverage closure. So this checklist exists to make "done" defensible. So measure to close. So this checklist exists because: "tests pass" is not "verified" (passing under-claims — the root); legality and correctness are different (need both, easy to miss one — the split); and coverage makes "done" defensible (else it's a guess — the closure). So the AHB verification checklist is the verification sign-off — ensuring legality and correctness and coverage closure before declaring done. So this chapter is the verification sign-off. So walk it before sign-off.

3. Mental Model

Model the verification checklist as a restaurant health inspection sign-off. A passing inspection isn't "the food tasted fine" — it's a complete checklist with two distinct kinds of check and a coverage requirement. The inspector verifies code compliance (the rules: temperatures, hand-washing stations, labeling — like assertions for protocol legality) AND verifies the food is actually safe (samples tested against safe limits — like a scoreboard checking data correctness). And they track that every area was inspected — kitchen, storage, prep, service — against the full plan (like coverage closure), so nothing is skipped. The sign-off requires all of it: rules met, samples clean, every area covered. "The food tasted fine" is not a sign-off — and neither is "the AHB tests passed." Verification sign-off is: assertions pass (legality), the scoreboard is clean (correctness), and coverage is closed (every scenario covered).

A restaurant health inspection sign-off. A passing inspection isn't "the food tasted fine" ("the tests passed") — it's a complete checklist with two distinct kinds of check and a coverage requirement. The inspector verifies code compliance — the rules: temperatures, hand-washing stations, labeling (like assertions for protocol legality) — AND verifies the food is actually safe — samples tested against safe limits (like a scoreboard checking data correctness). And they track that every area was inspected — kitchen, storage, prep, service — against the full plan (like coverage closure), so nothing is skipped. The sign-off requires all of it: rules met, samples clean, every area covered. "The food tasted fine" is not a sign-off — and neither is "the AHB tests passed." Verification sign-off is: assertions pass (legality), the scoreboard is clean (correctness), and coverage is closed (every scenario covered).

This captures the checklist: "the food tasted fine" not being a sign-off = "tests pass" not being "verified"; verifying code compliance (the rules) = assertions for legality; verifying the food is actually safe (samples) = the scoreboard for correctness; tracking every area inspected against the plan = coverage closure; the sign-off requiring all of it = the four sign-off criteria; two distinct kinds of check = the legality/correctness split. A real sign-off checks the rules (legality) AND the substance (correctness), tracks complete coverage (closure), and requires all of it — "it seemed fine" is not enough.

Here is the heart of it — the legality/correctness split:

Both checks on one transaction: assertions (legality) + scoreboard (correctness)

4 cycles

Figure 2 — the heart of the verification checklist: legality vs correctness, two checks for different bugs. The trace shows a transaction the monitor reconstructs (pipeline-anchored: it pairs the data D0 with the captured address A0, a cycle back). That transaction feeds two independent checks: the assertions check legality (was the protocol obeyed — HREADY behavior, HTRANS legal, the response well-formed?), and the scoreboard checks correctness (is D0 the right value for A0, per the reference model?). A design can pass one and fail the other, so both are required. The checklist confirms both are present and passing, plus coverage closed.

The model's lesson: a real sign-off checks the rules (legality) AND the substance (correctness), tracks complete coverage (closure), and requires all of it — "it seemed fine" is not enough. In the figure, one transaction feeds two independent checks — assertions (legality) and the scoreboard (correctness) — and the checklist confirms both are present and passing, plus coverage closed. That's verification, not "tests pass".

4. Real Hardware Perspective

The substance behind each check is the verification structure from the verification module — so each checklist item maps to a chapter, and the check confirms that component.

The assertions, monitor, scoreboard: the checks — (1) assertions for every rule (legality); (2) a pipeline-anchored monitor; (3) a scoreboard vs a reference (correctness). So the checklist confirms the assertion, monitor, and scoreboard structure (see AHB Assertions, AHB Monitors, AHB Scoreboards, Protocol-Checker Mindset). So they're the checking components. So confirm legality + correctness.

Figure 3 — the key verification split: legality vs correctness. Legality, checked by assertions: they encode the protocol rules (HREADY eventually high, control stable during waits, the two-cycle ERROR, legal HTRANS) and fire on any rule violation — checking the design obeys the bus protocol. Correctness, checked by the scoreboard: it compares observed data against a reference model, confirming every write is read back and every read returns the expected value — checking the data is right. These catch different, independent bugs: a design can be protocol-legal but corrupt data (passes assertions, fails the scoreboard), or return correct data while violating timing (passes the scoreboard, fails assertions). So you need both, kept separate. A checklist with only assertions, or only a scoreboard, has a hole; sign-off requires both plus coverage closure.

The coverage, stimulus, corners, sign-off: the checks — (4) coverage closed; (5) constrained-random + directed stimulus; (6) corners exercised; (7) the four sign-off criteria. So the checklist confirms the coverage, stimulus, and closure structure (see AHB Coverage, Constrained-Random AHB, UVM AHB Agent, AHB Verification Questions). So in practice, the verification checklist is the verification components turned into checks — confirm each before sign-off. So in practice, know the components and check them. So that's the sign-off.

5. System Architecture Perspective

At the verification-process level, the checklist defines done — it replaces the vague "tests pass" with a concrete, defensible sign-off (the four criteria), standardizes verification quality, and makes coverage closure the contract for completeness.

The it defines done: without the checklist, "done" is subjective ("I ran tests, they pass"). With it, "done" is concrete: assertions pass, scoreboard clean, coverage closed, regression green. So at the process level, the checklist defines done objectively. So it's the done-criteria. So define done concretely.

The coverage closure is the contract: the most important "done" element is coverage closure — it's the measurable contract that every meaningful scenario was exercised. So signing off requires closure (not "enough tests"). So at the process level, coverage closure is the completeness contract. So close coverage. So it's the contract. So at the verification-process level, the checklist defines done (the four concrete criteria, replacing "tests pass") and makes coverage closure the contract for completeness. So the checklist is where "verified" gets a concrete, defensible meaning — making the four sign-off criteria (especially coverage closure) the keys to a real sign-off. So define done by the criteria, and close coverage. So the checklist defines done.

6. Engineering Tradeoffs

Using the verification checklist embodies the both-checks, coverage-closure, exercise-the-corners discipline.

Both checks vs one. Assertions (legality) and a scoreboard (correctness) catch different bugs; only one leaves a hole. Require both.
Coverage closure vs "tests pass". Coverage closure defines done; "tests pass" can't claim completeness. Close coverage.
Constrained-random + directed vs one. Random gives breadth; directed gets the corners random misses. Use both.
Exercise corners vs the happy path. Actually exercising the corners (waits, errors, bursts, back-to-back, reset — confirmed by coverage) catches corner bugs; the happy path alone misses them. Hit the corners.

The throughline: the AHB verification checklist turns verification into a concrete sign-off — seven categories: (1) assertions (legality, all pass), (2) monitor (pipeline-anchored), (3) scoreboard (correctness, vs a reference), (4) coverage (closed), (5) stimulus (constrained-random + directed), (6) corners (exercised), (7) sign-off (assertions pass + scoreboard clean + coverage closed + regression green). The heart: the legality/correctness split (both required) and coverage closure defines done. At the process level, it defines done and makes coverage closure the completeness contract.

The verification gaps to avoid: having only assertions OR only a scoreboard (legality and correctness catch different bugs — need both), a monitor that mispairs data (pipeline-anchor it), claiming done without coverage closure (that's a guess), only constrained-random OR only directed (need both), and not exercising the corners (waits, errors, bursts, back-to-back, reset). Sign-off = assertions pass + scoreboard clean + coverage closed + regression green — all four

The verification gaps the checklist guards against — the holes that make "verified" a false claim: (1) Only one kind of check. Having only assertions (legality) or only a scoreboard (correctness) is the classic gap — they catch different, independent bugs. A protocol-legal design can corrupt data (assertions pass, scoreboard would catch it — if you had one); a data-correct design can violate timing (scoreboard passes, assertions would catch it). Require both. (2) A mispairing monitor. A monitor that pairs data with the live (not captured) address reconstructs the wrong transaction, so the scoreboard checks against the wrong address — false passes/fails. Pipeline-anchor the monitor (pair data with the captured address). (3) "Done" without coverage closure. Claiming verification complete without coverage closure is a guess — you've run tests, but which scenarios? Coverage closure (every meaningful bin/cross hit) is what makes "done" defensible. Close coverage. (4) Only one stimulus type. Only constrained-random misses specific corners (rare crosses); only directed lacks breadth. Use both — random for breadth, directed (or coverage-steered random) for corners. (5) Corners not exercised. The happy path passing is not enough — the corners (wait states, all burst types, the error path, back-to-back, reset) must be actually exercised (and coverage confirms they were). Hit the corners. (6) No reference model. A scoreboard needs a reference (shadow memory / golden model) to check against — without one, it checks nothing. Give it a reference. The sign-off rule: all four — assertions pass, scoreboard clean, coverage closed, regression green — or it's not signed off. Any one missing is a hole. (See AHB Assertions, AHB Scoreboards, and AHB Coverage.)

7. Industry Example

A concrete walk — signing off the verification of an AHB slave.

A verification engineer finishes the testbench for an AHB slave and walks the checklist before declaring verification complete.

(1) Assertions. They confirm the protocol checker is bound to the bus, with assertions for HREADY-eventually-high, stable control in waits, the two-cycle ERROR, and legal HTRANS — and the regression shows them all passing. ✓ (Legality covered.)
(2) Monitor. They verify the monitor is pipeline-anchored — it registers the address phase and pairs data with the captured address, not the live one — feeding correct transactions to the scoreboard and coverage. ✓
(3) Scoreboard. They confirm the scoreboard checks data against a shadow-memory reference model: every write is read back correctly, every read matches. The scoreboard is clean. ✓ (Correctness covered.)
(4) Coverage. They check the functional coverage report: transfer types, burst types, wait-state counts, responses, and the key crosses (burst-type × response, direction × wait-count) are all closed to target. ✓ (Done is defensible.)
(5) Stimulus. Constrained-random sequences provide breadth; directed tests cover specific corners (max-length bursts, the error path, back-to-back, reset mid-transfer). ✓
(6) Corners. They confirm — via coverage — that wait states (0/1/several), all burst types, the error path, back-to-back transfers, and reset were all actually exercised, not just the happy path. ✓
(7) Sign-off. All four criteria met: assertions pass, scoreboard clean, coverage closed, regression green. They sign off — verification is genuinely complete, not just "tests pass."
The result. Walking the checklist surfaced one gap (a burst-type × error cross that was unhit); they added a directed test to close it, then re-checked. The checklist did its job: guarding against a false "done."

The example shows the checklist in use: a thorough walk confirming both kinds of checking, closed coverage, and exercised corners — and catching a coverage hole before sign-off. This is how you sign off AHB verification.

8. Common Mistakes

9. Interview Insight

The verification checklist shows verification rigor — being able to list what makes verification complete (not just "tests pass") signals you understand verification methodology.

Figure 4 — the AHB verification checklist in one card: (1) assertions (legality) all pass; (2) a pipeline-anchored monitor; (3) a scoreboard (correctness) vs a reference; (4) functional coverage CLOSED (types/bursts/waits/responses/crosses); (5) stimulus (constrained-random + directed); (6) corners exercised (waits, bursts, errors, back-to-back, reset); (7) sign-off (assertions pass + scoreboard clean + coverage closed + regression green). The heart: legality (assertions) vs correctness (scoreboard) — both required; coverage closure defines done. Takeaway: the checklist makes verification sign-off concrete, with the legality-vs-correctness split at its heart.

If asked what makes AHB verification complete (or what you'd check before sign-off), recite the checklist: (1) assertions for legality (all pass), (2) a pipeline-anchored monitor, (3) a scoreboard for correctness (vs a reference model), (4) functional coverage closed, (5) constrained-random + directed stimulus, (6) the corners exercised, (7) the four sign-off criteria (assertions pass + scoreboard clean + coverage closed + regression green). Stress the legality/correctness split (both required — they catch different bugs) and that coverage closure defines done (not "tests pass"). That signals you understand verification methodology — that "verified" means systematically proven complete, not anecdotally tested.

10. Practice Challenge

Practice the verification sign-off.

The seven categories. List them (assertions, monitor, scoreboard, coverage, stimulus, corners, sign-off) and the check for each.
Legality vs correctness. Explain the split (assertions vs scoreboard) and a bug each catches that the other misses.
Coverage closure. Explain why coverage closure defines done (and "tests pass" doesn't).
The monitor. Explain why the monitor must be pipeline-anchored, and what a mispairing monitor breaks.
The four criteria. State the sign-off criteria (assertions pass + scoreboard clean + coverage closed + regression green) and why all four.

11. Key Takeaways

The AHB verification checklist turns verification into a concrete sign-off — confirm each item before declaring done.
Seven categories — (1) assertions (legality), (2) monitor (pipeline-anchored), (3) scoreboard (correctness), (4) coverage (closed), (5) stimulus (random + directed), (6) corners (exercised), (7) sign-off (four criteria).
The heart is the legality/correctness split — assertions check the protocol rules; the scoreboard checks the data (vs a reference model). They catch different bugs — both required.
Coverage closure defines done — functional coverage (types/bursts/waits/responses/crosses) closed to target. "Tests pass" is not "verified."
"Tests pass" ≠ "verified" — verified = assertions pass + scoreboard clean + coverage closed + regression green. All four, or it's a hole.
It defines done — a standardized, defensible sign-off (replacing vague "tests pass"), with coverage closure as the completeness contract.

12. What Comes Next

You can now sign off AHB verification. The remaining checklists cover integration and review:

AHB Integration Checklist (next) — the sign-off list for wiring AHB into a fabric/SoC.
Waveform, Interview, and Common Mistakes checklists — the rest of the sign-off lists.

To revisit the verification structure these checks confirm, see AHB Assertions, AHB Monitors, AHB Scoreboards, AHB Coverage, and AHB Verification Questions.