電子發(fā)燒友App
在FPGA開發(fā)設(shè)計中，我們可能會經(jīng)歷由于資源占用過高的情況，例如BRAM、LUT和URAM等關(guān)鍵資源利用率達到或超過80%，此時出現(xiàn)時序違例是常有的事，甚至由于擁塞導(dǎo)致布線失敗，整個FPGA工程面臨無法生成bit文件的危險。
那么，有沒有辦法來解決這類問題呢？
此類問題是FPGA設(shè)計實現(xiàn)中比較棘手的問題，Xilinx針對7系列及以后的UltraScale/UltraScale+等，提出了UltraFast設(shè)計方法論，用于指導(dǎo)該系列器件的成功設(shè)計和實現(xiàn)，完成復(fù)雜系統(tǒng)設(shè)計。
時序收斂是指設(shè)計滿足所有的時序要求。針對綜合采用正確的 HDL 和約束條件就能更易于實現(xiàn)時序收斂。通過選擇更合適的 HDL、約束和綜合選項，經(jīng)過多個綜合階段進行迭代同樣至關(guān)重要，如下圖所示。
Xilinx提出的實現(xiàn)快速收斂的設(shè)計方法論
FPGA布線擁塞怎么辦？
如果關(guān)鍵路徑在擁塞區(qū)域內(nèi)或者緊鄰擁塞區(qū)域，或者是資源利用率較高，都會導(dǎo)致時序收斂困難。在很多情況下，擁塞會消耗大量的布線時間，甚至布線失敗。如果布線延遲顯著大于預(yù)期值，那么我們就得考慮降低設(shè)計的擁塞程度。
在確保時序約束和物理約束正確的情況下，我們可以通過以下方法解決擁塞問題。
1.擁塞類型
Xilinx FPGA布線結(jié)構(gòu)包括東、南、西、北共4個方向不同長度的互聯(lián)資源。擁塞區(qū)域以最小的正方形體現(xiàn)，這個正方形覆蓋了相鄰的互聯(lián)資源或CLB單元。
“Device”視圖中的擁塞等級和擁塞區(qū)域
擁塞包括3種類型：全局擁塞、短線擁塞和長線擁塞。
擁塞類型
| 擁塞類型 | 主要原因 |
| 全局擁塞：在特定區(qū)域內(nèi)擁有較高的布線資源利用率 | 過多的LUT整合 |
| 過多的控制集 | |
| 過多的總線 | |
| 布局不合理 | |
| 短線擁塞：缺少短距離布線資源，常見于UltraScale系列芯片 | MUXF利用率過高 |
| 進位鏈利用率過高 | |
| 長線擁塞：缺少長距離布線資源，常見于UltraScale系列芯片 | Rent、Average Fanout的值過高 |
| Block RAM、UltraRAM、DSP使用率過高且互聯(lián)嚴重 | |
| 過多的穿越SLR的路徑 |
2.生成設(shè)計擁塞報告
為了檢查擁塞程度，我們可以基于布局之后生成的DCP，通過以下Tcl命令生成設(shè)計擁塞報告。
?
report_design_analysis -congestion -name cong
?
分析擁塞時，工具報告的等級可按下表所示方式進行分類。擁塞等級為 5 或更高時，通常會影響 QoR 并且必然會導(dǎo)致布線器運行時間延長。
| 等級 | 影響范圍 | 擁塞 (Congestion) | QoR 影響 |
| 1、2 | 2x2、4x4 | 無 | 無 |
| 3、4 | 8x8、16x16 | 輕微 | 可能導(dǎo)致 QoR 惡化 |
| 5 | 32x32 | 中等 | QoR 惡化可能性較高 |
| 6 | 64x64 | 高 | 難以布線 |
| 7、8 | 128x128、256x256 | 無法操作 | 可能無法布線 |
為幫助識別擁塞，Report Design Analysis命令支持生成擁塞報告以顯示器件的擁塞區(qū)域，以及這些區(qū)域內(nèi)存在的設(shè)計模塊的名稱。此報告中的擁塞表會顯示布局器和布線器算法發(fā)現(xiàn)的擁塞區(qū)域。下圖顯示了擁塞表示例。
擁塞表
“Placed Maximum”、“Initial Estimated Router Congestion”和“Router Maximum”擁塞表可提供有關(guān)東西南北四個方向上擁塞最嚴重的區(qū)域的信息。選中該表中的窗口時，在“Device”窗口中會突出顯示對應(yīng)的擁塞區(qū)域。
3.生成設(shè)計復(fù)雜性報告
我們也可以通過設(shè)計復(fù)雜性報告來預(yù)判是否出現(xiàn)擁塞。我們可以對布局生成的DCP,通過以下Tcl命令生成設(shè)計復(fù)雜度報告。
?
report_design_analysis -complexity -name comp
?
復(fù)雜性報告 (Complexity Report) 可按頂層設(shè)計和/或?qū)蛹墕卧娜~節(jié)點單元的類型顯示 Rent 指數(shù) (Rent Exponent)、平均扇出 (Average Fanout) 和分布方式。Rent 指數(shù)是指在使用min-cut算法以遞歸形式對設(shè)計進行分區(qū)時，網(wǎng)表分區(qū)的端口數(shù)量和單元數(shù)量之間的關(guān)系。其計算方法與在全局布局期間布局器所使用的算法類似。因此，它可準確表明布局器所面臨的困難，當設(shè)計的層級與在全局布局期間所發(fā)現(xiàn)的物理分區(qū)匹配良好時尤其如此。
Rent 指數(shù)較高的設(shè)計表示此類設(shè)計中包含邏輯緊密相連的分組，并且這些分組與其它分組同樣連接緊密。這通常可理解為全局布線資源利用率較高并且布線復(fù)雜性也更高。此報告中提供的 Rent 指數(shù)是根據(jù)未布局和未布線的網(wǎng)表來計算的。完成布局后，相同設(shè)計的 Rent 指數(shù)可能改變，因為它基于物理分區(qū)而不是邏輯分區(qū)。
?復(fù)雜性報告
Rent 指數(shù)的典型范圍
“平均扇出”典型范圍
4.解決擁塞問題
根據(jù)前文所述造成擁塞的原因，我們可以采用以下辦法解決布線擁塞問題。
擁塞原因1：過多的MUXF（將MUXF轉(zhuǎn)化為LUT）
方法1：利用模塊化綜合技術(shù)，對特定模式設(shè)置MUXF_REMAPPING：
?
set_property?BLOCK_SYNTH.MUXF_MAPPING?1?[get_cells?top/instance]
?
方法2：在opt_design階段使用-remap選項：
?
opt_design -mux_remap -remap
?
方法3：針對特定MUXF設(shè)置MUXF_REMAP屬性為ture
?
set_property MUXF_REMAP 1 [get_cells -hier-filter {NAME=~ cpu*&& REF_NAME=~MUXF*}]
?
擁塞原因2：過長的進位鏈（將進位鏈轉(zhuǎn)化為LUT）
方法1：在opt_design階段使用-remap選項：
?
opt_design -carry_remap -remap
?
方法2：針對特定MUXF設(shè)置CARRY_REMAP屬性
?
set_property?CARRY_REMAP?2?[get_cells?-hier-filter?{?REF_NAME==CARRY8}]
?
擁塞原因3：過多的控制集（合并控制集）
方法1：利用模塊化綜合技術(shù)，對特定模式設(shè)置CONTROL_SET_THRESHOLD：
?
set_property?BLOCK_SYNTH.?CONTROL_SET_THRESHOLD?10?[get_cells?top/instance]
?
方法2：在opt_design階段，使用-control_set_merge合并等效控制集
?
opt_design -control_set_merge
?
方法3：在opt_design階段，使用merge_equivalent_drivers合并等效控制集，包括非控制邏輯
?
opt_design -merge_equivalent_drivers
?
擁塞原因4：過多的LUT整合（阻止LUT整合）
方法1：利用模塊化綜合技術(shù)，對特定模式設(shè)置LUT_COMBINING：
?
set_property BLOCK_SYNTH. LUT_COMBINING 0 [get_cells top/instance]
?
方法2：設(shè)定LUT的LUTNM屬性為空：
?
set_property LUTNM “”[get_cells hier-filter {REF_NAME =~LUT*&& NAME=~*/inst/*}]
?
在綜合階段，除了使用以上的方法外，對于IP，我們最好采用OOC的綜合方式。
在實現(xiàn)階段，可以選擇適當?shù)膶崿F(xiàn)策略來緩解擁塞。對于UltraScale系列芯片，可嘗試采用“Congestion_*”策略緩解擁塞；對于UltraScale+系列芯片，可嘗試采用“performance_NetDelay_*” 策略緩解擁塞。如下圖所示。
實現(xiàn)時解決擁塞策略
當然，我們也嘗試采用“performance_ExtraTimingOpt” 策略進行時序優(yōu)化，但可能無法解決擁塞問題。
你在FPGA布局布線過程中，遇到哪些問題呢？歡迎分享或留言。
審核編輯：劉清
工商網(wǎng)監(jiān)
評論