Recovery and Removal in STA: Async Reset Timing Checks

Recovery and removal are the setup- and hold-like checks STA runs when an asynchronous reset (or set) is released relative to the clock. They answer a simple question: after the async clear/preset pin is deasserted, is the next active clock edge far enough away that the flip-flop samples cleanly—and is the deassert edge itself not racing the same clock edge from the other side?

If you already know setup and hold, recovery maps to setup and removal maps to hold for the async control pin. The rest of this post makes that analogy precise, shows how libraries and SDC express the arcs, walks through illustrative numbers, and gives a debug flow you can use on real reports. Related reading: Static Timing Analysis (STA) in VLSI, Useful Skew in VLSI, Multicycle Path and False Path in STA, Clock Gating and ICG, Latch vs Flip-Flop, Clock Tree Synthesis (CTS) and ECO in VLSI Physical Design.

What recovery and removal mean

An asynchronous reset (often named CLR, RESET_B, RN, or similar in the liberty pin name) forces the flop output to a known value without waiting for a clock edge. An asynchronous set (PRE, SET, SN) does the same for the opposite polarity. Asserting that pin is usually treated as a functional/async event: the designer accepts that it can interrupt the clocked behavior. Deasserting (releasing) the pin is different. Once the reset is released, the next clock edge must see a stable internal state so that the flop can capture data correctly. That is where recovery and removal come from.

Check	Plain meaning	Closest setup/hold analogy
Recovery time	Minimum time from async reset/set deassert to the next active clock edge	Like setup of the async pin relative to the clock
Removal time	Minimum time the async reset/set must remain asserted past (or clear of) the active clock edge—i.e., how soon after a clock edge the deassert may occur	Like hold of the async pin relative to the clock

In other words:

• Recovery protects the next clocked capture after release: the deassert edge must arrive early enough before the clock edge.
• Removal protects against a race on the same clock edge: the deassert must not happen so close after (or overlapping) the clock edge that the flop’s internal recovery path and clock path collide.

Both checks are measured at the flip-flop pins (async pin and clock pin), using library timing arcs characterized for that cell. They are not the same as a data setup/hold check on D→Q, even though the math looks similar.

Recovery vs removal vs setup/hold

The analogy is the fastest way to remember the pair—and the fastest way interviewers probe whether you really understand async controls.

Setup ↔ recovery. For data, setup asks: “Is D stable long enough before the clock edge?” For async reset, recovery asks: “Has CLR been released long enough before the clock edge?” If recovery fails, the flop may come out of reset in a metastable or incorrect state when that clock edge arrives.

Hold ↔ removal. For data, hold asks: “Does D stay stable long enough after the clock edge?” For async reset, removal asks: “Does the assert/deassert relationship to that same clock edge leave enough margin so the cell does not see a simultaneous race?” A removal failure typically means the reset is released too soon relative to the clock edge that is also trying to capture.

Important differences from ordinary data setup/hold:

1. The “data” pin of the check is an async control, not D.
2. Asserting reset is often unconstrained or handled differently; the critical STA focus for clean release is usually deassert timing (exact liberty arcs depend on the cell and how the library models assert vs deassert).
3. Reset trees are often lightly buffered, high-fanout networks. Delay and skew on the reset net dominate recovery/removal slack more often than a few gates on a data path.
4. Many designs intentionally synchronize reset deassert into the clock domain so that release becomes a synchronous event—then ordinary setup/hold (or a constrained sync path) replace raw async recovery/removal at the leaf flops. More on that below.

Async reset deassert and the next clock edge

Consider an active-low async clear (CLR_N). While CLR_N is low, Q is forced to 0. When CLR_N rises (deassert), the flop leaves the forced state and becomes clocked again.

STA then asks, for each subsequent active clock edge at that flop:

• From the deassert arrival at CLR_N to the clock arrival, is there at least the library recovery requirement?
• Relative to that same clock edge, does the deassert satisfy the library removal requirement (so the release is not racing the edge)?

Conceptually (same-edge / next-edge wording varies by tool report, but the idea is stable):

[
T_{\text{clk arrival}} – T_{\text{reset deassert arrival}} \ge T_{\text{recovery}}
]

for a recovery-style check, and a same-edge race form for removal analogous to hold:

[
T_{\text{reset deassert arrival}} – T_{\text{clk arrival}} \ge T_{\text{removal}}
]

(or the polarity/edge sense your library and tool use—always read the arc and the report, not only the textbook inequality). Early/late path values, OCV derates, and clock uncertainty apply the same way they do for setup/hold. See STA in VLSI for how those margins enter reports.

Worked example 1: recovery pass and fail (illustrative)

All numbers below are made up for teaching; they are not silicon measurements.

• Clock period (T_{\text{clk}} = 1.0\,\text{ns}), active rising edge.
• Library recovery (T_{\text{rec}} = 80\,\text{ps}), removal (T_{\text{rem}} = 30\,\text{ps}).
• Clock network delay to the flop (late for recovery) (T_{\text{clk,late}} = 400\,\text{ps}) from a virtual root used for this example.
• Reset deassert arrives at the flop CLR pin at (T_{\text{rst}} = 250\,\text{ps}) (same time origin).

Recovery slack (illustrative):
(T_{\text{clk,late}} – T_{\text{rst}} – T_{\text{rec}} = 400 – 250 – 80 = +70\,\text{ps}) → pass.

Now delay the reset tree so deassert arrives at (T_{\text{rst}} = 360\,\text{ps}):
(400 – 360 – 80 = -40\,\text{ps}) → fail. The clock edge is too soon after release; the flop may not be ready to capture cleanly.

Worked example 2: removal race (illustrative)

Keep (T_{\text{rec}} = 80\,\text{ps}), (T_{\text{rem}} = 30\,\text{ps}). Suppose an early clock arrives at (T_{\text{clk,early}} = 380\,\text{ps}) and reset deassert at the pin is (T_{\text{rst}} = 395\,\text{ps}) (release just after that edge in this simplified timeline).

A hold-like removal check might look at whether deassert is sufficiently away from the clock edge in the removal sense. Rough illustrative form:
(T_{\text{rst}} – T_{\text{clk,early}} – T_{\text{rem}} = 395 – 380 – 30 = -15\,\text{ps}) → fail.

Interpretation: release is too close to the clock edge. Fixes usually push deassert later relative to that edge (more reset delay after the edge of concern), move the clock, or—preferably—synchronize deassert so leaf flops never see a raw async release near a capture edge.

Worked example 3: sync deassert removes the async check at leaves (illustrative)

Two flip-flops in the clock domain form a simple reset synchronizer: async assert into the first stage is still allowed by methodology, but deassert is released only after two clocked stages, so fanout flops see a synchronous clear (or a synchronously released control). Leaf recovery/removal to the async pin may no longer apply (or apply only on the synchronizer cell itself, depending on how the cell and SDC are written). You then close ordinary setup/hold on the sync reset net. Numbers: if the sync chain adds two cycles before release is visible downstream, you trade async pin checks for standard sequential timing—usually what sign-off wants for the bulk of the register file.

Library arcs and how tools report them

In Liberty, recovery and removal appear as timing arcs between the async pin and the clock pin, with timing type such as recovery_rising / recovery_falling and removal_rising / removal_falling (names vary slightly by library). The sense follows which edge of reset and which edge of clock are related.

When you open a timing report:

• Look for checks labeled recovery or removal (not only setup/hold).
• Confirm related pin is the clock and constrained pin is the async control (or vice versa depending on tool wording).
• Note edge (rising/falling reset vs rising/falling clock).
• Apply the same corner/mode discipline you use for setup/hold: slow corners often dominate recovery (max delay on reset vs clock relationship); fast corners often dominate removal—mirroring setup vs hold.

If the library cell is a sync-only flop (no async pin), these arcs do not exist. If the cell has both async set and reset, you get arcs for each pin that is used.

SDC: expressing recovery and removal

Most flows inherit recovery/removal from the library once clocks and the reset port are defined. You still need correct clock definitions, input delays on reset (if it is a chip/block port), and sane exceptions.

Common SDC building blocks (syntax varies slightly by tool; treat the following as conceptual):

# Clock
create_clock -name CLK -period 1.0 [get_ports clk]

# Chip/block reset port: describe external deassert timing
set_input_delay -clock CLK -max 0.4 [get_ports reset_n]  ;# illustrative
set_input_delay -clock CLK -min 0.1 [get_ports reset_n]  ;# illustrative

# Explicit overrides when methodology requires them (tool-dependent commands)
# set_recovery_time / set_removal_time style constraints — check your STA reference
# for the exact command name and whether library arcs already cover the check.

Practical notes:

• Do not false-path the entire reset network “to quiet the report” unless the methodology truly treats that path as non-timed—and even then, document it. Silent recovery fails are functional risks at release.
• If reset is asserted asynchronously but deasserted synchronously, constrain the synchronizer and the sync reset distribution; leave async assert paths per CDC/reset methodology (often not closed like a data path).
• Multicycle/false-path exceptions that were meant for data can accidentally disable reset checks if they are written too broadly (set_false_path -from [get_ports reset_n] is a classic foot-gun). Prefer narrow exceptions. Background: Multicycle Path and False Path.

Sync vs async reset: what changes in STA

Style	Assert	Deassert	Dominant STA checks at leaf flops
Fully async reset	Async	Async	Recovery + removal on CLR/PRE vs CLK
Async assert, sync deassert (common)	Async	Through synchronizer	Recovery/removal mainly at sync flops; leaf flops often see sync clear → setup/hold
Fully sync reset	Clocked	Clocked	Ordinary setup/hold on reset data pin / sync clear

Why sync deassert is popular. Releasing reset in the same clock domain makes fanout flops leave reset on a clock edge under normal sequential rules. You avoid a chip-wide async deassert wave racing every local clock arrival. The cost is synchronizer latency (typically one or more cycles) and careful CDC if reset crosses domains.

Why pure async still appears. Small blocks, legacy IP, or “immediate clear” needs. Then recovery/removal closure and a well-designed reset tree are mandatory—not optional report cleaning.

Reset trees interact with CTS: clock arrival at each flop sets one side of the check; reset arrival sets the other. Balancing only the clock while leaving reset highly skewed is a common source of recovery fails after CTS.

Reset tree, OCV, and useful-skew interactions

Reset tree. High fanout, often buffered late in the flow. Delay on reset increases recovery difficulty when deassert is late relative to clock. Useful buffering and distribution (sometimes a dedicated reset CTS-like structure) improve both recovery and removal predictability.

OCV / AOCV / POCV. Derates on clock and reset paths can consume recovery margin the same way they consume setup margin. A reset path that looked fine at ideal clocks can fail at sign-off with advanced OCV. CRPR-like common-path behavior may apply when reset and clock share structure—but often they do not share much, so pessimism stays high. Do not assume textbook picoseconds equal sign-off slack.

Useful skew. Intentional clock shifts change recovery/removal just as they change setup/hold: moving capture clock later helps recovery-like checks and can hurt removal-like checks. If you schedule useful skew for data setup, re-check recovery/removal on flops with async pins.

Clock gating. Gated clocks change when the “next active edge” occurs after reset release. An ICG that stays off can defer the first capture edge—sometimes helping recovery in wall-clock time, but methodology must define whether gated-off behavior is acceptable functionally. See Clock Gating and ICG.

Debugging recovery and removal violations

A practical order:

1. Confirm the check type and pins. Is it really recovery/removal on CLR/PRE vs CLK, or a misread setup/hold on D?
2. Confirm methodology. Should this flop even see async deassert? If the design intends sync deassert, fix the RTL/netlist/synchronizer rather than hammering the async tree.
3. Compare arrivals. Is reset late (recovery) or racing the clock (removal)? Late reset tree vs early clock is the usual recovery story.
4. Inspect SDC. Over-broad false paths, missing clocks, wrong input delays on reset ports, or disabled library checks.
5. Corners. Recovery ~ max-delay style; removal ~ min-delay style. Wrong corner view wastes ECO time.
6. Fix. Buffer/rebalance reset, add or fix synchronizers, adjust clock schedule carefully, or correct constraints. Functional ECOs that change reset style need LEC/verification—not only STA green. See ECO in VLSI Physical Design.

Common findings:

• Recovery fails after CTS — clocks got faster/earlier at sinks while reset tree was untouched.
• Removal fails after useful skew — positive skew for data setup tightened removal on async pins.
• Clean sync design still reports recovery — leftover async pins on library cells still connected, or synchronizer not applied to all fanout.
• Quiet report, silicon bug at wake-up — reset was false-pathed; bring the checks back.

Interview questions and answers

1. What is recovery time?
The minimum time required between asynchronous reset/set deassertion and the next active clock edge so the flip-flop can leave reset and capture correctly. It is the setup-like check for the async control pin.

2. What is removal time?
The minimum time requirement that keeps asynchronous reset/set assertion/deassertion from racing the active clock edge—hold-like relative to that edge.

3. How do recovery and removal map to setup and hold?
Recovery ↔ setup; removal ↔ hold, with the async pin playing the role of the constrained signal relative to the clock.

4. Why is deassert more critical than assert for many STA discussions?
Assert forces a known value and is often accepted as asynchronous. Deassert returns the flop to clocked operation; a poorly timed release relative to the clock risks metastability or wrong capture. (Always follow your library arcs and project methodology for assert as well.)

5. Sync vs async reset—what does STA see?
Fully async: recovery/removal at leaves. Sync deassert: ordinary setup/hold on the synchronized reset, with recovery/removal concentrated at synchronizer/async boundary cells.

6. Can you false-path reset to “clean” STA?
Only with explicit methodology approval. Blanket false paths on reset can hide real recovery/removal failures that show up as boot or wake-up bugs.

7. How do OCV derates affect recovery?
They add pessimism on clock and reset paths, reducing reported recovery slack versus ideal-network arithmetic—similar to setup under OCV.

8. A recovery violation appears only after CTS. Why?
CTS changed clock arrivals at flops. If the reset network was not adjusted, the relative deassert-to-clock timing can violate recovery even though pre-CTS ideal clocks looked fine.

9. Does useful skew affect recovery/removal?
Yes. Shifting clock arrivals moves recovery and removal slack in opposite directions, just as with setup and hold. Re-check async pin timing after skew scheduling.

10. Where do library recovery/removal values come from?
Cell characterization in the liberty file: timing arcs between async pins and the clock pin for specified edges and transition conditions.

FAQ

Are recovery and removal only for resets?
They apply to asynchronous control pins—commonly reset and set. The same ideas extend to other async controls if the library defines arcs.

Is metastability the same as a recovery fail?
A recovery fail means the library’s required separation was not met; metastability is a possible physical outcome when async and clock edges collide. STA flags the timing risk; it does not simulate metastability waveforms.

Do latches have recovery/removal?
If a latch has async set/reset pins with library arcs, yes. Edge-triggered flops are the usual interview focus; see Latch vs Flip-Flop for latch timing differences on data.

Should every design use sync deassert?
It is a common best practice for large synchronous domains, but not a universal law. Follow the chip reset methodology; small blocks and some IP still use async release with careful tree design.

Why do interviewers ask this?
It tests whether you understand that setup/hold are not the only pin checks, that async controls have their own arcs, and that reset architecture (sync vs async) changes what STA must close.

Summary

• Recovery and removal are STA checks between asynchronous set/reset pins and the clock; recovery is setup-like for deassert, removal is hold-like for the race with the clock edge.
• Library timing arcs define the required values; tools report them alongside—but distinct from—data setup/hold.
• SDC must define clocks and reset port timing without blindly false-pathing the reset network.
• Sync deassert (e.g., 2FF synchronizer) moves most leaf checks to ordinary sequential timing; pure async release demands real recovery/removal closure and a controlled reset tree.
• CTS, useful skew, OCV and clock gating all move these slacks; re-check after clock changes.
• Debug by confirming pins and methodology first, then arrivals, corners and constraints—not by deleting the checks.

References

• J. Bhasker and R. Chadha, Static Timing Analysis for Nanometer Designs: A Practical Approach, Springer, 2009.
• IEEE Std 1801 / Accellera Liberty documentation for timing type semantics (recovery/removal arcs)—consult the liberty reference paired with your PDK.
• Static Timing Analysis (STA) in VLSI
• Setup and Hold Violations
• Useful Skew in VLSI
• Multicycle Path and False Path in STA
• Clock Tree Synthesis (CTS) in VLSI Physical Design
• Clock Gating and Integrated Clock Gating (ICG)
• ECO in VLSI Physical Design
• Difference Between Latch and Flip-Flop