AdvancedQuestion 18 of 63

Construct a scenario where forgetting sequential propagation makes a scan-disable silently ineffective.

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

Set set_case_analysis 0 [get_ports SCAN_MODE] (SDC) without enabling sequential case-analysis propagation on the scan flops, and the constant stops at their TE pins. It never crosses the flop, so the CP-to-TI scan arcs stay enabled and the scan chain keeps being timed - with no warning that anything is wrong.

A scan flip-flop with the case-analysis constant reaching its TE pin but the internal CP-to-TI scan arc still shown enabled, contrasted with the same flop after sequential propagation showing the arc disabled — Technical Reference DiagramConstruct a scenario where forgetting sequential propagation makes a scan-disable silently ineffective.

Technical Reference DiagramConstruct a scenario where forgetting sequential propagation makes a scan-disable silently ineffective.

Technical Explanation

The setup. A designer writes set_case_analysis 0 [get_ports SCAN_MODE] (SDC) intending to remove the scan chain entirely from analysis, but never runs set_case_sequential_propagation (PT) on the scan flops. The tool's global default for this propagation is never active, so nothing changes it.
How far the constant actually travels. The constant 0 does propagate forward through ordinary combinational logic and does reach the scan flops' TE (test enable) pins - that part works exactly as expected.
What it fails to do. Turning that TE=0 state into "the scan input path is inactive" requires sequential case analysis to be active on those specific flops. Without it, PrimeTime treats them as ordinary sequential cells that happen to have a constant on one input, nothing more.
The consequence. The CP-to-TI (clock-pin to scan-input) arcs inside those flops remain enabled, and the scan chain is still fully timed, exactly as if the case analysis had never been applied - and there is no error or warning to flag this.
How the mistake would actually surface. Indirectly: extra scan-network paths appearing in reports that are meaningless in functional mode, sometimes producing false violations, and always wasting analysis runtime on paths nobody needed timed.
How to catch it. Run report_disable_timing (PT) and check whether the CP-to-TI arcs show as disabled - they won't. Or look for scan paths still appearing in report_timing (PT) output.
The fix. Enable propagation on the right cells - set_case_sequential_propagation [get_cells scan_ff_*] - so the TE constant actually disables the scan arcs, then confirm with report_disable_timing.

Common Mistake

Assuming case analysis crosses every sequential cell by default the same way it crosses combinational logic, when sequential propagation is a separate setting that defaults to off.
Confirming the constant "worked" by checking it appears on the TE pin, without verifying the flop's internal arcs actually became disabled as a result.
Cost: an entire scan chain silently left in the timed design, adding meaningless paths, possible false violations, and wasted analysis runtime that nobody notices until someone investigates why scan paths keep showing up in functional-mode reports.

Follow-up Question & Model Response

What's the fastest single command to prove, after the fact, whether a scan-disable case analysis actually took effect on the flops rather than just reaching their TE pins?

Candidate Model Response: report_disable_timing on the scan flops is the fastest single check, because it reports which arcs are actually disabled in the timing graph rather than what value sits on a pin. If the CP-to-TI arcs for the scan flops don't appear in that report as disabled, the case analysis never took structural effect regardless of what report_case_analysis (PT) shows on the TE pin itself - which is exactly the gap this scenario exploits. Checking the pin value alone would give false confidence, since the constant genuinely is there; only checking the arc-disable state reveals whether it was ever translated into a real timing exclusion.

Practical Example

A 512-bit scan chain spans 64 flops named scan_ff_0 through scan_ff_63. set_case_analysis 0 [get_ports SCAN_MODE] is applied at the top of the SDC, and report_case_analysis confirms TE=0 on all 64 flops. But report_disable_timing shows none of their CP-to-TI arcs as disabled, and report_timing -through [get_pins scan_ff_30/TI] still returns a full timing path through the chain. Adding set_case_sequential_propagation [get_cells scan_ff_*] and rerunning both reports confirms all 64 CP-to-TI arcs now show disabled, and the scan-path query returns no results.

Complete STA Handbook