① vivado 的cpu利用率不高怎麼破
設置里打開性能模式就行了
② 如何加快xcode編譯速度
1. 增加XCode執行的線程數
可以根據自己Mac的性能，更改線程數設置5：defaults write com.apple.Xcode 5
另外也有一個設置可以開啟：defaults write com.apple.dt.Xcode ShowBuildOperationDuration YES
XCode默認使用與CPU核數相同的線程來進行編譯，但由於編譯過程中的IO操作往往比CPU運算要多，因此適當的提升線程數可以在一定程度上加快編譯速度。
2.將Debug Information Format改為DWARF
在工程對應Target的Build Settings中，找到Debug Information Format這一項，將Debug時的DWARF with dSYM file改為DWARF。
這一項設置的是是否將調試信息加入到可執行文件中，改為DWARF後，如果程序崩潰，將無法輸出崩潰位置對應的函數堆棧，但由於Debug模式下可以在XCode中查看調試信息，所以改為DWARF影響並不大。這一項更改完之後，可以大幅提升編譯速度。
比如在目前本人負責的項目中，由於依賴了多個Target，所以需要在每個Target的Debug Information Format設置為DWARF。順便提一下，如果通過Cocoapod引入第三方則Debug Information Format默認就是設置為DWARF的。
SDWebImage通過Cocoapod``Debug Information Format的默認設置
注意：將Debug Information Format改為DWARF之後，會導致在Debug窗口無法查看相關類類型的成員變數的值。當需要查看這些值時，可以將Debug Information Format改回DWARF with dSYM file，clean（必須）之後重新編譯即可。
3.將Build Active Architecture Only改為Yes
在工程對應Target的Build Settings中，找到Build Active Architecture Only這一項，將Debug時的NO改為Yes。
664334-fa1eb995c140ce0f.png
這一項設置的是是否僅編譯當前架構的版本，如果為NO，會編譯所有架構的版本。需要注意的是，此選項在Release模式下必須為NO`，否則發布的ipa在部分設備上將不能運行。這一項更改完之後，可以顯著提高編譯速度。
4.設計編譯優化等級
不要再項目中或者靜態庫中使用-O4，因為這會讓Clang鏈接Link Time Optimizations (LTO)使得編譯更慢，通常使用-O3。
注意：在設置編譯優化之後，XCode斷點和調試信息會不正常，所以一般靜態庫或者其他Target這樣設置。
4.資源整合
4.1 將常用的代碼及文件打包成靜態庫
4.2 添加預編譯文件，把常用的頭文件放到預編譯文件裡面
4.3 能用@class就用@class
③ vivado怎麼看設計最小周期
很高興告訴你！
自從去年10月Xilinx發布ISE147之後，ISE套件便暫時沒有了更新計劃，相當於進入了軟體生命中的「中年」；而當初在2012x版本還作為ISE套件中的一個組件的Vivado，此時已經如早上8、9點鍾的太陽一樣冉冉升起：因為隨著FPGA/SOC製造工藝、硬體單規模和設計方法的不斷改進，傳統的基於ISE的設計方法已經逐漸不能滿足我們的要求了。所以針對新的Artix-7/Kintex-7/Virtex-7晶元，Xilinx都建議我們使用全新設計的Vivado套件來進行開發（使用Spartan-6的筒子可以在新設計中考慮向Artix-7過渡了）。此外，因為ISE套件已經沒有升級計劃表，所以對新的作系統也無法支持了，例如在Win8/81上面，ISE147幾乎無法完美運行，而從Vivado20141版本就開始全面支持了。
直觀的來看，我理解的Vivado套件，相當於把ISE、ISim、XPS、PlanAhead、ChipScope和iMPACT等多個獨立的套件集合在一個Vivado設計環境中，在這個集合的設計流程下，不同的設計階段我們採用不同的工具來完成，此時Vivado可以自動變化菜單、工具欄，可以顯著提高效率：因為不需要在多個軟體間來回切換、調用，白白浪大量的時間。基於Vivado IP集成器（IPI），則把我們對硬體的配置更好地集成到我們的設計中，既極大地提高了對IP的使用和管理，也幫助我們減小了軟體和硬體（例如ZYNQ器件的PS）之間的隔閡。Vivado HLS則可以把現有的C代碼，在一些特定的規范下直接轉換為可綜合的邏輯，這也將極大地提高我們實現和移植現有演算法的速度。
因為Vivado套件較為復雜，所以先用一個對比測試，來檢驗一下它們之間的性能差別。採用的測試環境是：
作系統：win7 sp1x64
CPU：I7-4770k，開啟超線程，全部超頻至43GHz
ISE： 147
Vivado：20141
使用的晶元：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 generalmaxThreads 8
這樣就可以分發揮最大的CPU潛力了（例如DRC檢查可以使用全部的線程進行並行作）。然後運行產生比特流的作，開始時間是8：15：20，生成bit文件的時間是8：17：12，共花了112秒。
對比ISE的231秒，可以看出Vivado使用的時間只有ISE的485%。俗話說，「時間就是金」，「效率就是生命」，Vivado只用了不到ISE一半的時間就完成了這個復雜工程的全部實現過程，數據非常有說服力。當然Vivado使用的內存貌似比ISE多了幾百MB，但是對於現在配置中等的機器都可以達到8GB內存的情況下，這點內存的差距還是可以忽略的。（好馬配好鞍，電腦的這點投資和高端的晶元帶來的性能提升和time-to-market減小相
④ 如何提高ISE的編譯速度
如果你的cpu夠強你應該學會如何利用好它來加速你的代碼編譯速度，那麼你怎麼才能夠最大限度讓你的cpu發燒呢？
下面是一個對比：
比如我的cpu是i7 3770k，
編譯cocos2d-x的libcocos2d工程：
不優化：
1>Time Elapsed 00:01:35.25
優化後：
1>Time Elapsed 00:00:21.66
效果顯著！！！
參考網頁：
Visual Studio 2010中C++並行構建調優(1)
http://developer.51cto.com/art/201003/189235.htm
1>cl : Command line warning D9030: '/Gm' is incompatible with multiprocessing; ignoring /MP switch
解決辦法是：
Properties -> Configuration Properties -> C/C++ -> Code Generation -> Enable Minimal Rebuild -> No(/Gm-)
Properties -> Configuration Properties -> C/C++ -> Geneal -> Multi-processor Compilation -> Yes(/MP)
一些含義和拓展資料：
Enable minimal rebuild
通過保存關聯信息到.IDB文件，使編譯器只對最新類定義改動過的源文件進行重編譯，提高編譯速度
Enable Incremental Compilation
同樣通過.IDB文件保存的信息，只重編譯最新改動過的函數
/MP (Build with Multiple Processes)
http://msdn.microsoft.com/en-us/library/bb385193.aspx
/Gm (Enable Minimal Rebuild)
http://msdn.microsoft.com/en-us/library/kfz8ad09.aspx
⑤ xilinx ise 編譯的過程支持多線程么
是下載線是USB的還是並口的？ 若是USB的，如果開發板和下載線都沒問題，下載配置也沒問題，則可能是USB驅動的問題，如果剛裝過其他版本的ISE則可能導致上述問題，最簡單的方法就是卸載後重裝ISE。 還有可能是開發板上的跳線沒搞對，下載模式的問題
⑥ 如何在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的效率提高到底有多少
自從去年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完全不具備的。