How does an ECO in PrimeTime fix a hold violation without touching placement?

Short Answer

A PrimeTime ECO fixes a hold violation by inserting a delay buffer or upsizing a cell on the failing path using commands like insert_buffer or size_cell (PT), choosing cells from a list of pre-placed spare cells or small legal gaps so the physical implementation tool doesn't need to re-place or re-route the design. Because hold is fixed by adding delay to the data path rather than by making anything faster, and delay-adding cells are small and local, this kind of fix can usually stay confined to the immediate site of the violation instead of disturbing the surrounding layout.

Technical Explanation

fix_eco_timing -type hold (PT) automatically finds hold-violating paths and proposes fixes -- inserting a delay buffer or upsizing a cell along the data path -- that add just enough delay to clear the violation without pushing setup on the same path into failure.

• The command's -methods option restricts which fix types it may use, such as {size_cell insert_buffer}, so a flow can exclude fixes that would require moving existing cells or adding new routing that a placement-locked design cannot accommodate.
• Because a hold fix only needs to add delay, and a buffer or slightly larger cell takes up roughly the same footprint as what it replaces or fits into a nearby gap, the fix rarely requires disturbing any other cell's placement.
• Many flows pre-place spare, unconnected cells -- sometimes called programmable spare cells -- across the layout specifically so a late-stage ECO can connect one of them into the netlist instead of inserting a brand-new cell that would need fresh placement.
• write_changes (PT) then writes out the list of edits -- which cell was resized, which spare cell was connected, and where -- in a format the place-and-route tool can read back and apply, keeping the physical implementation tool informed of exactly what changed.
• Fixing setup, by contrast, usually needs the opposite direction of change -- downsizing delay, not adding it -- which more often requires resizing several cells along a path or occasionally moving a cell closer to its neighbor, making a setup ECO more likely to touch placement than a hold ECO.

Follow-up Question & Model Response

Why must a hold fix that adds a buffer still be re-verified with a full STA run instead of trusting PrimeTime's own ECO fix report?

Candidate Model Response: fix_eco_timing recalculates timing after each proposed edit and reports whether the targeted violation cleared, but that check runs on the same in-memory model the edit was made to, not on the actual routed layout the placed-and-routed tool eventually produces. The inserted buffer or spare cell still has to be physically connected and routed, and the real parasitics of that new route can differ from PrimeTime's placeholder estimate for a not-yet-routed net. A full re-run of STA after the physical implementation tool completes the edit confirms the fix holds with real, extracted parasitics rather than an estimate, and also confirms the added delay didn't create a new setup violation on the same path or a neighboring one sharing the same clock or resource. Skipping that re-verification is exactly the gap the Signoff & ECO closure checklist exists to catch.