Setup & Hold Time and STA Basics

A synchronous chip works because every flip-flop captures stable data on each clock edge. Two timing constraints make that possible: data must be steady for a short window before the edge (setup time) and for a short window after it (hold time). Static timing analysis (STA) is how engineers prove, without simulating a single vector, that every path in the design respects those windows at every corner. This page walks the timing path end to end, defines slack and the WNS/TNS numbers you live by, explains why setup fails at the slow corner and hold fails at the fast corner, and is honest about what open-PDK STA evidence can and cannot tell you.

Setup time vs hold time

A flip-flop’s D input has to be stable for a small interval before the active clock edge — the setup time — and for a small interval after it — the hold time. If data changes inside either window, the flop can capture the wrong value or, worse, go metastable. The two checks fail in opposite directions. A setup violation means data arrived too late: the path from one flop to the next is slower than the clock period allows. A hold violation means data arrived too early and raced through to the capture flop within the same edge, before the previous value was safely latched. The crucial asymmetry: a setup problem is cured by slowing the clock, but a hold problem is a structural race that cannot be fixed by lowering frequency — it has to be fixed by adding delay to the short path.

The timing path: launch, logic, capture

STA reasons about paths, not waveforms. A register-to-register path has a launch flop that drives data out on a clock edge, a block of combinational logic the data passes through, and a capture flop that samples the result on the next edge. The data’s arrival time is the sum of three pieces: the launch flop’s clock-to-Q delay (how long after its clock edge the output settles), the combinational delay through the logic and wires, and the routing to the capture flop’s D input. STA computes that arrival for every path by adding up the delays from a delay model (the Liberty timing library plus extracted or estimated parasitics), and compares it against the time the data is actually required to be stable.

Slack, WNS, and TNS

The single most important number in STA is slack, and it is just a subtraction:

slack = required arrival time − actual arrival time

Positive slack means the path met timing with margin to spare. Negative slack means it failed, and the magnitude tells you by how much. STA rolls those per-endpoint slacks into two design-level figures. WNS (Worst Negative Slack) is the most negative slack anywhere in the design — the single worst path, and the headline number for whether you closed timing. TNS (Total Negative Slack) is the sum of every negative slack across all failing endpoints, so it captures both how badly and how widely timing is missed: a WNS of −0.05 ns with a TNS of −0.05 ns is one stray path, while the same WNS with a TNS of −40 ns is a systemic problem. A corner is timing-clean only when WNS and TNS are both non-negative.

A worked setup-slack example

The setup check on a single-clock register-to-register path expands the slack equation into terms you can read off a timing report. Required time is the clock period minus the capture flop’s setup time, adjusted by clock skew; arrival is clock-to-Q plus combinational delay. The example below shows the same path passing by a hair at one corner and failing at a slightly slower one, which is exactly how WNS appears.

// One register-to-register setup path, single clock of period T.
//
//   launch FF --[ clock-to-Q ]--> combinational logic --> [ setup ] capture FF
//        ^                                                              ^
//        |------------------------ clock ------------------------------|
//
// Data ARRIVAL at the capture flop's D input:
//     arrival = t_clk2q + t_comb            (when the data actually shows up)
//
// REQUIRED time for that data to be valid for the next edge:
//     required = T - t_setup + t_skew       (skew = capture-clock minus launch-clock)
//
// SETUP SLACK is just the margin between them:
//     slack = required - arrival
//           = (T - t_setup + t_skew) - (t_clk2q + t_comb)
//
//   slack >= 0  -> path MET timing for this corner (margin to spare)
//   slack <  0  -> path FAILED; its magnitude is this endpoint's negative slack
//
// Worked example (slow corner): T = 5.00 ns
//     t_clk2q = 0.30, t_comb = 4.40, t_setup = 0.20, t_skew = 0.00
//     arrival  = 0.30 + 4.40              = 4.70 ns
//     required = 5.00 - 0.20 + 0.00       = 4.80 ns
//     slack    = 4.80 - 4.70             = +0.10 ns  (PASS, barely)
//
// Same path, +0.25 ns slower logic at a slower corner -> arrival 4.95 ns
//     slack    = 4.80 - 4.95             = -0.15 ns  (FAIL -> WNS = -0.15)

Why setup fails slow and hold fails fast

Gate and wire delays are not constant; they move with process, voltage, and temperature (PVT). At the slow corner — slow silicon, low supply voltage, often high temperature — logic takes longer, so data arrives later and setup is at greatest risk. At the fast corner — fast silicon, high voltage, low temperature — logic is quickest, data races through sooner, and hold is at greatest risk because a short path can deliver new data to the capture flop before its hold window closes. That is the core reason STA is never a single run: setup and hold are checked at the corners where each is most likely to break.

Why multi-corner analysis is mandatory

Because setup and hold fail at opposite ends of the PVT envelope, checking one corner can certify a design that breaks at another. A run that is clean at the typical corner can hide a setup failure at the slow corner and a hold failure at the fast corner simultaneously. Production flows therefore evaluate a set of corners — typically fast, slow, and typical, sometimes more — each backed by its own Liberty characterization, and a path is only signed off when it passes the relevant check at every corner. Multi-corner STA is what turns “it met timing in my one run” into “it met timing across the operating envelope.”

Clock skew and uncertainty

The clock does not arrive at every flop at the same instant. The difference in arrival between the launch and capture clocks is clock skew, and it shifts the slack equation directly: positive skew toward the capture flop relaxes setup but tightens hold, and the reverse for negative skew. On top of measured skew, STA budgets clock uncertainty — a margin that absorbs jitter, modeling error, and on-chip variation that the static delay model cannot pin down exactly. Both are subtracted from the available time, so a path that looks comfortable with an ideal clock can be tight once realistic skew and uncertainty are folded in. This is also why the quality of the clock tree, built during clock-tree synthesis in the RTL-to-GDSII flow, has such a direct effect on timing closure.

Where STA sits next to other signoff checks

STA is one gate among several, and it has blind spots that other checks cover. It assumes a synchronous design and cannot reason about asynchronous clock crossings, so a missing synchronizer is invisible to it — that is the domain of CDC analysis. It checks timing on the gate-level netlist but says nothing about whether that netlist still implements your RTL, which is what logical equivalence checking proves. And timing closure is only one column on the broader tapeout-readiness checklist, alongside DRC, LVS, and DFT scan readiness. Treat STA as the timing evidence in that set, not the whole signoff.

What open-PDK STA evidence can — and cannot — tell you

Running STA with OpenSTA against an open Liberty library (sky130 or gf180) produces real numbers: per-path slack, WNS, and TNS, computed across fast, slow, and typical corners from open cell characterization. That is genuinely useful pre-signoff timing evidence — it tells you which paths are tight, how negative your worst slack is, and whether a change helped or hurt, all before you commit to expensive flow steps.

What it cannot do is stand in for a foundry timing signoff on a commercial node. A production signoff relies on the foundry’s qualified, silicon-correlated cell libraries, signoff-grade parasitic extraction, on-chip-variation and advanced delay models, and an accountable sign-off — none of which open-PDK STA can replace. The honest framing is the same one ChipVerify uses everywhere: pre-signoff timing evidence on open PDKs, not a foundry-characterized signoff, not a certification, and not a guarantee of silicon behaviour.

How ChipVerify checks this

ChipVerify AI runs multi-corner static timing analysis with OpenSTA against open Liberty libraries, returning slack, WNS, and TNS across fast, slow, and typical corners with the failing paths identified. We describe this as pre-signoff timing evidence on open PDKs — bounded analysis that surfaces timing risk early — not a foundry signoff, not a certification, and not a replacement for a commercial signoff-grade timing flow on a characterized node.

FAQ

Related reading

• RTL to GDSII on sky130 — where clock-tree synthesis and the timing numbers come from.
• Logical equivalence checking — proving the timed netlist still matches your RTL.
• Tapeout readiness — the full set of gates, with timing as one of them.
• DFT & scan readiness — the test-side checks that sit alongside timing closure.