1. 為什么你的工程要編譯13個(gè)小時(shí)FPGA編譯慢這個(gè)事兒折磨過(guò)的人都知道。一次小改動(dòng)改兩行RTL代碼重新跑一遍綜合和布局布線(xiàn)動(dòng)輒大半天沒(méi)了。更難受的是你沒(méi)法干等因?yàn)榫幾g占著工作站你想干點(diǎn)別的都怕把機(jī)器搞卡。我見(jiàn)過(guò)不少團(tuán)隊(duì)FPGA工程師的時(shí)間基本被編譯吃掉一半早上提交編譯下午出結(jié)果趕上時(shí)序不收斂晚上還得再來(lái)一輪。這根本不是個(gè)例是整個(gè)行業(yè)的普遍狀態(tài)。我最近碰到一個(gè)項(xiàng)目規(guī)模不算特別夸張Zynq UltraScale 系列邏輯資源用了大概三十多萬(wàn)LUTBRAM和DSP也吃了不少還用到了多路高速SerDes和PCIE核。這種規(guī)模在真實(shí)產(chǎn)品里非常常見(jiàn)不算最難啃的但已經(jīng)足夠把編譯時(shí)間拉到13個(gè)小時(shí)左右。整個(gè)流程跑完綜合加布局布線(xiàn)加時(shí)序收斂再加生成比特流和調(diào)試文件一輪下來(lái)就像過(guò)了一個(gè)工作日。項(xiàng)目后期每天迭代好幾版時(shí)間全砸在等待上。后來(lái)我用了一段時(shí)間把整體編譯時(shí)間從13小時(shí)壓到5小時(shí)以?xún)?nèi)。沒(méi)有換服務(wù)器CPU沒(méi)有加內(nèi)存也沒(méi)改工程結(jié)構(gòu)純粹是圍繞Vivado的編譯流程做了一輪系統(tǒng)性的提速優(yōu)化。這里面思路并不復(fù)雜關(guān)鍵是有幾個(gè)環(huán)節(jié)必須搞清楚、抓準(zhǔn)。這篇文章把整個(gè)過(guò)程的思路、操作和坑都整理出來(lái)希望能幫到同樣被編譯時(shí)間折磨的人。先說(shuō)清楚一個(gè)前提FPGA編譯時(shí)間這個(gè)痛點(diǎn)適合所有使用Xilinx Vivado做中大型項(xiàng)目的人不管是Zynq系列、Kintex系列還是UltraScale原理都是通用的。小項(xiàng)目編譯幾分鐘就完事兒感受不明顯但一旦資源量上來(lái)了時(shí)序約束復(fù)雜了或者用了大量IP核編譯時(shí)間就會(huì)急劇膨脹。此時(shí)如果不能精確控制編譯流程代價(jià)就是人力空轉(zhuǎn)、項(xiàng)目延期、凌晨加班。而這些問(wèn)題其實(shí)大部分都有辦法解決。2. 編譯慢的核心原因剖析2.1 先搞清楚時(shí)間到底花在哪個(gè)階段要提速第一步不是盲目開(kāi)多線(xiàn)程或者套增量編譯模板而是先測(cè)量的。Vivado整個(gè)編譯流程分為綜合、布局、布線(xiàn)、時(shí)序優(yōu)化、比特流生成幾個(gè)大階段。不同階段的耗時(shí)占比差異非常大而且和工程本身的資源結(jié)構(gòu)強(qiáng)相關(guān)。脫離數(shù)據(jù)談優(yōu)化基本等于靠猜。我在這個(gè)工程里做了詳細(xì)的耗時(shí)統(tǒng)計(jì)。綜合階段大約占1.5小時(shí)其中因?yàn)槭褂昧舜罅縄P核IP的OOC綜合占了不少時(shí)間。后端的布局布線(xiàn)階段是大頭布局約2小時(shí)布線(xiàn)約4.5小時(shí)時(shí)序優(yōu)化流程跑下來(lái)又吃掉了2.5小時(shí)。最后生成比特流和調(diào)試用的調(diào)試核文件大約0.5小時(shí)。這一算下來(lái)13個(gè)小時(shí)基本是實(shí)打?qū)嵉牟皇悄膬撼隽薆ug導(dǎo)致卡死。如果資源利用率更高、時(shí)序約束更緊布線(xiàn)和時(shí)序優(yōu)化的耗時(shí)比例還會(huì)進(jìn)一步上升。布線(xiàn)是整個(gè)FPGA編譯里最耗時(shí)的一步尤其是全局布線(xiàn)因?yàn)楣ぞ咭邶嫶蟮穆酚少Y源中尋找最優(yōu)路徑既要滿(mǎn)足時(shí)序要求又要避免擁塞沖突。而時(shí)序優(yōu)化是一個(gè)反復(fù)迭代的過(guò)程一次不收斂工具就自動(dòng)調(diào)整策略再跑一遍非常耗時(shí)。知道這個(gè)結(jié)構(gòu)之后思路就清楚了后期日常小改動(dòng)迭代真正需要跑的其實(shí)只有后段局部。如果能在前端把時(shí)間截住省下來(lái)的就是幾個(gè)小時(shí)。2.2 瓶頸不只是CPU還有I/O和策略很多人第一反應(yīng)是加CPU核數(shù)、升主頻。確實(shí)有效果但效果有限。Vivado的并行度設(shè)計(jì)有一個(gè)特點(diǎn)綜合和布局布線(xiàn)階段的多線(xiàn)程支持是有上限的一般到8個(gè)線(xiàn)程之后收益就明顯衰減。而且工程如果放在機(jī)械硬盤(pán)上讀寫(xiě)大工程文件會(huì)頻繁觸發(fā)磁盤(pán)I/O綜合和布線(xiàn)的時(shí)間可能被I/O等待拖慢不少。還有一個(gè)大家容易忽視的點(diǎn)時(shí)序約束策略和綜合策略直接影響編譯耗時(shí)。默認(rèn)策略是保守的、通用的不針對(duì)具體工程做任何傾向性?xún)?yōu)化。如果工程本身時(shí)序余量很緊張默認(rèn)策略會(huì)反復(fù)做時(shí)序優(yōu)化嘗試一次不收斂就跑多輪結(jié)果就是耗時(shí)成倍增加。反過(guò)來(lái)工程本身時(shí)序余量充足卻使用了超高性能優(yōu)化策略也會(huì)白白多花時(shí)間。策略跟工程實(shí)際情況不匹配是很多人編譯慢的隱藏原因。這里插一句。網(wǎng)上很多帖子推薦直接改-max_threads參數(shù)拉滿(mǎn)多線(xiàn)程實(shí)際上對(duì)于Linux環(huán)境下的大工程有一定幫助但Windows環(huán)境下進(jìn)程管理機(jī)制不同收益沒(méi)那么明顯。另有一些教程推薦“關(guān)閉OOC綜合”或者“拼命加增量編譯”如果使用時(shí)機(jī)不對(duì)反而會(huì)導(dǎo)致工具判斷失效甚至更慢。不要盲目跟風(fēng)一切以數(shù)據(jù)說(shuō)話(huà)。3. 編譯進(jìn)度監(jiān)控與性能測(cè)量方法3.1 學(xué)會(huì)讀取Vivado的報(bào)告Vivado在編譯過(guò)程中會(huì)生成大量信息但很多人不看或者看的時(shí)候只盯著有沒(méi)有報(bào)錯(cuò)。真正有效的做法是在綜合和布局布線(xiàn)完成后主動(dòng)去查看報(bào)告文件里的“Runtime”部分那里有每個(gè)階段的耗時(shí)明細(xì)。具體路徑是Report Utilization看資源占用Report Timing Summary看時(shí)序狀態(tài)Report Methodology看靜態(tài)檢查。但耗時(shí)分布要到Tcl Console里輸入report_runtime或者打開(kāi)runme.log文件查看。runme.log里會(huì)記錄每一步啟動(dòng)和結(jié)束時(shí)的時(shí)間戳用時(shí)間戳差值就能計(jì)算出每個(gè)獨(dú)立步驟的真實(shí)耗時(shí)。這是最準(zhǔn)確的第一手?jǐn)?shù)據(jù)。我看到很多人的工作習(xí)慣是雙擊Run Synthesis然后去刷手機(jī)。編譯完了直接看有沒(méi)有時(shí)序錯(cuò)誤。如果時(shí)序沒(méi)過(guò)改兩行代碼又跑一遍。這樣一個(gè)循環(huán)下來(lái)時(shí)間全浪費(fèi)在“盲目的等待”和“重復(fù)性的全量編譯”上。如果愿意多花5分鐘看一次日志分析耗時(shí)分布優(yōu)化的方向自然就出來(lái)了。沒(méi)有數(shù)據(jù)支撐的優(yōu)化都是盲人摸象。3.2 寫(xiě)好腳本實(shí)現(xiàn)全流程自動(dòng)化純粹在GUI里操作編譯過(guò)程中的參數(shù)調(diào)整非常費(fèi)勁。更高效的做法是用Tcl腳本把整個(gè)編譯流程串起來(lái)。Vivado的Tcl支持非常好幾乎GUI里能做的所有操作都能在腳本里完成而且腳本可以版本化方便團(tuán)隊(duì)協(xié)作。我在做提速優(yōu)化時(shí)一開(kāi)始就把GUI操作全部遷移到了Tcl腳本里。最基本的腳本長(zhǎng)這樣open_project /path/to/project.xpr launch_runs synth_1 -jobs 8 wait_on_run synth_1 open_run synth_1 -name netlist_1 launch_runs impl_1 -to_step write_bitstream -jobs 8 wait_on_run impl_1 report_timing_summary -file timing_summary.rpt report_utilization -file utilization.rpt這段腳本的作用是打開(kāi)工程啟動(dòng)綜合8線(xiàn)程等待綜合完成然后打開(kāi)綜合后的網(wǎng)表啟動(dòng)布局布線(xiàn)直到生成比特流最后輸出時(shí)序和資源報(bào)告。整個(gè)過(guò)程不需要人工干預(yù)。腳本化之后編譯提速才能真正落地。因?yàn)槟悴恍枰看问謩?dòng)去GUI里翻找設(shè)置項(xiàng)改參數(shù)也只是改腳本的一兩行批量驗(yàn)證非常方便。我自己習(xí)慣在腳本里加上-to_step write_bitstream節(jié)省一步操作。另外也可以在腳本里加入set_property strategy Performance_Explore [get_runs impl_1]之類(lèi)的設(shè)置方便在不同策略之間切換做對(duì)比測(cè)試。這一步對(duì)于后面要說(shuō)的策略?xún)?yōu)化很關(guān)鍵沒(méi)有腳本策略對(duì)比會(huì)累死人。4. 綜合階段的提速方案4.1 合理調(diào)整綜合策略別讓綜合成為拖累綜合階段是在將RTL代碼轉(zhuǎn)換為門(mén)級(jí)網(wǎng)表的過(guò)程中進(jìn)行邏輯優(yōu)化、資源推斷和工藝映射。默認(rèn)情況下Vivado的綜合策略會(huì)盡可能地做面積和性能平衡這本身沒(méi)問(wèn)題但對(duì)于大型工程默認(rèn)策略的耗時(shí)可能偏高。在Vivado中綜合階段常見(jiàn)的策略有Flow_RuntimeOptimized和Flow_AreaOptimized_High。前者傾向于縮短綜合時(shí)間后者傾向于優(yōu)化面積。如果工程當(dāng)前處于功能迭代期時(shí)序壓力不太大的情況下用Flow_RuntimeOptimized綜合會(huì)快不少。實(shí)測(cè)中同樣一個(gè)模塊默認(rèn)綜合大約需要1.5小時(shí)切到Flow_RuntimeOptimized之后能壓到1小時(shí)左右。省下來(lái)的時(shí)間不多但恰好能保證綜合結(jié)果在后端布局布線(xiàn)中不會(huì)變差太多。具體操作方式set_property strategy Flow_RuntimeOptimized [get_runs synth_1]如果工程里面使用了大量第三方IP或者自己封裝的IP綜合階段還有另一個(gè)大頭OOC綜合。OOC全稱(chēng)Out-of-Context意思是IP核在頂層工程綜合之前先獨(dú)立完成綜合。好處是IP綜合結(jié)果可以復(fù)用不隨頂層修改而重新綜合。壞處是第一次跑的時(shí)候所有IP都要單獨(dú)綜合一遍耗時(shí)很長(zhǎng)。解決辦法是在工程設(shè)置里打開(kāi)-mode out_of_context并配合增量綜合使用。但要注意IP版本更新或者參數(shù)調(diào)整后對(duì)應(yīng)的OOC結(jié)果會(huì)失效需要重新綜合。4.2 增量綜合的正確用法和適用條件增量綜合Incremental Synthesis是很多加速教程推薦的第一方案。但不少人對(duì)它的理解有偏差。它并不是“只編譯改動(dòng)的那一小部分代碼”這么簡(jiǎn)單而是通過(guò)復(fù)用上一次綜合的中間結(jié)果減少邏輯優(yōu)化和工藝映射的計(jì)算量。前提是代碼改動(dòng)范圍比較小且沒(méi)有改動(dòng)到模塊接口。我當(dāng)時(shí)在功能迭代階段使用增量綜合實(shí)測(cè)把綜合時(shí)間從1小時(shí)壓到了20分鐘左右。比如我改了一段狀態(tài)機(jī)的邏輯但接口沒(méi)變那么增量綜合只需要重新綜合這個(gè)狀態(tài)機(jī)相關(guān)的邏輯塊其余部分直接用上次的結(jié)果。但如果改了頂層的端口定義、或者改動(dòng)涉及跨模塊的信號(hào)連接增量綜合的效果會(huì)大打折扣有時(shí)甚至?xí)|發(fā)全量重新綜合反而更慢。另外增量綜合有一個(gè)前置條件上一次綜合結(jié)果的文件必須還在不能清理掉。Vivado默認(rèn)會(huì)保留synth_1目錄下的incremental_synth文件但如果手動(dòng)清理過(guò)工程目錄或者換了一臺(tái)機(jī)器增量綜合會(huì)失效。這里也提醒一下增量綜合依賴(lài)的是工程目錄下的中間文件版本管理工具通常會(huì)忽略這些文件換環(huán)境之后需要重新做一次全量綜合建立新的基線(xiàn)之后才能繼續(xù)使用增量。實(shí)操時(shí)記得在運(yùn)行綜合前先用Tcl命令檢查是否存在可復(fù)用的增量文件get_property INCREMENTAL_CHECKPOINT [get_runs synth_1]返回路徑不為空才說(shuō)明增量綜合可用。5. 布局布線(xiàn)階段的核心加速手段5.1 全局布線(xiàn)是耗時(shí)的重災(zāi)區(qū)如何針對(duì)性?xún)?yōu)化布局布線(xiàn)階段是整個(gè)編譯過(guò)程中占比最大的部分通常占據(jù)總時(shí)間的60%到70%。這個(gè)階段里時(shí)序驅(qū)動(dòng)的布局和布線(xiàn)算法高度依賴(lài)計(jì)算資源也是很多優(yōu)化手段瞄準(zhǔn)的重點(diǎn)。針對(duì)布線(xiàn)耗時(shí)Vivado提供了多個(gè)布線(xiàn)策略。常用的是Performance_Explore、Congestion_SpreadLogic_high、RuntimeOptimized。默認(rèn)的布線(xiàn)策略偏向于在時(shí)序和擁塞之間尋找平衡但在工程時(shí)序余量充足的情況下可以切換為RuntimeOptimized。這個(gè)策略會(huì)放寬部分全局優(yōu)化范圍減少不必要的迭代實(shí)測(cè)能節(jié)省約20%到30%的布線(xiàn)時(shí)間。我用Tcl設(shè)置布局布線(xiàn)的實(shí)現(xiàn)策略set_property strategy Performance_Explore [get_runs impl_1]注意這里使用的是Performance_Explore聽(tīng)起來(lái)像是追求性能的但這個(gè)策略在多個(gè)子步驟中會(huì)探索不同的參數(shù)組合有時(shí)反而比RuntimeOptimized更快得出結(jié)果因?yàn)樗芨煺业綕M(mǎn)足約束的方案減少后續(xù)的時(shí)序收斂迭代。針對(duì)不同工程需要測(cè)試后才能確定最優(yōu)策略。我在這個(gè)項(xiàng)目中Performance_Explore比RuntimeOptimized還要快原因是工程時(shí)序約束相對(duì)寬松工具在第一輪探索中就找到了滿(mǎn)足要求的布線(xiàn)方案。還有一點(diǎn)在布局布線(xiàn)階段如果開(kāi)了比特流生成會(huì)額外增加時(shí)間。如果當(dāng)前只是需要驗(yàn)證時(shí)序或者做資源評(píng)估不會(huì)立即上板調(diào)試可以先用-to_step route_design把比特流生成留到最終確定版本時(shí)再做。這一步看似不起眼實(shí)際也能省10到15分鐘。5.2 布局方面的重要選項(xiàng) Floorplanning和PBlock布局階段的加速手段除了策略切換還有一個(gè)更深層的方案手動(dòng)布局約束Floorplanning。很多人覺(jué)得手動(dòng)布局是大神才干的事其實(shí)并不復(fù)雜只需要對(duì)設(shè)計(jì)關(guān)鍵模塊的位置做大致規(guī)劃就能有效減少布局器的搜索空間。實(shí)際操作上可以用PBlock約束把某個(gè)大的模塊固定在某個(gè)區(qū)域。例如PCIE控制器和DMA邏輯放在一個(gè)時(shí)鐘區(qū)域附近圖像處理管線(xiàn)放在另一個(gè)時(shí)鐘區(qū)域這樣可以減少跨區(qū)域繞線(xiàn)距離布線(xiàn)器的壓力變小也降低時(shí)序收斂難度。運(yùn)行布局時(shí)工具不再?gòu)念^全局搜索而是在給定初始位置的基礎(chǔ)上進(jìn)行局部?jī)?yōu)化時(shí)間會(huì)明顯縮短。但這里一定要說(shuō)清楚Floorplanning不是“加快編譯”的通用解它的主要價(jià)值在于優(yōu)化時(shí)序和減少擁塞。如果你為了強(qiáng)制固定某個(gè)模塊的位置反而把模塊放得太分散或者太集中可能導(dǎo)致布線(xiàn)擁塞加劇編譯時(shí)間不降反升。所以在做Floorplanning之前先看布局后的熱力圖確認(rèn)哪里有擁塞再有針對(duì)性地調(diào)整區(qū)域。沒(méi)有擁塞問(wèn)題的工程跑Floorplanning純屬畫(huà)蛇添足。6. 多線(xiàn)程、多機(jī)器協(xié)同與DFX模塊化6.1 多線(xiàn)程參數(shù)的正確設(shè)置姿勢(shì)Vivado從2017.1版本開(kāi)始支持多線(xiàn)程并行編譯官方說(shuō)明是在Linux系統(tǒng)下效果更明顯。這個(gè)功能本質(zhì)是讓綜合、布局和布線(xiàn)算法在多個(gè)CPU核上并行執(zhí)行從而縮短墻鐘時(shí)間。但并不是線(xiàn)程數(shù)越多越好-jobs 8并不意味著比-jobs 4快兩倍。由于算法內(nèi)部存在依賴(lài)關(guān)系真正能并行執(zhí)行的部分有限線(xiàn)程開(kāi)太多反而會(huì)因?yàn)榫€(xiàn)程調(diào)度開(kāi)銷(xiāo)而拖慢速度。我做了實(shí)際對(duì)比測(cè)試同一個(gè)工程在8核和16核CPU上跑-jobs 8差不多是-jobs 4的1.6倍速度提升-jobs 16比-jobs 8提升不到10%。所以建議設(shè)置在8到12之間即可太高沒(méi)意義還占滿(mǎn)機(jī)器資源導(dǎo)致你連看日志都卡。另外還要注意Vivado的版本差異。舊版本在-jobs和-max_threads之間有一些細(xì)微差別新版本通過(guò)launch_runs -jobs N統(tǒng)一管理。Tcl里可以這樣設(shè)置默認(rèn)線(xiàn)程數(shù)set_param general.maxThreads 8這個(gè)設(shè)置對(duì)所有階段全局生效。如果你用GUI方式啟動(dòng)綜合可以在Project Settings里設(shè)置Number of jobs效果相同。6.2 多機(jī)器并行編譯的實(shí)操方案如果單機(jī)性能確實(shí)有限另一個(gè)思路是把不同部分的綜合分散到多臺(tái)機(jī)器上跑。Vivado支持分布式綜合Distributed Synthesis主要針對(duì)IP核的OOC綜合。這種方式把多個(gè)IP核的綜合任務(wù)分發(fā)給多臺(tái)機(jī)器并行執(zhí)行全部完成后收集結(jié)果。前提是網(wǎng)絡(luò)環(huán)境穩(wěn)定、共享存儲(chǔ)可用、各機(jī)器上的Vivado版本一致并且License支持多機(jī)并行。這個(gè)操作在日常開(kāi)發(fā)中比較繁瑣需要配置xsim資源池和SSH免密登錄。如果項(xiàng)目周期緊、單機(jī)實(shí)在扛不住可以考慮。但如果只是平時(shí)的小迭代沒(méi)必要上這個(gè)方案。還有一個(gè)更輕量的思路用remote_host配置把綜合和實(shí)現(xiàn)放到專(zhuān)門(mén)的編譯服務(wù)器上跑本地只做編輯和查看報(bào)告。這個(gè)做法對(duì)個(gè)人體驗(yàn)的提升非常明顯編譯占用的是遠(yuǎn)端資源本地電腦不卡。特別是家里和辦公室分開(kāi)工作的時(shí)候遠(yuǎn)端編譯配合腳本自動(dòng)運(yùn)行隨時(shí)隨地看結(jié)果體驗(yàn)非常好。6.3 DFX模塊化設(shè)計(jì)大工程提速的終極答案如果項(xiàng)目結(jié)構(gòu)允許還有一招從根本上改變編譯模式DFX即Dynamic Function eXchange動(dòng)態(tài)功能切換。DFX允許你將工程劃分為靜態(tài)區(qū)域和動(dòng)態(tài)區(qū)域每次修改只針對(duì)其中一個(gè)動(dòng)態(tài)區(qū)域進(jìn)行編譯靜態(tài)區(qū)域使用上一次編譯的結(jié)果不需要重新跑一遍布局布線(xiàn)。這相當(dāng)于把一個(gè)大工程的編譯任務(wù)拆成了一個(gè)個(gè)小模塊的編譯效果顯著。我做過(guò)一個(gè)帶DFX的項(xiàng)目帶三個(gè)動(dòng)態(tài)功能模塊每個(gè)模塊的資源量約2萬(wàn)LUT。在沒(méi)有DFX的時(shí)候整體編譯一次是7小時(shí)使用DFX之后修改單個(gè)模塊重新編譯只需要1.5小時(shí)左右。原因是每次編譯實(shí)際只需要重新布局布線(xiàn)動(dòng)態(tài)區(qū)域靜態(tài)區(qū)域保持不變工具直接復(fù)用之前的結(jié)果。這幾個(gè)小時(shí)的時(shí)間差距在項(xiàng)目后期幾乎決定了你能不能在一天內(nèi)跑完所有驗(yàn)證場(chǎng)景。DFX在Vivado中需要單獨(dú)創(chuàng)建PR工程設(shè)置pblock約束并運(yùn)行PR_Verify檢查。操作路徑稍微復(fù)雜一些網(wǎng)上教程也不多但掌握了之后收益巨大。從個(gè)人經(jīng)驗(yàn)講如果工程規(guī)模在20萬(wàn)LUT以上并且有比較明確的可動(dòng)態(tài)切換的功能模塊DFX值得花一周時(shí)間研究落地。7. 時(shí)序約束與網(wǎng)表優(yōu)化層面的提速7.1 時(shí)序收斂的迭代過(guò)程如何縮短編譯時(shí)間長(zhǎng)的另一個(gè)隱性原因是時(shí)序不收斂工具反復(fù)做優(yōu)化迭代每次迭代都重新布局布線(xiàn)。這種情況治標(biāo)更重要。先把所有約束清理干凈把不是必須的虛假路徑、多周期路徑全部定義正確再談加速。約束寫(xiě)得不全、寫(xiě)錯(cuò)工具就只能靠猜測(cè)來(lái)優(yōu)化當(dāng)然會(huì)消耗大量時(shí)間。我在一個(gè)項(xiàng)目中遇到過(guò)某條跨時(shí)鐘域的路徑?jīng)]有設(shè)置set_clock_groups約束工具默認(rèn)按同步路徑做時(shí)序收斂反復(fù)調(diào)整寄存器位置和布線(xiàn)連跑了三輪都沒(méi)有收斂。后來(lái)加上異步時(shí)鐘組約束后一次布線(xiàn)就過(guò)了時(shí)間直接少了一半。這件事讓我徹底明白編譯優(yōu)化不是純靠工具參數(shù)約束質(zhì)量才是省時(shí)間的最強(qiáng)杠桿。另外set_false_path不是隨便用的。有些人為了快速收斂把一堆路徑設(shè)成FALSE時(shí)序報(bào)告是變好看了但上板跑起來(lái)功能就出錯(cuò)。正確的做法是先識(shí)別哪些路徑在功能上確實(shí)不需要時(shí)序檢查比如測(cè)試邏輯、配置寄存器鏈這類(lèi)再設(shè)置約束。這里需要豐厚的硬件設(shè)計(jì)經(jīng)驗(yàn)來(lái)支撐不能為了省時(shí)間犧牲正確性。7.2 網(wǎng)表優(yōu)化等級(jí)對(duì)編譯時(shí)間的影響Vivado的布局布線(xiàn)階段還有一個(gè)隱藏選項(xiàng)phys_opt_design的優(yōu)化等級(jí)。默認(rèn)情況下工具在布線(xiàn)后會(huì)有一次物理優(yōu)化嘗試調(diào)整寄存器位置、邏輯復(fù)制等手段改善時(shí)序。這個(gè)優(yōu)化本身也很耗時(shí)但在某些工程里效果并不大。我測(cè)試過(guò)幾種方案。一種是不再額外跑物理優(yōu)化只依賴(lài)布局器自身的優(yōu)化另一種是在布線(xiàn)前跑一輪物理優(yōu)化布線(xiàn)后不再跑。兩種方式理論上可能犧牲少量時(shí)序性能但對(duì)于本來(lái)就有時(shí)序余量的工程來(lái)說(shuō)完全是可行的能節(jié)省約20到30分鐘。如果工程時(shí)序本來(lái)就很緊不建議去掉這個(gè)步驟否則后續(xù)反復(fù)修時(shí)序的時(shí)間會(huì)遠(yuǎn)遠(yuǎn)超過(guò)省下的編譯時(shí)間。此外還可以在實(shí)現(xiàn)流程里加上-directive Quick來(lái)快速評(píng)估一版結(jié)果看能否滿(mǎn)足約束要求。這種方式相當(dāng)于跑一個(gè)低精度的快速預(yù)演跑完之后能知道大致的時(shí)序狀態(tài)。如果預(yù)演結(jié)果已經(jīng)滿(mǎn)足再跑全量精修如果預(yù)演就崩了那么全量精修大概率也崩可以提前改設(shè)計(jì)避免浪費(fèi)時(shí)間。8. 常見(jiàn)問(wèn)題排查實(shí)錄與最終效果總結(jié)8.1 增量編譯不生效這類(lèi)典型問(wèn)題怎么查增量編譯不生效算是非常高頻的問(wèn)題了。我當(dāng)時(shí)自己就踩過(guò)一次。代碼只改了某個(gè)模塊內(nèi)部理論上增量綜合應(yīng)該在幾分鐘內(nèi)完成但實(shí)際跑了一個(gè)半小時(shí)和全量綜合差不多。打開(kāi)日志一看發(fā)現(xiàn)提示有部分頂層接口發(fā)生了改變?cè)隽烤C合條件不滿(mǎn)足。導(dǎo)致這個(gè)問(wèn)題的原因很多頂層的端口順序調(diào)整了、IP核參數(shù)變了、全局屬性文件更新了都會(huì)導(dǎo)致增量檢查失敗。排查辦法是在綜合前打開(kāi)綜合日志搜索“Incremental”相關(guān)的提示信息。如果看到“reference checkpoint cannot be used”或類(lèi)似字眼那就說(shuō)明增量編譯這次沒(méi)生效別傻等直接停掉改全量。另外工程文件放在不同路徑下也可能導(dǎo)致incremental_checkpoint路徑失效需要確保路徑一致。還有一個(gè)坑就是增量編譯后資源利用率報(bào)告和之前的差別大得離譜。這大概率是某個(gè)宏定義或者參數(shù)被改動(dòng)了導(dǎo)致綜合后邏輯結(jié)構(gòu)完全變了。遇到這種情況別糾結(jié)直接重新全量綜合作為新的基線(xiàn)再開(kāi)啟下一輪增量。8.2 換了機(jī)器之后編譯時(shí)間反而變長(zhǎng)團(tuán)隊(duì)開(kāi)發(fā)中經(jīng)常遇到這個(gè)問(wèn)題。在服務(wù)器上編譯用6小時(shí)在本地工作站上編譯要10小時(shí)。排除機(jī)器性能差異之后最常見(jiàn)的兩個(gè)原因是本地運(yùn)行的Vivado版本不一致導(dǎo)致同一份工程代碼綜合策略有所變化另一個(gè)是本地沒(méi)有配置好-jobs參數(shù)默認(rèn)用了單線(xiàn)程。另外一個(gè)容易被忽略的因素是殺毒軟件。Windows環(huán)境下殺毒軟件會(huì)實(shí)時(shí)掃描工程目錄下大量不斷生成的小文件拖慢I/O。在Vivado編譯期間把工程目錄添加為掃描排除項(xiàng)或者干脆把所有編譯任務(wù)放到Linux服務(wù)器上跑性能會(huì)好很多。我自己在Windows上跑編譯時(shí)把整個(gè)工程目錄和Vivado安裝目錄都加入了白名單編譯耗時(shí)縮小了15%左右非?？捎^(guān)。8.3 最終提速效果從13小時(shí)到5小時(shí)是怎么湊出來(lái)的最后匯總一下這次的優(yōu)化結(jié)果。全量綜合從1.5小時(shí)降到0.9小時(shí)主要是調(diào)整了綜合策略和增量編譯。布局從2小時(shí)降到1.5小時(shí)主要?dú)w功于Floorplanning的加入某些模塊提前固定了大致區(qū)域布局器的搜索空間變小。布線(xiàn)從4.5小時(shí)降到1.8小時(shí)主要是切換到Performance_Explore策略結(jié)合物理優(yōu)化裁剪。時(shí)序優(yōu)化流程從2.5小時(shí)降到0.5小時(shí)核心原因是約束清理避免了很多不必要的調(diào)整迭代。比特流生成那半小時(shí)幾乎沒(méi)法再壓縮保持原樣。加起來(lái)總時(shí)間從13小時(shí)壓到了5小時(shí)出頭。這里面每個(gè)步驟單獨(dú)來(lái)看都不是天翻地覆的變化但逐項(xiàng)疊加之后效果就非常明顯。整個(gè)過(guò)程最核心的收獲是優(yōu)化之前先測(cè)量不要憑感覺(jué)去猜測(cè)瓶頸。你可以不知道Vivado內(nèi)部的每一個(gè)算法細(xì)節(jié)但一定要知道自己的時(shí)間花在了哪里然后針對(duì)性地去調(diào)整工具設(shè)置和工程結(jié)構(gòu)。如果你也正被FPGA編譯時(shí)間折磨建議按這個(gè)順序來(lái)先看報(bào)告確定耗時(shí)分布然后清理時(shí)序約束再調(diào)整策略參數(shù)最后考慮DFX或者多機(jī)協(xié)同這種工程級(jí)的改動(dòng)。把編譯時(shí)間省下來(lái)之后你才有更多時(shí)間去做真正的設(shè)計(jì)迭代而不是把光陰耗在等進(jìn)度條上。