Setup violation | Hold violation | |
|---|---|---|
Nature | Path too long (or clock too fast) | Path too short (or skew too large) |
Corner intuition (check all required views) | Slow data often limits | Fast data often limits |
RTL fixes | Fewer logic levels, pipelining, retiming, lower fanout, registered outputs | Rarely RTL; avoid skewed gated/divided clocks between connected flops |
Implementation fixes | Cell upsizing, buffering, placement, useful skew | Insert hold (delay) buffers, rebalance clock tree |
Constraint fixes | Relax the clock; add a valid multicycle path (only if true) | None (never relax a hold constraint to pass) |
Side effect of the fix | Tighter hold on the same flop's inputs when using skew | Slightly worse setup on that path; more area and power |
Applies at | Every stage of the flow | Mostly after clock tree synthesis |
Fix setup first, then build the clock tree and fix hold. Re-check both at all corners.
Follow the arrows from the top. Each box is one step; the diamond is the one review point.
Setup comes before the clock tree because its fixes change the logic; hold comes after because only real clock latencies show the true skew.
The buffer count is a health check: thousands of hold buffers hint at skew or architecture problems, not at a hold-fixing job.
The dashed arrow is the reason for the last step: confirm the fixes did not trade one check for the other.
No. Hold buffers add delay to short paths; if a few of them share a start or end with a critical path, their setup slack drops a little. Re-run setup after hold fixing.