Postroute: what should route_opt fix and what should PrimeTime ECO fix?

Short Answer

route_opt (ICC2) does the bulk of postroute fixing: setup, hold, area and logical DRC on data paths, with legalization and ECO routing in the same step. PrimeTime ECO handles what is left at signoff: violations only the signoff timer sees, with full extraction, SI, exhaustive PBA and every scenario. If ICC2 can see a violation, route_opt (ICC2) should fix it; PrimeTime should get a short list.

Technical Explanation

• route_opt (ICC2) first extracts and updates timing, using the PrimeTime delay calculation engine by default. It supports GBA, the default, and PBA through time.pba_optimization_mode (ICC2).
• By default it optimizes setup, hold, area and logical DRC for data paths. Clock optimization, concurrent clock and data, and power need their own application options. Synopsys recommends running it twice, since the first run's legalization and ECO routing can shift timing.
• It fixes with the layout in view: cells are legalized and nets rerouted in the same command, so hundreds of changes are routine.
• PrimeTime ECO works on the signoff view: full extraction, SI, exhaustive PBA when chosen, and every mode and corner through DMSA. It sees what ICC2's scenarios or parasitics missed.
• PrimeTime changes go through write_changes (PT), then place_eco_cells (ICC2) and route_eco (ICC2), then extraction and another PrimeTime run. Each round costs hours, so a long list is expensive and disturbs placement.
• PrimeTime's recommended order is power recovery, DRC, then timing with fix_eco_timing (PT), then final leakage recovery. When many changes disturb legalization, fix setup, hold and DRC one at a time.
• ICC2 does not treat max fanout as a DRC. opt.common.max_fanout (ICC2) is only a soft constraint, and route_opt (ICC2) honours only route_opt application options, so fanout rules checked at signoff can land on the PrimeTime side.

What To Check

• Violations ICC2 and PrimeTime agree on, left for route_opt (ICC2).
• Violations only PrimeTime shows, and why ICC2 misses them: scenario, SI, parasitics or PBA.
• Number of PrimeTime changes per round.
• Correlation between the two tools on the same paths.

Healthy, Suspicious & Hard-stop Results

• Healthy (illustrative): After two route_opt (ICC2) runs PrimeTime shows 40 setup and 60 hold violations, closed in one ECO round.
• Suspicious (illustrative): PrimeTime shows several hundred violations ICC2 also sees, which means route_opt (ICC2) work was skipped.
• Hard stop: Thousands of PrimeTime changes per round, or a large gap between the tools on the same paths.

What The Interviewer Is Testing

• Knows what route_opt (ICC2) optimizes by default.
• Can explain why the PrimeTime list should be short.
• Sends back to ICC2 what ICC2 already sees.

Follow-up Question & Model Response

"Why do report_qor numbers differ between ICC2 and PrimeTime on the same design?"

Candidate Model Response: Both tools have report_qor (ICC2) and report_qor (PT), but they time different views. ICC2 uses its own extraction and scenarios, while PrimeTime uses signoff extraction, SI settings, its own PBA choice and whatever scenarios DMSA loads. Small differences are expected; large ones point at a setup mismatch such as missing scenarios, different derates or different parasitics. Fix that correlation before splitting work, or each tool will chase different violations.