拥塞（Congestion）是评价一个后端设计是否能绕线绕的通的重要评价指标，在Floorplan阶段等阶段有重要指导作用，这里对其进行介绍，并对其解决方案罗列一二。

congestion map

图1 在ICC布局规划之后报告的拥塞图

congestion map详细解析

图2 ICC中的Congestion map图

下面给出了report_congestion的报告：

图3 ICC中的Congestion报告

在图3中，“Max” overflow是13，意味着至少有一个GRC的边界overflow是13。也就是说这条边要额外走13条线，可是却没有额外的布线资源来供它进行布线。总共的GRC overflow是2.73%，意味着设计中所有GRC的边界大约有2.73%存在着overflow。

根据经验，一般最大的Overflow如果超过10基本上这个设计就无法布通了，最好不要超过3~5。另外如果总共的overflow超过2%，也可以认为设计在后边很难绕通。这些说明Floorplan不是很好，需要修改Floorplan或者重新进行Floorplan，需要看拥塞出现在什么地方，根据不同情况不同对待。

如果设计中出现很大/很多拥塞，该如何解决？

数字集成电路中，跟Congestion相关的主要包括以下几个部分：

宏单元、标准单元、Power Mesh。Congestion可能发生在任何两个之间，下面对各种情况进行罗列并给出参考解决方案。

1、宏单元与宏单元之间

当相邻的两个Macro距离很近时，由其是Memory，多个Memory的数据线和地址线在狭窄的空间内无法找到足够的布线通道，通常会发生Congestion。

解决方案：

调整Macro的位置、摆放方向，注意出Pin的方向，为出pin的区域留出足够的空间，避免产生狭窄的通道。另外当多个Memory共用相同的数据线或者地址线时，可以调整它们的位置，使它们的Pin对齐，这样连线会比较规整，对Congestion有帮助。

2、宏单元与标准单元之间

标准单元不能离宏单元太近，宏单元周围要放置Placement Blockage。由其注意Macro出Pin的方向一定要留出channel，否则Macro离std太近不容易出Pin。另外要注意之前摆放宏单元的规则，注意尽量靠近角、边，给中间的标准单元一个连续的区域。

3、标准单元与标准单元之间

可以分为两种情况：

3.1 局部高密度标准单元引起的congestion

大量的绕线通过高密度标准单元区域时，有时候会发生局部的较为严重的congestion。

为了解决局部congestion，我们通常会借助partialblockage降低局部区域的标准单元密度。Partial blockage是placement blockage的一种，是某一区域设定标准单元的利用率。有时候用partialblockage，并不能有效的解决congestion，这时候可以用blockage array来解决此类congestion。Blockage array是用“blockage阵列”的方式，控制congestion区域的标准单元的在区域内成条状分布：一方面降低了密度，另一方面预留出了布线通道。

3.2局部高密度pin cell导致的congestion

在数字逻辑设计中，如果某些模块用了大量的高密度pin标准单元（如AOI、OAI等），这些标准单元会有很多的互联关系，这样就会导致在有限的空间内，存在大量的绕线，从而发生congestion。

解决方案：

1）在逻辑综合中，禁用这些高密度pin的标准单元，这样综合出的网表中就不会有这些单元了，或者用DC的高级功能—DCG来解Congestion；

2）有针对性的降低此种标准单元的密度，如在ICC里，可以对这些标准单元设置keep_out_margin。通过此种方法，可以有效的削弱congestion；

3）对于层次性（Hier）设计而言，如果拥塞基本发生在某个模块内部，那么可以单独针对该模块设置Plangroup，并设置它的利用率，可以通过尝试找出既不会有太大Congestion，又不会太浪费面积的参数设置，如下图所示：

4）当然除了3）之外，某些含有很多AOI、OAI单元的模块而言，也可以用RelativePlacement的方法来解决，因为这些模块大多是datapath，完成某类复杂数学运算的单元，其中大部分的datapath都有规律可循，如果让PR工具自己做Placement，摆放可能比较乱，且利用率也比较低，如果用手工分析摆放的方式，那么利用率甚至可以大于95%，且不会有Congestion，因为单元摆放比较规整，走线也都很规整。不过这种方式比较耗时，手工成分非常高，现在也有一些研究用人工智能、机器学习（ML）方式来自动做Relative Placement的（后续会发相关研究的推文，敬请期待！）。如下图所示：

4、Power Mesh与标准单元之间

解决方案：

1、减少power，不要打太多，根据以往经验和IR-drop分析的结果，可以在IR-drop满足的情况下，减少Power Mesh，不用占用太多布线资源。

2、另外可以在布局之前设置让软件在Power下面不要放太多单元，设置partial blockage，partial density control。如下图所示，可以非常清晰的看到，大部分的拥塞都发生在Power Mesh附近，这可以通过对Power Mesh设置partial blockage来解决。

 

5、Power Mesh与宏单元之间

这种情况可能不多见，如果出现了多半也是恰巧在Macro出Pin的地方上方有Strap。这种情况要注意，由于Memory这类Macro外边要做Macro的PGRing，Memory里面的PG网络也非常密集，有如Rail一般，都需要连到Macro的PG Ring上，且如果上方有Strap的话也会连上去。对于出Pin的地方如果有Strap，因为Strap会通过Via一路打到M1或者M2层的Rail上，那么这些地方可以说路都被封死了，Macro当然就很难出Pin了。

示意图如下：

解决方案：

调整电源地规划方案。

如果设计中有很大的拥塞，需要赶快解决。在Floorplan阶段也没有必要把设计中的拥塞全部降到0，因为此时软件只是快速做了一个参考布局方案而已，并非实际的布局，所以某些拥塞并没有完全解决，它们可以在后续的布局阶段解决。由于ICC允许可以不沿着格点布线（即Zroute模式），所以在布线阶段也会解决一部分拥塞。

随着工艺节点的深入，在14纳米以下的后端设计中，GR阶段的Congestion结果和实际DR之后的DRC结果之间的Correlation会非常差，以至于GR阶段的Congestion结果不是十分准确，甚至会误导EDA工具进行布局以及布线，想知道以后先进的人工智能、机器学习如何解决这种问题么？