企业官网建设流程全解析

数字IC后端设计里，density和congestion这一对指标，几乎是从floorplan一路跟到signoff的"老冤家"。我在实际项目里见过太多这样的情况：placement跑完报出来的cell density只有0.72，看着挺舒服，结果trial route一跑，某些区域congestion map红得像烙铁；也见过反过来，为了压congestion把density一路往下调，最后面积超标、时序收不回来，不得不回头重做floorplan。ICC2和Innovus这两套工具，控制density和congestion的旋钮各有各的叫法，社区里零零散散的帖子很多，但很少有人把"为什么这么调"和"调完会带来什么副作用"讲清楚。

这篇东西想干的事很具体：把density和congestion的物理含义拆开，把ICC2和Innovus里真正管用的那批参数列出来，再结合我自己跑过的几颗芯片，讲讲从floorplan到placement再到route，每个阶段该看什么指标、该动哪个旋钮、动完预期能改善多少。适合已经跑过一两轮PR流程、但对着congestion map还是有点懵的人看；刚入门的朋友也能从中拿到一些可以直接照着改的命令序列。

1. 先搞清楚density和congestion到底在说什么

很多人一上来就问"density调到多少合适"，这个问题本身就问偏了。density不是单一指标，congestion也不是单一成因，两个东西在不同阶段、不同工具里代表的意思并不一样。不把概念对齐，后面调参基本就是瞎猜。

1.1 三种density，混着用必然出错

工程里说的density至少要分成三种，它们在报告里长得像，含义差得远。

• Cell density（单元密度）：标准单元总面积除以可布单元区域的面积。注意分母是"可布单元区域"，也就是core面积减掉macro、减掉hard blockage、减掉keepout之后剩下的那块。ICC2的report_utilization和Innovus的density map默认给的都是这个口径。
• Pin density（引脚密度）：单位面积内的引脚数量。这是congestion最直接的驱动因素之一。一个区域cell density只有0.6但里面全是200pin以上的复杂单元，照样会堵得厉害。
• Track utilization / routing density（布线轨道利用率）：把可用布线轨道数当分母，实际走线需求当分子。这个才是congestion的近亲。PR工具里global route之后算出来的overflow，本质就是在算这个东西。

我在项目里判断一个block能不能收敛，习惯是三张图一起看：density map、pin density map、还有第一次trial route的congestion map。只看density map就拍板，十次里有七次会被坑。

还有一种容易被忽略的情况：同一个block里，不同module的density差异极大。比如一个DSP模块density到了0.85，旁边一个控制逻辑模块只有0.5，全局平均值看着很漂亮，但那个0.85的区域在route阶段必炸。所以后面讲的局部density控制，比全局参数更重要。

1.2 Congestion的物理成因，比你想的要杂

Congestion的表现是overflow，也就是某个global routing cell（GRC）里走线需求大于供给。但造成需求大于供给的原因有很多种，对应的解法完全不同。

第一类是总量型：整个区域cell塞太多，走线需求普遍偏高。这种靠降全局density、加面积就能解决。

第二类是通道型：macro之间留的channel太窄，或者macro和core boundary之间只有两三条track的缝隙。走线不可能凭空穿过石头，所有需求都挤在有限的通道里。这种靠降density几乎没用，必须回去挪macro或者加soft blockage。

第三类是引脚集中型：某些单元或IP的pin挤在一条边上，或者某个macro的pin全朝一个方向。这时候即使面积富裕，局部pin density也会爆。

第四类是层分配型：低层金属被power mesh吃掉了大半，信号只能往高层挤，结果高层局部溢出。这种要在floorplan阶段就把power plan和signal layer的分配算清楚。

我见过最典型的一次，一个block的congestion一直收不掉，反复降density从0.75降到0.6都没明显改善。最后发现是某个SRAM的halo设得太小，标准单元紧贴着它摆，而SRAM一侧的pin又特别密。加了两个GRC宽的keepout之后，congestion直接掉了一半。所以遇到congestion先别急着动density参数，先看地图上红的地方长得像什么形状——是整片红、条带红、还是点状红，形状直接告诉你病因。

1.3 为什么这两个指标总是在互相牵制

道理其实很朴素：density高，单元挤得紧，单元之间的平均连线长度短，时序好、面积省，但走线需求集中在更小的面积里，congestion容易爆；density低，分散了，走线需求摊开，congestion缓解，但线变长、时序变差、面积浪费，还可能因为分散导致更多长线反而引入新的拥堵。

所以density和congestion不是"调一个另一个就好"的关系，中间存在一个最优点，而这个最优点随设计变化。高pin密度的设计最优点偏向低density，线长敏感的设计偏向高density。

工具里的congestion effort参数，本质就是让placer在"塞紧"和"摊开"之间做取舍。设成high，placer会主动把单元推开一点、给高连接度的cell留空间，代价是runtime变长、线长变长。设成low，placer只求塞进去，runtime短但congestion风险高。这个取舍想明白了，后面看参数就不容易犯迷糊。

2. 工具侧参数全景：ICC2和Innovus的旋钮对照

两套工具的参数体系不一样，但功能上基本一一对应。我整理了一份自己常用的对照，先说清楚：不同版本参数名和默认值会有差异，动手之前一定先用工具自带的查询命令确认一遍，ICC2用report_app_options *keyword*，Innovus直接man或者help对应命令。

2.1 全局density控制参数

ICC2这边的入口主要是app options，核心是place.coarse.max_density。这个选项限制placement阶段单个区域能达到的最大cell density，默认值各版本不同，常见在0.6到0.75之间。对于新手来说，把它显式设成0.7到0.75是比较稳的起点。

ICC2还有set_congestion_options -max_utilization这个命令，能做区域级的density限制，后面第5章会细讲。

Innovus这边的入口是setPlaceMode -place_global_max_density，值域0到1，常用0.7到0.85。另外setPlaceMode -place_global_uniform_density true可以让placer主动把密度做得更均匀，这个选项在全局密度不高但局部不均的设计上效果非常明显，我几乎每个项目都会开。

还有一个常被忽略的：place_opt.flow.enable_ccd（ICC2）和对应的时钟数据并发优化。它本身不是density参数，但开启后placer会同时考虑时钟树和数据路径，placement结果会因为时钟单元的预留位置而变化，间接影响density分布。

2.2 congestion effort这一类参数

ICC2里跟congestion相关的app options是*congestion*这一族，用report_app_options *congestion*能列出一串。实际项目里最常调的是placement阶段的congestion effort，值一般是low/medium/high。设high之后，placer会在初始placement时就考虑布线资源分布，代价是runtime明显变长，我实测在大block上能到1.5到2倍。

Innovus这边是setPlaceMode -place_global_cong_effort low|medium|high|auto。auto让工具根据设计规模自己判断，我的习惯是先把auto跑一遍看结果，如果congestion还不行再手动上high。这个参数对结果的影响比density参数更"立体"，因为它不只是限制总量，还会改变单元的摆放形态。

global route阶段，ICC2用route.global.timing_driven和route.global.congestion_effort这类选项，Innovus用setRouteMode -earlyGlobalMaxRouteLayer配合trial route的参数。层数限制对congestion的影响经常被低估：如果你允许global route用满所有层，工具会找到解，但detail route阶段一旦因为DRC或者via密度问题被封掉几层，之前算好的解立刻崩掉。所以我一般会在floorplan阶段就定死信号可用层范围，让congestion评估从一开始就在真实约束下做。

2.3 两套工具命令对照速查

实际工作中切换工具最痛苦的就是命令名对不上。下面这张对照表是我自己攒的，放在手边随时查。

3. Floorplan阶段就要把density预算做对

我个人的判断是：一个block能不能收敛，七成在floorplan阶段就定了。placement和route阶段能做的修补很有限，大部分时候只是把already存在的问题挪个位置。所以与其在placement阶段死磕density参数，不如在floorplan阶段把预算算准。

3.1 目标utilization怎么算出来

先把公式摆清楚，因为很多人算的时候分母搞错了。

cell_utilization = 标准单元总面积 / (core面积 - macro面积 - hard blockage面积 - keepout面积)

这个分母才是真正能放标准单元的面积。如果分母里忘了扣keepout和blockage，算出来的utilization会虚低，你以为还有空间，其实已经满了。

经验值方面，我自己的取值习惯是：

• 普通逻辑为主的block：目标0.72到0.78。低于0.70会浪费面积，高于0.80在route阶段大概率要回来降。
• 高pin密度设计（大量复杂标准单元）：0.62到0.70。因为引脚集中，允许的密度必须更低。
• 含大量memory channel的设计：0.55到0.65。macro通道会吃掉大量布线资源。
• 顶层或者有大量长线的block：0.65到0.72。

还有一个容易被忘掉的项：spare cell和decap的预留。有些流程要求预留3%到5%的面积给spare cell，这部分面积在实际placement时会被填上单元，但floorplan阶段评估时经常漏算，导致最后density比预期高出一截。

3.2 macro摆放对congestion的隐性影响

macro的位置对congestion影响巨大，而且很多时候是"看不见"的——因为density map上看不出问题，只有route完才知道。

几个我踩出来经验：

第一，macro的pin面尽量朝向core内部的开阔区域。如果两个macro的pin面相对，中间通道再窄，那里必堵。宁可牺牲一点面积把pin面错开。

第二，不要把macro摆成阶梯状或者L形把core切成细长条。通道一旦窄于某个阈值（我一般按10到15条track估），global route会显示绿色，但detail route会大量绕线，最后还是堵。

第三，macro周围一定要留halo。ICC2用create_keepout_margin，Innovus用addHaloToBlock。halo宽度按macro的pin密度给，我一般起点是2到3个GRC，pin密的加到4个。

第四，memory阵列之间要留出"高速公路"。经验做法是在macro群之间保留一条宽度至少能跑20到30条track的通道，专门给跨模块的长线用。

3.3 blockage和halo的实操配置

blockage不是随便加就有效的，加错了比不加更糟。

ICC2里创建placement阻挡：

# 硬阻挡，完全不允许放标准单元 create_placement_blockage -type hard -boundary {{100 100} {200 200}} -name hard_blk_1 # 软阻挡，placer尽量避开但必要时可以放 create_placement_blockage -type soft -boundary {{300 100} {400 200}} -name soft_blk_1 # 部分阻挡，允许放到指定密度 create_placement_blockage -type partial -boundary {{500 100} {600 200}} \ -utilization_threshold 0.5 -name partial_blk_1

Innovus对应：

createPlaceBlockage -box {100 100 200 200} -type hard -name hard_blk_1 createPlaceBlockage -box {300 100 400 200} -type soft -name soft_blk_1 createPlaceBlockage -box {500 100 600 200} -type partial -name partial_blk_1

实操心得：soft blockage是我用得最多的一种。在macro上方或者通道附近放soft blockage，placer会倾向于避开，但如果实在塞不下还是允许放进去，这样既缓解了congestion又不会让placement失败。而hard blockage一旦设得太大，会把单元逼到别处，造成局部密度飙升，反而制造新热点。

注意：hard blockage的区域不会计入utilization计算的可布面积，所以设完之后要重新评估目标density，否则分母变了，你之前的65%实际变成了75%。

另外，blockage是有代价的——它会让线长变长、时序变差。我一般只会对确认有问题的区域加，加完之后一定会对比一下WNS和TNS的变化，如果时序掉了超过5%，就要重新评估是否值得。

4. Placement阶段控制density的实操流程

进到placement阶段，能做的调整其实是在既定floorplan下的优化。这时候的目标不是"改布局"，而是"精细分配"。

4.1 用什么指标判断density是否合理

跑完第一次placement，我会按顺序看这几项：

1. 全局cell density：直接看报告。超出目标值3个点以上就要查原因。
2. 局部density分布：看density map的直方图，不只看平均值。如果某个区域超过全局值10个点，就是潜在热点。
3. pin density分布：这个指标在Innovus里可以通过GUI的density视图切换查看，ICC2里用report出来的pin count分布估算。
4. 第一次trial route的overflow：这是最硬的证据。global route后report_congestion或reportCongestion -overflow，看overflow的GRC数量占比和最大值。

我的经验阈值：overflow的GRC占比超过1%，或者单个GRC的overflow超过该GRC容量的30%，就必须处理。低于这个数可以先放着，因为detail route阶段还有调整空间。

一个容易忽略的点：runtime和overflow之间不是线性关系。有时候你把effort从medium提到high，overflow只降了5%，但runtime翻倍。这种情况下不如回到floorplan改一下macro位置，收益大得多。

4.2 ICC2的实操命令序列

下面是我在ICC2里常用的一套顺序，从placement到检查：

# 1. 设定全局密度上限 set_app_options -name place.coarse.max_density -value 0.74 # 2. 提高placement阶段的拥堵优化力度 set_app_options -name place_opt.place.congestion_effort -value high # 3. 对已知的高密度区域做局部利用率限制 set_congestion_options -max_utilization 0.62 \ -coordinate {1200 800 1800 1400} -name congest_zone_1 # 4. 运行placement place_opt # 5. 检查利用率 report_utilization -hierarchical > ./rpt/util_hier.rpt report_utilization > ./rpt/util.rpt # 6. 跑全局布线评估拥堵 route_global report_congestion -grc_based > ./rpt/congestion.rpt

关于第2条里的app option路径，我提醒一句：ICC2的选项层级在不同版本之间改过，有时候是place_opt.flow.*，有时候是place_opt.place.*。最稳的做法是report_app_options *congestion*先看工具里到底有哪些，然后挑placement阶段那个改。不要照抄网上的路径，抄错路径工具不会报错，只会静默用默认值，那种"明明设了却没效果"的坑，八成都是路径写错了。

set_congestion_options这个命令值得多说两句。它支持按坐标区域设最大利用率，也支持按module名设定。对于已知的、floorplan阶段就判断会有问题的区域，提前设一个更低的利用率上限，比等到placement之后再补blockage效果好。我一般会在跑第一次placement之前，就把两三个高风险区域设好。

4.3 Innovus的实操命令序列

Innovus这边的顺序类似，命令名不同：

# 1. 全局密度与均匀化 setPlaceMode -place_global_max_density 0.74 setPlaceMode -place_global_uniform_density true # 2. 拥堵优化力度 setPlaceMode -place_global_cong_effort high # 3. 对个别高连接度单元加间距 specifyInstPad <instName_1> 1 specifyInstPad <instName_2> 2 # 4. 执行placement placeDesign -inPlaceOpt # 或者分步：place_opt_design checkPlace # 5. 早全局布线评估 setRouteMode -earlyGlobalMaxRouteLayer 5 addTrialRoute reportCongestion -overflow > ./rpt/congestion_overflow.rpt reportCongestion -hotSpot > ./rpt/congestion_hotspot.rpt

specifyInstPad这个命令用得好的话非常有效。它给指定实例周围加间距，placer会自动避让。适用场景是那些扇出特别大、或者引脚特别多的单元——比如时钟分频器、大型多路选择器、高扇出的缓冲器。给它们周围加一到两个site的间距，能显著缓解局部pin density，而且代价很小。

注意：specifyInstPad是对实例级的，不是对cell type的。如果某个类型的单元在设计中出现几百次，逐个指定不现实。这种情况更适合用全局的spacing规则，或者干脆在floorplan阶段就规划好。

setPlaceMode -place_global_uniform_density true我几乎必开。它做的事情是让placer主动把密度做得更均匀，代价是稍微牺牲一点线长。在大部分设计上，这个交换是划算的——因为线长增加5%，congestion可能降15%。

5. Congestion分层治理：从全局到局部

congestion的解决思路，我总结成一句话：先看形状，再找病因，最后分层下药。不同层级的拥堵，用的手段完全不一样。

5.1 怎么读congestion map和报告

看到congestion map第一件事是判断形状。

• 整片均匀泛红：典型的全局密度过高。解法是降全局density参数，或者扩core面积。
• 条带状红：通常沿macro边缘分布，是通道太窄。解法是挪macro或者加soft blockage。
• 点状集中红：某个具体单元或IP造成的。解法是给那个实例加padding或者局部blockage。
• 边界红：core boundary附近高密度，常见原因是IO或者pin约束把单元往那边挤。解法是在边界区域加partial blockage。
• 随层变化的红：如果低层红高层绿，说明信号都往上跑了，要检查power plan是否吃掉了太多低层资源。

报告里的数字，我会重点看两个：overflow的GRC数量和最大overflow值。前者告诉你影响面，后者告诉你严重程度。影响面大但程度轻的，用全局参数解决；影响面小但程度重的，用局部手段点对点处理。

我一般会把改动前的congestion报告存一份，改完之后对比。因为congestion优化经常是"这里好了那里坏了"，不对比很容易以为自己在进步，实际总量没变。

5.2 全局层级的四类解法

第一类：降density上限。最直接，效果也最明显。但代价是面积和线长，我在前面说过，一次不要降超过3个点，降太多会连带时序一起崩。降完一定要重跑时序。

第二类：提高congestion effort。效果比降density更"聪明"，因为它不靠牺牲全局密度，而是靠更聪明的摆放。代价是runtime。我的习惯是先提effort，effort解决不了再降density。

第三类：调整layer assignment。给global route更大的层范围，或者调整power plan让出更多低层资源。这一类的收益经常被低估——我遇到过一次，只是把power mesh的striping间距从30改到45，congestion直接降了20%，因为释放出来的低层track刚好够信号走。

第四类：cell padding与spacing规则。对整类单元加间距。ICC2里用set_placement_spacing_label配合set_placement_spacing_rule，Innovus里对实例用specifyInstPad。这一类的代价最小，但只对pin density型拥堵有效。

5.3 局部热点的手工干预

局部热点是place-and-route里最费时间的部分，因为工具自动优化对局部热点的效果有限。我的处理流程是这样的：

第一步，定位。用reportCongestion -hotSpot或者ICC2的report_congestion -grc_based，拿到具体坐标和module名。

第二步，判断成因。把这个区域单独放大看，看是单元太密、macro太近、还是某个单元pin太多。

第三步，下药：

# ICC2：对该区域设更低的利用率上限 set_congestion_options -max_utilization 0.55 \ -coordinate {1550 1200 1750 1400} -name hotspot_fix_1 # Innovus：加soft blockage把单元推出去 createPlaceBlockage -box {1550 1200 1750 1400} -type soft -name hotspot_fix_1

第四步，验证。重跑placement和trial route，确认热点消失的同时没有制造新热点。

这里有个很重要的经验：局部干预要一次改一个区域。我早期犯过的错误是一次性加五六个blockage，结果单元全被挤到剩下的地方，形成更大的热点，反而更难收拾。一次改一个，看效果，再改下一个。

注意：blockage加多了会让placement的结果非常"人工"，后续如果设计有改动（比如功能ECO加了逻辑），这些人工约束会变成负担。所以能靠参数解决的，尽量别靠blockage。

5.4 timing和congestion的取舍

这是placement阶段最需要判断力的一件事。congestion努力调高、density调低，都会让单元分散、线变长，时序变差。反过来，为了时序把单元挤紧，congestion又会爆。

我的做法是设两条线：

• congestion红线：overflow的GRC占比不超过1.5%。超过这条线，无论时序多好都要处理，因为route阶段过不去等于一切白做。
• 时序红线：WNS不超过目标值的负向10%。比如目标是-100ps，那placement后不能低于-110ps。

两条线都守住，说明placement是健康的。如果守不住一条，优先保congestion，因为时序在后面的CTS和route阶段还有修复空间，而congestion一旦固化到placement里，后面很难逆转。这是我做了几个项目之后形成的判断，早期我总是先保时序，结果route阶段反复返工，总时间反而更长。

另外，timing-driven和congestion-driven这两个目标在工具里是可以调权重的。ICC2和Innovus都允许你在placement时指定两者的优先级。我的默认配置是相等权重跑第一轮，看哪边差得更多，然后第二轮调整权重。

6. 常见问题排查速查与踩坑记录

前面讲的都是"应该怎么做"，这一章讲"做不对的时候怎么查"。

6.1 症状与病因对照表

这张表里的每一条我都实际遇到过，尤其最后一条，是新手最容易踩的：为了让某块区域不堵，设了一大片hard blockage，结果placer没地方放单元，直接报拥塞失败，还得回头一点点缩小blockage。

6.2 几个真实的坑

坑一：只调参数不动floorplan。我见过有同事把density从0.8一直降到0.55，congestion还是红的，最后发现是两颗macro贴得太近。降density在这里完全没有用，因为问题不在总量而在通道。所以我现在的原则是：第一次优化无效就立刻怀疑floorplan，不要在同一层级反复调参。

坑二：忽略power plan的影响。在一颗设计上，我们把所有placement参数都调了一遍，congestion纹丝不动。后来发现power mesh的宽度设得太大，低层金属被吃掉将近四成，信号只能挤在剩下那几层。改了power stripe宽度和间距之后，问题立刻缓解。这个教训是：congestion评估一定要在最终的power plan确定之后做，用临时power plan跑出来的结果没有参考价值。

坑三：spare cell和decap事后填。有些流程为了赶进度，先不填spare cell，placement跑完觉得没问题，最后填spare的时候直接填出了新的congestion。我的做法是在placement阶段就把spare cell按最终密度一起放进去，宁可多花一点时间，也不要最后翻车。

坑四：跨工具对比参数值。ICC2的density 0.75和Innovus的-place_global_max_density 0.75语义不完全一样，因为两者对"可布区域"的定义和计算方式有差异。换工具的时候不要直接照搬数值，而是要照着overflow的实测结果去标定。

坑五：congestion报告和实际detail route结果差距大。global route算出来的拥塞只是估算，它假设走线可以任意绕。实际detail route受DRC、via规则、pin access限制，结果会比global route差。所以我一般会在global route的overflow上留20%到30%的余量，报告显示0.8%以内才认为安全。

6.3 关于选中指定名字的PG term这类细活

最后一个话题，说说怎么处理那种"看起来很小但很费时间"的操作。

带body bias的工艺里，标准单元上会有额外的PG term，比如名为biasnw的n-well偏置端口。做PG连接或者做检查的时候，经常需要把设计里所有带这个名字的PG term选中。手动在GUI里点不现实，标准单元可能有几十万个实例。

思路是用数据库查询加批量选择。Innovus里比较通用的做法：

# 先清空当前选择 deselectAll # 用dbGet查询所有cell的pgTerm里名字匹配的项 set bias_pins [dbGet -e top.insts.cell.pgTerms.name biasnw] # 看看查出来多少个，确认数量合理再往下走 puts "matched pg terms: [llength $bias_pins]" # 批量选中 select_obj $bias_pins

这里-e这个选项很关键，它的作用是让dbGet把嵌套的属性展开成对象列表而不是字符串列表，不加的话选中会失败。这个细节我在第一次用的时候琢磨了很久，因为不加-e的时候命令不报错，只是选不中任何东西，非常容易误判成名字写错了。

如果需要按这个PG term做网络连接，Innovus里的命令是：

globalNetConnect biasnw -type pgpin -pin biasnw -inst * -override

-type pgpin指定连的是电源地引脚，-pin指定引脚名，-inst *表示所有实例。

如果只是想在GUI里目视检查，比敲命令更快的方式是用选择菜单里的按属性筛选功能，输入PG term名字即可。但批量操作、或者需要写进脚本里重复执行时，还是dbGet加select_obj这套更靠谱。

注意：查询出来的pg term数量一定要和预期对一下。如果工艺库里同一个名字的PG term出现在多种cell上，而你只想处理其中一部分，那就要在dbGet的条件里再加cell类型的过滤，否则会误选。这类"选择范围"的问题，出错了不会有任何报错提示，只会在后面某个环节冒出莫名其妙的结果。

还有一点经验：这类批量选择的操作，建议先在设计的副本上跑一遍，确认选中数量和范围符合预期，再在主流程里执行。因为select_obj之后如果接着做删除或者修改操作，误选会直接破坏数据库，而且很难回滚。

我个人在实际操作中的体会是，density和congestion这件事，越是急着调参数，越容易在原地打转。真正解决问题的那几次，都是回到floorplan图纸上，用笔把macro位置重新画一遍，或者拿着congestion map的形状反推物理原因。工具参数是加速器，不是发动机。

如果非要给一条可以马上用起来的建议，那就是：每次优化congestion之前，先把改动的预期收益写下来，把report存下来，改完对比。我早期是凭感觉调，改动十几个参数之后完全说不清哪个有效，后来养成记账的习惯，几颗芯片下来，手里就攒出了一份属于自己的参数-收益对应表，比任何文档都好用。