Skip to main content

Timing Verification and STA

Every other page in this section checks functional correctness — does the design do the right thing. Static Timing Analysis (STA) checks something no amount of functional simulation ever can: whether the design does the right thing fast enough, exhaustively, without simulating a single test vector.

Setup and hold: two different constraints, two different fixes​

Setup violation — data arrives too close to (or after) the capturing edge:

Timing diagram for signals: clk, dataclkdata

Data needs to arrive with margin before the clock edge (setup time). Here it changes right at/after the edge instead — too late.

Hold violation — data changes too soon after the capturing edge:

Timing diagram for signals: clk, dataclkdata

Data was correctly stable before the edge, but changes again almost immediately after it — violating the flop's required hold time.

  • A setup constraint enforces a maximum delay on the data path — data has to arrive with enough margin before the clock edge for the flop to reliably capture it. Setup violations are commonly fixable by lowering the clock frequency — with more time between edges, a marginal path has more room to settle.
  • A hold constraint enforces a minimum delay after the edge — data must not change again too soon after the flop just captured it. Hold violations cannot be fixed by changing frequency at all — the problem exists entirely within one clock edge's neighborhood, unrelated to how far apart edges are — and need an actual physical design change (inserting delay on the offending path) instead. This asymmetry is worth remembering precisely: "just slow down the clock" is a real fix for one of these two violation types and does nothing at all for the other.

Recovery and removal: setup and hold's asynchronous-control-pin counterparts​

Setup and hold, as described above, both check a flop's synchronous data input against its clock edge. An asynchronous reset or set pin needs its own, differently-named pair of checks for the exact same underlying reason: recovery time is the minimum time an async reset/set must be de-asserted before the next active clock edge — the recovery-check analog of setup, ensuring the flop has reliably exited its reset/set condition before the edge tries to capture normal data. Removal time is the minimum time the async reset/set must stay asserted after an active clock edge before being released — the analog of hold, preventing the release from racing the edge. Both apply specifically to the reset/set-deassertion transition, not to the ordinary D-input transitions setup and hold already cover — which is exactly why reset domain crossing's own de-assertion synchronizer matters: it exists in part to make sure this exact timing relationship is met safely, not left to chance.

Slack, and the two real sources of clock uncertainty STA has to account for​

The number STA actually reports on every path is slack: the margin between when data needs to arrive and when it actually does. Positive slack means the path met its constraint with room to spare; negative slack means a real violation — the path is too slow (setup) or too fast (hold) for the clock relationship it's checked against.

That check isn't against an idealized, perfectly periodic clock, either. Real clocks carry clock uncertainty, combining two genuinely distinct sources: skew — the difference in clock arrival time at two different flip-flops, from unequal wire lengths or buffering on the way to each — and jitter — cycle-to-cycle variation in exactly when an edge arrives at all, from supply noise or PLL imperfection. STA budgets both into the setup/hold check directly, which is why a design can show comfortable slack against an ideal, jitter-free clock and still be marginal once real clock uncertainty is accounted for.

SDC: the constraint file that ties synthesis and STA together​

Timing constraints — clock periods, input/output delays, false paths, multicycle exceptions — are written once, as an SDC (Synopsys Design Constraints) file, and used by both synthesis (to know what to optimize for) and STA (to know what to check against) — the same file, not two independently-maintained descriptions of the same intent. STA re-reads the design's actual netlist and SDF-annotated delays, builds a timing graph spanning every register and net, and reports setup/hold slack on every path against exactly what that SDC file specified.

Where CDC and STA meet — and deliberately don't overlap​

A cross-domain path, by construction, has no fixed timing relationship between its source and destination clocks — there's no meaningful "does this arrive in time relative to that clock edge" question to ask, since the two clocks aren't related at all. SDC files explicitly declare such clock pairs asynchronous to each other, which tells synthesis and STA to skip setup/hold checking across that boundary entirely — not because it doesn't matter, but because a synchronous timing check on an inherently asynchronous relationship would just report meaningless false violations. This is exactly why CDC verification exists as its own, separate check: STA's own scope explicitly excludes the paths CDC exists to verify. Neither technique's coverage overlaps with the other's blind spot by accident — it's a deliberate division of labor.

Where this topic's scope ends​

Everything above is the front-end perspective: why simulation alone can't catch a timing violation, what a setup/hold constraint actually enforces, and what an SDC file represents. Full sign-off STA — closing timing across an entire placed-and-routed chip, with real parasitic-extracted delays, across every process/voltage/temperature corner — is physical design (back-end) work this site doesn't cover yet. What matters at the front-end level is narrower and more tractable: writing correct, complete SDC constraints and understanding what they mean, not running sign-off STA itself.

What's next​

All six specialized verification domains — CDC, RDC, linting, GLS/X-propagation, power-aware verification, and timing — are now covered. Section E turns from what gets checked to how a team plans, tracks, and ultimately decides a verification effort covering all of this is actually complete.