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

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

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

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

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

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

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

根據上面這第一輪的報告再次修改時序約束文件，對有相關性的時鐘增加clock group約束，通常每一個group都包含source clokc和由它generated的所有clock，在上面報告中有跨時鐘域路徑的時鐘也要放到同一個group里，不同的group就可以是async關系了。再對上面報告中發現目標延時不合理路徑時鐘增加clock multisysle約束，增加1個clock的setup約束，同時hold檢查的沿保持不變，這里的寫法可以根據xilinx的constraint約束指導文檔來寫，一種是從快的時鐘進入慢的時鐘，另一種是從慢的時鐘進入快的時鐘，這兩種情況寫法不一樣。

還有個問題要注意，在解決單一時鐘的setup violation問題時，要慎重使用multicycle約束，首先是RTL功能確實是采用了multicycle，我們才能增加這種約束，否則雖然讓timing看上去沒問題，但實際功能卻不能保證。