How do you correlate clock differences between ICC2 and PrimeTime?

Short Answer

Two tools disagreeing on timing is almost never a "which tool is buggy" question — it's an "are they analyzing the same thing" question, and clocks are one of the richest places for silent mismatches to hide. Start with clock creation itself: same create_clock period/waveform, same source pin, and check any generated clocks [SDC: create_generated_clock] are derived identically in both environments.

Technical Explanation

• Compare the clock's actual modeling state: is it still ideal [SDC: pre-CTS, set_clock_latency/set_clock_uncertainty values] in one tool and propagated (post-CTS, real insertion delay and skew) in the other? Comparing an ideal-clock ICC2 report against a propagated-clock PrimeTime report will never match, and that's expected, not a bug.
• Check latency and uncertainty settings line by line — a stale set_clock_uncertainty left over from an earlier stage, or a different case-analysis/mode-exclusive setting active in only one tool, produces a real but misleading slack delta.
• Verify scope: are both tools analyzing the same MCMM scenario (same mode + corner), the same active path groups, and the same set of exceptions (false paths, multicycle paths)? A scenario mismatch alone can explain a large timing delta with nothing "wrong" in either tool.
• Only once clock definition, propagation state, uncertainty, and scenario scope are confirmed identical does it make sense to compare path-by-path slack numbers — and even then, keep each tool's log/report output separate so you're not accidentally mixing units or corners from different runs.

What To Check

• Warning sign: One tool sees a generated clock or exclusivity relation that the other does not.
• 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 shared SDC or tool-specific application context, then compare the same endpoint and scenario.

Healthy, Suspicious & Hard-stop Results

• Expected: Compare clock creation, generated relationships, waveform, latency, uncertainty, case analysis, and mode scope without mixing command outputs.
• Stop before floorplanning when required logic or timing coverage is missing or unexplained.

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. ”