Why does timing change after routing even if placement didn't change?

Short Answer

Before routing, net delays come from estimates: virtual routes or global routes and estimated parasitics. After routing, every net has its real length, layers and vias, and real neighbours that add coupling. Those differences change delay, and crosstalk appears for the first time, so slack moves even though no cell moved.

Technical Explanation

• Preroute timing uses estimated wire lengths, often close to the shortest possible path. Real routes detour around blockages, macros and congestion, so they are almost always longer.
• Layer assignment changes resistance. The estimate may assume an average layer mix; a critical net that ends up mostly on M2 and M3 is much more resistive than one on M6.
• Every via on the real route adds resistance that the estimate may not have fully counted.
• Real neighbours set real coupling capacitance. A net that runs next to a busy bus picks up capacitance and, with signal integrity analysis on, crosstalk delta delay.
• Clock nets change too. Real clock routing can shift latency by a few picoseconds per branch, which changes skew and moves both setup and hold slack.
• Hold can get worse as well as setup. Crosstalk that speeds up a net in the same direction makes data arrive earlier, and a clock branch that got slower delays capture.
• Tools reduce the surprise by using global route based estimates and good RC correlation, but routing always adds information that was not available earlier. Postroute optimization exists to handle it.
• Extraction corners matter here too. Preroute timing may have used one estimated corner; postroute signoff checks each RC corner separately, so a path can pass in the corner you looked at before routing and fail in RCworst after. Hold paths are checked in the fast corners, which need their own routed extraction too.

Follow-up Question & Model Response

"How would you find which nets caused most of the slack change?"

Candidate Model Response: Compare the same path before and after routing, net by net. Look for nets whose capacitance or delay grew most, then check whether that came from extra length, lower layers, more vias or coupling. report_timing with net and capacitance columns shows this per stage, and adding the crosstalk delta column shows how much came from coupling. Usually a small number of nets explain most of the change, and they tell you whether the cause is detours, layers or neighbours. Save the preroute timing report for the critical paths before routing starts, so the comparison is possible.