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内的逻辑数量。
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过于密集导致的。下图展示了一种比较极端的情况：
上图中左图为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)。
在某些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的情况，但对此类问题的解决方法又是另外一个话题了，以后有机会会开篇详谈。