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 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 -constraintsThis 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 with 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 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 in 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 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).
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 your 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 your 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.