产生Congestion的主要原因

Congestion意思为拥塞，一般是在后端PR阶段发现布局布线比较拥挤，可能会导致布线布不过去，出问题也无法做ECO。

Congestion也分为几种情况，和前端密切相关的是LogicCongestion（更多关于后端Congetsion问题，查看文末参考文章），主要原因是RTL设计问题导致，这种问题的现象从后端看上去就是Cell数没多少，就是线密。

产生Congestion的主要原因

有限的面积下，电路面积过大。从一开始预估的面积与最后实际的面积有一定差距，导致该模块面积被限定的情况下，逻辑较多，绕线严重。

大位宽信号做选择逻辑。假如有一个信号定义为3万bit，然后它还需要送到几个模块去做选择器，从里面挑数，这样就是3万根线，连来连去，这样的设计必然有问题。这样惊人的设计最后怎么能用呢。只能说，工艺牛逼！

选择器太大。选择器的选择项多，设计复杂的情况下，难免会有选择器的选择项有大几十上百个的情况。

信号负载大。一个参数信号可能用到了很多地方，驱动数个像上面那样的大mux，这样的信号的负载会非常大。

组合逻辑路径长。组合逻辑路径长，时序比较紧的地方，工具会做一些优化增加绕线，这样的结果会加重后端拥塞。

以上问题会出现归根结底就是设计方案和方法的问题。

几个无效的尝试

怎么解决，假设一个前提，时间紧迫，如果对时序逻辑进行大的改动，需要调试的时间较长，严重时造成项目delay。所以只能在不改变时序的情况下，只对组合逻辑进行优化。

模块划分重构，目的是想减少模块之间的耦合度，重新划分，把耦合度强的模块放到接近，模块的层级调整，比如三级模块变二级模块。但是，从后端布线上看，其实看不出模块边界，关联度高的模块甚至会揉在一起的，工具自动按元器件关联较近的方式布局布线，甚至会把你一个模块分成距离很远的两部分。这样修改可以减少耦合度，有效果但不明显。

大mux拆分成小mux。将单一的大mux拆分成多级小选择器，每一级之间用寄存器打断。但是，如果不用寄存器打断拆分，可能没啥用，因为工具也是这么做的。归纳可能会省去很多多余的分支。但在不改变时序的情况下做拆分基本无收益，因为只是在RTL级别上看的大mux写法的不同，实际上还是由众多小mux组成的。

降低信号的负载，参数寄存器复制多份，送给不同的模块。数据通路的寄存器也可以进行复制，减少信号的负载。但是综合加max_fanout约束后，工具会自动插buffer和复制寄存器的操作，而且因为面积本身有限，时序的优化带来的收益还会被寄存器的增加所抵消。

总结一下，就是忙碌了半个月的硅农师傅，白忙活了。

有效的修改优化总结

运算逻辑复用，节省面积给逻辑走线。先选后比/加/乘/模块。

乘法器复用打拍位置调整，乘法器模块的复用把打拍放在复用模块的输出，而不是传输到各个模块中才打拍，节省寄存器开销，负载的问题，前面也说了，工具会自动插buffer和复制寄存器。

重定时（retiming）技术，改变寄存器的打拍位置，节省寄存器。

打断较复杂的组合逻辑，中间插入寄存器，时序变好，即使寄存器增多，面积（可能）反而会变小。

大于1k的寄存器组考虑用RAM替代，但用RAM读取数据需要进行时序控制逻辑，并行度会降低。要求并行度高，可使用多个RAM。面积和速度永远是两个背道相驰的努力目标。所以要Trade Off（折中）

后端喜欢，深度深，位宽小的RAM，这样最后的bit/面积的值会更大。举例说明就是Depth128xWidth16和，Depth16xWidth128相比最后的面积大小，前者会比后者小很多。简单来说，后端喜欢细长的，不喜欢粗短的。

RAM也可以复用，前面计算用完空闲下来的RAM，可以复用起来。

交给后端同事吧（逃）。

审核编辑 ：李倩