Hold violations are frequency-independent, physically guaranteed failures. Unlike setup violations (which can be resolved by reducing the clock frequency), a hold violation means data will overwrite a flip-flop before it has finished capturing its current value — every time, regardless of how slow the clock is. They appear en masse after CTS and must be eliminated — without exception — before tape-out.
Before CTS, STA uses ideal clocks with zero skew. After CTS, real clock tree buffers introduce local skew — the clock arrives at different times at physically adjacent flip-flops. Consider two flip-flops FF_L (launch) and FF_C (capture) connected by a very short combinational path:
Short paths are the most vulnerable because a very short combinational delay (e.g., a direct connection or a single buffer) means data arrives almost immediately after FF_L launches it. If FF_C’s clock came even 10ps early, a 1-gate path may have a hold violation.
The hold check compares the minimum data arrival time against the minimum required hold time:
Hold slack = Min_data_arrival − (Capture_clock_arrival + Hold_time)
For hold to pass, this must be ≥ 0. Min_data_arrival uses the fastest (best-case) data path; Capture_clock_arrival uses the latest (worst-case) capture clock to maximise pessimism (making the hold window as short as possible); Hold_time is the flip-flop’s hold time from Liberty.
The primary fix for a hold violation is inserting buffers (delay cells) on the data path to increase the minimum data arrival time. The goal: make Min_data_arrival exceed Capture_clock + Hold_time.
Standard cells provide dedicated delay elements: DLYB1, DLYB2, DLYB4 (increasing delay values), or simply a pair of series inverters. The number of buffers needed depends on the hold violation amount.
Every buffer inserted for hold increases both the minimum AND maximum path delay. If setup slack on that path was already tight (say +0.050 ns) and you insert a DLYB2 adding 0.070 ns, you’ve now created a setup violation (-0.020 ns). Always check setup timing after hold ECO. Hold-aware timing closure alternates between hold and setup fixes.
Cells on very short paths (single-gate or two-gate paths) may have been previously upsized or swapped to LVT for setup fixing. LVT cells are fast — which is great for setup but makes them the worst cells for hold. Swapping them back to SVT or HVT slows the minimum path.
| Cell Vt | Min path delay | Hold impact | Setup impact |
|---|---|---|---|
| LVT | Shortest (fastest) | Worst for hold (data arrives earliest) | Best for setup |
| SVT | Nominal | Standard | Standard |
| HVT | Longest (slowest) | Best for hold (data arrives latest) | Worst for setup |
Useful skew can also help hold violations. By making the launch FF’s clock arrive later relative to the capture FF’s clock (increasing the effective data flight time budget), hold margin improves on that specific path pair. However, this means delaying the launch clock, which reduces setup margin on that same path. Useful skew for hold trades setup margin for hold margin — only viable if setup has sufficient margin to spare.
In production design flows, hold fixing is an automated ECO step run after CTS and routing:
The best time to prevent hold violations is during CTS, not after. A hold-aware CTS strategy actively controls local skew:
Investing effort in hold-aware CTS typically reduces post-route hold ECO buffer count by 50–80%, saving routing resources and reducing congestion from inserted buffers.
Hold violations are physical failures that occur every clock cycle, regardless of clock frequency. They cannot be fixed by running at a lower frequency. A design with unresolved hold violations is non-functional silicon — period. Never approve tape-out with any hold violations, and never apply set_false_path or set_multicycle_path to hide a real hold violation. The only acceptable fixes are physical: more delay on the data path, less skew in the clock tree.
Pre-CTS STA uses ideal clocks with zero local skew. After CTS, real clock buffers create local skew between adjacent flip-flops. If the capture FF’s clock arrives earlier than the launch FF’s clock (positive skew in capture direction), the hold window shrinks. Short data paths can’t sustain even 30–50ps of this skew without violating hold.
Buffer (delay cell) insertion on the data path is the primary fix. By adding one or more delay cells between the launch FF’s output and the capture FF’s input, the minimum data arrival time increases. Each delay cell adds approximately 0.05–0.10 ns depending on cell type. The inserted delay must exceed the hold violation amount plus hold margin.
HVT (High Threshold Voltage) cells switch slower than SVT or LVT cells due to higher Vt. Swapping cells on a short hold-violating path from LVT or SVT to HVT increases the minimum path delay. This is complementary to buffer insertion and is especially useful when LVT cells were previously inserted for setup fixes, inadvertently creating hold vulnerabilities on those paths.
No. Hold violations are frequency-independent functional failures — they occur every clock cycle regardless of how slow the clock is. A chip with hold violations will fail in the field, consistently and irrecoverably. Unlike setup violations (which can be mitigated by reducing frequency), hold violations have no operational workaround. They must be fixed physically before tape-out.
Hold-aware CTS controls local skew between adjacent flip-flops during clock tree building. By targeting local skew < 30ps, the CTS tool prevents the worst-case skew conditions that cause post-CTS hold violations. This reduces the amount of ECO buffer insertion needed after routing, saving routing resources and avoiding congestion from hundreds of inserted delay cells.