The cheapest bug a verification engineer will ever find is one found in a meeting, in a document, before a line of RTL exists. Fixing it costs an edit to a paragraph. The same disagreement found in simulation costs debug time and RTL changes; found in silicon, a respin. Yet many teams start verification only when the RTL is ready, and read the specification only to write tests.
How should a verifier review a specification, and what questions find the gaps?
The obvious review reads the document for errors: typos, wrong numbers, contradictions. That finds the easy problems. The expensive ones are silences: the document says nothing about what happens at reset, at a limit, on an error, or when two events coincide. Silence reads as "nothing special happens", and each reader fills it differently. A verifier's review is a hunt for silences.
Question | Typical silence it exposes |
|---|---|
What happens at reset, and in the first cycles after it? | Reset values, start-up order, what may be sent before initialisation |
What happens at each limit (full, empty, maximum, zero)? | Off-by-one boundaries, saturation versus wrap |
What happens on an error, and who is told? | Error responses, counters, recovery |
What if two events happen in the same cycle? | Priorities between simultaneous updates |
Does it hold in every mode and configuration? | Behaviour when features are disabled |
How soon, exactly? | Latency, ordering, "eventually" |
How would I check it? | Anything that cannot become an assertion or model prediction |
Suppose an early draft of DCRouter's error section read as follows. The questions a verifier would file are listed under it.
Draft: "Packets with a bad CRC are flagged with out_err and counted in ERR_CNT.
Software can clear the counters."
Q1 Flagged on which flit? The tail only, or every flit of the packet?
Q2 Counted per input or per output? (One counter per port, but which port?)
Q3 What happens when a counter reaches its maximum: saturate or wrap?
Q4 Does clearing one counter clear the others?
Q5 Is a header with len = 0 a CRC error, another kind of error, or legal?
Q6 Is the packet still forwarded when its CRC is bad, or dropped?
Q7 Is out_err set for high-priority packets exactly as for low-priority ones?Every question became part of DCRouter's final rules R5, R8 and R9, and five of them match Bug Zoo bugs: what is counted, and where (Q2, BUG_14 counts port 2's good packets), saturation (Q3, BUG_15), independent clearing (Q4, BUG_19), length 0 (Q5, BUG_4) and priority (Q7, BUG_13). Each silence in the draft was a place a real bug could hide.
File it, with an owner and a date: a question in a hallway is forgotten; a filed one is answered.
Choose the strictest reasonable reading for checks in the meantime, and mark the check as provisional.
Do not let the RTL answer it: "whatever the design does" is not a specification.
Track open questions as risk: unanswered questions at sign-off are part of residual risk (Part 14).
Practice | Purpose |
|---|---|
Verification sign-off on the specification before RTL | Gaps are found when they cost a paragraph |
A question list per specification section | Every silence is asked about systematically |
Questions tracked like bugs | Owners, answers and versions are recorded |
A project (illustrative) started verification only after RTL freeze. The first week of writing checks produced 47 questions about the specification; 12 led to RTL changes, two of them in blocks already integrated. A review at the specification stage would have asked the same questions when the answers cost nothing to implement.
Any three of: cleared by a write of any value or a specific one? Does clearing one counter clear others? What if hardware increments it in the same cycle as the clear? What is read back immediately after? Can it be cleared in every mode?
It turns the design into its own specification, so any bug in that behaviour becomes the expected result and can never fail.
Specification review by verifiers finds bugs when they cost an edit to a paragraph.
Ask every requirement about reset, limits, errors, simultaneous events, modes, timing and how to check it.
File every question, check the strictest reading meanwhile, and never let the RTL answer it.