Why is on-chip variation derating only meaningful once clocks are propagated?

Short Answer

OCV (on-chip variation) works by derating clock latencies, giving the launch and capture clock paths different, scaled delays. With an ideal clock, there are no real propagated clock delays to derate, so before that point the equivalent margin is approximated by inflating set_clock_uncertainty (SDC) instead.

Technical Explanation

The reasoning turns on what OCV actually has something to act on.

• What OCV's mechanism needs: it derates the launch and capture clock paths differently, so the two sides of a setup or hold check no longer share an identical clock delay — that asymmetry is what produces the intended pessimism.
• Why that requires propagated clocks: with an ideal clock network, every register sees the clock with no propagated delay to scale in the first place, so there's essentially nothing for OCV to derate, and enabling it accomplishes very little.
• Why OCV is largely inert pre-CTS: clock tree synthesis (CTS) is what creates the real, per-register clock latencies that OCV derating actually multiplies against — before CTS, those latencies don't exist yet.
• How the margin is modeled instead, pre-CTS: the designer approximates what OCV would have contributed by inflating set_clock_uncertainty — a single lumped budget standing in for the launch-versus-capture clock variation that can't yet be derated path by path.
• Why that's a coarser but honest stand-in: one number replaces per-path derating, which is less precise, but it's the honest way to hold the margin while no real clock tree exists yet.
• The switch at CTS: once clocks are propagated, the flow moves to real OCV derating and pulls the uncertainty budget back down to match — otherwise the same margin is being counted twice, once in the inflated uncertainty and again in the newly active OCV derates.

Follow-up Question & Model Response

After CTS, how would you tell whether the pre-CTS clock uncertainty value is now double-counting margin against the newly active OCV derates?

Candidate Model Response: Compare the pre-CTS uncertainty value against what the propagated clock's actual skew plus the OCV derate now contributes on a representative path, using report_clock_timing (PT) and report_timing (PT) side by side. If the uncertainty value was sized to cover the full anticipated skew and OCV is now separately derating that same propagated skew, the two are stacking rather than each covering a distinct piece of margin. The fix is to shrink the uncertainty to a residual covering only jitter and modeling guardband, letting OCV account for the skew itself.