Why does marking a path false when it actually toggles cause a silicon bug?
From PDVerse STA Mentor Guide · pdVerse Mentor Guide
Short Answer
set_false_path (SDC) tells the tool to stop checking a path's delay completely — it does not stop the real hardware from switching. If that path genuinely does carry a changing signal during functional operation, its real delay is never verified, and a slow path can fail silently in silicon while every report stays clean.
Technical Explanation
The exception only changes what the tool looks at, never what the transistors actually do.
- What the tool stops doing: once a path is marked false,
report_timing(PT) never computes or reports a slack number for it again, under any corner, in any future run. - What the silicon keeps doing: the actual wires and gates on that path are completely unaffected by the SDC file — if the path was ever going to switch in real operation, it still will.
- Why the mistake is easy to make: a path might look safe to exclude because it rarely switches, or only switches in a corner case the designer did not think through carefully enough before writing the exception.
- Why the failure is so hard to catch: because the tool no longer reports on the path at all, there is no slack number, no warning, and no violation to notice — the report looks completely clean, which is the most dangerous kind of undetected problem.
- Where it eventually surfaces: the bug typically shows up much later, as an intermittent functional failure in the lab or in the field, and tracing it back to a false timing exception can take far longer than catching it in constraint review would have.
Common Mistake
The Trap: marking a path false path based on how it behaves in one specific test or simulation scenario, rather than confirming it never toggles in any real operating condition.
- A designer observes the path stays quiet in a handful of simulated test cases and assumes that means it is functionally never active.
- A different, untested operating mode later does exercise that exact path, and its real, never-verified delay now causes a genuine setup or hold failure that no report ever flagged.
Follow-up Question & Model Response
What review step would have caught this kind of false-path mistake before tapeout? Candidate Model Response: A constraint review that checks every set_false_path (SDC) statement against a written, specific reason — not just "this looked safe" — and, ideally, cross-checks it against functional simulation or formal analysis that confirms the path truly is never active. Some flows also run formal false-path verification tools specifically to prove or disprove that a path marked false can genuinely never propagate a changing value, which catches exactly this class of error before the constraint ships.
Practical Example
A path from a rarely-used error-injection register to the ALU is marked false because it stayed quiet in the regression suite. A field-return failure is eventually traced to that exact path toggling during a diagnostic routine nobody had simulated, with a real delay that violates setup by 400ps — a number no report had ever shown.
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.
Continue practising