IntermediateQuestion 63 of 112Source: Synopsys PrimeTime User Guide: Setting Multicycle Paths

Why would you choose a multicycle path over a false path for a signal that changes slowly?

From PDVerse STA Mentor Guide · pdVerse Mentor Guide

By Tabish Iqbal · 9+ Years VLSI Physical Design Experience

Short Answer

A false path removes a path from timing checking entirely, which is only correct if the path's timing genuinely never matters. A multicycle path instead tells the tool the real number of clock cycles available, so a slow signal that does need to meet a timing budget — just a looser one than one cycle — stays checked, with a deadline that matches how the hardware actually behaves.

A configuration register updating once every 16 cycles, shown with a 32ns multicycle budget line versus what a false path would look like on the same signal: no budget line at all, no check performed. — Technical Reference DiagramWhy would you choose a multicycle path over a false path for a signal that changes slowly?

Technical Explanation

The choice comes down to one question: does this path have a real deadline, just a longer one, or no deadline at all?

A false path claims the timing never matters. set_false_path (SDC) removes the path from setup and hold checking completely, which is appropriate for paths that are functionally guaranteed never to be sampled in a way that timing could break.
A multicycle path claims a longer, but real, deadline. set_multicycle_path -setup N ... (SDC) tells the tool the path is allowed N clock cycles instead of one, and the tool still checks that the path completes within that window.
A slow signal usually has a real deadline. A configuration register updated once every 16 cycles still needs its value to arrive before the logic reading it samples it — just not within one cycle. That is exactly the case a multicycle path was built for.
Using a false path here removes real protection. If a bug or a later change made that same slow signal take even longer than 16 cycles to settle, a false path would still report a clean pass, while a multicycle exception would correctly flag it as a violation.
The multiplier automatically tracks the clock period. A set_multicycle_path value stays correct if the clock period changes later; a set_max_delay value written as a fixed number does not update itself and can quietly become wrong.
Rule of thumb: if you can state a specific number of cycles the signal is allowed to take, use a multicycle path. Reach for a false path only when no number of cycles would ever make the path relevant.

Common Mistake

The Trap: reaching for a false path on any signal that "looks slow", without asking whether it still has a real deadline it must meet.

A designer sees a signal change once every several cycles and assumes it is safe to exclude from timing entirely, treating "slow" as equivalent to "timing doesn't matter".
If the signal later takes longer than intended, the false path hides the resulting violation completely, instead of flagging it the way a multicycle exception would.

Follow-up Question & Model Response

A colleague argues a false path is simpler to write than a matched multicycle path, so it should be preferred whenever a signal is slow. How do you respond?

Candidate Model Response: Simplicity is not the deciding factor — correctness of what gets checked is. A false path and a multicycle path make different claims about the hardware: one says timing never matters here, the other says timing matters but over a longer window. If the signal genuinely has a cycle budget, even a generous one, a false path throws away real protection against future changes, while a multicycle exception keeps that protection with an accurate deadline. I would only agree to the false path if we could state, in writing, that no delay on that path could ever cause a functional problem.

Practical Example

A configuration register in a 500MHz core (2ns period) only needs to present a stable value once every 16 cycles, giving it a 32ns budget instead of 2ns. The team applies set_multicycle_path -setup 16 -from [get_cells CFG_REG] -to [get_cells CONSUMER_REG] (SDC) with set_multicycle_path -hold 15 ... to anchor the hold check near the launch edge. When a later library swap adds 3ns of delay, report_timing (PT) still shows positive slack against the 32ns budget — a check a false path on the same signal would never have performed.

Complete STA Handbook