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

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

針對運行時間：

Flow_RunPhysOpt

Flow_RunPos tRoutePhysOpt

Flow_Runtimcoptinized

擁塞報告

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

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

這里我們要格外關注Level列對應的數據，該列數據表明了擁塞程度。

對于擁塞程度（Congestion Level），我們有如下判定標準：

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

擁塞程度≥6：設計很難實現時序收斂，運行時間會很長，而且很有可能出現布線失敗；

擁塞程度＝5：存在一定難度實現設計收斂；

擁塞程度＜5：可認為設計不存在擁塞問題

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

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

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

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

Short：擁塞區域的MUXF或Carry Chain過多；

明確了擁塞類型，就可知道造成擁塞的原因，再結合報告中顯示的擁塞區域，進而查找到相應的模塊，就可以有的放矢，解決擁塞問題。但是，在解決擁塞問題之前要確保設計滿足以下幾點：

（1）約束是合理的

（2）Pblock之間沒有重疊

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

測試

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

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

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

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

以058版本為例，時序在-0.5的版本是不行的，一般要在-0.5以內，-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

總結

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

opt_design:Default

place_design:AtspeedLogic_high

phys_opt_design:Explore

route_design:NoTimingRelaxation

（unenable or ennable）phys_opt_design:Explore

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

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

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