Verification Review Checklist

Module 21 · Chapter 21.3 · CHI Design-Review Checklist

Project thread — 21.2 reviewed the RTL. 21.3 reviews the verification that proves it; 21.4 reviews performance.

1. The Review

The verification review is a completeness pass over a CHI block's testbench — reading it as a proof of correctness, not as a set of passing runs. A green regression is ambiguous: it can mean the design is verified, or that the testbench stimulates without checking. Only a review of the verification itself — its checkers, scoreboard, coverage, and stimulus — can tell the two apart. This review makes that distinction before tapeout, when it still matters.

2. When To Run It

Run the verification review at the DV-completeness gate — when the testbench is built and the regression is passing, but before the block is declared verified.

• Trigger: the DV environment is complete and the regression is green.
• Precondition: coverage reports, the assertion list, and the scoreboard architecture exist as artifacts.
• Output: a verified sign-off, or a list of verification gaps (missing checks, coverage holes) to close.
• Cost of skipping: an unverified corner ships — a bug the suite could have caught but never checked reaches silicon.

3. Key Terms

4. Previous Chapter Connection

This review verifies what 21.2 built. The protocol rules (Chapters 6–10) become assertions; the coherence model (Chapters 4, 8) becomes the scoreboard reference; the hazards, ordering, exclusives, and DVM (Chapters 9–12) become coverage and corner-case scenarios; the debugging knowledge (Module 18) informs what to check.

Where 21.1 asked "is it right?" and 21.2 "is it built cleanly?", 21.3 asks "have we proven it?" — and proof is harder than it looks, because a testbench that runs everything but checks nothing passes exactly like one that proves everything. This review supplies the completeness discipline: coverage that measures the right things, checkers that actually check, and a closure argument — the difference between a suite that looks thorough and one that is.

5. How To Use This Checklist

The method — audit checking, not just passing.

1. Separate stimulus from checking. For each area, ask what verifies the behavior — an assertion, a scoreboard compare — not merely what drives it. No checker, no credit.
2. Walk the seven areas (sections 7–13). Each - [ ] box is ticked against a coverage report, an assertion, or a scoreboard, never against a passing count alone.
3. Read coverage for holes — an unhit point is an unverified scenario, not a formality.
4. Log gaps as verification issues — a missing check or an open hole blocks sign-off.
5. Re-review after RTL or spec change — new behavior needs new coverage and checks, or it is silently unverified.

6. The Review Areas

The seven areas of a CHI verification review, and what each protects.

Each area below is a checklist plus the why. A tick means something checked it — not that a test ran.

7. Checklist — Coverage Model

• The functional coverage model enumerates the coherence states, transactions, and channels that matter (Chapters 4, 7).
• Cross-coverage captures the interactions — state × transaction, requester × responder, snoop × access.
• Coverage measures behavior verified, not just lines executed — code coverage is necessary, not sufficient.
• The model is reviewed against the spec — no protocol feature is absent from the coverage plan.
• Illegal / should-never-happen bins exist and are expected empty — hitting one is a bug.

Why. The coverage model defines what "done" means. A model that omits a scenario makes it invisible — the suite can be 100% on a model that never mentions the bug's condition, so a weak model is a blind spot disguised as thoroughness.

8. Checklist — Protocol Checkers & Assertions

• Every protocol rule (channel handshakes, ordering, response legality) has an assertion (Chapters 6–10).
• Assertions run on every interface, every cycle — not just in directed tests.
• Illegal transitions and responses are actively asserted against, not merely absent from stimulus.
• The assertion set is reviewed for gaps — a rule with no assertion is a rule nothing enforces.
• Assertions fire in a fault-injection / bug-seeding check — a silent assertion may be mis-coded.

Why. Assertions are the always-on protocol police (Module 18). A missing assertion means a violation passes silently; a mis-coded one gives false assurance — so the review must confirm assertions exist and actually fire.

9. Checklist — Scoreboard & Data Integrity

• A scoreboard checks observed data against an expected value from a coherence reference model (Chapters 4, 8).
• End-to-end data integrity is verified — every read returns the last write per the coherence model.
• The scoreboard handles out-of-order completion and reordered responses correctly (Chapter 9).
• Coherence-specific checks exist — a stale copy, a lost update, a missed invalidation is caught.
• The reference model is independent of the DUT — not the same logic checking itself.

Why. The scoreboard is what makes a run a proof (Chapter 21.3's whole point). Without a checking scoreboard, the testbench is a stimulus generator — it exercises the DUT but verifies nothing, the essence of the hollow pass.

10. Checklist — Stimulus & Randomization

• Constrained-random stimulus reaches the coverage targets — randomization is directed by coverage feedback.
• Directed tests exist for the hard corners random is unlikely to hit (rare interleavings, deadlock setups).
• Multi-agent, concurrent traffic is generated — coherence bugs need contention, not one requester at a time.
• Constraints do not accidentally exclude legal scenarios — a hidden constraint is a hidden hole.
• Stimulus spans the address, transaction, and QoS space the design must handle.

Why. Stimulus decides what gets exercised (Module 15/18 corners). Coverage can only close on scenarios stimulus reaches — and an over-tight constraint silently removes a scenario, leaving a hole coverage may not even show.

11. Checklist — Corner Cases & Coherence Scenarios

• Address hazards (overlapping in-flight to one line) are explicitly generated and checked (Chapter 10).
• Snoop-vs-access races and concurrent-writer scenarios are covered (Chapters 8–10).
• Deadlock / near-deadlock setups are exercised and shown to resolve (Chapters 13–14).
• Retry, forward, and cancel paths are covered — not just the happy path.
• Ownership transfer and cache-to-cache scenarios are checked for data and state correctness.

Why. These are where coherence actually breaks (Module 18). The happy path is easy and rarely wrong; the races and hazards are the real risk — so a suite that skips them is unverified exactly where it matters most.

12. Checklist — DVM, Exclusives & RAS Coverage

• DVM operations (TLB maintenance, sync) are generated and checked for completeness (Chapter 12).
• Exclusive / atomic sequences — including failing and contended cases — are covered (Chapter 11).
• RAS paths (poison, error responses, containment) are injected and their handling verified.
• CMO (cache-maintenance) operations are checked for exact clean/invalidate effect (Chapter 11).
• These system-level features have dedicated coverage — not assumed covered by generic traffic.

Why. DVM, exclusives, and RAS are low-frequency, high-consequence (Chapters 11–12). Generic random traffic rarely exercises them, so without dedicated coverage they are effectively unverified — and their failures are severe (broken sync, uncontained faults).

13. Checklist — Coverage Closure & Sign-off Metrics

• Functional coverage is closed — every bin hit or explicitly justified as unreachable.
• Unreachable points are reviewed and waived with a reason — not auto-excluded to inflate the number.
• Code and assertion coverage are also closed — dead code and never-triggered assertions are investigated.
• The bug-discovery curve has flattened — new tests stop finding new bugs (a maturity signal).
• Closure is measured on a reviewed coverage model (area 7) — 100% of a weak model is not done.

Why. Closure is the sign-off metric — and the easiest to fake. A 100% number on a thin model, or with holes waived to hit a target, is hollow. Real closure is full coverage of a reviewed model, with a flattened bug curve.

14. A Worked Review

Applying the checklist to a snoop-filter DUT's testbench.

1. Scoreboard (9). The env drives reads/writes and the regression is green — but there is no coherence reference model; nothing checks a read returns the last write. Finding: stimulus without checking — a hollow pass. Blocking issue.
2. Coverage Model (7). States and transactions are binned; cross-coverage of snoop × concurrent-write is missing. Finding: a blind spot. Blocking issue.
3. Assertions (8). Channel-handshake assertions exist and fire under bug-seeding. Tick.
4. Corners (11). Directed snoop-vs-write race tests exist and are checked. Tick (after the scoreboard is added).
5. DVM/RAS (12). No poison-injection coverage. Finding: RAS unverified. Blocking issue.
6. Closure (13). "98%" — but on the incomplete model of area 7, with holes waived. Finding: hollow closure.

The review found a green regression that verified almost nothing — no scoreboard, missing crosses, no RAS. Passing was hiding unverified. Every finding is a bug the suite could catch but never checked.

15. Sign-off Criteria

What "the block is verified" actually means.

• All seven areas walked, each ticked against a checker, assertion, or coverage report — not a pass count.
• A checking scoreboard with an independent reference model verifies data end to end.
• Every protocol rule has an assertion, and assertions are shown to fire.
• Functional coverage is closed on a reviewed model, with all waivers justified.
• The bug curve has flattened, and every verification gap is closed before sign-off.

16. The Pitfall

17. Common Mistakes & Red Flags

• Stimulus without checking. Assumption: it runs, it works. Bug: hollow pass (the Pitfall). Fix: a checking scoreboard.
• Code coverage as proof. Assumption: 100% lines = verified. Bug: executed ≠ checked. Fix: functional coverage + checks.
• Thin coverage model. Assumption: high % = done. Bug: blind spots. Fix: review the model vs spec.
• Waiving holes to hit a target. Assumption: close the number. Bug: unverified scenarios. Fix: justify every waiver.
• Assuming assertions fire. Assumption: they exist, so they check. Bug: silent/mis-coded SVA. Fix: bug-seed to confirm firing.
• Red flag — no reference model. The scoreboard checks the DUT against itself; add an independent model.
• Red flag — no RAS/DVM coverage. System features unverified; add dedicated coverage.
• Red flag — "100%" with a flat bug curve you never plotted. Prove maturity, do not assume it.

18. Quick Revision

Verification Review Checklist. A DV-completeness pass over a CHI testbench, reading it as a proof of correctness, not a set of passing runs — because a green regression is ambiguous: it can mean verified, or stimulated but never checked, and only a review of the verification itself tells them apart. Run it when the env is built and the regression is green, with coverage reports, the assertion list, and the scoreboard architecture as evidence. Walk seven areas, each ticked against a checker, assertion, or coverage report (never a pass count): Coverage Model (states/transactions/crosses, reviewed vs spec, Chapters 4/7); Protocol Checkers & Assertions (a rule per assertion, shown to fire, Chapters 6–10); Scoreboard & Data Integrity (independent reference model, end-to-end data, Chapters 4/8); Stimulus & Randomization (reaches corners, concurrent traffic, no hidden constraints); Corner Cases & Coherence Scenarios (hazards, races, deadlock, ownership transfer, Chapters 8–14); DVM, Exclusives & RAS Coverage (dedicated coverage for system features, Chapters 11–12); and Coverage Closure (full closure on a reviewed model, waivers justified, bug curve flattened). Sign-off means a checking scoreboard with an independent model, an assertion per rule proven to fire, closed coverage on a reviewed model, and every gap closed. The pitfall is the hollow pass — a green regression that proves nothing because the testbench stimulates without checking, or coverage measures what ran not what was verified, so real bugs ride a passing suite to silicon. Passing is not verified; only a check that could have failed proves anything. Next, 21.4 reviews performance.

Coming Next

Chapter 21.4 — Performance Review Checklist. The block is functionally verified; the next review asks whether it is fast enough. Chapter 21.4 covers the pre-tapeout performance audit for CHI — the latency, bandwidth, directory-efficiency, snoop-reduction, hotspot, system-level-cache, and QoS questions that confirm a correct coherent design also meets its performance targets before it is too late to change.