A waiver says “this finding is understood and accepted”, never “this finding is unimportant”. The distinction decides the whole policy: some findings describe safe-by-construction situations and can be waived with evidence, while others describe defects and can only be fixed. Waiving a defect does not change the silicon; it only changes the report.
Class | Example | Why it can be safe |
|---|---|---|
Qualified quasi-static | A configuration bit loaded once and held, sampled only while stable | Nothing changes near a sampling edge by construction |
Synchronised by construction | A crossing inside a hardened macro whose internal synchroniser is proven once | The structure exists; the waiver records where the proof lives |
Unreachable mode | A test-only crossing that the functional clocking can never produce | The condition for failure cannot occur in the waived mode |
Reset handled elsewhere | A reset crossing covered by the reset-domain methodology rather than the CDC check | Ownership is transferred explicitly, not dropped |
An unsynchronised functional crossing: no argument makes an unguarded asynchronous sample safe.
Logic before the synchroniser: the glitch risk is structural and only a design change removes it.
A multi-bit crossing without a protocol: independent resolution cannot be argued away.
A finding nobody understands: “no failure seen yet” is an observation, not evidence.
When both paths seem open, prefer the fix unless the waiver argument is airtight and cheap to evidence. A synchroniser costs two flops; a waiver costs a protocol argument, assertions, a constraint reference, joint review, and perpetual expiry tracking. Fixes are one-off costs while waivers charge interest every revision. Waive where the design is genuinely safe by construction — quasi-static, unreachable, proven macro — and fix everywhere else.
The burden sits entirely with the requestor. The default answer to a waiver request is no; the requestor moves it to yes by supplying the evidence the next lesson lists, in writing, attached to the finding. A reviewer never has to prove a waiver unsafe — the absence of proof is already a rejection.
Scope and expiry: the waiver should have named the mode it applied to and expired on design change, forcing re-review when the path became functional.
Because the reviewer cannot prove a negative across all operating conditions. The person claiming safety must exhibit the evidence; anything else turns review into guessing.