基于Xilinx FPGA用于ASIC前端驗(yàn)證的問題總結(jié)-FPGA本身是有專門的時(shí)鐘cell的，以xilinx FPGA為例，就是primitive庫中的BUFG。

本文是自己對Xilinx XC7V系列FPGA用于ASIC前端驗(yàn)證遇到問題的總結(jié)，為自己記載并共享給咱們，假如有歧義或過錯(cuò)請?jiān)蹅冊谡務(wù)摾镏赋觥?/p>

將FPGA用于ASIC驗(yàn)證和完結(jié)傳統(tǒng)RTL規(guī)劃的首要差異便是ASIC會依據(jù)運(yùn)用場景有很多的門控時(shí)鐘（clokc gate）和電源開關(guān)（power gate），其間power gate不需求在FPGA上完結(jié)而且也無法完結(jié)，它是來歷與IP供貨商或foundry供給的底子庫文件，歸于不行歸納的類型，前端仿真會有對應(yīng)的仿真model，當(dāng)然這個(gè)model也不能在FPGA上完結(jié)。clock gate即門控時(shí)鐘也有對應(yīng)的仿真model，而且稍加修正就能夠歸納并在FPGA上完結(jié)。

FPGA自身是有專門的時(shí)鐘cell的，以xilinx FPGA為例，便是primitive庫中的BUFG。當(dāng)運(yùn)用BUFG時(shí)，F(xiàn)PGA tool是能確保時(shí)鐘樹到各個(gè)Flip-Flop的時(shí)鐘輸入端C的途徑相對等長，這能有用確保Clk_skew在一個(gè)合理的值內(nèi)，所以進(jìn)行“歸納——優(yōu)化——布局——布線”的流程時(shí)，底子不會呈現(xiàn)hold volaTIon的問題，咱們只需求要點(diǎn)處理setup volaTIon的問題就行了。BUFG資源在xilinx FPGA上有限且名貴，所以傳統(tǒng)FPGA規(guī)劃都要求防止門控時(shí)鐘的代碼，而且對時(shí)鐘域的區(qū)分要十分明晰潔凈，盡或許的讓整個(gè)規(guī)劃作業(yè)在同步時(shí)鐘，這會有利于TIming的收斂。

可是當(dāng)FPGA用來完結(jié)ASIC的驗(yàn)證時(shí)，門控時(shí)鐘便是不行防止的，比方ASIC上電復(fù)位時(shí)，不是一切的邏輯都一起作業(yè)起來，即只要一部分Flip-Flop開端作業(yè)，很大一部分或許底子沒有收到有用的時(shí)鐘，這種狀況契合ASIC上電boot的流程，所以在FPGA上驗(yàn)證時(shí)要保存的；再比方ASIC作業(yè)在某一場景下需求下降功耗，會封閉某個(gè)module的時(shí)鐘，這種為了下降功耗功用而存在的clock gate就能夠直接優(yōu)化掉，并不會影響FPGA驗(yàn)證ASIC的功用。所以在拿到ASIC RTL后要先將這種能夠優(yōu)化掉的clock gate挑揀出來并處理，再對處理后的RTL進(jìn)行歸納，查看各種資源的運(yùn)用狀況是否合理，LUT，F(xiàn)F，RAM等資源只要不超越FPGA容量束縛就沒問題，當(dāng)然在運(yùn)用率特別高的狀況下，會形成后邊P&R速度慢而且有失利的危險(xiǎn)，能夠酌情對RTL進(jìn)行取舍。BUFG的運(yùn)用狀況就要要點(diǎn)查看了，XC7V系列的FPGA單片BUFG不超越32個(gè)，而XC7V2000T這種多die的FPGA會有32x4個(gè)BUFG，但BUFG的運(yùn)用是越少越好，當(dāng)BUFG運(yùn)用特別多時(shí)，在place時(shí)就有或許報(bào)錯(cuò)了，各種時(shí)鐘之間的聯(lián)系也要逐一剖析，都是跨時(shí)鐘域問題。

當(dāng)BUFG運(yùn)用量很多時(shí)，在歸納完優(yōu)化前就能夠把工程停住了，用vivado翻開dcp文件查找一切BUFG例化的當(dāng)?shù)?，人為添加的MMCM這種IP消耗掉的BUFG能夠不論，歸納發(fā)生的BUFG要逐一查看，而且掉過頭來修正原始的時(shí)序束縛文件，對每一個(gè)BUFG的輸出O添加generated_clock的束縛，并找到它的source clock，我的經(jīng)歷是這個(gè)時(shí)分還不要對跨時(shí)鐘域進(jìn)行束縛處理，這樣vivado的剖析東西會以為每兩個(gè)時(shí)鐘之間都是有聯(lián)系的，在陳述中都會剖析他們的setup和hold。在vivado里source修正后的時(shí)序束縛文件，進(jìn)行第一輪的P&R，在布線完結(jié)之后report_TIming_summary指令得到整個(gè)design的時(shí)序查看陳述，在這個(gè)timing陳述里會具體列出你界說的一切時(shí)鐘，各個(gè)時(shí)鐘的聯(lián)系，intra陳述和inter陳述：

1. 其間intra陳述是單時(shí)鐘內(nèi)部的setup和hold問題，一般只會有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東西自己完結(jié)的，這個(gè)繞線的意圖或許是由于這條path還存在于別的一個(gè)時(shí)鐘timing束縛里，有或許便是跨時(shí)鐘域的狀況，所以能夠先不論這種setup的violation，但假如logic level自身就很大，比方現(xiàn)已超越了60，但你這條path的clock卻要求跑到80M，那這很難滿意要求了，要掉過頭來去看RTL的問題，最好是對RTL進(jìn)行修正，添加打拍；

2. 而inter陳述則顯現(xiàn)了一切的跨時(shí)鐘域問題，一般第一輪P&R得到的inter陳述timing violation會很慘，不必每一條path都去看，但每兩個(gè)報(bào)出violation的時(shí)鐘都要看，能夠只看violation最嚴(yán)峻的那條path，先查看東西要求的setup時(shí)刻是不是合理，由于咱們還沒有對這兩個(gè)時(shí)鐘加束縛，所以這兒的查看是最嚴(yán)厲的的，東西就會依照時(shí)鐘推移，找到延時(shí)最小的兩個(gè)上升沿來查看setup問題，假如這個(gè)延時(shí)方針不合理咱們就能夠添加multicycle的束縛，這個(gè)延時(shí)方針很或許十分小，只要幾ns。

依據(jù)上面這第一輪的陳述再次修正時(shí)序束縛文件，對有相關(guān)性的時(shí)鐘添加clock group束縛，一般每一個(gè)group都包括source clokc和由它generated的一切clock，在上面陳述中有跨時(shí)鐘域途徑的時(shí)鐘也要放到同一個(gè)group里，不同的group就能夠是async聯(lián)系了。再對上面陳述中發(fā)現(xiàn)方針延時(shí)不合理途徑時(shí)鐘添加clock multisysle束縛，添加1個(gè)clock的setup束縛，一起hold查看的沿堅(jiān)持不變，這兒的寫法能夠依據(jù)xilinx的constraint束縛輔導(dǎo)文檔來寫，一種是從快的時(shí)鐘進(jìn)入慢的時(shí)鐘，另一種是從慢的時(shí)鐘進(jìn)入快的時(shí)鐘，這兩種狀況寫法不一樣。

還有個(gè)問題要注意，在處理單一時(shí)鐘的setup violation問題時(shí)，要穩(wěn)重運(yùn)用multicycle束縛，首先是RTL功用確實(shí)是采用了multicycle，咱們才干添加這種束縛，不然盡管讓timing看上去沒問題，但實(shí)踐功用卻不能確保。