Why does PrimeTime not propagate a set_case_analysis constant through a flip-flop by default, and how do you turn that on for specific cells?

Short Answer

A logic constant set with set_case_analysis (SDC) propagates automatically through combinational gates, but the tool stops it at a flip-flop's output by default, because a sequential cell's output value depends on its stored state and clock behavior, not purely on its input value the way a combinational gate's output does. Overriding that default — for the whole design with a variable, or for specific cells with set_case_sequential_propagation (PT) — is a deliberate, narrow decision, not something to switch on globally without checking each cell it affects.

Technical Explanation

• Case analysis constants set with set_case_analysis 0 or 1 (SDC) on a pin or port propagate forward through combinational logic automatically, the same way a constant driven directly by the netlist does — an AND gate with both inputs tied to logic 1 propagates a logic 1 from its output, for instance.
• The case_analysis_sequential_propagation (PT) variable controls whether that automatic propagation continues through sequential cells; its default is never, meaning a flip-flop or latch stops the propagation at its output regardless of what constant value is set on its data input.
• Setting case_analysis_sequential_propagation to always turns this on for every sequential cell in the design, which is a broad, design-wide change with no per-cell control.
• The narrower, cell-specific alternative keeps the variable at its default never and instead runs set_case_sequential_propagation (PT) on a specific list of cell instances or library cells, enabling propagation only through those named cells.
• This matters because a flip-flop only reliably outputs the same constant as its data input if it is verified to never toggle under the case condition — for example, a scan flop permanently held in reset — which is a design-specific fact the tool cannot infer on its own from the netlist.
• report_case_analysis -sequential_propagation (PT), or querying the is_case_sequential_propagation attribute, confirms exactly which cells have propagation enabled, which matters because the setting silently changes what downstream logic the tool treats as constant.
• What breaks: enabling propagation through a sequential cell that is not actually held constant under the modeled case condition creates a false constant downstream, potentially removing real timing paths from analysis as if they could never toggle, when in fact they can.

Follow-up Question & Model Response

"If I only need this behavior for one specific reset-holding flop, what's the safest way to verify it before enabling propagation?"

Candidate Model Response: Confirm from the design intent, not from the timing tool, that the specific flop is provably held at a constant value under the modeled case, for example a scan flop tied into permanent scan-hold during the mode being analyzed. Leave case_analysis_sequential_propagation at its default never, and instead run set_case_sequential_propagation (PT) naming only that instance or its library cell, so no other sequential cell in the design is affected. Follow with report_case_analysis -sequential_propagation to confirm exactly that one cell, and nothing else, now has propagation enabled, before trusting any downstream slack numbers that depend on it.