False Paths

Timing constraints — clocks, generated clocks, I/O delays, exceptions, OCV and MCMM setup

False Paths

The timing tool is literal. It checks every path the wires allow, whether or not that path ever matters in real operation. Some paths exist in the netlist but are never functionally active. Checking them wastes effort and, worse, can block the tool from fixing real problems because it is busy chasing fake ones. A false path is a path you tell the tool to ignore entirely. A path is a route signals can take from a start point to an end point. A netlist is the connected list of gates and wires. The SDC constraint format marks false paths with set_false_path . Once marked, the tool removes that path from both setup and hold checking. This chapter explains when a path is truly false, how to mark it, and the real danger of being too aggressive. The most common cases are mutually exclusive logic, asynchronous clock crossings, and configuration signals that change rarely. Each is a path that is physically present but functionally dead during normal timing. It helps to remember why false paths exist at all. The synthesis tool builds gates and wires from your description. It does not understand the intent behind those gates. It cannot read your mind and know that two modes never run together, or that a register is only loaded once at boot. So it must assume the worst: every wire could carry timing-critical data every cycle. A false path is how you hand back the missing intent. You are restoring knowledge that the netlist alone cannot express.

Paths That Exist But Never Run

A false path is not a slow path or a long path. It is a path that the design never exercises in a timingcritical way. The wires are there; the data simply never flows along that route in a way that needs to meet the clock. The distinction is about function, not about speed or distance. A classic example is a multiplexer. A multiplexer, or mux, picks one of several inputs based on a select signal. If a particular combination of select values can never occur, the path through that combination is false. The tool, not knowing the functional restriction, would still time it. You must tell it to stop. Another example is a test-only path. Some logic exists only for manufacturing test and is never active in normal mode. During functional timing, those paths are false. They will be timed separately in a test mode, which is a different scenario. A subtle point: a path that is false in one mode is often very real in another. The same scan wire that is dead during functional operation carries the test pattern during scan. This is why false paths are tied to a mode, not declared once for all time. When you change modes, you change the false-path list. Treating a false path as a permanent global truth is a common source of confusion and bugs. It also helps to contrast a false path with a slow path. A slow path is one that struggles to meet the clock; the fix is to make it faster or give it more time. A false path is not slow at all in the timing sense; it simply does not need checking. Mixing the two ideas leads people to mark genuinely slow, active paths as false just to clear a report, which is exactly the abuse this chapter warns against.

set_false_path  removes a path from analysis. You can scope it broadly or narrowly. The narrower

the scope, the safer, because you only disable what you truly mean to. You target it with -from , -to , and -through . -from names a start point, -to names an end point, and -through forces the path to pass through a specific point. Using -from and -to together pins down a precise path. Using only -from disables everything starting there, which is broad and risky.

When a chip has modes that can never be active at the same time, the paths belonging to different modes do not interact. Suppose a block can run in mode A or mode B but never both, selected by a single bit. A path that would only matter if both modes were on at once is false. You mark these paths false so the tool does not pad timing for an impossible combination. This frees the tool to spend its effort on paths that really run. It also stops the tool from reporting violations on combinations the silicon will never see.

Two clocks are asynchronous when they have no fixed timing relationship, for example a 100 MHz clock and a 73 MHz clock from separate oscillators. The phase between their edges drifts constantly. There is no meaningful setup or hold check across them, because the receiving edge could be anywhere relative to the launching edge. Such crossings are handled by special synchronizer circuits, not by normal timing. So the data path across the boundary is treated as false for ordinary analysis. The synchronizer itself is checked, but the wide combinational path is not.

A cleaner alternative for whole-clock-group relationships is set_clock_groups -asynchronous , which disables timing between entire groups of clocks at once. But set_false_path on the crossing also works for targeted cases. The choice between the two is mostly about scope and maintenance. If two whole domains are unrelated, set_clock_groups states that fact once and stays correct even as you add new logic that crosses between them. A pile of individual set_false_path lines on specific pins can go stale: add a new crossing register and you must remember to add another false-path line, or it gets checked against a meaningless relationship and reports noise. For broad domain relationships, prefer the clock-group form; reserve targeted false paths for the few crossings that the group statement does not naturally cover.

A false path is a promise: you are telling the tool this route never matters. If that promise is wrong, the tool stops checking a path that actually does run, and a real violation hides silently. This is the most common and most dangerous false-path mistake. The risk grows with scope. A set_false_path -from someClock with no -to can disable thousands of legitimate paths in one line. A single careless -through on a shared node can mask whole regions of logic. Each broad statement should be justified and reviewed. Consider a worked impact. Suppose a block has 4,200 timing paths. A loose set_false_path -from clk_a accidentally covers 1,150 of them, of which 60 were real, active paths with negative slack. Those 60 violations now vanish from reports. The chip taps out looking clean and fails in the lab.

# Worked over-broad example
Total paths in block        = 4,200
Paths disabled by broad rule = 1,150
Of those, truly false        = 1,090
Of those, actually active     =    60  <- now hidden, may fail in silicon

There is also an ordering and precedence point worth knowing. A false path is the strongest exception. If a path is both covered by a multicycle relaxation and by a false path, the false path wins and the path simply vanishes from analysis. So a stray broad false path can quietly override more careful exceptions you set elsewhere. This makes review even more important: one loose line can undo a page of precise constraints. Good practice: prefer narrow -from / -to pairs, document why each false path is false, and audit the false-path list before sign-off. A report of disabled paths helps catch over-reach.

functionally active in a timing-critical way. It is not a slow path; it is a path the design never exercises against the clock. You mark it with set_false_path so the tool removes it from both setup and hold checks.

that can never occur), asynchronous clock crossings (two clocks like 100 MHz and 73 MHz with no fixed phase), and static configuration bits or test-only logic that are inactive during normal functional operation.

starts at that point, which can be thousands of paths. -from with -to pins down one precise route. Narrow scope means you only disable what you intend, reducing the chance of hiding a real, active path.

fixed phase relationship, the capture edge can land anywhere relative to the launch edge, so a normal setup or hold check is meaningless. Synchronizer circuits handle the crossing, and the wide combinational path is excluded from ordinary timing.

active. What is the danger? Those 60 active paths are removed from checking. If any have negative slack, the violations disappear from reports. The design looks clean at sign-off but can fail in silicon, because real timing problems were hidden by an over-broad exception.

single-ended rules, document the reason each path is false, prefer set_clock_groups for whole-domain async relationships, and audit the disabled-path list before sign-off so no active path is silently excluded.

Key Takeaways

• A false path is physically present but never functionally active; set_false_path removes it from setup and hold checks.
• Common sources are mutually exclusive modes, asynchronous clock crossings, and static or test-only logic.
• Narrow -from/-to scoping is far safer than a single-ended rule that can disable thousands of paths.
• An over-broad false path is a silent killer: it can hide real violations and let a failing chip look clean.
• Always document and audit false paths before sign-off, and prefer set_clock_groups for whole- domain async relationships.