ExpertPrimeTime guide question 4 of 1

Explain how CRPR, crosstalk, and PBA interact for an SI-critical clock path, end to end.

From PDVerse PrimeTime STA Interview Guide, part of the pdVerse Mentor Guide

By Tabish Iqbal, who has 9+ years of VLSI Physical Design experience

Short Answer

Three layers stack on top of each other. Base CRPR removes the ordinary OCV double-count on the shared clock segment when the tool computes final slack. A second layer removes the coupling-delay pessimism CRPR would otherwise miss on that same shared segment, but only for zero-cycle checks, where the identical clock edge launches and captures. A third layer, enabled by pba_enable_xtalk_delay_ocv_pessimism_reduction, extends CRPR into the arrival-window computation itself during path-based analysis (PBA), since those windows do not get CRPR by default.

PrimeTime reference figure: three stacked CRPR layers on an SI-critical clock path - base CRPR, zero-cycle crosstalk credit, and PBA arrival-window credit removing a further 12ps on a shared 150ps trunk — Technical Reference DiagramExplain how CRPR, crosstalk, and PBA interact for an SI-critical clock path, end to end.

Technical Reference DiagramExplain how CRPR, crosstalk, and PBA interact for an SI-critical clock path, end to end.

Technical Explanation

Base CRPR is the first layer: it removes the ordinary OCV double-count on the shared clock segment when the tool computes final slack, and it applies to every path whenever CRPR is enabled.
The second layer is CRPR interacting with crosstalk, governed by a zero-cycle rule: on that same shared segment, crosstalk-induced delay is removed only for zero-cycle checks, where the identical clock edge both launches and captures — only then is the aggressor's effect on the launch and capture signal guaranteed identical.
For any other check, the launch and capture edges are different edges at different times, so the crosstalk delta on the shared segment cannot be assumed identical between them, and it is not removed.
The third layer is arrival-window pessimism during path-based analysis (PBA): the arrival windows the tool uses for crosstalk timing do not get CRPR credit by default, so derating on a shared clock segment can falsely widen the aggressor's and victim's windows and manufacture overlaps that cannot physically occur.
pba_enable_xtalk_delay_ocv_pessimism_reduction (PT), set to true, extends CRPR-style accounting into those arrival-window computations too, correcting this third layer of pessimism.
The three layers stack: getting an SI-limited clock path's slack genuinely accurate can require understanding, and where appropriate enabling, all three together.
What breaks: each added layer costs more runtime, since it moves CRPR-style accounting into a more expensive part of the computation — enabling all three blanket-wide on a large signoff run is far costlier than scoping the advanced layers to only the paths that actually need them.

Common Mistake

The Trap: assuming ordinary CRPR being enabled automatically also removes crosstalk-related pessimism on shared clock segments.

The zero-cycle rule specifically limits crosstalk-delay CRPR credit to same-edge checks; a multicycle or different-edge check on the same shared segment does not get that credit, since the aggressor's effect on launch and capture is no longer guaranteed identical, so treating every check on that trunk as equally covered overstates how much credit is really available.
Leaving pba_enable_xtalk_delay_ocv_pessimism_reduction at its default false setting while running exhaustive PBA on an SI-critical clock path silently leaves arrival-window pessimism in place, even though ordinary CRPR is working correctly elsewhere in the same report — a clean-looking base CRPR credit can coexist with a still-inflated arrival window feeding the crosstalk delta on the same path.

Follow-up Question & Model Response

"If you enable pba_enable_xtalk_delay_ocv_pessimism_reduction on a large block-level signoff run, what tradeoff are you accepting, and how would you decide it's worth it for this specific path?"

Candidate Model Response: I would be accepting additional runtime, since this option asks path-based analysis to apply CRPR-style common-point accounting during arrival-window computation for every aggressor/victim pair evaluated, on top of the exhaustive PBA re-timing that is already expensive. I would judge it worth enabling selectively, scoped with path tagging or a filtered report_timing pass to just the SI-critical clock paths that are both genuinely marginal and have a meaningfully long shared clock trunk feeding their aggressor and victim nets, rather than turning it on blanket-wide for a whole block where most paths would see no benefit for the added cost. I would confirm the scoping actually worked by comparing the reported slack on those specific paths with and without the option before committing to the wider, more expensive run.

Practical Example

Worked case: an SI-critical clock path has aggressor and victim nets both fed from a shared 150 ps clock trunk. Ordinary CRPR already credits back the OCV double-count on that trunk for final slack — call this an 18 ps base credit. Because this is a zero-cycle check (same launch and capture edge), the crosstalk-delay pessimism on that same trunk is also eligible for removal, adding a second credit of roughly 6 ps once the coupling delta on the shared segment is corrected. Running exhaustive PBA with pba_enable_xtalk_delay_ocv_pessimism_reduction set to true additionally tightens the aggressor and victim arrival windows computed on that shared trunk, removing a further 12 ps of manufactured window-overlap pessimism that neither the base CRPR credit nor the zero-cycle crosstalk credit alone would have caught. Stacked together, the three layers recover roughly 36 ps of slack on this one path that a base-CRPR-only analysis would have left on the table, at the cost of the extra runtime the exhaustive, window-level recomputation requires.

Complete STA Handbook