Walk through a full setup check including clock reconvergence pessimism (CRPR) — why does OCV derating create artificial pessimism on shared clock paths, and how is it removed?

Short Answer

A setup check compares when data arrives at a flip-flop against the latest time it is allowed to arrive. On-chip variation (OCV, the assumption that identical cells on the same chip can still run at slightly different speeds) forces the tool to derate the launch clock path late and the capture clock path early, even though both paths often share the same physical wires up to some branch point. That double-counts variation on the shared segment. Clock reconvergence pessimism removal (CRPR) finds that shared segment and credits back the extra margin.

Technical Explanation

• The tool builds the full setup path in four segments: launch clock path (source to launch flop), data path (launch flop to capture flop), capture clock path (source to capture flop), and the flop's own setup requirement.
• Data arrival time is the launch clock edge plus clock path delay plus data path delay; the required time is the next capture clock edge plus clock path delay, minus the setup requirement and any uncertainty. Slack is required time minus arrival time.
• In on-chip variation mode, the tool applies set_timing_derate (SDC) factors so the launch side of a setup check uses late (slow) derating and the capture side uses early (fast) derating — modeling one flop's neighborhood running slow while another runs fast.
• The launch and capture clock trees usually share the same buffers and wires from the clock root out to some divergence point, because both flops sit on the same physical clock tree. Applying opposite derates on the same physical segment is not physically possible — one buffer cannot be both fast and slow at once.
• CRPR (clock reconvergence pessimism removal, sometimes labeled CPPR for common-path pessimism removal) finds the common point where the launch and capture clock paths diverge, computes the derated delay difference on that shared segment, and adds the difference back into slack as a credit.
• report_crpr (PT) prints the exact common-point pin and the size of the pessimism credit for a given path, and report_timing -derate (PT) shows the per-segment derate factor actually applied, so both are the way to confirm CRPR fired rather than trusting the summary slack number alone.
• What breaks without it: paths with a long shared clock trunk and a short divergence — common in a balanced clock tree — show slack that is more pessimistic than physically possible, which can trigger unnecessary ECO buffer insertion or over-conservative floorplan decisions.

Follow-up Question & Model Response

"If CRPR gives back a large slack credit on one specific path, what would make you suspicious that the credit itself is wrong rather than trust it at face value?"

Candidate Model Response: I would check the common point report_crpr reports and confirm it actually sits on the true shared clock segment for both the launch and capture flop — a wrong common point (for example, one computed before a useful-skew clock-gating cell was accounted for) can hand back credit that does not correspond to real shared silicon. I would also check whether the launch and capture edges are the same clock edge; CRPR credit is largest and most trustworthy at zero-cycle, same-edge checks, and shrinks or should be treated cautiously once launch and capture use different edges of a multicycle or generated-clock relationship, where the 'shared' delay no longer occurs at the same physical instant.