本文是本人對xilinx XC7V系列FPGA用于ASIC前端驗證遇到問題的總結(jié)，為自己記錄并分享給大家，如果有歧義或錯誤請大家在評論里指出。

　　將FPGA用于ASIC驗證和實現(xiàn)傳統(tǒng)RTL設(shè)計的主要區(qū)別就是ASIC會根據(jù)應(yīng)用場景有大量的門控時鐘（clokc gate）和電源開關(guān)（power gate），其中power gate不需要在FPGA上實現(xiàn)并且也無法實現(xiàn)，它是來源與IP供應(yīng)商或foundry提供的基本庫文件，屬于不可綜合的類型，前端仿真會有對應(yīng)的仿真model，當(dāng)然這個model也不能在FPGA上實現(xiàn)。clock gate即門控時鐘也有對應(yīng)的仿真model，并且稍加修改就可以綜合并在FPGA上實現(xiàn)。

　　FPGA本身是有專門的時鐘cell的，以xilinx FPGA為例，就是primitive庫中的BUFG。當(dāng)使用BUFG時，F(xiàn)PGA tool是能保證時鐘樹到各個Flip-Flop的時鐘輸入端C的路徑相對等長，這能有效保證Clk_skew在一個合理的值內(nèi)，所以進行“綜合——優(yōu)化——布局——布線”的流程時，基本不會出現(xiàn)hold volation的問題，我們只需要重點解決setup volation的問題就行了。BUFG資源在xilinx FPGA上有限且寶貴，所以傳統(tǒng)FPGA設(shè)計都要求避免門控時鐘的代碼，并且對時鐘域的劃分要非常清晰干凈，盡可能的讓整個設(shè)計工作在同步時鐘，這會有利于timing的收斂。

　　但是當(dāng)FPGA用來實現(xiàn)ASIC的驗證時，門控時鐘就是不可避免的，比如ASIC上電復(fù)位時，不是所有的邏輯都同時工作起來，即只有一部分Flip-Flop開始工作，很大一部分可能根本沒有收到有效的時鐘，這種情況符合ASIC上電boot的流程，所以在FPGA上驗證時要保留的；再比如ASIC工作在某一場景下需要降低功耗，會關(guān)閉某個module的時鐘，這種為了降低功耗功能而存在的clock gate就可以直接優(yōu)化掉，并不會影響FPGA驗證ASIC的功能。所以在拿到ASIC RTL后要先將這種可以優(yōu)化掉的clock gate挑揀出來并處理，再對處理后的RTL進行綜合，查看各種資源的使用情況是否合理，LUT，F(xiàn)F，RAM等資源只要不超過FPGA容量限制就沒問題，當(dāng)然在使用率特別高的情況下，會造成后面P&R速度慢并且有失敗的風(fēng)險，可以酌情對RTL進行剪裁。BUFG的使用情況就要重點檢查了，XC7V系列的FPGA單片BUFG不超過32個，而XC7V2000T這種多die的FPGA會有32x4個BUFG，但BUFG的使用是越少越好，當(dāng)BUFG使用特別多時，在place時就有可能報錯了，各種時鐘之間的關(guān)系也要逐個分析，都是跨時鐘域問題。

　　當(dāng)BUFG使用量很多時，在綜合完優(yōu)化前就可以把工程停住了，用vivado打開dcp文件搜索所有BUFG例化的地方，人為增加的MMCM這種IP消耗掉的BUFG可以不管，綜合產(chǎn)生的BUFG要逐個檢查，并且掉過頭來修改原始的時序約束文件，對每一個BUFG的輸出O增加generated_clock的約束，并找到它的source clock，我的經(jīng)驗是這個時候還不要對跨時鐘域進行約束處理，這樣vivado的分析工具會認為每兩個時鐘之間都是有關(guān)系的，在報告中都會分析他們的setup和hold。在vivado里source修改后的時序約束文件，進行第一輪的P&R，在布線完成之后report_timing_summary命令得到整個design的時序檢查報告，在這個timing報告里會詳細列出你定義的所有時鐘，各個時鐘的關(guān)系，intra報告和inter報告：

　　1. 其中intra報告是單時鐘內(nèi)部的setup和hold問題，通常只會有setup問題，如果有hold問題，你就要檢查你的clock代碼是不是用錯了BUFG，從而導(dǎo)致clock skew太大，當(dāng)有setup問題時可以看下critical path，如果logic level層數(shù)是合理的，但data path延時卻很大，造成了setup無法滿足，就要打開vivado的版圖工具，找到明顯不合理的走線，如果某兩個LUT之間的空間位置很近，走線延時卻很大，比如超過2ns，那這個走線很有可能進行了多余的繞線，當(dāng)然這是route工具自己實現(xiàn)的，這個繞線的目的可能是因為這條path還存在于另外一個時鐘timing約束里，有可能就是跨時鐘域的情況，所以可以先不管這種setup的violation，但如果logic level本身就很大，比如已經(jīng)超過了60，但你這條path的clock卻要求跑到80M，那這很難滿足要求了，要掉過頭來去看RTL的問題，最好是對RTL進行修改，增加打拍；

　　2. 而inter報告則顯示了所有的跨時鐘域問題，通常第一輪P&R得到的inter報告timing violation會很慘，不用每一條path都去看，但每兩個報出violation的時鐘都要看，可以只看violation最嚴(yán)重的那條path，先檢查工具要求的setup時間是不是合理，因為我們還沒有對這兩個時鐘加約束，所以這里的檢查是最嚴(yán)格的的，工具就會按照時鐘推移，找到延時最小的兩個上升沿來檢查setup問題，如果這個延時目標(biāo)不合理咱們就可以增加multicycle的約束，這個延時目標(biāo)很可能非常小，只有幾ns。