Why can hold violations appear after routing, and how are they fixed?

Short Answer

Routing changes both clock and data timing. A clock branch that picked up extra delay moves the capture edge later, and a data path sped up by same-direction crosstalk or a short route arrives earlier, so hold margin shrinks. Postroute hold is fixed by adding delay to the data path near the capturing flop, usually with delay cells or buffers, and then re-checking setup.

Technical Explanation

• A hold check requires data to stay stable for a short time after the capture clock edge. If data changes too early, the flop can capture the new value in the wrong cycle.
• Routed clock wires rarely match the CTS estimate exactly. If the capture branch got slower than the launch branch, skew grows in the direction that hurts hold.
• Crosstalk can speed up a data net when an aggressor switches the same way, which makes data arrive earlier on min paths.
• Hold is checked in fast corners, such as fast process and best RC corners, where everything is quicker. Those corners must be active during postroute optimization.
• route_opt fixes hold by default along with setup, typically by inserting delay cells or buffers on data paths and by sizing. It then legalizes and ECO routes the changed nets.
• Hold fixes add delay, so every fix risks setup. Paths with little setup margin need care, and the fix is best placed near the capture flop, where it does not also slow other paths sharing the start of the route.
• Adding many hold buffers in a congested area can create new routing problems, so congestion near the fixes matters too.

What To Check

• Hold violations per scenario after routing, with report_qor.
• The worst hold paths and whether clock skew or data speed-up caused them.
• Setup slack on the same paths after hold fixing.
• Congestion and DRCs where hold buffers were added.

Healthy, Suspicious & Hard-stop Results

• Healthy (illustrative): No hold violations in any fast-corner scenario, setup still clean, and no DRC increase.
• Suspicious (illustrative): A few hundred small hold violations after routing that route_opt clears with small setup cost.
• Hard stop: Hold fixing that pushes setup negative on the same paths, which usually means the clock skew problem should be fixed instead.

What The Interviewer Is Testing

• Whether you can name the physical causes of postroute hold changes.
• Do you place fixes carefully and re-check setup?
• A strong answer shows you make sure the right scenarios are active.

Follow-up Question & Model Response

"When should you fix hold with the clock instead of with data path delay?"

Candidate Model Response: When many hold violations share the same capture clock branch, the cause is usually skew on that branch, not the data paths. Adding delay to hundreds of data paths treats the symptom and costs area and setup margin. Adjusting the clock, for example resizing a clock buffer so that branch is less late, can fix them all at once. It has to be done carefully because it also moves setup on every path through that branch.