What are the four types of timing paths in STA?

The four timing path types are: (1) Input-to-register, (2) Register-to-register (most common), (3) Register-to-output, and (4) Input-to-output (purely combinational).

What does slack mean in STA?

Slack is the timing margin. Positive slack means timing is met. Negative slack means a violation. Setup slack = (Tclk minus Tsetup) minus Tdata_path. The critical path has the worst (most negative) slack.

DAY 1 · STA FUNDAMENTALS

What is Static Timing Analysis?

Q: What is Static Timing Analysis?

Static Timing Analysis (STA) is the process of verifying that a digital circuit meets its timing constraints without running simulation. It traces every possible timing path through the design, computes the worst-case delay along each path, and checks whether setup and hold time requirements are met at every flip-flop.

By EcrioniX · Updated June 2026

Every chip that goes to tapeout must pass Static Timing Analysis. It is the primary method used to verify that a digital design meets its timing constraints — that signals propagate fast enough to meet setup time, and slow enough not to violate hold time. Understanding STA is not optional for a VLSI engineer: it is the language the entire industry speaks from synthesis to sign-off.

1. The problem STA solves

A modern SoC has hundreds of millions of flip-flops. Every flip-flop has a setup time requirement: data must be stable for a minimum window before the clock edge arrives. If any signal — anywhere, across any combination of inputs — arrives too late, the chip fails.

The naive approach is simulation: apply input vectors, measure timing. But a design with even 1,000 flip-flops has more possible states than atoms in the observable universe. You cannot simulate them all. A simulation might run for weeks and still miss the one input combination that causes a timing violation.

Static Timing Analysis solves this by working on the circuit graph directly. It traces every possible timing path through the netlist, computes the worst-case delay along each path, and checks whether constraints are met — without applying a single input vector. This makes STA exhaustive by construction.

STA is not functional verification

STA verifies timing only — that signals arrive at the right time. It does not verify function — that signals carry the correct values. A design can pass STA perfectly and still have a logic bug. Simulation and formal equivalence checking handle functional correctness. You need both.

2. Static vs Dynamic timing analysis

Property	Static Timing Analysis	Dynamic Simulation
Input vectors needed?	No — analyzes all paths structurally	Yes — timing depends on applied stimuli
Coverage	100% of paths checked exhaustively	Only paths exercised by test vectors
Speed	Minutes to hours on a full chip	Days to weeks for equivalent coverage
What it checks	Setup, hold, recovery, removal, pulse width	Whatever the testbench exercises
Functional bugs	Cannot detect	Can detect
Industry use	Mandatory sign-off method for all ASICs	Functional verification, not timing sign-off

3. What STA actually does — step by step

The STA tool reads three inputs: the gate-level netlist, extracted parasitics (SPEF), and SDC constraints. It then:

Builds a timing graph — directed graph where nodes are pins, edges carry delay values from Liberty models
Propagates clock arrival times forward from all clock sources through the clock network
Propagates data arrival times forward from all startpoints through combinational logic
Computes slack at each endpoint — the margin between required and actual arrival time
Reports violations — any path with negative slack is a timing failure

Slack = Required Time − Arrival Time

Setup slack = (T_clk − T_setup) − T_{data_path} | Hold slack = T_{data_path} − T_hold

Positive slack → timing met | Negative slack → violation | Worst slack path = critical path

4. The four types of timing paths

TYPE 1

Input → Register

From a primary input port to the data pin (D) of a flip-flop. Constrained by set_input_delay in SDC.

TYPE 2

Register → Register

From the clock pin (CK) of one FF through combinational logic to the data pin (D) of another FF. The most common path — checked for both setup and hold.

TYPE 3

Register → Output

From the clock pin of a FF through combinational logic to a primary output port. Constrained by set_output_delay in SDC.

TYPE 4

Input → Output

Purely combinational — from a primary input directly to a primary output with no flip-flops in the path.

Figure — The four STA timing path types. Register-to-register (Type 2) is most numerous. Input/output paths require SDC constraints to define external timing.

5. The five timing checks STA performs

Check	Where	What it verifies	Fix if violated
Setup	FF data pin (D)	Data stable before clock edge by T_setup	Shorten data path; upsize cells; use LVT
Hold	FF data pin (D)	Data stable after clock edge for T_hold	Insert delay buffers on data path
Recovery	FF async reset pin	Async reset de-asserted before active clock edge	Fix reset synchronizer timing
Removal	FF async reset pin	Async reset held for minimum time after clock edge	Fix reset assertion timing
Pulse width	FF clock pin	Clock high/low pulse meets minimum width	Fix clock gating or division logic

6. STA tools in the industry

Tool	Vendor	Use
PrimeTime (PT)	Synopsys	Industry-standard ASIC sign-off — used at virtually every semiconductor company
Tempus	Cadence	Integrated with Innovus PnR; sign-off grade
DesignCompiler (DC)	Synopsys	Synthesis-time STA — estimation only, not sign-off
Vivado Timing	AMD/Xilinx	FPGA timing analysis
Quartus Timing	Intel	Intel FPGA timing analysis

This course uses Synopsys PrimeTime syntax

All SDC commands, timing reports, and flows in this course are written in PrimeTime format — the industry standard for ASIC sign-off. The concepts apply equally to Cadence Tempus; command syntax is nearly identical.

7. A minimal PrimeTime session

To run STA with PrimeTime you need three inputs: gate-level netlist, Liberty libraries, and an SDC file.

run_sta.tcl — minimal PrimeTime script

## 1. Read Liberty library (standard cell timing model)
read_lib /pdk/tsmc28/typical/sc9_cln28hp_svt_ff0p99vg25c.lib

## 2. Read the gate-level netlist
read_verilog /design/out/soc_top.v
link_design soc_top

## 3. Read extracted parasitics (post-layout RC values from router)
read_parasitics /design/out/soc_top.spef

## 4. Apply SDC timing constraints (clocks, I/O delays, exceptions)
source /design/constraints/soc_top.sdc

## 5. Setup check -- worst 10 paths
report_timing -max_paths 10 -delay_type max \
              -path_type full_clock_expanded

## 6. Hold check -- worst 10 paths
report_timing -max_paths 10 -delay_type min \
              -path_type full_clock_expanded

## 7. Summary: worst negative slack (WNS) and total negative slack (TNS)
report_timing_summary

What the output tells you

report_timing prints the full path from startpoint to endpoint: every cell delay, net delay, clock arrival time, required time, and slack. report_timing_summary shows WNS (Worst Negative Slack) and TNS (Total Negative Slack). If WNS is negative, timing is violated. Day 11 covers reading and interpreting these reports in full detail.

8. What STA cannot check

Functional correctness — STA verifies timing, not logic. A path can pass timing and still compute the wrong value.
Async clock domain paths — paths between unrelated clocks have no fixed phase relationship; STA cannot check them. CDC tools handle these.
Incorrectly declared false paths — paths excluded with set_false_path are invisible to STA. A wrong declaration masks real violations.
Power-on reset sequencing — handled by low-power/UPF tools, not STA.
Analog and thermal effects — accounted for indirectly via PVT corner selection and OCV derating (Days 6 and 7).

Day 1 Key Takeaways

STA is exhaustive — checks every timing path without input vectors; simulation cannot match this coverage
STA checks timing, not function — still need simulation and formal verification for correctness
Four path types — input-to-reg, reg-to-reg (most common), reg-to-output, input-to-output
Five timing checks — setup, hold, recovery, removal, pulse width
Slack = Required − Arrival — positive means timing met; negative means violation
WNS / TNS — WNS is the worst single path violation; TNS is the total work to close timing
Three inputs needed — netlist + parasitics (SPEF) + constraints (SDC)
PrimeTime is the industry standard — all ASIC tapeouts require PT sign-off

Frequently Asked Questions

What is the difference between STA and gate-level simulation?

Gate-level simulation applies specific input vectors and checks timing using SDF back-annotation — only paths your testbench activates. STA checks every path structurally without vectors. Use both: STA for complete timing sign-off, gate-level sim for corner-case functional verification at specific operating points.

Can STA be run before physical design?

Yes — synthesis tools run STA using estimated wire delays (wireload models). This is pre-layout STA. It is less accurate but fast, useful for early timing feedback. Post-layout STA uses actual extracted RC parasitics from the routed design and is the sign-off standard.

What is the critical path?

The critical path is the timing path with the worst (most negative) setup slack — the path that limits maximum operating frequency. Fixing the critical path reveals the next-worst path. Timing closure is the iterative process of fixing critical paths until all slacks are non-negative.

What is SDC?

Synopsys Design Constraints (SDC) is a Tcl-based format for specifying timing requirements: clock frequencies, clock relationships, I/O delays, timing exceptions (false paths, multicycle paths), and load/drive constraints. Without a correct SDC, STA produces meaningless results. Day 4 covers SDC in full.

What is WNS and TNS?

WNS (Worst Negative Slack) is the most negative slack across all timing paths — the worst single violation. TNS (Total Negative Slack) is the sum of all negative slacks. WNS tells you severity; TNS tells you total work needed to close timing.