AR# 69690

Vivado IP Flows - [Vivado 12-5470] The design checkpoint file '….dcp' was generated for an IP by an out of context synthesis run and should not directly be used as a source in a Vivado flow

Description

When I add a design checkpoint (DCP) file of an IP core to my project, or read it in with the read_checkpoint command, I get a message stating that it is not recommended.

The following messages can be received, depending on how the DCP is added.

[Vivado 12-5470] The design checkpoint file '.dcp' was generated for an IP by an out of context synthesis run and should not directly be used as a source in a Vivado flow. It is strongly recommended that that the original IP source file (.xci) be used.

[Vivado 12-5469] The design checkpoint file '.dcp' was generated for an IP by an out of context synthesis run and should not directly be used as a source in a Vivado flow. It is strongly recommended that that the original IP source file (.xci) be used.

CRITICAL WARNING: [Project 1-863] The design checkpoint file my_ip.dcp was generated for a block design or an IP or BD by an out of context synthesis run and should not directly be used as a source in a Vivado flow to refer to an IP source. As of 2017.1, the DCP from OOC runs will not contain XDC timing constraints because these are expected to be referred to by the IP .xci or .xcix file source. DCP files prior to 2017.1 will contain incorrect constraints because they were generated with default OOC clock period which will not likely match your top level clock constraints when used in the full design context.

I did not get this message in Vivado 2016.4 and earlier and have been using the same flow with earlier releases. 

In my company's basic flow, the IP cores are generated OOC and then the DCP is loaded into the design instead of the XCI file.

  • Has Xilinx changed the recommended use model for adding IP core files?
  • Why is using an XCI or XCIX file recommended over a DCP file for IP cores?
  • What, if anything has changed related to the generation of IP core output files when generated out of context (OOC)?
  • Does this also apply to user packaged IP?
  • Was DCP support for IP core DCP files completely removed?
  • Do the changes introduced in Vivado 2017.1 affect other, non-IP DCP files synthesized OOC?
  • What is the difference between reading in the XCI and DCP file? Don't they contain the same IP core design files?
  • Why were changes introduced in Vivado 2017.1?
  • Will DCP files created in Vivado 2016.4 and earlier continue to work as before?
  • Will Vivado 2017.1 and later versions be able to create IP core DCP files exactly identical to those created in Vivado 2016.4?
  • Do I need to change existing scripts and flows or is this something that should only be changed as I move to new projects and scripts?
  • If, for any reason, I need to modify the output files (for example, the pinout constraints) of a generated IP core, should I then add a generated DCP file or add the XCI/ XXCIX file?

Solution

Has Xilinx changed the recommended use model for adding IP core files?

In Vivado 2017.1 a check and subsequent message was added to the software in order to help emphasize the Xilinx recommendation that an XCI or XCIX file should be used as the source file for all Xilinx IP cores and that users should not replace these files with the generated out of context (OOC) checkpoint (DCP). This recommendation is not new. This has been the primary recommendation for many years however, we have changed or added messaging in Vivado to make the recommendation more clear.

Why is using an XCI or XCIX file recommended over a DCP file for IP cores?

  • The XCI file is an XML file that captures all the configuration settings for the IP core.
  • The XCI file points Vivado to all of the files generated for the IP core, including - the DCP, synthesis, constraints, memory initialization and simulation files.
  • The XCI file is how Vivado determines if the IP is fully generated or if there are any files missing.

What, if anything has changed related to the generation of IP core output files when generated out of context (OOC)?

The following changes have been implemented for Vivado 2017.1 related to this flow:

  • Customers who add a DCP file to their project, for Xilinx IP from our catalog, will see a critical warning telling them that this is not recommended.
    Note: The flow will continue to work as it has before, with a few limitations that existed prior to 2017.1.
  • We have also modified how IP OOC synthesis runs work.
    • In order to avoid redundant application of constraints, beginning in 2017.1, the OOC DCP will no longer contain any constraints. By removing the constraints from the DCP, we can ensure that there will be no duplicates.
    • If you follow our recommendations, and use the IP .xci file, the original constraints, will be re-applied to the IP.
    • A DCP for an IP core cannot and should not be used standalone unless constraints are manually re-applied. If a user generates an IP core in Vivado 2017.1 or later and takes the DCP out of the OOC synth directory and uses it directly, it will not contain constraints.

Was DCP support for IP core DCP files completely removed?

Many customers preferred a generation model that was closer to ISE core generator, where they had a single file that was produced, so they have been taking the DCP out of the generation directories and putting that in their Vivado projects as a source file instead of using the .xci. 

Although not recommended, Xilinx tried to support this model. However, due to technical challenges that could not be easily addressed with many IP, we are backing away from trying to support this flow and trying to more strongly guide our customers to our recommended flows. 

This flow is not tested or supported by Xilinx.


Does this also apply to user packaged IP?

The recommendation to use an XCI or XCIX file as the source for an IP core applies to IP from Xilinx IP Catalog and customer packaged IP. 

A user IP is expected and designed be used in the same manner as a Xilinx IP and will be treated the same by Vivado.

An IP provider can verify that they are not affected by this issues by assuring that the created IP has no constraints pertaining to propagated clocks and has no memory unit or COE files. 

However, if a user adds only the DCP of a user IP core as source, they will still get a critical warning.

Do the changes introduced in Vivado 2017.1 affect other, non-IP DCP files synthesized OOC?

If you have RTL in your project and have turned on OOC synthesis, or bottom up synthesis, this flow is unaffected and will still work as it has in the past. No Critical Warning message will be issued in this case.
These changes only apply to IP from the Xilinx IP catalog and customer packaged IP.

What is the difference between reading in the XCI and DCP file? Don't they contain the same IP core design files?

There is a fundamental difference between the reading of an IP (read_ip) and reading of a checkpoint (read_checkpoint) related to application of constraints.
  • IP: 1) Reads the xci file. 2) Reads the DCP pointed to by the XCI. 3) Applies the original IP core XDC constraints pointed to by the XCI file. (The XDC constraints embedded in the DCP are ignored)
  • read_checkpoint: 1) Reads in the DCP file. 2) Extracts the DCP to a temporary directory. 3) Reads the extracted EDIF netlist. 4) Applies XDC constraints file extracted from DCP. 5) Reads xdefs if they exist.

Why were changed introduce in Vivado 2017.1?

The key to understanding the root of this problem lies in knowing the difference between the original IP core XDC file and the XDC file embedded in the generated DCP and knowing what files are needed to correctly implement the IP core.

  • The generated DCP contains the constraints that were used for the OOC synthesis run. This was an out of context synthesis run which needed reasonable constraints in order to produce a reasonable netlist. However, those constraints have no knowledge of the external design.
  • The XCI file points to the original XDC constraints that will be applied when Vivado synthesis and implementation processes have access to the entire design.
    Having a knowledge of the external design allows the constraints to be set based on the design (not an artificial estimate or default value).
  • Vivado needs information embedded in the XCI to correctly do memory initialization
      • Update_mem does not work with a DCP as it needs hierarchy information to correctly apply memory contents
      • The MIG IP exhibits one of the most common initialization challenges as the embedded MicroBlaze IP, for calibration requires programming of calibration code
      • ELF and COE, memory initialization files are not embedded in the DCP
  • Simulation is ~100x slower when using a DCP file.
      The simulation time difference is due the difference between a structural netlist simulation and behavioral models that are shipped with IP (outside DCP)
  • You cannot recreate an IP core (or upgrade or make changes to it)
    • If you lose track of the XCI file of the IP core you have no knowledge of the of the settings or DCP content so the XCI will always need to be preserved in any case.
  • Xilinx never tests standalone DCP for our IP Catalog
      Customers can choose to ignore the Critical Warning and the flow will continue. However, they are essentially "off-roading" by doing this.

Will DCP files created in Vivado 2016.4 and earlier continue to work as before?

If the DCP was generated in Vivado 2016.4 or earlier, you should see the Critical Warning message but if you choose to continue, the DCP netlist will be read in and the OOC constraints stored in the DCP will be applied just as they were in Vivado 2016.4 and earlier.


Will Vivado 2017.1 and later be able to create IP core DCP files exactly identical to those created in Vivado 2016.4?

No, the DCP created for an IP core in Vivado 2017.1 and later will not include the OOC XDC file.

Do I need to change existing scripts and flows or is this something that should only be changed as I move to new projects and scripts?

Changing a script should be a one line change. For example: Replace "read_checkpoint my_ip_core.dcp" to "read_ip my_core.xci"

As outlined above, existing scripts might continue to work and only have an additional Critical Warning generated. 

If the script includes the generation of a new IP core in Vivado 2017.1 or later, the script will most likely either need to be updated to point to the XCI file as recommended, or additionally to add the IP core XDC constraints and any initialization files and scope them to the DCP instance.

If, for any reason, I need to modify the output files (for example, The pinout constraints) of a generated IP core, should I then add a generated DCP file or add the XCI/ XXCIX file?

Editing the generated files of an IP core should not be a common flow. However, there are some cases (generally related to editing the IP core constraints) where this might be needed. The XCI or XCIX file should still be used as the source in this situation. 

The work-around for modifying IP constraints is to disable them in the project and then write whatever they need to override at the top level as a user XDC.

You can select the IP core XDC, right mouse click and select disable. This will also issue the Tcl command to disable the file, which can be used in a scripted flow if needed. If a user modifies the output files of an IP core, they will need to generate the OOC DCP of the IP core.

After creating the DCP they should still use the IP core XCI file to correctly point to all the IP core files (Including the DCP).

Reference Documentation:

Quick Take Video on Revision Control:

https://www.xilinx.com/video/hardware/vivado-design-suite-revision-control.html


Designing With IP User Guide:

https://www.xilinx.com/cgi-bin/docs/rdoc?v=latest;d=ug896-vivado-ip.pdf

Revision Control Design Example and Scripts:

https://github.com/xilinx/revCtrl

Revision Control Tutorial User Guide (last updated 2016.3 wont be updated)

https://www.xilinx.com/support/documentation/sw_manuals/xilinx2016_3/ug1198-vivado-revision-control-tutorial.pdf

AR# 69690
Date 10/17/2017
Status Active
Type General Article
Tools