MODULE 1 / 12 · FREE PREVIEW

Timing Foundations

A chip that computes the right answer too late computes the wrong answer. This module installs the physical bedrock — what delay and slew actually are, why a resistor and a capacitor rule your career — and the worldview that lets STA verify a billion paths without simulating a single vector.

4 topics4 labs~65 min

Why Static Timing Analysis

in plain words Imagine hiring a security guard who never misses a shift but sometimes flags innocent visitors as suspicious. STA is that guard. It checks every possible timing path in your chip (billions of them) without simulating every input pattern. It never misses a real violation — but it does occasionally complain about paths that could never actually fail in real use. The "founding bargain" is: accept a little over-caution to guarantee completeness.

Functional verification asks "does the logic compute the right values?" Timing verification asks a different question: does every value arrive before the clock edge that consumes it? You could try to answer it dynamically — simulate with delays, watch waveforms — but timing depends on which paths the data actually exercises, and exercising all of them needs every input/state combination. The lab below lets you feel how fast 2ⁿ kills that plan.

Static timing analysis abandons vectors entirely. It reads the design as a graph: pins are nodes, timing arcs (through cells, along nets) are edges. It computes the worst-case arrival time at every node by propagating delays through the graph — once, input-independently — and compares each arrival against the time the consuming flop requires. Three properties make this the signoff standard:

  • Complete — every structural path is covered, including ones no sane testbench would ever sensitize.
  • Fast — graph traversal is roughly linear in design size; a full SoC times overnight, not over a career.
  • Conservative — worst-case assumptions everywhere mean false alarms happen (a "violating" path that's never functionally exercised — Module 7 handles those), but a clean STA report means silicon timing is safe. Pessimism is the price; Modules 9's CRPR is the refund counter.
Where STA sits in the flow: after synthesis (rough netlists, estimated wires), through placement and routing (increasingly real parasitics — see our RouteForge course), and finally signoff STA with extracted RC, multiple corners, and SI — the report a tapeout decision rests on. Same engine, increasingly honest inputs.

STA's conservatism means a clean report implies…

Worst-casing never under-reports real problems; it over-reports impossible ones. That asymmetry is exactly what you want at signoff.

STA needs no input vectors because it…

The graph abstraction replaces stimulus: every arc contributes its worst delay, every path is implicitly walked.

A timing-clean chip can still fail in the field if…

STA verifies the design AGAINST THE CONSTRAINTS. Garbage in, signoff out. Module 6 exists because of this sentence.

Delay, Slew & Transition

in plain words A light switch looks instant — flick it and the light is on. But inside a chip, every "switch" is a tiny transistor charging a capacitor through a resistor. The voltage rises like water filling a glass: slowly at first, then faster, then slowing down near the top. Delay measures how long until it reaches halfway. Slew measures how long the ramp takes total. A slow (high-slew) signal going into the next gate makes the next gate also slow — delays compound down the chain.
t IN ideal IN real OUT cell delay output slew 50% Delay and Slew
Cell delay and slew. The ideal step (dashed) becomes a ramp in silicon. Cell delay is the 50%→50% spacing between input and output transitions; output slew is the 20%→80% ramp time. Both are load- and input-slew-dependent — hence the NLDM table in Module 2.

Digital diagrams draw vertical edges; silicon draws ramps. Two measurements characterize every transition:

  • Delay — measured between the 50% points of input and output crossings (conventions vary slightly per library, but half-rail is standard).
  • Slew / transition time — how long the edge itself takes, measured between threshold points (commonly 10–90% or 20–80% of VDD; the .lib states which).

The non-obvious part — the thing that makes slew a first-class citizen of STA rather than trivia — is that slew propagates. A slow edge at a gate's input means its transistors switch gradually, so the gate responds more slowly and produces a degraded output edge, which slows the next gate. Delay depends on input slew and output load; output slew also depends on both. That's why Module 2's library tables are two-dimensional, indexed by exactly those two quantities, and why STA must carry (arrival, slew) pairs through the whole graph, not just arrivals.

VDD 0 crisp edge · fast slew degraded edge · slow slew 50% a slow edge entering the next gate makes THAT gate slow too — slew is contagious
The two measurements. Delay between 50% crossings; slew across the edge itself. Both flow downstream.
Slow slews are also power and noise bugs: while an input ramps through the middle voltages, both the pull-up and pull-down networks conduct simultaneously (short-circuit current), and the net spends maximum time vulnerable to crosstalk (Module 11). max_transition design rules exist to cap all three problems at once.

Cell delay in a .lib is a function of…

The two-dimensional truth behind every NLDM table — Module 2 makes you interpolate one by hand.

STA propagates slew along with arrival time because…

(arrival, slew) is the real propagated tuple. Slew merging at reconvergence is even a source of subtle tool pessimism.

RC: the Physics of Late

in plain words Charge a phone through a thin (high-resistance) cable: it's slow. Use a thick (low-resistance) cable: fast. Same battery (capacitance), different cables (resistance). The RC time constant (τ = R × C) captures this exactly: bigger R or bigger C → slower charging → higher delay. Every gate, every wire in a chip is secretly just an RC circuit doing this charging math.

Strip any digital delay to its skeleton and you find the same machine: a resistance charging a capacitance. The driving gate's transistors are the R (stronger gate = lower R); the wire and every input pin hanging on it are the C. The output voltage follows the exponential:

V(t) = VDD · (1 − e^(−t/τ)),   τ = R·C
t(50%) ≈ 0.69·τ      // the delay measurement
t(90%) ≈ 2.3·τ       // the slew tail — why slow edges drag on

From this single equation, read off the design levers you'll use forever:

  • Upsize the driver → R halves → delay halves. (But the bigger gate presents more input capacitance to its driver — sizing is a chain negotiation, the heart of Module 12's ECOs.)
  • Reduce the load → fewer fanouts, shorter wire → C drops.
  • Split long wires with buffers → wire delay grows with the square of length (R and C both grow linearly); a repeater in the middle turns one quadratic into two small quadratics. This is why routed designs are full of buffers (RouteForge covers the insertion side).
Mental arithmetic that impresses in reviews: τ for a typical mid-strength driver on a short net is tens of picoseconds. A millimeter of minimum-width wire at an advanced node can be hundreds of Ω and ~200 fF — wire τ alone rivals several gate delays. When someone asks "why is this path slow", check the wire before the gates.

A wire doubles in length. Its unbuffered delay roughly…

τ = RC with both linear in length ⇒ quadratic delay. The single best argument for repeaters ever written.

Upsizing a driver helps the current stage but…

Every sizing decision exports capacitance upstream. Chains of gates have an optimal taper (≈e× per stage for pure drivers) — and ECO tools negotiate this constantly.

The STA Worldview

in plain words STA is like a chess engine that can evaluate every legal position but cannot tell you whether a human player will ever actually reach it. It sees all structural paths; it cannot see functional reachability. That's why a "false path" (a logic path that's structurally there but can never be exercised in real operation) still shows up as a potential violation until you tell the tool to ignore it.

Before the deep modules, calibrate on what STA fundamentally is and is not. The tool's world contains exactly: a netlist (cells + connectivity), libraries (Module 2), parasitics (Module 8), and your constraints (Modules 6–7). From those it computes arrivals, requireds, and slacks. It does not know what your logic means, which states are reachable, or what the chip is for.

STA checksSTA cannot check
setup & hold at every flop, every cornerfunctional correctness (verification's job)
min/max delays on constrained pin-to-pin pathsasynchronous crossing PROTOCOL correctness (CDC tools — Module 11)
clock-gating setup/hold (glitch-safe enables)whether your constraints describe reality
design rules: max_transition, max_capacitance, max_fanoutanalog behavior, exotic circuits it has no arcs for
recovery/removal on async set/reset deassertiondynamic supply droop (separate analysis feeds derates)

Internalize the implication: STA is a constraint amplifier. Correct constraints → exhaustive verification for free. Wrong constraints → exhaustively verified nonsense, stamped "signoff clean". This is why senior engineers review SDC like contract lawyers (Module 6 trains you to be one) and why every timing course that skips constraints produces dangerous graduates.

"STA is a constraint amplifier" means…

The tool verifies the world you DESCRIBED. The description is the single point of failure — hence constraint review culture.

Recovery/removal checks apply to…

Assertion is async by design; the danger is releasing reset too close to a clock edge — recovery (like setup) and removal (like hold) time it.