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 PrimeTime STA Interview Guide · pdVerse Mentor Guide
Ten-second Interview Answer
The gap is almost certainly CRP merging. report_timing merges adjacent common-clock points whose CRP differs by less than timing_crpr_threshold_ps, default 5 ps, slightly under-crediting CRP. The report_crpr number is unmerged and more accurate.
Complete Technical Explanation
Before you suspect either engineer, suspect the merging threshold. To save runtime, report_timing merges adjacent common-clock points whose CRP values differ by less than timing_crpr_threshold_ps, whose default is 5 ps. Merging coarsens the common-point search, which slightly reduces the CRP credited into slack, so the report_timing number comes out a little worse. The report_crpr accounting is unmerged, so hand arithmetic built on it lands on a slightly better and more accurate slack. Adjudicate in three steps. First, read the current timing_crpr_threshold_ps: if it holds a large design-phase value rather than the default, report_timing is under-crediting CRP by a meaningful amount and that alone explains the discrepancy. Second, lower it toward a signoff value and re-run report_timing, watching the slack converge upward toward the report_crpr -derived number - that convergence is the proof that merging, not a methodology difference, caused the gap. Third, for the official signoff number, prefer the unmerged report_crpr accounting, since it is the more accurate of the two. Then document the threshold you used, because it materially affects reported slack on paths through deep clock trees, and a number quoted without its threshold is not reproducible. The engineers were both right; they were reading two different accuracy settings of the same computation.
In Pd / Signoff
This comes up whenever two people quote different slack for the same path at signoff review, or when a block owner's number disagrees with the top-level regression. You read the threshold out of each run, re-run with it lowered, and record the value alongside the slack in the signoff document so the number can be reproduced later.
Common Trap
Assuming the two reports must agree and hunting for a constraint or corner difference, when the merging threshold explains it. The costlier error is quoting a signoff slack without recording timing_crpr_threshold_ps, since on deep clock trees a design-phase threshold can shift the number enough to change a pass into a fail.
Expect Next
How would you pick a defensible signoff value for timing_crpr_threshold_ps on a given clock tree?
Topic And Primetime Commands
Operating Conditions / PVT & Corners. report_timing, report_crpr, report_crprderived, timing_crpr_threshold_ps
Keep building interview depth
Continue practising STA
Continue learning free
Get a practical low-power chapter
Receive the existing “Low Power and Multivoltage Fundamentals” PDF chapter and its download link by email.
Continue practising