False Paths - 2021.2 English

A false path is a path that topologically exists in the design but either: (1) is not functional; or (2) does not need to be timed. Consequently, the false paths should be ignored during timing analysis.

Examples of false paths include:

• Clock domain crossings in which double synchronizer logic has been added
• Registers that might be written once at power up
• Reset or test logic
• Ignore 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 should be defined as a false path.

Figure 1. Non-Functional Path Example

Reasons to remove false paths from the timing analysis include:

Decrease Runtime

When false paths have been removed from the timing analysis, the tool does not need to time or optimize those non-functional paths. Having non-functional paths visible to the timing and optimization engines can result in a large runtime penalty.

Enhance Quality of Results (QOR)

Removing false paths can greatly enhance the Quality of Results (QOR). The quality of the synthesized, placed, and optimized design is greatly impacted by the timing issues that the tool tries to solve.

If some non-functional paths have timing violations, the tool might try to fix those paths instead of working on the real functional paths. Not only might the design unnecessarily increase in size (such as logic cloning), but the tool might skip fixing real issues because non-functional paths have larger violations that overshadow other real violations. The best results are always achieved with a realistic set of constraints.

False paths are defined inside the tool with the Xilinx Design Constraints (XDC) command set_false_path:

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

You can use the following additional options to the command to fine tune the path specification. For detailed information about all supported command line options, see the Vivado Design Suite Tcl Command Reference Guide (UG835).

• The list of nodes for the -from option should be a list of valid start-points. A valid startpoint is a clock object, a clock pin of a sequential element, or an input (or inout) primary port. Multiple elements can be provided.
• The list of nodes for the -to option should be a list of valid endpoints. A valid endpoint is a clock object, an output (or inout) primary port, or a sequential element input data pin. Multiple elements can be provided.
• The list of nodes for the -through option should be a list of valid pins, ports, or nets. Multiple elements can be provided.

The order of the -through option is important. See the following examples. For example, the following two commands are different:

set_false_path -through cell1/pin1 -through cell2/pin2 
set_false_path -through cell2/pin2 -through cell1/pin1

The following example removes the timing paths from the reset port to all the registers:

set_false_path -from [get_port reset] -to [all_registers]

The following example disables the timing paths between two asynchronous clock domains (for example, from clock CLKA to clock CLKB):

set_false_path -from [get_clocks CLKA] -to [get_clocks CLKB]

The previous example disables the paths from clock CLKA to clock CLKB. Paths from clock CLKB to clock CLKA are not disabled. Accordingly, disabling all the paths between the two clock domains in either direction requires two 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]

set_clock_groups -group CLKA -group CLKB

In the non-functional path example shown in Figure 1, the false path can be set using the -through option instead of using the -from or -to option. See Figure 2.

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]

Another common example is with asynchronous dual-ports distributed RAM. The write operations are synchronous to the clock RAM but the read operations can be asynchronous when permitted by the design. In this case, it is safe to false paths the timing paths between the write and the read clocks.

There are two ways to do this:

• Define a false path from the write registers before the RAM to the registers after the RAM receiving the read clock:

  set_false_path -from [get_cells <write_registers>] -to [get_cells <read_registers>]

  On the Vivado Design Suite example project WAVEGen (HDL):

  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 pin WE of the RAM

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

  On the Vivado Design Suite example project WAVEGen (HDL):

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

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

Figure 3. Distributed RAM Driven in the WAVE Example Project