摘要：根據(jù)官方說法，嘗試解決post route里面的擁塞問題，參考文章在策略中一些參數(shù)細(xì)節(jié)的配置方法。參考文章中的

Vivado strategies：

針對性能：

Perfornance_Explore

Perfornance_ExplorePostRouteFhsopt

Perfornance_WLBlockPlacement

Perfornance_WLBlockPlacementFanoutopt

Perfornance_NetDelay_high

Perfornance_NetDelay_low

Perfornance_Retiming

Perfornance_ExtraTimingOpt

Perfornance_Refineplacement

Perfornance_SpreadSLLs

Perfornance_BalanceSLLs

針對布線擁塞：

Congestion_ SpreadLogic_high

Congestion_ SpreadLogic_medium

Congestion_ SpreadLogic_low

Congestion_ SpreadLogic_Explore

以下三個針對SSI芯片：

Congestion_ SSI_SpreadLogic_high

Congestion_ SSI_SpreadLogic_low

Congestion_ SSI_SpreadLogic_Explore

針對資源：

Area_Explore

Area_ExploreSequential

Area_ExploreWithRemap

針對功耗：

Power_DefaultOpt

Power_ExploreArea

針對運(yùn)行時間：

Flow_RunPhysOpt

Flow_RunPos tRoutePhysOpt

Flow_Runtimcoptinized

擁塞報(bào)告

第一步：打開布局或者布線后的DCP文件

第二步：在菜單下，依次選擇Reports -> Report Design Analysis，彈出如下圖所示對話框，只選擇圖中的Congestion，即可生成擁塞報(bào)告。

這里我們要格外關(guān)注Level列對應(yīng)的數(shù)據(jù)，該列數(shù)據(jù)表明了擁塞程度。

對于擁塞程度（Congestion Level），我們有如下判定標(biāo)準(zhǔn)：

擁塞程度≥7：設(shè)計(jì)幾乎不太可能收斂，布線極有可能失敗；

擁塞程度≥6：設(shè)計(jì)很難實(shí)現(xiàn)時序收斂，運(yùn)行時間會很長，而且很有可能出現(xiàn)布線失敗；

擁塞程度＝5：存在一定難度實(shí)現(xiàn)設(shè)計(jì)收斂；

擁塞程度＜5：可認(rèn)為設(shè)計(jì)不存在擁塞問題

我們再看看布線后生成的擁塞報(bào)告，如下圖所示。此時，我們要關(guān)注Type這一列。該列表明了擁塞的類型。

通常，有三類擁塞類型：Global、Long和Short。造成這三類擁塞的原因是不同的。

Global：擁塞區(qū)域的Combined LUT過多，或者控制集過多；

Long：擁塞區(qū)域的BRAM、URAM和DSP過多，或者跨die路徑過多；

Short：擁塞區(qū)域的MUXF或Carry Chain過多；

明確了擁塞類型，就可知道造成擁塞的原因，再結(jié)合報(bào)告中顯示的擁塞區(qū)域，進(jìn)而查找到相應(yīng)的模塊，就可以有的放矢，解決擁塞問題。但是，在解決擁塞問題之前要確保設(shè)計(jì)滿足以下幾點(diǎn)：

（1）約束是合理的

（2）Pblock之間沒有重疊

（3）不存在過大的Hold違例（WHS < -0.4ns）

測試

首先看擁塞的等級，可以分別采用Congestion_ SpreadLogic_high、Congestion_ SpreadLogic_medium等不同的策略去解決。

我在跑版本的時候發(fā)現(xiàn)，有的版本時序還行，但是功能完全不正確，warning比功能正確的版本要多。考慮到可能是策略不同所致，所以進(jìn)行了一些關(guān)于策略測試，不是很明白策略，只是單純的跑版本進(jìn)行測試。

具體策略每項(xiàng)的介紹可以看這篇文章：【vivado UG學(xué)習(xí)】Implementation策略學(xué)習(xí)_lu-ming.xyz的博客-CSDN博客_vivado 實(shí)現(xiàn)策略(https://blog.csdn.net/lum250/article/details/119920135)

在有擁塞的時候，使用congestion_spreadlogic_high策略，但是好像很容易會造成版本的unlock，這點(diǎn)不是很確定。

以058版本為例，時序在-0.5的版本是不行的，一般要在-0.5以內(nèi)，-0.4的樣子

第一次修改策略，其它不變，只改HigherDelayCost

第二次修改策略，有unlock的問題：

opt_design:Default

place_design:AtspeedLogic_high

phys_opt_design:AggressiveExplore

route_design:NoTimingRelaxation

（unenable）phys_opt_design:Explore

第三次修改策略：

opt_design:Default

place_design:AtspeedLogic_high

phys_opt_design:ExploreWithHoldFix

route_design:NoTimingRelaxation

（unenable）phys_opt_design:Explore

第四次修改策略：（無unlock問題，功能沒太大問題）

opt_design:Explore

place_design:AtspeedLogic_high

phys_opt_design:AggressiveExplore

route_design:NoTimingRelaxation

（unenable）phys_opt_design:Explore

058錯誤版本，無unlock問題，但是功能有問題：（同策略下跑出過正常版本很奇怪）

opt_design:ExploreArea

place_design:AtspeedLogic_high

phys_opt_design:Explore

route_design:NoTimingRelaxation

（unenable）phys_opt_design:Explore

058正式版本：（無lock問題，功能正確，時序微差）

opt_design:Default

place_design:AtspeedLogic_high

phys_opt_design:Explore

route_design:NoTimingRelaxation

（unenable）phys_opt_design:Explore

13 critical warning

354 warning

WNS：-0.429

TNS：-4010.661

057版本測試

057-0606（未通過）

opt_design:Explore

place_design:AtspeedLogic_high

phys_opt_design:Explore

route_design:NoTimingRelaxation

phys_opt_design:Explore

53 critical warnings

273 warnings

WNS:-0.438ns

總結(jié)

根據(jù)測試，簡單的判斷下來，在高LUT使用率以及擁塞的版本下，可暫時使用如下策略，雖然同策略跑出的其他版本在prach測試時有點(diǎn)偏差，但是不能夠確定是環(huán)境問題還是代碼問題：

opt_design:Default

place_design:AtspeedLogic_high

phys_opt_design:Explore

route_design:NoTimingRelaxation

（unenable or ennable）phys_opt_design:Explore

在使用策略的時候可以先不用更改策略內(nèi)的項(xiàng)，用每個策略的默認(rèn)項(xiàng)，待時序很差或者擁塞依舊不通過或者功能不正確時，再考慮更改某些項(xiàng)。

目前看下來，當(dāng)LUT使用過多，并且時序差的時候會有擁塞、unlock以及功能不正確的現(xiàn)象。我在使用congestion_spreadlogic_high策略的時候，很容易會有unlock的現(xiàn)象。功能不正確伴隨著的是時序竟然會好，這點(diǎn)很奇怪，感覺是由于策略過于激進(jìn)優(yōu)化掉了很多東西，造成了更多的warning（DRC警告）。

不過這三個問題在不改代碼的前提下，可以去通過更改策略解決。