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

本文是自己對Xilinx XC7V系列FPGA用于ASIC前端驗證遇到問題的總結，為自己記載并共享給咱們，假如有歧義或過錯請咱們在談論里指出。

將FPGA用于ASIC驗證和完結傳統RTL規(guī)劃的首要差異便是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在一個合理的值內，所以進行“歸納——優(yōu)化——布局——布線”的流程時，底子不會呈現hold volaTIon的問題，咱們只需求要點處理setup volaTIon的問題就行了。BUFG資源在xilinx FPGA上有限且名貴，所以傳統FPGA規(guī)劃都要求防止門控時鐘的代碼，而且對時鐘域的區(qū)分要十分明晰潔凈，盡或許的讓整個規(guī)劃作業(yè)在同步時鐘，這會有利于TIming的收斂。

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

當BUFG運用量很多時，在歸納完優(yōu)化前就能夠把工程停住了，用vivado翻開dcp文件查找一切BUFG例化的當地，人為添加的MMCM這種IP消耗掉的BUFG能夠不論，歸納發(fā)生的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聯系了。再對上面陳述中發(fā)現方針延時不合理途徑時鐘添加clock multisysle束縛，添加1個clock的setup束縛，一起hold查看的沿堅持不變，這兒的寫法能夠依據xilinx的constraint束縛輔導文檔來寫，一種是從快的時鐘進入慢的時鐘，另一種是從慢的時鐘進入快的時鐘，這兩種狀況寫法不一樣。

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