At the tape-out review an executive asks the verification lead directly: "Are you confident there are no bugs?" Answering "yes" would be untrue and everyone in the room knows it; answering "no" sounds like a refusal to sign. The useful answer is neither. It is a statement of what is known, what is assumed and what is estimated, with the evidence for each.
Are you confident there are no bugs?
The obvious answers are reassurance ("we're confident") or a single number ("98% coverage"). Reassurance gives the decision-makers nothing to weigh, and a single number hides what it does not measure. Residual risk is a structured list: the parts of the design and its use where a bug could still be, how likely that is, and what would happen.
Kind | Examples | How to state it |
|---|---|---|
Known gaps | Features without evidence; coverage holes | List them, with why |
Accepted waivers | Decided exceptions (lesson 14.3) | List them, with owners |
Unchecked assumptions | Environment models, formal assumptions, neighbours' behaviour, the specification itself | List the assumptions the evidence depends on |
Unknown bugs | Bugs in situations nobody planned, checked or covered | Estimate from discovery curves and capture-recapture, as a range (Part 12) |
Kind | Item |
|---|---|
Known gaps | None of the 28 planned features is without evidence after the gap-closing bench |
Waivers | ERR_CNT0, 1, 3 saturation bins (lesson 14.3); throughput specification corrected to one idle cycle between packets |
Unchecked assumptions | Sinks return credits only for held flits (formal assumption, and true of the testbench sinks); sources hold data while stalled; the specification R1–R13 is right for the system |
Unchecked assumptions | Formal proofs cover FIFO, arbiter and credit rules only; framing, CRC, counters and sleep rely on simulation |
Unknown bugs | The design's own bug count is unknown; the testbench catches all 24 planted bugs, and the gap bench found one plan-versus-design difference, so the method is sensitive, but planted bugs are not real ones |
Out of scope | Integration in the SoC, power-aware behaviour with domains switched off, electrical margins (Parts 8, 11) |
"No one can be certain there are no bugs. Here is what we know: every planned feature has evidence, the control logic is proved for all inputs, and our testbench detects every bug we planted. Here is what we assumed: the interface behaviour of the neighbouring blocks and the specification itself. Here is what we accepted: two waivers, listed. Our estimate of remaining bugs from the discovery curve is low, with a wide range. We recommend sign-off, with silicon validation starting on the listed items."
Specific, not soothing: items, not adjectives.
Ranges, not points: estimates with uncertainty (lesson 12.2).
Assumptions named: every proof and model rests on some.
Out of scope stated: what this sign-off does not cover, and who covers it.
Carried forward: residual risk becomes the silicon validation plan's first page (lesson 11.2).
Practice | Purpose |
|---|---|
A residual-risk section in every sign-off report | Decision-makers see what they accept |
Assumption registers for formal and modelling | Assumptions reviewed and discharged where possible |
Residual risk linked to silicon validation priorities | Known risks tested first on silicon |
A team (illustrative) reported "high confidence" at every review. When a silicon bug appeared in an area verified only against a behavioural model of a neighbouring block, it emerged that everyone had known the model was approximate; nobody had written it down. A residual-risk statement listing "neighbour behaviour verified against an approximate model" would have put that interface first in silicon validation.
That a sink returns a credit only for a flit it holds.
It gives decision-makers nothing to weigh: no gaps, assumptions, waivers or estimates, and no basis for directing silicon validation.
Residual risk is known gaps, waivers, unchecked assumptions and unknown bugs.
State it specifically, with ranges for estimates and assumptions named.
Carry it forward into silicon validation priorities.