How to Read a PrimeTime Timing Report
A timing report is a story about one path. It starts at a launching point, walks through logic, and ends at a capturing point, and the last line tells you whether that path passes. Once you can read it line by line, debugging any violation becomes a matter of following the trail.
The header: what path is this
The top of the report names the startpoint and endpoint, the path group, and the clocks involved. Always read this first. Half of all confused debugging happens because someone analyzes the wrong path or the wrong corner.
The two columns
The body has an incremental column and a cumulative path column. Each row is a cell or net the signal passes through, the incremental value is the delay it adds, and the path value is the running total. You are watching arrival time build up as the signal travels.
Startpoint: a_reg (rising edge clk)
Endpoint: b_reg (rising edge clk)
Path Group: clk Path Type: max
Point Incr Path
clock clk (rise) 0.00 0.00
a_reg/CK 0.12 0.12
a_reg/Q 0.09 0.21
u_logic/Z 0.34 0.55
b_reg/D 0.02 0.57 data arrival time
...
clock uncertainty -0.05
b_reg setup time -0.04
required time
slack (MET) 0.06Example values, your numbers will differ. The shape is what matters.
Arrival versus required
The report computes two times. Data arrival time is when the signal actually reaches the capturing flop. Required time is the latest it could arrive and still be captured safely, which is the clock period plus the capture clock path, minus setup time and uncertainty. Slack is required minus arrival.
| Line in the report | What it tells you |
|---|---|
| Startpoint / Endpoint | Which path you are looking at |
| Path type max or min | Setup check (max) or hold check (min) |
| Data arrival time | When data actually reaches the flop |
| Required time | The deadline for safe capture |
| Clock uncertainty | Margin for jitter and skew |
| Library setup or hold time | The flop requirement |
| Slack | Positive passes, negative fails by that amount |
Read the path from the largest incremental delays first. The one or two cells adding the most delay are where your fix lives. Chasing small contributors wastes time.
Check the path type before you act. A max path is a setup check, a min path is a hold check, and the fix for one can break the other. Fixing what you think is a setup path when it is actually a hold report leads you in the wrong direction.
Key takeaways
- Read the header first to confirm the path, clocks, and corner
- The path column is arrival time building up cell by cell
- Slack is required time minus arrival time
- Attack the largest incremental delays, and respect max versus min