上个月帮人看一个 block 的 PR 收敛对方发来的第一句话是“这玩意儿利用率才 68%怎么 congestion 红成一片”我打开 GUI 看了一眼 placer 结果标准单元在中间堆得密不透风四周留了一大片空地两个 macro 之间最窄的那条通道只剩下六个 track而恰好有三个 module 的 pin 全挤在通道边上。这不是 density 问题这是 floorplan 问题——把 target density 从 0.72 调到 0.62 也救不回来只会让工具把单元摊得更开、net 拉得更长最后 timing 和 congestion 一起崩。density 和 congestion 是数字 IC 后端设计里被讨论最多、也被误解最多的两个词。几乎每个做 PR 的人都遇到过“数字看着不吓人、图看着要命”的情况也都试过在 ICC2 或 Innovus 里翻参数、加 blockage然后发现效果和预期完全相反。这篇内容就围绕 PR 工具里 density 与 congestion 的控制展开把两者到底指什么、在 flow 的哪个阶段用什么手段干预、两个主流工具的命令怎么对应以及我这些年踩过的坑一次讲透。不管你是刚接手第一个 block 的新人还是已经独立带项目的工程师下面的内容都可以直接抄去用。1. 先把话说清楚density 和 congestion 不是同一件事1.1 工具报出来的那个 density只是四种 density 里的一种很多人一上来就问“density 控制在多少合适”这个问题本身缺少前提。在数字后端语境下density 至少可以指四种东西标准单元的面积利用率cell density / placement density、单位面积内的引脚数量pin density、金属层的走线密度metal density以及功耗密度power density。PR 工具报出来的那个百分比通常是第一种偶尔是第二种的统计平均。真正让布线堵死的是第二种。所以经常出现这样的错位利用率只有 60%但局部 pin density 高得离谱因为那一块全是小面积、多引脚的功能单元比如各种时钟门控、多路选择器、扫描链上的组合逻辑平均到整个 block 上就被稀释掉了。反过来一块全是 macro 和 buffer 的区域利用率能到 90%但走线需求很低一点都不堵。density 类型物理含义主要影响观察方式cell / placement density单元 footprint 占 core 面积比例合法化难度、IR drop、局部走线需求利用率报告、GUI 的 density mappin density单位面积内 pin 个数局部 GCell 的走线需求量pin density heat map、拥塞热点图叠加metal density各层金属覆盖率制造端的 CMP / DRC 规则签核阶段的密度检查power density单位面积功耗IR drop、电迁移功耗分析、IR 分析提示看数字之前先确认口径。工具报告里的利用率是否包含 macro、是否包含 physical-only celldecap、filler、tap、是否包含 hard macro 内部的单元不同口径算出来的数字能差十几个百分点。我习惯的做法是先让工具输出一张把利用率图和 pin density 图叠在一起的图。利用率高的地方不一定堵利用率中等但 pin density 高的地方基本就是要出事的地方。这个判断顺序很关键它决定了你后面是调 density target还是去动 floorplan。1.2 congestion 报告里的 overflow本质是在数“track 不够用”绝大多数 PR 工具的拥塞度量都建立在一个叫 GCellInnovus 里叫 gcell 或 tileICC2 里叫 global routing cell / tile的网格上。工具先把绕线区域切成网格在每个网格里统计两件事可用于走线的 track 数量供给以及这个网格里所有 net 的预估走线需求需求。需求超过供给的部分就是 overflow分水平和垂直两个方向分别统计。这个定义带来几个非常实用的推论。第一congestion 报告必须在 global route 之后看才有意义place 阶段直接报出来的数字往往是估算别拿它当结论。第二overflow 的单位是“多少个 track”不是百分比所以一个 total overflow 200 的 block 和一个 total overflow 2000 的 block严重程度完全不是一个量级判断严重性要看最大值和热点面积而不是总和。第三供给是跟可用层数直接相关的你把信号可用层从 M2 到 M6 收到 M2 到 M4等于把供给砍掉三成congestion 报告立刻变脸——所以调层数和调 density 这两件事千万别同时改否则你分不清是谁的功劳。注意换了一层绕线规则、改了 PG mesh 宽度、动过 floorplan 之后一定要重新跑一次 global route 再出 congestion 报告。拿着三天前的报告分析今天的设计是新手最常见的浪费时间的做法。1.3 为什么利用率 70% 的 block 反而比 85% 的更堵这是最反直觉的一点也是我在评审会上被问得最多的问题。利用率低不代表走线需求低造成这种反常的原因主要有五个macro 之间的通道太窄。利用率低往往是因为 macro 占了大块面积单元只能塞在剩下的缝隙里而这些缝隙就是仅有的走线资源。10 个 track 宽的通道放两条总线级的 net 就满了。pin 集中在某些边界。hierarchical block 的 pin 如果全堆在一条边上那条边的局部走线需求会爆掉跟整体利用率无关。PG mesh 吃掉了 track。电源网格是要占走线资源的一条宽 3 微米的电源条在低层占掉的 track 数量非常可观。mesh 越密信号可用资源越少。长 net 和被拉高的 fanout。单元摊得越开net 越长工具为了满足 timing 会在中间插 buffer而 buffer 又占用面积和 pin 资源形成正反馈。partial blockage 加得太随意。随手圈出来的部分阻塞区域会把单元挤到本来就紧张的通道里。所以正确的顺序是先判断堵的原因在哪一类再决定动什么。利用率高但分布均匀、pin density 不高的 block往往只需要微调利用率不高但通道窄、pin 集中的 block调 density target 是缘木求鱼。2. 把 congestion 掐死在 floorplan 阶段2.1 macro 摆放与通道预留halo 的取值是有逻辑的floorplan 阶段花的每一分力气在 place 和 route 阶段能省十倍。macro 摆放最核心的约束是通道宽度。我的经验公式是先统计这个通道两侧要穿过的净线数量再估算平均每根净线需要的 track 数一般按 1.2 到 1.5 根保守估计含 buffer 插入和绕行余量乘起来除以可用层的 track 密度得到理论最小通道宽度然后在这个基础上再加 30% 到 50% 的余量。halo 的取值同理不是拍脑袋给 2 微米。如果 macro 边缘有大量 pin、并且这个方向上有走线需求halo 就应该给到能容纳一条完整 bus 的宽度如果 macro 边缘是空白的、没有 pinhalo 可以小一些把面积让给标准单元。那种“所有 macro 一律加 2 微米 halo”的做法在 macro 密集的设计里会白白浪费大量面积最后利用率上不去只能靠加大 core 面积来补偿。提示halo 和 keepout margin 的四元组参数顺序是左、下、右、上。写{2 2 2 2}的时候看不出任何问题一旦写成不对称的{2 2 2 4}你以为是左右窄、上下宽工具理解的可能完全不是一回事。不对称参数一定要查手册确认顺序。2.2 block pin 的位置决定了一半的 congestionhierarchical 设计里block pin 的处理是被严重低估的一环。pin 的位置和间距直接决定了边界处的局部走线需求而且这个影响会在顶层集成时被放大。几条我固定会做的事第一pin 尽量按数据流方向分布不要为了连线好看把 pin 集中在一侧。让 pin 靠近它真正的驱动源和负载net 的走线路径最短。第二控制相邻 pin 的间距。把一堆 pin 无间隔排成一行等于在那一小段边界上制造一个必然的热点。工具通常有 pin 分布的约束比如均匀分布到边上、限制单个区域内的 pin 数floorplan 阶段就该打开。第三给 pin 预留扇出通道。block 边界附近留出几个微米的区域不要放单元让 pin 出来的线有地方走。这个区域可以用 placement blockage 实现也可以用 pin 附近的 keepout 实现。第四feedthrough 要慎用。feedthrough 看起来解决了连线问题但它把一个 net 的走线需求压进了本来就很紧的内部资源里如果 feedthrough 的区域本来就是热点那就是雪上加霜。2.3 先算 track 预算再谈利用率我在做任何 block 之前都会做一次 track 预算core 面积 × 可用层数 × 每层单位面积的 track 数 总 track 供给再把所有 net 的预期长度估一遍粗略乘以绕行系数一般 1.3 到 1.6得到总需求。需求除以供给如果超过 0.7这个 floorplan 的利用率目标就必须往下调没有第二条路。顺带说一句电源网格。PG mesh 的间距和宽度直接决定了信号层还剩多少资源。mesh 做得越密IR drop 表现越好但给信号留的 track 越少congestion 越容易爆。我的习惯是先按 IR 分析给出一个“刚好够”的 mesh 方案然后在低层不要铺得过宽把高层资源尽量留给信号。如果某个 block 的 PG 结构特别重比如有多组不同电压域、需要额外做 level shifter 和 isolation cell 的区域它的利用率目标必须比普通 block 再低 5 到 8 个百分点。3. ICC2 侧density 与 congestion 的具体控制点3.1 place.coarse.max_density 和它周围那几个选项ICC2 里跟 placement density 最直接相关的就是place.coarse.max_density。它的含义是 global placement 阶段允许的最大局部密度上限注意是“上限”而不是“目标值”。把它设成 0.75工具会尽量避免任何局部区域超过 0.75但不会主动把所有区域都填到 0.75。# ICC2确认当前版本里有哪些与 placement 相关的 app option list_app_options -name place* ./rpts/app_options_place.rpt get_app_options -name place.coarse.max_density这里必须强调一件事不同版本的 ICC2app option 的名字是有差异的尤其是跟 congestion driven placement 相关的那些开关。我见过好几个人从旧脚本里抄参数结果工具默默忽略了这个选项有的版本只是打一句 warning 就继续跑跑完发现没任何变化还以为是设置无效。所以每换一次工具版本第一件事就是用list_app_options把相关选项列一遍确认名字还在不在。report_app_options -non_default部分版本可用能直接列出所有被改过的非默认值更适合排查“到底哪个设置生效了”。设置的原则是先按 floorplan 的余量给一个全局值再对局部热点做定向限制。全局值设得太低工具会把单元摊平net 变长timing 变差设得太高合法化和局部热点都会失控。经验区间是 0.65 到 0.78 之间具体看 pin density 和 macro 占比。3.2 placement blockage 与 keepout margin 的正确写法ICC2 里控制局部密度的主力是create_placement_blockage它支持 hard 和 partial 两种类型。hard 就是完全不放单元partial 则是限制该区域内的最大利用率。# ICC2全局密度上限 局部降压 macro 周边 keepout set_app_options -name place.coarse.max_density -value 0.72 create_placement_blockage -type partial -utilization 55 \ -boundary {{1200 800} {1400 1100}} -name pb_hotspot_1 create_placement_keepout_margin -type hard \ -objects [get_cells -hier -filter is_hard_macro true] \ -outer_margin {2 2 2 2}几个实操要点。第一partial blockage 的-utilization是相对该区域面积的比例设成 55 意味着这块地方最多塞 55% 的单元。如果你把已经存在的热点区域圈起来设成 40工具会把单元推到周边所以要提前评估周边有没有空间否则会形成新的热点典型的按下葫芦浮起瓢。第二blockage 的边界坐标是绝对坐标跟 core 边界的相对关系会随 floorplan 调整而改变所以最好的做法是把这些坐标写到脚本里由变量计算得出而不是硬编码。第三-filter里用到的属性名比如判断是不是 hard macro 的属性在不同版本里可能不同用之前先用get_attribute确认。还有一个容易被忽略的点placement keepout margin 和 routing keepout margin 要配套用。只给 placement 加 keepout信号线还是会从 macro 上方穿过去只给 routing 加 keepout 而 placement 允许放则会出现单元压在 macro 上方、pin 被挡住的情况。两个一起加并且 routing keepout 通常要比 placement keepout 稍大一点给走线留出绕行空间。3.3 从 place_opt 到 route_opt 的收敛节奏ICC2 的流程大概是place_opt→clock_opt→route_opt。congestion 的处理窗口主要在前两步到了 route_opt 阶段能做的已经很有限了。我的习惯是分阶段看 congestionplace_opt 完成后重跑一次 global route出一张热点图如果这时候就有大面积热点不要继续往下走 CTS先把 floorplan 和 placement 层的问题解决。理由很简单CTS 会插入大量时钟 buffer 和门控单元这些单元集中在时钟树主干附近会把本来只是“黄”的区域推到“红”。我有一个项目就是 placement 阶段 overflow 看着还好做完 CTS 直接爆了回头查发现时钟树主干正好压在一个本来就紧的通道上如果当时先动一下 floorplan 把主干移开能省两周时间。# ICC2绕线层规划跟 density 设置要分开调 set_routing_layers -signal M2:M7 -clock M2:M8层数规划这件事单独说一下。把 signal 的最高层从 M7 降到 M5等于砍掉了大量供给congestion 必然上升反过来把信号放上高层低层的压力立刻缓解。但高层资源通常要留给电源网格和时钟不是你想用就能用。所以层数规划要和 PG 方案一起定而且要一次改一个变量改完重新出报告对比否则你永远不知道是哪个改动起了作用。4. Innovus 侧对应套路与命令对照4.1 setPlaceMode 里真正影响 congestion 的参数Innovus 的 placement 控制在setPlaceMode里跟密度和拥塞直接相关的参数有几个控制最大局部密度的、控制拥塞优化力度的、以及打开时钟和功耗感知的。# Innovusplacement 阶段的密度与拥塞相关设置 setPlaceMode -place_global_max_density 0.72 setPlaceMode -place_global_cong_effort high setPlaceMode -timingDriven true setPlaceMode -place_global_clock_power_driven true-place_global_max_density和 ICC2 的place.coarse.max_density语义接近都是局部密度上限。-place_global_cong_effort是 Innovus 的特色调高它会显著增加 global placement 阶段在拥塞评估上的计算量跑得慢但出来的单元分布更“避开”热点。这个参数我一般只在第一次跑或者 congestion 明显超标时开到 high日常迭代用默认值就够了不然一轮 place 从四十分钟变成两个小时迭代效率掉得厉害。提示Innovus 的参数名在不同版本间也有变化尤其是带place_global_前缀的这一批。脚本里写死之前用man setPlaceMode或者help setPlaceMode把参数列表打出来核对一遍比事后 debug 便宜得多。4.2 blockage、halo、padding 的取舍Innovus 侧控制局部密度的手段有三个层次从粗到细分别是placement blockage、halo、instance padding。# Innovus局部降压、macro halo、以及局部禁止走线 createPlaceBlockage -type partial -density 45 -box {1200 800 1400 1100} addHaloToBlock {2 2 2 2} -allBlock createRouteBlk -box {1200 800 1400 1100} -layer {M3 M4}createPlaceBlockage的-type可以是 hard 或 partialpartial 配合-density使用效果和 ICC2 的 partial blockage 对应。addHaloToBlock给所有 macro 统一加 halo参数同样是左、下、右、上写不对称的时候一定要确认顺序。至于给单个 instance 或 module 加 padding让某个单元周围强制留空减小局部 pin 密度Innovus 各版本的命令不太统一老流程里常见的是specifyInstPad一类的命令新版本更推荐用模块级的 padding 选项。如果你只是想解决个别热点不想纠结命令名字直接用 partial placement blockage 圈一小块区域把密度压到 40 到 50效果基本等效而且命令稳定——这也是我在赶进度时最常用的做法。还有一个细节Innovus 里 partial blockage 的密度值和-place_global_max_density是叠加生效的实际局部上限取两者中更严的那个。所以别出现全局设 0.72、局部 blockage 设 0.8 这种没意义的组合那块区域实际还是按 0.72 走。4.3 nanoRoute 阶段的兜底手段到了布线阶段congestion 的处理空间已经很窄了但还有几招可以用。# Innovus布线阶段常用设置 setNanoRouteMode -routeWithTimingDriven true setNanoRouteMode -drouteEndIteration 20 setNanoRouteMode -drouteAutoStop false-drouteEndIteration加大迭代次数让工具在收敛 DRC 的同时多做几轮绕线优化-drouteAutoStop false关掉自动停止防止工具觉得“差不多了”就提前收工留下没修完的 overflow。这两个参数配合用在 overflow 只是零星热点的时候能救回来一部分。再往后的optDesign -postRoute阶段工具会做 post-route 的优化包括 spread wire把走线在空间上摊开、插 buffer 修 timing、以及一些局部的绕线调整。这时候如果还有热点通常意味着问题在更上游——要么是 floorplan要么是某个 module 的 pin density 实在太高。这时候最有效的做法往往是局部的 ECO把一小块高 pin density 的单元重新映射成面积稍大、引脚更少的实现牺牲一点面积换走线空间比在布线阶段硬压划算得多。4.4 ICC2 与 Innovus 关键控制点对照控制目标ICC2 常用做法Innovus 常用做法全局局部密度上限place.coarse.max_densitysetPlaceMode -place_global_max_density拥塞优化力度与 congestion 相关的 place app option版本相关用list_app_options确认setPlaceMode -place_global_cong_effort局部利用率限制create_placement_blockage -type partial -utilizationcreatePlaceBlockage -type partial -densitymacro 周边留白create_placement_keepout_margin/create_routing_keepout_marginaddHaloToBlockcreateRouteBlk绕线层规划set_routing_layers -signal/-clock层范围相关的setDesignMode/setNanoRouteMode参数用man核对拥塞报告report_congestion重跑 global route 后reportCongestion -overflow/-hotSpot合法性检查check_legalitycheckPlace这张表里的命令名我尽量用了确定性高的但还是要提醒一句两个工具的参数名都随版本演进抄表之前先在本地man一遍。我见过太多次“按照文档写的但工具不认”最后发现是版本差异。5. 一次真实的 congestion 排查全过程5.1 先看 map 再看数字报告本身会骗人出问题的时候第一反应不要去看 overflow 的总和。我的固定动作是重跑 global route打开 congestion 的热点图同时叠加 pin density 图和利用率图然后找红块的位置和 floorplan 图对照。这里有几个报告层面的坑。第一热点图的分辨率跟 GCell 大小有关GCell 设得太大热点会被平均掉看起来一切正常设得太小图会碎得看不出规律。第二图上显示的是“需求/供给”的比值还是“绝对差值”两种口径下同一个位置的颜色可能不同。第三congestion 报告只统计信号线不含电源和时钟的最终实现时钟在 CTS 之后才有实体所以 CTS 之后必须重新看一遍。我一般会同时看三张图叠在一起利用率、pin density、overflow。如果某块区域三张图全红那这个地方基本可以确诊如果只有利用率红多半是假的警报。5.2 PG 网络和 pin 造成的堵点怎么快速锁定有一类热点很隐蔽单元密度不高、pin density 也一般但就是堵。这种情况十有八九是电源网络或者某个特定 pin 类型造成的。比如某些工艺里的体偏置bias相关的引脚命名上常见biasnw这类后缀它们分布在大量单元上、又需要单独连到某条网络上密集区域很容易形成局部走线压力。Innovus 里要定位这类 term用dbGet顺着层次结构查是最快的# Innovus找出所有 instance 上名字含 biasnw 的 term并打印它所在的 inst 和 net set terms [dbGet -p2 top.insts.instTerms.name *biasnw*] foreach t $terms { puts inst[dbGet $t.inst.name] term[dbGet $t.name] net[dbGet $t.net.name] } # 在 GUI 里把这些 inst 高亮出来看它们的分布是否和热点重合 deselectAll selectInst [dbGet -p $terms inst]dbGet -p2的含义是往回找两级父对象从instTerms.name找到对应的 inst。这个套路对所有“按名字找引脚”的场景都通用把biasnw换成你关心的关键字就行。查到之后如果这些 term 的分布确实和热点重合那结论就很清楚了不是单元放得太密是这类引脚的连接方式或者网络走向有问题处理方式应该是调整这些网络的走线层和拓扑而不是继续降压密度。5.3 三种典型热点的成因与对策跑得多了会发现热点翻来覆去就那么几类。我整理了一张对照表出问题的时候先对号入座能省掉大量试错时间。热点特征最可能的成因优先尝试的处理长条形沿 macro 边缘延伸macro 通道过窄通道内 net 数超预算调整 macro 位置加宽通道或把部分 net 引到别的方向团块状位于 block 边界内侧block pin 集中扇出通道不够重新分配 pin边界内侧加 keepout 预留通道点状散布与高 pin density 区域重合局部单元 pin 太多且多为高扇出 net局部 partial blockage 降压控制高扇出 net 的 buffer 分布与电源网格走向重合PG mesh 占用了主要走线层调整 mesh 层与宽度把信号引到高层判断成因有个小技巧把热点图和 net 的走线图叠加看是“很多短 net 挤在一起”还是“少数几根长 net 横穿而过”。前者是密度问题后者是拓扑问题处理手段完全不同。前者靠 partial blockage 和密度上限能改善后者只能改 floorplan 或者改层规划硬压密度只会把问题推来推去。5.4 修完之后怎么验证没有引入新问题改完任何一个参数验证动作要固定成一套别只看 congestion 一项。首先是重跑 global route 出新的热点图确认原来的热点确实淡了。其次是看 total overflow 和 max overflow 两个数字前者降了但后者没降说明你只是把热点打散了实际上并没有解决根本问题。第三是跑一次合法化检查确认加进去的 blockage 没有导致单元堆在不该堆的地方。第四是重新看 timing因为控制密度通常会让 net 变长timing 会退化要确认退化在可接受范围内。第五是看面积partial blockage 加多了会让有效可用面积变小如果利用率已经接近上限就要考虑加 core 面积。这五步我一般是写成一个脚本一起跑一次性把报告都出出来。分开跑最容易出现的情况是改了 A 之后只看 A忘了 B 也受影响等两周后发现 timing 崩了回头查不出是哪次改动造成的。6. 踩过坑才明白的几条经验6.1 density target 到底设多少关于这个数字我现在的判断逻辑是这样的先看 pin density 和 macro 占比。单元平均 pin 数不高、macro 占比低于 30% 的 block0.72 到 0.78 是可以尝试的区间pin density 偏高比如大量小面积多引脚单元或者 macro 占比超过 40% 的建议从 0.65 起步如果设计里有多电压域、需要额外插入 level shifter 和 isolation cell 的区域再降 3 到 5 个百分点。这里有个反直觉的结论把 density target 从 0.78 降到 0.68congestion 未必会变好。因为单元被摊开之后net 变长工具为了修 timing 插入更多 buffer整体走线需求反而可能上升。我做过一次对比同一个 block 在 0.70 和 0.60 两个设置下0.60 那版的 total overflow 只降了 8%但门数增加了 4%timing 变差了 12%。所以密度上限这个东西调到“刚好能缓解热点”就够了别当万能药。6.2 不要做的三件事第一件不要盲目堆 partial blockage。我见过有人在热点上盖了十几块 partial blockage结果单元全被挤到周边周边变成新的热点最后整个 block 的利用率上不去、绕线更乱。partial blockage 是精细手术刀不是创可贴一块区域压 10 到 15 个百分点通常就够了。第二件不要过早追求零 overflow。global route 阶段的 overflow 只要控制在很小的范围和量级后面 detail route 阶段往往能自己消化掉。为了把最后那点 overflow 清零把 density 压到 0.6牺牲面积和 timing这笔账通常不划算。真正需要担心的是“大面积、连续、落在关键路径附近”的热点。第三件不要同时改多个变量。floorplan、density 上限、blockage、绕线层一次只动一个动完重新出报告。我在早期项目里同时改了层规划和 blockage结果 congestion 好了但 timing 崩了花了一周才定位到是层规划的问题。现在这条已经变成我的硬性纪律。6.3 从更上游的地方减轻压力congestion 从来不是 PR 阶段才产生的问题。综合阶段的一些选择会直接决定 PR 阶段有多难受。一是控制高扇出 net。综合时如果让某个使能信号直接驱动几千个单元PR 阶段这条 net 的 buffer 树会把某个区域彻底压垮。合理的做法是综合阶段就把高扇出 net 做一定的复制和分层或者在后端用工具做 net 的分割。二是关注单元的面积与引脚比。同样功能的实现不同库单元的面积和 pin 数差别很大。在 pin density 本来就高的区域选用引脚更少的实现哪怕面积大一点往往比硬压密度更有效。三是数据流的方向性。综合和 floorplan 阶段如果能把相关的逻辑尽量放在一起net 的长度和走线需求都会明显下降。这一步做得好后面能省掉一大半调 density 的工作。四是别忽略 pin access。有些热点其实是局部 pin 密集导致工具找不到合法的引脚接入方式被迫绕远路绕路的线又加重了附近网格的拥塞。这种情况下降压密度只是缓解症状真正有效的做法是让工具在合法化阶段就考虑 pin access 的余量或者对高 pin density 的单元加一点 instance padding 把它们隔开。做久了我最大的体会是density 是一个可以量化、可以设置的参数而 congestion 是一个结果是 floorplan、数据流、电源规划、单元选择、布线层规划共同作用的结果。盯着 density 数字调来调去往往解决不了 congestion把 congestion 当成一个诊断问题去对待先看 map、先找成因再决定动手的位置效率会高得多。前面那个 68% 利用率还堵的 block最后我们没动任何 density 参数只是把两个 macro 之间的通道从 6 个 track 加宽到 14 个把三个 module 的 pin 重新分配到了两条边上overflow 直接降了七成。