IntermediateQuestion 31 of 112

Why is "case analysis propagates forward only" a fundamental limitation to keep in mind?

From PDVerse STA Mentor Guide, part of the pdVerse Mentor Guide

By Tabish Iqbal, who has 9+ years of VLSI Physical Design experience

Short Answer

Setting a constant with set_case_analysis (SDC) constrains only what's downstream of that pin — the tool never infers which upstream values would be logically necessary to produce it. So the constant has to be placed where its value can propagate forward to reach the logic it's meant to simplify.

Logic cone showing set_case_analysis placed on a downstream internal node failing to reach the upstream decode gates, versus placement on the real controlling port propagating forward correctly — Technical Reference DiagramWhy is "case analysis propagates forward only" a fundamental limitation to keep in mind?

Technical Reference DiagramWhy is "case analysis propagates forward only" a fundamental limitation to keep in mind?

Technical Explanation

Case analysis is a forward-only operation, and that shapes where you're allowed to place constants.

What placing a constant actually does: set_case_analysis 0 [get_pins ...] (SDC) constrains only the logic downstream of that pin; the tool won't back-solve the upstream logic to work out which input combinations would have produced that constant value.
The practical implication: if the mode you want to force is really determined by some internal signal, the constant has to go on a pin from which the value can actually propagate forward to the arcs and conditions you care about — pinning a downstream pin doesn't reach backward to constrain what feeds it.
Why mode-select constants belong on the controlling input: a RAM's read_write pin, for example, is the correct place, not some internal node you merely wish were constant, because only the controlling input's value actually propagates forward through the mode logic.
The quiet failure mode: setting the constant somewhere convenient produces no error. The mode condition upstream is simply never evaluated against the intended value, so the mode doesn't resolve the way the designer assumed — and nothing in the tool's output flags this as a mistake.
The rule of thumb: ask which pins the value needs to reach, then trace backward through the logic by hand to find the real control point, and set the constant there. The tool only does the forward half; the backward reasoning is the designer's job.

Common Mistake

The Trap: placing set_case_analysis on a convenient internal node instead of the actual controlling input, and trusting that the tool will "figure out" the upstream implications.

A designer wants to force test mode off and pins an internal enable signal near the block of interest, assuming that's equivalent to pinning the real mode-select port far upstream.
The command runs cleanly with no warning, but the upstream mode-select logic is never simplified, so paths through the untouched upstream mux are still analyzed in both modes, silently defeating the point of the case analysis.

Follow-up Question & Model Response

How would you confirm that a set_case_analysis constant actually reached and simplified the logic you intended, rather than trusting the command ran without error?

Candidate Model Response: Use report_case_analysis (PT) or check the constant-propagation results with report_disable_timing-style commands to see which pins actually ended up constant as a consequence, not just the pin you directly set. If the mux or gate you expected to simplify away still shows both input arcs active in report_timing (PT), the constant never reached it, meaning it was placed downstream of, not upstream of, the logic that needed simplifying. Tracing the fanin cone from the target logic back to a real controlling port, before writing the command, avoids this check being needed after the fact.

Practical Example

A memory controller has a test_mode internal signal that's the output of a small decode block fed by pins TM_SEL0 and TM_SEL1. A designer runs set_case_analysis 0 [get_pins decode/test_mode] (SDC), expecting the whole upstream decode logic to be removed from analysis. Because test_mode is downstream of TM_SEL0/TM_SEL1, the decode gates themselves are still fully analyzed in both states. Rewriting the command as set_case_analysis 0 [get_ports TM_SEL0] -set_case_analysis 0 [get_ports TM_SEL1] on the actual controlling ports lets the value propagate forward through the decode gates, and report_timing confirms the decode path no longer appears as a live arc.

Complete STA Handbook