BeginnerQuestion 22 of 95

How do you read a basic timing report from report_timing?

From PDVerse STA Mentor Guide, part of the pdVerse Mentor Guide

By Tabish Iqbal, who has 9+ years of VLSI Physical Design experience

Short Answer

A report_timing (PT) report has four parts read top to bottom: a header naming the start and end of the path, a data-arrival section tracing the signal's delay pin by pin, a data-required section computing the deadline, and a slack line at the bottom showing whether the path passed.

Annotated report_timing output showing the header, data arrival table with incr and path columns, data required section, and final slack line — Technical Reference DiagramHow do you read a basic timing report from report_timing?

Technical Reference DiagramHow do you read a basic timing report from report_timing?

Technical Explanation

Every violation you will ever debug starts with reading this report correctly, so it is worth slowing down on the four blocks.

Header block: names the startpoint (usually the launching flip-flop's clock pin) and endpoint (usually the capturing flip-flop's data pin), plus which clock and which check — setup or hold — the report is for.
Data arrival path: a table listing every pin the signal passes through, with two numbers per row — incr (the delay added at that one step) and path (the running total so far). Reading down the path column shows the signal's cumulative arrival time.
Data required path: starts from the clock period, adds the capturing clock's own delay, and subtracts the cell's setup time, ending in a required arrival time — the deadline the data must beat.
Slack line: the tool subtracts arrival time from required time and prints the result — a positive number means the path passed with that much margin; a negative number is a violation of that size.
Rise/fall markers: each pin row is tagged r (rising edge) or f (falling edge), because a gate's delay is not the same in both directions.

Common Mistake

The Trap: Reading the incr column as if it were the total delay so far, instead of the delay added at that one pin.

This makes a path look far slower than it is, since each row's incr is only that step's contribution, not the running sum.
The running sum is the path column — always compare slack against the last path value, not any single incr entry.

Follow-up Question & Model Response

How would you get a report that shows every clock buffer in the tree, not just a summary latency number?

Candidate Model Response: I would add -path_type full_clock_expanded to report_timing (PT), which expands the launch and capture clock paths pin by pin instead of one latency number. That is useful for tracing an unexpectedly large skew back to a specific buffer. I would pair it with -derate to also see the on-chip variation applied at each stage.

Practical Example

A report for a path from reg_a/CK to reg_b/D shows a data arrival time of 1.840 ns against a data required time of 2.000 ns on a 2 ns clock, for 0.160 ns of positive slack. Scanning the arrival table shows one 3-input AND gate contributing 0.62 ns — far more than the other four cells combined — making it the obvious first target if that margin ever needs to grow.

Complete STA Handbook