Closing DCRouter's last open features (lesson 14.6) produced a surprise. The plan said each output carries one flit per cycle. The measurement, six back-to-back maximum-length packets per output, gave 0.953 flits per cycle: one idle cycle between packets, because a new grant follows the previous tail by a cycle. The design behaves as built; the plan stated something stronger. Either the RTL changes, the specification changes, or someone signs a waiver.
When would you waive a coverage hole or a criterion, and how do you record it?
One obvious stance is "never waive": every gap is closed. Some gaps cost far more to close than the risk they carry, and refusing all waivers pushes teams to hide gaps instead, by excluding bins or relaxing checks quietly. The opposite stance, waiving whatever is left at the end, turns sign-off into paperwork. Waivers are legitimate exactly when they make a gap visible and owned.
Element | Question it answers |
|---|---|
What exactly | Which bin, criterion, rule or behaviour, precisely |
Why it is not closed | Unreachable? Too costly? Out of scope? A deliberate deviation? |
Evidence that the risk is low | Related tests, proofs, reuse, design arguments |
Consequence if wrong | What happens in the product if the waived behaviour is buggy |
Owner and approvers | Who requested it, who accepted the risk |
Follow-up | Silicon validation item, specification change, next-revision fix, or none |
Element | Waiver 1: ERR_CNT0, 1, 3 never saturated | Waiver 2: throughput 0.953 instead of 1.0 |
|---|---|---|
What | Coverage bins "ERR_CNTk saturated" for k = 0, 1, 3 | Feature F26: one idle cycle between back-to-back packets on an output |
Why not closed | Cost of a test per counter judged low value | Removing the bubble needs grant look-ahead in the arbiter: a design change late in the project |
Evidence | Same RTL loop for all four counters; ERR_CNT2 saturation tested (lesson 6.9); formal could prove it | Measured 0.953 for 17-flit packets; shorter packets lose proportionally more; functional behaviour unaffected |
Consequence if wrong | Statistics wrap on one counter after 255 errors | About 5% lower peak bandwidth for maximum-length packets, more for short packets |
Decision | Waive, or better: add the three loops (cheap) | Specification change: "one flit per cycle within a packet, one idle cycle between packets"; architects confirm bandwidth budget |
Follow-up | Silicon validation reads all four after an error storm | Performance validation on silicon measures it (lesson 11.2) |
Waiver 2 shows a common outcome: a gap between plan and behaviour that is resolved by correcting the specification, after checking the system can afford it. Measured performance is evidence; what the system needs decides whether it is a bug.
Vague: "some error coverage holes waived".
Unjustified: "not enough time" with no risk assessment.
Unowned: nobody senior accepted the risk.
Silent: the gap removed from metrics (excluded bins) without a record.
Repeated: the same waiver every project, never revisited.
Practice | Purpose |
|---|---|
A waiver register reviewed at sign-off | Every exception visible in one place |
Approval levels by severity | Bigger risks need more senior owners |
Waivers carried into silicon validation plans | Waived areas tested early on silicon |
Waiver audits on derivatives | Old waivers re-examined when designs are reused |
A team (illustrative) waived a coverage hole for an error-recovery path as "unreachable in our system". A derivative chip reused the block in a system where the path was reachable, and the waiver was never re-examined. The bug in the recovery path appeared in the derivative's first silicon. Waivers belong to a context; reuse must re-check them.
Functional behaviour is correct, the bandwidth loss is small and was confirmed affordable, and removing the bubble would need a late arbiter redesign; the plan's statement was stronger than needed.
A check in silicon validation, a specification change, or a fix in the next revision, recorded with the waiver.
Waivers make known gaps visible and owned; silent gaps are the real danger.
A valid waiver is specific, justified with evidence, owned, approved and followed up.
Measured behaviour that differs from the plan may be a bug or a plan error: decide which.