ExpertQuestion 53 of 69Source: Synopsys PrimeTime User Guide: Clock Reconvergence Pessimism Removal

Why can CRPR (clock reconvergence pessimism removal) actually make a hold violation worse, rather than better, on some paths?

From PDVerse STA Mentor Guide · pdVerse Mentor Guide

By Tabish Iqbal · 9+ Years VLSI Physical Design Experience

Short Answer

CRPR only gives back derate on the portion of the clock tree that the launch and capture paths genuinely share in common — it never touches derate applied to the parts of the tree that diverge. On a path where the divergent branch is where the real timing risk sits, removing pessimism from the shared trunk does nothing to help that risk, while the tool still fully derates the divergent branch in the pessimistic direction, so the net effect on hold slack can be negative rather than positive.

Two hold paths in the same clock domain: P1 sharing 30 of 34 clock-tree stages with 88ps CRPR credit and comfortable margin, versus P2 sharing only 6 of 34 stages with just 18ps credit, turning +15ps margin into a -12ps violation — Technical Reference DiagramWhy can CRPR (clock reconvergence pessimism removal) actually make a hold violation worse, rather than better, on some paths?

Technical Explanation

CRPR, or CPPR, clock reconvergence pessimism removal (PT), identifies the common clock path segment shared by the launch and capture flops of a specific timing arc, and removes the artificial extra margin created by derating that shared segment independently on both sides.
Removing common-path pessimism is correct because a real clock tree only has one physical delay value on a shared branch — deriving two different, independently-derated values for the same physical wire is the artifact CRPR corrects, not a real timing effect.
CRPR does nothing to the divergent portion of the clock tree — the branches that differ between the launch and capture flops — because there is no shared physical segment there for two independent derates to double-count.
A hold check is most sensitive to how much the capture clock's derated latency can shrink relative to the launch clock's derated latency, so if a path's divergent branch is long relative to its shared trunk, most of the derate driving the hold check sits in a region CRPR cannot touch at all.
If a design change, such as adding buffers, increases the divergent portion of a clock tree while shrinking the shared portion, the amount of pessimism CRPR removes goes down at the same time the true, un-recoverable derate on the divergent branch effectively counts for more of the total, and hold slack on that specific path can get worse even though CRPR is "helping."
The direction of the effect is path-specific: two paths through the same clock domain, but with different ratios of shared to divergent clock-tree segments, can see CRPR help one and barely help the other.
What breaks: assuming CRPR uniformly improves hold margin across a clock domain, without checking each path's actual shared-versus-divergent tree ratio, misjudges which specific paths remain at risk after a CTS or ECO change reshapes the clock tree.

Common Mistake

The Trap: Treating CRPR as a blanket hold-margin improvement that applies roughly evenly across a clock domain, rather than a path-specific correction tied to each pair of flops' actual shared clock-tree segment.

Engineers reviewing a hold-fix plan sometimes assume "CRPR is on, so hold margin across this domain is already generous," without checking that some specific paths have almost no shared trunk to benefit from.
A CTS re-balance intended to improve overall skew can shrink the shared segment on certain paths, quietly reducing the CRPR credit those paths were relying on, and a path that used to pass by a comfortable margin fails after a change that looked purely beneficial.

Follow-up Question & Model Response

"If two paths in the same clock domain get very different CRPR benefit, how would I find that out before it costs me a late ECO?"

Candidate Model Response: Run report_crpr (PT) on each path individually rather than assuming domain-wide behavior — the report shows the actual common pin the tool identified and the specific pessimism value removed for that pair of flops. Compare that removed value against the total derate applied to each flop's clock latency; a path where the CRPR credit is small relative to the total derate is one where the divergent branch dominates, and it deserves a specific hold-margin check rather than reliance on the domain's general reputation for having CRPR enabled. Doing this on every marginal hold path before a CTS re-balance, not after, is what catches the risk while it is still cheap to fix.

Practical Example

Two hold paths, P1 and P2, both launch and capture within the same 800 MHz clock domain at the SSG 0.72V 125°C corner. P1's flops share 30 of 34 clock-tree stages, so report_crpr shows 88 ps removed from a 95 ps total derate, leaving 7 ps of real pessimism and a comfortable +40 ps hold margin. P2's flops share only 6 of 34 stages after a later CTS re-balance moved a buffer, so report_crpr removes just 18 ps of a comparable 95 ps derate, leaving 77 ps of real pessimism — enough to turn what had been +15 ps of hold margin into a -12 ps violation, even though CRPR was active on both paths the whole time.

Complete STA Handbook