How do you try an ECO in PrimeTime before committing to it?

Short Answer

PrimeTime lets you edit its in-memory netlist, see the timing effect, and only then write the change out for ICC2. Use estimate_eco (PT) to rank the options quickly, commit the one you like with size_cell (PT) or insert_buffer (PT), and check it with report_timing (PT). The timing update stays incremental, and therefore fast, only while you stick to the edit commands PrimeTime supports for what-if analysis.

Technical Explanation

• The edit changes PrimeTime's in-memory netlist, and an incremental update re-times only the part of the design it touches.
• The incremental update works for size_cell (PT), insert_buffer (PT), remove_buffer (PT), set_coupling_separation (PT), remove_coupling_separation (PT), connect_net (PT), disconnect_net (PT), remove_net (PT), create_cell (PT) and remove_cell (PT). Use any other netlist editing command and the next update_timing (PT) becomes a full update.
• The update covers the affected nets, their aggressors and a fanout cone limited by where slew stops changing. Crosstalk results can differ slightly from a full analysis, so signoff still needs a full run.
• estimate_eco (PT) is faster again. It computes one stage from its current timing: incoming transition, load, parasitics if present, and each candidate cell's drive. The numbers are not guaranteed exact, so use it to explore and report_timing (PT) to decide.
• estimate_eco -type size_cell (PT) lists each alternative cell with area, stage delay, arrival and slack, the current cell marked by an asterisk. The -type insert_buffer form with -verbose compares current and estimated delays. eco_estimation_output_columns (PT) adds more columns.
• Same-name trap: size_cell (PT) edits PrimeTime's copy of the netlist, while size_cell (ICC2) edits the layout and has freeze-silicon spare-cell awareness. PrimeTime inserts buffers with insert_buffer (PT); ICC2 scripts normally use add_buffer (ICC2) or add_buffer_on_route (ICC2), though ICC2 also accepts insert_buffer (ICC2).
• Manual edits ignore dont_use settings; PrimeTime only warns (NED-076), so read the log before write_changes -format icctcl (PT).
• The update cannot include parasitic changes from the new placement and routing; those arrive after ICC2 implements the change and the block is extracted again.

What To Check

• Every edit in the plan uses a command that keeps the update incremental.
• The gap between the estimate_eco (PT) number and the committed report_timing (PT) slack.
• Hold slack on other paths through the edited stage, not only the setup path you targeted.
• Any NED-076 dont_use warning in the log.

Healthy, Suspicious & Hard-stop Results

• Healthy (illustrative): The estimate said +8 ps, the committed report says +6 ps, and hold through the stage moved by 3 ps or less.
• Suspicious (illustrative): Estimate and committed slack differ by 20 ps or more, or the log shows a full rather than incremental update.
• Hard stop: The setup fix leaves a hold check through the same net negative, or the chosen cell carries an unapproved dont_use warning.

What The Interviewer Is Testing

• Knows which edit commands keep the what-if update incremental.
• Can explain why estimate_eco (PT) is for exploring and report_timing (PT) is for deciding.
• Does the candidate remember that PrimeTime cannot see the parasitic change ICC2 will make?

Follow-up Question & Model Response

"Why might a fix that looked clean in PrimeTime come back worse after ICC2 implements it?"

Candidate Model Response: PrimeTime times the edit on the parasitics it already has, and the guide says the update does not account for changes caused by new placement and routing. ICC2 then places the new cell where there is room and ECO-routes its nets, so real wire length and coupling differ from the assumption. That is why you extract again and re-run PrimeTime after every implemented ECO, and why physically aware ECO, which only makes changes where space exists, narrows the gap.