How are hold violations fixed with delay cells, and where should they go?

Short Answer

Hold violations are fixed by adding delay to the data path so new data arrives after the hold window closes. The delay cell goes near the capture flop, on the branch that only the hold-failing endpoint uses. That keeps the delay off shared logic that may feed setup-critical endpoints. Always check the setup margin of the fixed path at the slow corner.

Technical Explanation

• Hold is fixed by adding delay, not by changing the clock period. You can add a delay cell or buffer, or downsize a cell to slow it down.
• Delay cells are buffers designed to be slow, with long intrinsic delay in a small footprint. They give a predictable delay without driving a lot of load.
• Placement matters. The start of a path often feeds many endpoints. Adding delay there slows every path through it, including ones that are setup-critical. Near the capture flop D pin, the delay only affects that endpoint.
• The same path has a setup check too. A delay that fixes hold at the fast corner is larger at the slow corner. If setup slack there is smaller than that added delay, the fix creates a setup violation.
• fix_eco_timing -type hold (PT) uses both cell sizing and buffer insertion by default and seeks to avoid introducing setup and DRC violations. You give it the cells to use with -buffer_list.
• For very small violations, the PT UG shows -load_cell_list with fix_eco_timing -type hold (PT): a load cell adds capacitance to slow the net slightly, which fixes violations of about 5 ps or less without the over-fix that even the smallest buffer can cause.
• Check with report_timing -delay_type min (PT) in the fast corners and report_timing -delay_type max (PT) in the slow corners after the fix.

What To Check

• Hold slack at every fast corner, not only the one used for fixing.
• Setup slack of the same path at the slow corner, before and after.
• Whether the delay cell sits on a shared branch or on the endpoint branch.
• Total count of delay cells and whether they fit near the target flops.

Healthy, Suspicious & Hard-stop Results

• Healthy (illustrative): Hold WNS at or above 0 in every fast scenario, and setup slack on fixed paths still at or above 20 ps.
• Suspicious (illustrative): A fixed path whose setup margin dropped under 5 ps. It is closed but fragile against the next extraction.
• Hard stop: Hundreds of delay cells needed on one flop group. Look for a clock skew or constraint problem before adding more.

What The Interviewer Is Testing

• Knowing to add delay near the capture flop on the unshared branch.
• Checking setup on the same path after a hold fix.
• Can you name what PrimeTime hold fixing does by default?

Follow-up Question & Model Response

"Hundreds of flops in one region fail hold by 40 to 60 ps. Would you add delay cells to all of them?"

Candidate Model Response: Not before looking at the clock. A large group failing by a similar amount often points to capture clocks arriving much later than launch clocks in that region, or to a wrong constraint such as a missing multicycle hold adjustment. Fixing the cause may clear them all at once. If the clock and constraints are correct, I would use fix_eco_timing -type hold (PT) and check the placement space for so many delay cells.