Why does a set_case_analysis value set directly on a pin win over one set on its driver?

Short Answer

The tool applies a fixed priority order whenever two case analysis settings conflict on the same object: a value set directly on a pin or port always overrides a value that merely propagates to it from an upstream driver. This lets a designer override a general upstream setting for one specific downstream pin without having to change the upstream setting itself.

Technical Explanation

Case analysis values can come from two places on the same pin — a direct set_case_analysis command, or propagation forward from an upstream constant — and the tool needs a rule to pick a winner.

• Direct beats propagated, unconditionally. A set_case_analysis (SDC) value applied straight to a pin or port always takes priority over a conflicting value that only reached that pin by propagating through combinational logic from somewhere upstream.
• Newer beats older, on the same object. If two direct set_case_analysis commands target the exact same pin, the one issued later in the constraint file wins, so command order in the SDC file matters.
• A set_case_analysis value beats a built-in constant. If the netlist itself ties a pin to a constant — for example in the Verilog source — an explicit case analysis command on that pin still overrides the netlist-level constant.
• Among propagated values only, logic 0 wins first, then static, then logic 1. This tie-break only matters when nothing was set directly and two different constants are propagating in from different directions.
• Why the direct-wins rule is useful: it lets a designer set one broad upstream case analysis value — say, for a whole test mode — then locally override just one downstream pin that genuinely behaves differently, without touching the broad setting.
• The risk is an unintended override. If a downstream direct setting was written for an old netlist version and is now stale, it can silently override a newer, correct upstream propagated value without any error being reported.

Follow-up Question & Model Response

You change an upstream mode-select pin's case analysis value, but one downstream gate still reports the old configuration. What's the first thing you would check?

Candidate Model Response: I would check whether that specific downstream pin has its own direct set_case_analysis command somewhere in the constraint set, since a direct setting always overrides a propagated one regardless of how the upstream value changed. I would search the SDC files for that pin's exact name rather than assuming the upstream change should have reached it automatically. If I found a stale direct setting left over from an earlier design phase, I would remove it so the pin goes back to inheriting the correct, current value from upstream, and I would re-run the analysis to confirm the downstream logic now reflects the new mode.