IntermediateQuestion 15 of 112

What is timing-exception precedence, and why can a broad false path silently swallow an intended multicycle exception?

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

When more than one timing exception could apply to the same path, the tool resolves the conflict by precedence rather than combining them — and set_false_path (SDC) takes precedence over set_multicycle_path (SDC). A broad false path declaration can therefore completely exclude a path an engineer meant only to relax with a multicycle exception, with no warning that the multicycle command was ever overridden.

Timing exception precedence hierarchy: a broad set_false_path overriding an intended set_multicycle_path on an overlapping path, revealed by report_exceptions — Technical Reference DiagramWhat is timing-exception precedence, and why can a broad false path silently swallow an intended multicycle exception?

Technical Reference DiagramWhat is timing-exception precedence, and why can a broad false path silently swallow an intended multicycle exception?

Technical Explanation

Why precedence rules exist at all. SDC lets a designer apply several different exceptions — false path, multicycle path, min/max delay — to overlapping sets of paths, often written by different people at different times. The tool needs a fixed rule for which one wins on a shared path, rather than merging them.
The actual precedence order. From highest to lowest: set_false_path (SDC), then set_max_delay/set_min_delay (SDC), then set_multicycle_path (SDC) last. A path-specific exception of the same type generally takes priority over a broader one covering the same path.
How a false path silently overrides a multicycle exception. If a broad set_false_path, written to exclude an entire clock domain crossing, happens to also match a specific path a separate set_multicycle_path was written to relax, the false path wins entirely — the multicycle command is simply never used for that path.
Why this is dangerous rather than just redundant. The engineer who wrote the multicycle exception may believe that path is still timed with extra cycles allowed, when it has actually been removed from analysis entirely.
How to catch it. report_exceptions (PT) lists every exception actually applied to each path, including which were overridden by precedence — running it after adding any new broad exception confirms nothing was silently swallowed.

Common Mistake

The Trap: Adding a new broad false path late in the project without checking whether it overlaps any existing multicycle or delay exception already written for a specific path.

Because precedence resolution happens silently, with no error or warning, the multicycle exception simply stops being used and nobody is told.
The affected path is now either completely untimed (if it should have been false all along) or, worse, a path that genuinely needed the relaxed multicycle timing is now excluded entirely, hiding a real constraint gap from every later report.

Follow-up Question & Model Response

If report_exceptions shows that a false path is overriding an intended multicycle exception on the same path, what is the correct fix?

Candidate Model Response: The fix is almost never to abandon the multicycle exception; it is to narrow the false path so it no longer matches that specific path, typically by adding a -through point that excludes the exact net or pin the multicycle exception was written for. Rewriting the false path with a tighter, more specific -from/-to/-through scope restores the multicycle exception's precedence on that path while keeping the false path's original intent intact elsewhere. Simply deleting the multicycle command instead would either leave the path with no exception at all or force it to be timed at full single-cycle speed, neither of which reflects the actual design intent.

Practical Example

A design has set_false_path -from [get_clocks TEST_CLK] -to [get_clocks FUNC_CLK] written to exclude a test-mode clock crossing, and separately set_multicycle_path 2 -from [get_pins CFG_REG/Q] -to [get_pins DATA_MUX/A1] written to relax a specific configuration-register path that is known to be slow but only needs to settle within two functional cycles. If CFG_REG happens to be clocked by TEST_CLK during one configuration mode, the broad false path silently takes precedence over the multicycle exception on that exact path. Running report_exceptions -from [get_pins CFG_REG/Q] reveals the false path is the one actually applied; the fix is adding -through [get_pins DATA_MUX/A1] conditions narrow enough to exclude that specific path from the false path's scope, restoring the intended two-cycle relaxation.

Complete STA Handbook