解决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警告）。

 

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