IntermediateQuestion 60 of 112Source: Synopsys PrimeTime User Guide: Case and Mode Analysis

What is set_case_analysis, and how does it differ from a false path?

From PDVerse STA Mentor Guide · pdVerse Mentor Guide

By Tabish Iqbal · 9+ Years VLSI Physical Design Experience

Short Answer

set_case_analysis (SDC) fixes a pin or port to a constant logic value for the whole analysis run, so the tool treats that input as never toggling in any mode it checks. A false path instead leaves the pin free to toggle and only removes one specific launch-to-capture pair from setup and hold checking. Because case analysis changes what the tool believes the hardware does, it can remove entire branches of logic from analysis; a false path removes only the paths you name.

Side-by-side diagram: set_case_analysis fixing a mux select pin so the unselected branch disappears from the design entirely, versus set_false_path leaving the same mux toggling but excluding one labeled path from setup/hold checking. — Technical Reference DiagramWhat is set_case_analysis, and how does it differ from a false path?

Technical Explanation

The two commands solve different problems, even though both are used to cut down what gets checked.

What set_case_analysis does: set_case_analysis 0|1|rising|falling|static (SDC) fixes a pin's logic value for every timing calculation in that run, not just for one path.
The knock-on effect: logic fed only by the fixed pin — say, one input of a 2:1 mux that is permanently selected away — is treated as unreachable, so the tool never even builds paths through it.
What set_false_path does instead: set_false_path -from ... -to ... (SDC) removes exactly the named path from setup and hold checking, but the pin keeps toggling normally in the model, and every other path through that pin is still fully checked.
Scope is the real difference: case analysis changes what the circuit is, for the whole scenario; a false path changes what is checked, without changing the assumed behavior of the hardware.
Why the gap matters: marking a pin false when it really does toggle across modes hides one real path from one check. Marking it constant when it can genuinely change means the tool never builds any of those paths at all — a much bigger blind spot.
When each one fits: case analysis suits a genuinely fixed configuration, such as a test-mode strap tied off after boot. A false path suits one launch/capture pair that never happens together, while both endpoints stay active on other paths.

Common Mistake

The Trap: using set_case_analysis on a mode-select pin that actually changes during normal functional operation, not only at reset.

A designer ties off a boot_mode pin with case analysis because it looks constant after power-up, missing that a later warm-reset path drives it to the other value.
The tool then never builds or reports any path through the branch selected by that other value, so a real functional path goes completely unchecked instead of merely being deprioritized.

Follow-up Question & Model Response

If a pin is constant 0 during one operating mode but toggles freely in another mode you also need to analyze, can you still use set_case_analysis on it?

Candidate Model Response: Not as one blanket setting for both modes — set_case_analysis fixes the pin for the whole run, so applying it once would make the tool blind to the mode where the pin actually toggles. The usual approach is to run case analysis inside a separate scenario for the fixed-value mode, and remove it with remove_case_analysis (SDC) in the scenario where the pin is active. Each scenario then gets an accurate model of that mode, instead of one setting silently overriding the other mode's real behavior.

Practical Example

On a chip with a TEST_EN port, the team sets set_case_analysis 0 [get_ports TEST_EN] (SDC) in the functional-mode scenario, which removes an entire scan-shift datapath from that scenario's analysis. In the separate test-mode scenario, they run remove_case_analysis [get_ports TEST_EN] and apply set_case_analysis 1 instead, just for that scenario. Both scenarios sign off independently. A set_false_path used in place of case analysis — from the functional flops to the scan-shift path — would still have built and reported that scan path in the functional scenario, only excluded from setup and hold checking, which wastes analysis time without matching the real fixed configuration.

Complete STA Handbook