Why do setup and hold fixes pull in opposite directions?

Short Answer

Setup wants data to arrive earlier and hold wants it to arrive later, so any change to a data path helps one check and costs margin on the other. Clock skew has the same effect: a later capture clock helps setup and hurts hold on the same flop. The goal is to fix each on the paths where the other has spare margin.

Technical Explanation

• Setup checks the latest possible arrival against the next clock edge. Hold checks the earliest possible arrival against the same edge. One path has a valid window, and fixes move the arrival inside it.
• Making a data path faster, by upsizing, Vt swapping or buffering a long wire, moves arrival earlier. Setup slack goes up and hold slack on that path goes down. On a long path this rarely matters, but on a path that is short at the fast corner and long at the slow corner it can create a hold failure.
• Adding delay does the opposite. A delay cell improves hold and eats setup margin. If the path has little setup margin at the slow corner, the hold fix creates a setup violation.
• Skew pulls both ways at once. A later capture clock gives a failing setup path more time and shrinks the hold margin on every path into that flop. Useful skew is a trade, and the stage that gives up the time has to be able to afford it.
• Different corners make the conflict worse. Setup is worst at the slow corner and hold at the fast corner, so a path can have plenty of hold margin in one corner and none in another. Every fix has to be checked against the opposite check in the opposite corner, not only in the scenario where it was made.
• PrimeTime encodes this in the ECO fixing order. Setup fixing avoids new DRC violations but is allowed to introduce hold violations, while hold fixing preserves setup slack. That is why the recommended order is DRC, then setup, then hold.
• The safe place for a hold fix is on the part of the path that only the hold-failing endpoint uses. Adding delay on a shared branch delays other endpoints that might be setup-critical. For setup fixes the same logic applies in reverse: speeding up a shared cell speeds up short paths through it as well.

Follow-up Question & Model Response

"A flop has a setup violation on one input path and a hold violation on another. What can you do?"

Candidate Model Response: I cannot use skew at that flop, because moving its clock helps one check and hurts the other. I would fix each path on its own data branch: speed up the setup path by sizing or buffering, and add delay on the hold path close to the capture pin, on the branch no other endpoint shares. I would check that the hold fix does not eat the setup margin of that same path at the slow corner. If both paths share most of their logic, I would look for a restructure rather than trading ps back and forth.