Compare disabling a path with case analysis, set_disable_timing and set_false_path - mechanism, blast radius, and when each is the right tool.

Short Answer

Case analysis sets a fixed value and structurally kills every arc that value controls; set_disable_timing removes one specific arc or object entirely; set_false_path removes exactly the point-to-point paths named. There is an efficiency ladder favoring them in that order.

Technical Explanation

• All three remove paths from analysis, but at different levels. They differ in what triggers the removal and how far its effect spreads - its blast radius.
• Case analysis: mechanism. set_case_analysis (SDC) fixes a signal to a constant value. The propagated constant structurally disables whatever logic arcs that value controls, so its blast radius is everything downstream of that constant - potentially a whole mode's worth of logic from a single signal.
• Case analysis: when it's right. It is the correct tool when a real control signal or a real operating mode is the actual root cause of a path being irrelevant - test mode, a configuration strap, a disabled feature.
• set_disable_timing: mechanism and blast radius. set_disable_timing (PT) removes a specific arc, pin, or cell from timing analysis directly. Its blast radius is every path passing through that specific object, regardless of the logic driving it.
• set_disable_timing: when it's right. It fits when all paths through one specific point are irrelevant no matter what the logic does - a genuinely dead pin, or an arc that will never be exercised.
• set_false_path: mechanism and blast radius. set_false_path (SDC) is a point-to-point exception whose blast radius is exactly the paths named in its -from/-through/-to specification - the most flexible of the three, but tracked as an exception with its own precedence bookkeeping, and the costliest to maintain at scale.
• The efficiency ladder. Prefer case analysis first, since it addresses the root cause structurally with zero exception bookkeeping. Reach for clock groups or set_disable_timing next. Use false paths last, reserved for crossings that are not mode-governed.

Follow-up Question & Model Response

A scan-test path and a functional-mode-only path both need to be removed from analysis. Would you use the same tool for both, and why or why not?

Candidate Model Response: No - they call for different tools because their root causes are different in kind. The scan-test path is removed by a real, known control signal (test-mode enable), so set_case_analysis on that signal is the right, root-cause fix, and it structurally disables the whole scan cone at once. The functional-mode-only path, if it's a single specific crossing not governed by any one control signal - say a documented false timing path between two asynchronous but unrelated blocks - is better handled with a targeted set_false_path, since there's no clean control signal to fix instead. Using the same tool for both would either over-apply a false path where a cleaner case-analysis constant exists, or try to force case analysis onto a path that has no controlling signal to set.