What does write_changes do at the end of a PrimeTime ECO session?

Short Answer

write_changes (PT) takes every edit an ECO command like fix_eco_timing (PT) made inside PrimeTime's model and writes it out as a script of concrete netlist edits — cell resizes, buffer insertions, connections — that another tool can apply. Without this step, the ECO exists only inside PrimeTime's own view of the design and never reaches the real netlist or the physical layout.

Technical Explanation

An ECO fixing command changes PrimeTime's internal model first; write_changes is what turns that internal change into something the rest of the flow can use.

• After fix_eco_timing (PT), fix_eco_drc (PT), or fix_eco_power (PT) run, PrimeTime holds a list of proposed edits in memory, not yet reflected anywhere outside the tool.
• write_changes (PT) writes that list out, recording the location of each change so the receiving tool knows exactly which cell or net to touch.
• The physical implementation tool then reads this output and applies the same edits to the real, placed netlist, including legalizing any cell that a resize or insertion displaced.
• This two-step handoff — fix inside PrimeTime, then apply via the physical tool — keeps ECO changes traceable, since the change list itself becomes a record of exactly what was modified and why.
• Skipping write_changes (PT) and only trusting PrimeTime's in-memory report means the fix looks real in the report but was never actually implemented in the design.
• The written change list is also what a design team reviews before accepting an ECO, since it is a short, readable summary instead of a full netlist diff.

Follow-up Question & Model Response

If the physical implementation tool cannot legalize one of the cell placements that write_changes specifies, what happens to that part of the ECO?

Candidate Model Response: That specific change fails to apply cleanly, and the physical tool typically reports it back as an unresolved or partial ECO item rather than silently dropping it. The design team then has to decide between a different fixing method — a smaller buffer, a different available site — or accepting a slightly different location for that cell. This is exactly why a full timing re-verification after applying the change list matters: PrimeTime's estimate assumed the fix would apply exactly as written, and a legalization conflict means the real result can differ from that estimate.