2. 拥塞的物理与逻辑成因

拥塞不是某一个环节单独造成的错误，而是物理资源与逻辑需求在版图局部失衡后的综合表现。理解成因的价值在于：当工具报告 overflow 时，我们能判断它是“单元太挤”“引脚太密”“走线通道不够”“宏单元挡路”，还是“时钟树和逻辑结构把需求推高”，从而选择正确的优化手段，而不是盲目降利用率或反复重跑。

一、物理侧：资源供给被谁消耗

标准单元密度决定单元行内还有多少空隙可供布线穿越。利用率（utilization）是单元面积占核心面积的比例，但它只是平均值。真正影响拥塞的是局部利用率：某 20μm×20μm 窗口内利用率达到 85%，即使全芯片只有 60%，该窗口也会先溢出。原因是标准单元引脚和内部金属会占用 M1、M2 的布线轨道，单元越密，可穿越的轨道越少。

引脚密度比单元密度更直接。一个反相器只有 2 个引脚，而一个 8 输入与门或复杂 AOI 单元可能有十几个引脚，且集中在很小的区域内。当高引脚单元成排摆放时，其周围需要大量短连线接入，局部引脚/面积比急剧上升，形成“引脚墙”。典型判断是观察 pin density 热图：若某区域引脚密度超过 0.6 pins/μm²，即使利用率不高，也容易出现局部 DRC 和 overflow。

布线资源是供给端。可用轨道数由金属层数、线宽、间距、通孔规则和 blockage 共同决定。例如某工艺 M2 水平方向 track 间距 0.14μm，一个 100μm 宽的区域理论上有约 714 条轨道，但扣除电源地线、宏单元引脚和 keep-out 后可能只剩 400 条。若该区域需求为 520 条，overflow 就是 120 条。这个差值才是拥塞的真实度量。

二、结构侧：宏单元与时钟树如何改变地形

宏单元布局制造的是“地形障碍”。SRAM、PLL、模拟 IP 通常占据多个金属层，其上方不能走线，边缘还有 keep-out 和引脚密集区。若把两个 SRAM 紧贴放置，中间只留 5μm 通道，而两侧单元又需要跨通道连接，这条通道就会成为瓶颈。更隐蔽的问题是宏单元把核心区域切分成不规则碎片，使全局布线器难以均匀分配资源。

时钟树是后期拥塞的常见推手。CTS 前，时钟网络只是逻辑连接；CTS 后，工具插入大量缓冲器和长时钟线，这些缓冲器本身占面积、引脚多，时钟线又常被约束到特定层并需要屏蔽。一个 200MHz、覆盖 5 万寄存器的时钟树，可能插入上千个时钟缓冲器，集中在时钟根附近，使原本宽松的区域突然变挤。若时钟树与数据路径争抢同一层资源，局部 overflow 会明显上升。

三、逻辑侧：深度与扇出放大需求

逻辑深度影响的是路径长度和绕行倾向。深组合逻辑意味着信号要穿过很多级单元，若这些单元被摆放得分散，连线就必须跨越多个区域，占用更多轨道。深度本身不直接等于拥塞，但它让布局对位置更敏感：一旦关键路径被拉长，工具会倾向于把相关单元拉近，进一步推高局部密度。

高扇出是最典型的逻辑成因。一个驱动 500 个负载的信号，如果只用一级缓冲，布线器需要从一点引出 500 条线，呈放射状穿过周围区域，形成“扇出锥”。即使每条线很短，总轨道需求也很大。实际处理中通常插入缓冲树，把扇出分级，但缓冲器本身又增加单元和引脚。因此高扇出不是简单“加缓冲就好”，而是要在扇出级数、缓冲器位置和区域密度之间折中。

四、共同作用：从局部到全局的传导

这些因素很少单独出现。一个典型场景是：某模块利用率 78%，看似安全，但其中两个 SRAM 紧贴，中间通道仅 6μm；同时该模块有一个 400 扇出的复位信号，CTS 后时钟缓冲器又集中在 SRAM 上方。此时局部窗口的可用轨道被宏单元、时钟线和扇出锥同时占用，overflow 迅速升高。布线器为了绕开障碍，会把连线推到相邻区域，导致相邻区域也变挤，形成全局拥塞的连锁反应。

因此，分析拥塞时应按“供给—需求—地形”三条线同时看：供给看轨道数和 blockage，需求看单元/引脚/扇出，地形看宏单元和时钟树。只调其中一项，往往只是把 overflow 从一个窗口搬到另一个窗口。

五、可执行的排查顺序

面对 overflow 报告，建议按以下顺序定位主因，避免盲目优化：

1. 先看局部利用率热图：若高 overflow 窗口与高利用率窗口重合，优先降局部密度或加 placement blockage。
2. 再看引脚密度热图：若利用率不高但引脚密度高，检查是否有高引脚单元成排，考虑打散或换低引脚单元。
3. 检查宏单元通道：测量宏单元之间、宏单元与边界之间的通道宽度，若小于布线所需轨道对应宽度，调整宏单元位置或方向。
4. 检查时钟树分布：看 CTS 后缓冲器是否集中在某区域，必要时约束时钟缓冲器分布或调整时钟树层次。
5. 检查高扇出网络：列出扇出大于 100 的网络，确认是否已插入缓冲树，缓冲树是否落在拥挤区域。
6. 最后看逻辑深度：若以上都正常，检查深逻辑路径是否导致单元过度聚集，考虑逻辑复制或流水化。

理解这些成因的最终目的，是建立“看到 overflow 就能反推原因”的判断力。局部溢出先查密度和引脚，通道瓶颈先查宏单元，后期突然恶化先查时钟树，大面积分散溢出则要回到逻辑结构和扇出。只有把物理供给和逻辑需求放在同一张图上衡量，才能选择真正有效的收敛策略。