Recovery and removal checks

In short: Recovery and removal checks are the asynchronous-reset equivalents of setup and hold — they guarantee that a reset de-asserts (or asserts) far enough from the active clock edge that the flop resolves cleanly instead of going metastable.

Every digital engineer learns setup and hold for the data pin of a flip-flop. Far fewer can confidently explain what happens at the asynchronous set/reset pin of that same flop. Yet static timing analysis (STA) tools like Synopsys PrimeTime and Cadence Tempus run two extra timing checks on those control pins: recovery and removal. Miss them and you ship a part that occasionally powers up into a corrupted state — a bug that is brutal to reproduce on the bench.

Why an async pin needs its own timing checks

An asynchronous reset forces a flop's output to a known value regardless of the clock. That is exactly why it is useful at power-up. But the flop still contains a feedback loop, and when the reset is released, the loop must latch whatever the reset drove. If the release happens too close to the capturing clock edge, the flop can't decide whether reset is still active — the classic setup/hold race, just moved to the control pin.

So the tool splits the problem into two constraints, mirroring setup and hold exactly:

• Recovery time — the minimum time the reset must be de-asserted (released) before the active clock edge. It is the setup-analogue: “get your reset out of the way early enough.”
• Removal time — the minimum time the reset must stay asserted after the active clock edge. It is the hold-analogue: “don't release reset too soon after the edge.”

Recovery ↔ setup, removal ↔ hold. Both are measured from the reset's inactive-going edge to the capturing clock edge. If you can time a data path, you already have 90% of the mental model.

The check equations, with real numbers

STA evaluates these just like data checks. For a reset release launched by a source register and captured by a destination flop:

• Recovery slack = (capture clock edge + recovery requirement correction) − (reset arrival time). Positive slack means the reset settled in time.
• Removal slack = (reset-change arrival) − (capture edge + removal requirement). Positive slack means reset held long enough.

Recovery/removal values in a 28 nm library are commonly 50–100 ps — usually a touch larger than setup/hold, because the reset net often drives a big fanout and the internal override path is slower.

Where real designs get bitten

The violation almost never comes from the reset assertion — that is asynchronous by intent. It comes from reset release relative to the clock. The textbook fix is a reset synchronizer: an asynchronous-assert, synchronous-de-assert circuit (two flops clocked by the destination clock, with reset tied to their async pins). This guarantees the release edge is aligned to the clock, so recovery/removal are met by construction.

Watch for these in practice:

• Clock-domain crossings on reset: a reset synchronized in domain A but released against domain B's clock still fails recovery. Each clock domain needs its own synchronizer.
• Huge reset fanout: a global reset feeding 50k flops has large, skewed arrival. High-fanout buffering and balancing the reset tree matters as much as the clock tree.
• Gated or divided clocks: the capture edge the tool uses may differ from your mental model — always confirm with report_timing -check_type recovery in PrimeTime or Tempus.

Fixing recovery and removal violations

The techniques overlap heavily with hold-violation fixing and setup-time fundamentals, because the underlying math is identical:

• Recovery (setup-like) fails? The reset release is arriving too late. Shorten the reset path: reduce buffering, retime the synchronizer closer to the sink, or relax the clock frequency on that path.
• Removal (hold-like) fails? The reset release is arriving too early relative to the capture edge. Add delay on the reset net — the same buffer-insertion trick used for hold.
• Architectural fix: insert or fix the reset synchronizer so de-assertion is clock-aligned. This is almost always the correct answer and removes the need to chase individual paths.

Teams building full reset strategies, from power-on reset to multi-domain release sequencing, often lean on structured training — see the physical-design and RTL programs at ChipXpert's VLSI training for hands-on labs on exactly these flows.

Want to run recovery/removal checks yourself in PrimeTime and debug a real reset tree? Explore the STA and physical-design track on our CourseTron courses.

FAQ

Are recovery and removal checks only for resets?

No — they apply to any asynchronous control pin, including asynchronous set and preset. The tool checks the inactive-going transition of whichever async pin the cell defines.

Why is recovery usually larger than setup for the same flop?

The asynchronous override path inside the flop is typically slower and less optimized than the data path, and reset nets drive heavier fanout. Characterization therefore reports larger recovery/removal margins than setup/hold.

Can a reset synchronizer eliminate these checks entirely?

It doesn't remove the check, but it makes meeting it automatic: because de-assertion is registered on the destination clock, the release edge is already aligned, so recovery and removal close with comfortable slack in nearly all cases.

What command reports these in Synopsys PrimeTime?

Use report_timing -check_type recovery and -check_type removal. Cadence Tempus and Siemens tools expose equivalent report options filtered by async-pin check type.