AdvancedQuestion 23 of 63

How does on-chip variation (OCV) fundamentally change the setup and hold analysis?

From PDVerse STA Mentor Guide, part of the pdVerse Mentor Guide

By Tabish Iqbal, who has 9+ years of VLSI Physical Design experience

Short Answer

OCV derates parts of a path differently to build a deliberately pessimistic worst case: for setup, the data path and launch clock are treated as slow while the capture clock is treated as fast; for hold, the assignment reverses. CRPR then credits back the pessimism double-counted on the clock segment both paths share.

Two flip-flops sharing a common clock buffer segment before diverging to separate leaf buffers, with the launch path derated slow and the capture path derated fast for a setup check, and CRPR crediting back the double-counted shared segment — Technical Reference DiagramHow does on-chip variation (OCV) fundamentally change the setup and hold analysis?

Technical Reference DiagramHow does on-chip variation (OCV) fundamentally change the setup and hold analysis?

Technical Explanation

What on-chip variation captures. Even at a single global process, voltage and temperature (PVT) corner, real chips have local variation - some cells and nets run faster than nominal, some slower, purely from local manufacturing and environmental differences. OCV (on-chip variation) is the modeling of that local spread.
The single-delay baseline. Without OCV, a timing check uses one fixed delay per arc - the corner's characterized value, with no local spread applied.
How OCV builds a setup check's worst case. For a setup check, PrimeTime applies a slow derate (larger delay) to the data path and the launch clock, while applying a fast derate (smaller delay) to the capture clock - data arrives as late as the model allows, the capture edge arrives as early as the model allows.
How OCV builds a hold check's worst case - the mirror image. For a hold check, the assignment flips: data path is derated fast (earliest arrival) and the capture clock is derated slow (latest edge) - data arrives as early as possible, the capture edge as late as possible.
Why this construction introduces its own pessimism. The launch and capture clock paths share physical segments - the common clock path - up until they diverge toward their respective flip-flops. A single physical wire and set of cells cannot honestly be both "fast" for one check and "slow" for the other at the same instant, yet the setup/hold construction above asks the model to do exactly that.
What removes the excess. CRPR, clock reconvergence pessimism removal, credits back the variation that was double-counted specifically on the shared common-clock-path segment, once the tool identifies which portion of the two clock paths is genuinely the same physical structure.
What goes further still. POCV (parametric on-chip variation) replaces flat derate factors with statistical, sigma-based derating per cell, which reduces pessimism again - most visibly on deep paths, where a flat per-cell derate compounds unrealistically across many stages.

Common Mistake

Assuming a slow PVT corner already covers OCV, when OCV is a separate, local-scale effect layered on top of whatever global corner is chosen - a chip can be at the slow global corner and still have real within-die mismatch that only OCV derating exposes.
Reading a design's setup and hold checks as using the same derated view of the clock, when they in fact use opposite - mirror-image - derate assignments for launch versus capture.
Cost: a signoff methodology that skips OCV entirely because "the slow corner is conservative enough," missing local skew or mismatch risk between two cells that are supposedly identical but genuinely differ on a real die.

Follow-up Question & Model Response

If CRPR removes the pessimism on the shared clock segment, why does the tool still report any OCV-derived variation at all on a path with a very short, mostly non-shared clock tree?

Candidate Model Response: CRPR only credits back pessimism on the portion of the launch and capture clock paths that is genuinely the same physical structure - the common segment. A path with a short or mostly non-shared clock tree has little or no common segment to credit back in the first place, so CRPR has little to correct there. The OCV derating on the non-shared portions of the launch and capture paths, and on the entire data path, still reflects genuine local variation risk that has nothing to do with double-counting - those portions really can run at different local speeds on the actual die, and that risk is exactly what OCV is meant to capture, with or without CRPR in play.

Practical Example

Two flip-flops share a common clock buffer for 70% of their clock path before diverging to separate leaf buffers for the final 30%. At the ss_0p72v_125c corner, flat OCV derating without CRPR reports −45ps setup slack, double-counting the shared segment as slow for launch and fast for capture at once. Enabling CRPR credits back 38ps on that shared segment alone, leaving genuine variation only on the non-shared 30% and the data path, moving slack to −7ps - a real violation, not a double-count artifact.

Complete STA Handbook