Hold fails in 3 of 12 corners while setup is tight in 2 others. How do you fix without ping-pong?

Short Answer

Fix hold once, in a DMSA session that contains all 12 scenarios, so every change is judged against setup in the tight corners and hold in the failing ones at the same time. Ping-pong comes from fixing the hold corners in one run and checking setup in another. Where no data-path change satisfies both, the endpoint is a real conflict and needs a clock or constraint answer.

Technical Explanation

• Hold fixing in PrimeTime honors setup slack and DRC. That rule only protects the scenarios the command can see. With the two slow scenarios outside the session, a hold buffer can consume their last picoseconds of setup without the tool knowing.
• In DMSA, a netlist change must be possible in all scenarios before it is committed to any. Running fix_eco_timing -type hold (PT) from the manager with all 12 scenarios in the session gives one set of changes checked against all of them.
• Map endpoints across corners before fixing. An endpoint failing hold in fast corners with plenty of setup in slow corners is easy. One failing hold in a fast corner with setup under 10 ps in a slow corner is the ping-pong candidate; list those separately.
• Use load cells for small violations. fix_eco_timing -type hold -load_cell_list (PT) fixes violations of a few picoseconds with less delay overshoot than the smallest buffer, which keeps setup damage low in the slow corners.
• Per-scenario margins exist, but be careful. set_eco_options -timing_hold_margin (PT) and set_eco_options -timing_setup_margin (PT) can be set per scenario; the PT UG shows a large negative hold margin in the worst corner so only setup is tested there. That saves runtime, but it hides hold in that corner, so it only works if hold there is known to be safe.
• Ask for reasons on what is left. With eco_report_unfixed_reason_max_endpoints (PT) set, -estimate_unfixable_reasons with code T means the timing margin is too tight: the delay hold needs would use setup slack, plus any setup margin you set, that some scenario does not have.
• Remaining conflicts are a clock problem: the capture clock arrives too late relative to launch in fast corners and too early in slow ones. Clock skew changes on that register, or a constraint review, are the real fix.

What To Check

• Hold slack per endpoint in the 3 failing scenarios next to setup slack in the 2 tight ones.
• That the DMSA session includes all 12 scenarios when hold fixing runs.
• Per-scenario ECO margins in the setup script.
• Unfixable reason codes on the remaining hold endpoints.

Healthy, Suspicious & Hard-stop Results

• Healthy (illustrative): All hold violations fixed in one DMSA pass and setup in the tight corners still above 10 ps.
• Suspicious (illustrative): A dozen endpoints left with reason code T, all under the same clock branch.
• Hard stop: Hold fixed in a separate run that excluded the slow scenarios, and setup now failing there. Revert and redo in one session.

What The Interviewer Is Testing

• Understanding that "hold fixing honors setup" only covers scenarios in the session.
• Can you separate easy endpoints from true multi-corner conflicts?
• Awareness of what per-scenario margins hide.

Follow-up Question & Model Response

"Why not simply add hold margin in the fast corners and fix again?"

Candidate Model Response: Extra hold margin makes the tool add more delay, and delay on a data path is setup cost in every corner. On endpoints with plenty of setup that is harmless, but on the ping-pong endpoints it guarantees a setup failure in the slow corners. I would rather fix to zero hold slack with load cells, confirm the conflict endpoints with PBA, and take the true conflicts to a clock fix.