False Paths - False Paths - 2026.1 English - UG903

Vivado Design Suite User Guide: Using Constraints (UG903)
Document ID
UG903
Release Date
2026-07-01
Version
2026.1 English

A false path is a path that topologically exists in the design but is either not functional or does not need to be timed. As a result, false paths are ignored during timing analysis.

Video: For training on advanced timing exceptions, including false paths, refer to Vivado Design Suite QuickTake Video: Advanced Timing Exceptions - False Path, Min-Max Delay and Set_Case_Analysis.

Examples of false paths include the following:

  • Clock domain crossings where double synchronizer logic is present
  • Registers written a single time at power-up
  • Reset or test logic
  • Paths between the write and asynchronous read clocks of an asynchronous distributed RAM, when applicable

The following figure shows an example of a non-functional path. Because both multiplexers are driven by the same select signal, the path from Q to D does not exist and is considered a false path.

Figure 1. Non-Functional Path Example

Tip: Use a multicycle constraint instead of a false path when the intent is to relax timing on a synchronous path that still requires timing, verification, and optimization.

Reasons to remove false paths from the timing analysis include the following:

Decrease Runtime
When false paths are removed, the tool does not spend time analyzing or optimizing non-functional paths. Leaving these paths visible to the timing and optimization engines can lead to significant runtime penalties.
Enhance Quality of Results (QOR)
Removing false paths improves the quality of synthesis, placement, and optimization. The tool focuses on valid timing paths, improving synthesis, placement, and optimization quality.

If non‑functional paths have timing violations, the tool might attempt to fix them instead of optimizing real functional paths. This can unnecessarily increase design size, such as through logic cloning, and cause valid issues to be missed when non‑functional violations overshadow real ones.

The best results come from applying a realistic set of constraints.

False paths are defined in the tool using the XDC command set_false_path:

set_false_path [-setup] [-hold] [-from <node_list>] [-to <node_list>] \ 
     [-through <node_list>]

You can use additional options with this command to fine-tune the path specification. For full details on supported options, refer to the Vivado Design Suite Tcl Command Reference Guide (UG835).

  • The -from option node list must contain valid startpoints. A valid startpoint is a clock object, a clock pin of a sequential element, or an input/inout primary port. You can include multiple elements.
  • The -to option node list must contain valid endpoints. A valid endpoint is a clock object, an output/input primary port, or a sequential element data-input pin. You can include multiple elements.
  • The -through option node list must contain valid pins, ports, or nets. You can include multiple elements.
CAUTION:
Use the -through option carefully. When it is used without -from and -to, it removes any path going through its pins or ports from timing analysis. Risk occurs when constraints created for an IP or sub‑block are applied in a different context. Many paths can then be unexpectedly excluded.

The order of multiple -through options affects results.

Examples

  • The following two commands are not equivalent:
    set_false_path -through cell1/pin1 -through cell2/pin2 
set_false_path -through cell2/pin2 -through cell1/pin1
  • The following command removes timing paths from the reset port to all registers:
    set_false_path -from [get_port reset] -to [all_registers]
  • The following command disables timing paths between two asynchronous clock domains (clock CLKA to clock CLKB):
    set_false_path -from [get_clocks CLKA] -to [get_clocks CLKB]
    • This example disables paths from clock CLKA to clock CLKB. It does not disable paths from CLKB to CLKA.
  • The following command disables all paths between the two clock domains in both directions, using two separate set_false_path commands:
    set_false_path -from [get_clocks CLKA] -to [get_clocks CLKB] 
set_false_path -from [get_clocks CLKB] -to [get_clocks CLKA]
    Important: Although the two set_false_path commands achieve the intended result, when two or more clock domains are asynchronous and paths between those domains must be disabled in both directions, AMD recommends using the set_clock_groups command instead. Refer to the following codeblock.
    set_clock_groups -group CLKA -group CLKB

In the example shown in Figure 1, you can define the false path with the -through option instead of the -from or -to options.

Figure 2. Non-Functional Path Example

This ensures that all the paths going through the path shown above are selected without needing to find specific patterns for the startpoints and endpoints.
set_false_path -through [get_pins MUX1/a0] -through [get_pins MUX2/a1]
Note: The order of the -through option is important. In the previous example, the order ensures that the false path passes through pin MUX1/a0 first, then pin MUX2/a1.

Another common use case involves asynchronous dual-port distributed RAM. Write operations are synchronous to the RAM write clock, while read operations can be asynchronous if the design allows. In this case, it is safe to apply false paths between the write and read clock domains.

  • Define a false path from the write-side registers before the RAM to the read-side registers after the RAM:
    set_false_path -from [get_cells <write_registers>] -to [get_cells <read_registers>]

    Example from the Vivado Design Suite WAVEGen (HDL) project:

    set_false_path -from [get_cells -hier -filter {NAME =~
*gntv_or_sync_fifo.gl0.wr*reg[*]}] -to [get_cells -hier -filter {NAME=~
*gntv_or_sync_fifo.mem*gpr1.dout_i_reg[*]}]
  • Define a false path starting from the WE pin of the RAM:
    set_false_path -from [get_cells -hier -filter {REF_NAME =~ RAM* && IS_SEQUENTIAL && NAME =~ <PATTERN_FOR_DISTRIBUTED_RAMS>}]

    Example from the Vivado Design Suite WAVEGen (HDL) project:

    set_false_path -from [get_cells -hier -filter {REF_NAME =~ RAM* && IS_SEQUENTIAL && NAME =~ *char_fifo*}]

The following figure illustrates how the distributed RAM is driven in the WAVE (HDL) example project.

Figure 3. Distributed RAM Driven in the WAVE Example Project