IP Constraints

Most Xilinx IP come with constraint fi les (.xdc). They can contain physical constraints such as setting IO standards or locations and timing constraints, such as false paths. These two types can be mixed in the same fi le. The constraints are written as if the IP were the top of the design. The constraints are automatically scoped to IP instance(s). It is strongly recommended that you do not modify the constraints delivered by an IP.

There are two sources of constraints used by IP. If you’re a user of IP from the available catalog, you need not worry about this distinction. However, this distinc- tion would be of importance, if you are creating an IP of your own:

• XDC fi les created during generation of the IP and contained in the IP directory or the Core Container

• Constraints created by Vivado automatically during the processing of the IP

IP Delivered

There are three general types of XDC fi les which IP deliver:

• OOC XDC : This fi le provides the target frequency for any clocks which drive the IP for use during out-of-context synthesis. The fi le is not used during global synthesis or global implementation. The target frequency of each clock is set either during the IP customization via the GUI or by setting a property on the IP after it has been created. This special XDC file is always processed before all other XDC fi les that an IP may deliver. The file has an extension of _ooc. xdc . Only one such fi leis delivered per IP.

• XDC fi les marked with a PROCESSING_ORDER of EARLY : The constraints con- tained either provide clock objects or do not have any dependence, such as a clock provided from outside the IP. These fi les are typically named <ip_name>.xdc .

• XDC fi les marked with a PROCESSING_ORDER of LATE . The constraints con- tained have a dependency on an external clock(s) being provided. The clock(s) would come from the top level during global synthesis and during global imple- mentation. During out-of-context synthesis and implementation, the _ooc.xdc provides the clock defi nition(s). These fi les have the extension of _clocks.xdc .

With the exception of the _ooc.xdc , not all IP deliver constraint fi les. It depends on the specifi c IP and its requirements. Typically larger and more complex IP deliver all three. Some IP may further break their constraints up, for example, putting the implementation specifi c constraints in one file and timing constraints in another file.

Vivado Delivered

During the processing of the IP, the Vivado tool creates additional constraints as follows:

• The <ip_name>_ in_context.xdc fi le: This fi le is created for IP when using the default out-of-context synthesis fl ow, where IP is synthesized stand- alone. The _in_context.xdc is used during global synthesis, when the IP is a black box. After completing synthesis of the IP stand-alone, the IP is scanned to determine:

– Does the IP output a clock object? Some IP produce clocks which could be used by other IP or by the user during global synthesis and implementation. The clocking wizard is an example of one such IP. The _in_context.xdc pro- vides these clock defi nitions, which consist of create_clock command(s) which will put the clock object(s) on the boundary pin(s) of the IP, which will be a black box during global synthesis. This fi le is stored within the IP DCP fi le.

– Does the IP contain clock or IO buffers? In this case a property is set on the respective boundary pin. With this property set on the IP black box, it will pre- vent global synthesis from unnecessarily inserting an additional one.

• The dont_touch.xdc fi le: Depending on the version of Vivado, this fi le might be seen being read in the global synthesis log (if the IP is synthesized glob- ally) or in the IP out-of-context synthesis log (default). This fi le places a DONT_ TOUCH on the boundary of the IP. This serves two purposes, to prevent the IP boundary pins from being optimized away and to prevent the IP hierarchy from being altered. This guarantees any constraints an IP delivers do not get invalidated. The DONT_TOUCH is removed at the end of synthesis. This allows constant propagation and cross boundary optimizations to be performed during imple mentation after the IP constraints have been applied. In later versions of Vivado, this may be done without the creation of the dont_touch.xdc fi le though messaging will be produced.

Processing Order

Constraints are processed in a specifi c order. For user XDC fi les, they are processed either in the order they are read using the read_xdc command in a script or in the order they are placed in the Vivado project (the compile order). IP are automatically processed along with the user fi les. Synthesis option decides which IP XDC fi les will be used: out-of-context (default) or global with the user HDL. The processing order is important, if your design has constraints that impact an IP or your design’s constraints depend on the constraints of the IP. For such dependence, it is important that the dependent constraints are read later. Vivado provides you with an ability to process your XDC fi les before or after any IP delivered XDC by setting the PROCESSING_ORDER , though it is not common for users to change the PROCESSING_ORDER property for their XDC fi les. IP use this property to cause their various XDC fi les to come either before or after the user XDC fi les.

The order of XDC fi les during synthesis of the top level where the IP a black box, since it was synthesized out-of-context, is (default):

1. Any <ip_name>_in_context.xdc fi les

2. User fi les in the compile order set

The order of XDC fi les when the IP is set to use global synthesis is:

1. User fi les with the PROCESSING_ORDER property set to EARLY

2. IP fi les with the PROCESSING_ORDER property set to EARLY

3. User fi les with the PROCESSING_ORDER property set to NORMAL (default order for fi les is based upon the compile order)

4. IP fi les with the PROCESSING_ORDER set to LATE

5. User fi les with the PROCESSING_ORDER set to LATE

This is the same order that is used during implementation.

To see the order in which the XDC as well as the HDL fi les are processed, use the report_compile_order command. To see just the constraints, use the -constraints option. The output is organized into sections:

• HDL used during global synthesis

• HDL used during out-of-context IP synthesis

• Constraints used during global synthesis

• Constraints used during implementation

• Constraints used during IP out-of-context synthesis

• Constraints used during IP out-of-context implementation (results for this are for analysis only; to fully place and route logic for use, see the hierarchical design document)

TABLE OF CONTENTS

IP Delivered

Vivado Delivered

Processing Order