在数字后端设计里Congestion是最能骗人的问题之一。它不像DRC violation那样白纸黑字列在report前面也不像setup/hold那样能给出一个明确的slack数字它更像一座城市在高峰时段把所有车都赶上几个路口——你从全局热图上看只是局部红了几块可等route真的跑起来Overflow瞬间冲到四位数Hotspots从一个点烧成一大片。我见过不少团队在place阶段看到congestion report全绿就放心收工结果route stage第一天就翻车整个项目节奏被打乱最后灰头土脸地回来改floorplan。这篇文章不讲大道理就围绕Overflow和Hotspots这两个最常被挂在嘴边、也最容易被误读的指标把Congestion分析、定位、修复的完整思路展开讲一遍给正在被routing congestion折磨的后端工程师一份能直接落地的排查路线。1. Congestion的本质布线资源的账怎么算成Overflow1.1 先搞清楚供给上限track、GCell与blockageCongestion分析本质上是一笔供需账。物理设计里每一层金属都有自己的preferred directionM1水平、M2垂直高层金属的track pitch比低层宽能提供的走线数量也各不一样。router会把整个die划分成大量的小格子也就是GCellglobal routing cell的缩写然后对每个格子分别统计两笔数据一笔是demand代表这个格子里所有net需要穿过的线网量另一笔是supply代表这个格子可用的routing track数量。一旦demand超过supply多出来的那部分就叫overflow。这里的“可用”两个字是关键。一个GCell的物理空间是固定的但里面的资源会被很多东西扣掉macro内部不能走线、pin access区域要保留、power stripe占掉的track、预布线的clock shielding甚至hard macro边缘的halo都会把supply吃掉一截。所以我一直强调看congestion不能只盯着面积利用率同样面积的corefloorplan摆法不同真实的routing supply可能差出两到三成。后面所有placement和routing层面的优化都是在给定的这个供给上限下面腾挪供给本身不够的时候任何看起来很优雅的优化都只是把问题从A点搬到了B点。1.2 Overflow的三种读数总量、峰值与发生面积Overflow report一般会列这几个数total overflow是全局所有GCell溢出之和看的是整体资源缺口max overflow是溢出的单个GCell里最严重那个差了多少条track看的是局部严重程度而overflow GCell count则是发生溢出的格子数量反映的是拥堵覆盖面积。这三个数单独拿出来都有盲区配合起来才是一个完整画面。我自己的使用习惯是total overflow大而max overflow小代表整个区域均匀偏紧多半是utilization偏高或者整体supply不足total overflow一般但少数几个GCell的max overflow非常高那基本就是结构性hotspot比如macro通道、pin集中区、stripe横穿处。这两种情况背后的处理逻辑完全不同——前者要做placement spread、降密度、甚至调整面积规划后者要动floorplan、pin assignment或者特定区域的routing layer分配。所以拿到overflow数字先别急着改这改那先判断它是哪种类型否则很容易在错误的层面空转。1.3 为什么timing clean的设计route阶段照样崩这是很多团队的共同困惑synthesis和place的timing都过了congestion report看起来也不差怎么一到route就全线飘红。原因是早期阶段的congestion估算跟真实情况存在系统性偏差不是工具不行而是信息不完整。综合工具用的是virtual flat placement它没有一个真实的floorplanmacro位置和pin位置都是估算出来的。而且synthesis阶段同样没有clock tree没有power stripe也没有经过real legalization的真实cell位置。CTS本身是congestion的一个超大贡献者它会在时钟分支点上插入数量惊人的buffer/inverter这些cell面积不大但数量极多经常在不经意间制造出局部density高峰scan chain reorder和hold fixing再补一批delay cell这些在早期的congestion report里全都没有体现。所以我把“只看synthesis的congestion绿灯就放心”列为后端十大坑之一。至少要打开clock tentation或者估算clock tree的flow跑一版更接近真实情况的评估再决定要不要往下走。2. Hotspot读图方法论从红色格子定位到根因坐标2.1 三张图叠读density、GRC与hotspotCongestion map是可视化工具里最直观的输出但直接盯着红色看很容易被误导。我的标准动作是叠三张图第一张是placement density map看局部cell密度第二张是global routing congestion map看GRC的overflow分布第三张是工具自动标出的hotspot列表和坐标。三张图叠在一起才能回答“这个区域为什么堵”——是cell挤还是routing supply被吃因为两者的修复手段完全不同。判断方法并不复杂。如果density map和congestion map的红区高度重合说明是placement密度驱动的问题可以靠padding、spread、partial blockage这些placement手段解决。如果density正常但congestion红那就要往routing资源方向查看看是不是macro挡路、stripe占道、pin access区域过密这类结构性原因。我见过太多人一看到congestion红就开始乱加padding结果padding把面积撑爆legalization一片报错真正的问题一个没解决。2.2 Hotspot的分级与软硬判断工具通常会按threshold标出hotspot并给出坐标但我不建议完全照搬工具的默认阈值。基于我自己的项目经验大致可以按congestion ratio分四档ratio在100%到110%的先观察多半是flow噪声110%到120%的标记为watch本轮可以不处理但要持续跟踪120%到140%的本轮迭代必须处理超过140%并且出现在通道或者pin集中区的十有八九是结构性拥塞靠router自己绕是绕不过去的。除此之外还要学会判断hotspot的“软硬”。软的hotspot改一下cell padding、加一个partial blockage或者把place effort调高就消失了硬的hotspot是你试了padding、spread、换routing layer directive全都不见好转那就要做好回头动floorplan的准备。有个简单的测试方法把hotspot附近的cell手动spread开一些再重新place如果overflow明显下降说明是密度型问题如果纹丝不动那基本就是supply型问题必须从资源供给端解决placement层面再怎么调都是在原地打转。2.3 复盘一个真实hotspot问题根本不在红色区域里说一个我印象比较深的例子。某个带四个macro的blockcongestion map上有个很顽固的hotspot正好压在两排macro中间的channel里。我们第一反应是channel太窄把两边macro各挪了位置加宽channel结果hotspot只是换了个坐标数值一点没降。后来把trial route的结果按GCell dump出来逐个看穿过hotspot的net分布才发现问题根本不在channel内部——是channel两端的pin过于集中所有跨macro信号都被挤到同一个track row进进出出channel本身反倒只是过车通道真正堵的是两头的“收费站”。最后把pin重新均匀铺开hotspot才真正消失channel宽度反而没怎么动。这个案例给了我一个很深的习惯hotspot只是结果数据流方向才是原因。工具给出的坐标负责帮你定位但要靠net trace、pin density report和信号流分析去回答“是谁把资源吃掉的”。如果只盯着红色格子做局部优化大概率是治标不治本修完一版换一个地方继续红。3. 容易导致Congestion的六大设计因素按优先级排查3.1 Macro摆放所有congestion的先天基因Macro是congestion的第一大来源因为它同时从需求和供给两端施加影响。从供给端看macro整体占据的区域内所有routing layer都无法走线相当于在routing资源地图上挖掉一块从需求端看macro边缘的pin会产生高密度pin access所有连到这些pin的net都要在macro外围挤。两个macro如果靠得太近中间形成的channel会成为信号穿越的必经之路一旦net数量超过channel能提供的track数hotspot立刻成形。我评估macro布局时有个习惯不只看面积还要估算“每条channel大概要过多少net”。如果某条channel两侧macro的pin很多这个channel的宽度就要留足别把routing demand estimation省掉。还有macro pin朝向问题pin面向core内部的macro通常会在内侧产生额外拥塞有时候只需要把macro旋转180度让pin朝外hotspot就能消掉一大半。这类调整成本最低但必须在place之前做等place跑完再挪macro代价就大了。3.2 Pin分配与跨block信号通道拥堵的头号嫌疑人子模块的pin位置、pin间距和pin的疏密程度直接决定信号从block边界进来之后如何散开。pin挤在一条边上接口逻辑cell就只能放在那附近这些cell各自需要track从pin接入局部demand瞬间抬高。跨block信号更危险如果boundary两侧的pin位置没有对齐track不得不在通道里斜穿甚至换层浪费的可就不止一条track了。检查手段是看boundary pin density report算一下每微米有多少pin。超过经验值就要处理对soft macro或者允许调整pin order的block尽量让pin均匀交错排列别把所有bus堆在同一个edge上。很多floorplan阶段的congestion其实改一版pin assignment就解决了根本不用动placement。我在实际项目里见过一个block光是把一组64-bit bus从edge中央拆成两半均匀分布GRC overflow直接降了40%效果比后面调三天placement都明显。3.3 利用率与局部Cell Densityglobal不堵不等于局部不堵后端里最常见的误判之一就是看到全局utilization只有70%就觉得安全。实际上一旦RTL里某个module逻辑特别密place之后这个module所在区域会形成一个高density island局部utilization可能超过100%。congestion看的是局部不是全局。所以看utilization report时我习惯同时拉一个按区域划分的density详情而不是只看一个global数字。面对这种密度型hotspot最快的软手段是加cell padding把拥堵模块里的cell左右各pad掉几个site物理上占得稍大一点demand降得很快。但padding是吃面积的全局utilization超过85%时要小心padding过头会引发overlap和legalization问题。我一般从1到2个site开始试看hotspot的变化再逐步加绝不一上来就下猛药。3.4 时钟树与Power Stripe两只隐形占道者CTS插入的buffer和低层金属上的power stripe是两种最常见的“看不见的占道”。CTS带来的congestion在synthesis评估阶段根本看不出来因为那个时候还没有clock treepower stripe则是物理上把routing layer的track直接切掉一块尤其在低层金属上走stripe时对track的消耗相当可观。排查hotspot的时候如果density正常、pin也不密我第一个想到的就是看看hotspot附近有没有stripe横穿、有没有CTS buffer集中地。遇到stripe造成的congestion把stripe绕开一点或者换到更高层走经常比调一堆placement选项都管用。CTS buffer集中导致的局部拥堵可以用CTS option把局部buffer插入密度限制住或者提前在floorplan阶段给时钟buffer预留区域。这两个因素都属于“静默型”问题不专门查很容易忽略。3.5 逻辑结构MUX树、高扇出net与datapath有些congestion是网表结构带来的floorplan再完美也压不下去。比如一串mux级联的数据选择逻辑每一级都会产生新的netbus宽度一大同一区域内的track需求成倍上涨再比如高fanout net在综合优化时会在驱动端本地插出一个buffer tree这个buffer tree周围就是一个天然的cell密集区。这类问题在物理阶段能做的事情有限最好的处理窗口其实在综合阶段。能调整RTL结构就调整结构比如把集中的mux tree打散减少不必要的多级选择不能动RTL的就对高fanout net设置合理的physical constraint别让综合工具把所有buffer都堆到一个点上。等到了place阶段再发现逻辑结构问题能做的只是把demand稍微摊开结构性代价已经付出了。3.6 多电压域与Level Shifter的边界效应多电压域设计里电压域交界处会插入大量level shifter和isolation cell。这些cell有固定面积往往只能放在power domain边界附近导致边界区域密度天然偏高。如果这个边界再恰好落在floorplan的通道上congestion基本躲不掉。这种情况下不要硬调placement应该在floorplan阶段就给level shifter区域预留好空间或者把电压域边界挪到routing资源更充裕的位置。提前规划比事后补救省事得多因为level shifter的数量和位置并不是place工具能自由决定的它们被power domain的边界牢牢绑定。4. Overflow数据对比方法如何把数字变成决策4.1 值得长期盯的三个指标直接给一张表说明我这几年盯数据的习惯。指标含义我常用的参考线出现异常时的优先动作Total Overflow全局所有GCell的溢出总和反映整体资源缺口中小block建议控制在几百以内四位数就要警觉先看是均匀偏高还是集中在局部均匀偏高优先降密度、提supplyMax Overflow单个GCell的最大溢出track数反映最差点的严重程度超过5到8条基本就是结构性hotspot信号定位到坐标按前面说的软硬判断走Overflow GCell Count发生溢出的GCell数量反映拥堵覆盖面积面积占比超过5%要注意结合density map判断是密度型还是供给型这组指标我建议每跑完一版place就记录一次慢慢积累同一个block的历史曲线。单独看某一版的绝对值很难判断严重程度但overflow相比上一版是涨是降、hotspot是不是换了位置这些趋势信息反而比绝对值更有决策价值。4.2 三个阶段各看什么synthesis、place、routeSynthesis阶段看的是趋势。virtual flat placement下的congestion如果有明显hotspot说明网表结构本身存在逻辑集中问题最好在综合阶段就让前端或综合工程师介入改结构或调约束。这个阶段数值本身不精确但方向足够可信值得认真对待。Placement阶段看的是主战场。经过真实floorplan和legalization之后GRC overflow已经相当接近最终结果这也是修复congestion的最佳窗口。这个阶段的hotspot每个都要有明确结论——是版本波动还是真问题是fix还是track必须记录在案不能模棱两可。Route阶段看的是验证。global route之后的数据基本可以当作最终congestion的预演。如果到这里才第一次看overflow留给你的操作空间已经很小了大部分修复都要回到place甚至floorplan去重跑。所以我把route阶段的congestion report当“验尸报告”用用来检验前面各阶段的判断是否到位而不是用来临场救火。4.3 一份可复用的排查命令思路工具命令各家略有差异但分析思路完全一致。以Innovus环境为例我常用的动作大致是这几个# 报告整体congestion带overflow和hotspot坐标 reportCongestion -global_route -overflow -hotspot -output_file congestion.rpt # 针对某个热区出细分报告锁定x1 y1 x2 y2范围内的情况 reportCongestion -global_route -report_by_gcell { x1 y1 x2 y2 } -output_file area_cong.rpt # 提高placement的congestion优化力度 setPlaceMode -place_global_cong_effort high -place_detail_cong_effort mediumICC2环境对应的思路是report_congestion配合set_app_options调整congestion effort命令名字不同但分析路径是一样的。关键不在于记命令而在于每次拿到report之后都做同一套动作先看总量再看峰值最后定位坐标。还有个我一直在用的小技巧把GRC overflow按GCell写到CSV在表格软件里按坐标排序自己画一个溢出热力分布。工具自带的图适合快速浏览自己导出的数据适合算数——比如算hotspot面积占core的比例、统计overflow集中在哪个坐标区间这些量化指标能帮你更早发现规律而不是每次都说“感觉这里有点红”。5. Hotspot修复动作优先级先软后硬从Padding到Floorplan5.1 先试软手段padding、partial blockage与region约束修复hotspot我基本遵循“先软后硬”的顺序因为软手段迭代成本低往往跑一版place就能验证。第一梯队通常是对拥堵区域内的cell加padding把cell之间的空隙拉大降低局部demand在hotspot区域放一个低密度的partial placement blockage把一部分cell温和地挤出去却不至于把这个区域完全清空对明确知道要放的模块用region约束提前规划好位置避免place工具乱撒cell。这三个手段见效快适合在place阶段内部循环迭代。但它们的本质是把demand往旁边赶如果周边资源也不够效果会很有限而且可能把hotspot挪到隔壁区域。所以每用一步都要看一眼全局别把局部问题修成另一个局部问题。我自己的经验是padding加完之后一定重新出一次overflow分布图确认原来的hotspot周边没有新增红区。5.2 布局级调整macro微调与通道加宽软手段无效就要进入第二梯队回floorplan做布局级调整。比如前面反复提到的macro通道问题加宽channel、调整macro之间的相对位置、旋转macro让pin朝外这类动作成本比软手段高但效果是结构性的修完不会反弹。这里有个节奏问题先做影响面小的微调比如只挪一个macro、只加宽一段channel跑一版place看hotspot如何变化再决定要不要大动。一次别同时改太多东西否则hotspot变化了你根本不知道是哪个改动起的作用。我的习惯是一次只动一个变量记录hotspot坐标和overflow数值的变化形成一组对照数据。调macro时还要顺手看一眼timing挪位置可能会让某些路径变长别congestion修好了setup又红了。5.3 route阶段的补救空间与边界如果你已经走到了route阶段才发现congestion操作空间确实小但不是完全没有。可以试试调整routing layer directive让部分net走资源更充裕的层或者提高绕线优化力度让router多跑几轮还可以针对热点区域设定更细致的routing guide。另外via pillar、track assignment这些细节手段在小范围、轻度拥塞的场景下能救一救。但必须清醒route阶段的修复只是“疏通”解决不了结构性供给不足。如果total overflow四位数、hotspot成片老实回到place和floorplan重来比在route里硬扛省时间得多。跑route run之前先看一眼overflow提前判断这版值不值得跑这笔时间账要会算。我见过有人在一个结构性hotspot上反复跑route tuning跑了整整一周最后发现把macro挪开1.2微米一版place就彻底解决了。5.4 回归验证怎么确认真的修好了修复完不是看hotspot消失就结束了还要排查两个反向问题一是hotspot是不是被挪走了而不是消失了对比修复前后的hotspot坐标列表确认没有在相邻区域新增二是congestion修好之后timing有没有恶化特别是padding和spread对density的影响可能会让路径边长、插buffer变多。每次修复动作之后我习惯把congestion report、hotspot坐标、关键path的QoR三个东西放在一起对比三张表都稳定才敢收工。最后说句个人感受。做了这么多年后端我遇到的大多数顽固congestion追到底都是floorplan阶段埋下的macro摆位、pin分配、通道预留、电源方案这些在早期看起来只是“有点挤”的小决定到了route阶段都会变成让人抓狂的hotspot。Congestion分析的价值不在于修得多漂亮而在于尽早把账算清楚——早期多花半天做一次认真的supply和demand评估好过route阶段烧掉三五天的run time最后还得回头改floorplan。另一件值得做的事是给每个block维护一份congestion历史记录哪怕只是简单的overflow数字和hotspot坐标连续记上几个版本之后你对这个block的“脾气”会比任何人都清楚再遇到问题基本一眼就能判断该往哪个方向查。