Reset timing failures are rare in a working design but severe: the chip comes out of reset in an inconsistent state, and the failure depends on voltage and temperature. A short review list catches the usual causes.
Item | Evidence |
|---|---|
Checks exist for all asynchronous pins | Count of recovery plus removal checks is twice the count of flops with async pins (one of each per pin) |
Both checks clean in every view | Per-view slack summary; in the conventional case removal in fast views, recovery in slow views, while at low voltage both temperature extremes are checked |
Release comes from a synchroniser in the capturing domain | Netlist review; no flop is released straight from an input or another domain |
Reset input port is constrained | Input delay on the reset port, or the port is the input of a synchroniser and is the CDC case, not a timing path |
No blanket false path on reset | A false path on the reset port into a synchroniser is acceptable; one on the synchroniser output network is not |
Tree skew within budget | Spread of release arrival times in each domain |
async_pins, checks = 18240, 36480 # one recovery and one removal check per pin
views = {"ss_cold": (2.10, 6.40), "ff_cold": (-0.04, 7.20), "tt": (0.62, 6.80)} # (removal slack, recovery slack)
count_ok = checks == 2 * async_pins
bad = {v: s for v, s in views.items() if min(s) < 0}
assert count_ok and list(bad) == ["ff_cold"]
assert bad["ff_cold"] == (-0.04, 7.20)
print("PASS: counts match;", "failing view", list(bad), "removal", bad["ff_cold"][0])The counts match (36480 checks for 18240 pins: one recovery and one removal check per pin), but the fast cold view fails removal by 0.04 ns. That is a real hold-type problem on the reset network, found only because removal was reported per view. The fix is delay on the shortest reset paths, followed by a recheck of recovery in the slow view.
Symptom | Fix |
|---|---|
Removal violation, short reset path | Insert delay on the short path, or retime the release |
Recovery violation, long reset tree | Rebalance or buffer the tree; split into per-region branches; if needed use a synchroniser per region |
Partial release across the domain | Reduce tree skew against the clock period; synchronise the release closer to its flops |
Release from another clock domain | Add a reset synchroniser in the capturing domain |
The number of async-pin flops against the number of checks (one recovery and one removal check per pin, so twice as many checks), because a pin with no check is one nobody has analysed.