Why is on-chip variation derating only meaningful once clocks are propagated?
From PDVerse PrimeTime STA Interview Guide · pdVerse Mentor Guide
Ten-second Interview Answer
OCV works by derating clock latencies, deriving different launch and capture clock delays. With ideal clock latency there are no propagated clock delays to derate, so you approximate OCV's margin by inflating set_clock_uncertainty instead.
Complete Technical Explanation
The reasoning is about what OCV has to act on. OCV's whole mechanism is applied to clock latencies: it derates the launch and capture clock paths differently so the two sides of a check no longer share an identical clock delay, and that asymmetry is what produces the pessimism you want. That requires propagated clock delays to exist in the first place. With ideal clock latency, the clock arrives at every register with no propagated delay to scale, so there is essentially nothing for OCV to derate and enabling it accomplishes very little. This is why OCV belongs with propagated clocks and is largely inert before clock tree synthesis. The consequence is not that you go without the margin, but that you model it differently. Before you have a real clock tree, you approximate what OCV would have contributed by inflating set_clock_uncertainty - a lumped budget standing in for launch-versus-capture clock variation you cannot yet derate path by path. It is a coarser instrument, since a single number replaces per-path derating, but it is the honest way to hold the margin while the clock tree does not exist. Once clocks are propagated, you switch to real OCV derating and pull the uncertainty budget back down accordingly, otherwise you are counting the same margin twice.
In Pd / Signoff
This determines how your constraints change across the flow. Pre-CTS, with ideal clocks, you hold clock variation in an inflated set_clock_uncertainty . Post-CTS, with propagated clocks, OCV derating takes over and the uncertainty value comes back down to real jitter and skew margin. Reviewing a post-CTS constraint file, a large pre-CTS uncertainty left in alongside active derating is double-counted margin.
Common Trap
Enabling OCV derating on an ideal-clock run and believing the margin is now covered. With no propagated clock delays there is nearly nothing to derate, so slack barely moves and the clock variation budget is effectively absent. The mirror error is keeping the inflated set_clock_uncertainty after clocks are propagated, double-counting the same variation.
Expect Next
Once clocks are propagated and OCV derating is active, how would you decide how much of the inflated set_clock_uncertainty to remove?
Topic And Primetime Commands
Operating Conditions / On-Chip Variation. set_clock_uncertainty
Keep building interview depth
Continue practising STA
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