How do you fix hold without creating new setup violations?

Short Answer

Add delay where the data path has setup margin to spare, not simply where the hold violation shows up. Delay added at a pin helps hold on every path through that pin and costs setup on the same paths, so the right pin is the one whose worst setup path still passes after the delay goes in. For very small violations, around 5 ps or less, a load cell adds just enough delay without the overshoot of a whole buffer.

Technical Explanation

• Hold and setup pull the same arrival time in opposite directions. Adding d ps at a pin improves hold by d on paths through it and costs d of setup on every path through that pin, including paths to other endpoints.
• So the violating endpoint is not always the right place. Check each candidate pin with report_timing -delay_type max -through U45/Z (PT) and pick the one with the most setup slack through it.
• fix_eco_timing -type hold (PT) runs that search for you. By default hold fixing uses both sizing and buffer insertion, and it avoids introducing setup and DRC violations, which is why it runs after setup fixing.
• Load cells fix the smallest violations. In the PT UG example a path has -2 ps hold and +6 ps setup; the smallest buffer adds 7 ps and leaves +5 ps hold but -1 ps setup, while a 3 ps load cell leaves +1 ps hold and +3 ps setup, in less area.
• Use -load_cell_list with -buffer_list in one run and the tool uses load cells for small violations and buffers for larger ones. Or run a load-cell pass limited to violations between 0 and -3 ps, then a buffer pass for the rest.
• Load cells are dedicated single-pin cells, or buffers and inverters with their outputs left unconnected. In the physically aware flow the site search for both buffers and load cells is bounded by eco_insert_buffer_search_distance_in_site_rows (PT), default 8 site rows.
• Some violations cannot be fixed on the data path because every candidate pin is tight on setup. Once eco_report_unfixed_reason_max_endpoints (PT) is set, fix_eco_timing -type hold -estimate_unfixable_reasons (PT) flags these with reason T, timing margin too tight, and they need a clock-side or constraint review.

What To Check

• Hold and setup slack on the same endpoint, each in its worst scenario.
• Worst setup slack through each candidate insertion pin.
• Size of each violation: a few picoseconds suits a load cell, larger needs a buffer or delay cell.
• Setup WNS and TNS in every setup scenario before and after the hold pass.

Healthy, Suspicious & Hard-stop Results

• Healthy (illustrative): Hold WNS moves from -21 ps to +1 ps and setup WNS in the slow corner is unchanged at +9 ps.
• Suspicious (illustrative): Hold closes but setup WNS drops from +9 ps to +1 ps, or 200 delay cells were added to fix 40 endpoints.
• Hard stop: Any new setup violation created by the hold pass, or violations above 20 ps reported unfixable because timing margin is too tight.

What The Interviewer Is Testing

• Whether you treat hold fixing as choosing where to put delay, weighing setup slack through each pin.
• Awareness of load cells as a finer tool than buffers for tiny violations.
• Do you recheck setup in every scenario, not just the one being fixed?

Follow-up Question & Model Response

"What if every candidate pin on a hold path has almost no setup margin?"

Candidate Model Response: Then the data path cannot absorb delay without breaking setup, and you look at the clock side. Delaying the launch clock fixes hold but costs setup on every path those flops launch and hold on the paths they capture, so check that first. In PrimeTime, clock network fixing uses -cell_type clock_network and needs the physically aware flow with a PrimeTime-ADV license. It is also worth checking hold uncertainty and derates in the fast corner, because over-margined hold uncertainty can create a violation that silicon would never see.