AdvancedQuestion 53 of 63Source: Synopsys PrimeTime User Guide: report_timing Path Report Format

How do you read a full report_timing path report, section by section?

From PDVerse STA Mentor Guide · pdVerse Mentor Guide

By Tabish Iqbal · 9+ Years VLSI Physical Design Experience

Short Answer

A full report_timing (PT) path report has four readable sections in order: a header naming the startpoint, endpoint, and which check it reports; an arrival-time section that adds up every delay from launch to the endpoint; a required-time section that works out the latest, or earliest, legal arrival from the capture clock; and a slack line, simply required time minus arrival time. Reading it section by section, instead of jumping straight to the slack number, is what lets a designer find which specific arc is actually eating the margin.

An annotated report_timing text block with four bracketed regions labeled header, data arrival path (incremental and cumulative columns), expanded clock path, and required-time/slack lines, with an arrow from the largest incremental delay to the slack line. — Technical Reference DiagramHow do you read a full report_timing path report, section by section?

Technical Explanation

The header block states the startpoint (the launching flop or input port) and endpoint (the capturing flop or output port), the path group, and which check -- setup or hold -- the report reflects; getting this wrong makes every number below meaningless.

The arrival section lists every arc from the clock's launch edge through each cell and net to the endpoint's data pin, with an incremental delay column (that one arc's contribution) and a cumulative column (the running total) side by side.
Because both columns are shown, a designer can scan the incremental column for the single largest jump -- often a long net or an undersized cell -- without mentally subtracting consecutive cumulative values.
The clock path section, shown separately from the data path when using report_timing -path_type full_clock_expanded (PT), expands the capture clock's own launch-to-capture delay arc by arc, which matters because skew between the launch and capture clock paths directly changes the required time.
The required-time section starts from the clock period (for setup) or zero (for hold), then subtracts the capture clock's arrival, the endpoint's setup or hold time, and any clock uncertainty margin, arriving at the latest or earliest legal data arrival.
The final slack line, required time minus arrival time, is positive when the path passes and negative when it violates -- but the report is genuinely useful for debug only once the arrival and required sections above it have been read, since slack alone doesn't say why a path is tight.

Common Mistake

The Trap: reading only the final slack number and the top one or two lines of the arrival path, then guessing which cell is 'probably' the bottleneck instead of checking the incremental delay column all the way down.

Consequence: a designer who fixes the largest cell delay they happened to notice near the top of the report can miss a single dominant net delay further down the list, spending an ECO cycle on a cell that was never the real bottleneck.

Follow-up Question & Model Response

Why does the clock path section matter for a setup check if the setup check is really about the data path being too slow?

Candidate Model Response: A setup check compares the data path's arrival time against a required time that is itself derived from the clock path's own arrival at the endpoint, so any skew between the launch and capture clock paths shifts the required time up or down before the data arrival is even compared. A capture clock arriving later than the launch clock, for instance, effectively grants the data path more time, which shows up as looser required time rather than as any change in the data path itself. Reading only the data path section without checking the clock path section means a designer can't tell whether a comfortable slack number came from genuinely fast data logic or from favorable clock skew that might not hold under a different corner. This is exactly the distinction the report's clock-path expansion exists to make visible instead of folding it silently into the required-time number.

Practical Example

A report_timing -path_type full_clock_expanded (PT) run on a path from u_fifo/rd_ptr_reg[3]/CP to u_fifo/wr_ptr_sync_reg[3]/D shows a data path arrival of 1.42 ns, dominated by a single 0.61 ns net delay on a long horizontal route crossing the block, not by any one cell's logic delay. The clock path section shows the capture clock arriving 0.18 ns later than the launch clock due to CTS-inserted buffer imbalance, which loosens the required time to 1.55 ns and leaves 0.13 ns of slack -- a margin that would disappear entirely if a later CTS revision reduced that clock-path skew.

Complete STA Handbook