一、拥塞的物理根源：标准单元密度过高、宏单元布局不合理、电源网络规划不当

大家好，我是老陈。做后端十几年了，每次看到新手对着拥塞报告抓耳挠腮，我就想起自己刚入行那会儿。说实话，拥塞这东西，你光看报告是看不出名堂的。你得去摸它的根，去理解它到底是怎么来的。

今天咱们就聊聊拥塞的三个物理根源。说白了，就是三个“罪魁祸首”：标准单元密度太高、宏单元摆得不对、电源网络规划有问题。这三样东西，任何一个出问题，都会导致绕线资源被抢来抢去，最后拥塞就来了。

核心观点：拥塞的本质是“资源竞争”。绕线资源就那么多，你抢我抢，最后谁都过不去。

你想想看，一条马路本来能并排走四辆车，你硬塞进去八辆，那肯定堵死。芯片里也一样。标准单元放得太密，绕线通道就不够了。

我个人习惯，在布局阶段就会盯着局部利用率看。什么叫局部利用率？就是在一个小区域内，标准单元占的面积比例。一般来说，超过70%就要警惕了。我在项目中遇到过，有个模块局部利用率干到了85%，结果布线阶段直接爆了，绕线器跑了三天都没跑通。

为什么会这样？因为标准单元之间需要走线。每个单元都有输入输出 pin，这些 pin 需要连起来。单元越密，pin 越挤，绕线器就得绕来绕去，最后绕不过去就报错。

我的经验：布局阶段用工具跑一下 congestion map，看到红彤彤一片的区域，赶紧调。别等到布线再后悔。

这里有个常见的误区：有人觉得把单元堆在一起能省面积。嗯，省面积是省了，但布线资源被挤没了。最后为了绕开拥塞区域，绕线器会绕大圈，反而把面积撑大了。得不偿失。

宏单元，比如 Memory、PLL、ADC 这些，个头大，pin 多，而且通常有固定的形状。它们往那一放，就像在马路中间立了根柱子，绕线通道直接被切断。

我记得有个项目，设计师把几块大 Memory 并排放在芯片中央，结果把整个芯片的横向绕线通道全堵死了。标准单元只能从上下两边绕，拥塞得一塌糊涂。

宏单元布局有几个要点：

避坑指南：我曾经把两个 Memory 面对面放，中间留了条窄缝。结果那缝里的标准单元密度爆表，绕线器直接罢工。后来我把它们错开摆放，问题就解决了。

说白了，宏单元布局就像城市规划里的“大型建筑”。你不能把体育馆、火车站全堆在一个路口，得分散开，留出道路。

电源网络，也就是 PG（Power Ground）网格，是给芯片供电的。它由一层层的金属线组成，横平竖直，覆盖整个芯片。但问题来了——这些金属线也是绕线资源的一部分。

你想想看，PG 网格把金属层占掉了一部分，信号线能用的 track 就少了。如果 PG 网格太密、太粗，信号线就得在夹缝中求生存。

我见过一个设计，为了降低 IR Drop，工程师把 PG 网格做得特别密，每条线都加宽。结果呢？IR Drop 是降了，但绕线资源被吃掉了一大半，拥塞得一塌糊涂。最后不得不返工，把 PG 网格调稀一些，才把布线跑通。

这里有个平衡点：

我个人习惯，在规划 PG 网格时，会先跑一个快速拥塞评估。如果发现某个区域拥塞严重，就适当调稀 PG 网格，或者把部分 PG 线改到更高层——高层金属资源相对充裕。

关键点：PG 网格不是越密越好。要在 IR Drop 和拥塞之间找到平衡。我一般先按 foundry 的推荐值来，然后根据实际拥塞情况微调。

这三个根源，说白了就是“资源竞争”的三种表现形式。标准单元密度高，是微观层面的竞争；宏单元布局不合理，是宏观层面的阻塞；PG 网格规划不当，是基础设施层面的挤占。

遇到拥塞问题，别急着调绕线参数。先看看这三个方面有没有问题。很多时候，根源找到了，问题就解决了一半。

一个小技巧：用工具的 analyze_congestion 命令，它会告诉你拥塞是由什么引起的。是标准单元太密？还是宏单元挡住了？还是 PG 网格占太多？一目了然。

好了，这一章就聊到这儿。下一章咱们聊聊怎么具体分析拥塞报告，到时候我会拿一个真实案例出来，带大家一步步看。