A path fails hold only after you enabled crosstalk analysis. Could CRPR be involved, and how would you investigate?

Short Answer

Possibly. Crosstalk-induced delay change on the shared segment of the launch and capture clock paths is only pessimistic — and only removable by CRPR — for a zero-cycle check, where the same clock edge launches and captures. The discriminator is whether this specific check is zero-cycle; if it is not, the crosstalk effect on launch and capture cannot be assumed identical, and CRPR correctly leaves it alone.

Technical Explanation

Crosstalk analysis and CRPR interact in exactly one well-defined case, and knowing which case you are in changes the entire debug.

• Why crosstalk pessimism exists at all on the clock path. When PrimeTime SI performs crosstalk analysis, an aggressor net can push or pull a clock signal's delay on the shared segment of the launch and capture clock trees.
• Why that is only pessimistic for a zero-cycle check. A zero-cycle check is one where the same clock edge drives both the launch and capture event. There, aggressor switching affects both signals the same way at the same time, so treating the crosstalk delay as independent on each side is double-counting.
• Why other checks are different. For a check that is not zero-cycle, the crosstalk-induced delay change cannot be assumed identical on launch and capture, since they are different clock events — there is no guaranteed common effect for CRPR to remove, and the extra delay reflects a real SI concern.
• Where zero-cycle checks actually show up. A standard hold check, a hold check on a register whose Q-bar feeds back to D as in a divide-by-2 circuit, hold checks with crosstalk feedback from Q-bar-to-D coupling, and a multicycle path deliberately set to zero with designed-in launch-capture skew.
• The investigation, in order. First, confirm the check really is zero-cycle by reading the launch and capture edges out of report_timing (PT) — infer nothing from topology alone. Second, run report_crpr (PT) and check whether the crosstalk delta on the shared segment is being removed. Third, confirm timing_remove_clock_reconvergence_pessimism (PT) is true.
• The branch people skip. If the check is not zero-cycle, CRPR is correct to leave the crosstalk delta in place — the failure is likely real SI, and the next step is shielding or spacing, not hunting for a credit that was never supposed to apply.

Follow-up Question & Model Response

"You confirm the check is zero-cycle and report_crpr shows the crosstalk delta is not being removed. What would you check next?"

Candidate Model Response: I would confirm timing_remove_clock_reconvergence_pessimism (PT) is actually set true for this run, since CRPR is off entirely if it is false, and I would verify the common clock node CRPR identifies is a real, physically shared point rather than a miscomputed one — for instance, confirming it is not sitting on the wrong side of a clock-gating cell that should have split the launch and capture trees earlier than the tool assumed. If both check out and the credit is still missing, that points to a tool or setup issue worth escalating rather than a modeling gap in the design.