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.
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?
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?
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:
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.
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.
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:
Designing With IP User Guide:
Revision Control Design Example and Scripts:
Revision Control Tutorial User Guide (last updated 2016.3 wont be updated)