CRPR: Removing Clock Pessimism
Why hold paths show violations that are not real
Once you move past basic setup and hold, the first advanced effect you meet is clock reconvergence pessimism, and the removal of it (CRPR, also called CPPR). It explains a whole class of violations that are not actually real.
The shared clock path
On a timing path, the launch flop and the capture flop are usually fed by the same clock tree up to some branch point, then the clock diverges to each. That shared segment before the branch is physically one path: the same buffers, the same wires.
Where the false pessimism comes from
On-chip variation analysis deliberately makes the launch clock slow and the capture clock fast (for a setup check) to model worst-case spread. But it applies that opposite derating even to the shared segment, as if the same buffers could be both slow and fast at once. They cannot. That double-counted, impossible variation on the common path is pure pessimism.
What CRPR does
CRPR computes the pessimism that was wrongly added on the common clock path, up to the point where launch and capture diverge, and credits it back into the slack. The result is a slack that reflects reality instead of an impossible worst case.
Reported slack (with pessimism) = -0.06 ns (looks like a violation)
CRPR credit on the common path = +0.09 ns
True slack after CRPR = +0.03 ns (actually passes)CRPR matters most for hold checks, where launch and capture share a long common clock path and the pessimism is large relative to the tiny hold margin. If a hold path looks like it fails by a hair, suspect uncredited clock pessimism first.
CRPR is enabled by default in modern signoff tools, but it costs runtime, and how much pessimism it can remove depends on how the common path is identified. If you see surprising violations, confirm CRPR is on and that the common path is being recognized correctly.