Why does forgetting set_propagated_clock after CTS make hold checks meaningless?
From PDVerse STA Mentor Guide · pdVerse Mentor Guide
Explanation
Hold checks depend heavily on skew (S) between launch and capture clock arrival. If the clock is still treated as ideal after the real tree is built, every flop appears to receive the clock at t=0 — meaning skew is effectively zero in the tool's math, even though real skew exists in silicon.
Timing-path Walkthrough
In the hold inequality, skew S is a direct term: Tcq+Tlogic,min ≥ Th+S+Uh. If S is forced to 0 (idealized clock) when the true post-CTS skew is actually significant, the tool's computed margin no longer reflects reality — a path could show passing hold slack in the tool while failing due to real skew on the fabricated chip.
Equation
Tcq + Tlogic,min ≥ Th + S + UhCommand
set_propagated_clockExpected Report Behavior
Without propagation, hold slack in report_timing looks artificially clean (based on zero skew); the numbers do not track the physical clock tree at all.
Mentor Note — Common Mistake
Trusting a passing hold report generated with an idealized clock after the physical clock tree already exists.
How To Debug
Verify set_propagated_clock has been applied post-CTS by checking that clock path entries show real per-flop insertion delay rather than uniform zero latency, per the notes' explicit warning that this becomes meaningless and can pass in the tool while failing in silicon.
Continue learning free
Get a practical low-power chapter
Receive the existing “Low Power and Multivoltage Fundamentals” PDF chapter and its download link by email.
Continue practising