ICC2 and PrimeTime disagree. How do you test a unit hypothesis?
From PDVerse PnR Interview Handbook, part of the pdVerse Mentor Guide
Short Answer
Before assuming a real timing bug, rule out the boring explanation first: are both tools even reporting in the same units? A slack reported in "ns" versus "ps" without noticing looks like a 1000x discrepancy that isn't a timing bug at all. Pull each tool's reported units directly — clock period units, delay units, slew units, capacitive load units — and compare them side by side rather than assuming they match by convention.
Technical Explanation
- Pick one identical clock, one identical delay value, one identical slew, and one identical load, and feed the same numbers through both tools' reporting to see if the displayed values diverge in a way that looks like a scale factor (10x, 1000x) — that's the signature of a units mismatch.
- Keep each tool's logs and reports in separate files during this test — don't eyeball-compare from memory or mix outputs, since a units bug is exactly the kind of thing that's obvious in raw data and easy to miss in a summarized report.
- If the units genuinely check out identical, move on to the next standard correlation hypothesis (library, clock, PVT, scenario) rather than continuing to chase a units explanation that's already been ruled out.
- This is really a template debugging habit: for any two-tool timing disagreement, check the boring stuff (units, then libraries, then clocks, then scenario/exception scope) before assuming the disagreement is a real design or algorithmic difference.
What To Check
- Warning sign: Numbers differ by a power of ten or one thousand across tools.
- Inspect: Keep at least two possible causes open, then use one named object and the active mode or scenario to separate them.
- Correct: Correct the input-unit boundary or file interpretation, reload both cleanly, and compare a small shared testcase.
Command Checks & Actions
- report_user_units: shows the units ICC2 uses when reading and printing values
- report_clocks: shows clock definitions and relationships
- report_ports -design_rule [get_ports *]: shows boundary constraints and electrical assumptions
Run the commands in order. Each line answers a separate part of the check.
Healthy, Suspicious & Hard-stop Results
- Expected: Compare reported units and the same clock, delay, slew, and load values before comparing slack; keep each tool's logs separate.
- Stop before floorplanning when required logic or timing coverage is missing or unexplained.
Common Mistake
The Trap: Do not assume the check passed just because ICC2 continued. Fix or narrowly justify the named objects, then rerun the same command.
What The Interviewer Is Testing
Be ready to explain why this matters before floorplanning.
Follow-up Question & Model Response
Model response: “I would save the report, inspect one affected object in the correct block and scenario, and make or request this correction. ”
Physical Design & Planning Handbook
Master ASIC Physical Design Planning & Floorplanning
Dive into 14 comprehensive chapters covering netlist sanity, FinFET grids, macro placement, power grids, CTS, and timing budgeting.
Offline PDF Bundle
Want all 1109 questions offline?
Get the complete 4-book PDF bundle (PnR, STA, MMMC, Low Power) with a clickable table of contents - no ads, no internet needed.
Continue practising