What typically causes a setup violation?

Short Answer

A setup violation means data reaches the capture flop too late for the next clock edge. The usual causes are too much logic between flops, weak drivers, long or detoured wires, a capture clock that arrives earlier than the launch clock, derates, and crosstalk that slows the signal. Most real failures are two or three of these adding together.

Technical Explanation

• Deep logic is the first suspect. If a path has 25 stages of logic in a period that fits 15, no amount of sizing will close it. The fix belongs in RTL, through pipelining or restructuring, or in a multicycle exception if the design really allows two cycles.
• Weak drivers show up as a large cell delay followed by a slow transition. An X1 cell driving a long net or many loads switches slowly, and the slow edge also makes the next cell slower. The report shows this as a big Incr on the cell and a large transition value.
• Long wires and detours come from placement and routing. Two connected cells placed far apart, or a net that has to route around a macro or congested area, add resistance and capacitance. Delay on a long unbuffered wire grows roughly with the square of its length.
• Negative skew hurts setup. If the capture clock arrives earlier than the launch clock, the required time moves earlier while the arrival time stays the same. A path that passes with ideal clocks can fail after CTS for this reason alone.
• Derates and uncertainty take margin away. For setup, on-chip variation derates make the launch clock and data path slower and the capture clock faster, so both sides of the slack move the wrong way. Clock uncertainty is subtracted directly from required time.
• Crosstalk can slow a victim net when a neighbour switches in the opposite direction at the same time. That delta delay only appears once SI is enabled on routed parasitics, which is why some paths fail only at signoff. Paths that run long distances beside busy buses are the usual victims.
• Operating conditions matter. Setup is usually worst at the slow process, low voltage corner, and temperature inversion in newer nodes can make the cold corner the slow one.
• Before fixing anything, identify which cause dominates by reading the report. The cheapest fix follows from the cause: sizing for a weak driver, buffering for a long wire, clock work for skew. Guessing wastes ECO loops and adds area where none was needed.

Follow-up Question & Model Response

"A path meets setup before CTS and fails by 50 ps after CTS with no data path change. What happened?"

Candidate Model Response: The data path did not change, so the difference is in the clocks. Before CTS the clocks were ideal, so launch and capture latency were equal. After CTS the capture flop probably gets its clock later or earlier than the launch flop, and here the capture clock arrives earlier, which is negative skew for setup. Clock uncertainty may also have changed from a pre-CTS value to a post-CTS value. I would compare the two clock network delay lines in the report to confirm.