使用“独立的”.dcp文件代替.xci文件

早在2017年1月初，我们宣布Xilinx IP目录中的所有IP使用xci和xcix格式的文件，这已经不是什么新鲜事了，其实我们之前一直在说这是我们多年来的主要建议，这其中包括很多重要的原因，xci文件是一个xml格式的文件，它能够搜集ip所有的配置信息，更重要的是包括Vivado指向的ip所生成的大量文件，比如上下文综合、约束和模拟文件等。根据xci文件Vivado可以确定IP是否已经“完全生成”或者缺少哪些文件。

许多客户都更喜欢与ISE core生成器接近的生成模型，因为这样会生成单个文件，将.dcp文件从生成目录拷贝到Vivado工程目录，作为源文件代替之前使用的.xci文件，我们尝试支持这种模式，但是这种方法存在很多问题我们还无法解决，因此从某种意义上讲，我们正远离这一点，并试图引导我们的客户使用我们所推荐的流程。

为此从2017年1月开始，如果用户向工程中添加.dcp文件，尤其是涉及Xilinx IP目录中的模块将会看到一个严重的警告，提示他们不推荐这样做，这个流程将继续像以前一样持续，并且保持2017年1月之前就存在的一些限制条件。

我们还修改了IP OOC综合的工作方式，为了避免约束多余的应用，在2017年1月初，OOC dcp文件将不再包含任何约束信息，如果你遵循我们的建议使用IP xci文件，那么之前的约束信息将能够重新应用于IP，通过将约束信息从dcp文件中移除，我们能够确保不会有重复的信息。

如果客户在工程中使用了RTL代码，并且开启了OOC综合或者使用“自下而上的综合”，那么这个流程不会受到影响，并且仍然会像之前那样正常工作，这些更改仅适用于Xilinx IP目录内的IP和用户自定义封装的IP模块。

当读取xci文件时，Vivado会读取生成的dcp文件，跳过嵌入的约束信息，采用的是原始IP的约束文件，这是我们推荐的流程，可以确保应用的约束信息符合IP设计者的想法。

另一方面，当单独读取dcp文件时，Vivado并不会涉及原始的IP约束文件，DCP文件会被解压到一个临时目录，读取网表信息并且应用DCP文件中嵌入的约束信息，理解这个问题的根源在于原始ip xdc文件和嵌入到dcp中的xdc文件之间的差异，生成的DCP文件包括用于OOC综合的约束信息，这是一个“关乎上下文的”综合过程，需要合理的约束才能生成正确的网表，但是这些约束信息并不关心外部的设计。

还有一些问题用户可能还没有意识到，.xci文件指向的IP模块还需要其他一些必需的文件，dcp文件中没有嵌入关键的内存初始化信息，比如elf和coe文件等，当我们使用dcp文件时，工具无法访问层次信息，这有助于我们确定是否存在控制MIG校准的嵌入式MicroBlaze处理器，所以DDR的MIG流程使用独立的dcps文件无法正确工作时，我们需要引入xci文件。

除此之外，使用.dcp进行的模拟操作发生在结构化后综合的网表文件中，这与行为描述的RTL文件(由.xci文件指向和传递)相比速度会非常的慢，大约会慢100倍。

其他通常会发生的问题是丢失.xci文件——它包含有IP的配置信息，IP不能通过dcp文件重新生成——因此用户必须保持对.xci文件的跟踪，在早期IP的支持中，Vivado会大量的文件，我们非常努力的减少这些文件的数量，现在的文件数量相比2014年减少了2/3，因此用户检查所有生成文件的版本控制会比之前容易的多，至少用户可以使用.xci文件来重新生成IP或者检查所有生成的文件从而减少编译时间。

这些问题可以通过使用.xci或者.xcix文件来避免，这是我们测试和支持的—我们没有测试独立的dcps文件。

现在的情况比之前少了很多，与几年前相比，用户看到的文件数量和大小都减少了很多，这是对使用.xci和.dcp脚本进行的单行更改，用户仍然可以完全控制使用.xci的生成过程，因此不应该有太多的阻力就可以转移到这个流程。

.xcix文件会提供一个文件，可以用来进行版本控制，它保留了我们建议流程的优势。

我们还想说的是我们的IP用户设计指南中关于.xci文件的使用建议已经非常清晰了，很长一段时间使用dcp文件都会有局限性，这对用户来说应该并不奇怪，我们理解有时用户无法在短时间内跟上用户指南中大量的建议，这也是我们引入警告信息的原因，并且能够提示用户使用.xci文件的重要性。

遵循Xilinx的建议非常的重要，可以充分利用我们最新技术带来的便利，dcp文件的设计目的并不是为了完全符合IP复杂的设计流程，它实际上是网表/约束/路由设计信息的数据库，为了能够正确使用IP，你应该使用专为此而设计的.xci或.xcix文件。