ExpertQuestion 27 of 69

A path shows negative setup slack, but you believe it's a genuine multicycle path that was never constrained. Give the end-to-end procedure to confirm and fix it safely.

From PDVerse STA Mentor Guide, part of the pdVerse Mentor Guide

By Tabish Iqbal, who has 9+ years of VLSI Physical Design experience

Short Answer

Treat it as an investigation, not a slack-closing shortcut. Confirm the path is real and see what already constrains it, get the real number of allowed cycles from the RTL designer, apply set_multicycle_path -setup N with the matching -hold (N-1), then re-check with report_timing -exceptions all that the exception is dominant and covers exactly this path and nothing else.

Multicycle path investigation flow: all_fanout confirming the path exists, then a paired set_multicycle_path -setup 2 / -hold 1 exception on addr_reg to decode_reg — Technical Reference DiagramA path shows negative setup slack, but you believe it's a genuine multicycle path that was never constrained. Give the end-to-end procedure to confirm and fix it safely.

Technical Reference DiagramA path shows negative setup slack, but you believe it's a genuine multicycle path that was never constrained. Give the end-to-end procedure to confirm and fix it safely.

Technical Explanation

A negative setup slack that looks like it should be a multicycle path is one of the more dangerous shortcuts in STA, because "just add the exception" can silently pass a real bug.

Confirm the path physically exists first. all_fanout -from launch_reg -to capture_reg (PT) verifies there really is a logical path between the two flops, rather than assuming it from a schematic or a guess.
Check what already constrains the path. report_timing -from launch_reg -to capture_reg -exceptions all (PT) shows whether some other exception is already dominant, or whether the path genuinely sits on the default single-cycle check.
Get the real answer from the designer, not the failing report. How many clock cycles does the enable logic actually allow the data to take? Never invent a cycle count that happens to make the slack pass.
Apply the setup exception with the confirmed count. set_multicycle_path -setup N -from [get_cells launch_reg] -to [get_cells capture_reg] (SDC) tells the tool the setup check spans N clock cycles.
Pair it with the matching hold exception. By default, set_multicycle_path -setup N alone shifts the implicit hold check's capture edge, giving (hold cycles) = (setup value) − 1 − (hold value), which with the default hold value of 0 is N − 1 cycles. Adding set_multicycle_path -hold (N-1) -from [get_cells launch_reg] -to [get_cells capture_reg] (SDC) moves the hold check back to line up with the first legal launch edge.
Re-verify, do not assume it passed. report_timing -exceptions all (PT) confirms the exception is now dominant on exactly this path and that the object list did not sweep in neighboring paths.
Document and diff. Compare the new constraint against the golden SDC and record why the exception exists — a multicycle path is a design fact with a paper trail, not a private fix.

Common Mistake

The Trap: applying set_multicycle_path -setup N alone to make the slack pass and stopping there, without the matching -hold exception.

The default hold-cycle shift, N − 1, is usually not the intended relationship and can either mask a real hold violation or manufacture one that was never there.
The exception "working" — setup slack turning positive — gives false confidence, because nobody re-checked whether the hold side of the same path is now analyzed against the wrong edge.

Follow-up Question & Model Response

"The designer tells you the enable only allows 2 cycles, but report_timing -exceptions all shows your new multicycle exception is 'overridden' rather than 'dominant'. What do you do next?"

Candidate Model Response: An overridden exception means something else in the constraint set — commonly a set_false_path (SDC) or a conflicting set_multicycle_path (SDC) from another file — is taking priority on that path, so my new exception has no effect and the reported slack is not coming from the number I just set. I would use report_timing -exceptions all (PT) to identify exactly which command is winning, confirm with the designer or the owning team whether that command is still valid, and only then decide whether to remove the conflicting exception or adjust the object lists so the intended multicycle relationship actually takes effect.

Practical Example

A path from addr_reg to decode_reg on a 250 MHz bus clock, CLK_BUS (4 ns period), fails setup by 3.1 ns under the default single-cycle check. The bus protocol owner confirms the decode logic is only sampled every second cycle by design, so the path legitimately gets 2 cycles. Applying set_multicycle_path -setup 2 -from [get_cells addr_reg] -to [get_cells decode_reg] (SDC) gives an 8 ns setup window, turning the 3.1 ns violation into a 0.9 ns pass. Pairing it with set_multicycle_path -hold 1 -from [get_cells addr_reg] -to [get_cells decode_reg] (SDC) — matching N − 1 = 1 — moves the hold check's capture edge back to the first legal launch edge, and report_timing -exceptions all (PT) confirms both exceptions are dominant on that path and nowhere else.

Complete STA Handbook