Why do pre-CTS and post-CTS timing reports show different slack for the same path?

Short Answer

Before clock tree synthesis (CTS) — the step that builds the real buffered network delivering the clock to every flip-flop — the tool has no real clock wiring to measure, so it assumes an ideal clock with zero or estimated delay. After CTS, the clock has real buffers, wires, and skew, so the same path is timed against a completely different — usually less generous — set of clock arrival times.

Technical Explanation

The data path barely changes across this step, but the clock model changes completely.

• Pre-CTS, the clock is ideal or estimated. Without set_propagated_clock (SDC) active on real buffers, the tool assumes every flip-flop's clock pin sees the same edge at the same time, give or take a manually entered clock latency estimate.
• Post-CTS, the clock is a real, propagated network. Actual buffers, inverters, and wire delay now sit between the clock source and each flip-flop, so different flip-flops see the clock edge at slightly different times — this difference is clock skew.
• Skew changes both setup and hold slack, in opposite directions depending on sign. If the capturing flop's clock edge now arrives later than the launching flop's edge, setup slack improves; if it arrives earlier, setup slack shrinks and hold risk grows.
• The data path delay also shifts, but usually less. Placement and routing are refined further after CTS, so cell locations and net lengths change modestly — the bigger swing almost always comes from the clock side, not the logic.
• Why it matters for planning: a path that looked comfortably positive pre-CTS can go negative post-CTS purely from skew, which is why teams do not treat a clean pre-CTS report as proof the design will close.
• This is why a hold check run before CTS is close to meaningless. Hold checks are especially sensitive to skew, so running one before the real clock network exists mostly tests an assumption, not the design.

Follow-up Question & Model Response

A path reports +120ps of setup slack pre-CTS and -15ps post-CTS. What would you check first?

Candidate Model Response: I would start by comparing clock latency at the launch and capture flops between the two reports, since a 135ps swing on one path is large enough that it is very likely a clock-skew effect rather than a data-path change. I would run report_clock_timing (PT) on both flops to see their post-CTS clock arrival times and compare that difference to what the pre-CTS ideal-clock assumption implied. If the capture flop's clock now arrives earlier relative to the launch flop than the ideal model assumed, that skew shift explains most of the slack loss, and the fix is usually a clock-tree balancing adjustment rather than resizing the data path.