Report Per Constraint Section - 2022.1 English

Vivado Design Suite User Guide: Design Analysis and Closure Techniques (UG906)

Document ID
UG906
Release Date
2022-05-04
Version
2022.1 English

The Report Per Constraint section provides more details for each of the set_bus_skew constraints. Each reported constraint includes two parts:

  1. Detailed summary of the paths covered by the constraint.
  2. Detailed timing paths for the paths reported in the Per Constraint summary.

The detailed summary table provides the following information:

From Clock
Startpoints clock domain.
To Clock
Endpoints clock domain.
Endpoint Pin
Endpoint pin involved in the reported path.
Reference Pin
Reference pin used to compute the skew. Each row of this table refers to the reference pin which results in the largest skew for that endpoint path.
Corner
Fast/slow corner used to compute the worst skew to this endpoint.
Actual
Computed skew. The skew is the difference between the relative delay for Endpoint Pin minus the relative delay for Reference Pin and minus the relative CRPR.
Slack
The difference between the actual path skew and the requirement.
Note: Both the -from and -to options must be specified when defining a bus skew constraint.

By default, only the endpoint with the worst bus skew is reported. To report multiple endpoints, the command line options -max_paths and -nworst can be used. They work similarly as for the report_timing command. For example, the combination of -nworst 1 -max_path 16 reports, for each constraint, up to 16 endpoints with a single path per endpoint.

Figure 1. Bus Skew Report Per Constraint

The detailed timing paths section provides a detailed timing path for each of the pin pairs reported in the Per Constraint summary table. The number of detailed paths that are reported is the same as the number of endpoints reported in the summary table and can be controlled with -max_paths/-nworst command line options.

The format for the detailed bus skew timing path is similar to a traditional timing path. Clock uncertainty, however, is not included because the bus skew analysis is done on the same clock edge. Instead, the worst of the clock uncertainty from the endpoint or reference paths is reported in the bus skew header. The launch time of the destination clock is always zero. For each slack, a timing path to the endpoint and a timing path to the reference pin are printed. When the clock or the datapath cross multiple SLRs, some inter-SLR compensation is applied during the slack computation to prevent unnecessary pessimism. Such compensation is then reported in the bus skew header.

The following detailed path was reported using the command line option -path_type short to collapse the clock network details. The path to the endpoint pin precedes the path to the reference pin. The path header summarizes the information from the two detailed paths, plus the requirement and the relative CRPR:

Figure 2. Detailed Path Example