Constraint File Processing Order - 2021.2 English

Vivado Design Suite User Guide : Designing with IP (UG896)

Document ID
UG896
Release Date
2021-11-03
Version
2021.2 English

By default, IP XDC constraints have the PROCESSING_ORDER value of EARLY, and user constraints are marked NORMAL. In this way, the constraints processed later can override constraints on the same object that are processed earlier.

The order in which IP XDC files could be processed are, as follows:

  • User XDC set to EARLY
  • IP XDC set to EARLY
  • User XDC set to NORMAL (default)
  • IP XDC set to LATE
  • User XDC set to LATE

Using this method, you can have an XDC file(s) processed before or after IP XDC(s).

See the following documents for more detail:

  • Vivado Design Suite User Guide: Creating and Packaging Custom IP (UG1118)
  • This link to the Vivado Design Suite User Guide: Using Constraints (UG903)

Vivado IP can generate multiple XDC constraints files. By default, IP constraints are processed before user constraints because of the following possibilities:

  • The IP might produce a clock that must be available to the end-user constraints.
  • If the IP delivers physical constraints, the end-user can override them if necessary.

The following is an example of the report_compile_order Tcl command to report constraint compile order:

report_compile_order -constraints

This command provides the processing order of constraints used for synthesis and implementation of user logic, and provides a breakdown of the constraints used for each IP synthesis run used for the generation of the IP DCP.

Some constraints that an IP delivers could have a dependency on a clock object that comes from either the end-user or another IP. These constraints are provided in a separate XDC file and are processed after the end-user constraints.

Typically, an IP delivers a core XDC file that can contain clock creation commands as well as commands without external clock dependencies. The constraint file name is <ip_name>.xdc, and is referred to as the core XDC file.

IP can also include another XDC file that contains clock-dependent commands.

Because the top-level clock can come from other constraints, or from other IP with a dependency, any constraints that need those clocks to be defined first should be placed in the <ip_name>_clocks.xdc. By default, the Vivado IDE processes the <ip_name>_clocks.xdc file after user constraints and other IP core XDC files.

Most IP deliver an OOC XDC file as well, (<ip_name>_OOC.xdc). This file contains default top-level definitions for input clocks to the IP. This file is only used in the DCP creation when using the recommended default flow (IP synthesized OOC to the top-level design). When the Vivado Design Suite synthesizes the IP OOC of the top-level design, clocks that are created by the end-user or other IP are not available; consequently, this file is necessary to provide the clock definitions for synthesizing the IP.

The <ip_name>_ooc.xdc is not needed during implementation of the user logic with the IP, because all the netlists are linked together before constraints are applied. At that point a user-created clock or an IP-created clock is available to any IP that requires a clock.

Some IP can deliver additional XDC files. This might be because they deliver constraints that are to be used only during synthesis or only during implementation. For a list of possible XDC files that an IP can deliver, see IP Files and Directory Structure.

Some IP support a the Vivado Board Flow as defined at this link to the Vivado Design Suite User Guide: System-Level Design Entry (UG895).

When you create a project that targets a platform board instead of a target part, that board is available during the IP customization letting you specify which connections on the board to use in connecting to the IP. This produces an <ip_name>_board.xdc file which contains PACKAGE_PIN, IOSTANDARD, and other physical constraints.

For more detailed information on XDC constraints, see this link to the Vivado Design Suite User Guide: Using Constraints (UG903).

After some constraints are processed for a project, those constraints can become project Properties. For more information regarding properties, see the Vivado Design Suite Properties Reference Guide (UG912).

Video: See the Vivado Design Suite QuickTake Video: IP Constraints Overview, for a demonstration of how the following constraints are used during IP flow.

The following subsections briefly describe some of the constraint files that the Vivado Design Suite creates when processing IP.

dont_touch.xdc Constraint

The Vivado tools use the dont_touch.xdc to set DONT_TOUCH properties on the IP top-level during synthesis of the IP. This prevents interface ports from being removed.

You can see this constraint file being processed in the synthesis log file, either for the IP when it is synthesized using OOC (the default flow), or in the global synthesis log file when synthesizing the IP with the end-user RTL.

in_context.xdc Constraint

By default, IP is treated as a black box during top-level synthesis because it is synthesized using OOC. During the creation of the IP DCP, an <ip_name>_in_context.xdc file is created and stored in the IP DCP file, under the following conditions:

  • The IP produces a clock which can be referenced on the IP boundary
  • The IP has an instance of any I/O buffers

If present, the <ip_name>_in_context.xdc file is processed before the end-user constraints when synthesizing the user logic. This file is not necessary during implementation because the IP are no longer a black box.

If clocks are created, they are placed on the boundary pins of the IP black box cell. The clock can be of the following types:

  • A primary clock on an input port of the IP (such as the Clocking Wizard IP).
  • A primary clock on an output port of the IP.
  • A generated clock on an output port of the IP with the master being an input clock (such as the Clocking Wizard IP).

A clock would be created on an input port of the IP only in the case that the IP contained an input buffer. The clocking wizard is configured so by default. This clock propagates to a top-level port during synthesis of the top level user logic.

If a user constraint must reference a clock produced by an IP, it should be done indirectly by referencing the pin of the IP where the clock is produced, such as in the get_clocks command:

get_clocks â€"of_objects [get_pins <IP_clock_pin>]

If I/O buffers are present, the IO_BUFFER_TYPE property is set to NONE for the interface pin with an I/O buffer. Setting this property prevents an additional I/O buffer from being inserted during top-level synthesis.