In short: CRPR (Clock Reconvergence Pessimism Removal), also called CPPR, credits back the on-chip-variation delay that a static timing tool double-counts on the clock segment shared by a launch and capture path, so that a common buffer is not pushed slow for one edge and fast for the other at the same instant.
Why the pessimism exists at all
Modern sign-off is done with On-Chip Variation (OCV), or its derivatives AOCV and POCV. The idea is simple: no two transistors on a die are identical, so the tool derates delays — it slows down the launch clock path and speeds up the capture clock path for a setup check, to model the worst realistic skew. A typical flat OCV might apply a late factor of 1.05 and an early factor of 0.95 to every cell and net along the respective paths.
The trouble starts where the two clock paths share hardware. A launch flop and a capture flop almost always sit downstream of the same clock root, PLL output, and the first several buffers of the clock tree. That shared stretch is the common point. OCV, applied naively, derates those shared buffers twice and in opposite directions — slow for launch, fast for capture — even though a single physical buffer cannot be both slow and fast at the same picosecond. That contradiction is the reconvergence pessimism, and CRPR removes it.
A concrete number
Suppose the common segment B1→B2→B3 has a nominal delay of 300 ps. Under OCV with ±5% derate, the launch path sees it as 300 × 1.05 = 315 ps (late) and the capture path sees it as 300 × 0.95 = 285 ps (early). The tool therefore bakes in a 30 ps skew across hardware that is physically identical. CRPR computes that 30 ps and adds it back as a positive credit to the slack of the setup check.
If a path reports −25 ps setup slack before CRPR and the common point contributes +30 ps of removable pessimism, the true slack is +5 ps — the path actually passes. Forgetting CRPR can trigger needless ECOs, buffer insertion, and area/power waste.
Setup vs. hold: the credit flips
For a setup check the launch clock is pushed late and capture early, so CRPR adds pessimism back (improves slack). For a hold check the roles invert — launch early, capture late — and CRPR again removes the opposing derate on the common segment. In both cases the rule is the same: find the last common node shared by launch and capture clock paths, and reconcile the min/max derate applied beyond it.
| Check | Launch clock | Capture clock | CRPR effect on slack |
|---|---|---|---|
| Setup (max) | late / slow | early / fast | adds credit → more positive |
| Hold (min) | early / fast | late / slow | adds credit → more positive |
How tools name and control it
The concept is universal but the knobs differ by vendor. In Synopsys PrimeTime it is controlled by timing_remove_clock_reconvergence_pessimism (on by default in sign-off flows). Cadence Tempus and the Innovus timer call the same feature CPPR, enabled through set_global timing_enable_crpr_mode (or the analogous setAnalysisMode -cppr both). Siemens Tessent/Questa and third-party timers use equivalent settings. Clock-gating cells, logic on the clock (dividers), and crossing clock domains complicate the "last common node" search, so each tool defines a CRPR threshold and granularity to bound runtime.
CRPR/CPPR is a run-time-heavy analysis. On large SoCs the common-point search across millions of paths is why PrimeTime and Tempus expose a pessimism-removal threshold — paths with pessimism below, say, 5 ps may be skipped to save hours of CPU.
Interaction with MMMC and derating methods
Because derate values change per corner and mode, CRPR is computed independently in every scenario of a multi-mode multi-corner (MMMC) sign-off. A path that is CRPR-dominated in the slow-slow corner may have negligible common-point credit in a fast corner. With POCV (parametric OCV), the pessimism is derived from statistical sigma on the common cells rather than a flat percentage, which generally yields a smaller, more defensible credit than flat OCV. Teams moving from flat OCV to AOCV/POCV often see reported slack shift simply because the CRPR credit is recomputed — a frequent source of confusion in static timing analysis debug sessions.
Practical sign-off guidance
- Always confirm CRPR/CPPR is enabled before trusting negative-slack reports; a disabled flag inflates violations.
- Check the common point reported in the path report — if it is unexpectedly shallow (near the flop, not the root), a clock-gating cell or a don't-touch may be breaking the shared tree.
- Keep the clock tree genuinely common for related launch/capture flops; duplicated buffers reduce CRPR credit and manufacture real skew.
- Match the derate method (flat/AOCV/POCV) across the whole clock network so the credit is self-consistent.
For hands-on labs on OCV derating, clock-tree synthesis, and sign-off closure, our team at CourseTron partners with industry mentors from Avecas, a VLSI physical-design services house, so the examples mirror real tapeout flows.
Want to master STA, OCV/AOCV, and CRPR with real PrimeTime and Tempus runs? Explore our VLSI Physical Design & STA course and close timing like a sign-off engineer.
Frequently asked questions
Are CRPR and CPPR the same thing?
Yes. CRPR (Clock Reconvergence Pessimism Removal, Synopsys terminology) and CPPR (Clock Path Pessimism Removal, Cadence terminology) describe the identical analysis: crediting back OCV derate double-counted on the common clock segment.
Does CRPR make my design optimistic?
No. It removes pessimism that is physically impossible (one buffer cannot be simultaneously slow and fast). It restores accuracy; it does not hide real skew caused by separate buffers or routing.
Why did my slack improve after enabling CPPR?
Because the tool stopped double-derating the shared clock path. The improvement equals the opposing derate applied beyond the common point — often tens of picoseconds on deep clock trees.
Does CRPR apply to hold checks?
Yes, with the derate roles inverted (launch early, capture late). The common-point reconciliation improves hold slack just as it improves setup slack.