Path Segmentation - Path Segmentation - 2026.1 English - UG903

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

Unlike other XDC constraints, the set_max_delay and set_min_delay commands can accept a list of invalid startpoints or endpoints when using the -from and -to options.

When an invalid startpoint is specified, the timing engine stops timing propagation through the node, treating it as a valid startpoint. This allows greater flexibility in defining timing paths.

In the following example, the only valid startpoint is FD1/C:

set_max_delay 5 -from [get_pins FD1/C]
Figure 1. Original Timing Arc

If the constraint is applied to FD1/Q, the timing engine stops propagation through the C->Q arc, making pin Q a valid startpoint:

set_max_delay 5 -from [get_pins FD1/Q]
Figure 2. Timing Not Propagating after Path Segmentation

The process of stopping timing propagation to create a valid startpoint is called path segmentation. Path segmentation applies to max and min delay analysis and affects any timing constraint passing through segmented nodes, such as FD1/C and FD1/Q.

Note: Because of path segmentation, no clock insertion delay is used for the launch clock on paths starting from FD1/Q. This can lead to large skew, as the clock skew at the endpoints is still included in the analysis.
Figure 3. Path Segmentation Result in Large Skew

CAUTION:
Path segmentation can have unexpected consequences. Avoid path segmentation completely, or use it very carefully.

After path segmentation, there is no default hold requirement on the path. Assuming the -datapath_only option is not been specified, use the set_min_delay command to apply a hold requirement if needed.

Because of the risks associated with path segmentation, the tool issues a critical warning when it occurs.

If you targeted the output FD1/Q as the startpoint to avoid including clock skew, AMD recommends using the -datapath_only option instead. Use the clock pin of the sequential element as the startpoint and apply the constraint as follows:

set_max_delay 5 -from [get_pins FD1/C] -datapath_only

Similarly, when an invalid endpoint is specified, the timing engine stops propagation after that node, treating it as a valid endpoint.

In the following example, the max delay is applied to LUTA/O, which is not a valid endpoint:

set_max_delay 5 -from [get_pins LUTA/O]

This behavior is illustrated in the following figure.

Figure 4. Path Segmentation When an Invalid Endpoint is Specified

To make LUTA/O a valid endpoint, the timing engine stops propagation after LUTA/O. As a result, all timing paths passing through LUTA/O are affected for both setup and hold analysis. For a path that starts at REGA/C and ends at LUTA/O, only the insertion delay of the launch clock is considered. This can lead to very large skew.

Because path segmentation stops propagation through timing arcs, it can produce unexpected consequences. All timing paths that go through the segmented nodes are impacted.

In the following example, a max delay is set between LUTA/O and REGB/D:

set_max_delay 6 -from [get_pins LUTA/O] -to [get_pins REGB/D]

This is shown in the following figure.

Figure 5. Path Segmentation Breaking Multiple Paths

Because the pin LUTA/O is not a valid startpoint, a path segmentation occurs, and the timing arcs from LUTA/I* to LUTA/O are broken. Even though the set_max_delay constraint was applied only between LUTA/O and REGB/D, other paths such as REGA/C to REGC/D, are still broken.