ExpertQuestion 31 of 69

Two engineers get different slack on the same path, same corner. One used report_timing, the other report_crpr plus hand arithmetic. How do you adjudicate?

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

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

Short Answer

report_timing is the signoff number, and the gap almost certainly comes from a merging step that only report_timing performs: it merges adjacent common-clock-path points whose reconvergence pessimism differs by less than a threshold, 5 picoseconds by default, which slightly under-credits pessimism removal. report_crpr reports the unmerged, more granular value, so hand-adding its numbers on top of a separately-run report_timing double-counts or misaligns the credit.

report_timing's 5 ps CRP merging threshold rounding a 45 ps report_crpr credit down to a 38 ps folded credit, explaining a 17 ps slack gap between two engineers — Technical Reference DiagramTwo engineers get different slack on the same path, same corner. One used report_timing, the other report_crpr plus hand arithmetic. How do you adjudicate?

Technical Reference DiagramTwo engineers get different slack on the same path, same corner. One used report_timing, the other report_crpr plus hand arithmetic. How do you adjudicate?

Technical Explanation

This is not really a disagreement about which command is right — it is two different levels of granularity on the same calculation.

Why report_timing merges points at all. For computational efficiency, report_timing (PT) merges points along the shared clock path when the CRP difference between adjacent points is small, controlled by timing_crpr_threshold_ps (PT), default 5 picoseconds.
What that merging costs. Merging close-but-not-identical points slightly under-credits the true pessimism removal. The guide states plainly: when report_crpr and report_timing disagree on CRP, the report_crpr (PT) value is the more accurate one, since it skips the merging step.
Why report_timing is still the signoff number. Despite the slightly less precise CRP, report_timing (PT) is the tool's official, integrated slack — folding in path-specific derating, voltage/temperature scaling, and SI delta-delay in one consistent pass. A hand-assembled number is not that same calculation, and manual arithmetic reintroduces its own errors — a missed slew-dependent derate, a transposed sign, or the wrong path's CRP value.
The adjudication is procedural. First, confirm both engineers ran the identical netlist, SDC, and PrimeTime version — a stale cache or uncommitted local edit produces exactly this mismatch. Second, re-run report_timing -derate -path_type full_clock_expanded (PT) on the path to see the full arc-by-arc breakdown officially used for signoff. Third, check report_crpr (PT) for that path and see if the CRP gap is close to the 5 ps default threshold — if so, merging is the likely explanation.
The rule to state plainly: the official signoff slack comes from report_timing (PT); report_crpr (PT) is a diagnostic for the CRP component, never a substitute for the integrated calculation, and hand arithmetic overrides neither.

Common Mistake

The Trap: trusting a manually-assembled CRPR number over report_timing (PT) output when preparing a formal signoff waiver, because the manual number looks more "precise".

Hand arithmetic on top of report_crpr (PT) output easily misses transition-time derates, non-linear slew propagation, or picking the correct edge-specific reconvergence point — none of which show up as an obvious error in the spreadsheet.
A waiver built on the hand number rather than the tool's official slack is not reproducible by a reviewer re-running the same commands, which is itself a signoff red flag.

Follow-up Question & Model Response

"What would you check to confirm CRPR itself is even enabled and correctly configured before trusting either number?"

Candidate Model Response: I would confirm set_app_var timing_remove_clock_reconvergence_pessimism true (PT) is active for the run, since CRPR is disabled by setting that variable false and the whole mechanism silently stops applying if it is off. I would also check timing_crpr_threshold_ps (PT) is at its intended value — the guide recommends setting it to about half the smallest CRP difference you care to resolve — because a threshold left far too large would merge more points than intended and understate pessimism removal more than the default already does.

Practical Example

Two engineers report slack on the same path launched from regA, captured at regB, both under the SSG 0.81 V 125 °C corner. Engineer A's report_timing -derate -path_type full_clock_expanded (PT) shows −12 ps slack with a 38 ps CRP credit already folded in. Engineer B manually summed a report_crpr (PT) printout showing a 45 ps CRP credit and arrived at +5 ps by adding that credit to a slack number pulled from an older run. Re-running report_crpr (PT) on Engineer A's exact netlist and SDC confirms the same 45 ps unmerged credit, while report_timing's internal merging under the 5 ps default threshold rounds it to the 38 ps folded into the official slack — the 17 ps discrepancy is entirely explained by the merging behavior plus Engineer B pulling a stale baseline slack rather than a genuine tool disagreement.

Complete STA Handbook