What is the difference between a placement-only ECO and a full ECO that changes cell instances?

Short Answer

A placement-only ECO moves existing cells to new legal locations without changing what those cells are or how they're connected -- used for physical fixes like DRC cleanup or small routing congestion relief. A full ECO changes the netlist itself -- swapping a cell's size or type, inserting a new buffer, or rewiring a connection -- which is what a timing fix from fix_eco_timing (PT) actually does, and which then requires the physical tool to place and connect whatever new or changed cell the edit introduced.

Technical Explanation

A placement-only ECO keeps the netlist's logical content fixed -- same cells, same instance names, same connectivity -- and only asks the place-and-route tool to relocate one or more existing instances to resolve a physical problem, such as two cells placed too close together.

• A full ECO changes the netlist: it can add a new cell instance, remove one, change an existing instance's cell type (a resize, technically swapping one library cell for another with the same logical function), or rewire which pin drives which net.
• Timing ECOs from PrimeTime are, by this distinction, full ECOs -- size_cell, insert_buffer, and any pin rewiring all change what the netlist actually contains, not just where existing content sits.
• A full ECO's netlist changes still need placement and routing applied afterward -- a new buffer instance needs a site and a route, same as a placement-only ECO's moved cell needs a legal new location -- so the two categories overlap in what the physical tool has to do, even though they differ in whether the logical netlist changed.
• Because a full ECO touches the netlist, it needs a fresh logical equivalence check (LEC) against the pre-ECO netlist to confirm the change didn't alter functional behavior, a step a placement-only ECO doesn't need since its netlist is provably identical to before.
• Distinguishing the two matters for signoff planning: a placement-only ECO late in the flow is comparatively low-risk since functional behavior cannot have changed, while a full ECO, even a small, targeted timing fix, always needs both the LEC and a re-verified STA pass before it can be considered closed.

Follow-up Question & Model Response

If a resize genuinely can't change logical function, why does it still need a logical equivalence check at all?

Candidate Model Response: The equivalence check isn't really verifying that resizing a cell changes its logic function -- it almost never does -- it's verifying that the ECO script actually did what it intended to do, correctly, across the whole netlist, not just at the one site the designer was looking at. A scripted or automated ECO applied across many instances at once can have an error in its target list, its pin mapping, or its connectivity update that has nothing to do with the resize itself being logically safe. Running LEC catches a broader class of mistakes than whether the resize changed logic, including a mis-targeted edit that touched the wrong instance entirely. Skipping it because the specific edit type is inherently low-risk conflates the safety of the edit's intent with the safety of its actual scripted execution, which are two different questions.