Path Segmentation - 2023.1 English

Vivado Design Suite User Guide: Using Constraints (UG903)

Document ID
Release Date
2023.1 English

Unlike other XDC constraints, the set_max_delay command and the set_min_delay command can accept, in the case of -from and -to options, a list of invalid startpoints or endpoints respectively.

When an invalid startpoint is specified, the timing engine stops the propagation of the timing going through the node so that the node becomes a valid startpoint.

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 the propagation through the arc C->Q to make the 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 the propagation of the timing to create a valid startpoint is called path segmentation. Path segmentation affects both max and min delay analysis. Path segmentation also affects any timing constraint going through those nodes (FD1/C and FD1/Q).

Note: Because of Path Segmentation, no clock insertion delay is used for the launch clock for paths starting from FD1/Q. This can potentially result in large skew because the clock skew of the endpoints is still taken into account. See the following figure.
Figure 3. Path Segmentation Result in Large Skew

Path segmentation can have unexpected consequences. Avoid path segmentation altogether, or use it very carefully.

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

Because of the risks, a critical warning is issued when a path segmentation occurs.

If you targeted the output FD1/Q as the startpoint in order to avoid taking the clock skew into account, AMD recommends using the -datapath_only option. Instead, see the following example:

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

In the same way, when an invalid endpoint is specified, the timing engine stops the propagation after the node so that the node becomes a valid endpoint.

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

set_max_delay 5 -from [get_pins LUTA/O]

This is shown in the following figure.

Figure 4. Path Segmentation When an Invalid Endpoint is Specified

To make LUTA/O a valid endpoint, the timing stops propagating after LUTA/O. As a result, all timing paths going through LUTA/O are impacted for both setup and hold. For the path starting on REGA/C and ending on LUTA/O, only the insertion delay of the launch clock is taken into account. This can result in very large skew.

Because path segmentation stops the propagation through the timing arcs, it can have unexpected consequences. All the timing paths going through those nodes are impacted.

In the following example, a max delay has been 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* and LUTA/O are broken. Even though the set_max_delay constraint was set between LUTA/O and REGB/D only, other paths such as the path between REGA/C and REGC/D are also broken.