2、拥塞度量指标：全局拥塞度、局部拥塞度、溢出单元数、拥塞热点图解读

各位工程师朋友，咱们接着聊。上一章我讲了拥塞是怎么产生的，这一章咱们来点实在的——怎么量化它。

你想想看，如果连拥塞的程度都说不清楚，你怎么去优化？所以，度量指标就是我们的“尺子”。我个人习惯把这套指标分成四个维度：全局的、局部的、具体的、可视化的。咱们一个一个来拆。

2.1 全局拥塞度（Global Congestion）

全局拥塞度，说白了就是看整个芯片的“平均拥挤程度”。它把整个版图划分成一个个小格子（G-Cell），然后统计每个格子里实际需要的布线资源，跟这个格子能提供的资源做个比值。

公式很简单：

全局拥塞度 = (所有G-Cell的布线需求总和) / (所有G-Cell的布线容量总和)

这个值如果超过 100%，说明整体资源不够用。但我得提醒你，全局拥塞度只是一个“平均数”。

所以，全局拥塞度适合做“快速筛查”。比如你跑完布局，一看这个值超过 120%，那基本可以断定这版布局要重来。但如果它在 90% 以下，也别高兴太早——还得看局部。

2.2 局部拥塞度（Local Congestion）

局部拥塞度，才是真正要命的指标。它关注的是每个小区域内的资源竞争情况。我一般会关注两个维度：

• 峰值拥塞度： 整个芯片里最堵的那个格子，它的拥塞度是多少。这个值决定了你的布线器能不能“挤过去”。
• 拥塞分布： 拥塞是集中在几个点，还是大面积铺开？这决定了你的优化策略是“局部手术”还是“全局换药”。

举个例子，我在一个 7nm 的项目里，全局拥塞度只有 92%，但局部峰值达到了 180%。那个区域正好是数据通路和时钟网络的交汇处。嗯，这里要注意——这种地方，你光靠调整线宽、加 spacing 是没用的，必须从 floorplan 层面去动。

2.3 溢出单元数（Overflow Cells）

这个指标更直接——它统计的是那些“实在塞不下”的格子数量。每个 G-Cell 都有固定的布线轨道数，如果需求超过了容量，多出来的部分就叫“溢出”。

溢出单元数通常分两种：

• 水平溢出： 水平方向（M1、M2 等）的轨道不够用
• 垂直溢出： 垂直方向（M3、M4 等）的轨道不够用

我习惯把溢出单元数当作“硬指标”。如果溢出单元数超过总 G-Cell 数的 5%，那这版布线基本没戏。为什么？因为 EDA 工具在处理溢出时，会强行绕线，结果就是线长暴增、时序变差、甚至出现天线效应。

// 一个简单的溢出检查脚本（伪代码）
for each G-Cell in design:
    demand = get_routing_demand(cell)
    capacity = get_routing_capacity(cell)
    if demand > capacity:
        overflow_count += (demand - capacity)
        
if overflow_count > total_cells * 0.05:
    print("⚠️ 溢出严重，建议重新布局")
else:
    print("✅ 溢出在可控范围内")

2.4 拥塞热点图解读

最后这个，是我最常用的工具——拥塞热点图。它把拥塞度用颜色映射到版图上，红色代表高拥塞，蓝色代表低拥塞。一眼就能看出问题区域。

怎么读这张图？我总结了三个步骤：

1. 找“红点”： 先看有没有深红色甚至紫色的区域。这些地方就是“堵点”。
2. 看“蔓延”： 红色是孤立的点，还是连成一片？连成一片说明是结构性拥塞，比如两个大模块之间的通道太窄。
3. 对“结构”： 把热点图叠到 floorplan 上，看看红色区域对应的是什么——是 SRAM 的边界？是时钟树的根部？还是数据通路的汇聚点？

我记得有一次，热点图上显示芯片右上角有一块深红色。我一开始以为是那个区域的 std cell 太密，结果放大一看——原来是电源网络（PG mesh）的 via 把布线轨道占满了。嗯，这种问题，你光看数字是看不出来的，必须看图。

下面这张图，是我自己整理的拥塞度量体系。你可以把它当作一个检查清单：

最后说一句，这四个指标不是孤立的。我通常的做法是：先用全局拥塞度判断这版布局要不要重来，然后用局部拥塞度找到具体的问题区域，接着用溢出单元数评估问题的严重程度，最后用热点图去验证和定位。一套组合拳下来，拥塞问题基本就无处遁形了。

好了，这一章就到这里。记住，度量是优化的第一步——你连问题都描述不清楚，就别谈解决了。