CRPR / CPPR: Removing Clock Pessimism
CRPR (CPPR) explained: how OCV double-derates the common clock path, how the common-point credit removes fake pessimism, and why it matters most for hold, with a worked example.
On-chip variation makes STA derate the launch clock slow and the capture clock fast, to hit the worst case. But launch and capture usually travel together through the first part of the clock tree, the same buffers, the same wires. Deriating that shared segment two opposite ways at once is physically impossible, so it is fake pessimism. CRPR (also called CPPR) finds the shared path and credits that pessimism back. It rescues real margin, especially on hold.
Where the pessimism comes from
For a setup check, OCV pushes the launch/data path as slow as allowed and the capture clock as fast as allowed. The launch and capture clocks both start at the clock source and run together through a common set of buffers before they branch off to their own flops. The tool has just assumed that common segment is simultaneously slow (for launch) and fast (for capture), but it is one physical piece of silicon and can only be one speed. That contradiction is pure, non-physical pessimism.
The common point and the CRPR credit
STA finds the common point, the last node the launch and capture clock paths share before diverging, and computes how much opposite derating was applied to that shared segment. That amount is the CRPR credit, added back to the path's slack. The longer the shared clock path (the deeper the common tree), the bigger the credit.
Why it matters most for hold
Hold paths are usually between physically close flops that share almost the entire clock tree, and hold slack is often tiny. So the fake common-path pessimism can be large relative to the real margin, big enough to turn a passing hold path into a false violation. CRPR removes exactly that artefact, which is why hold analysis without CRPR reports violations that vanish once it is enabled. Signoff tools apply CRPR by default.
Worked example
Suppose the common clock path is nominally 0.80 ns and OCV derates by ±5%. The launch view sees it as 0.80 × 1.05 = 0.84 ns; the capture view sees 0.80 × 0.95 = 0.76 ns, a 0.08 ns difference the tool baked in as pessimism. CRPR credits that 0.08 ns back. On a hold path whose reported slack was -0.05 ns, adding 0.08 ns turns it into +0.03 ns: it was never a real violation.
Recap: launch and capture clocks share a common path that OCV illegally derates both slow and fast. CRPR/CPPR finds the common point and credits that impossible pessimism back to slack. The effect is largest on hold paths between nearby flops, where it removes violations that were never real, and it is on by default at signoff.