BeginnerQuestion 291 of 97Source PDF page undefined

Beyond setup and hold, what other timing checks does STA run at a sequential element?

From PDVerse PnR Interview Handbook · pdVerse Mentor Guide

Short Answer

STA runs several distinct check types at sequential boundaries: setup and hold (data stability before/after the clock edge), removal (minimum time between a clock edge and releasing an async control signal like reset), recovery (minimum time between releasing that signal and the next clock edge), period (minimum time for one full clock cycle), and minimum pulse width high/low (MPH/MPL). Each protects a different failure mode -- removal and recovery specifically guard asynchronous reset/set behavior, not the synchronous data path.

Technical Reference DiagramBeyond setup and hold, what other timing checks does STA run at a sequential element?
Beyond setup and hold, what other timing checks does STA run at a sequential element?, illustrating the physical design concept.

Technical Explanation

  • Setup: data must be stable for a defined interval BEFORE the active clock edge.
  • Hold: data must remain stable for a defined interval AFTER the active clock edge.
  • Removal: the limit on time between an active clock edge and RELEASING an asynchronous control signal (e.g. reset) from its active state -- releasing too soon leaves the FF state uncertain.
  • Recovery: the limit on time between releasing that async signal and the NEXT active clock edge.
  • Period: the minimum allowable time for one complete clock cycle -- must be >= max FF propagation delay + max combinational logic delay on any path.
  • MPH/MPL: minimum time a clock pulse must remain high/low respectively.
  • Each check type has a direct reporting command: report_timing -delay_type max for setup, report_timing -delay_type min for hold, report_timing -check_type removal, and report_timing -check_type recovery.

Common Mistake

The Trap: Only checking setup and hold and assuming that covers all sequential timing risk -- removal and recovery specifically guard asynchronous reset/set paths that setup/hold checks don't touch at all.

Follow-up Question & Model Response

"Why would removal and recovery checks matter specifically for an asynchronous reset, when the reset itself isn't part of the normal synchronous data path?"

Candidate Model Response: Because releasing an async reset too close to a clock edge can leave the flip-flop's output in an undefined or metastable state -- removal and recovery exist specifically to guarantee the reset release doesn't collide with the clock edge the way setup/hold guarantee data doesn't.

Practical Example

Debug Scenario: A design passes setup and hold cleanly but fails signoff on a removal violation at an async reset pin -- the reset is being released too close to the next active clock edge, a distinct failure mode from anything setup/hold checks would catch.

Physical Design & Planning Handbook

Dive into 14 comprehensive chapters covering netlist sanity, FinFET grids, macro placement, power grids, CTS, and timing budgeting.