Timing Path Summary - 2025.2 English - UG906

The Timing Path Summary header includes the following information:

Slack

A positive slack indicates that the path meets the path requirement, which is derived from the timing constraints. The slack equation depends on the analysis type.

• Max delay analysis (setup/recovery) is as follows:

  slack = data required time - data arrival time

• Min delay analysis (hold/removal) is as follows:

  slack = data arrival time - data required time

Vivado calculates and reports the data required and arrival times in other sections of the timing path report.

Source

This field shows the path startpoint and the source clock that launches the data. The startpoint is usually the clock pin of a sequential cell or an input port. When applicable, the second line shows the primitive type and the edge sensitivity of the clock pin. It also includes the clock name and the clock edge definition (waveform and period).

Destination

This field shows the path endpoint and the destination clock that captures the data. The endpoint is usually the input data pin of a sequential cell or an output port. When applicable, the second line shows the primitive type and the edge sensitivity of the clock pin. It also includes the clock name and the clock edge definition (waveform and period).

Path Group

This field shows the timing group that includes the path endpoint. The group usually comes from the destination clock. For asynchronous timing checks such as recovery and removal, the path appears in the **async_default** timing group. User-defined groups can also appear and are useful for reporting purposes.

Path Type

This field shows the type of analysis used for the path.

• Max: Uses maximum delay values to calculate the data path delay for setup and recovery analysis.
• Min: Uses minimum delay values to calculate the data path delay for hold and removal analysis.

The field also shows the timing corner used in the report: Slow or Fast.

Requirement

This field shows the timing path requirement. When the startpoint and endpoint use the same clock or clocks with no phase shift, the requirement is typically the following:

• One clock period for setup and recovery analysis
• 0 ns for hold and removal analysis

For paths between two different clocks, the requirement equals the smallest positive difference between any source and destination clock edges. Timing exception constraints such as multicycle path, max delay, or min delay override this value.

For more information on how Vivado derives the timing path requirement from constraints, see Timing Paths.

Data Path Delay

This field shows the accumulated delay through the logic section of the path. It does not include clock delay unless the clock is used as data. The delay type matches the analysis shown in the Path Type field.

Logic Levels

This field shows the number of each type of primitive in the data path. It excludes the startpoint and endpoint cells.

Clock Path Skew

The insertion delay difference between the launch edge of the source clock and the capture edge of the destination clock, plus clock pessimism correction (if any).

Destination Clock Delay (DCD)

This field shows the accumulated delay from the destination clock source point to the endpoint of the path.

• For max delay analysis (setup/recovery), Vivado uses the minimum cell and net delay values
• For min delay analysis (hold/removal), Vivado uses the maximum delay values

Source Clock Delay (SCD)

This field shows the accumulated delay from the clock source point to the startpoint of the path.

• For max delay analysis (setup/recovery), Vivado uses the maximum cell and net delay values
• For min delay analysis (hold/removal), Vivado uses the minimum delay values

Clock Pessimism Removal (CPR)

The extra skew introduced when source and destination clocks use different delay types on shared circuitry. Vivado removes this pessimism to eliminate skew on the shared path. In routed designs, the last common clock tree node usually lies in routing resources and does not appear in path details.

Clock Uncertainty

This field shows the total possible time variation between any pair of clock edges. The value includes:

• Computed clock jitter (system and discrete)
• Phase error from hardware primitives
• User-defined clock uncertainty from the set_clock_uncertainty constraint

Vivado adds the user-defined clock uncertainty to the computed uncertainty from the timing engine.

Total System Jitter (TSJ)

This field shows the combined system jitter applied to both the source and destination clocks. To modify system jitter globally, use the set_system_jitter constraint. Virtual clocks are ideal and do not include any system jitter.

Total Input Jitter (TIJ)

This field shows the combined input jitter for the source and destination clocks. Use the set_input_jitter constraint to define input jitter for each primary clock. The Vivado IDE timing engine calculates the input jitter for generated clocks based on the master clock's jitter and the clocking resources it traverses. By default, virtual clocks are ideal and do not include jitter.

For more details, see the Clock Latency Jitter and Uncertainty section in the Vivado Design Suite User Guide: Using Constraints (UG903).

Discrete Jitter (DJ)

This field shows the jitter introduced by hardware primitives such as MMCM or PLL. The Vivado IDE timing engine computes this value based on how these components are configured.

Phase Error (PE)

This field shows the amount of phase variation between two clock signals introduced by hardware primitives such as MMCM or PLL. The Vivado IDE timing engine automatically calculates this value and adds it to the overall clock uncertainty.

User Uncertainty (UU)

This field shows the additional uncertainty defined by the set_clock_uncertainty constraint. For usage details, see the Vivado Design Suite Tcl Command Reference Guide (UG835).

Additional lines can appear in the Timing Path Summary depending on the timing constraints, the reported path, and the target device:

Inter-SLR Compensation

Appears only for AMD SSI devices and shows the margin required to safely report timing paths that cross super logic region (SLR) boundaries. Its presence depends on timing constraints, the reported path, and the target device.

Input Delay

This field shows the input delay value set by the set_input_delay constraint on the input port. It does not appear for paths that do not start from an input port.

Output Delay

This field shows the output delay value set by the set_output_delay constraint on the output port. It does not appear for paths that do not end at an output port.

Timing Exception

This field shows the timing exception that applies to the path. Only the exception with the highest precedence appears, as it determines the timing path requirement.

For details on timing exceptions and how precedence is applied, see Report Exceptions.