What is clock propagation, and what does set_propagated_clock actually change?

Short Answer

Before layout, STA typically assumes an ideal clock: it arrives at every flop at exactly the same time, with zero skew. set_propagated_clock (SDC) switches the tool to use the clock's real insertion delay through the actual clock tree built during clock tree synthesis (CTS) — the step that builds the physical wiring that distributes the clock.

Technical Explanation

• What ideal clock hides. Before a design has a physical clock tree, the tool has no wires to measure a clock delay through, so it typically assumes an ideal clock — a convenient fiction where the clock reaches every register instantly and simultaneously, with zero skew between any two flops. This keeps early timing runs simple, but it also hides the real difference in when the clock arrives at different flops.
• What set_propagated_clock (SDC) does. Applying it to a clock tells the tool to stop assuming zero clock delay and instead compute the clock's actual delay through whatever clock network currently exists — the buffers, inverters, and wires clock tree synthesis inserted.
• When it gets applied. Before CTS there is no real tree to measure, so the command has nothing to compute from; it is applied once CTS has built the physical network, switching that clock from ideal to propagated for every later STA run.
• What changes in the numbers. Once propagated, the launch and capture clock delays in a setup or hold check are no longer equal placeholders — they reflect real skew, which can help or hurt a given path depending on which direction the tree happened to be unbalanced.
• Why this matters for signoff. A design signed off only with an ideal clock has never actually seen the skew that will exist in silicon; propagated analysis is what makes the final setup/hold numbers trustworthy.

Follow-up Question & Model Response

If a path passes setup comfortably under an ideal clock assumption, is it guaranteed to still pass once the clock is propagated?

Candidate Model Response: No. Under an ideal clock the launch and capture delays are both zero, so the setup slack reported is really just the raw logic margin with no skew applied. Once propagated, the real clock tree can add favorable or unfavorable skew to that same path — a longer capture-side clock delay actually helps setup, but a longer launch-side delay hurts it. A path with thin margin under the ideal assumption can fail setup after propagation if the tree happens to add unfavorable skew, which is exactly why signoff timing is never run on an ideal clock alone.