How does the incremental ECO flow avoid a full extraction on every iteration?
From PDVerse PnR Interview Handbook · pdVerse Mentor Guide
Short Answer
ICC2 records only what the ECO changed, StarRC extracts only those changes, and PrimeTime applies them to a saved session instead of reloading the design. record_signoff_eco_changes (ICC2) tracks the edits, StarRC runs in ECO mode, and PrimeTime reads them with read_eco_changes (PT) and read_parasitics -eco (PT) before an incremental timing update. Final signoff still needs a full extraction and a full timing run.
Technical Explanation
- A full loop writes the whole netlist, extracts every net and reloads PrimeTime from scratch, which takes hours on a large block. The incremental flow repeats only the changed part.
- Initialize once: in ICC2 copy the block and run
record_signoff_eco_changes -init -def(ICC2), which saves the design and writes Verilog and DEF. StarRC extracts it with ECO_MODE: YES, and PrimeTime does a full update and saves a session. - Each loop in ICC2 copies the block, starts recording with
record_signoff_eco_changes -start -input pt-eco_inc1.tcl(ICC2), implements with minimum physical impact, and stops with-stop -def. That writes an incremental database for StarRC and an incremental change list for PT. - StarRC then extracts only the changes and writes an incremental parasitic file.
- PrimeTime restores the session, reads the change list with
read_eco_changes(PT) and the parasitics withread_parasitics -eco(PT), andupdate_timing(PT) runs incrementally by default. read_eco_changes(PT) is PrimeTime only. It also replays awrite_changes -format eco(PT) binary between PT sessions, which needs a PrimeTime-ADV license; ICC2 has no such command.- Hierarchical designs read each block's change list and parasitics, and hierarchy is applied automatically. With DMSA, scenarios are created from saved images and the reads run in
remote_execute(PT). - Anything edited outside the start and stop window is not in the incremental data. The PT UG requires a final full extraction and full timing run for signoff, and that run is what catches such an edit.
What To Check
- ICC2 wrote the incremental change list and DEF at stop.
- StarRC ran in ECO mode on the right block.
- No unannotated nets after the incremental read.
- Timing change against what the ECO was expected to fix.
Command Checks & Actions
record_signoff_eco_changes -init -defSaves the baseline and writes Verilog and DEF for the flow.
record_signoff_eco_changes -start -input pt-eco_inc1.tclStarts tracking and applies the PT change list.
place_eco_cells -legalize_mode minimum_physical_impact -eco_changed_cells -legalize_only -displacement_threshold 10Legalizes the changed cells at their PrimeTime locations with minimal disturbance, as in the ICC2 UG incremental signoff flow.
route_ecoRoutes the changed nets.
record_signoff_eco_changes -stop -defStops tracking and writes the incremental data.
restore_session eco_session1Restores the saved PrimeTime session.
read_eco_changes ndm_path/design.incr.ptApplies the incremental netlist changes.
read_parasitics -eco Block_eco1_inc.gpdApplies the incremental parasitics.
report_annotated_parasiticsConfirms every net is annotated after the incremental read.
Healthy, Suspicious & Hard-stop Results
- Healthy (illustrative): Each loop takes about 45 minutes instead of 5 hours, and the final full run matches the last incremental session within a few picoseconds.
- Suspicious (illustrative): Unannotated nets on ECO cells after the incremental read, so the incremental parasitics did not cover them.
- Hard stop: Signing off on an incremental session without the final full extraction and timing run.
Common Mistake
The Trap: Fixing a short by hand in ICC2 after record_signoff_eco_changes -stop (ICC2). The edit is not in the incremental change list or the incremental extraction, so PrimeTime times a design that differs from the layout until the final full extraction finds it, usually in the week of tapeout.
What The Interviewer Is Testing
- The three-tool loop and what each tool writes.
- Is
read_eco_changes(PT) correctly placed in PrimeTime? - Knowing full signoff is still required.
Follow-up Question & Model Response
"Why keep a full extraction for final signoff if the incremental flow is accurate?"
Candidate Model Response: The incremental flow is only as good as its change tracking. Any edit outside the recorded window, or any drift between the saved sessions and the real layout after many loops, can slip through. The PT UG states that final signoff needs a full extraction and full timing analysis. That run is the independent check that the last incremental answer was right.
Practical Example
Tapeout Scenario: A block needs four ECO loops (illustrative). A full loop of extraction plus a fresh PT load and update takes 5 hours 20 minutes. With the incremental flow, loop 1 changes 380 cells, StarRC extracts the changes in 25 minutes and the PT incremental update takes 12 minutes, so the loop takes about 45 minutes with ICC2 time. Four loops take 3 hours instead of about 21. The final full extraction and timing run reports setup WNS +3 ps against +4 ps in the last incremental session.
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