The ECO loop won't converge: setup fixes reopen hold, which reopens DRC. How do you break the cycle?

Short Answer

The loop exists because each fixing step is allowed to hurt something else. PrimeTime defines precedence rules for exactly this reason: DRC fixing can degrade setup and hold, setup fixing honors DRC but may degrade hold, and hold fixing honors both setup and DRC. Run the steps in that order, give each step margins, and find the paths where no legal answer exists instead of looping over them.

Technical Explanation

• The PrimeTime UG recommended order is power recovery with fix_eco_power (PT), then DRC and noise with fix_eco_drc (PT), then timing with fix_eco_timing (PT), then a final leakage recovery by Vt swapping. Each step runs after the ones it is allowed to break.
• Setup fixing seeks to avoid new DRC violations but may introduce hold violations, because setup is the harder problem. Hold fixing avoids introducing both setup and DRC violations. So running hold last is what stops hold from being reopened.
• By default fix_eco_timing (PT) does not fix timing on paths that have DRC violations, and setup or hold fixing does not degrade DRC. If DRC is left dirty, timing fixing quietly skips those paths and you think the tool is failing. -ignore_drc changes that, but then timing fixing can degrade max_transition, max_capacitance and max_fanout, which feeds the loop. DRC that returns after a hold pass without it comes from the ICC2 implementation (legalization, ECO routing).
• Many small hold violations fixed with full buffers overshoot and eat setup slack. For violations of a few picoseconds, fix_eco_timing -type hold -load_cell_list (PT) inserts load cells, which add a small delay with less area; the PT UG example uses load cells for hold violations down to -3 ps and buffers for the rest.
• Margins stop the tool leaving paths at exactly zero. set_eco_options -timing_setup_margin (PT) and -timing_hold_margin give a later step room to move without flipping the sign.
• Ask the tool why, before changing options. Set eco_report_unfixed_reason_max_endpoints (PT) to the number of endpoints to explain, then fix_eco_timing -type hold -estimate_unfixable_reasons (PT) reports reasons without changing the design. Code T (timing margin too tight) on a hold endpoint means the delay needed would break setup plus any setup margin. If T remains with margins at zero, it is a real conflict, not a tool problem.
• If many changes disturb ECO routing and legalization in ICC2, the PrimeTime UG suggests fixing DRC, setup and hold one at a time, starting with the type that causes the most changes.

What To Check

• The order the ECO script runs the fix commands in, and whether hold runs last.
• Whether -ignore_drc (PT) is set anywhere in the loop.
• Unfixable reason codes on endpoints that keep coming back.
• Endpoints that fail setup and hold in different scenarios, which no data-path fix can satisfy.

Healthy, Suspicious & Hard-stop Results

• Healthy (illustrative): Each pass reduces violations by a clear step, and the third pass changes fewer than 1% of the cells the first pass changed.
• Suspicious (illustrative): The same 40 endpoints flip between setup and hold on every pass.
• Hard stop: Hold endpoints report reason code T with setup slack already at zero in another scenario. The loop cannot converge by fixing; the clock or the constraint has to change.

What The Interviewer Is Testing

• Knowing the precedence rules between DRC, setup and hold fixing in PrimeTime.
• Can you tell a real setup/hold conflict from a script ordering problem?
• Using unfixable-reason reports instead of re-running with different options.

Follow-up Question & Model Response

"What do you do with an endpoint whose hold violation cannot be fixed without breaking setup?"

Candidate Model Response: First confirm it is real: check both checks with exhaustive PBA in the scenarios where each fails. If the data path has no room, the fix is in the clock, for example reducing capture clock skew on that register, or in the constraint if the hold check is on the wrong edge. Data-path buffering cannot solve it, because every picosecond added for hold comes straight out of setup. I report it as a design conflict with numbers from both scenarios.