Why is a false path dangerous if the "it can never happen" assumption turns out to be wrong?
From PDVerse STA Mentor Guide, part of the pdVerse Mentor Guide
Short Answer
A false path is a path the tool can trace through the netlist, but which the engineer asserts can never actually be exercised in real functional operation — for example, a path only active in a test mode that never coexists with the capturing clock. set_false_path (SDC) tells the tool to stop timing that path entirely, so if the assumption behind it is wrong, the path ships with zero timing verification and no warning.
Technical Explanation
- What a false path claims. STA analyzes every path it can trace through the netlist, whether or not it can genuinely occur during real chip operation.
set_false_path(SDC) is the designer telling the tool: this path will never be exercised in a way that matters for timing, so stop checking it. - Common reasons a path gets marked false. Two flops driven by clocks that never operate together, a configuration register read only once at reset, or a scan-test-only path that never runs functionally are typical candidates.
- What happens once it's marked false. The tool removes that path from setup and hold analysis completely — it never shows up in a report, never contributes to WNS or TNS, regardless of how much real delay is on it.
- Why a wrong assumption is dangerous. If the "can never happen" assumption turns out to be false — the two clocks do briefly run together during a power-mode transition — the path stays completely invisible to STA, with no partial checking or reduced-confidence warning.
- Why this is worse than an unconstrained path. An unconstrained path at least shows up as a violation in
check_timing(PT). A false path that shouldn't have been false produces a clean report while hiding a real, unverified path — the failure mode caught only in silicon.
Common Mistake
The Trap: Marking a path false because it looks like it belongs to an unused mode, without tracing every real functional condition under which it could actually be exercised.
- Designers under schedule pressure sometimes false-path a whole clock domain crossing to quiet a report, rather than proving with a functional or formal review that the crossing genuinely never both toggles.
- Once marked false, that path gets zero scrutiny again — a silicon bug from this exact mistake is one of the hardest categories to root-cause after fabrication, since STA reports gave no hint anything was wrong.
Follow-up Question & Model Response
What review practice would catch a false path that was applied too broadly, before tapeout rather than after?
Candidate Model Response: A false-path review should trace each set_false_path command back to a specific functional justification — a documented mode exclusivity, a formal clock-domain-crossing proof, or a reset condition — rather than accepting "this looks unused." Cross-checking the false-path list against the clock definitions with report_clock_groups or a similar report catches cases where two clocks assumed never to run together actually can, such as during a low-power mode transition. Any false path that only has a comment like "should be fine" instead of a traceable functional reason is a candidate for re-verification before signoff, since that is exactly the pattern behind most false-path-related silicon bugs.
Practical Example
A chip has a 200 MHz functional clock and a 50 MHz test clock feeding shared scan-enable logic. An engineer applies set_false_path -from [get_clocks TEST_CLK] -to [get_clocks FUNC_CLK] reasoning that scan mode and functional mode never run together. Months later, a low-power feature briefly enables the test clock during a functional debug hook without fully gating scan-enable, creating a real, timed path between the two clocks that was never re-verified because the false path silently excluded it from every subsequent STA run. The fix, once discovered, was to replace the broad false path with set_case_analysis (SDC) on the scan-enable pin during functional-mode signoff runs, so the path is provably inactive rather than just assumed inactive.
Complete STA Handbook
Master Signoff-Ready Static Timing Analysis
Get the complete 10-chapter STA handbook covering setup/hold margins, clock modeling, OCV/POCV, crosstalk noise, and PrimeTime closure.
Offline PDF Bundle
Want all 1109 questions offline?
Get the complete 4-book PDF bundle (PnR, STA, MMMC, Low Power) with a clickable table of contents - no ads, no internet needed.
Continue practising