Why is final timing signed off in PrimeTime rather than ICC2?
From PDVerse PnR Interview Handbook · pdVerse Mentor Guide
Short Answer
ICC2 is an optimizer: its timer runs inside placement, CTS and routing loops and is tuned for speed because optimization calls it over and over. PrimeTime is the dedicated analysis engine that the team agrees to trust, run on signoff parasitics with crosstalk, path-based recalculation and every scenario at once. Signing off in PT means one reference engine and one data set decide whether the chip meets timing.
Technical Explanation
- ICC2 times the design to steer optimization. By default it uses graph-based analysis, which merges timing at nodes for speed and memory and is conservative on purpose. Its extraction also depends on the stage: unrouted and global-routed blocks always use native TLUPlus extraction, and routed blocks use the mode set by
extract.starrc_mode(ICC2), Fusion Signoff Extraction by default in X-2025.06 (ICC2 Timing UG p137), with settings chosen for the optimization loop. - PrimeTime reads the signoff parasitics produced by StarRC with
read_parasitics(PT), so the delays it calculates come from the same extraction the rest of signoff uses. - Crosstalk analysis in PT, enabled with
si_enable_analysis(PT), calculates delta delays from aggressor timing windows and reports noise bumps. ICC2 can also run SI withtime.si_enable_analysis(ICC2), but PT is where the final delta delays are judged. - Path-based analysis exists in both tools, but PT is where it is used for signoff decisions, especially
report_timing -pba_mode exhaustive(PT) on the last violating paths before anything is waived. - Distributed multi-scenario analysis in PT times many modes and corners in parallel and merges the reports, so one command shows the worst violation across every scenario.
- PT also carries the final checks that decide handoff:
check_timing(PT) for constraint holes,report_analysis_coverage(PT) for untested checks, and the ECO commands that fix what remains. - The two tools will never match exactly, because extraction, delay calculation and analysis settings differ. A small, stable gap is expected; a large or growing gap means something in setup differs and must be found.
- Separating the roles also keeps the optimizer honest. If the tool that makes the changes also judged them, any blind spot in its timer would be invisible; an independent signoff run catches it, and the ECO loop exists to feed that result back into ICC2.
Common Mistake
The Trap: Declaring a block clean because report_qor (ICC2) shows no violations after route, and handing it off without a PT run. PT with StarRC parasitics and SI enabled then finds 60 setup violations of −5 to −15 ps on long nets, and the top-level team loses two days waiting for an ECO that should have been in the block schedule. A PT run with the signoff setup at every major milestone would have shown the gap weeks earlier, while there was still time to fix it in ICC2.
Follow-up Question & Model Response
"If ICC2 can run PBA and StarRC, why not sign off there?"
Candidate Model Response: Because signoff is about one agreed reference, not about which features exist. The whole team, including the top-level and IP owners, runs PrimeTime with the same parasitics, constraints and scenario set, so a clean PT result means the same thing to everyone. ICC2's settings are chosen for optimization and change between stages. I would use ICC2's PBA and SI to reduce surprises before handoff, and PT to make the final call. When the two disagree, I treat the PT number as the truth and look for the setting in ICC2 that explains the gap.
Practical Example
Tapeout Scenario: At route completion ICC2 reports WNS −3 ps and 11 violating endpoints in the slow scenario (illustrative). PrimeTime with StarRC SPEF and SI enabled reports WNS −12 ps and 38 violating endpoints. The team checks the gap: 24 of the extra endpoints carry more than 6 ps of crosstalk delta delay, and the rest sit on nets where the extraction differs by a few femtofarads. PBA exhaustive in PT clears 15 of the 38, and the remaining 23 go into a PT ECO of 14 resized cells and 9 buffers. After ICC2 implements it and StarRC re-extracts, PT shows all scenarios clean and the block is signed off on the PT result, with the ICC2 report kept only as a record of the gap.
PnR Flow Mentor Guide
Master the Physical Design Implementation Flow
Read the complete 8-chapter PnR Flow Mentor Guide free on the web — library setup through placement, clock tree synthesis, routing, chip finishing, hierarchical implementation, and ECO, all the way to stream-out.
Continue practising