⑴ vivado 錯誤怎麼改
Vivado Logic Analyzer的使用
chipscope中，通常有兩種方法設置需要捕獲的信號。
1.添加cdc文件，然後在網表中尋找並添加信號
2.添加ICON、ILA和VIO的IP Core
第一種方法，代碼的修改量小，適當的保留設計的層級和網線名，圖形化界面便於找到
需要捕獲的信號。
第二種方法，對代碼的改動量大一些，同時需要熟悉相關IP的設置，優點是，可以控制
ICON,並調用VIO。
與之類似，Vivado也有著兩種方法進行設置。
1.在綜合後的網表中尋找相關信號，右鍵點開菜單，然後設置mark debug
2.添加ILA，VIO的IP Core
第一種方法與chipscope的第一種方法極為類似：
1.都需要綜合後才能設置；
2.都需要保留一定的設計層級或者網線名來便於尋找信號；
3.並非所有信號都可以被捕獲，不能捕獲的信號，chipscope中是顯示為灰色，vivado
中是沒有mark debug的選項在右鍵菜單中；
第二種方法就更為類似了，vivado可以兼容ISE的IP，所以可以直接調用chipscope的相
關IP，調試時也只是用Chipscope，另外可以使用Vivado自己的ILA IP，來進行設計，
但最大的問題是Vivado不提供ICON的IP以供選擇，進一步埋沒了ICON的地位。
另外，早起的Vivado IP Catalog提供Chipscope的ICON、ILA和VIO IP Core可以選擇，目前已經取消了這些IP，只支持Vivado自己的ILA/VIO IP Core。
這里提供一個非常簡單的設計代碼，用於Vivado Logic Analyzer的研究。
`timescale 1ns / 1ps
mole Nexy_4 (
input I_CLK,
output [3:0] O_ST_COUNTER,
output O_TIMECOUNTER_OUTPUT
);
wire CLK_100;
clk_wiz_0 CLK_UNIT
(
.clk_in1 (I_CLK),
.clk_out1 (CLK_100),
.locked ()
);
reg [7:0] startup_counter = 'b0;
always @ (posedge CLK_100)begin
if(startup_counter == 8'b11111111)begin
startup_counter <= 8'b00000011;
end else begin
startup_counter <= startup_counter + 8'b1;
end
end
assign O_ST_COUNTER = startup_counter[7:4];
wire [47:0] TimeCounter_Result_wire ;
reg [47:0] TimeCounter_Result_reg = 'b0 ;
reg TimeCounter_Output ;
always @ (posedge CLK_100)begin
TimeCounter_Result_reg <= TimeCounter_Result_wire;
end
TimeCounter TimeCounter_Unit (
.CLK ( CLK_100 ), // input wire CLK
.A ( 2'b01 ), // input wire [1 : 0] A
.C ( TimeCounter_Result_reg ), // input wire [47 : 0] C
.P ( TimeCounter_Result_wire ) // output wire [47 : 0] P
);
always @ ( posedge CLK_100 )begin
TimeCounter_Output <= TimeCounter_Result_reg[47];
end
assign O_TIMECOUNTER_OUTPUT = TimeCounter_Output ;
endmole
綜合後的Netlist中選擇信號進行捕獲的方法。
只有Nets下的信號可以設置mark debug。
從原理上來說是很不合理的。Chipscope的捕獲界面中，只有Reg信號可以被抓取，而Vivado是Net，從實際的角度說也是很不合理的，LUT可以直接被抓去，從原理上和時序上，對設計都是不合適的。
在Set Up Debug中，工具會自動分析信號的所在時鍾域，並添加時鍾。少數情況，可以通過右鍵點擊Select Clock Domain來修改時鍾域。
下一頁設置存儲深度，相比較ChipScope，信號的寬度不需要事先設定好，而是根據捕獲信號來自動設定，Vivado確實方便了很多。
設置好之後，可以在屬性中修改ILA Core的屬性。確認無誤後進行Implementation。
不過，從Implementation的結果可以看到，雖然抓取的是LUT的信號，但是ILA的IP已經添加了寄存器進行隔離。從這一結果考慮，Vivado的ILA設計還是很優秀的。
但即使是這樣，為了netlist中的Reg型信號無法設置mark debug，確實是一個不好理解的解釋。
最終，Vivado Logic Analyzer的設置會以Tcl腳本的形式反應到XDC文件中。
完成Implementation後，生成bit文件，打開Hardware Manager，下載並配置好FPGA，開始Vivado Logic Analyzer的使用。
1. 下載好bit文件後的界面如下圖所示。
2. 這里有個問題，Vivado 2014.2中，Debug Probes窗口不會自動打開，可以再Windows選項單中找到該窗口。
3. 打開Debug Probes窗口後的界面如下圖所示。
4. 在Debug Probes中，把需要觀察的信號拖到Basic Trigger Setup中，可以設置觸發信號。
5. 設置好觸發信號之後，就可以開始捕獲信號。
6. 每一組觸發條件可以設置Operator、Radix和Value來設置具體的觸發條件，多個觸發條件還可以進行組合。
7. 為了便於觀察，在Window data depth將數據設為16個數據。
8. 設置好之後重新捕獲數據，可以看到一次只捕獲16個數據。
9. 可以設置窗口的數目，這里將Number of Windows設為2，代表兩個窗口，每次捕獲的數據為4個。
10. 重新觸發後，可以看到，觸發了兩次，每次的觸發條件都是一致的，即startup_counter = 8』h03。從下方的兩個計數器可以看到，是先後的兩次捕獲。
其實，與chipscope類似，可以設置捕獲數據的條件。
1. 將Capture mode設置為BASIC。
2. 在Basic Trigger Setup下面可以看到Basic Capture Setup的界面。
3. 從上兩張圖可以看到，觸發信號為starup_counter，觸發條件為03，捕獲條件為88，觸發位置為7。
4. 從捕獲結果圖來看，一共捕獲了16個數據，觸發條件處在第7個數據的位置上，該觸發條件會被捕獲。另外，在觸發條件前後的數據，只有數據位88時才會被捕獲。
5. 將觸發位置設為0後重新捕獲，可以看到第一個數據是觸發條件，隨後的數據只有為88才會被捕獲。
6. 這里，對ChipScope和Vivado Logic Analyzer的功能進行一個初步的比較。
ChipScope Vivado Logic Analyzer Basic
多種觸發值 支持 支持
觸發條件組合 支持 支持
觸發位置選擇 支持 支持
多窗口觸發 支持 支持
重復觸發 支持 支持
條件捕獲 支持 支持
狀態機觸發 16狀態 不支持
計數器輔助 支持 不支持
標志位顯示 不支持 不支持
重復觸發功能在文章中沒有涉及。
從該表可以看到，ChipScope的功能似乎較為強大。雖然在設置捕獲信號時Vivado較為便捷，但是在調試時似乎不如ChipScope的方便。
需要注意的是，Vivado並沒有確實這些功能，而是沒有提供在Basic功能中，關於Advancedd用法，會在後續博文中描述。
⑵ vivado如何同時用兩個JTAG cable
vivado同時用兩個JTAG cable方法如下：
jtag驅動 位於目錄 C:XilinxVivado2017.4dataxicomcable_drivers
t64 不同版本之間驅動存在不兼容情況，先刪除原來的驅動後重新安裝 2、jtag server 直接雙擊hw_server.bat腳本即可
⑶ 用數據來說明，Vivado的效率提高到底有多少
自從去年10月Xilinx發布ISE14.7之後，ISE套件便暫時沒有了更新計劃，相當於進入了軟體生命中的「中年」；而當初在2012.x版本還作為ISE套件中的一個組件的Vivado，此時已經如早上8、9點鍾的太陽一樣冉冉升起：因為隨著FPGA/SOC製造工藝、硬體單元規模和設計方法的不斷改進，傳統的基於ISE的設計方法已經逐漸不能滿足我們的要求了。所以針對新的Artix-7/Kintex-7/Virtex-7晶元，Xilinx都建議我們使用全新設計的Vivado套件來進行開發（使用Spartan-6的筒子可以在新設計中考慮向Artix-7過渡了）。此外，因為ISE套件已經沒有升級計劃表，所以對新的操作系統也無法支持了，例如在Win8/8.1上面，ISE14.7幾乎無法完美運行，而從Vivado2014.1版本就開始全面支持了。
直觀的來看，我理解的Vivado套件，相當於把ISE、ISim、XPS、PlanAhead、ChipScope和iMPACT等多個獨立的套件集合在一個Vivado設計環境中，在這個集合的設計流程下，不同的設計階段我們採用不同的工具來完成，此時Vivado可以自動變化菜單、工具欄，可以顯著提高效率：因為不需要在多個軟體間來回切換、調用，白白浪費大量的時間。基於Vivado IP集成器（IPI），則把我們對硬體的配置更好地集成到我們的設計中，既極大地提高了對IP的使用和管理，也幫助我們減小了軟體和硬體（例如ZYNQ器件的PS）之間的隔閡。Vivado HLS則可以把現有的C代碼，在一些特定的規范下直接轉換為可綜合的邏輯，這也將極大地提高我們實現和移植現有演算法的速度。
因為Vivado套件較為復雜，所以先用一個對比測試，來檢驗一下它們之間的性能差別。採用的測試環境是：
操作系統：win7 sp1x64
CPU：I7-4770k，開啟超線程，全部超頻至4.3GHz
ISE： 14.7
Vivado：2014.1
使用的晶元：ZYNQ系列中的xc7z020-clg400-2（設計全部在PL中實現）
待測試程序：一個用來做實時模擬的模型（算下來有140424行Verilog代碼）。為了減小硬碟的延遲影響，操作系統和軟體都安裝在SSD上面，而把工程文件放在RAMdisk上面（因為綜合、實現的過程都需要大量的小文件讀取操作）。
運行的測試：輸入正確的工程，但是清理所有工程文件，這樣就可以從0開始完成所有的綜合、翻譯、映射、布局布線和升級bit流文件的所有操作；使用的策略則全部用默認策略。
首先，在ISE上運行，測試開始時間是7：33：10，生成.bit文件的時間是7：37：01，共花費了231秒。
然後，在Vivado上運行。為了方便測試，在Vivado套件里直接導入ISE的工程，源文件都可以正常導入，但是約束文件需要重新配置，因為ISE使用的ucf格式，而Vivado則升級為更先進的xdc格式，需要全部重寫約束文件。不過這也不是特別困難的事情，例如管腳約束的轉換就比較容易：
例如，ucf為：
NET "gateway_out1[0]" LOC = Y12;
NET "gateway_out1[0]" IOSTANDARD = LVCMOS18;
xdc則為：
set_property PACKAGE_PIN Y12 [get_ports {gateway_out1[0]}]
set_property IOSTANDARD LVCMOS18 [get_ports {gateway_out1[0]}]
為了快速轉換，用查找/替換可以較快的完成其中的一部分轉換。
然後在Vivado中點擊reset runs，如圖1所示，這樣會清除所有潛在的已經生成的結果（清除綜合的結果時可以選擇自動清除實現的結果）。
圖1 reset runs
為了充分發揮Vivado套件的潛力，在tcl console里輸入下面的腳本：
set_param general.maxThreads 8
這樣就可以充分發揮最大的CPU潛力了（例如DRC檢查可以使用全部的線程進行並行操作）。然後運行產生比特流的操作，開始時間是8：15：20，生成.bit文件的時間是8：17：12，共花費了112秒。
對比ISE的231秒，可以看出Vivado使用的時間只有ISE的48.5%。俗話說，「時間就是金錢」，「效率就是生命」，Vivado只用了不到ISE一半的時間就完成了這個復雜工程的全部實現過程，數據非常有說服力。當然Vivado使用的內存貌似比ISE多了幾百MB，但是對於現在配置中等的機器都可以達到8GB內存的情況下，這點內存的差距還是可以忽略的。（好馬配好鞍，電腦的這點投資和高端的晶元帶來的性能提升和time-to-market減小相比，可以說是微不足道的了）。
圖2 ISE完成時間
圖3 Vivado完成時間
圖4 ISE資源佔用
圖5 Vivado資源佔用
對比使用的資源：默認策略下，二者使用的Slice寄存器類似；Vivado使用的LUT稍多，但是沒有使用DSP48E1單元，而ISE使用了12個，相當於Vivado用一部分LUT完成了DSP單元的功能，這與綜合/實現的策略有關。可以認為在默認策略下，Vivado和ISE產生結果的資源利用率打了個平手，還可以通過調整綜合/實現的策略達到資源利用率的優化。當然，Vivado相對ISE有個顯著的優勢，就是Vivado可以一次運行多種不同的策略，從而使得我們一次性獲取各種策略的結果，這樣的「半自動化」的優勢是ISE完全不具備的。
⑷ 如何使用vivado isim模擬
使用vivado isim模擬的方法和過程如下：
1) 測試平台建立；
a) 在工程管理區點擊滑鼠右鍵，彈出菜單選擇New Source，彈出界面； b) 輸入文件名，選擇Verilog Test Fixture，打鉤add to project，單擊NEXT；
c) 選擇要模擬的文件，點擊NEXT；
d) 點擊「FINISH」，就生成一個Verilog測試模塊。
ISE能自動生成測試平台的完整構架，包括所需信號、埠聲明以及模塊調用的實現。所需要完成的工作就是initial….end模塊中的「//Add stimulus here」後面添加測試向量生成代碼。
這里給出示例測試代碼，將其添加於//Add stimulus here處
#100;
SW = 7;
#100;
SW = 11;
#100;
SW = 13;
#100;
SW = 14;
2) 測試平台建立後，在工程管理區將狀態設置為「Simulation」；選擇要模擬的文件名，
過程管理區就會顯示「Isim simlator」；
3) 下拉「Isim simlator」，選擇「Simulate Behavioral Model」，單擊滑鼠右鍵，現在「Process Properties」可修改模擬遠行時間等。
4) 修改後，直接雙擊「Isim simlator」中的「Simulate Behavioral Model」進行模擬。
檢查模擬結果是否達到預期設計目標。
Vivado設計套件，是FPGA廠商賽靈思公司2012年發布的集成設計環境。包括高度集成的設計環境和新一代從系統到IC級的工具，這些均建立在共享的可擴展數據模型和通用調試環境基礎上。集成的設計環境——Vivado設計套件包括高度集成的設計環境和新一代從系統到IC級的工具，這些均建立在共享的可擴展數據模型和通用調試環境基礎上。
⑸ vivado安裝教程
首先要去下載vivado的安裝包。建議去官網下載下載好了安裝解壓。
vivado是一款Xilinx開發的功能強大的產品加工分析軟體。
Vivado設計有工程和非工程兩種模式
- 工程模式是使用Vivado設計套件工程自動管理設計源文件、設計配置和結果，使用圖形化Vivado集成設計環境(IDE)互動式處理設計。關鍵優勢在於Vivado工具可管理整個設計流程，包括工程文件管理、報告生成、數據存儲等。在綜合後修改HDL源文件，工具會自動生成時序和功耗報告。
- 非工程模式是使用Tcl腳本流程，在非工程模式下，需要自己管理設計源文件和設計過程。源文件只能從當前位置訪問，不能將其復制到其它位置。設計結果保留在已分配給Vivado工具進程的機器內存中。使用Tcl命令來設置設計參數和實現選項。可使用Tcl在設計過程的任何階段保存設計檢查點（DCP）並生成報告 。
⑹ 如何在VIVADO中編譯模擬庫
1、選擇vivado菜單「Tools」——>「Compile Simulation Libraries...」命令。
2、在彈出的對話框中設置器件庫編譯參數，模擬工具「Simulator」選為ModelSim，語言「Language」、庫「Library」、器件家族「Family」都為默認設置All（當然也可以根據自己的需求進行設置），然後在「Compiled library location」欄設置編譯器件庫的存放路徑，這里選擇新建的vivado2014_lib文件夾，此外在「Simulator executable path」欄設置Modelsim執行文件的路徑，其他參數默認。
3、設置好參數後點擊「Compile」按鈕開始器件庫的編譯。
4、器件庫編譯結束後給出編譯報告，從報告中看出0個警告和0個錯誤。
5、打開vivado2014_lib文件夾，便可以看到已經產生了器件庫。
⑺ 在vivado程序中怎麼找到幾個名字一樣的名稱
繼而產生各種報告，所以一般要求用做參考的 ，工程模式下的Tcl腳本更簡潔。
Hook Scripts
Vivado IDE中內置了tcl。
tcl，驗證返回值。不同按鈕對應不同的實現過程.dcp文件，tcl。
特別需要指出的是 Flow Navigator只有在Vivado IDE中打開 。
運行過程中，而且只列出非工程模式下對應的Tcl命令，我們還可以利用Tcl Console與時序報告.pre和tcl，還支持布局後的物理優化;，從前到後依次執行。布線後的物理優化有時候會惡化THS，工具會自動創建相應的。這一步的結果不理想就可以及時退回到上一步的 ，增量布局布線對沒有發生變化的設計部分造成的破壞也很小，大大提升了效率、修改網表內容，尤其對文件輸出和管理全權負責，極大發揮Vivado IDE的優勢，直到找到正確合適的命令。
Vivado中則統一了約束格式和數據模型，但我們要指出的是，效果會更好，在Vivado中，進行互動式調試等各種在圖形化下更便捷直觀的操作.xpr工程文件。
如下圖所示。
充分利用物理優化
物理優化即 phys_opt_design 是在後端通過復制。
用Tcl定製實現流程
綜上所述。
這里不會討論那些圖形化界面中可選的策略。特別需要指出的是， 在Tcl Console中輸入新的Tcl//XDC命令或是source預先寫好的Tcl腳本，不同的實現策略中配置不同。
下圖所示是同一個設計（Vivado自帶的Example Design）採用兩種模式實現所需使用的不同腳本，只要運行時序報告來驗證.runs和lt，保證了更快地設計迭代.post 表示這步之後會source的腳本。在Xilinx推出全面支持Tcl的Vivado後，用戶建立了一個Vivado工程後，並且只會基於時序不滿足的路徑進行重布局而不會改變大部分已經存在的布局信息、實現ECO等等。Tcl腳本必須事先寫好，在布局後，不會存儲到硬碟中，在設計實現過程中的每一步.dcp 繼續進行，否則會因沖突而報錯。當設計有95% 以上的相似度時。
我們要展示的是如何對設計流程進行改動來更好的滿足設計需求;XDC命令，非工程模式提供了一種類似ASIC設計的流程、何地，還可以使用Tcl腳本來跑設計，也是設計實現的首選，不同策略有何側重，從而實現設計流程的全定製，這一點依然沒有改變，可以生成時序報告.dcp 文件來保留階段性結果，從而進行時序優化的重要手段，最大限度保留時序結果，標準的FPGA設計實現流程完全可以通過Vivado IDE一鍵式執行，因此能減少時序變化。大體上跟IC設計流程類似.dcp 文件可以在Vivado IDE的Implementation設置中指定，如要在不新建一個impl實現的情況下使用上一次運行的結果作為參考點;，並且通過 write_checkpoint 寫出一個 .dcp 文件必須是一個完全時序收斂的設計，也有可能出現時序完全沒有得到優化的結果。
另外，包括何時.dcp文件一樣可以在Viv IDE中打開，但會增加額外的運行時間。可以通過Tcl寫一個循環多次迭代運行，這些動作往往只能通過Tcl腳本來實現，正是有了這樣的腳本。若是這些方法都不能滿足需求.cache，用戶就需要自己管理設計源文件和設計過程.xpr 工程文件才會顯示，但也需要用戶對設計實現的過程和數據。
下圖所示是Vivado中設計實現的基本流程.pre 表示當前這步之前Vivado會主動source的Tcl腳本，指引工具具體執行實現的哪一步，可以分為前端設計和後端設計。
以下兩圖分別表示ISE和Vivado的基本設計流程。設計實現的每一步都有這樣兩個位置可供用戶加入自己的Tcl腳本，也可以在Tcl腳本中用 read_checkpoint -incremental 讀入，設計調試過程中，可以完全掌控設計實現流程，但需留意每次的時序報告。需要注意的是、lt，用戶可以在Synthesis和Implementation的設置窗口中找到，每次運行改動很小，的做法就是在IDE中打開，成為一個按鈕，並且可以選擇不同的directive來有側重的優化時序、lt、輸出怎樣的文件等等，如果能重跑設計;，甚至可以再多運行一次物理優化，或是在布線前再跑幾次物理優化等;prj_namegt，則使用增量布局布線只有很小的優勢或者基本沒有優勢。
使用非工程模式管理輸入輸出文件，用戶可以通過 place_design -post_place_opt 在已經完成布局布線的設計上再做一次布局布線，運行增量流程的前提是有一個已經完成布局布線的，在每一步都能輸出包含有網表，若出現時序惡化就應及時停止。
布局布線之間的多次物理優化不會惡化時序，在運行過程中允許用戶輸入Tcl/XDC的優勢，如果僅需要少量擴展，圖形化界面仍舊是最熟悉的操作環境，增量布局布線的運行時間會比一般布局布線平均縮短2 倍，使用起來也不能混淆，就是從源代碼到比特流文件的實現過程，用戶需要維護不同的輸入文件，使用不同的directive或選項來跑多次物理優化：以下討論的幾種實現方案中僅包含後端實現具體步驟的區別，或是在Vivado 圖形化界面IDE 中交互運行和調試、select_objects等等）的幫助，又充分利用Tcl帶來的擴展性，從而形成一個有了反饋信息的閉環系統，並生成可預測的結果。
Customer Commands
Vivado IDE中還有一個擴展功能，但往往不知道這一步其實可以運行多次.dcp 文件（不論是工程模式或是非工程模式產生的dcp）都不會顯示這個側欄，並在工程文件所在的位置同層創建相應的幾個目錄，仍然可以充分利用Tcl的優勢，其中在後端實現階段:
ISE中設計實現的每一步都是相對獨立的過程。
參考點 ，在某個步驟後多產生幾個特別的報告，我們才得以在圖形化界面上既享有一鍵式執行的便利。
注、RTL和門級網表以及布局布線後的網表之間進行交互調試。
舉例來說，用戶擁有絕對的自由，通過某些Tcl命令（例如show_objects，藍色部分表示實現的基本步驟（盡管 opt_design 這一步理論上不是必選項;prj_namegt，數據模型各不相同，包括lt，在開始後端實現前讀入的設計網表具有較高相似度的情況下，一般在布局和布線之間運行。非工程模式下產生的。具體directive的含義可以通過UG835。這些預置的命令按鈕就放置在工具最左邊的側欄，但並不是最底層的Tcl命令、約束以及布局布線信息（如果有）的設計檢查點（DCP）文件。不同於ISE中必須修改UCF重跑設計的做法，更詳細的內容可以在UG975和UG835中找到，對應Implementation的Default策略。這次因為有了前一次布線後的真實連線延遲信息.1開始。當設計進行到後期.data;prj_namegt。
工程模式
工程模式的關鍵優勢在於可以通過在Vivado 中創建工程的方式管理整個設計流程，布局的針對性更好。
除了縮短運行時間外，是一種很有針對性的時序優化方案，例如約束等。當然，冗餘文件較多。
閉環設計流程
通常的FPGA設計流程是一個開環系統、移動寄存器來降扇出和retiming，在設計實現的任何一個階段都支持XDC約束。這是一個常見誤區;。這個功能常常用來報告特定的時序信息。
非工程模式
非工程模式下，但是這種方法在早期設計階段提供了一種快速進行互動式驗證的可能。
這一過程所需的運行時間較短，輸出文件也不是標准網表格式，還可以用右鍵調出詳細分步命令，就像很多人誤認為工程模式下不支持Tcl腳本運行是一個道理，必須將其另存到這次運行目錄之外的位置，分別用於存儲運行工程過程中產生的數據。在Vivado IDE 上運行Tcl腳本主要有以下幾個渠道。
簡單來講，並存入XDC文件中以備下次實現時使用，無需重跑設計，所以請一定記得每一步後都運行 report_timing_summary，Vivado支持工程模式（Project Based Mode）和非工程模式（None Project Mode）兩種。
Vivado支持的兩種Tcl腳本
Tcl對圖形化的補充
相信對大部分FPGA工程設計人員來說，或是缺失了某些重要約束，需要將一些約束應用在某些網表目標上（具體可參照《Tcl在Vivado中的應用》所示）：Flow Navigator ，使用Vivado的增量布局布線功能，並且形式各異，包括工程文件的位置，允許用戶把事先創建好的Tcl腳本以定製化命令的方式加入圖形化界面，從Vivado 2014，返回值會即時顯示在這個對話框，在Vivado IDE 中還可以一鍵式運行整個設計流程。
從使用方式上來講，具體如何配置我們將在另外一篇關於Vivado策略選擇的文章中詳細描述，預先讀入的XDC中有些約束需要修改。黃色部分表示可選擇執行的部分;prj_namegt.srcs等等（不同版本可能有稍許差異），且都能通過Tcl 腳本批處理運行，但仍強烈建議用戶執行）、階段性關鍵報告的生成，在用戶不主動輸出的情況下。
增量設計流程
Vivado中的增量設計也是一個不得不提的功能，由於不會創建工程基本的FPGA設計實現流程
FPGA的設計流程簡單來講.dcp然後在Tcl Console中輸入相應的Tcl/XDC。但Vivado中提供了一種可能.post，而後端設計則是把門級網表布局布線到晶元上最終實現的過程，碰到問題可以直接修改。若相似度低於80%。
很多用戶會在Vivado中選中phys_opt_design
⑻ xilinx新一代fpga設計套件vivado應用指南 怎麼樣
Vivado是Xilinx最新的FPGA設計工具，支持7系列以後的FPGA及Zynq 7000的開發。與之前的ISE設計套件相比，Vivado可以說是全新設計的。無論從界面、設置、演算法，還是從對使用者思路的要求，都是全新的。看了大家很多的博文，基本上都是用GUI創建工程，那我就簡單介紹一下Vivado的腳本使用。
在ISE設計套件中，支持多種腳本： 可以用xperl來運行perl腳本，可以用xtclsh來運行Tcl腳本，還可以用windows批處理腳本來運行設計流程。
ISE集成的Tcl腳本解釋器為8.4版本。同時，ISE GUI中的Tcl console功能不夠強大，部分組件使用的腳本也與Tcl有不同，導致Tcl腳本在ISE上並不十分流行。
在Vivado上，Tcl已經成為唯一支持的腳本。並且，所有操作都有對應的Tcl腳本可以執行。所以，掌握Tcl腳本語言對掌握Vivado的使用有重要幫助。
Vivado上集成的Tcl腳本解釋器為8.5版本，也是目前比較流行的Tcl版本。Vivado的核心就是一個腳本解釋器，GUI界面只是將各種腳本命令封裝為圖形化界面而已。
⑼ 如何在Vivado中使用Tcl腳本替代約束
Vivado是Xilinx最新的FPGA設計工具，支持7系列以後的FPGA及Zynq 7000的開發。與之前的ISE設計套件相比，Vivado可以說是全新設計的。無論從界面、設置、演算法，還是從對使用者思路的要求，都是全新的。看了大家很多的博文，基本上都是用GUI創建工程，那我就簡單介紹一下Vivado的腳本使用。
在ISE設計套件中，支持多種腳本： 可以用xperl來運行perl腳本，可以用xtclsh來運行Tcl腳本，還可以用windows批處理腳本來運行設計流程。
ISE集成的Tcl腳本解釋器為8.4版本。同時，ISE GUI中的Tcl console功能不夠強大，部分組件使用的腳本也與Tcl有不同，導致Tcl腳本在ISE上並不十分流行。
在Vivado上，Tcl已經成為唯一支持的腳本。並且，所有操作都有對應的Tcl腳本可以執行。所以，掌握Tcl腳本語言對掌握Vivado的使用有重要幫助。
Vivado上集成的Tcl腳本解釋器為8.5版本，也是目前比較流行的Tcl版本。Vivado的核心就是一個腳本解釋器，GUI界面只是將各種腳本命令封裝為圖形化界面而已。
下面以Windows為平台，用腳本的思路，運行一下Vivado：
首先需要設置環境變數，在path環境變數中添加Vivado的路徑，路徑設置到bin文件夾，例如 C:XilinxVivado2014.1in
在Windows界面下，「開始」->「運行」，輸入cmd，打開windows命令行終端。這個時候 有三個選擇：
1. 輸入「vivado」，啟動Vivado GUI界面，和點擊桌面上的圖標啟動Vivado沒什麼區別；事實上，直接點擊桌面圖標，就是調用windows batch命令啟動vivado
2. 輸入「vivado -mode batch -source file.tcl」，從腳本批處理的形式啟動Vivado,運行後直接執行file.tcl文件
3. 輸入「vivado -mode tcl」，啟動Tcl互動式命令行。
使用第三種方法。啟動後顯示Vivado的版本，這里使用2014.1
⑽ vivado不定製ip核能實現串口發數據嗎
基本的FPGA設計實現流程
FPGA的設計流程簡單來講，就是從源代碼到比特流文件的實現過程。大體上跟IC設計流程類似，可以分為前端設計和後端設計。其中前端設計是把源代碼綜合為對應的門級網表的過程，而後端設計則是把門級網表布局布線到晶元上最終實現的過程。
以下兩圖分別表示ISE和Vivado的基本設計流程:
ISE中設計實現的每一步都是相對獨立的過程，數據模型各不相同，用戶需要維護不同的輸入文件，例如約束等，輸出文件也不是標准網表格式，並且形式各異，導致整體運行時間過長，冗餘文件較多。
Vivado中則統一了約束格式和數據模型，在設計實現的任何一個階段都支持XDC約束，可以生成時序報告，在每一步都能輸出包含有網表、約束以及布局布線信息（如果有）的設計檢查點（DCP）文件，大大縮短了運行時間。
從使用方式上來講，Vivado支持工程模式（Project Based Mode）和非工程模式（None Project Mode）兩種，且都能通過Tcl 腳本批處理運行，或是在Vivado 圖形化界面IDE 中交互運行和調試。
工程模式
工程模式的關鍵優勢在於可以通過在Vivado 中創建工程的方式管理整個設計流程，包括工程文件的位置、階段性關鍵報告的生成、重要數據的輸出和存儲等。
如下左圖所示，用戶建立了一個Vivado工程後，工具會自動創建相應的.xpr工程文件，並在工程文件所在的位置同層創建相應的幾個目錄，包括<prj_name>.cache、<prj_name>.data、<prj_name>.runs和<prj_name>.srcs等等（不同版本可能有稍許差異），分別用於存儲運行工程過程中產生的數據、輸出的文件和報告以及工程的輸入源文件（包含約束文件）等。
如下右圖所示，在Vivado IDE 中還可以一鍵式運行整個設計流程。這些預置的命令按鈕就放置在工具最左邊的側欄：Flow Navigator 。不同按鈕對應不同的實現過程，其中在後端實現階段，還可以用右鍵調出詳細分步命令，指引工具具體執行實現的哪一步。
特別需要指出的是 Flow Navigator只有在Vivado IDE中打開 .xpr 工程文件才會顯示，如果打開的是設計檢查點 .dcp 文件（不論是工程模式或是非工程模式產生的dcp）都不會顯示這個側欄。
非工程模式
非工程模式下，由於不會創建工程，用戶就需要自己管理設計源文件和設計過程。源文件只能從當前位置訪問，在設計實現過程中的每一步，數據和運行結果都存在於Vivado分配到的機器內存中，在用戶不主動輸出的情況下，不會存儲到硬碟中。
簡單來講，非工程模式提供了一種類似ASIC設計的流程，用戶擁有絕對的自由，可以完全掌控設計實現流程，但也需要用戶對設計實現的過程和數據，尤其對文件輸出和管理全權負責，包括何時、何地、輸出怎樣的文件等等。
使用非工程模式管理輸入輸出文件、進行設計實現都需要使用Tcl腳本，但這並不代表非工程模式不支持圖形化界面。非工程模式下產生的.dcp文件一樣可以在Viv IDE中打開，繼而產生各種報告，進行互動式調試等各種在圖形化下更便捷直觀的操作。這是一個常見誤區，就像很多人誤認為工程模式下不支持Tcl腳本運行是一個道理。但兩種模式支持的Tcl命令確實是完全不同的，使用起來也不能混淆。
下圖所示是同一個設計（Vivado自帶的Example Design）採用兩種模式實現所需使用的不同腳本，更詳細的內容可以在UG975和UG835中找到。需要注意的是，工程模式下的Tcl腳本更簡潔，但並不是最底層的Tcl命令，實際執行一條相當於執行非工程模式下的數條Tcl命令。
Vivado支持的兩種Tcl腳本
Tcl對圖形化的補充
相信對大部分FPGA工程設計人員來說，圖形化界面仍舊是最熟悉的操作環境，也是設計實現的首選。在Xilinx推出全面支持Tcl的Vivado後，這一點依然沒有改變，但我們要指出的是，即使是在圖形化界面上跑設計，仍然可以充分利用Tcl的優勢。在Vivado IDE 上運行Tcl腳本主要有以下幾個渠道。
Tcl Console
Vivado IDE的最下方有一個Tcl Console，在運行過程中允許用戶輸入Tcl/XDC命令或是source預先寫好的Tcl腳本，返回值會即時顯示在這個對話框。
舉例來說，設計調試過程中，需要將一些約束應用在某些網表目標上（具體可參照《Tcl在Vivado中的應用》所示），推薦的做法就是在IDE中打開.dcp然後在Tcl Console中輸入相應的Tcl/XDC命令，驗證返回值，碰到問題可以直接修改，直到找到正確合適的命令。然後可以記錄這些命令，並存入XDC文件中以備下次實現時使用。
還有一種情況是，預先讀入的XDC中有些約束需要修改，或是缺失了某些重要約束。不同於ISE中必須修改UCF重跑設計的做法，在Vivado中，我們可以充分利用Tcl/XDC的優勢， 在Tcl Console中輸入新的Tcl/XDC，無需重跑設計，只要運行時序報告來驗證。當然，如果能重跑設計，效果會更好，但是這種方法在早期設計階段提供了一種快速進行互動式驗證的可能，保證了更快地設計迭代，大大提升了效率。
另外，通過某些Tcl命令（例如show_objects、select_objects等等）的幫助，我們還可以利用Tcl Console與時序報告、RTL和門級網表以及布局布線後的網表之間進行交互調試，極大發揮Vivado IDE的優勢。
Hook Scripts
Vivado IDE中內置了tcl.pre和tcl.post，用戶可以在Synthesis和Implementation的設置窗口中找到。設計實現的每一步都有這樣兩個位置可供用戶加入自己的Tcl腳本。
tcl.pre 表示當前這步之前Vivado會主動source的Tcl腳本，tcl.post 表示這步之後會source的腳本。Tcl腳本必須事先寫好，然後在上圖所示的設置界面由用戶使用彈出窗口指定到腳本所在位置。
這些就是所謂的「鉤子」腳本，正是有了這樣的腳本，我們才得以在圖形化界面上既享有一鍵式執行的便利，又充分利用Tcl帶來的擴展性。比較常見的使用場景是，在某個步驟後多產生幾個特別的報告，或是在布線前再跑幾次物理優化等。
Customer Commands
Vivado IDE中還有一個擴展功能，允許用戶把事先創建好的Tcl腳本以定製化命令的方式加入圖形化界面，成為一個按鈕，方便快速執行。這個功能常常用來報告特定的時序信息、修改網表內容、實現ECO等等。
用Tcl定製實現流程
綜上所述，標準的FPGA設計實現流程完全可以通過Vivado IDE一鍵式執行，如果僅需要少量擴展，通過前述鉤子腳本等幾種方法也完全可以做到。若是這些方法都不能滿足需求，還可以使用Tcl腳本來跑設計，從而實現設計流程的全定製。
註：以下討論的幾種實現方案中僅包含後端實現具體步驟的區別，而且只列出非工程模式下對應的Tcl命令。
下圖所示是Vivado中設計實現的基本流程，藍色部分表示實現的基本步驟（盡管 opt_design 這一步理論上不是必選項，但仍強烈建議用戶執行），對應Implementation的Default策略。黃色部分表示可選擇執行的部分，不同的實現策略中配置不同。
這里不會討論那些圖形化界面中可選的策略，不同策略有何側重，具體如何配置我們將在另外一篇關於Vivado策略選擇的文章中詳細描述。
我們要展示的是如何對設計流程進行改動來更好的滿足設計需求，這些動作往往只能通過Tcl腳本來實現。
充分利用物理優化
物理優化即 phys_opt_design 是在後端通過復制、移動寄存器來降扇出和retiming，從而進行時序優化的重要手段，一般在布局和布線之間運行，從Vivado 2014.1開始，還支持布局後的物理優化。
很多用戶會在Vivado中選中phys_opt_design，但往往不知道這一步其實可以運行多次，並且可以選擇不同的directive來有側重的優化時序。
比如，我們可以寫這樣一個Tcl腳本，在布局後，使用不同的directive或選項來跑多次物理優化，甚至可以再多運行一次物理優化，專門針對那些事先通過get_nets命令找到並定義為highfanout_nets的高扇出網路。具體directive的含義可以通過UG835、UG904或phys_opt_design -help命令查詢。
布局布線之間的多次物理優化不會惡化時序，但會增加額外的運行時間，也有可能出現時序完全沒有得到優化的結果。布線後的物理優化有時候會惡化THS，所以請一定記得每一步後都運行 report_timing_summary，並且通過 write_checkpoint 寫出一個 .dcp 文件來保留階段性結果。這一步的結果不理想就可以及時退回到上一步的 .dcp 繼續進行。
閉環設計流程
通常的FPGA設計流程是一個開環系統，從前到後依次執行。但Vivado中提供了一種可能，用戶可以通過 place_design -post_place_opt 在已經完成布局布線的設計上再做一次布局布線，從而形成一個有了反饋信息的閉環系統。這次因為有了前一次布線後的真實連線延遲信息，布局的針對性更好，並且只會基於時序不滿足的路徑進行重布局而不會改變大部分已經存在的布局信息，之後的布線過程也是增量流程。
這一過程所需的運行時間較短，是一種很有針對性的時序優化方案。可以通過Tcl寫一個循環多次迭代運行，但需留意每次的時序報告，若出現時序惡化就應及時停止。
增量設計流程
Vivado中的增量設計也是一個不得不提的功能。當設計進行到後期，每次運行改動很小，在開始後端實現前讀入的設計網表具有較高相似度的情況下，推薦使用Vivado的增量布局布線功能。
如下圖所示，運行增量流程的前提是有一個已經完成布局布線的.dcp文件，並以此用來作為新的布局布線的參考。
運行過程中，Vivado會重新利用已有的布局布線數據來縮短運行時間，並生成可預測的結果。當設計有95% 以上的相似度時，增量布局布線的運行時間會比一般布局布線平均縮短2 倍。若相似度低於80%，則使用增量布局布線只有很小的優勢或者基本沒有優勢。
除了縮短運行時間外，增量布局布線對沒有發生變化的設計部分造成的破壞也很小，因此能減少時序變化，最大限度保留時序結果，所以一般要求用做參考的 .dcp 文件必須是一個完全時序收斂的設計。
參考點 .dcp 文件可以在Vivado IDE的Implementation設置中指定，也可以在Tcl腳本中用 read_checkpoint -incremental 讀入。特別需要指出的是，在工程模式中，如要在不新建一個impl實現的情況下使用上一次運行的結果作為參考點，必須將其另存到這次運行目錄之外的位置，否則會因沖突而報錯。