What's the precise OCV rule ICC2 applies differently for setup checks versus hold checks?
From PDVerse PnR Interview Handbook, part of the pdVerse Mentor Guide
Short Answer
For setup checks: worst PVT for the clock and data (launch) paths, best PVT for the reference clock (capture) path. For hold checks: best PVT for the clock and data paths, worst PVT for the reference clock (capture) path -- the launch/capture PVT assignment flips entirely between the two check types, which is exactly what makes setup and hold pull a design in opposite directions.
Technical Explanation
- For SETUP checks: worst PVT for the clock and data (launch) paths, best PVT for the reference clock (capture) path.
- For HOLD checks: best PVT for the clock and data (launch) paths, worst PVT for the reference clock (capture) path.
- The launch/capture PVT assignment flips ENTIRELY between setup and hold -- this is exactly why fixing setup (which wants launch slow, capture fast) and fixing hold (which wants launch fast, capture slow) genuinely pull a design in opposite directions.
- ICC2's own phrasing: the tool uses on-chip variation (OCV) mode where setup uses max delays for launch/data and min delays for the capture clock; hold uses min delays for launch/data and max delays for the capture clock.
Formula Or Decision Rule
Setup: launch=worst PVT, capture=best PVT. Hold: launch=best PVT, capture=worst PVT. The two rules are exact mirror images of each other.
What To Check
- Warning sign: a fix applied to close a setup violation on a path introduces a NEW hold violation on the same or a nearby path.
- Inspect: confirm whether the fix (e.g. upsizing a cell to speed up the launch path) shifted the same path's relative launch/capture timing in the direction hold checks are sensitive to.
- Correct: recognize this as the expected OCV mirror-image behavior, not a tool bug -- setup and hold fixes genuinely trade off against each other under this rule.
Command Checks & Actions
report_timing -delay_type maxReports setup-side timing specifically, using the worst-PVT-launch/best-PVT-capture OCV assignment.
report_timing -delay_type minReports hold-side timing specifically, using the mirror-image best-PVT-launch/worst-PVT-capture assignment.
Healthy, Suspicious & Hard-stop Results
- Expected: a fix targeted at one check type (setup or hold) is verified against BOTH check types before being considered complete, given their PVT assignments are mirror images.
- Investigate: a setup fix is applied without re-checking hold on the same path -- given the exact-mirror-image PVT rule, this is a real risk, not a hypothetical one.
- Stop: a design is signed off having only verified setup OR hold under OCV, not both, on paths that were recently modified.
Common Mistake
The Trap: Fixing a setup violation without re-checking hold on the same path afterward -- given the OCV launch/capture PVT assignment is an exact mirror image between the two checks, a setup fix has a real chance of introducing a hold problem.
What The Interviewer Is Testing
Whether you know the PRECISE OCV rule (which side gets worst vs best PVT, and that it flips completely between setup and hold), not just that "OCV makes timing more pessimistic."
Practical Example
Debug Scenario: Upsizing a cell to fix a setup violation (making the launch path faster, which OCV analyzes as launch getting FASTER relative to its worst-PVT assumption) introduces a new hold violation on the same path -- the mirror-image OCV rule for hold makes a faster launch path exactly the direction that creates hold risk.
PnR Flow Mentor Guide
Master the Physical Design Implementation Flow
Read the complete 8-chapter PnR Flow Mentor Guide free on the web — library setup through placement, clock tree synthesis, routing, chip finishing, hierarchical implementation, and ECO, all the way to stream-out.
Offline PDF Bundle
Want all 1109 questions offline?
Get the complete 4-book PDF bundle (PnR, STA, MMMC, Low Power) with a clickable table of contents - no ads, no internet needed.
Continue practising