今天想说一说，遇到congestion问题的时候，一般都是通过什么手段解决的。
在此之前先普及一下congestion的概念，以防没有基础的同学不清楚我们在说什么。Congestion在后端通常指绕线阻塞，即局部或者整体绕线资源不够的现象。产生congestion的原因有很多，可能是后端的原因，也可能是前端的原因。我们将针对不同的成因说明该如何解决。
1、RTL阶段
一般是由大的MUX、大的Crossbar造成的，解决方法是将设计拆分，大模块分成小模块；
对于大扇入的MUX，可以通过级联MUX优化走线问题；对于大扇出，例如一个FSM驱动多个block，可以通过复制这个FSM来优化走线问题。
2、PR阶段
跟Congestion相关的主要包括以下几个部分：宏单元、标准单元、Power Mesh。
1、宏单元与宏单元之间
如上图所示的为Channel Congestion：此种现象比较常见，也比较简单，多发生于hard macro之间。
上图中，每一个灰色多边形代表一个macro。之所以用这种形状是因为实际设计中的某些memory会做成这种外形。黄色部分代表macro的pin，在此每个macro都只有一个方向有pin。图中也展示了两种典型的macro摆放方式：普通的毗连和背靠背。无论何种摆放方式，当macro之间的空隙不足以满足需要穿过的net所需要的资源的时候，就会发生channel congestion。因此，在floorplan阶段，考虑每个channel中可能穿过的net数量，配合metal layer层数和routing rule估算绕线资源是通常需要后端设计者考虑的事。遇到channel congestion时最简单的想法当然是增大macro距离，但这并不是总是有用，尤其是channel中有逻辑cell穿过的时候，设计者需要根据design的逻辑规划数据走向，控制channel内的逻辑数量。
当相邻的两个Macro距离很近时，由其是Memory，多个Memory的数据线和地址线在狭窄的空间内无法找到足够的布线通道，通常会发生Congestion。
解决办法：
a）加大宏单元的间距，可以设置placer_soft_keepout_channel_width，让工具在较小的channel间放置soft blockage
b）调整Macro的位置、摆放方向，注意出Pin的方向，为出pin的区域留出足够的空间，避免产生狭窄的通道。
c）另外当多个Memory共用相同的数据线或者地址线时，可以调整它们的位置，使它们的Pin对齐，这样连线会比较规整，对Congestion有帮助，即相关的macros进行group。
2、宏单元与标准单元之间
（a）标准单元不能离宏单元太近，宏单元周围要放置Placement Blockage。可以设置physopt_hard_keepout_distance在宏单元四周放置hard blockage，或者create_placement_blockage -name -type -bbox
（b）由其注意Macro出Pin的方向一定要留出channel，否则Macro离std太近不容易出Pin。可以使用命令set_keepout_margin -type hard -outer {10 0 10 0} RAM
（c）另外要注意之前摆放宏单元的规则，注意尽量靠近角、边，给中间的标准单元一个连续的区域。
3、标准单元与标准单元之间
可以分为两种情况：
3.1局部高密度标准单元引起的congestion
大量的绕线通过高密度标准单元区域时，有时候会发生局部的较为严重的congestion。
解决办法：
a）为了解决局部congestion，我们通常会借助partialblockage降低局部区域的标准单元密度。Partial blockage是placement blockage的一种，是某一区域设定标准单元的利用率。有时候用partialblockage，并不能有效的解决congestion，这时候可以用blockage array来解决此类congestion。Blockage array是用“blockage阵列”的方式，控制congestion区域的标准单元的在区域内成条状分布：一方面降低了密度，另一方面预留出了布线通道。create_placement_blockage -name -type -bbox
b）限制阻塞区域的placement的密度：set_congestion_options -max_util 0.4 -coordinate {x1 y1 x2 y2}
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与标准单元之间
PG(Power Ground)Congestion：此种情况多由于power/ground的结构不合理或者过剩导致的。如下图所示：
上图红色方框中的均为PG via，我们可以看到，金属接触的部分全部打满了via。在实际设计中，电源网络的密度和via的数量其实是需要比较精确的估算的，因为过于密集的PG会占用过多的绕线资源，从而降低整体的绕通性。常用的手段是，如果在芯片局部出现绕线紧张的现象，会通过删除部分pg via/shape来释放一部分绕线资源。当然，这样做的前提是电源网络足够稳固(robust)，IR-drop和power EM不会发生很大恶化。
High Cell Density Congestion：此种congestion主要是由于局部或整体的cell过于密集导致的。下图展示了一种比较极端的情况：
high cell density congestion:上图中左图为cell density map，右图为routing congestion map。density map颜色越深意味着density越高，同理congestion map颜色越深意味着绕线资源越紧张。可以看出density越高的地方基本上congestion也越严重。在实际设计中，局部出现这种congestion的情况比较常见，我们可以通过很多手段来控制局部的density：placement blockage（soft hard partial), keepout margin(cell spacing constraint), cut row等。与此同时，工具也会提供一些功能来控制局部density，比如icc2的place.coarse.max_density。
High Pin Density Congestion：此种congestion多发生于多pin cell集中的区域。下图展示了两种常见的多pin cell：AOI(and/or/inverter)和多位选择器(selector)。
multi-input cells在某些design中，如果不加控制，逻辑综合的结果可能是几百上千个此类cell聚集在一起从而造成某个区域的net十分密集。在place阶段，尽管工具会尝试把这些cell尽量推开，但是由于逻辑本身的限制优化空间有限。因此需要综合阶段配合，选择合适的cell来综合网表。例如可以禁用此类cell，使综合工具将其逻辑进行拆分。但是这样做的后果是可能导致design的逻辑数量增加，面积增大，功耗上升。因此需要对各方面的影响进行评估。
Logic Congestion：此类congestion可以说是最棘手的问题之一。因为在后端结果看来，可能这类congestion的区域中cell density很低，也没有或者很少有多pin cell，周围也没有marco阻挡，但是congestion却一塌糊涂。原因可能在于前端工程师为了节省面积而将某一个模块复用多次，连接了过多的input或者output；也可能是design中存在大量的同级选择逻辑(如几百位的选择器)。原因不一而足，需要后端工程师去深入分析design才能得出结论。这类问题需要向前端工程师反馈，与他们沟通能否修改RTL，而且常常以牺牲面积或者性能为代价。
以上就是后端常见的几种congestion问题，实际设计中可能每个人针对每种问题都有自己的解决方法，但是问题的根本原因不会改变。大家在项目中还需要多一些深入分析和摸索，寻找问题背后的原因并形成解决方案。除了在prects和preroute阶段尽量解决congestion，在routing之后可能仍然会出现剩余大量short/drc的情况，但对此类问题的解决方法又是另外一个话题了.
数字IC版图设计中如果PowerMesh打的太多，下方还放置的有标准单元，那么在出Pin的地方可能会存在Congestion
解决方案：
1、减少power，不要打太多，根据以往经验和IR-drop分析的结果，可以在IR-drop满足的情况下，减少Power Mesh，不用占用太多布线资源。
2、另外可以在布局之前设置让软件在Power下面不要放太多单元，设置partial blockage，partial density control。如下图所示，可以非常清晰的看到，大部分的拥塞都发生在Power Mesh附近，这可以通过对Power Mesh设置partial blockage来解决。set_pnet_options -partial {metal2 metal3} set_pnet_options -complete {metal2 metal3}
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了。
解决方案：
（1）调整电源地规划方案。
（2）如果设计中有很大的拥塞，需要赶快解决。在Floorplan阶段也没有必要把设计中的拥塞全部降到0，因为此时软件只是快速做了一个参考布局方案而已，并非实际的布局，所以某些拥塞并没有完全解决，它们可以在后续的布局阶段解决。由于ICC允许可以不沿着格点布线（即Zroute模式），所以在布线阶段也会解决一部分拥塞。
原文链接：https://blog.csdn.net/CrazyUncle/article/details/114794018?ops_request_misc=%257B%2522request%255Fid%2522%253A%2522165365574716782248529517%2522%252C%2522scm%2522%253A%252220140713.130102334.pc%255Fall.%2522%257D&request_id=165365574716782248529517&biz_id=0&utm_medium=distribute.pc_search_result.none-task-blog-2~all~first_rank_ecpm_v1~rank_v31_ecpm-8-114794018-null-null.142^v11^control,157^v12^control&utm_term=pnet+%E7%94%B5%E6%BA%90&spm=1018.2226.3001.4187