What is the difference between recovery/removal checks and setup/hold checks?

Short Answer

Recovery and removal are the asynchronous-control equivalents of setup and hold, but applied to a register's set or clear pin rather than its data pin. Recovery is setup-like — the control signal must be de-asserted early enough before the clock edge. Removal is hold-like — the signal must stay asserted long enough after the edge before releasing.

Technical Explanation

• What pin they police. Setup and hold constrain the data pin of a register. Recovery and removal constrain a different pin entirely: the asynchronous set or clear (commonly called preset or reset) that can force a register's state independent of the clock.
• Recovery is the setup analogue. A recovery check verifies that the asynchronous control signal — typically a reset — is de-asserted (released) early enough before the next active clock edge for the register to reliably resume normal, clocked operation on that edge. Like setup, it is about giving the circuit enough margin before the edge.
• Removal is the hold analogue. A removal check verifies the opposite side of the same edge: the asynchronous control must stay asserted long enough after the clock edge — or, equivalently, must not be released too soon after it — so the edge does not catch the register mid-transition out of reset. Like hold, it is about stability after the edge.
• Why this distinction exists at all. An asynchronous reset is, by definition, not gated by the clock — it can change state at any moment. But the moment it releases still has to be properly timed relative to the clock, or the register can land in an unpredictable, indeterminate state instead of cleanly resuming operation. Recovery and removal checks are exactly how STA verifies that release moment.
• What breaks if this is skipped. A design with no recovery/removal checking might look completely clean in a report that only checks data setup/hold, because those checks never touch the reset pin at all — the reset-release hazard would only ever surface as an intermittent, hard-to-reproduce failure after silicon.

Follow-up Question & Model Response

If a design uses a reset synchronizer to release reset synchronously to the clock, are recovery and removal checks still needed?

Candidate Model Response: Yes, though the risk is reduced rather than eliminated. A reset synchronizer aligns the release edge to the clock, which is why teams use them — to make recovery/removal timing predictable instead of arbitrary. But the synchronizer's output still drives real reset pins on downstream flops, and that final leg of the reset tree still has routing delay the checks need to verify, especially if the reset fans out to flops at very different distances. Skipping the checks ignores that the synchronizer only fixes the source of the release edge, not the delay to every flop it reaches.