What is the difference between set_false_path/set_max_delay and the more surgical set_disable_timing, and how does exception precedence resolve conflicts between them?
From PDVerse STA Mentor Guide · pdVerse Mentor Guide
Technical Explanation
set_false_path and set_max_delay define exceptions on a specific point-to-point path basis, while set_disable_timing removes timing arcs through a given pin entirely, which is more efficient when every path through that pin is genuinely false.
Timing-path Reasoning
set_false_path -from/-to targets a specific launch-to-capture path pairing and tells the tool to ignore timing on just that path. set_disable_timing [get_pins pin_name] instead disables timing arcs through the named pin altogether, which is described as more efficient when all paths through a pin are false — avoiding the need to enumerate every from/to pairing individually. set_max_delay/set_min_delay instead impose an explicit delay budget on a path rather than exempting it. Where multiple exceptions could apply to the same path, exception precedence resolves the conflict: set_false_path overrides set_max_delay on any path both apply to, but set_max_delay still governs nonoverlapping paths that the false_path exception doesn't cover.
Command
set_false_path -from [get_pins FFB1/CP] -to [get_pins FFB2/D];
set_disable_timing [get_pins pin_name]; set_max_delay 12.0 -from [get_cells
REGA] -to [get_cells REGB]; set_min_delay 2.0 -from [get_cells REGA] -to
[get_cells REGB]Switch-by-switch
-from/-to specify the launch and capture endpoints defining the path an exception applies
to. set_disable_timing takes a pin argument and disables all timing arcs through that pin
rather than a specific path pairing. -probe (on set_max_delay, e.g. set_max_delay 4.5 -to
I_TOP/MEM/U133/Z -probe) creates a timing endpoint without forcing it as an endpoint
for other exceptions, letting you measure at an intermediate point without disturbing other
constraint scoping.Expected Result
When a pin has every path through it genuinely false, set_disable_timing removes all those arcs in one efficient declaration; when only specific from/to pairings are false, set_false_path is the correct scoped tool; set_max_delay overrides default timing only on the paths it explicitly names, and yields to any overlapping set_false_path.
Failure Symptoms
Using set_false_path pair-by-pair on a pin where all paths are truly false leads to an unwieldy, incomplete, or error-prone constraint set compared to a single set_disable_timing; conversely, misapplying set_disable_timing on a pin where only some paths are false would incorrectly exempt paths that should still be checked.
Root Cause
Choosing the wrong granularity of exception (path-pair vs whole-pin) for the actual scope of the false condition, or not accounting for precedence rules when set_false_path and set_max_delay exceptions overlap on the same path.
Mentor Note — Debugging Procedure
Confirm whether the false condition truly applies to every path through the pin (favoring set_disable_timing) or only specific launch/capture pairs (favoring set_false_path); check for overlapping set_max_delay declarations and verify precedence resolves as expected (false_path wins on overlap, max_delay still applies elsewhere). set_disable_timing trades precision for efficiency when an entire pin's paths are false, while set_false_path/set_max_delay operate at path-pair granularity — and when they overlap, set_false_path always wins, with set_max_delay retaining authority only outside that overlap.
Continue learning free
Get a practical low-power chapter
Receive the existing “Low Power and Multivoltage Fundamentals” PDF chapter and its download link by email.
Continue practising