AdvancedQuestion 26 of 63Source: Synopsys PrimeTime User Guide: Reporting Timing

Why can the same netlist report a different critical path before and after place-and-route?

From PDVerse STA Mentor Guide · pdVerse Mentor Guide

By Tabish Iqbal · 9+ Years VLSI Physical Design Experience

Short Answer

Before place-and-route, PrimeTime estimates wire delay from a wire-load model or a rough placement guess; after routing, it uses real extracted parasitics from the actual metal geometry. Because interconnect delay - not gate delay - usually dominates at advanced nodes, a path that looked fastest on paper can become the slowest once real wire lengths and coupling are known, and a different path takes over as the critical one.

Two side-by-side chip floorplans showing the same 14-stage adder path and a register-to-far-corner-memory path; pre-route both show equal estimated wire delay per net, post-route the adder's real routed wires are short and local while the memory path's wires stretch across the die, flipping which one is the worst-slack critical path — Technical Reference DiagramWhy can the same netlist report a different critical path before and after place-and-route?

Technical Explanation

Two different delay sources feed the same setup check. Total path delay is cell delay (the gate itself) plus net delay (the wire); pre-route, net delay is a guess, and post-route it is measured.
Pre-route wire-load models spread delay evenly by fanout and estimated length. They assume every net of a given fanout behaves like an "average" net for the technology - useful for early estimation, not for signoff.
Post-route parasitics come from real geometry. Extracted resistance and capacitance reflect the actual routed length, layer, and neighboring wires of every single net, which can differ wildly from the pre-route average.
A short logical path can become long if its wires got routed around congestion. Two paths with the same gate count can end up with very different net delay once the router places one net next to a blocked region and the other along a clean, short track.
Ranking by slack, not by name, decides which path is "critical." PrimeTime always reports the path with least slack; if post-route wire delay pushes one path's arrival time later than another's, the label of "critical path" moves with it, even though nothing in the logic changed.
The fix is to keep re-running signoff-quality STA after each major placement/routing update. Pre-route numbers are for early guidance; only post-route, back-annotated timing is trustworthy for signoff.

Common Mistake

Trusting a pre-route or pre-CTS critical path list as if it will still be the critical path after routing.
Wire-load-model or placement-estimate delay is a statistical guess, not a measurement, and interconnect-dominated designs can see it miss badly on individual nets.
Cost: engineering effort spent optimizing a path that was never going to be the real bottleneck, while the actual post-route critical path gets no attention until late in the flow.

Follow-up Question & Model Response

If a path was the single worst-slack path pre-route but shows comfortable positive slack post-route, while a different path that looked fine pre-route is now failing, what would you check first?

Candidate Model Response: I would compare the net delay component of both paths in the two reports, not just the totals, because that isolates whether the shift came from routing rather than from a constraint change. I would check whether the newly-critical path's nets were routed through a congested region or on a higher-resistance upper metal layer, since that is the most common cause of a large pre-to-post jump. I would also confirm the SDC did not change between runs, since a re-timed clock or an added exception can produce the same symptom and should not be mistaken for a routing effect.

Practical Example

A 1.2GHz design's pre-CTS report lists a 14-stage ALU adder path as the worst path at -40ps slack, estimated with a wire-load model that assumes 0.08ns per fanout-of-4 net. After routing, that adder path measures only 0.05ns of real net delay per stage and closes to +90ps slack, because its nets stayed short and local. Meanwhile a register-to-register path that used a wire-load estimate of 0.06ns per net gets routed across two thirds of the die to reach a far-corner memory controller; its real extracted net delay comes in at 0.31ns per net, and it becomes the new worst path at -65ps, a path that never appeared in the pre-route top-10 list at all.

Complete STA Handbook