What is Common Path Pessimism, and how does CPPR remove it?
From PDVerse PnR Interview Handbook · pdVerse Mentor Guide
Short Answer
A good CTS algorithm branches clock paths as late as possible -- close to the leaf cells, not near the source -- so that under on-chip variation, delay differences along each path stay local and the shared (common) portion of the path doesn't contribute to skew. But that same shared common path then gets analyzed twice with opposite variation assumptions (worst-case for the launch side, best-case for the capture side), which introduces artificial pessimism into the reported slack -- that's Common Path Pessimism (CPP). CPPR (also called CRPR, Clock Reconvergence Pessimism Removal) is the analysis step that identifies the actual shared common path and removes that double-counted pessimism from the timing report.
Technical Explanation
- A well-built clock tree branches near the leaf cells, not near the source, so under OCV the delay differences along each path stay local to that path.
- STA under OCV applies worst-case delays to the launch path and best-case delays to the capture path for setup checks. Where launch and capture share a common clock segment before diverging, that segment gets analyzed as worst-case AND best-case simultaneously -- physically impossible on the same wire.
- That impossible double-counting is Common Path Pessimism (CPP) -- reported slack looks worse than the design actually is.
- CPPR / CRPR identifies the real common clock path and removes that artificial pessimism from the analysis.
- A later branch point means a longer common path, which means more pessimism for CPPR to remove -- a tree that branches early not only risks more real skew, it also leaves less common path for CPPR to correct.
Command Checks & Actions
report_timing -delay_type max -from [get_pins ...] -to [get_pins ...]Shows the path report’s "clock reconvergence pessimism removed" line -- the actual CRPR value ICC2 subtracted for that path, governed by timing_remove_clock_reconvergence_pessimism (default true).
report_clock_timing -type skewReports skew with CRPR already subtracted.
Healthy, Suspicious & Hard-stop Results
- Expected:
report_timingshows a nonzero "clock reconvergence pessimism removed" line on paths with a genuinely shared clock segment, and removing it materially improves reported slack versus the raw graph-based number. - Investigate: the CRPR line is zero or near-zero on a path you expect to share a long common clock segment -- check whether the clock tree structure actually branches where you think it does.
- Stop: reported slack without CRPR applied is being used as the signoff number -- that's exactly the artificial pessimism this mechanism exists to remove, and using it uncorrected will make real designs look like they fail when they don't.
Common Mistake
The Trap: Treating CPP/CPPR as an obscure STA detail rather than connecting it back to CTS: a tree that branches early (near the source) isn't just a skew risk, it's also giving the analysis less common path to remove pessimism from.
What The Interviewer Is Testing
Whether you understand CPPR is correcting an analysis artifact (not a real physical effect), and whether you can connect it back to why CTS branch-point discipline matters in the first place.
Practical Example
Worked Example: Launch and capture clock paths share a 400ps common segment before diverging into a 50ps launch-side branch and a 40ps capture-side branch. Without CPPR, worst-case/best-case OCV derating on the shared 400ps alone can manufacture tens of picoseconds of impossible pessimism into the reported slack -- CPPR is what strips that back out so the signoff number reflects only the real 50ps-vs-40ps divergence.
PnR Flow Mentor Guide
Master the Physical Design Implementation Flow
Read the complete 8-chapter PnR Flow Mentor Guide free on the web — library setup through placement, clock tree synthesis, routing, chip finishing, hierarchical implementation, and ECO, all the way to stream-out.
Continue practising