Why it matters

Noise analysis can produce thousands of lines. The review reduces them to a table by receiver class, with each violation fixed, waived with a reason, or open. The rules for what blocks signoff are written beforehand.

Worked example

1
2
3
4
5
6
7
8
9
10
11
12

# class: (receivers checked, violations, waived with evidence)
summary = {"flop_D": (4000, 12, 10), "clock_pin": (36, 0, 0), "async_reset": (210, 2, 0), "latch_enable": (15, 1, 1)}
critical = {"clock_pin", "async_reset", "latch_enable"}
open_items = {c: v - w for c, (n, v, w) in summary.items() if v - w > 0}
blockers = sorted(c for c in open_items if c in critical)
assert open_items == {"flop_D": 2, "async_reset": 2}
assert blockers == ["async_reset"]
total_checked = sum(n for n, v, w in summary.values())
assert total_checked == 4261
ready = not open_items
assert ready is False
print("PASS: open items", open_items, "; blockers", blockers, "; receivers checked", total_checked)

Of 4261 receivers, 15 violate; 11 are waived with evidence and 4 are open. The two open asynchronous-reset items are blockers by rule; the two open data-pin items need a fix or a waiver with evidence. The one waived latch-enable violation deserves a second look because waivers on critical receivers carry the highest risk: its evidence should show why the enable glitch cannot open the latch while its data is changing (the pulse is too narrow to open it, or the data is stable across the glitch window).

What the review looks for

• Each waiver has a reason that depends on the design (a timing window, a logic condition), not on the lack of observed failures.

• Open critical items block signoff without exception unless the rule itself is changed by the signoff owner.

• The review is repeated after every ECO that changes routing or drive strength around a victim.

Related topics

• Functional Failure Risk