What is the exact mechanism by which clock reconvergence pessimism removal (CRPR/CPPR) computes its credit?

Short Answer

The tool walks the clock tree from its root toward the launch and capture flops and finds the last pin both paths still share — the common point. It then computes the derated delay to that pin twice: once using the derate factor the launch side would apply, once using the derate factor the capture side would apply. The difference between those two derated values is added back into the path's slack as the CRPR credit, because the shared silicon cannot actually run at two different speeds at once.

Technical Explanation

• The tool traces both the launch clock path and the capture clock path back from their respective flops toward the clock root, pin by pin, and finds the last pin at which the two traces are still identical — this is the common point, sometimes shown as the common path pessimism point in a report.
• Delay from the clock root to the common point is computed twice: once with the derate factor that applies on the launch side of this particular check (late derate for a setup check), and once with the derate factor for the capture side (early derate for setup).
• Since both computations describe the same physical wires and cells, the difference between the two derated delays is entirely artificial — it exists only because the tool applied two different multipliers to one physical quantity. That difference is the CRPR credit.
• The credit is added into the reported slack: a setup check adds it directly, since the artificial pessimism had reduced arrival-to-required margin; the arithmetic sign works out the same way for hold, using whichever combination of early/late applies to that check type.
• report_crpr (PT) prints the identified common point pin, the late-derated delay, the early-derated delay, and the resulting credit for a specific path, which is the way to confirm the mechanism actually ran as expected rather than trusting the final slack number alone.
• The merging threshold matters at the margins: if the launch and capture paths only diverge by a very small, sub-threshold amount at some pin, the tool can treat nearly-identical sub-paths as still common for CRPR purposes, governed by a merging threshold setting, rather than stopping the common point search at the first bit-exact difference.
• What breaks without this mechanism: any check with a genuinely shared clock trunk reports slack that assumes physically impossible variation, which either manufactures false violations that trigger unnecessary ECO fixes, or — less obviously — masks the true amount of margin available for other optimization on that same trunk.

Follow-up Question & Model Response

"If report_crpr shows a common point much closer to the clock root than you expected, given how the tree was built, what would you check first?"

Candidate Model Response: I would first confirm the clock tree structure actually diverges where I think it does — a useful-skew buffer, a balancing insertion, or an unexpected clock-gating cell placed upstream of where the two branches split can move the real common point earlier than the logical tree diagram suggests. I would also check whether the launch and capture flops are even on the same generated-clock domain in the SDC, since a common point search across two only loosely related generated clocks can legitimately terminate much earlier than for two flops on the exact same clock.