Walk through the fix_eco_timing flow for setup versus hold, and explain why the recommended ECO fixing order matters.

Short Answer

fix_eco_timing fixes setup violations by default using cell sizing alone, reducing data path delay without adding buffers, while it fixes hold violations using both cell sizing and buffer insertion, adding delay where a path is too fast. Setup is fixed first because it is the harder violation to repair and is allowed to introduce new hold violations along the way; hold is fixed second, and it deliberately avoids reintroducing setup or design-rule violations, since fixing hold after setup means the setup picture is already considered final.

Technical Explanation

• fix_eco_timing -type setup (PT) reduces data path delay to close setup violations, using cell sizing (swapping in a faster-drive version of the same logical cell) by default, without inserting buffers or touching the clock network.
• fix_eco_timing -type hold (PT) instead needs to add delay to a path that is too fast, and by default uses both cell sizing (toward slower drive strength) and buffer or inverter-pair insertion to add controlled delay, since sizing alone often cannot add enough delay margin the way it can remove it.
• The -type argument is mandatory on every invocation — you must explicitly choose setup or hold each time, because the two violation types need fundamentally different fixing strategies and cannot share one default behavior.
• Setup fixing is done first in the recommended order because setup violations are generally harder to fix (there is less headroom for aggressive sizing before running into area, power, or design-rule limits), and the command explicitly allows setup fixing to introduce new hold violations as a side effect, since hold is comparatively easier to fix afterward.
• Hold fixing is done second and deliberately avoids introducing new setup or design rule violations, because at that point the setup timing has already been accepted as the target to preserve — reordering this (fixing hold first) risks the subsequent setup pass undoing or conflicting with delay just added for hold.
• -pba_mode exhaustive (PT) can be added to either fixing pass to use path-based timing (real, path-specific delays) instead of the default graph-based estimate, reducing unnecessary over-fixing caused by graph-based pessimism, at the cost of additional runtime.
• -methods {size_cell insert_buffer} (PT) lets a designer explicitly restrict or expand which fixing techniques are allowed for a given pass, and -cell_type clock_network (PT) extends fixing into the clock tree specifically, which is off by default since clock-network changes carry more downstream risk than local data-path changes.
• What breaks: running hold fixing before setup fixing, or running both without respecting this dependency, risks the setup-repair pass later undoing delay the hold pass just added, forcing another iteration and consuming more ECO turns than the recommended order needs.

Follow-up Question & Model Response

"After a setup fixing pass introduces a few new hold violations, as the command allows, how would you decide whether the follow-up hold fixing pass actually resolved them cleanly, without silently reopening any of the setup fixes?"

Candidate Model Response: I would re-run report_timing -delay_type min (PT) style checks, or more directly rerun a full setup and hold summary via report_global_timing (PT), after the hold pass completes, rather than trusting the hold pass's own completion message alone. Since hold fixing by default is required to avoid introducing new setup or DRC violations, a clean completion should mean the setup numbers from the prior pass are unchanged; I would specifically diff the worst setup slack values before and after the hold pass to confirm nothing regressed, and check the -estimate_unfixable_reasons (PT) output for any hold violations the tool could not resolve without touching setup-critical cells.