同設(shè)計(jì)：FPGA帶IP核工程的時(shí)序收斂與效率優(yōu)化)
做過(guò)大型FPGA工程的朋友應(yīng)該都有過(guò)這種體驗(yàn)RTL寫起來(lái)很快真正折磨人的是綜合布局布線那動(dòng)輒幾個(gè)小時(shí)的等待以及怎么調(diào)都收不攏的時(shí)序。我?guī)н^(guò)好幾版帶高速接口和復(fù)雜IP核的工程早期全部壓在Vivado一條流水線里每次迭代都像在熬鷹。后來(lái)切換到Synplify與Vivado協(xié)同設(shè)計(jì)的流程綜合時(shí)間縮短了將近一半時(shí)序收斂的迭代次數(shù)也明顯減少。這篇文章就圍繞這套協(xié)同設(shè)計(jì)方法聊聊帶IP核的FPGA工程到底該怎么組織、怎么跑通、有哪些坑必須避開(kāi)。這套流程的核心價(jià)值在于讓專業(yè)工具干專業(yè)的事Synplify負(fù)責(zé)邏輯綜合和時(shí)序預(yù)估Vivado只專注在布局布線和最終實(shí)現(xiàn)上。對(duì)于使用Aurora、CAN-FD、FFT、除法器等IP核的工程尤其是圖像處理、信號(hào)發(fā)生器、串口升級(jí)這些需要反復(fù)迭代的項(xiàng)目這套協(xié)同設(shè)計(jì)帶來(lái)的收益非?？捎^。不管你是在校學(xué)生做FPGA入門課設(shè)還是工程師在推進(jìn)量產(chǎn)級(jí)項(xiàng)目下面這些基于實(shí)際項(xiàng)目踩坑總結(jié)出來(lái)的流程和心得都能直接用得上。1. 為什么在Vivado時(shí)代還要用Synplify做綜合先解決一個(gè)最常見(jiàn)的疑問(wèn)Vivado自帶綜合引擎已經(jīng)很成熟了為什么還要繞一圈用Synplify綜合完再導(dǎo)回Vivado布局布線這個(gè)問(wèn)題的答案要從綜合這個(gè)環(huán)節(jié)的本質(zhì)說(shuō)起。1.1 Synplify的差異化優(yōu)勢(shì)到底在哪里綜合的本質(zhì)是把RTL代碼翻譯成由查找表和觸發(fā)器構(gòu)成的網(wǎng)表。Vivado自帶綜合器在標(biāo)準(zhǔn)流程下表現(xiàn)不錯(cuò)但Synplify在幾個(gè)關(guān)鍵維度上有明顯優(yōu)勢(shì)。首先是綜合策略的成熟度。Synplify在FPGA領(lǐng)域耕耘了二十多年它的有限狀態(tài)機(jī)優(yōu)化、資源共享、retiming這些算法經(jīng)過(guò)大量工業(yè)級(jí)項(xiàng)目的打磨綜合出來(lái)的網(wǎng)表在面積和頻率上通常比默認(rèn)綜合結(jié)果更好。其次是綜合速度。我?guī)н^(guò)一個(gè)包含DDR控制器、PCIe硬核和視頻處理邏輯的工程RTL代碼量大概在十幾萬(wàn)行Vivado默認(rèn)綜合需要跑三四十分鐘Synplify在相同機(jī)器上十分鐘左右就能跑完。這個(gè)速度差異在頻繁修改RTL做驗(yàn)證的階段非常寶貴每次綜合省二十分鐘一天迭代十幾輪省出來(lái)的時(shí)間相當(dāng)可觀。第三是跨平臺(tái)和版本迭代的靈活性。Synplify可以獨(dú)立于Vivado版本運(yùn)行對(duì)于使用多種FPGA平臺(tái)的團(tuán)隊(duì)統(tǒng)一用Synplify做綜合可以保證綜合結(jié)果的一致性不會(huì)因?yàn)閂ivado版本更新導(dǎo)致綜合策略變化。這一點(diǎn)在團(tuán)隊(duì)協(xié)作中常被忽視但實(shí)際影響很大。第四個(gè)優(yōu)勢(shì)也是我覺(jué)得最關(guān)鍵的一點(diǎn)是Synplify對(duì)時(shí)序的早期預(yù)估能力。它在綜合階段就能依據(jù)物理約束做粗略的時(shí)序估算告訴你哪條路徑可能時(shí)序緊張。這意味著時(shí)序問(wèn)題可以在綜合階段就暴露出來(lái)而不是等到布局布線跑完才被一通亂報(bào)嚇一跳。1.2 什么樣的工程適合走協(xié)同設(shè)計(jì)流程不是所有工程都需要Synplify和Vivado協(xié)同設(shè)計(jì)。我總結(jié)下來(lái)具備以下特征的工程比較適合走這套流程。首先是IP核數(shù)量多、類型復(fù)雜的工程。比如用到Aurora 8B/10B高速收發(fā)器、CAN-FD控制器、各類DSP IP核的工程IP核的綜合結(jié)果直接影響整體時(shí)序Synplify對(duì)IP核網(wǎng)表的處理更加精細(xì)。特別是使用Xilinx的Aurora IP它的GT復(fù)位邏輯和時(shí)鐘結(jié)構(gòu)非常復(fù)雜用Synplify綜合時(shí)對(duì)復(fù)位和時(shí)鐘樹的處理更容易滿足要求。其次是邏輯規(guī)模大、時(shí)序約束緊的工程。當(dāng)工程資源利用率超過(guò)60%或者主頻要求接近器件極限時(shí)綜合質(zhì)量對(duì)布局布線的影響會(huì)急劇放大。Synplify綜合出的網(wǎng)表質(zhì)量在這種場(chǎng)景下更穩(wěn)定。第三是需要頻繁迭代RTL邏輯的項(xiàng)目。比如FPGA圖像處理算法調(diào)試階段經(jīng)常要改幾行代碼就跑一次綜合看效果。用Synplify做綜合等于把整個(gè)迭代周期壓縮了。1.3 什么時(shí)候不建議用協(xié)同設(shè)計(jì)說(shuō)句公道話Synplify也不是萬(wàn)能的。如果你的工程只用了一兩個(gè)標(biāo)準(zhǔn)IP核邏輯規(guī)模也不大直接用Vivado一條龍反而更省事。原因很簡(jiǎn)單多一個(gè)工具就多一層銜接成本EDIF網(wǎng)表的生成、約束文件的轉(zhuǎn)換、IP核的重新定位每一步都可能引入新的問(wèn)題。另外如果工程大量依賴Vivado獨(dú)有的綜合特性比如使用Vivado的自動(dòng)流水線插入、全局時(shí)鐘緩存優(yōu)化等那強(qiáng)行套用Synplify反而可能丟掉這些優(yōu)化機(jī)會(huì)。我在實(shí)際中遇到過(guò)類似情況某個(gè)工程大量使用Vivado的宏和綜合屬性Synplify綜合后功能雖然正確但性能和資源比Vivado直接綜合差了不少。所以協(xié)同設(shè)計(jì)是一個(gè)可選工具不是一個(gè)必選流程。明確這一點(diǎn)后面做方案選型思路會(huì)清晰很多。2. 協(xié)同設(shè)計(jì)的整體思路與工程組織如果決定走協(xié)同設(shè)計(jì)先別急著開(kāi)工具花點(diǎn)時(shí)間把工程結(jié)構(gòu)理清楚。協(xié)同設(shè)計(jì)最怕的就是兩個(gè)工具各管一段、接口混亂。下面這套工程組織方式是我在多個(gè)項(xiàng)目里驗(yàn)證過(guò)的能夠有效減少銜接階段的低級(jí)錯(cuò)誤。2.1 雙工具流水線的核心流程協(xié)同設(shè)計(jì)的核心流水線說(shuō)白了就是四個(gè)環(huán)節(jié)IP核生成、邏輯綜合、網(wǎng)表交付、布局布線。整個(gè)流程中設(shè)計(jì)源文件只有一個(gè)來(lái)源所有RTL代碼統(tǒng)一維護(hù)IP核統(tǒng)一在Vivado中生成Synplify只做綜合和網(wǎng)表輸出最后的布局布線又回到Vivado完成。這種流水線里最需要嚴(yán)格管控的是IP核。很多項(xiàng)目習(xí)慣在Vivado里生成IP核后直接例化使用但在協(xié)同設(shè)計(jì)流程里IP核文件需要分兩路走一路是RTL仿真模型給仿真用另一路是綜合網(wǎng)表交給Synplify做綜合。如果IP核版本沒(méi)對(duì)齊很容易出現(xiàn)仿真通過(guò)但綜合后功能對(duì)不上的情況。2.2 IP核在哪里生成與維護(hù)聽(tīng)過(guò)一種說(shuō)法說(shuō)協(xié)同設(shè)計(jì)要把IP核拿到Synplify里去生成這個(gè)說(shuō)法并不準(zhǔn)確。Synplify對(duì)Xilinx IP核的處理方式是“讀入并識(shí)別”不是“生成”。IP核本身必須由Vivado生成Synplify做的是把IP核的網(wǎng)表文件讀入到綜合流程中和用戶邏輯一起進(jìn)行綜合優(yōu)化。具體操作時(shí)每個(gè)IP核在Vivado中生成后會(huì)附帶一個(gè)工程文件里面包含IP核的所有配置參數(shù)和生成文件列表。在Synplify中需要將這個(gè)工程文件或者IP核的網(wǎng)表文件添加到工程里。以Vivado生成一個(gè)FIFO IP核為例生成完成后要把IP核的輸出網(wǎng)表文件通常是NGC或EDIF格式以及相關(guān)的約束文件都納入工程管理。這里有一個(gè)容易踩坑的點(diǎn)。Vivado不同版本生成的IP核文件格式可能不一樣。使用較老版本IP核時(shí)生成的是NGC格式用新版Vivado生成時(shí)可能輸出的是EDIF或其他格式。Synplify對(duì)這兩種格式的支持程度不同導(dǎo)致綜合結(jié)果也會(huì)不同。我踩過(guò)這個(gè)坑同一個(gè)DDR控制器IP核在Vivado 2018.2版本下生成后Synplify綜合沒(méi)問(wèn)題換到Vivado 2020.2生成后Synplify綜合直接報(bào)錯(cuò)原因是網(wǎng)表格式和約束文件的兼容性問(wèn)題。解決方案是查Synplify版本對(duì)應(yīng)的Xilinx IP核支持列表必要時(shí)做版本匹配。2.3 工程目錄與版本管理的幾點(diǎn)建議協(xié)同設(shè)計(jì)工程的目錄組織直接決定了交接效率。推薦用下面的結(jié)構(gòu)組織工程文件rtl/存放所有RTL源碼包括頂層、子模塊和IP核的例化文件ip/存放Vivado生成的所有IP核文件按IP核名稱分子目錄syn/存放Synplify工程文件、綜合腳本和綜合結(jié)果constraints/存放時(shí)序約束和物理約束文件impl/存放Vivado布局布線工程、比特流和調(diào)試文件sim/存放仿真測(cè)試文件和波形這套結(jié)構(gòu)有兩點(diǎn)好處。一是職責(zé)清晰每個(gè)工具都有自己的工作目錄不會(huì)互相污染二是方便腳本化后續(xù)要跑自動(dòng)化回歸只需要在syn/目錄下執(zhí)行綜合腳本再到impl/目錄下執(zhí)行布局布線腳本不用到處找文件。版本管理方面建議把所有源文件納入Git管理但生成文件不要提交。尤其是Synplify生成的各種中間網(wǎng)表文件體積大且每次綜合都會(huì)變化提交到Git里只會(huì)帶來(lái)無(wú)盡的沖突和倉(cāng)庫(kù)膨脹。IP核的生成文件原則上也不提交團(tuán)隊(duì)協(xié)作時(shí)每個(gè)人都應(yīng)該有自己的本地IP核生成路徑提交ip/目錄下的IP核配置描述文件即可。2.4 工具版本匹配的注意事項(xiàng)版本匹配問(wèn)題在協(xié)同設(shè)計(jì)里被討論得最多也是最容易被忽視的。Synplify和Vivado的版本如果不匹配輕則綜合結(jié)果不理想重則直接無(wú)法識(shí)別IP核或報(bào)錯(cuò)中斷。這里分享一個(gè)務(wù)實(shí)的匹配策略不要追求版本完全對(duì)應(yīng)而是以Synplify的IP核支持清單為準(zhǔn)。每次Synplify發(fā)布新版本都會(huì)附帶一個(gè)詳細(xì)的支持列表標(biāo)明該版本支持哪些廠商的哪些器件型號(hào)以及IP核的哪些版本。在開(kāi)始一個(gè)項(xiàng)目之前先確定Synplify版本再根據(jù)支持列表選擇Vivado版本。比如如果你用的Synplify版本明確支持Vivado 2020.2生成的IP核那就統(tǒng)一用Vivado 2020.2不要團(tuán)隊(duì)里有人用2019.1、有人用2021.1。還有一點(diǎn)IDEA模式下的IP核管理。Synplify通過(guò)IP核識(shí)別時(shí)需要指定IP核的生成目錄。這些目錄在Vivado中生成IP核時(shí)是絕對(duì)路徑換一臺(tái)機(jī)器就失效了。所以協(xié)同設(shè)計(jì)通常要打開(kāi)Synplify的“Use Relative Paths”之類的選項(xiàng)讓工程相對(duì)路徑化這樣才能保證在不同機(jī)器上都能打開(kāi)工程。這個(gè)細(xì)節(jié)在團(tuán)隊(duì)協(xié)作中非常關(guān)鍵解決不了這個(gè)每次換機(jī)器都要重新指定一遍IP核路徑非常痛苦。3. 實(shí)操流程從RTL到比特流的完整鏈路理論說(shuō)了一大堆接下來(lái)進(jìn)入實(shí)操環(huán)節(jié)。這個(gè)部分我會(huì)按照完整流程逐步拆解從IP核生成、Synplify綜合、約束處理到Vivado布局布線每一步都給出可以直接操作的方法。3.1 第一步在Vivado里生成和配置IP核在Vivado中生成IP核是協(xié)同設(shè)計(jì)的起點(diǎn)。具體操作是在Vivado中新建一個(gè)IP核或打開(kāi)已有的IP核工程配置好參數(shù)后生成輸出文件。這里有幾個(gè)參數(shù)需要額外注意。首先是IP核的輸出文件格式盡量選擇EDIF或NGC格式作為綜合網(wǎng)表輸出。在Vivado的IP核自定義設(shè)置中通常有輸出產(chǎn)品選項(xiàng)比如綜合網(wǎng)表、仿真模型、約束文件等。在協(xié)同設(shè)計(jì)流程里綜合網(wǎng)表中的EDIF文件是Synplify做綜合時(shí)主要使用的文件。其次是IP核的約束文件處理。Vivado為每個(gè)IP核生成的約束文件包括引腳約束、時(shí)序約束和區(qū)域約束。這些約束文件在協(xié)同設(shè)計(jì)中需要統(tǒng)一收集后續(xù)交給Synplify或者Vivado使用。比較穩(wěn)妥的做法是在生成IP核時(shí)設(shè)置輸出約束文件到一個(gè)特定目錄比如放在constraints/ip目錄下后續(xù)統(tǒng)一處理。第三是復(fù)位和高電平有效這類配置選項(xiàng)。Aurora IP核里關(guān)于GT復(fù)位、power_down的配置和CAN-FD IP核的中斷配置直接決定了后續(xù)RTL邏輯的接口語(yǔ)義。務(wù)必在Vivado配置階段把每個(gè)接口搞清楚否則后面到了Synplify里要根據(jù)IP核接口改RTL那代價(jià)就大了。3.2 第二步Synplify綜合與約束傳遞IP核準(zhǔn)備妥當(dāng)后打開(kāi)Synplify新建一個(gè)綜合工程。RTL源碼的添加方式很直接把所有.v或者.vhd文件加進(jìn)工程。這里有個(gè)小建議把RTL文件按模塊分目錄管理添加到Synplify工程時(shí)也保持同樣的目錄層級(jí)這樣綜合報(bào)告定位模塊時(shí)會(huì)更直觀。IP核的添加方式有兩種。一種是直接把Vivado生成的EDIF網(wǎng)表文件作為輸入添加進(jìn)去另一種是使用Synplify的IP核管理功能。兩種方式在普通工程中差別不大但對(duì)于包含大量IP核的工程第二種方式更推薦因?yàn)镾ynplify能自動(dòng)識(shí)別IP核之間的依賴關(guān)系并且能正確讀取IP核的約束文件。約束文件的處理是協(xié)同設(shè)計(jì)的核心環(huán)節(jié)之一。Vivado工程使用XDC格式的約束而Synplify綜合時(shí)使用SDC格式的約束。這兩個(gè)約束格式并不完全等價(jià)XDC中包含的大量物理約束和時(shí)序例外在SDC中都無(wú)法完整表達(dá)。操作上可以這樣處理在Synplify中設(shè)置時(shí)序約束時(shí)只設(shè)置核心的時(shí)鐘周期、輸入輸出延遲等基礎(chǔ)約束用于指導(dǎo)綜合器做時(shí)序優(yōu)化而物理約束和詳細(xì)的時(shí)序例外則保留在XDC中等網(wǎng)表交付給Vivado后讓布局布線工具去處理。在綜合屬性設(shè)置上有幾點(diǎn)經(jīng)驗(yàn)值可以參考。對(duì)于目標(biāo)頻率建議把約束的時(shí)鐘周期設(shè)置得比實(shí)際需求略嚴(yán)格一些預(yù)留5%到10%的余量。這個(gè)“超頻設(shè)約束”的做法是因?yàn)镾ynplify綜合階段的時(shí)序估算和最終布局布線的真實(shí)延遲存在偏差留出余量可以避免網(wǎng)表交到Vivado后大量路徑違反時(shí)序。頻率策略選擇“Performance Balanced”這個(gè)選項(xiàng)在面積和速度之間相對(duì)均衡適合大多數(shù)工程。映射選項(xiàng)方面如果資源足夠可以嘗試開(kāi)啟“Use Full Mapping”或類似的選項(xiàng)讓綜合器做更充分的邏輯優(yōu)化。完成約束設(shè)置后點(diǎn)擊綜合按鈕開(kāi)始綜合。綜合完成后重點(diǎn)看三個(gè)方面時(shí)序報(bào)告中的最差負(fù)時(shí)序裕量、資源利用率報(bào)告、以及警告信息。如果最差負(fù)時(shí)序裕量為負(fù)說(shuō)明存在路徑不滿足時(shí)序要求需要回到RTL層或約束層做優(yōu)化。資源利用率方面如果查找表或觸發(fā)器使用率超過(guò)70%需要檢查是否存在冗余邏輯或優(yōu)化空間。警告信息里經(jīng)常包含未連接端口、多驅(qū)動(dòng)信號(hào)等潛在問(wèn)題建議逐條查看不要直接忽略。3.3 第三步把EDIF網(wǎng)表交還給Vivado布局布線Synplify綜合完成后會(huì)輸出多種文件其中最核心的是EDIF格式的網(wǎng)表文件。在Synplify工程中將綜合結(jié)果導(dǎo)出為EDIF網(wǎng)表這就是交給Vivado做布局布線的源文件。在Vivado側(cè)新建一個(gè)工程器件型號(hào)必須和Synplify綜合時(shí)選的型號(hào)一致否則在導(dǎo)入網(wǎng)表時(shí)會(huì)報(bào)錯(cuò)。工程的RTL源碼不需要再添加了因?yàn)镾ynplify已經(jīng)綜合成了網(wǎng)表Vivado只需要網(wǎng)表文件和約束文件就能完成布局布線。導(dǎo)入EDIF網(wǎng)表后還需要添加同步生成的約束文件。建議把XDC約束文件中的時(shí)序約束包括時(shí)鐘定義、輸入輸出延遲等和物理管腳約束都加進(jìn)去。如果約束文件之前在Synplify里同步做過(guò)設(shè)置這里需要注意避免約束重復(fù)。一個(gè)常見(jiàn)問(wèn)題是同樣的時(shí)鐘約束在SDC和XDC里各定義了一次導(dǎo)致Vivado布局布線時(shí)報(bào)告約束沖突。解決辦法是在Synplify綜合時(shí)不導(dǎo)出時(shí)序約束文件只保留物理管腳約束在XDC中時(shí)序約束統(tǒng)一在Vivado側(cè)管理。但如果不熟悉兩邊的約束分工更穩(wěn)妥的做法是在Vivado側(cè)只保留管腳約束和物理約束時(shí)序約束全部從Synplify導(dǎo)入后在Vivado中重新生成和審查。導(dǎo)入完成后運(yùn)行布局布線。如果一切正常會(huì)生成比特流文件可直接用于硬件調(diào)試或固件發(fā)布。到這里Synplify和Vivado協(xié)同設(shè)計(jì)的基本流程就走通了。3.4 第四步時(shí)序收斂與設(shè)計(jì)迭代布局布線完成后第一件事不是急著生成比特流而是打開(kāi)時(shí)序報(bào)告查看最差負(fù)時(shí)序裕量和總負(fù)時(shí)序裕量這兩個(gè)關(guān)鍵指標(biāo)。如果時(shí)序違規(guī)嚴(yán)重先回Synplify調(diào)整綜合約束不要直接在Vivado里硬調(diào)布局布線選項(xiàng)。這是因?yàn)椴季植季€層面的優(yōu)化手段有限能做的無(wú)非是改變布局策略、優(yōu)化時(shí)鐘樹等效果往往不理想。而回到綜合階段可以通過(guò)調(diào)整約束、修改RTL流水線結(jié)構(gòu)、調(diào)整寄存器復(fù)制策略等方式從源頭解決問(wèn)題。我在多次實(shí)踐中發(fā)現(xiàn)時(shí)序違規(guī)的根因大多數(shù)在RTL設(shè)計(jì)層面比如組合邏輯鏈路過(guò)長(zhǎng)、復(fù)位邏輯時(shí)序不滿足、跨時(shí)鐘域路徑約束不當(dāng)?shù)?。?dāng)Synplify綜合后的時(shí)序報(bào)告顯示最差負(fù)時(shí)序裕量為正但Vivado布局布線后出現(xiàn)少量違規(guī)時(shí)可以嘗試在Vivado中調(diào)節(jié)布局布線策略。將布局布線模式設(shè)為Explore或者嘗試PerformanceExplore這些策略通過(guò)嘗試不同的布線算法組合來(lái)優(yōu)化時(shí)序。但要注意這些策略會(huì)顯著增加運(yùn)行時(shí)間建議在集中收尾階段使用。時(shí)序收斂達(dá)標(biāo)后進(jìn)入迭代設(shè)計(jì)階段。這里的迭代包括兩種情況一種是修改RTL代碼后重新綜合布局布線這時(shí)候只修改了部分邏輯理論上可以只對(duì)變化的部分做增量布局布線另一種是修改IP核配置后重新生成IP核此時(shí)需要重新在Synplify里做綜合。增量布局布線對(duì)工程管理要求較高我一般建議在工程穩(wěn)定之前還是做全量流程等設(shè)計(jì)凍結(jié)后再考慮增量手段。3.5 高帶寬IP核協(xié)同設(shè)計(jì)的細(xì)節(jié)處理在帶IP核的FPGA工程里Aurora 8B/10B、CAN-FD這些IP核的使用頻率很高而且它們的協(xié)同處理方式有特殊性。這里單獨(dú)說(shuō)幾個(gè)細(xì)節(jié)。Aurora 8B/10B IP核的協(xié)同設(shè)計(jì)最需要注意的是GT復(fù)位邏輯。Aurora IP核的復(fù)位接口通常包括gt_reset和system_reset等這些復(fù)位信號(hào)直接影響GT收發(fā)器的初始化過(guò)程。在RTL中如果對(duì)復(fù)位信號(hào)做了同步處理或延遲處理在Synplify綜合時(shí)務(wù)必保證這些復(fù)位邏輯不被優(yōu)化掉。有幾次我在綜合工具里看到未連接的復(fù)位接口被自動(dòng)優(yōu)化結(jié)果上板后發(fā)現(xiàn)Aurora鏈路無(wú)法建立。解決辦法是在RTL中把復(fù)位信號(hào)聲明為合理的屬性防止綜合器將其判定為無(wú)影響的冗余邏輯。CAN-FD IP核相對(duì)簡(jiǎn)單但要注意時(shí)鐘域的劃分。CAN-FD控制器通常有總線時(shí)鐘域、處理器接口時(shí)鐘域和波特率時(shí)鐘域,不同時(shí)鐘域之間的握手信號(hào)必須經(jīng)過(guò)正確的同步。在Synplify綜合時(shí)如果跨時(shí)鐘域約束沒(méi)有在SDC中聲明綜合器可能將這些路徑當(dāng)作普通路徑處理導(dǎo)致布局布線后出現(xiàn)亞穩(wěn)態(tài)問(wèn)題。建議在SDC中為每個(gè)跨時(shí)鐘域路徑添加set_false_path約束并配合RTL中的兩級(jí)同步器邏輯。另外FFT IP核、除法器等運(yùn)算類IP核的協(xié)同設(shè)計(jì)相對(duì)直接因?yàn)樗鼈兺ǔＪ羌兘M合邏輯和寄存器邏輯的組合不涉及太多跨時(shí)鐘域問(wèn)題。但要注意FIFO IP核的讀時(shí)鐘和寫時(shí)鐘可能來(lái)自不同時(shí)鐘域這時(shí)候FIFO IP核的復(fù)位和時(shí)鐘約束同樣需要仔細(xì)設(shè)置。FIFO IP核使用異步時(shí)鐘時(shí)如果復(fù)位信號(hào)處理不當(dāng)會(huì)出現(xiàn)功能仿真通過(guò)但上板后數(shù)據(jù)錯(cuò)位的問(wèn)題。4. 常見(jiàn)問(wèn)題與排查技巧實(shí)錄協(xié)同設(shè)計(jì)流程跑多了必然會(huì)遇到五花八門的報(bào)錯(cuò)和異常。這里把我在多個(gè)項(xiàng)目里遇到的高頻問(wèn)題整理成速查表并分享排查思路。4.1 Vivado DRC報(bào)錯(cuò)與Implement變紅的經(jīng)典場(chǎng)景在協(xié)同設(shè)計(jì)流程里Vivado的DRC檢查經(jīng)常被觸發(fā)。特別是在布局布線完成后DRC報(bào)告里報(bào)出一堆RTSTAT-2錯(cuò)誤很多新手就懵了。這個(gè)RTSTAT-2這類DRC規(guī)則的實(shí)質(zhì)是約束設(shè)置和實(shí)際物理實(shí)現(xiàn)之間的沖突。舉個(gè)例子X(jué)DC里如果一個(gè)管腳被分配到了某個(gè)BANK的低電壓域但實(shí)際連接的IP核或邏輯需要的電壓等級(jí)不同DRC就會(huì)報(bào)錯(cuò)。在協(xié)同設(shè)計(jì)流程中由于管腳約束在XDC中定義而時(shí)序約束從Synplify導(dǎo)入兩邊信息不完整就很容易導(dǎo)致這類DRC報(bào)錯(cuò)。排查思路是先分清DRC錯(cuò)誤的具體類型是針對(duì)引腳、時(shí)鐘、還是區(qū)域的沖突然后針對(duì)性修改XDC。如果是引腳電壓域沖突修改引腳的IOSTANDARD屬性如果是時(shí)鐘約束沖突檢查是否在SDC和XDC中重復(fù)定義了時(shí)鐘。Implement變紅往往伴隨著DRC錯(cuò)誤或布局布線資源不足這時(shí)候的排查優(yōu)先級(jí)是先處理DRC錯(cuò)誤再檢查資源利用率最后才是時(shí)序違例。這里有一個(gè)經(jīng)驗(yàn)DRC錯(cuò)誤不要攢著到最后才看。Synplify生成的網(wǎng)表和Vivado中IP核的物理布局如果存在潛在沖突DRC檢查在布局布線前就應(yīng)該做一次作為獨(dú)立步驟運(yùn)行。Vivado支持在布局布線前單獨(dú)運(yùn)行DRC檢查盡早發(fā)現(xiàn)物理實(shí)現(xiàn)層面的沖突能在源頭上減少排錯(cuò)成本。4.2 復(fù)位信號(hào)引起的跨時(shí)鐘域與亞穩(wěn)態(tài)問(wèn)題FPGA設(shè)計(jì)中復(fù)位信號(hào)的處理是一個(gè)高頻踩坑點(diǎn)。在協(xié)同設(shè)計(jì)流程中復(fù)位信號(hào)的問(wèn)題尤其隱蔽因?yàn)镾ynplify綜合時(shí)對(duì)復(fù)位信號(hào)的處理邏輯可能和Vivado直接綜合不一樣。先解釋一下亞穩(wěn)態(tài)。簡(jiǎn)單來(lái)說(shuō)當(dāng)觸發(fā)器的數(shù)據(jù)輸入在時(shí)鐘邊沿附近發(fā)生變化時(shí)觸發(fā)器的輸出可能進(jìn)入一個(gè)不確定狀態(tài)既不是穩(wěn)定的高電平也不是穩(wěn)定的低電平這就是亞穩(wěn)態(tài)。如果這個(gè)不確定狀態(tài)被后續(xù)邏輯采樣就會(huì)導(dǎo)致功能錯(cuò)誤。復(fù)位信號(hào)如果處理不當(dāng)很容易引起亞穩(wěn)態(tài)特別是異步復(fù)位信號(hào)在釋放時(shí)與時(shí)鐘邊沿關(guān)系不確定時(shí)。很多工程師在RTL里把異步復(fù)位、同步釋放掛在嘴邊但實(shí)際寫代碼時(shí)只做了一半。比如復(fù)位同步釋放邏輯只處理了復(fù)位釋放的同步但沒(méi)有處理復(fù)位拉低時(shí)的同步導(dǎo)致復(fù)位信號(hào)在不同模塊間釋放時(shí)間不一致出現(xiàn)系統(tǒng)部分模塊已經(jīng)運(yùn)行、部分模塊還在復(fù)位的狀態(tài)。更隱蔽的情況是設(shè)計(jì)了復(fù)位同步邏輯但在Synplify綜合時(shí)沒(méi)有對(duì)復(fù)位信號(hào)設(shè)置合理的綜合屬性綜合器認(rèn)為復(fù)位信號(hào)上連接的同步邏輯是冗余的直接優(yōu)化掉了。排查這類問(wèn)題時(shí)先打開(kāi)Synplify的綜合報(bào)告查看復(fù)位信號(hào)是否被推斷為全局復(fù)位網(wǎng)絡(luò)以及復(fù)位同步器的寄存器是否被保留。然后在Vivado布局布線后使用時(shí)序分析工具查看復(fù)位釋放路徑的時(shí)序裕量。這兩個(gè)步驟能覆蓋大多數(shù)復(fù)位問(wèn)題。4.3 布局布線變紅并不全是時(shí)序問(wèn)題有一次一個(gè)工程跑完布局布線直接把路由資源用爆了Implement直接變紅。第一反應(yīng)是邏輯規(guī)模太大但仔細(xì)排查后發(fā)現(xiàn)問(wèn)題的根因不在邏輯規(guī)模而在時(shí)鐘資源分配不合理。問(wèn)題出在我用的是同步時(shí)鐘卻在RTL里通過(guò)時(shí)鐘分頻創(chuàng)造了多個(gè)派生時(shí)鐘。在Synplify綜合時(shí)這些派生時(shí)鐘被識(shí)別為獨(dú)立的時(shí)鐘網(wǎng)絡(luò)綜合器為每個(gè)時(shí)鐘網(wǎng)絡(luò)都預(yù)留了獨(dú)立的時(shí)鐘資源。在布局布線階段這些時(shí)鐘網(wǎng)絡(luò)爭(zhēng)搶全局時(shí)鐘資源最終導(dǎo)致布線擁塞。排查這個(gè)問(wèn)題的思路是通過(guò)Vivado的時(shí)鐘報(bào)告檢查所有時(shí)鐘網(wǎng)絡(luò)的物理資源使用情況。這種問(wèn)題在協(xié)同設(shè)計(jì)里很常見(jiàn)因?yàn)榫C合階段看到的是邏輯資源而布局布線階段才暴露物理資源沖突。解決辦法是在RTL里盡量減少邏輯分頻產(chǎn)生的時(shí)鐘改用FPGA的時(shí)鐘管理單元生成所需的時(shí)鐘這樣在綜合和布局布線時(shí)時(shí)鐘網(wǎng)絡(luò)規(guī)劃會(huì)更清晰。4.4 常用IP核的協(xié)同設(shè)計(jì)注意事項(xiàng)速查把幾種高頻使用的IP核在協(xié)同設(shè)計(jì)中的表現(xiàn)整理成一張速查表方便參考。IP核類型協(xié)同設(shè)計(jì)重點(diǎn)常見(jiàn)問(wèn)題解決思路Aurora 8B/10BGT復(fù)位與初始化邏輯鏈路無(wú)法建立、誤碼率高檢查復(fù)位接口保留約束GT時(shí)鐘和復(fù)位路徑FIFO IP核異步時(shí)鐘與復(fù)位處理數(shù)據(jù)錯(cuò)位、讀寫指針不同步約束跨時(shí)鐘域路徑確保復(fù)位同步釋放FFT IP核數(shù)據(jù)位寬與時(shí)序輸入時(shí)鐘受限、數(shù)據(jù)溢出在Vivado里配置位寬參數(shù)Synplify綜合時(shí)設(shè)置充分余量除法器IP核流水線結(jié)構(gòu)選擇延遲過(guò)大不滿足時(shí)序配置更高的流水線級(jí)數(shù)或改用并行結(jié)構(gòu)CAN-FD IP核多時(shí)鐘域同步總線數(shù)據(jù)錯(cuò)誤、幀丟失完善跨時(shí)鐘域握手邏輯SDC設(shè)置false_pathROM/RAM IP核初始化文件路徑仿真正常但綜合后數(shù)據(jù)丟失將初始化文件路徑改為相對(duì)路徑確保Synplify能正確讀取這張表里列的每一條都是我在實(shí)際項(xiàng)目中遇到過(guò)或者同事反饋過(guò)的真實(shí)問(wèn)題。ROM/RAM IP核初始化文件路徑這個(gè)問(wèn)題特別想多說(shuō)一句在Vivado中生成ROM IP核時(shí)如果指定的COE文件是通過(guò)絕對(duì)路徑引用的Synplify在綜合時(shí)可能因?yàn)檎也坏铰窂蕉^(guò)初始化導(dǎo)致生成的網(wǎng)表里帶了空的存儲(chǔ)內(nèi)容。上板之后表現(xiàn)出來(lái)的現(xiàn)象就是讀出來(lái)的數(shù)據(jù)全是0仿真階段卻一切正常。這個(gè)坑非常隱蔽排查手段只有去Synplify的網(wǎng)表文件里檢查存儲(chǔ)器的初始化內(nèi)容。4.5 綜合面積與布局布線優(yōu)化的小技巧綜合面積和布局布線優(yōu)化是FPGA工程師的必修課。在協(xié)同設(shè)計(jì)流程里兩者的優(yōu)化手段有一些不同。綜合階段Synplify提供了多種綜合選項(xiàng)比如自動(dòng)寄存器復(fù)制、資源共享、有限狀態(tài)機(jī)重新編碼等。開(kāi)啟這些選項(xiàng)可以優(yōu)化面積和時(shí)序。但開(kāi)啟之后一定要對(duì)比綜合報(bào)告因?yàn)橛行┻x項(xiàng)對(duì)特定設(shè)計(jì)反而有害。比如資源共享在數(shù)據(jù)通路上通常有效但在控制邏輯上可能增加布線延遲反而讓時(shí)序變差。所以綜合選項(xiàng)不是開(kāi)得越多越好而是要在每個(gè)工程里試驗(yàn)后確定最優(yōu)組合。布局布線階段Vivado提供的物理優(yōu)化手段相對(duì)較少但有一個(gè)技巧很實(shí)用在綜合階段保留層次化結(jié)構(gòu)。也就是說(shuō)讓Synplify在綜合時(shí)不要做全局扁平化而是保留模塊的層次邊界。這樣做的好處是在布局布線階段Vivado可以根據(jù)模塊邊界做更合理的物理布局避免邏輯碎片化。Synplify里有類似“Flatten”的選項(xiàng)建議保持關(guān)閉。還有一個(gè)細(xì)節(jié)容易被忽視FFT或?yàn)V波類IP核的輸入輸出位寬問(wèn)題。FPGA圖像處理里經(jīng)常要算定點(diǎn)數(shù)如果IP核配置的是浮點(diǎn)接口在Synplify綜合時(shí)很可能無(wú)法正確映射到DSP48資源造成資源和時(shí)序的浪費(fèi)。這種情況下的做法是在RTL層做定點(diǎn)數(shù)轉(zhuǎn)換IP核接口統(tǒng)一用定點(diǎn)數(shù)。我在圖像處理工程里吃過(guò)這個(gè)虧后來(lái)統(tǒng)一改定點(diǎn)數(shù)接口DSP48利用率從55%降到了30%左右時(shí)序收斂也輕松了不少。4.6 高速接口與專用硬核的處理建議帶Aurora、LVDS、QSPI這類高速接口的工程在協(xié)同設(shè)計(jì)里有一些特殊的處理建議。高速收發(fā)器接口的RTL邏輯和普通邏輯不同它們依賴于FPGA內(nèi)部的專用硬核資源比如收發(fā)器通道、高速時(shí)鐘管理單元等。在Synplify綜合時(shí)這些硬核資源不會(huì)被綜合成查找表和觸發(fā)器而是保持為原語(yǔ)實(shí)例。所以RTL代碼里必須使用Xilinx提供的原語(yǔ)模塊比如Aurora IP核內(nèi)部已經(jīng)封裝好了這些原語(yǔ)。RTL代碼里直接實(shí)例化這些IP核Synplify綜合時(shí)會(huì)把它們當(dāng)作黑盒處理。這個(gè)黑盒處理方式帶來(lái)了一個(gè)問(wèn)題黑盒接口的時(shí)序無(wú)法在綜合階段預(yù)估。解決思路是在SDC里手動(dòng)為這些黑盒接口設(shè)置合理的輸入輸出延遲讓綜合器有一個(gè)明確的時(shí)序目標(biāo)。否則綜合器會(huì)認(rèn)為這些路徑?jīng)]有時(shí)序約束優(yōu)化時(shí)直接跳過(guò)到了Vivado布局布線階段才暴露時(shí)序問(wèn)題而這時(shí)候修改RTL的代價(jià)已經(jīng)很大了。LVDS接口的協(xié)同處理相對(duì)簡(jiǎn)單主要關(guān)注數(shù)據(jù)對(duì)齊和位滑移控制邏輯。這類邏輯通常在RTL中實(shí)現(xiàn)通過(guò)例化Xilinx的LVDS收發(fā)原語(yǔ)完成。在Synplify綜合時(shí)保持原語(yǔ)實(shí)例不被優(yōu)化是關(guān)鍵可以用綜合屬性來(lái)標(biāo)記這些原語(yǔ)。QSPI接口如果涉及Flash配置和Multiboot功能在協(xié)同設(shè)計(jì)流程中沒(méi)有額外負(fù)擔(dān)但有一點(diǎn)要和綜合工具強(qiáng)調(diào)QSPI接口相關(guān)的時(shí)序約束通常是寬松的建議在SDC中設(shè)置成set_false_path或者較寬松的multicycle path避免給布局布線工具增加不必要的約束難度。5. 協(xié)同設(shè)計(jì)的效率提升與團(tuán)隊(duì)協(xié)作流程跑通之后下一步就是優(yōu)化效率特別是團(tuán)隊(duì)多人協(xié)同時(shí)。這一節(jié)分享腳本化、自動(dòng)化方面的實(shí)踐以及多人協(xié)作時(shí)容易忽略的細(xì)節(jié)。5.1 用腳本把重復(fù)勞動(dòng)自動(dòng)化協(xié)同設(shè)計(jì)流程里重復(fù)性的操作很多打開(kāi)工具、添加文件、設(shè)置約束、跑綜合、跑布局布線這些可以通過(guò)腳本一口氣完成。Synplify支持通過(guò)命令行方式運(yùn)行工程也支持使用Tcl腳本。在工程穩(wěn)定之后把綜合流程腳本化每次修改RTL后只需要運(yùn)行一條命令就能完成綜合。記得把綜合次數(shù)、綜合時(shí)間、時(shí)序結(jié)果輸出到日志文件里方便追溯。Vivado側(cè)同樣支持Tcl腳本。布局布線的腳本化需要注意一點(diǎn)每次運(yùn)行前清空之前的布局布線結(jié)果目錄否則可能因?yàn)榇嬖跉埩粑募?dǎo)致流程異常。腳本化還有一個(gè)附加好處CI集成。如果在服務(wù)器上建立了自動(dòng)化流程每次代碼提交后自動(dòng)跑一遍綜合加布局布線團(tuán)隊(duì)每個(gè)人都能在第一時(shí)間看到自己修改對(duì)時(shí)序和資源的影響。這個(gè)能力對(duì)多人協(xié)作的FPGA團(tuán)隊(duì)價(jià)值巨大能顯著減少集成階段的沖突和返工。5.2 IP核版本與參數(shù)凍結(jié)的協(xié)作規(guī)范團(tuán)隊(duì)協(xié)作中最頭疼的問(wèn)題之一就是IP核版本和參數(shù)不統(tǒng)一。兩個(gè)人同時(shí)改一個(gè)IP核的參數(shù)互相不知道最后集成到一起直接亂套。協(xié)同設(shè)計(jì)流程能夠天然緩解這個(gè)問(wèn)題因?yàn)镮P核統(tǒng)一在Vivado中生成只要約定好IP核的配置基線在版本管理上鎖定IP核的配置文件所有成員都從同一個(gè)基線生成IP核就不會(huì)出現(xiàn)版本漂移。具體操作上建議在Git中為每個(gè)IP核建立一個(gè)配置文件跟蹤機(jī)制。IP核的參數(shù)配置通常保存在一個(gè)配置文件里這個(gè)文件用文本格式記錄便于diff和版本比較。每個(gè)IP核參數(shù)變更都需要通過(guò)Merge Request流程由專人review合并后才允許團(tuán)隊(duì)成員更新本地IP核。這個(gè)規(guī)范在Aurora這類復(fù)雜IP核上尤其重要。Aurora IP核的配置參數(shù)有幾十個(gè)包括線速率、通道數(shù)量、數(shù)據(jù)位寬、流控模式等任何一個(gè)參數(shù)不一致都會(huì)導(dǎo)致鏈路互連異常。把規(guī)范前置到IP核配置階段能節(jié)省大量聯(lián)調(diào)時(shí)間。5.3 時(shí)序報(bào)告與設(shè)計(jì)評(píng)審該看哪些關(guān)鍵指標(biāo)周期性地做設(shè)計(jì)評(píng)審是保證工程健康度的關(guān)鍵手段。在協(xié)同設(shè)計(jì)流程里評(píng)審時(shí)重點(diǎn)看幾個(gè)指標(biāo)綜合后的時(shí)序報(bào)告、布局布線后的時(shí)序差異、資源利用率變化趨勢(shì)、以及DRC報(bào)告中的警告數(shù)量。綜合后時(shí)序報(bào)告和布局布線后時(shí)序差異是重點(diǎn)。如果Synplify綜合后顯示時(shí)序滿足要求但Vivado布局布線后大量路徑不滿足說(shuō)明綜合階段的時(shí)序預(yù)估和實(shí)際物理實(shí)現(xiàn)偏差過(guò)大。這通常意味著SDC約束設(shè)置有問(wèn)題比如時(shí)鐘定義不完整、輸入輸出延遲設(shè)置不合理等。反過(guò)來(lái)如果綜合階段就報(bào)告時(shí)序違規(guī)那問(wèn)題更大概率在RTL邏輯本身。資源利用率的變化趨勢(shì)也值得關(guān)注。如果每輪迭代資源都在漲需要及時(shí)定位是什么邏輯引起的。有些邏輯膨脹是正常的比如增加了新的功能模塊有些則是綜合策略導(dǎo)致的比如代碼風(fēng)格不合適、模塊復(fù)用不當(dāng)?shù)?。早發(fā)現(xiàn)早優(yōu)化總比到最后快收尾時(shí)發(fā)現(xiàn)資源不夠要強(qiáng)。DRC報(bào)告里的警告類型盡量清零。DRC警告雖然不會(huì)直接導(dǎo)致功能錯(cuò)誤但往往是隱患的信號(hào)。一個(gè)不完整的I/O約束、一個(gè)未使用的時(shí)鐘域都可能在某個(gè)特定條件下變成真正的bug。建議每個(gè)迭代周期都目標(biāo)性地清理DRC警告保持工程健康。5.4 調(diào)試手段從Vivado到硬件的閉環(huán)帶IP核的工程上板調(diào)試是繞不開(kāi)的環(huán)節(jié)。Synplify和Vivado協(xié)同設(shè)計(jì)流程中調(diào)試手段需要和純Vivado流程有所區(qū)分。一個(gè)重要區(qū)別是Synplify綜合后的網(wǎng)表在Vivado里是黑盒狀態(tài)。使用Vivado的ILA調(diào)試核時(shí)需要注意信號(hào)的可觀測(cè)性。ILA核的探針信號(hào)需要在綜合時(shí)保留但在Synplify綜合的網(wǎng)表里很多內(nèi)部信號(hào)可能已經(jīng)被優(yōu)化或重命名無(wú)法直接作為ILA探針。解決辦法是在RTL里用綜合屬性標(biāo)記需要保留的信號(hào)比如標(biāo)記為keep或mark_debug。另一個(gè)調(diào)試手段是使用Vivado的邏輯分析儀功能但前提是網(wǎng)表中的信號(hào)層次清晰。這就回應(yīng)了之前說(shuō)的保留層次化結(jié)構(gòu)的重要性。如果Synplify綜合時(shí)把層次打平了Vivado的邏輯分析儀根本無(wú)法定位到具體信號(hào)調(diào)試就會(huì)變得非常困難。上板階段比特流生成和固話操作本身和純Vivado流程沒(méi)有區(qū)別。QSPI Flash的燒寫、Multiboot配置、固化程序的生成這些操作在Vivado硬件管理器中完成。唯一要注意的是固話用的比特流必須和最終驗(yàn)證通過(guò)的布局布線結(jié)果一致不要在最后關(guān)頭為了省時(shí)間用舊比特流。6. 從經(jīng)驗(yàn)到方法論我的幾點(diǎn)體會(huì)最后談幾點(diǎn)比較主觀的體會(huì)是我做完幾個(gè)協(xié)同設(shè)計(jì)項(xiàng)目后沉淀下來(lái)的想法。第一工具鏈的選擇要服務(wù)于迭代效率而不是服務(wù)于“用上了新工具”的成就感。現(xiàn)在很多項(xiàng)目上來(lái)就要用最新的Vivado版本貪圖新特性但對(duì)于一個(gè)已經(jīng)跑得很穩(wěn)的工程升級(jí)工具鏈并帶來(lái)直接的收益反而平添變量。協(xié)同設(shè)計(jì)同樣如此如果你的工程規(guī)模不大、時(shí)序不緊用Vivado一條龍完全夠了不必強(qiáng)行上Synplify。我見(jiàn)過(guò)一些團(tuán)隊(duì)為了追求協(xié)同設(shè)計(jì)而協(xié)同設(shè)計(jì)結(jié)果在IP核版本兼容上花費(fèi)了大量時(shí)間反而降低了效率。第二時(shí)序問(wèn)題的根因90%在RTL設(shè)計(jì)層面工具能做的只是錦上添花。經(jīng)過(guò)多個(gè)工程的數(shù)據(jù)積累我發(fā)現(xiàn)長(zhǎng)期無(wú)法收斂的時(shí)序問(wèn)題深層原因基本都是邏輯鏈路過(guò)長(zhǎng)、跨時(shí)鐘域處理不當(dāng)、復(fù)位設(shè)計(jì)混亂這類RTL問(wèn)題。Synplify的時(shí)序預(yù)估能力和Vivado的布局布線優(yōu)化只能緩解表面癥狀真正解決問(wèn)題的路徑是審視設(shè)計(jì)本身。所以在跑工具之前先把RTL代碼評(píng)審一遍把能預(yù)見(jiàn)的時(shí)序問(wèn)題提前消化掉。第三個(gè)人比較推薦的做法是把Synplify的快速綜合當(dāng)作設(shè)計(jì)過(guò)程中的日常檢查手段。不一定要把協(xié)同設(shè)計(jì)作為最終交付流程但在RTL開(kāi)發(fā)階段每完成一個(gè)模塊就丟進(jìn)Synplify快速綜合一次看看資源占用和時(shí)序預(yù)估。這個(gè)習(xí)慣能讓你在開(kāi)發(fā)的早期就發(fā)現(xiàn)很多問(wèn)題而不是等整個(gè)工程集成完才發(fā)現(xiàn)某個(gè)模塊把整塊邏輯拖垮了。這個(gè)習(xí)慣養(yǎng)成之后你會(huì)發(fā)現(xiàn)后期布局布線的迭代次數(shù)大大減少。第四PDCA的思路用在FPGA工程管理上同樣適用。每完成一個(gè)迭代周期記錄下這一輪的時(shí)序結(jié)果、資源使用、DRC報(bào)告、遇到的問(wèn)題和解決方法。積累三輪之后回看你會(huì)發(fā)現(xiàn)問(wèn)題集中在哪幾個(gè)方面然后有針對(duì)性的在RTL設(shè)計(jì)規(guī)范、約束文件管理、IP核配置這些環(huán)節(jié)做標(biāo)準(zhǔn)化改進(jìn)。寫到這里這套基于Synplify與Vivado協(xié)同設(shè)計(jì)處理帶IP核FPGA工程的方法基本已經(jīng)完整鋪開(kāi)了。無(wú)論是流程組織、IP核管理、約束處理還是時(shí)序收斂和團(tuán)隊(duì)協(xié)作最終的目標(biāo)都是讓FPGA開(kāi)發(fā)變得更可預(yù)測(cè)、更高效。我用這套流程完成了多個(gè)項(xiàng)目的交付每一次迭代優(yōu)化都在不斷印證同一條經(jīng)驗(yàn)工具鏈只是手段真正決定項(xiàng)目成敗的還是對(duì)設(shè)計(jì)本身的理解和對(duì)流程細(xì)節(jié)的堅(jiān)持。希望這篇基于實(shí)際項(xiàng)目踩坑經(jīng)驗(yàn)寫下的文章能在你構(gòu)建或優(yōu)化自己的FPGA開(kāi)發(fā)流程時(shí)提供一些真正有用的參考。 Synplify與Vivado協(xié)同設(shè)計(jì)：FPGA帶IP核工程的時(shí)序收斂與效率優(yōu)化
做過(guò)大型FPGA工程的朋友應(yīng)該都有過(guò)這種體驗(yàn)RTL寫起來(lái)很快真正折磨人的是綜合布局布線那動(dòng)輒幾個(gè)小時(shí)的等待以及怎么調(diào)都收不攏的時(shí)序。我?guī)н^(guò)好幾版帶高速接口和復(fù)雜IP核的工程早期全部壓在Vivado一條流水線里每次迭代都像在熬鷹。后來(lái)切換到Synplify與Vivado協(xié)同設(shè)計(jì)的流程綜合時(shí)間縮短了將近一半時(shí)序收斂的迭代次數(shù)也明顯減少。這篇文章就圍繞這套協(xié)同設(shè)計(jì)方法聊聊帶IP核的FPGA工程到底該怎么組織、怎么跑通、有哪些坑必須避開(kāi)。這套流程的核心價(jià)值在于讓專業(yè)工具干專業(yè)的事Synplify負(fù)責(zé)邏輯綜合和時(shí)序預(yù)估Vivado只專注在布局布線和最終實(shí)現(xiàn)上。對(duì)于使用Aurora、CAN-FD、FFT、除法器等IP核的工程尤其是圖像處理、信號(hào)發(fā)生器、串口升級(jí)這些需要反復(fù)迭代的項(xiàng)目這套協(xié)同設(shè)計(jì)帶來(lái)的收益非?？捎^。不管你是在校學(xué)生做FPGA入門課設(shè)還是工程師在推進(jìn)量產(chǎn)級(jí)項(xiàng)目下面這些基于實(shí)際項(xiàng)目踩坑總結(jié)出來(lái)的流程和心得都能直接用得上。1. 為什么在Vivado時(shí)代還要用Synplify做綜合先解決一個(gè)最常見(jiàn)的疑問(wèn)Vivado自帶綜合引擎已經(jīng)很成熟了為什么還要繞一圈用Synplify綜合完再導(dǎo)回Vivado布局布線這個(gè)問(wèn)題的答案要從綜合這個(gè)環(huán)節(jié)的本質(zhì)說(shuō)起。1.1 Synplify的差異化優(yōu)勢(shì)到底在哪里綜合的本質(zhì)是把RTL代碼翻譯成由查找表和觸發(fā)器構(gòu)成的網(wǎng)表。Vivado自帶綜合器在標(biāo)準(zhǔn)流程下表現(xiàn)不錯(cuò)但Synplify在幾個(gè)關(guān)鍵維度上有明顯優(yōu)勢(shì)。首先是綜合策略的成熟度。Synplify在FPGA領(lǐng)域耕耘了二十多年它的有限狀態(tài)機(jī)優(yōu)化、資源共享、retiming這些算法經(jīng)過(guò)大量工業(yè)級(jí)項(xiàng)目的打磨綜合出來(lái)的網(wǎng)表在面積和頻率上通常比默認(rèn)綜合結(jié)果更好。其次是綜合速度。我?guī)н^(guò)一個(gè)包含DDR控制器、PCIe硬核和視頻處理邏輯的工程RTL代碼量大概在十幾萬(wàn)行Vivado默認(rèn)綜合需要跑三四十分鐘Synplify在相同機(jī)器上十分鐘左右就能跑完。這個(gè)速度差異在頻繁修改RTL做驗(yàn)證的階段非常寶貴每次綜合省二十分鐘一天迭代十幾輪省出來(lái)的時(shí)間相當(dāng)可觀。第三是跨平臺(tái)和版本迭代的靈活性。Synplify可以獨(dú)立于Vivado版本運(yùn)行對(duì)于使用多種FPGA平臺(tái)的團(tuán)隊(duì)統(tǒng)一用Synplify做綜合可以保證綜合結(jié)果的一致性不會(huì)因?yàn)閂ivado版本更新導(dǎo)致綜合策略變化。這一點(diǎn)在團(tuán)隊(duì)協(xié)作中常被忽視但實(shí)際影響很大。第四個(gè)優(yōu)勢(shì)也是我覺(jué)得最關(guān)鍵的一點(diǎn)是Synplify對(duì)時(shí)序的早期預(yù)估能力。它在綜合階段就能依據(jù)物理約束做粗略的時(shí)序估算告訴你哪條路徑可能時(shí)序緊張。這意味著時(shí)序問(wèn)題可以在綜合階段就暴露出來(lái)而不是等到布局布線跑完才被一通亂報(bào)嚇一跳。1.2 什么樣的工程適合走協(xié)同設(shè)計(jì)流程不是所有工程都需要Synplify和Vivado協(xié)同設(shè)計(jì)。我總結(jié)下來(lái)具備以下特征的工程比較適合走這套流程。首先是IP核數(shù)量多、類型復(fù)雜的工程。比如用到Aurora 8B/10B高速收發(fā)器、CAN-FD控制器、各類DSP IP核的工程IP核的綜合結(jié)果直接影響整體時(shí)序Synplify對(duì)IP核網(wǎng)表的處理更加精細(xì)。特別是使用Xilinx的Aurora IP它的GT復(fù)位邏輯和時(shí)鐘結(jié)構(gòu)非常復(fù)雜用Synplify綜合時(shí)對(duì)復(fù)位和時(shí)鐘樹的處理更容易滿足要求。其次是邏輯規(guī)模大、時(shí)序約束緊的工程。當(dāng)工程資源利用率超過(guò)60%或者主頻要求接近器件極限時(shí)綜合質(zhì)量對(duì)布局布線的影響會(huì)急劇放大。Synplify綜合出的網(wǎng)表質(zhì)量在這種場(chǎng)景下更穩(wěn)定。第三是需要頻繁迭代RTL邏輯的項(xiàng)目。比如FPGA圖像處理算法調(diào)試階段經(jīng)常要改幾行代碼就跑一次綜合看效果。用Synplify做綜合等于把整個(gè)迭代周期壓縮了。1.3 什么時(shí)候不建議用協(xié)同設(shè)計(jì)說(shuō)句公道話Synplify也不是萬(wàn)能的。如果你的工程只用了一兩個(gè)標(biāo)準(zhǔn)IP核邏輯規(guī)模也不大直接用Vivado一條龍反而更省事。原因很簡(jiǎn)單多一個(gè)工具就多一層銜接成本EDIF網(wǎng)表的生成、約束文件的轉(zhuǎn)換、IP核的重新定位每一步都可能引入新的問(wèn)題。另外如果工程大量依賴Vivado獨(dú)有的綜合特性比如使用Vivado的自動(dòng)流水線插入、全局時(shí)鐘緩存優(yōu)化等那強(qiáng)行套用Synplify反而可能丟掉這些優(yōu)化機(jī)會(huì)。我在實(shí)際中遇到過(guò)類似情況某個(gè)工程大量使用Vivado的宏和綜合屬性Synplify綜合后功能雖然正確但性能和資源比Vivado直接綜合差了不少。所以協(xié)同設(shè)計(jì)是一個(gè)可選工具不是一個(gè)必選流程。明確這一點(diǎn)后面做方案選型思路會(huì)清晰很多。2. 協(xié)同設(shè)計(jì)的整體思路與工程組織如果決定走協(xié)同設(shè)計(jì)先別急著開(kāi)工具花點(diǎn)時(shí)間把工程結(jié)構(gòu)理清楚。協(xié)同設(shè)計(jì)最怕的就是兩個(gè)工具各管一段、接口混亂。下面這套工程組織方式是我在多個(gè)項(xiàng)目里驗(yàn)證過(guò)的能夠有效減少銜接階段的低級(jí)錯(cuò)誤。2.1 雙工具流水線的核心流程協(xié)同設(shè)計(jì)的核心流水線說(shuō)白了就是四個(gè)環(huán)節(jié)IP核生成、邏輯綜合、網(wǎng)表交付、布局布線。整個(gè)流程中設(shè)計(jì)源文件只有一個(gè)來(lái)源所有RTL代碼統(tǒng)一維護(hù)IP核統(tǒng)一在Vivado中生成Synplify只做綜合和網(wǎng)表輸出最后的布局布線又回到Vivado完成。這種流水線里最需要嚴(yán)格管控的是IP核。很多項(xiàng)目習(xí)慣在Vivado里生成IP核后直接例化使用但在協(xié)同設(shè)計(jì)流程里IP核文件需要分兩路走一路是RTL仿真模型給仿真用另一路是綜合網(wǎng)表交給Synplify做綜合。如果IP核版本沒(méi)對(duì)齊很容易出現(xiàn)仿真通過(guò)但綜合后功能對(duì)不上的情況。2.2 IP核在哪里生成與維護(hù)聽(tīng)過(guò)一種說(shuō)法說(shuō)協(xié)同設(shè)計(jì)要把IP核拿到Synplify里去生成這個(gè)說(shuō)法并不準(zhǔn)確。Synplify對(duì)Xilinx IP核的處理方式是“讀入并識(shí)別”不是“生成”。IP核本身必須由Vivado生成Synplify做的是把IP核的網(wǎng)表文件讀入到綜合流程中和用戶邏輯一起進(jìn)行綜合優(yōu)化。具體操作時(shí)每個(gè)IP核在Vivado中生成后會(huì)附帶一個(gè)工程文件里面包含IP核的所有配置參數(shù)和生成文件列表。在Synplify中需要將這個(gè)工程文件或者IP核的網(wǎng)表文件添加到工程里。以Vivado生成一個(gè)FIFO IP核為例生成完成后要把IP核的輸出網(wǎng)表文件通常是NGC或EDIF格式以及相關(guān)的約束文件都納入工程管理。這里有一個(gè)容易踩坑的點(diǎn)。Vivado不同版本生成的IP核文件格式可能不一樣。使用較老版本IP核時(shí)生成的是NGC格式用新版Vivado生成時(shí)可能輸出的是EDIF或其他格式。Synplify對(duì)這兩種格式的支持程度不同導(dǎo)致綜合結(jié)果也會(huì)不同。我踩過(guò)這個(gè)坑同一個(gè)DDR控制器IP核在Vivado 2018.2版本下生成后Synplify綜合沒(méi)問(wèn)題換到Vivado 2020.2生成后Synplify綜合直接報(bào)錯(cuò)原因是網(wǎng)表格式和約束文件的兼容性問(wèn)題。解決方案是查Synplify版本對(duì)應(yīng)的Xilinx IP核支持列表必要時(shí)做版本匹配。2.3 工程目錄與版本管理的幾點(diǎn)建議協(xié)同設(shè)計(jì)工程的目錄組織直接決定了交接效率。推薦用下面的結(jié)構(gòu)組織工程文件rtl/存放所有RTL源碼包括頂層、子模塊和IP核的例化文件ip/存放Vivado生成的所有IP核文件按IP核名稱分子目錄syn/存放Synplify工程文件、綜合腳本和綜合結(jié)果constraints/存放時(shí)序約束和物理約束文件impl/存放Vivado布局布線工程、比特流和調(diào)試文件sim/存放仿真測(cè)試文件和波形這套結(jié)構(gòu)有兩點(diǎn)好處。一是職責(zé)清晰每個(gè)工具都有自己的工作目錄不會(huì)互相污染二是方便腳本化后續(xù)要跑自動(dòng)化回歸只需要在syn/目錄下執(zhí)行綜合腳本再到impl/目錄下執(zhí)行布局布線腳本不用到處找文件。版本管理方面建議把所有源文件納入Git管理但生成文件不要提交。尤其是Synplify生成的各種中間網(wǎng)表文件體積大且每次綜合都會(huì)變化提交到Git里只會(huì)帶來(lái)無(wú)盡的沖突和倉(cāng)庫(kù)膨脹。IP核的生成文件原則上也不提交團(tuán)隊(duì)協(xié)作時(shí)每個(gè)人都應(yīng)該有自己的本地IP核生成路徑提交ip/目錄下的IP核配置描述文件即可。2.4 工具版本匹配的注意事項(xiàng)版本匹配問(wèn)題在協(xié)同設(shè)計(jì)里被討論得最多也是最容易被忽視的。Synplify和Vivado的版本如果不匹配輕則綜合結(jié)果不理想重則直接無(wú)法識(shí)別IP核或報(bào)錯(cuò)中斷。這里分享一個(gè)務(wù)實(shí)的匹配策略不要追求版本完全對(duì)應(yīng)而是以Synplify的IP核支持清單為準(zhǔn)。每次Synplify發(fā)布新版本都會(huì)附帶一個(gè)詳細(xì)的支持列表標(biāo)明該版本支持哪些廠商的哪些器件型號(hào)以及IP核的哪些版本。在開(kāi)始一個(gè)項(xiàng)目之前先確定Synplify版本再根據(jù)支持列表選擇Vivado版本。比如如果你用的Synplify版本明確支持Vivado 2020.2生成的IP核那就統(tǒng)一用Vivado 2020.2不要團(tuán)隊(duì)里有人用2019.1、有人用2021.1。還有一點(diǎn)IDEA模式下的IP核管理。Synplify通過(guò)IP核識(shí)別時(shí)需要指定IP核的生成目錄。這些目錄在Vivado中生成IP核時(shí)是絕對(duì)路徑換一臺(tái)機(jī)器就失效了。所以協(xié)同設(shè)計(jì)通常要打開(kāi)Synplify的“Use Relative Paths”之類的選項(xiàng)讓工程相對(duì)路徑化這樣才能保證在不同機(jī)器上都能打開(kāi)工程。這個(gè)細(xì)節(jié)在團(tuán)隊(duì)協(xié)作中非常關(guān)鍵解決不了這個(gè)每次換機(jī)器都要重新指定一遍IP核路徑非常痛苦。3. 實(shí)操流程從RTL到比特流的完整鏈路理論說(shuō)了一大堆接下來(lái)進(jìn)入實(shí)操環(huán)節(jié)。這個(gè)部分我會(huì)按照完整流程逐步拆解從IP核生成、Synplify綜合、約束處理到Vivado布局布線每一步都給出可以直接操作的方法。3.1 第一步在Vivado里生成和配置IP核在Vivado中生成IP核是協(xié)同設(shè)計(jì)的起點(diǎn)。具體操作是在Vivado中新建一個(gè)IP核或打開(kāi)已有的IP核工程配置好參數(shù)后生成輸出文件。這里有幾個(gè)參數(shù)需要額外注意。首先是IP核的輸出文件格式盡量選擇EDIF或NGC格式作為綜合網(wǎng)表輸出。在Vivado的IP核自定義設(shè)置中通常有輸出產(chǎn)品選項(xiàng)比如綜合網(wǎng)表、仿真模型、約束文件等。在協(xié)同設(shè)計(jì)流程里綜合網(wǎng)表中的EDIF文件是Synplify做綜合時(shí)主要使用的文件。其次是IP核的約束文件處理。Vivado為每個(gè)IP核生成的約束文件包括引腳約束、時(shí)序約束和區(qū)域約束。這些約束文件在協(xié)同設(shè)計(jì)中需要統(tǒng)一收集后續(xù)交給Synplify或者Vivado使用。比較穩(wěn)妥的做法是在生成IP核時(shí)設(shè)置輸出約束文件到一個(gè)特定目錄比如放在constraints/ip目錄下后續(xù)統(tǒng)一處理。第三是復(fù)位和高電平有效這類配置選項(xiàng)。Aurora IP核里關(guān)于GT復(fù)位、power_down的配置和CAN-FD IP核的中斷配置直接決定了后續(xù)RTL邏輯的接口語(yǔ)義。務(wù)必在Vivado配置階段把每個(gè)接口搞清楚否則后面到了Synplify里要根據(jù)IP核接口改RTL那代價(jià)就大了。3.2 第二步Synplify綜合與約束傳遞IP核準(zhǔn)備妥當(dāng)后打開(kāi)Synplify新建一個(gè)綜合工程。RTL源碼的添加方式很直接把所有.v或者.vhd文件加進(jìn)工程。這里有個(gè)小建議把RTL文件按模塊分目錄管理添加到Synplify工程時(shí)也保持同樣的目錄層級(jí)這樣綜合報(bào)告定位模塊時(shí)會(huì)更直觀。IP核的添加方式有兩種。一種是直接把Vivado生成的EDIF網(wǎng)表文件作為輸入添加進(jìn)去另一種是使用Synplify的IP核管理功能。兩種方式在普通工程中差別不大但對(duì)于包含大量IP核的工程第二種方式更推薦因?yàn)镾ynplify能自動(dòng)識(shí)別IP核之間的依賴關(guān)系并且能正確讀取IP核的約束文件。約束文件的處理是協(xié)同設(shè)計(jì)的核心環(huán)節(jié)之一。Vivado工程使用XDC格式的約束而Synplify綜合時(shí)使用SDC格式的約束。這兩個(gè)約束格式并不完全等價(jià)XDC中包含的大量物理約束和時(shí)序例外在SDC中都無(wú)法完整表達(dá)。操作上可以這樣處理在Synplify中設(shè)置時(shí)序約束時(shí)只設(shè)置核心的時(shí)鐘周期、輸入輸出延遲等基礎(chǔ)約束用于指導(dǎo)綜合器做時(shí)序優(yōu)化而物理約束和詳細(xì)的時(shí)序例外則保留在XDC中等網(wǎng)表交付給Vivado后讓布局布線工具去處理。在綜合屬性設(shè)置上有幾點(diǎn)經(jīng)驗(yàn)值可以參考。對(duì)于目標(biāo)頻率建議把約束的時(shí)鐘周期設(shè)置得比實(shí)際需求略嚴(yán)格一些預(yù)留5%到10%的余量。這個(gè)“超頻設(shè)約束”的做法是因?yàn)镾ynplify綜合階段的時(shí)序估算和最終布局布線的真實(shí)延遲存在偏差留出余量可以避免網(wǎng)表交到Vivado后大量路徑違反時(shí)序。頻率策略選擇“Performance Balanced”這個(gè)選項(xiàng)在面積和速度之間相對(duì)均衡適合大多數(shù)工程。映射選項(xiàng)方面如果資源足夠可以嘗試開(kāi)啟“Use Full Mapping”或類似的選項(xiàng)讓綜合器做更充分的邏輯優(yōu)化。完成約束設(shè)置后點(diǎn)擊綜合按鈕開(kāi)始綜合。綜合完成后重點(diǎn)看三個(gè)方面時(shí)序報(bào)告中的最差負(fù)時(shí)序裕量、資源利用率報(bào)告、以及警告信息。如果最差負(fù)時(shí)序裕量為負(fù)說(shuō)明存在路徑不滿足時(shí)序要求需要回到RTL層或約束層做優(yōu)化。資源利用率方面如果查找表或觸發(fā)器使用率超過(guò)70%需要檢查是否存在冗余邏輯或優(yōu)化空間。警告信息里經(jīng)常包含未連接端口、多驅(qū)動(dòng)信號(hào)等潛在問(wèn)題建議逐條查看不要直接忽略。3.3 第三步把EDIF網(wǎng)表交還給Vivado布局布線Synplify綜合完成后會(huì)輸出多種文件其中最核心的是EDIF格式的網(wǎng)表文件。在Synplify工程中將綜合結(jié)果導(dǎo)出為EDIF網(wǎng)表這就是交給Vivado做布局布線的源文件。在Vivado側(cè)新建一個(gè)工程器件型號(hào)必須和Synplify綜合時(shí)選的型號(hào)一致否則在導(dǎo)入網(wǎng)表時(shí)會(huì)報(bào)錯(cuò)。工程的RTL源碼不需要再添加了因?yàn)镾ynplify已經(jīng)綜合成了網(wǎng)表Vivado只需要網(wǎng)表文件和約束文件就能完成布局布線。導(dǎo)入EDIF網(wǎng)表后還需要添加同步生成的約束文件。建議把XDC約束文件中的時(shí)序約束包括時(shí)鐘定義、輸入輸出延遲等和物理管腳約束都加進(jìn)去。如果約束文件之前在Synplify里同步做過(guò)設(shè)置這里需要注意避免約束重復(fù)。一個(gè)常見(jiàn)問(wèn)題是同樣的時(shí)鐘約束在SDC和XDC里各定義了一次導(dǎo)致Vivado布局布線時(shí)報(bào)告約束沖突。解決辦法是在Synplify綜合時(shí)不導(dǎo)出時(shí)序約束文件只保留物理管腳約束在XDC中時(shí)序約束統(tǒng)一在Vivado側(cè)管理。但如果不熟悉兩邊的約束分工更穩(wěn)妥的做法是在Vivado側(cè)只保留管腳約束和物理約束時(shí)序約束全部從Synplify導(dǎo)入后在Vivado中重新生成和審查。導(dǎo)入完成后運(yùn)行布局布線。如果一切正常會(huì)生成比特流文件可直接用于硬件調(diào)試或固件發(fā)布。到這里Synplify和Vivado協(xié)同設(shè)計(jì)的基本流程就走通了。3.4 第四步時(shí)序收斂與設(shè)計(jì)迭代布局布線完成后第一件事不是急著生成比特流而是打開(kāi)時(shí)序報(bào)告查看最差負(fù)時(shí)序裕量和總負(fù)時(shí)序裕量這兩個(gè)關(guān)鍵指標(biāo)。如果時(shí)序違規(guī)嚴(yán)重先回Synplify調(diào)整綜合約束不要直接在Vivado里硬調(diào)布局布線選項(xiàng)。這是因?yàn)椴季植季€層面的優(yōu)化手段有限能做的無(wú)非是改變布局策略、優(yōu)化時(shí)鐘樹等效果往往不理想。而回到綜合階段可以通過(guò)調(diào)整約束、修改RTL流水線結(jié)構(gòu)、調(diào)整寄存器復(fù)制策略等方式從源頭解決問(wèn)題。我在多次實(shí)踐中發(fā)現(xiàn)時(shí)序違規(guī)的根因大多數(shù)在RTL設(shè)計(jì)層面比如組合邏輯鏈路過(guò)長(zhǎng)、復(fù)位邏輯時(shí)序不滿足、跨時(shí)鐘域路徑約束不當(dāng)?shù)?。?dāng)Synplify綜合后的時(shí)序報(bào)告顯示最差負(fù)時(shí)序裕量為正但Vivado布局布線后出現(xiàn)少量違規(guī)時(shí)可以嘗試在Vivado中調(diào)節(jié)布局布線策略。將布局布線模式設(shè)為Explore或者嘗試PerformanceExplore這些策略通過(guò)嘗試不同的布線算法組合來(lái)優(yōu)化時(shí)序。但要注意這些策略會(huì)顯著增加運(yùn)行時(shí)間建議在集中收尾階段使用。時(shí)序收斂達(dá)標(biāo)后進(jìn)入迭代設(shè)計(jì)階段。這里的迭代包括兩種情況一種是修改RTL代碼后重新綜合布局布線這時(shí)候只修改了部分邏輯理論上可以只對(duì)變化的部分做增量布局布線另一種是修改IP核配置后重新生成IP核此時(shí)需要重新在Synplify里做綜合。增量布局布線對(duì)工程管理要求較高我一般建議在工程穩(wěn)定之前還是做全量流程等設(shè)計(jì)凍結(jié)后再考慮增量手段。3.5 高帶寬IP核協(xié)同設(shè)計(jì)的細(xì)節(jié)處理在帶IP核的FPGA工程里Aurora 8B/10B、CAN-FD這些IP核的使用頻率很高而且它們的協(xié)同處理方式有特殊性。這里單獨(dú)說(shuō)幾個(gè)細(xì)節(jié)。Aurora 8B/10B IP核的協(xié)同設(shè)計(jì)最需要注意的是GT復(fù)位邏輯。Aurora IP核的復(fù)位接口通常包括gt_reset和system_reset等這些復(fù)位信號(hào)直接影響GT收發(fā)器的初始化過(guò)程。在RTL中如果對(duì)復(fù)位信號(hào)做了同步處理或延遲處理在Synplify綜合時(shí)務(wù)必保證這些復(fù)位邏輯不被優(yōu)化掉。有幾次我在綜合工具里看到未連接的復(fù)位接口被自動(dòng)優(yōu)化結(jié)果上板后發(fā)現(xiàn)Aurora鏈路無(wú)法建立。解決辦法是在RTL中把復(fù)位信號(hào)聲明為合理的屬性防止綜合器將其判定為無(wú)影響的冗余邏輯。CAN-FD IP核相對(duì)簡(jiǎn)單但要注意時(shí)鐘域的劃分。CAN-FD控制器通常有總線時(shí)鐘域、處理器接口時(shí)鐘域和波特率時(shí)鐘域,不同時(shí)鐘域之間的握手信號(hào)必須經(jīng)過(guò)正確的同步。在Synplify綜合時(shí)如果跨時(shí)鐘域約束沒(méi)有在SDC中聲明綜合器可能將這些路徑當(dāng)作普通路徑處理導(dǎo)致布局布線后出現(xiàn)亞穩(wěn)態(tài)問(wèn)題。建議在SDC中為每個(gè)跨時(shí)鐘域路徑添加set_false_path約束并配合RTL中的兩級(jí)同步器邏輯。另外FFT IP核、除法器等運(yùn)算類IP核的協(xié)同設(shè)計(jì)相對(duì)直接因?yàn)樗鼈兺ǔＪ羌兘M合邏輯和寄存器邏輯的組合不涉及太多跨時(shí)鐘域問(wèn)題。但要注意FIFO IP核的讀時(shí)鐘和寫時(shí)鐘可能來(lái)自不同時(shí)鐘域這時(shí)候FIFO IP核的復(fù)位和時(shí)鐘約束同樣需要仔細(xì)設(shè)置。FIFO IP核使用異步時(shí)鐘時(shí)如果復(fù)位信號(hào)處理不當(dāng)會(huì)出現(xiàn)功能仿真通過(guò)但上板后數(shù)據(jù)錯(cuò)位的問(wèn)題。4. 常見(jiàn)問(wèn)題與排查技巧實(shí)錄協(xié)同設(shè)計(jì)流程跑多了必然會(huì)遇到五花八門的報(bào)錯(cuò)和異常。這里把我在多個(gè)項(xiàng)目里遇到的高頻問(wèn)題整理成速查表并分享排查思路。4.1 Vivado DRC報(bào)錯(cuò)與Implement變紅的經(jīng)典場(chǎng)景在協(xié)同設(shè)計(jì)流程里Vivado的DRC檢查經(jīng)常被觸發(fā)。特別是在布局布線完成后DRC報(bào)告里報(bào)出一堆RTSTAT-2錯(cuò)誤很多新手就懵了。這個(gè)RTSTAT-2這類DRC規(guī)則的實(shí)質(zhì)是約束設(shè)置和實(shí)際物理實(shí)現(xiàn)之間的沖突。舉個(gè)例子X(jué)DC里如果一個(gè)管腳被分配到了某個(gè)BANK的低電壓域但實(shí)際連接的IP核或邏輯需要的電壓等級(jí)不同DRC就會(huì)報(bào)錯(cuò)。在協(xié)同設(shè)計(jì)流程中由于管腳約束在XDC中定義而時(shí)序約束從Synplify導(dǎo)入兩邊信息不完整就很容易導(dǎo)致這類DRC報(bào)錯(cuò)。排查思路是先分清DRC錯(cuò)誤的具體類型是針對(duì)引腳、時(shí)鐘、還是區(qū)域的沖突然后針對(duì)性修改XDC。如果是引腳電壓域沖突修改引腳的IOSTANDARD屬性如果是時(shí)鐘約束沖突檢查是否在SDC和XDC中重復(fù)定義了時(shí)鐘。Implement變紅往往伴隨著DRC錯(cuò)誤或布局布線資源不足這時(shí)候的排查優(yōu)先級(jí)是先處理DRC錯(cuò)誤再檢查資源利用率最后才是時(shí)序違例。這里有一個(gè)經(jīng)驗(yàn)DRC錯(cuò)誤不要攢著到最后才看。Synplify生成的網(wǎng)表和Vivado中IP核的物理布局如果存在潛在沖突DRC檢查在布局布線前就應(yīng)該做一次作為獨(dú)立步驟運(yùn)行。Vivado支持在布局布線前單獨(dú)運(yùn)行DRC檢查盡早發(fā)現(xiàn)物理實(shí)現(xiàn)層面的沖突能在源頭上減少排錯(cuò)成本。4.2 復(fù)位信號(hào)引起的跨時(shí)鐘域與亞穩(wěn)態(tài)問(wèn)題FPGA設(shè)計(jì)中復(fù)位信號(hào)的處理是一個(gè)高頻踩坑點(diǎn)。在協(xié)同設(shè)計(jì)流程中復(fù)位信號(hào)的問(wèn)題尤其隱蔽因?yàn)镾ynplify綜合時(shí)對(duì)復(fù)位信號(hào)的處理邏輯可能和Vivado直接綜合不一樣。先解釋一下亞穩(wěn)態(tài)。簡(jiǎn)單來(lái)說(shuō)當(dāng)觸發(fā)器的數(shù)據(jù)輸入在時(shí)鐘邊沿附近發(fā)生變化時(shí)觸發(fā)器的輸出可能進(jìn)入一個(gè)不確定狀態(tài)既不是穩(wěn)定的高電平也不是穩(wěn)定的低電平這就是亞穩(wěn)態(tài)。如果這個(gè)不確定狀態(tài)被后續(xù)邏輯采樣就會(huì)導(dǎo)致功能錯(cuò)誤。復(fù)位信號(hào)如果處理不當(dāng)很容易引起亞穩(wěn)態(tài)特別是異步復(fù)位信號(hào)在釋放時(shí)與時(shí)鐘邊沿關(guān)系不確定時(shí)。很多工程師在RTL里把異步復(fù)位、同步釋放掛在嘴邊但實(shí)際寫代碼時(shí)只做了一半。比如復(fù)位同步釋放邏輯只處理了復(fù)位釋放的同步但沒(méi)有處理復(fù)位拉低時(shí)的同步導(dǎo)致復(fù)位信號(hào)在不同模塊間釋放時(shí)間不一致出現(xiàn)系統(tǒng)部分模塊已經(jīng)運(yùn)行、部分模塊還在復(fù)位的狀態(tài)。更隱蔽的情況是設(shè)計(jì)了復(fù)位同步邏輯但在Synplify綜合時(shí)沒(méi)有對(duì)復(fù)位信號(hào)設(shè)置合理的綜合屬性綜合器認(rèn)為復(fù)位信號(hào)上連接的同步邏輯是冗余的直接優(yōu)化掉了。排查這類問(wèn)題時(shí)先打開(kāi)Synplify的綜合報(bào)告查看復(fù)位信號(hào)是否被推斷為全局復(fù)位網(wǎng)絡(luò)以及復(fù)位同步器的寄存器是否被保留。然后在Vivado布局布線后使用時(shí)序分析工具查看復(fù)位釋放路徑的時(shí)序裕量。這兩個(gè)步驟能覆蓋大多數(shù)復(fù)位問(wèn)題。4.3 布局布線變紅并不全是時(shí)序問(wèn)題有一次一個(gè)工程跑完布局布線直接把路由資源用爆了Implement直接變紅。第一反應(yīng)是邏輯規(guī)模太大但仔細(xì)排查后發(fā)現(xiàn)問(wèn)題的根因不在邏輯規(guī)模而在時(shí)鐘資源分配不合理。問(wèn)題出在我用的是同步時(shí)鐘卻在RTL里通過(guò)時(shí)鐘分頻創(chuàng)造了多個(gè)派生時(shí)鐘。在Synplify綜合時(shí)這些派生時(shí)鐘被識(shí)別為獨(dú)立的時(shí)鐘網(wǎng)絡(luò)綜合器為每個(gè)時(shí)鐘網(wǎng)絡(luò)都預(yù)留了獨(dú)立的時(shí)鐘資源。在布局布線階段這些時(shí)鐘網(wǎng)絡(luò)爭(zhēng)搶全局時(shí)鐘資源最終導(dǎo)致布線擁塞。排查這個(gè)問(wèn)題的思路是通過(guò)Vivado的時(shí)鐘報(bào)告檢查所有時(shí)鐘網(wǎng)絡(luò)的物理資源使用情況。這種問(wèn)題在協(xié)同設(shè)計(jì)里很常見(jiàn)因?yàn)榫C合階段看到的是邏輯資源而布局布線階段才暴露物理資源沖突。解決辦法是在RTL里盡量減少邏輯分頻產(chǎn)生的時(shí)鐘改用FPGA的時(shí)鐘管理單元生成所需的時(shí)鐘這樣在綜合和布局布線時(shí)時(shí)鐘網(wǎng)絡(luò)規(guī)劃會(huì)更清晰。4.4 常用IP核的協(xié)同設(shè)計(jì)注意事項(xiàng)速查把幾種高頻使用的IP核在協(xié)同設(shè)計(jì)中的表現(xiàn)整理成一張速查表方便參考。IP核類型協(xié)同設(shè)計(jì)重點(diǎn)常見(jiàn)問(wèn)題解決思路Aurora 8B/10BGT復(fù)位與初始化邏輯鏈路無(wú)法建立、誤碼率高檢查復(fù)位接口保留約束GT時(shí)鐘和復(fù)位路徑FIFO IP核異步時(shí)鐘與復(fù)位處理數(shù)據(jù)錯(cuò)位、讀寫指針不同步約束跨時(shí)鐘域路徑確保復(fù)位同步釋放FFT IP核數(shù)據(jù)位寬與時(shí)序輸入時(shí)鐘受限、數(shù)據(jù)溢出在Vivado里配置位寬參數(shù)Synplify綜合時(shí)設(shè)置充分余量除法器IP核流水線結(jié)構(gòu)選擇延遲過(guò)大不滿足時(shí)序配置更高的流水線級(jí)數(shù)或改用并行結(jié)構(gòu)CAN-FD IP核多時(shí)鐘域同步總線數(shù)據(jù)錯(cuò)誤、幀丟失完善跨時(shí)鐘域握手邏輯SDC設(shè)置false_pathROM/RAM IP核初始化文件路徑仿真正常但綜合后數(shù)據(jù)丟失將初始化文件路徑改為相對(duì)路徑確保Synplify能正確讀取這張表里列的每一條都是我在實(shí)際項(xiàng)目中遇到過(guò)或者同事反饋過(guò)的真實(shí)問(wèn)題。ROM/RAM IP核初始化文件路徑這個(gè)問(wèn)題特別想多說(shuō)一句在Vivado中生成ROM IP核時(shí)如果指定的COE文件是通過(guò)絕對(duì)路徑引用的Synplify在綜合時(shí)可能因?yàn)檎也坏铰窂蕉^(guò)初始化導(dǎo)致生成的網(wǎng)表里帶了空的存儲(chǔ)內(nèi)容。上板之后表現(xiàn)出來(lái)的現(xiàn)象就是讀出來(lái)的數(shù)據(jù)全是0仿真階段卻一切正常。這個(gè)坑非常隱蔽排查手段只有去Synplify的網(wǎng)表文件里檢查存儲(chǔ)器的初始化內(nèi)容。4.5 綜合面積與布局布線優(yōu)化的小技巧綜合面積和布局布線優(yōu)化是FPGA工程師的必修課。在協(xié)同設(shè)計(jì)流程里兩者的優(yōu)化手段有一些不同。綜合階段Synplify提供了多種綜合選項(xiàng)比如自動(dòng)寄存器復(fù)制、資源共享、有限狀態(tài)機(jī)重新編碼等。開(kāi)啟這些選項(xiàng)可以優(yōu)化面積和時(shí)序。但開(kāi)啟之后一定要對(duì)比綜合報(bào)告因?yàn)橛行┻x項(xiàng)對(duì)特定設(shè)計(jì)反而有害。比如資源共享在數(shù)據(jù)通路上通常有效但在控制邏輯上可能增加布線延遲反而讓時(shí)序變差。所以綜合選項(xiàng)不是開(kāi)得越多越好而是要在每個(gè)工程里試驗(yàn)后確定最優(yōu)組合。布局布線階段Vivado提供的物理優(yōu)化手段相對(duì)較少但有一個(gè)技巧很實(shí)用在綜合階段保留層次化結(jié)構(gòu)。也就是說(shuō)讓Synplify在綜合時(shí)不要做全局扁平化而是保留模塊的層次邊界。這樣做的好處是在布局布線階段Vivado可以根據(jù)模塊邊界做更合理的物理布局避免邏輯碎片化。Synplify里有類似“Flatten”的選項(xiàng)建議保持關(guān)閉。還有一個(gè)細(xì)節(jié)容易被忽視FFT或?yàn)V波類IP核的輸入輸出位寬問(wèn)題。FPGA圖像處理里經(jīng)常要算定點(diǎn)數(shù)如果IP核配置的是浮點(diǎn)接口在Synplify綜合時(shí)很可能無(wú)法正確映射到DSP48資源造成資源和時(shí)序的浪費(fèi)。這種情況下的做法是在RTL層做定點(diǎn)數(shù)轉(zhuǎn)換IP核接口統(tǒng)一用定點(diǎn)數(shù)。我在圖像處理工程里吃過(guò)這個(gè)虧后來(lái)統(tǒng)一改定點(diǎn)數(shù)接口DSP48利用率從55%降到了30%左右時(shí)序收斂也輕松了不少。4.6 高速接口與專用硬核的處理建議帶Aurora、LVDS、QSPI這類高速接口的工程在協(xié)同設(shè)計(jì)里有一些特殊的處理建議。高速收發(fā)器接口的RTL邏輯和普通邏輯不同它們依賴于FPGA內(nèi)部的專用硬核資源比如收發(fā)器通道、高速時(shí)鐘管理單元等。在Synplify綜合時(shí)這些硬核資源不會(huì)被綜合成查找表和觸發(fā)器而是保持為原語(yǔ)實(shí)例。所以RTL代碼里必須使用Xilinx提供的原語(yǔ)模塊比如Aurora IP核內(nèi)部已經(jīng)封裝好了這些原語(yǔ)。RTL代碼里直接實(shí)例化這些IP核Synplify綜合時(shí)會(huì)把它們當(dāng)作黑盒處理。這個(gè)黑盒處理方式帶來(lái)了一個(gè)問(wèn)題黑盒接口的時(shí)序無(wú)法在綜合階段預(yù)估。解決思路是在SDC里手動(dòng)為這些黑盒接口設(shè)置合理的輸入輸出延遲讓綜合器有一個(gè)明確的時(shí)序目標(biāo)。否則綜合器會(huì)認(rèn)為這些路徑?jīng)]有時(shí)序約束優(yōu)化時(shí)直接跳過(guò)到了Vivado布局布線階段才暴露時(shí)序問(wèn)題而這時(shí)候修改RTL的代價(jià)已經(jīng)很大了。LVDS接口的協(xié)同處理相對(duì)簡(jiǎn)單主要關(guān)注數(shù)據(jù)對(duì)齊和位滑移控制邏輯。這類邏輯通常在RTL中實(shí)現(xiàn)通過(guò)例化Xilinx的LVDS收發(fā)原語(yǔ)完成。在Synplify綜合時(shí)保持原語(yǔ)實(shí)例不被優(yōu)化是關(guān)鍵可以用綜合屬性來(lái)標(biāo)記這些原語(yǔ)。QSPI接口如果涉及Flash配置和Multiboot功能在協(xié)同設(shè)計(jì)流程中沒(méi)有額外負(fù)擔(dān)但有一點(diǎn)要和綜合工具強(qiáng)調(diào)QSPI接口相關(guān)的時(shí)序約束通常是寬松的建議在SDC中設(shè)置成set_false_path或者較寬松的multicycle path避免給布局布線工具增加不必要的約束難度。5. 協(xié)同設(shè)計(jì)的效率提升與團(tuán)隊(duì)協(xié)作流程跑通之后下一步就是優(yōu)化效率特別是團(tuán)隊(duì)多人協(xié)同時(shí)。這一節(jié)分享腳本化、自動(dòng)化方面的實(shí)踐以及多人協(xié)作時(shí)容易忽略的細(xì)節(jié)。5.1 用腳本把重復(fù)勞動(dòng)自動(dòng)化協(xié)同設(shè)計(jì)流程里重復(fù)性的操作很多打開(kāi)工具、添加文件、設(shè)置約束、跑綜合、跑布局布線這些可以通過(guò)腳本一口氣完成。Synplify支持通過(guò)命令行方式運(yùn)行工程也支持使用Tcl腳本。在工程穩(wěn)定之后把綜合流程腳本化每次修改RTL后只需要運(yùn)行一條命令就能完成綜合。記得把綜合次數(shù)、綜合時(shí)間、時(shí)序結(jié)果輸出到日志文件里方便追溯。Vivado側(cè)同樣支持Tcl腳本。布局布線的腳本化需要注意一點(diǎn)每次運(yùn)行前清空之前的布局布線結(jié)果目錄否則可能因?yàn)榇嬖跉埩粑募?dǎo)致流程異常。腳本化還有一個(gè)附加好處CI集成。如果在服務(wù)器上建立了自動(dòng)化流程每次代碼提交后自動(dòng)跑一遍綜合加布局布線團(tuán)隊(duì)每個(gè)人都能在第一時(shí)間看到自己修改對(duì)時(shí)序和資源的影響。這個(gè)能力對(duì)多人協(xié)作的FPGA團(tuán)隊(duì)價(jià)值巨大能顯著減少集成階段的沖突和返工。5.2 IP核版本與參數(shù)凍結(jié)的協(xié)作規(guī)范團(tuán)隊(duì)協(xié)作中最頭疼的問(wèn)題之一就是IP核版本和參數(shù)不統(tǒng)一。兩個(gè)人同時(shí)改一個(gè)IP核的參數(shù)互相不知道最后集成到一起直接亂套。協(xié)同設(shè)計(jì)流程能夠天然緩解這個(gè)問(wèn)題因?yàn)镮P核統(tǒng)一在Vivado中生成只要約定好IP核的配置基線在版本管理上鎖定IP核的配置文件所有成員都從同一個(gè)基線生成IP核就不會(huì)出現(xiàn)版本漂移。具體操作上建議在Git中為每個(gè)IP核建立一個(gè)配置文件跟蹤機(jī)制。IP核的參數(shù)配置通常保存在一個(gè)配置文件里這個(gè)文件用文本格式記錄便于diff和版本比較。每個(gè)IP核參數(shù)變更都需要通過(guò)Merge Request流程由專人review合并后才允許團(tuán)隊(duì)成員更新本地IP核。這個(gè)規(guī)范在Aurora這類復(fù)雜IP核上尤其重要。Aurora IP核的配置參數(shù)有幾十個(gè)包括線速率、通道數(shù)量、數(shù)據(jù)位寬、流控模式等任何一個(gè)參數(shù)不一致都會(huì)導(dǎo)致鏈路互連異常。把規(guī)范前置到IP核配置階段能節(jié)省大量聯(lián)調(diào)時(shí)間。5.3 時(shí)序報(bào)告與設(shè)計(jì)評(píng)審該看哪些關(guān)鍵指標(biāo)周期性地做設(shè)計(jì)評(píng)審是保證工程健康度的關(guān)鍵手段。在協(xié)同設(shè)計(jì)流程里評(píng)審時(shí)重點(diǎn)看幾個(gè)指標(biāo)綜合后的時(shí)序報(bào)告、布局布線后的時(shí)序差異、資源利用率變化趨勢(shì)、以及DRC報(bào)告中的警告數(shù)量。綜合后時(shí)序報(bào)告和布局布線后時(shí)序差異是重點(diǎn)。如果Synplify綜合后顯示時(shí)序滿足要求但Vivado布局布線后大量路徑不滿足說(shuō)明綜合階段的時(shí)序預(yù)估和實(shí)際物理實(shí)現(xiàn)偏差過(guò)大。這通常意味著SDC約束設(shè)置有問(wèn)題比如時(shí)鐘定義不完整、輸入輸出延遲設(shè)置不合理等。反過(guò)來(lái)如果綜合階段就報(bào)告時(shí)序違規(guī)那問(wèn)題更大概率在RTL邏輯本身。資源利用率的變化趨勢(shì)也值得關(guān)注。如果每輪迭代資源都在漲需要及時(shí)定位是什么邏輯引起的。有些邏輯膨脹是正常的比如增加了新的功能模塊有些則是綜合策略導(dǎo)致的比如代碼風(fēng)格不合適、模塊復(fù)用不當(dāng)?shù)?。早發(fā)現(xiàn)早優(yōu)化總比到最后快收尾時(shí)發(fā)現(xiàn)資源不夠要強(qiáng)。DRC報(bào)告里的警告類型盡量清零。DRC警告雖然不會(huì)直接導(dǎo)致功能錯(cuò)誤但往往是隱患的信號(hào)。一個(gè)不完整的I/O約束、一個(gè)未使用的時(shí)鐘域都可能在某個(gè)特定條件下變成真正的bug。建議每個(gè)迭代周期都目標(biāo)性地清理DRC警告保持工程健康。5.4 調(diào)試手段從Vivado到硬件的閉環(huán)帶IP核的工程上板調(diào)試是繞不開(kāi)的環(huán)節(jié)。Synplify和Vivado協(xié)同設(shè)計(jì)流程中調(diào)試手段需要和純Vivado流程有所區(qū)分。一個(gè)重要區(qū)別是Synplify綜合后的網(wǎng)表在Vivado里是黑盒狀態(tài)。使用Vivado的ILA調(diào)試核時(shí)需要注意信號(hào)的可觀測(cè)性。ILA核的探針信號(hào)需要在綜合時(shí)保留但在Synplify綜合的網(wǎng)表里很多內(nèi)部信號(hào)可能已經(jīng)被優(yōu)化或重命名無(wú)法直接作為ILA探針。解決辦法是在RTL里用綜合屬性標(biāo)記需要保留的信號(hào)比如標(biāo)記為keep或mark_debug。另一個(gè)調(diào)試手段是使用Vivado的邏輯分析儀功能但前提是網(wǎng)表中的信號(hào)層次清晰。這就回應(yīng)了之前說(shuō)的保留層次化結(jié)構(gòu)的重要性。如果Synplify綜合時(shí)把層次打平了Vivado的邏輯分析儀根本無(wú)法定位到具體信號(hào)調(diào)試就會(huì)變得非常困難。上板階段比特流生成和固話操作本身和純Vivado流程沒(méi)有區(qū)別。QSPI Flash的燒寫、Multiboot配置、固化程序的生成這些操作在Vivado硬件管理器中完成。唯一要注意的是固話用的比特流必須和最終驗(yàn)證通過(guò)的布局布線結(jié)果一致不要在最后關(guān)頭為了省時(shí)間用舊比特流。6. 從經(jīng)驗(yàn)到方法論我的幾點(diǎn)體會(huì)最后談幾點(diǎn)比較主觀的體會(huì)是我做完幾個(gè)協(xié)同設(shè)計(jì)項(xiàng)目后沉淀下來(lái)的想法。第一工具鏈的選擇要服務(wù)于迭代效率而不是服務(wù)于“用上了新工具”的成就感。現(xiàn)在很多項(xiàng)目上來(lái)就要用最新的Vivado版本貪圖新特性但對(duì)于一個(gè)已經(jīng)跑得很穩(wěn)的工程升級(jí)工具鏈并帶來(lái)直接的收益反而平添變量。協(xié)同設(shè)計(jì)同樣如此如果你的工程規(guī)模不大、時(shí)序不緊用Vivado一條龍完全夠了不必強(qiáng)行上Synplify。我見(jiàn)過(guò)一些團(tuán)隊(duì)為了追求協(xié)同設(shè)計(jì)而協(xié)同設(shè)計(jì)結(jié)果在IP核版本兼容上花費(fèi)了大量時(shí)間反而降低了效率。第二時(shí)序問(wèn)題的根因90%在RTL設(shè)計(jì)層面工具能做的只是錦上添花。經(jīng)過(guò)多個(gè)工程的數(shù)據(jù)積累我發(fā)現(xiàn)長(zhǎng)期無(wú)法收斂的時(shí)序問(wèn)題深層原因基本都是邏輯鏈路過(guò)長(zhǎng)、跨時(shí)鐘域處理不當(dāng)、復(fù)位設(shè)計(jì)混亂這類RTL問(wèn)題。Synplify的時(shí)序預(yù)估能力和Vivado的布局布線優(yōu)化只能緩解表面癥狀真正解決問(wèn)題的路徑是審視設(shè)計(jì)本身。所以在跑工具之前先把RTL代碼評(píng)審一遍把能預(yù)見(jiàn)的時(shí)序問(wèn)題提前消化掉。第三個(gè)人比較推薦的做法是把Synplify的快速綜合當(dāng)作設(shè)計(jì)過(guò)程中的日常檢查手段。不一定要把協(xié)同設(shè)計(jì)作為最終交付流程但在RTL開(kāi)發(fā)階段每完成一個(gè)模塊就丟進(jìn)Synplify快速綜合一次看看資源占用和時(shí)序預(yù)估。這個(gè)習(xí)慣能讓你在開(kāi)發(fā)的早期就發(fā)現(xiàn)很多問(wèn)題而不是等整個(gè)工程集成完才發(fā)現(xiàn)某個(gè)模塊把整塊邏輯拖垮了。這個(gè)習(xí)慣養(yǎng)成之后你會(huì)發(fā)現(xiàn)后期布局布線的迭代次數(shù)大大減少。第四PDCA的思路用在FPGA工程管理上同樣適用。每完成一個(gè)迭代周期記錄下這一輪的時(shí)序結(jié)果、資源使用、DRC報(bào)告、遇到的問(wèn)題和解決方法。積累三輪之后回看你會(huì)發(fā)現(xiàn)問(wèn)題集中在哪幾個(gè)方面然后有針對(duì)性的在RTL設(shè)計(jì)規(guī)范、約束文件管理、IP核配置這些環(huán)節(jié)做標(biāo)準(zhǔn)化改進(jìn)。寫到這里這套基于Synplify與Vivado協(xié)同設(shè)計(jì)處理帶IP核FPGA工程的方法基本已經(jīng)完整鋪開(kāi)了。無(wú)論是流程組織、IP核管理、約束處理還是時(shí)序收斂和團(tuán)隊(duì)協(xié)作最終的目標(biāo)都是讓FPGA開(kāi)發(fā)變得更可預(yù)測(cè)、更高效。我用這套流程完成了多個(gè)項(xiàng)目的交付每一次迭代優(yōu)化都在不斷印證同一條經(jīng)驗(yàn)工具鏈只是手段真正決定項(xiàng)目成敗的還是對(duì)設(shè)計(jì)本身的理解和對(duì)流程細(xì)節(jié)的堅(jiān)持。希望這篇基于實(shí)際項(xiàng)目踩坑經(jīng)驗(yàn)寫下的文章能在你構(gòu)建或優(yōu)化自己的FPGA開(kāi)發(fā)流程時(shí)提供一些真正有用的參考。