在FPGA開(kāi)發(fā)設(shè)計(jì)中，我們可能會(huì)經(jīng)歷由于資源占用過(guò)高的情況，例如BRAM、LUT和URAM等關(guān)鍵資源利用率達(dá)到或超過(guò)80%，此時(shí)出現(xiàn)時(shí)序違例是常有的事，甚至由于擁塞導(dǎo)致布線(xiàn)失敗，整個(gè)FPGA工程面臨無(wú)法生成bit文件的危險(xiǎn)。

那么，有沒(méi)有辦法來(lái)解決這類(lèi)問(wèn)題呢？

此類(lèi)問(wèn)題是FPGA設(shè)計(jì)實(shí)現(xiàn)中比較棘手的問(wèn)題，Xilinx針對(duì)7系列及以后的UltraScale/UltraScale+等，提出了UltraFast設(shè)計(jì)方法論，用于指導(dǎo)該系列器件的成功設(shè)計(jì)和實(shí)現(xiàn)，完成復(fù)雜系統(tǒng)設(shè)計(jì)。

時(shí)序收斂是指設(shè)計(jì)滿(mǎn)足所有的時(shí)序要求。針對(duì)綜合采用正確的 HDL 和約束條件就能更易于實(shí)現(xiàn)時(shí)序收斂。通過(guò)選擇更合適的 HDL、約束和綜合選項(xiàng)，經(jīng)過(guò)多個(gè)綜合階段進(jìn)行迭代同樣至關(guān)重要，如下圖所示。

Xilinx提出的實(shí)現(xiàn)快速收斂的設(shè)計(jì)方法論

FPGA布線(xiàn)擁塞怎么辦？

如果關(guān)鍵路徑在擁塞區(qū)域內(nèi)或者緊鄰擁塞區(qū)域，或者是資源利用率較高，都會(huì)導(dǎo)致時(shí)序收斂困難。在很多情況下，擁塞會(huì)消耗大量的布線(xiàn)時(shí)間，甚至布線(xiàn)失敗。如果布線(xiàn)延遲顯著大于預(yù)期值，那么我們就得考慮降低設(shè)計(jì)的擁塞程度。

在確保時(shí)序約束和物理約束正確的情況下，我們可以通過(guò)以下方法解決擁塞問(wèn)題。

1.擁塞類(lèi)型

Xilinx FPGA布線(xiàn)結(jié)構(gòu)包括東、南、西、北共4個(gè)方向不同長(zhǎng)度的互聯(lián)資源。擁塞區(qū)域以最小的正方形體現(xiàn)，這個(gè)正方形覆蓋了相鄰的互聯(lián)資源或CLB單元。

“Device”視圖中的擁塞等級(jí)和擁塞區(qū)域

擁塞包括3種類(lèi)型：全局擁塞、短線(xiàn)擁塞和長(zhǎng)線(xiàn)擁塞。

擁塞類(lèi)型

擁塞類(lèi)型	主要原因
全局擁塞：在特定區(qū)域內(nèi)擁有較高的布線(xiàn)資源利用率	過(guò)多的LUT整合
	過(guò)多的控制集
	過(guò)多的總線(xiàn)
	布局不合理
短線(xiàn)擁塞：缺少短距離布線(xiàn)資源，常見(jiàn)于UltraScale系列芯片	MUXF利用率過(guò)高
	進(jìn)位鏈利用率過(guò)高
長(zhǎng)線(xiàn)擁塞：缺少長(zhǎng)距離布線(xiàn)資源，常見(jiàn)于UltraScale系列芯片	Rent、Average Fanout的值過(guò)高
	Block RAM、UltraRAM、DSP使用率過(guò)高且互聯(lián)嚴(yán)重
	過(guò)多的穿越SLR的路徑

2.生成設(shè)計(jì)擁塞報(bào)告

為了檢查擁塞程度，我們可以基于布局之后生成的DCP，通過(guò)以下Tcl命令生成設(shè)計(jì)擁塞報(bào)告。

report_design_analysis -congestion -name cong

分析擁塞時(shí)，工具報(bào)告的等級(jí)可按下表所示方式進(jìn)行分類(lèi)。擁塞等級(jí)為 5 或更高時(shí)，通常會(huì)影響 QoR 并且必然會(huì)導(dǎo)致布線(xiàn)器運(yùn)行時(shí)間延長(zhǎng)。

等級(jí)	影響范圍	擁塞 (Congestion)	QoR 影響
1、2	2x2、4x4	無(wú)	無(wú)
3、4	8x8、16x16	輕微	可能導(dǎo)致 QoR 惡化
5	32x32	中等	QoR 惡化可能性較高
6	64x64	高	難以布線(xiàn)
7、8	128x128、256x256	無(wú)法操作	可能無(wú)法布線(xiàn)

為幫助識(shí)別擁塞，Report Design Analysis命令支持生成擁塞報(bào)告以顯示器件的擁塞區(qū)域，以及這些區(qū)域內(nèi)存在的設(shè)計(jì)模塊的名稱(chēng)。此報(bào)告中的擁塞表會(huì)顯示布局器和布線(xiàn)器算法發(fā)現(xiàn)的擁塞區(qū)域。下圖顯示了擁塞表示例。

擁塞表

“Placed Maximum”、“Initial Estimated Router Congestion”和“Router Maximum”擁塞表可提供有關(guān)東西南北四個(gè)方向上擁塞最嚴(yán)重的區(qū)域的信息。選中該表中的窗口時(shí)，在“Device”窗口中會(huì)突出顯示對(duì)應(yīng)的擁塞區(qū)域。

3.生成設(shè)計(jì)復(fù)雜性報(bào)告

我們也可以通過(guò)設(shè)計(jì)復(fù)雜性報(bào)告來(lái)預(yù)判是否出現(xiàn)擁塞。我們可以對(duì)布局生成的DCP,通過(guò)以下Tcl命令生成設(shè)計(jì)復(fù)雜度報(bào)告。

report_design_analysis -complexity -name comp

復(fù)雜性報(bào)告 (Complexity Report) 可按頂層設(shè)計(jì)和/或?qū)蛹?jí)單元的葉節(jié)點(diǎn)單元的類(lèi)型顯示 Rent 指數(shù) (Rent Exponent)、平均扇出 (Average Fanout) 和分布方式。Rent 指數(shù)是指在使用min-cut算法以遞歸形式對(duì)設(shè)計(jì)進(jìn)行分區(qū)時(shí)，網(wǎng)表分區(qū)的端口數(shù)量和單元數(shù)量之間的關(guān)系。其計(jì)算方法與在全局布局期間布局器所使用的算法類(lèi)似。因此，它可準(zhǔn)確表明布局器所面臨的困難，當(dāng)設(shè)計(jì)的層級(jí)與在全局布局期間所發(fā)現(xiàn)的物理分區(qū)匹配良好時(shí)尤其如此。

Rent 指數(shù)較高的設(shè)計(jì)表示此類(lèi)設(shè)計(jì)中包含邏輯緊密相連的分組，并且這些分組與其它分組同樣連接緊密。這通?？衫斫鉃槿植季€(xiàn)資源利用率較高并且布線(xiàn)復(fù)雜性也更高。此報(bào)告中提供的 Rent 指數(shù)是根據(jù)未布局和未布線(xiàn)的網(wǎng)表來(lái)計(jì)算的。完成布局后，相同設(shè)計(jì)的 Rent 指數(shù)可能改變，因?yàn)樗谖锢矸謪^(qū)而不是邏輯分區(qū)。

復(fù)雜性報(bào)告

Rent 指數(shù)的典型范圍

“平均扇出”典型范圍

4.解決擁塞問(wèn)題

根據(jù)前文所述造成擁塞的原因，我們可以采用以下辦法解決布線(xiàn)擁塞問(wèn)題。

• 擁塞原因1：過(guò)多的MUXF（將MUXF轉(zhuǎn)化為L(zhǎng)UT）

• 方法1：利用模塊化綜合技術(shù)，對(duì)特定模式設(shè)置MUXF_REMAPPING：

set_property BLOCK_SYNTH.MUXF_MAPPING 1 [get_cells top/instance]

• 方法2：在opt_design階段使用-remap選項(xiàng)：

opt_design -mux_remap -remap

• 方法3：針對(duì)特定MUXF設(shè)置MUXF_REMAP屬性為ture

set_property MUXF_REMAP 1 [get_cells -hier\-filter {NAME=~ cpu*&& REF_NAME=~MUXF*}]

• 擁塞原因2：過(guò)長(zhǎng)的進(jìn)位鏈（將進(jìn)位鏈轉(zhuǎn)化為LUT）

• 方法1：在opt_design階段使用-remap選項(xiàng)：

opt_design -carry_remap -remap

• 方法2：針對(duì)特定MUXF設(shè)置CARRY_REMAP屬性

set_property CARRY_REMAP 2 [get_cells -hier\-filter { REF_NAME==CARRY8}]

• 擁塞原因3：過(guò)多的控制集（合并控制集）

• 方法1：利用模塊化綜合技術(shù)，對(duì)特定模式設(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：過(guò)多的LUT整合（阻止LUT整合）

• 方法1：利用模塊化綜合技術(shù)，對(duì)特定模式設(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/*}]

在綜合階段，除了使用以上的方法外，對(duì)于IP，我們最好采用OOC的綜合方式。

在實(shí)現(xiàn)階段，可以選擇適當(dāng)?shù)膶?shí)現(xiàn)策略來(lái)緩解擁塞。對(duì)于UltraScale系列芯片，可嘗試采用“Congestion_*”策略緩解擁塞；對(duì)于UltraScale+系列芯片，可嘗試采用“performance_NetDelay_*” 策略緩解擁塞。如下圖所示。

實(shí)現(xiàn)時(shí)解決擁塞策略

當(dāng)然，我們也嘗試采用“performance_ExtraTimingOpt” 策略進(jìn)行時(shí)序優(yōu)化，但可能無(wú)法解決擁塞問(wèn)題。