早在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文件和.dcp文件工作流程的差异,这有助于让我们理解使用独立的dcp格式的文件:
当读取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文件。
全部0条评论
快来发表一下你的评论吧 !