Why does setting only -setup 2 create a hold problem? Walk the edges.
From PDVerse STA Mentor Guide, part of the pdVerse Mentor Guide
Short Answer
Because a hold check's reference edge is derived from the same-cycle setup relationship, not defined independently. Moving the setup capture edge out by one cycle drags the implied hold edge forward with it, demanding data stay stable for a full extra cycle the real hardware never needs.
Technical Explanation
- Hold checks are not independent of setup - they're derived from it. All hold relationships in PrimeTime are computed from the valid setup relationship on the same path, not set as their own separate rule.
- The default, same-clock-edge case. On a path with a 10-unit clock period, data launched at t=0 is normally captured by the very next edge, at t=10 - that's the default setup relationship. The matching hold check uses the capture edge one cycle earlier, at t=0, the ordinary same-edge hold check.
- What -setup 2 does to the setup edge.
set_multicycle_path 2 -setup(SDC) moves the setup capture edge out from the first edge at t=10 to the second edge at t=20 - exactly the intent, giving the path two full cycles to complete. - What that drags along, uninvited. The implied hold edge follows the setup edge, landing one cycle before the new setup edge - so it moves from t=0 to t=10. PrimeTime is now demanding that data launched at t=0 stay stable at the capture flop until t=10, a full cycle later than the ordinary hold check ever required.
- Why real hardware almost never needs that. The enable signal that gates a genuine two-cycle data transfer does not typically also hold the source data steady for an extra cycle - so the tool reports a large, artificial hold violation that no realistic buffering fix addresses.
- The idiom that prevents it. Write the matching hold exception in the same breath:
set_multicycle_path 1 -hold(SDC) alongsideset_multicycle_path 2 -setup, pulling the implied hold edge back to where the real hardware behavior actually requires it.
Common Mistake
- Writing
set_multicycle_path 2 -setupalone and treating the job as done, without checking whether the hold report on the same endpoint suddenly shows a large new violation. - Attempting to fix the resulting hold violation by inserting delay buffers, which papers over a self-inflicted artificial violation rather than removing its actual cause.
- Cost: real engineering time spent buffering a path against a hold requirement the hardware was never supposed to have, while the one-line fix - a paired -hold exception - sits unwritten.
Follow-up Question & Model Response
If a designer sees a huge positive setup slack right after applying set_multicycle_path 2 -setup, should that be treated as good news? What else must be checked before moving on?
Candidate Model Response: A huge positive setup slack right after the change is expected, not necessarily good news on its own - it simply reflects that the path now has a full extra cycle to work with, which was the intent. What must be checked before moving on is the hold report at the exact same endpoint, since the implied hold edge just moved forward by one cycle as a direct side effect. If a paired -hold exception wasn't added, that endpoint will very likely show a new, large hold violation that has nothing to do with the physical path delay and everything to do with an unaddressed implied edge shift. Treating the setup number as the whole story, without checking hold at the same point, is exactly how this trap gets missed.
Practical Example
A path from fast_reg/Q to slow_reg/D runs on a 10-unit-period clock. Single-cycle analysis shows required time ~1000, arrival ~1400, giving slack ~โ460 (a violation). Applying set_multicycle_path 2 -setup -to [get_pins slow_reg/D] moves the required time to ~2000 against the same 1400 arrival, giving slack ~+540 - passing. But the same endpoint's hold report, with no paired hold exception, now shows a false violation around โ380, because the implied hold edge moved from t=0 to t=1000. Adding set_multicycle_path 1 -hold -to [get_pins slow_reg/D] restores the hold check to its correct t=0 reference, clearing the false violation without touching a single cell.
Complete STA Handbook
Master Signoff-Ready Static Timing Analysis
Get the complete 10-chapter STA handbook covering setup/hold margins, clock modeling, OCV/POCV, crosstalk noise, and PrimeTime closure.
Offline PDF Bundle
Want all 1109 questions offline?
Get the complete 4-book PDF bundle (PnR, STA, MMMC, Low Power) with a clickable table of contents - no ads, no internet needed.

Continue practising