A waiver granted for the wrong reason is a bug with a signature on it. On NanoSoC the classic request arrives from the crossing checker: the interrupt lines into the controller cross from the system clock to the peripheral clock through two-flop synchronisers, and an early run flags the paths because the synchroniser cells were hand-written rather than taken from the library. That waiver is legitimate. The request that must be refused arrives the same week: waive the missing synchroniser on a new status bit because the last three simulations passed. This lesson tells the two apart by rule, not by feeling.
Three classes may be waived. False violations are checker noise over correct design: a quasi-static configuration crossing flagged as an unconstrained path, a reset-tree path the checker misclassifies, a block that is provably unreachable and is excluded from coverage with the reachability proof. Proven-safe violations are real structures with complete evidence: the hand-written synchroniser with its two-flop waveform and its timing constraints, the asynchronous FIFO whose depth was computed from the burst formula. Bounded-risk violations are real weaknesses with contained effect: a rarely reachable error-path coverage hole whose only effect is a recoverable error flag, with the driver rule that clears it.
A real crossing, clamp, reset or default slave that is missing, with no proof that it is not needed, may never be waived. A structure that is absent by design, a quasi-static configuration bit or two domains that always power together, is a false violation and needs the proof of why: the crossing checker reports exactly a missing synchroniser, so the waiver must show the signal is static by construction. Simulation passing is never that proof, because simulation cannot see metastability, floating supplies or un-driven addresses. What is never acceptable is no structure and no argument.
Class | NanoSoC example | Requested by, granted by | Evidence required |
|---|---|---|---|
False violation | Quasi-static pad-config path flagged as a crossing; provably unreachable debug logic excluded from coverage | Discipline owner requests, integrator grants | Designer proof the path is static by construction, or the reachability proof |
Proven safe | The irq_dma and irq_sbr synchronisers (crossing X5) built from hand-written flops the checker does not recognise | Discipline owner requests, integrator grants, programme lead co-signs | Waveform, constraints, synchroniser depth arithmetic |
Bounded risk | A rarely reachable error-path coverage hole whose only effect is a recoverable ERR flag cleared by the driver rule | Discipline owner requests, integrator grants, programme lead co-signs | Containment analysis plus residual-risk note |
Never waived | A real missing synchroniser, clamp, reset or default slave with no proof it is unnecessary | Nobody: fix the design | Simulation is not evidence |
Bounded-risk waivers are requested by the discipline owner, granted by the integrator and co-signed by the programme or chip lead; nobody approves a waiver they requested. False and proven-safe waivers are requested by the owner of their domain (the crossing owner for synchronisers, the timing owner for false paths, the power owner for isolation intent) and granted by the integrator, because the risk crosses into system behaviour. Each waiver carries an audit record: requester, approver, date, the checker violation identifier, the signal or path pattern it covers, the baseline it was granted on, and the evidence reference. The tapeout review in the fourth topic re-confirms every live waiver; approval is a signature with a date, stored in the manifest, never a comment in a log file.
Every waiver names its class and carries the audit record above, and no waiver sits in the never-waived row.
Proven-safe waivers attach their evidence: waveforms, arithmetic, constraint references, not assertions of correctness.
The requester and the approver are different people, and the approver matches the class table above; a waiver approved by its own requester is refused on sight.
Audit the waiver table against the checker output: every excused violation must appear in both, with the same identifier, so nothing is excused that the checker never saw. Then sample one proven-safe waiver per discipline and reproduce its evidence: re-run the synchroniser arithmetic, re-read the waveform. A waiver whose evidence cannot be reproduced is a violation wearing a signature.
One waiver on the root cause, listing all 40 paths, with the synchroniser evidence attached once. Forty waivers hide the pattern; one waiver names it, and fixing the library cell clears all forty together.