The PrimeTime timing report is the primary output of STA. Every line tells you something specific about the timing path: where the clock came from, what happened to it at each cell, when the data arrived, when it needed to arrive, and whether the design passed or failed. Being able to read a timing report fluently — without looking anything up — is a core skill for any STA or physical design engineer.
1. The anatomy of a timing report
A full report_timing -path_type full_clock_expanded report has five sections:
Header — path group, analysis type, startpoint, endpoint, path type
Launch clock network — clock arrival at the launch flip-flop’s CK pin
Data path — clock-to-Q then each combinational gate and wire
Capture clock network — clock arrival at the capture flip-flop’s CK pin
Required time / slack — the deadline, uncertainty, setup time, and final slack
Startpoint: u_core/ff_launch (rising edge-triggered flip-flop clocked by clk_core)
Endpoint: u_core/ff_capture (rising edge-triggered flip-flop clocked by clk_core)
Path Group: clk_core
Path Type: max <- max = setup check; min = hold check
Point Incr Path
──────────────────────────────────────────────────────
clock clk_core (rise edge) 0.00 0.00 <- t=0: clock reference edge
clock source latency 0.20 0.20 <- board/PLL delay to chip pad
CLK_PAD (in) 0.00 0.20
BUF_ROOT/Z (rise) [ck_net_1] 0.14 0.34 <- clock tree root buffer
BUF_SPINE/Z (rise) [ck_net_2] 0.12 0.46
BUF_BRANCH/Z (rise) [ck_net_3] 0.09 0.55 <- local clock buffer
u_core/ff_launch/CK (rise) 0.00 0.55 <- launch FF clock arrival
u_core/ff_launch/Q (rise) 0.08 0.63 <- clk-to-Q delay (from Liberty)
u_core/U1/A (rise) [net_a] 0.03 0.66 <- wire delay on net_a
u_core/U1/Z (fall) 0.07 0.73 <- gate delay AND1X4
u_core/U2/A (fall) [net_b] 0.04 0.77 <- wire delay on net_b
u_core/U2/Z (rise) 0.09 0.86 <- gate delay OR2X2
u_core/U3/A (rise) [net_c] 0.02 0.88 <- wire delay
u_core/U3/Z (fall) 0.06 0.94 <- gate delay INV_X2
u_core/ff_capture/D (fall) [net_d] 0.02 0.96 <- final wire, data arrives
data arrival time 0.96
── Required Time Computation ──────────────────────────
clock clk_core (rise edge) 2.00 2.00 <- next clock edge (period)
clock source latency 0.20 2.20
CLK_PAD (in) 0.00 2.20
BUF_ROOT/Z (rise) [ck_net_1] 0.14 2.34 <- same tree as launch
BUF_SPINE/Z (rise) [ck_net_2] 0.12 2.46
BUF_CAP_BRANCH/Z (rise) [ck_net_4] 0.10 2.56 <- different leaf buffer
u_core/ff_capture/CK (rise) 0.00 2.56 <- capture FF clock arrival
clock reconvergence pessimism 0.04 2.60 <- CPPR correction (+slack)
clock uncertainty -0.08 2.52 <- subtract uncertainty
library setup time -0.05 2.47 <- subtract FF setup requirement
required time 2.47
──────────────────────────────────────────────────────
data required time 2.47
data arrival time -0.96
──────────────────────────────────────────────────────
slack (MET) 1.51 <- positive = timing met
3. Line-by-line explanation
Startpoint and Endpoint
The startpoint is where the timing path begins — either a flip-flop clock pin (for reg-to-reg paths) or an input port (for input-to-reg paths). The endpoint is where the path ends — either a flip-flop data input (D pin) or an output port.
The clock name in parentheses tells you which clock drives the startpoint. If a path has a different clock at startpoint vs endpoint, it’s a clock domain crossing path.
Path Type: max vs min
Path Type: max means this is a setup analysis — the tool is looking for the latest data arrival (maximum path delay). Path Type: min means hold analysis — the tool is looking for the earliest data arrival (minimum path delay).
Incr and Path columns
Every line in the path section has two numbers: Incr (the incremental delay added at this point) and Path (the running cumulative total from t=0). Always read the Path column to track total progress. The Incr column helps identify which cell or wire contributes the most delay.
Clock network delay (propagated)
The launch clock section shows how the clock edge propagates through the clock tree to reach the launch flip-flop. Each buffer appears as a line with its gate delay. The wire delay is shown as the net name in brackets. The total clock delay to the launch FF is the Path value at the ff_launch/CK line (0.55 ns in the example).
Data path section
Beginning at ff_launch/Q (clock-to-Q delay), the data section shows every gate and wire the signal passes through. The first value at Q is the flip-flop’s clock-to-Q propagation delay (from Liberty). Each subsequent line alternates between net (wire) delays and cell output delays.
Required time computation
The required time starts from the next clock edge (period = 2.00 ns), follows the capture clock tree to the capture FF’s CK pin (2.56 ns), then applies three adjustments:
CPPR correction (+0.04 ns) — adds back pessimism removed from shared clock path segments
Clock uncertainty (-0.08 ns) — subtracts jitter and margin
Library setup time (-0.05 ns) — subtracts the flip-flop’s setup time requirement from Liberty
Required time = 2.47 ns. Slack = 2.47 - 0.96 = 1.51 ns (MET).
4. Understanding WNS, TNS, and NVP
Metric
Definition
Sign-off target
WNS (Worst Negative Slack)
The single most negative slack across all paths. If WNS = -0.080 ns, your worst path fails by 80ps.
WNS ≥ 0 at all corners
TNS (Total Negative Slack)
Sum of all negative slack values. WNS can be -0.010 while TNS is -2000 if there are thousands of paths each failing by a small amount.
TNS = 0 (no violating paths at all)
NVP (Number of Violating Paths)
Count of paths with negative slack. Useful for estimating closure effort.
NVP = 0
WHS (Worst Hold Slack)
Most negative hold slack (hold analysis equivalent of WNS). Must be ≥ 0.
WHS ≥ 0 at all corners
THS (Total Hold Slack)
Sum of all negative hold slacks.
THS = 0
5. report_timing_summary
report_timing_summary — reading the summary
## Run timing summary across all path groups
report_timing_summary -significant_digits 4
## Sample output:
## ──────────────────────────────────────────────────────────────────────
## Path Group WNS TNS NVP (Setup Analysis, SS/0.9V/125C)
## ──────────────────────────────────────────────────────────────────────
## clk_core -0.0420 -12.840 87 <- 87 setup violations!
## clk_usb 0.2100 0.000 0 <- clean
## clk_ddr -0.0180 -0.360 4 <- 4 DDR violations
## INOUT_PATHs 0.0550 0.000 0 <- input-output paths clean
## ──────────────────────────────────────────────────────────────────────
## Total -0.0420 -13.200 91
## For hold (min analysis):
report_timing_summary -delay_type min -significant_digits 4
## Path Group WHS THS NVP (Hold Analysis, FF/1.1V/-40C)
## clk_core 0.0350 0.000 0 <- hold clean
## clk_ddr -0.0120 -0.084 7 <- hold violations on DDR!
6. Useful report_timing flags
report_timing — essential flags and examples
## Basic setup timing (top 5 paths)
report_timing -delay_type max -nworst 5
## Hold timing (top 10 shortest paths)
report_timing -delay_type min -nworst 10
## Expanded clock network detail (essential for debugging)
report_timing -path_type full_clock_expanded -nworst 3
## Filter by path group (clock domain)
report_timing -group clk_core -nworst 20
## Paths through a specific cell (to find which paths use it)
report_timing -through [get_cells u_adder/U_mult/*] -nworst 10
## From a specific flip-flop
report_timing -from [get_cells u_ctrl/state_reg[*]] -nworst 5
## To a specific endpoint
report_timing -to [get_cells u_mem/write_data_reg[*]] -nworst 5
## Show net delays (useful for identifying wire delay dominance)
report_timing -input_pins -nets -nworst 3
## High precision (4 decimal places instead of 3)
report_timing -significant_digits 4 -nworst 5
## Find all paths with slack worse than -0.1 ns
report_timing -slack_lesser_than -0.1 -max_paths 1000
## Report exceptions applied to paths
report_timing -exceptions -nworst 20
## Prevent line wrapping (easier to parse or grep)
report_timing -nosplit -nworst 5
7. Common timing report diagnostics
What you see
What it means
Where to look
Large incremental delay on a net (not a cell)
Long wire or high-fanout net; wire parasitic dominates
Check SPEF; consider buffer insertion or net resizing
Clock network delay > 40% of path delay
CTS result is poor; high insertion delay
review CTS log; check for unnecessary clock gating depth
CPPR correction is 0
CPPR is not enabled, or ideal clocks are used
Check set_propagated_clock and CPPR app variable
Clock uncertainty > 0.3 ns post-CTS
Old pre-CTS uncertainty not updated; too pessimistic
Update set_clock_uncertainty after CTS
Library setup time is 0
Liberty file may have wrong cell or idealised setup arc
Check Liberty file for the correct cell type
Slack is negative on hold (min) analysis only
Hold violation from excessive skew or very short path
Day 13: hold violation fixes
TNS is more important for closure effort than WNS
Engineers often focus only on WNS (the worst path) during timing closure. But TNS and NVP tell you whether fixing the worst path will make a significant difference. If WNS = -0.020 ns and TNS = -0.020 ns, there is exactly one violating path — fix it and you’re done. If WNS = -0.020 ns and TNS = -25 ns with NVP = 1250, there are 1250 paths all failing by ~20ps each — a systemic issue requiring global optimisation.
Day 11 Key Takeaways
Five sections: header, launch clock network, data path, capture clock network, required time/slack
Incr vs Path: Incr is the per-cell/wire incremental delay; Path is the running total from t=0
Data arrival: cumulative delay from launch FF clock edge through Q and all combinational logic to capture D
Required time: capture clock edge + capture tree delay + CPPR − uncertainty − setup time
WNS: worst (most negative) slack; TNS: sum of all negative slacks; NVP: count of violating paths
report_timing_summary: quick overview by path group; use after update_timing to see overall status
Frequently Asked Questions
What is WNS in STA?
WNS (Worst Negative Slack) is the most negative slack value across all timing paths in the design for a given analysis corner and path group. If WNS = -0.050 ns, the design has a setup violation where data arrives 50ps too late. For tape-out sign-off, WNS must be zero or positive at all PVT corners in all modes.
What is TNS in STA?
TNS (Total Negative Slack) is the sum of all negative slack values. It captures the overall severity of timing violations, not just the worst one. A design with WNS = -0.010 ns but TNS = -5.000 ns has hundreds of paths each failing by a small amount — a systemic issue that requires global optimisation, not just fixing one path.
What does the arrival time section of a timing report show?
The arrival time section shows the cumulative delay from the launch FF’s clock edge to the data pin of the capture FF. It starts with the launch clock network delay (clock tree to launch FF), adds the clock-to-Q propagation delay, then adds each combinational gate delay and wire delay on the data path, ending at the capture FF’s D pin.
How is required time computed in a timing report?
Required time = (next clock edge time) + (capture clock tree delay to capture FF’s CK) + (CPPR correction) − (clock uncertainty) − (FF setup time from Liberty). This represents the deadline by which data must be stable at the capture FF’s D input. Slack = required time − arrival time.
What are the most useful report_timing flags?
Key flags: -delay_type max for setup, -delay_type min for hold; -nworst N for top N violating paths; -path_type full_clock_expanded for full clock network detail; -group CLOCK to filter by clock domain; -through PINS for paths through specific cells; -slack_lesser_than VALUE to filter violating paths; -significant_digits 4 for higher precision.