Why is a false path dangerous if the "it can never happen" assumption turns out to be wrong?
From PDVerse STA Mentor Guide · pdVerse Mentor Guide
Explanation
A false path is a path that STA can trace through the netlist topologically but that the engineer asserts can never actually be exercised in functional operation — for example, a path only active during a mode that never coexists with the capturing clock. set_false_path tells the tool to stop timing it entirely.
Timing-path Walkthrough
Declaring set_false_path is effectively a promise to the tool that the path's behavior doesn't matter for correctness. If that promise is wrong — if the path actually can be functionally exercised — then a real timing check has been silently removed from analysis. The chip can then fail in silicon on a path that was never actually checked, even though the STA report looked completely clean.
Command
set_false_pathExpected Report Behavior
A path under a false path exception disappears from timing analysis entirely — report_timing may show nothing for it, or a wildcard false path can accidentally exclude an unrelated path that shares the same clock, as in the notes' example where an expected FF_a→FF_b path showed nothing because a wildcard set_false_path -from [get_clocks clkX] matched FF_a's clock.
Mentor Note — Common Mistake
Using an overly broad clock-based wildcard (e.g., -from [get_clocks clkX]) that unintentionally captures paths beyond the one truly meant to be excluded.
How To Debug
If an expected path is missing from report_timing, check for a false path exception with a wildcard clock or pin match that may have unintentionally caught it, as in the notes' notanalyzed-path example.
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