Walk through how you would debug a path that fails by a surprising amount using report_timing increments.
From PDVerse STA Mentor Guide · pdVerse Mentor Guide
Explanation
Start by reading report_timing's Incr column arc by arc to find where delay accumulates unexpectedly. The decision point at each large increment is whether it's a net arc (a wire) or a cell arc (a gate): a big net increment points to a physical fix like rerouting, buffering, or placing cells closer together, while a big cell increment points to checking the driving input transition and load, then sizing or fixing the cell.
Timing-path Walkthrough
In the diagnosis example, a path fails by 20 ps, and the biggest single increment is U5/ Z's cell delay at 78 ps. Its input transition is 130 ps, which is bad, marking U5 as a victim rather than the root cause. Tracing further up the path shows U4 is driving a heavy load with a weak driver — the real fix is upsizing U4, which improves delay not just at U5 but at U6 as well. Similarly, in the alternating cell/net example (FF1/Q 95, u1/A net 12, u1/Z 48, u2/A net 30 flagged as 'long wire!', u2/Z 52, u3/A net 8, u3/Z 44, FF2/D net 10), the u2/A net increment of 30 stands out among net arcs, pointing to a wiring/placement issue rather than a cell-sizing one; total data arrival sums to 299 ps.
Command
report_timing -delay_type max -transition_time -capacitance -input_pins netsSwitch-by-switch
-transition_time and -capacitance reveal whether the flagged cell's slow delay stems
from a bad input slew or a heavy load; -nets exposes the individual net delays so a longwire contributor (like the 30 ps net) can be spotted directly.Expected Report Behavior
The Incr column highlights the true bottleneck arc; following it upstream (as with U5 back to U4) shows report_timing's per-arc detail revealing that the reported slow point is a symptom, with the actual root cause one or more stages earlier.
Mentor Note — Common Mistake
Fixing the flagged slow arc directly (e.g., resizing U5) without checking its input transition and tracing upstream, missing that the true root cause is an earlier weak driver (U4) feeding it a bad transition.
How To Debug
Use the decision tree: for the largest Incr, check whether it's a net or cell arc; if cell, check input transition/load with -transition_time and -capacitance and trace upstream to find the real driver-sizing issue, as illustrated by U5 tracing back to U4.
Continue learning free
Get a practical low-power chapter
Receive the existing “Low Power and Multivoltage Fundamentals” PDF chapter and its download link by email.
Continue practising