Construct a scenario where forgetting sequential propagation makes a scan-disable silently ineffective.
From PDVerse PrimeTime STA Interview Guide · pdVerse Mentor Guide
Ten-second Interview Answer
Set set_case_analysis 0 [get_ports SCAN_MODE] without enabling sequential propagation on the scan flops and the constant stops at their TE pins: the CP->TI scan arcs stay enabled and the scan chain is still timed, with no warning.
Complete Technical Explanation
Here is the scenario. You write set_case_analysis 0 [get_ports SCAN_MODE] intending to remove the scan chain from the analysis, but you never enable sequential case-analysis propagation on the scan flops - the global default is never, and you did not run set_case_sequential_propagation on them. The constant 0 does propagate forward through the combinational logic and does reach the scan flops' TE pins. What it cannot do is turn that TE=0 state into the conclusion that the scan input path is inactive, because that translation requires sequential case analysis to be active on those flops. Without it PrimeTime treats them as ordinary sequential cells, the CP->TI scan arcs remain enabled, and the scan chain is still timed. Your scan-disable did nothing, silently. The visible symptoms are indirect: extra scan-network paths that are meaningless in functional mode, possibly producing false violations, and definitely wasting runtime. You would only catch it two ways - by running report_disable_timing and noticing the CP->TI arcs do not appear as disabled, or by seeing scan paths show up in report_timing . The fix is to enable propagation on the right cells, for example set_case_sequential_propagation [get_cells scan_ff_*], so that the TE constant actually disables the scan arcs, and then verify with report_disable_timing . This is the canonical trap that case analysis does not cross flops by default.
In Pd / Signoff
Any functional-mode signoff run on a scan-inserted netlist hits this. After sourcing the mode constraints you check report_disable_timing for the expected CP->TI disables before you trust a single timing report; if they are absent you add targeted set_case_sequential_propagation on the scan flops. It is the difference between a clean functional QoR review and hours spent debating scan-path violations nobody needs to fix.
Common Trap
Believing a correctly applied port constant is sufficient proof the scan chain is off. The value is on the port, report_case_analysis looks right, and yet the arcs were never disabled because propagation stopped at the flops. The falsifiable check is whether CP- >TI arcs appear in report_disable_timing .
Expect Next
Why is flipping the global setting to always a dangerous way to fix this instead of using per-cell
Topic And Primetime Commands
Case & Mode Analysis / Case Analysis. set_case_sequential_propagation, report_disable_timing, set_case_analysis, get_ports
Keep building interview depth
Continue practising STA
Continue learning free
Get a practical low-power chapter
Receive the existing “Low Power and Multivoltage Fundamentals” PDF chapter and its download link by email.
Continue practising