On-Chip Variation in Static Timing

Why a Single Delay Model Breaks Down

Static timing analysis at its simplest evaluates every path against two extreme library views: a slow corner for setup and a fast corner for hold. That approach assumes the whole die shifts uniformly to one process point at one voltage and one temperature. Physical reality is messier. Within a single die at a single moment, one region can run slightly faster than nominal while another runs slower, because transistor thresholds, wire dimensions, local IR drop, and thermal gradients all vary block to block.

A timing path is rarely contained in one region. Its launch flop may sit in a warm, slightly dense area while its capture flop sits across the block in a cooler, sparser one. Analyzing that path with a single flat corner either ignores the difference or punishes the design with the compound worst case, where every element on both the launch and capture sides is assumed to reach its extreme simultaneously. That compound case is physically impossible, and designing to it converts variability into wasted area and power.

What On-Chip Variation Represents

On-chip variation, usually shortened to OCV, is the modeling layer that captures delay differences between paths that are close enough to share a corner but far enough not to share exact conditions. Instead of replacing the corner libraries, OCV adjusts individual timing arcs within the analysis. The standard method applies a derate factor: launch and data arcs are slowed by a late factor while capture clock arcs are sped up by an early factor for setup, with the assignment reversed for hold.

The result is a per-path pessimism model that reflects the plausible spread between two physically distinct arcs rather than a globally impossible one. OCV sources include systematic variation from lithography and chemical-mechanical polishing, random variation in transistor parameters, local supply voltage droop, and on-die temperature gradients. None of these respect block boundaries, so OCV settings belong to the chip-level signoff plan rather than to individual designers.

Setup and Hold Under Derating

The derating assignment follows directly from what each check measures. A setup check asks whether data launched at one edge of the clock arrives before the next capturing edge. The risk is that the launch clock and data arcs are slow while the capture clock arc is fast, which shrinks the effective window from both sides. Setup analysis therefore derates launch clock and data paths late and the capture clock path early.

Hold analysis asks the opposite question: whether new data can race through and corrupt the current capture. The danger is a fast launch path and a slow capture clock path, so the early and late derates swap sides. Getting these assignments wrong in either direction is a silent signoff error. A swapped pair can pass every check in the report while covering none of the physical risk, which is why derate tables are reviewed in signoff audits exactly like constraint files.

Choosing Derate Values Without Guessing

Derate factors are estimates of the delay spread that corner analysis does not capture, and they should be justified, not invented. Foundry signoff kits, internal silicon correlation data, and prior tapeout experience all feed the number. A derate that is too small turns real variation into escaped marginal paths; one that is too large converts into extra buffers, upsized cells, and burnable power.

Mature flows treat derates as versioned signoff parameters: recorded in a table, referenced by every run, and changed only through a documented review. When a derate value changes, the affected corners are re-analyzed and the delta is recorded, because a slack summary is only comparable across runs made under the same OCV settings. Teams that let derates drift informally end up comparing slacks across incompatible analyses without realizing it.

Common Path Pessimism Removal

Naive derating applies its factors to every arc on a path, including the portion of the clock network that launch and capture share. That shared arc is counted slow on one side and fast on the other, producing pessimism on a piece of silicon that physically cannot disagree with itself. Common Path Pessimism Removal, CRPR, identifies the shared clock arc and credits back the difference.

Enabling CRPR is standard in modern signoff because without it, OCV derating double-charges every path with a common clock spine, and that charge is not uniform. It concentrates on short paths with a large shared portion, which are precisely the paths where hold margin is tightest. The practical discipline is to confirm CRPR is active in every OCV run, record the amount of pessimism removed as part of the report, and treat a report that lacks the CRPR flag as incomplete for signoff purposes.

Advanced OCV and Path-Based Refinements

Flat derating applies the same factor to a two-inverter path and a twenty-stage path, even though variation accumulates per stage and the short path is proportionally more exposed. Advanced OCV, AOCV, addresses this by scaling the derate with measured path depth and distance, usually through table-based factors derived from statistical analysis of the process. Short, local paths receive larger derates; long, averaging paths receive smaller ones.

The refinement costs runtime and requires well-charactered tables, so many flows apply it selectively: AOCV for the critical and near-critical paths identified in a first-pass run, flat derating elsewhere. Path-based statistical timing goes further by propagating delay distributions rather than adjusted delays, but its library and runtime demands keep it a specialized tool. The engineering decision is not which method is most accurate in the abstract but which level of refinement removes real pessimism at an acceptable analysis cost for the node and schedule at hand.

Fitting OCV Into Signoff Discipline

OCV is one row in a larger signoff matrix of modes, corners, and constraint sets. A design is only as signed-off as the weakest combination actually analyzed, so the OCV settings must be enumerated per corner in the same manifest that fixes libraries, parasitic extraction views, and timing exceptions. Regression discipline matters here more than cleverness. Every timing run should log its derate table, CRPR state, and corner list so that a slack regression from Tuesday to Thursday can be traced to a real design change rather than a settings change.

Reviews should cover the derate table alongside the SDC, because both define what the analysis claims about physics. When OCV settings live only in someone's interactive session, signoff becomes unauditable and the same mistake can recur on the next tapeout.

Common Failure Modes and Their Fixes

Several failures recur across teams adopting OCV-based signoff. Derates applied to setup but not hold leave the design exposed on short paths, the failure mode with the least design margin to absorb it. Forgetting CRPR inflates pessimism and burns area on buffers that solve a modeling artifact rather than a physical problem. Mixing OCV settings between regression runs corrupts trend data and hides genuine degradations.

Applying a single chip-wide derate when the signoff plan specifies different values per corner over-constrains some corners and under-constrains others. The fix for all of these is the same in structure: a versioned OCV configuration, a manifest in every run proving which configuration was used, and a review gate that checks derate assignments as carefully as it checks exceptions. Variation modeling rewards teams that treat it as configuration management, not as a knob turned during closure.