Skip to content

Timing Closure

Richard Huang edited this page Aug 3, 2026 · 2 revisions

Timing Closure

Timing closure is the iterative process of making every path in the design meet its timing requirement across every operating condition. It isn't a single stage — it runs alongside Placement, Clock Tree Synthesis, and Routing, tightening as estimates become real.

It is usually the longest phase of a tapeout, and the one most likely to slip the schedule.


Objectives

  • Zero setup violations — the chip runs at target frequency
  • Zero hold violations — the chip works at any frequency (hold failures are unfixable in silicon)
  • Clean design rules — max transition, max capacitance, max fanout
  • Across all corners — every PVT combination, every mode
  • Without wrecking area and power — closure by brute-force upsizing is a bad trade

The Two Checks

Setup:  T_clk  ≥  t_cq + t_logic + t_setup − t_skew + t_uncertainty
Hold:   t_cq + t_logic  ≥  t_hold + t_skew
Setup Hold
Question Is the path fast enough? Is the path too fast?
Fix by Making logic faster Adding delay
Frequency Fixable by slowing the clock Not fixable by clocking — silicon is dead
Worst corner Slow (hot, low voltage) Fast (cold, high voltage)
When it appears Throughout Mostly after Clock Tree Synthesis

Slack = required time − arrival time. Negative slack is a violation. WNS is the worst single path; TNS is the sum of all negative slack — WNS tells you how broken, TNS tells you how much work.

Hold deserves respect: a hold violation means the chip is broken at every frequency. Never ship with hold violations, and never assume you'll "fix it in test."


Why Timing Changes Through the Flow

Stage Clock model Parasitics Reality
Synthesis Ideal Wireload estimate Fantasy
Post-placement Ideal Placement estimate Directional
Post-CTS Propagated Placement estimate Skew is now real; hold violations appear
Post-route Propagated Extracted (SPEF) Real
Signoff Propagated Extracted + SI Authoritative

Each transition typically makes timing worse. Engineers who celebrate clean pre-CTS timing get an unpleasant surprise twice. Carry realistic clock uncertainty in Design Constraints so the optimizer leaves margin for what it can't yet see.


MMMC: Multi-Mode Multi-Corner

Real chips must work across process variation, voltage range, and temperature — in every functional mode.

  • Corners — combinations of process (slow/typical/fast), voltage, temperature, and RC (Cmax/Cmin/RCmax/RCmin)
  • Modes — functional, scan shift, at-speed test, low-power
  • Views = mode × corner, each analysed independently

A design with 4 corners and 3 modes has 12 views. Every one must pass. This is why MMMC setup is defined once and reused across synthesis, implementation, and signoff — see Design Constraints.

On-chip variation (OCV) models the fact that two identical gates on the same die behave differently. Tools derate launch and capture paths in opposite directions to be pessimistic. Modern flows use AOCV (distance- and depth-dependent) or POCV (statistical) to reduce that pessimism, plus CPPR (common path pessimism removal) to credit back the shared clock path that was double-derated.


Fixing Techniques

Setup

Technique Cost
Upsize cells on the critical path Area, leakage, load on the previous stage
Restructure logic to reduce depth Netlist diverges from synthesis
Promote long nets to upper metal Consumes scarce upper-layer resource
Insert/rebalance buffers Area and power
Useful skew — borrow time from an adjacent stage Reduces that stage's margin
Use low-Vt cells Leakage power, sometimes dramatically
Fix the floorplan so the path is shorter Schedule, but the best real fix

Hold

Technique Cost
Insert delay buffers Area, power — usually thousands of cells
Downsize/swap to slower cells Can hurt setup on the same path
Use high-Vt cells Slower — check setup doesn't break
Route detour Rarely worth it

Fix setup first, then hold. Hold fixes add delay, and doing them before setup is settled means redoing them.


Cadence Innovus / Tempus Flow

# Optimization at each stage
opt_design -pre_cts
opt_design -post_cts
opt_design -post_cts -hold
opt_design -post_route
opt_design -post_route -hold

# Reports
report_timing -max_paths 100 -path_group reg2reg
report_timing -early -max_paths 100          ;# hold paths
report_timing_summary                        ;# WNS/TNS per view
report_constraint -all_violators
report_analysis_coverage                     ;# are all paths actually checked?

# Path groups isolate where the problem lives
group_path -name in2reg  -from [all_inputs]
group_path -name reg2out -to   [all_outputs]
group_path -name reg2reg -from [all_registers] -to [all_registers]

Signoff STA in Tempus:

read_lib -max slow.lib -min fast.lib
read_verilog design.routed.v
read_spef design.spef
read_sdc top.sdc
set_analysis_mode -analysis_type onChipVariation -cppr both
update_timing
report_timing -max_paths 100
  • read_spef — real extracted parasitics; this is what makes signoff authoritative
  • -cppr both — removes double-counted pessimism on the shared clock path
  • report_analysis_coverage — catches paths that are silently unconstrained, a classic way to tape out a broken chip

Reading a Timing Report

A path report shows the launch clock path, the data path, and the capture clock path. What to look for:

Observation Diagnosis
Net delay ≫ cell delay Physical problem — long wire, bad Floorplanning
Cell delay ≫ net delay Logic problem — too many levels, weak cells
Many levels of logic Restructure, or pipeline in RTL
Large clock skew term Clock Tree Synthesis issue
Huge uncertainty Over-conservative constraints
Slack similar across hundreds of paths Systemic — frequency target may be wrong

That first row is the most important habit to build: always compare net delay to cell delay. It tells you instantly whether the fix is physical or logical.


Metrics

Metric Target Notes
WNS ≥ 0 across all views One path can hold the whole design
TNS 0 Large TNS with small WNS = many marginal paths
NVP (number of violating paths) 0 Trend it run over run
Hold WNS ≥ 0, no exceptions Non-negotiable
DRV count 0 max_tran / max_cap / max_fanout
Leakage power Within budget Watch low-Vt usage creeping up
Analysis coverage ~100% Uncovered paths are unverified paths

Common Problems

Problem Root cause Fix
One path far worse than the rest Structural — long wire or deep cone Look at net vs cell delay; likely floorplan
Thousands of small violations Frequency target too aggressive, or clock uncertainty too large Re-examine constraints before optimizing
Setup fixed, hold explodes Upsizing sped up short paths too Fix setup fully, then hold, then re-check setup
Timing fine in one view, fails another Corner-specific behaviour Check per-view; often the fast corner for hold
Closure achieved but leakage doubled Low-Vt swapping used freely Constrain low-Vt percentage
Passes without SI, fails with Crosstalk delta delay Shield/space aggressors — see Routing
Paths not reported at all Missing constraint or over-broad false path report_analysis_coverage, report_exceptions
Endless iteration, no convergence Trying to fix a floorplan problem with optimization Stop and revisit Floorplanning

The exception trap: a set_false_path that hides a real path produces a chip that fails in silicon while every report is green. Every exception needs a documented reason and a reviewer.


Best Practices

  • Diagnose before optimizing. Read the worst path and understand why it fails. Blind effort-level increases waste days.
  • Use path groups. reg2reg, in2reg, reg2out, and clock-domain groups tell you where the problem actually lives.
  • Close setup before hold, then re-verify setup.
  • Track WNS/TNS run over run. A plateau means you're at a structural limit.
  • Be suspicious of clean reports. Check coverage and exceptions.
  • Keep low-Vt usage on a budget — it's the easiest way to close timing and blow the power spec.
  • Escalate structural problems early. If closure needs a floorplan change, week 3 is cheap and week 20 is not.
  • Sign off with extracted parasitics and SI enabled. Anything else is an estimate.

See also: Design Constraints · Clock Tree Synthesis · Routing · Signoff · Physical Design

Clone this wiki locally