IntermediateQuestion 20 of 112

Walk through how you would debug a path that fails by a surprising amount using report_timing increments.

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

Start by reading report_timing's (PT) Incr column arc by arc to find where delay accumulates unexpectedly. At each large increment, decide whether it belongs to a net arc (a wire) or a cell arc (a gate): a large net increment usually calls for a physical fix like rerouting or buffering, while a large cell increment calls for checking the cell's driving input transition and load before resizing or fixing it.

Tracing a surprising timing failure back one stage from a flagged slow cell arc to the predecessor net that produced its unexpectedly slow input transition — Technical Reference DiagramWalk through how you would debug a path that fails by a surprising amount using report_timing increments.

Technical Reference DiagramWalk through how you would debug a path that fails by a surprising amount using report_timing increments.

Technical Explanation

Start from the surprise, not the summary. A path failing by a surprising amount means something in it is behaving very differently than expected. The design-wide summary (WNS/TNS) will not tell you why; only the path's own arc-by-arc report will.
Walk the Incr column, not the Path column. Scan the Incr values for one or two arcs disproportionately large compared to the rest — that is almost always where the surprise lives.
Classify the dominant arc: net or cell. Each large Incr belongs to either a net arc (the wire between cells) or a cell arc (the gate delay itself). This decides what kind of fix is worth considering.
If it's a net arc, look at the physical picture. A large net delay usually means the wire is unusually long, poorly routed, or driving a very high-fanout load — the fix is typically adding a buffer or re-routing, not resizing the driving cell.
If it's a cell arc, check the input transition and load first. Before assuming the cell is too small, check whether its input transition is unexpectedly slow (which traces back one more stage) or its output load is unexpectedly heavy.
Why this order matters. Fixing a net-caused delay with a cell resize, or vice versa, targets the wrong stage and recovers little of the lost slack.

Common Mistake

The Trap: Resizing the driving cell at the dominant arc as a first response, without first checking whether that cell's slow delay is actually caused by a slow input transition inherited from the stage before it.

If the real problem is one stage further back, upsizing the flagged cell barely helps, since a faster cell driven by a slow input transition still produces a slow output.
The debug then has to repeat one stage earlier anyway, costing an extra iteration that checking the input transition first would have avoided.

Follow-up Question & Model Response

How do you tell, from the report alone, whether a slow cell arc is the cell's own fault versus an inherited slow input transition?

Candidate Model Response: report_timing -transition_time (PT) or a similar option prints the input and output transition at each pin alongside the delay, so comparing the input transition at the slow cell against that same library cell's characterized transition range shows whether the input arriving at it is already unusually slow. If the input transition is within a normal range for that cell type and the delay is still high, the cell is genuinely under-driving its load, pointing at resizing or buffering. If the input transition itself is far outside the library's characterized range, the real problem sits one stage earlier, and that predecessor cell is the one that actually needs the fix.

Practical Example

A path that previously met timing by 0.2 ns now fails by 0.6 ns after a routing change. report_timing -path_type full_clock_expanded -transition_time shows a driving buffer with an Incr of 0.75 ns — clearly the dominant contributor against neighboring cell arcs of 0.05–0.10 ns each — and an input transition at that buffer of 0.28 ns, well beyond the library's characterized 0.15 ns limit for that cell. Tracing back one stage further, the predecessor cell now drives a longer, unbuffered net after the routing change, producing that slow 0.28 ns transition. The correct fix is adding an intermediate buffer on the predecessor's output net, not resizing the flagged buffer itself, which was only reporting the symptom of a problem one stage upstream.

Complete STA Handbook