At a tape-out review, an auditor from the customer's safety team points at requirement 4.7.3 and asks three questions: which check enforces it, how do you know that check was exercised, and where is the result? The team has thousands of passing tests and 95% coverage, and cannot answer for that one requirement without a day of digging. Evidence that cannot be found for a specific rule is, for a reviewer, not evidence.
How do you show, for every requirement, that it was verified?
The obvious answer points at aggregate numbers: all tests pass, coverage is high. Aggregates hide gaps. A requirement can have no check at all while coverage is high (coverage measured something else); a check can exist but never fire (vacuous); a test can pass without exercising the requirement. Only a per-requirement link from rule to check to coverage to result shows each one is really verified.
A broken link anywhere is a gap: no check (nothing could fail), no coverage (the check may never have run in the situation that matters), no result (nobody knows).
A traceability table for DCRouter, filled in with what exists so far: the smoke test (step 1) and the reference model (step 3). The gaps are the point.
Rule | Check | Coverage | Result so far |
|---|---|---|---|
R1 FIFO admission | None yet | None | Smoke test only: FIFO never full |
R2 Exact occupancy | None yet | None | Not exercised |
R3 Whole packets, per-flow order | Smoke-test comparison; reference model (2.3) | None | Passes 4 packets |
R4 Lengths 1-15 honoured | Reference model predicts flit counts | None | Lengths 2 only |
R5 Length 0 flagged | Reference model predicts it | None | Not exercised |
R6 Arbitration and priority | None | None | Not exercised |
R7 Credits | None | None | Not exercised |
R8 CRC check | Reference model predicts out_err | None | Not exercised |
R9, R10 Counters | Register table (2.4); model predicts values | None | Not exercised |
R11 Reset values | Register table (2.4) | None | CTRL read once |
R12 pslverr | Register table (2.4) | None | Not exercised |
R13 Sleep and wake | Rules written (2.2) | None | Not exercised |
Every "none" is a cell a later part fills: stimulus in Part 4, checks in Part 5, coverage in Part 6, proofs in Part 7. By Part 14 the table is DCRouter's evidence ledger.
Link from the artefacts: assertion and coverage names carry rule numbers, so the table is generated, not maintained by hand.
Trace at the level of rules, not sentences or features: fine enough to show gaps, coarse enough to keep current.
Report gaps first: the useful output is the list of rules with a broken chain.
Practice | Purpose |
|---|---|
Requirement IDs in assertion, coverage and test names | Automatic links from results back to rules |
Traceability reports at milestones | Gaps are visible long before sign-off |
Mandatory in safety-critical projects | Functional-safety standards expect evidence per requirement (Part 15) |
A project (illustrative) traced requirements to tests but not to coverage. Every requirement had a test; one requirement's test configured a mode that a later regression change silently overrode, so the test kept passing without ever exercising the requirement. A link from the requirement to a coverage point for that mode would have shown the point drop to zero hits the day it happened.
The test may never exercise the situation the check guards, so the check passes without ever being able to fail.
R5 or R8 (and the counters): the reference model predicts their outcomes, but no test has sent a length-0 header or a bad CRC.
Traceability links each requirement to its checks, its coverage and its results.
A broken link anywhere is a gap that aggregate numbers hide.
Generate the table from rule IDs in checks and coverage, and review broken chains first.