解决Vivado implementation拥塞的策略方法

摘要：根据官方说法，尝试解决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警告）。

不过这三个问题在不改代码的前提下，可以去通过更改策略解决。