首先，我们需要了解拥塞的类型和原因。通常，拥塞可以分为三类：Global、Long和Short。Global拥塞是由于拥塞区域的Combined LUT过多，或者控制集过多造成的；Long拥塞是由于拥塞区域的BRAM、URAM和DSP过多，或者跨die路径过多造成的；Short拥塞是由于拥塞区域的MUXF或Carry Chain过多造成的。
接下来，我们需要了解Vivado提供的布线拥塞解决策略。Vivado提供了多种策略，包括针对性能的Performance_Explore、Performance_ExplorePostRouteFhsopt等，针对布线拥塞的Congestion_SpreadLogic_high、Congestion_SpreadLogic_medium等，针对资源的Area_Explore、Area_ExploreSequential等，针对功耗的Power_DefaultOpt、Power_ExploreArea等，以及针对运行时间的Flow_RunPHYsOpt、Flow_RunPos tRoutePhysOpt等。这些策略可以根据设计的特点和需求选择使用。
在实际应用中，我们可以先使用默认的策略，如果时序很差或者拥塞依旧不通过或者功能不正确时，再考虑更改某些项。此外，还可以参考其他相关文献，例如文章“vivado UG学习”中提供的策略介绍，以帮助我们更好地理解和选择合适的策略。
通过以上策略的实施，我们可以有效地解决布线拥塞问题，提高集成电路设计的质量和效率。在实际应用中，我们需要结合设计的特点和需求，灵活运用各种策略，以达到最佳的效果。
摘要：根据官方说法，尝试解决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警告）。
不过这三个问题在不改代码的前提下，可以去通过更改策略解决。
