An architect wants DCRouter to give high-priority packets precedence, but never let low-priority traffic starve. The specification says "high priority wins". The designer implements exactly that. The verification engineer, reading the same sentence, writes a check that high priority always wins. Every test passes. In the lab, a stream of high-priority traffic locks out low-priority packets for seconds. Design and checks agree perfectly; both disagree with what was wanted.
Where do the gaps between intent, specification and implementation come from, and how does verification close them?
The obvious model is a single comparison: the testbench checks the design, and passing means correct. But a testbench encodes somebody's reading of the specification, and the specification encodes somebody's reading of the intent. If the design and the testbench are built from the same misreading, they agree, and the bug is invisible. Passing tests show agreement between two descriptions, not correctness.
Description | Who holds it | How it goes wrong |
|---|---|---|
Intent | Architects, customers, system teams | Never fully written down; assumptions stay in people's heads |
Specification | The document | Ambiguous, incomplete or simply wrong about the intent |
Implementation | The RTL | Wrong about the specification, or right about a misreading of it |
Independent readings: the checks and the reference model are written from the specification by someone other than the designer, so a misreading shows up as a mismatch.
Specification review: questions raised while writing checks feed back into the specification (Part 2).
Validation scenarios: real workloads compare the whole product with intent, catching specification gaps (lesson 0.1).
Explicit rules for intent: unwritten assumptions ("low priority must not starve") become numbered, checkable rules.
Practice | Why |
|---|---|
Separate design and verification engineers | Two readings of the specification instead of one |
Verification IP for standard interfaces | An independent reading already tested on many designs |
Architect review of the verification plan | Checks the plan against intent, not only the document |
Bugs filed against the specification | Treats ambiguity as a bug to fix, not a judgment call to bury |
The opening priority bug (illustrative) was fixed by adding the missing intent to the specification as a rule: "a low-priority packet waiting at an output is served within 64 packets". That rule became an assertion, and the arbiter got a starvation limit. DCRouter's own rule R6 (round-robin within each class) is the kind of statement that would have been checked against the wrong reading if nobody had asked what the architect meant.
Only that the RTL and the testbench agree; any misreading of the specification is shared by both, so it cannot fail.
The gap between intent and specification: verification checks against the specification, so a specification that misstates the intent passes.
Intent, specification and implementation are three descriptions that can each disagree with the others.
Passing tests show agreement between design and checks, not correctness; shared misreadings stay invisible.
Independent readings, specification review and validation close the gaps.