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?

Short Answer

set_false_path and set_max_delay are point-to-point exceptions: they remove or replace the timing requirement on specific paths but the tool still computes and can report the path's delay. set_disable_timing instead removes the arcs through a pin, cell, or port from the timing graph entirely, so no path can be traced through that point at all — more efficient when every path through a point is genuinely false. When exceptions conflict on the same path, PrimeTime resolves it per path using a fixed priority: set_false_path beats set_max_delay/set_min_delay, which beats set_multicycle_path, and a more specific -from/-to/-through specification beats a more general one.

Technical Explanation

• set_false_path (SDC) declares that a specific path — matched by -from/-to/-through — should not be checked for timing at all. The tool still calculates the path's delay internally, but does not flag it as a violation regardless of how long the delay is.
• set_max_delay (SDC) instead replaces the normal clock-derived requirement on a matched path with an explicit numeric delay budget, useful for paths without a normal clock relationship (for example, to an asynchronous or external interface) that still need some bound checked.
• set_disable_timing (SDC) works differently in kind, not just in strictness: it removes the specified pin, cell, or port from the timing graph, so the tool cannot trace any path through that point in either direction. There is no delay computed through a disabled arc at all, because the arc itself no longer exists for analysis purposes.
• The PrimeTime User Guide states directly: if every path through a given pin is false, set_disable_timing [get_pins pin_name] is more efficient than set_false_path -through [get_pins pin_name], because the tool can skip that arc entirely during graph traversal instead of tracing every individual path through it and then discarding each one.
• When exceptions conflict on the same path, the tool applies exception type priority independently per path (not per command): set_false_path has the highest priority, then set_max_delay/set_min_delay, then set_multicycle_path — so a path declared false stays false even if a set_max_delay also matches it, and the max-delay setting is silently ignored for that specific path (visible with report_exceptions -ignored, PT).
• Path-specification priority is separate from type priority: a more specific -from/-to pin-level match overrides a more general clock-level match for two commands of the same exception type, and -from pin outranks -to pin, which outranks -through, which outranks -from clock/-to clock.
• What breaks: assuming a broad set_false_path -through X and a narrower set_max_delay -from A -to B (where the through-point also lies on that A-to-B path) both apply is wrong — the false-path setting wins for that specific path, and the max-delay budget is silently never enforced there, which can hide a real timing requirement the designer thought was still active.

Follow-up Question & Model Response

"You have set_false_path -through [get_pins muxA/Z] for a specific mux, but you later discover a legitimate, real timing path also happens to pass through that same mux output pin for an unrelated signal. What went wrong, and how do you fix the scope?"

Candidate Model Response: The mistake is treating -through as if it only matched the paths the designer had in mind, when it actually matches every path passing through that pin, including the unrelated legitimate one. I would tighten the false-path declaration to a full -from/-through/-to specification that names the actual startpoint and endpoint of the paths meant to be excluded, rather than relying on -through alone to disambiguate, since -through matches based on pin traversal, not intent. I would then confirm with report_timing -from ... -to ... on the previously-mistaken-for-false path that it is now correctly analyzed, and use report_exceptions to confirm the narrowed false-path declaration no longer overlaps it.