基于xilinx FPGA驗(yàn)證ASIC可能遇到的timing問題

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

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

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

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

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

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

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