Where does CRPR show up in a timing report, and why does it improve slack?

Short Answer

CRPR appears as a line called clock reconvergence pessimism on the capture side of a PrimeTime timing report, just after the clock network delay. It adds back the pessimism created when the shared part of the launch and capture clock paths was timed late for one and early for the other. Because it only removes pessimism, it can only improve slack.

Technical Explanation

• With on-chip variation, PT times the launch clock path late and the capture clock path early. The segment the two paths share, up to the common point, is then counted with two different delays at once, which cannot happen in silicon.
• The pessimism is the latest arrival minus the earliest arrival at the common point. PT adds that amount back as the clock reconvergence pessimism line, which moves the required time later for setup.
• CRPR is on by default. timing_remove_clock_reconvergence_pessimism (PT) set to false turns it off to save runtime, at the cost of more pessimism, and any change forces a full timing update.
• timing_clock_reconvergence_pessimism (PT) controls how the common point is found. The default, normal, uses the latest common point even if the launch and capture transitions differ there; same_transition requires the same transition and is more conservative.
• Crosstalk delta delay on the common segment is removed only for zero-cycle checks, such as a standard hold check, because only then does the same aggressor event affect launch and capture together.
• For speed, report_timing (PT) merges nearby points on the clock path when their CRP differs by no more than timing_crpr_threshold_ps (PT), 5 ps by default. report_crpr (PT) does not merge, so when the two differ, its value is the accurate one.
• A large CRPR value means a long shared clock path with a large early-late spread, so a path that only passes because of CRPR deserves a look at the clock tree.

What To Check

• The clock reconvergence pessimism line on the capture side of the worst setup and hold paths.
• The common point, launch and capture edge types and CRP values from report_crpr (PT).
• Whether the report and report_crpr (PT) disagree by more than the merge threshold.
• The CRPR variables in the run, compared with the signoff setup.

Healthy, Suspicious & Hard-stop Results

• Healthy (illustrative): A CRPR line of 10 to 30 ps on paths with a long shared clock trunk, matching report_crpr (PT) within a few picoseconds.
• Suspicious (illustrative): A CRPR line of 0.00 on two flops that sit next to each other on the same clock branch; check that CRPR is enabled and the clocks are propagated.
• Hard stop: CRPR disabled in a signoff run, or a path signed off on a report whose CRP differs from report_crpr (PT) by more than the merge threshold without anyone looking.

What The Interviewer Is Testing

• Recognising the CRPR line and knowing which side of the report it is on.
• Can you calculate CRP from the early and late arrivals at the common point?
• Knowing why crosstalk on the common segment is only removed for zero-cycle checks.

Follow-up Question & Model Response

"Why can CRPR only increase slack, never reduce it?"

Candidate Model Response: CRPR corrects a double count: the shared clock segment was timed with its late delay on one side and its early delay on the other. Removing that difference moves the capture edge later for setup, or the launch edge relative to capture for hold, in the direction that helps the check. There is no case where a real shared buffer would be faster for one side than the analysis assumed. The PT user guide states this directly: a design clean with CRPR off is also clean with it on.