早在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文件。