企业官网建设流程全解析

芯片做到后期，真正决定能不能按时tapeout的，往往不是RTL写得多漂亮，也不是综合结果多紧凑，而是物理签核这一关怎么过。这里的“签核”说白了就是一系列电气和物理检查的合集，而最常卡人的四座大山，就是IR Drop、EM、Noise和Antenna。不管你是刚接手物理实现的新人，还是已经在后端摸爬滚打了几年的工程师，这四个词大概率都绕不开。我见过不少项目，前面PR阶段势如破竹，一到签核阶段就被这些violation反复折腾，改一版跑一遍，跑一遍再改一版，最后时间全耗在收敛上。

这篇内容我不想做教科书式的原理复读，而是结合我自己做过的流片项目和签核迭代经验，把这四类问题背后真正的物理逻辑、工具判断口径、以及实战中的修复顺序一次讲清楚。内容会比较细，也会带一些踩坑的记录。适合刚接触后端物理实现的工程师，也适合想弄明白“后端到底在卡什么”的架构师和前端同事。

1. 物理签核这关，到底在审什么

1.1 为什么卡人的总是这四个问题

先退一步想一个问题：物理签核为什么不是只跑一遍DRC和LVS就完事？因为DRC查的是“几何上能不能造”，LVS查的是“版图和原理图对不对得上”，但芯片流片之后能不能稳定跑起来、能跑多久，取决于很多分布式的物理效应。这些效应很难在设计早期全部预测，必须在版图基本成型、寄生参数比较可信的前提下，用专门的分析工具去验证。

IR Drop、EM、Noise、Antenna这四类问题，恰好对应了四个不同维度的风险：

• IR Drop是供电维度的问题，解决的是“电源从引脚进到每个单元门口时，电压还剩多少”。
• EM是可靠性维度的问题，解决的是“常年的电流应力会不会把金属和过孔慢慢‘磨断’”。
• Noise是信号维度的问题，解决的是“相邻信号线之间会不会互相干扰到逻辑判断出错”。
• Antenna是制造维度的问题，解决的是“等离子工艺过程中积累的电荷会不会把栅氧击穿”。

这四类问题的共同特征是：它们都不是单点问题，而是跟版图结构、走线方式、翻转活动、工艺参数深度耦合的分布式效应。你没法像修DRC那样，这里调一下那里改一下就能快速清新。很多时候你修掉一个IR Drop violatio，回头一看EM又冒出来几条；你把Noise修好了，Antenna的累积面积比又超了。所以网上才有那么多“四大挑战”的说法，确实不是营销话术，是后端工程师真实面对的情况。

1.2 签核分析的整体流程概览

一套比较标准的物理签核流程，大致是这样的：

PR工具（比如ICC2或Innovus）完成布局布线后，会导出寄生参数（SPEF）和版图数据。这时你会跑静态时序分析（STA）看timing是否收敛，跑物理验证（DRC/LVS）看版图是否干净，同时还要跑IR Drop和EM分析（用RedHawk、Voltus或PrimeRail这类工具），跑噪声和串扰分析（通常在PrimeTime SI或Tempus SI里做），最后跑Antenna检查（一般用Calibre或者PR工具自带的天线检查）。每一轮ECO之后，这些分析都要重新回归。

从时间投入上看，IR Drop和EM往往占掉一半以上的修复工作量，因为它们的violation经常和电源网络规划、floorplan布局绑在一起，越到后期越难改。Noise的violation虽然数量可能不少，但大多数可以通过局部优化解决。Antenna则比较特殊，如果布线阶段没有提前设置规则，后期ECO阶段一旦动了金属层，可能会出现“本来都干净了，改一个via又炸一片”的情况。

下面我把这四个挑战逐个拆开，讲原理、讲判断口径、讲实操修复，也会把一些工具层面的细节和容易踩的坑穿插在里面。

2. IR Drop：供电网络的“血压计”

2.1 IR Drop是怎么来的，为什么动态IR才是致命问题

IR Drop的原理其实非常简单，初中物理就能解释：电流流过电阻会造成电压下降。芯片内部从焊盘（bump或者bonding pad）到每个标准单元，要经过封装基板、电源引脚、多层电源网格、无数via，这中间每一段都有电阻。当单元瞬间抽取大电流时，实际到达单元VDD端的电压就会打折扣。如果这个折扣超过一定阈值，单元的延时就会变差，极端情况下逻辑状态都会被破坏。

很多刚开始看IR Drop报告的同学，习惯只看平均功耗条件下的静态IR结果。但我个人的经验是，真正致命的问题往往藏在动态IR里。动态IR分析需要基于实际的翻转活动数据（VCD/FSDB），看的是某个时间窗口内，多个模块同时“开火”抽取电流的瞬间，电源网格上最大压降出现在哪个instance。

我遇到过一个非常典型的案例：某个项目静态IR分析的结果非常健康，核心区域最大只有1.8%的压降，看着完全没问题。但把动态分析和真实唤醒序列一跑，发现某个模块在从低功耗模式唤醒的瞬间，几十万个触发器同时翻转，局部current spike直接让旁边某几个instance的压降掉到8.5%。那几条路径的时序余量本来就只有几十皮秒，压降一上来，时序分析直接爆红。后来我们通过调整唤醒序列、加大局部decap才把这个问题压下去。

这个例子想说明的是：IR Drop不是“平均电压够不够”，而是“最差时刻、最差位置、最差instance”有没有超过裕量。只看云图上的平均颜色，意义非常有限。

2.2 静态IR和动态IR的分析口径差异

从工具实现上，静态IR和动态IR的区别主要在于激励模型和网格提取方式。

静态IR用的是平均功耗Map或者VCD统计后的平均电流，注入到PG网络中，然后做一次直流分析。它的优点是跑得快，几乎不依赖仿真波形，适合在版图早期做快速迭代。缺点是它看不到瞬态效应，比如di/dt造成的压降尖峰、谐振引起的电压纹波，这些都是静态分析完全无法体现的。

动态IR则是把电流激励按时间窗口切分，在RLC网络上做瞬态仿真。不同时间点的压降分布会不同，工具会输出每个时间点上的压降云图，并汇总出最差情况。动态分析的精度和刺激的完备性直接相关。如果你的VCD没有覆盖最差唤醒场景，那么动态IR的结论也是偏乐观的。所以项目里通常会用仿真团队提供的worst-case activity，而不是随便抓一段功能仿真波形。

从判断准则上看，不同工艺节点、不同IP类型要求差异很大。一般标准单元库要求核心电压的公差在正负10%以内，但实际上很多先进工艺节点会把目标收严到5%到8%。SRAM这类存储接口模块通常要求更严，因为位线灵敏放大器的噪声容限非常小。模拟模块更是经常要求压降低于几个毫伏，甚至需要单独做供电网络优化。

这里有一个非常容易踩的坑：只关注VDD端的IR Drop，忽略VSS端的电压反弹。芯片上地网络同样有电阻，地弹抬高的是单元的VSS电位，等效于VDD相对VSS的电压被进一步压缩。所以签核分析一定同时看VDD压降和VSS反弹，两者要一起算总账。

2.3 IR Drop修复的实操手段

IR Drop的修复，不能一上来就盲目加宽电源线。加宽电源线确实有效，但代价是面积和布线资源，而且某些瓶颈节点不是加宽能解决的。我在实际项目中比较常用的修复手段，按优先级排序是这样：

第一，检查电源网格（PG mesh）的line-end和via密度。IR问题最多的位置往往不是线和线的中间，而是via阵列不够、strap切换层的出入口。如果你发现某条竖strip和横strap的交叉处压降特别大，优先看看那边是不是via数量不够，多加几个via往往比加宽金属更立竿见影。

第二，在floorplan阶段就要关注大功耗模块的位置。一个功耗很大的模块，如果被放在供电入口比较远的角落，那么无论怎么修都费劲。早期的power规划工具可以帮你估算每个区域的等效电阻，尽量让高功耗模块靠近供电引脚区域，会有事半功倍的效果。

第三，合理使用decap。decap单元本质上是在供电网络上放一些电容，在电流峰值的瞬间先由这些本地电容放电顶着，减小远端供电压降。但decap不是越多越好，放太多会漏电增加，还占用面积。放的位置才是关键——decap要放在动态IR最差的instance附近，而且要尽量靠近电流抽取点，不然作用会被电阻隔离掉。

第四，在先进工艺节点，有时候还要配合低频谐振分析来看。如果动态IR云图上出现明显的区域性纹波，可能是电源网格的谐振频率和唤醒频率耦合了。这种时候单纯加decap不一定有效，需要调整decap的频段特性，增加不同尺寸的decap组合。

2.4 IR Drop分析的工具数据准备

最后补充一下IR Drop分析的数据输入。无论你用RedHawk、Voltus还是PrimeRail，都需要三类东西：版图（含PG结构）、功耗信息、库的电气模型。功耗信息是最容易出问题的地方。

早期没有VCD，可以用平均功耗估算，但一定要留够裕量。签核阶段最好用真实的仿真波形或者经过校准的功耗模型。我见过有项目用RTL仿真波形直接提取VCD，但工具里忘了做功耗校准，导致分析的电流比实际偏小30%，IR结果看起来一片绿。流片后高温环境下功能出现偶发失效，查到最后才发现是IR问题没有真实暴露。

这里我的建议是：每次跑动态IR之前，先花十分钟对比一下平均功耗的数值和功耗实测/仿真的差距，确认在合理范围内再往下走。数据不对，工具再强也白搭。

3. EM：金属的“疲劳”与寿命账本

3.1 电迁移（EM）的物理本质

EM（Electromigration）是金属在电流应力下的长期退化过程。当电子流过金属导线时，会不断撞击金属原子，形成所谓“电子风”。如果电流密度足够高，金属原子就会顺着电子运动方向发生迁移。日积月累，导线的某些区域会形成空洞（void），导致电阻增大甚至断路；另一些区域又会堆积成小丘（hillock），严重时会跨过相邻金属之间的间距，造成短路。

EM的寿命模型一般套用Black方程。MTTF和电流密度的n次方成反比，和激活能成指数关系。这意味着温度和电流密度是EM寿命的两大杀手。芯片工作温度越高，电流密度越大，金属老化越快。所以EM检查里，对于温度角、IR drop角、电流密度这三个因素会做联合缩放，而不是单独看某一个。

EM失效是典型的“长期可靠性”问题，它不像IR Drop那样会让芯片在测试台上立刻死掉，而是可能在出货后几周到几个月内逐渐显形。这也是EM问题最阴险的地方：你没法在量产测试里筛出即将EM失效的芯片，只能靠设计阶段的签核去保证寿命。

3.2 信号EM、电源EM和Via EM的差异

EM检查在签核工具里通常会分成三类来看：

信号EM针对的是标准单元之间信号线上的电流。信号线里的电流方向会随着逻辑翻转来回变化，属于双向电流（AC EM）。因为电流方向来回交替，原子被推过来又推回去，部分损伤可以自修复，所以信号EM的容限相对宽松。但时钟网络的翻转率极高，信号EM风险反而很大。时钟树上的EM violation如果不处理，芯片可能在几个月内出现时钟沿抖动超标，那整个芯片的逻辑都会受影响。

电源EM针对的是供电网络上的电流。电源线里的电流方向基本不变，属于单向电流（DC EM），没有自修复机会，所以规则要严苛得多。电源EM的检查对象包括电源网格上的金属线和过孔。在动态分析里，工具还会区分DC电流和AC电流，通过设置AC-to-DC ratio来折算等效直流电流。

Via EM是指过孔上的电流密度限制。一块10微米宽的金属，如果下面只打了一个Via，那这个Via的电流密度就会非常大。过孔的EM容限通常比金属线更差，因为在同样电流下，Via的横截面积小，电流密度高。很多EM violation其实都是报在Via上的，修复方法一般是增加Via数量或者换用更大的Via阵列。

3.3 签核报告里的“EM px”到底在查什么

后处理工具跑完EM后，你会在报告里看到“EM per pin”这类的标记，行业里简称为EM px。它指的是工具按每个pin（比如某个标准单元电源脚、某个宏单元的电源和地脚）上的电流情况来判断EM风险。

为什么工具一定要按pin来查？因为EM失效是在局部发生的。一根电源线上的总电流可能没超限，但局部某个pin从旁边抽取的电流密度特别大，这个区域就是EM风险点。工具把每个pin上的峰的电流、平均电流和对应金属/过孔的面积拿出来，计算电流密度，再和工艺规则里的容限做对比。凡是超了的就是violation。

我建议你在看EM report时，不要只盯着violation数目，要把每个violation对应的pin和所在net匹配起来分析。很多时候，一个pin上的EM violation其实跟它驱动的负载有关，或者跟它所在的时钟buffer树结构有关。单纯在violation的位置加宽线宽，效果往往不好；因为根因不在这里，而是在这个pin之前很大的去耦电容充电电流或者多个buffer同时开关叠加出来的电流。

3.4 EM修复的实操顺序

EM修复有一个很重要的原则：先修电源EM，再修信号EM，然后修Via EM。因为电源网络是全局性的，电源EM不收敛，后续的修复很可能会被大电流路径反复影响。

具体操作手段我总结成几类：

• 加宽电流过大的金属走线，或者并联更多Via。这是最直接的方法，但要注意先后层上下层一体考虑，别只加宽的某一层。
• 换到更厚的金属层。上层金属通常更厚，允许的电流密度更大。这也是为什么很多电源网络喜欢用高层金属的原因。
• 降低整个模块的峰值电流。这个要从驱动强度和翻转窗口下手，比如把同时翻转的buffer分散开、调整时钟树的buffer规格等。
• 调整时钟网络的驱动。时钟EM violation经常是buffer驱动过大、扇出过高造成的，改clock tree structure常有奇效。
• 在ECO阶段使用EM能力更强的金属填充或改变Via类型。

这些操作里，最容易被忽略的是“降低翻转窗口的重合度”。芯片上很多EM问题不是平均电流超了，而是某个瞬间大量单元同时抽取电流导致的瞬态尖峰超过容限。这种情况下，把一部分单元的逻辑稍作调整，让它们的翻转时间岔开哪怕零点几纳秒，峰值电流就能砍掉一大截。这需要和前端配合，信号延迟的微调对时序影响不大，但对EM收敛有明显收益。

3.5 “EM失效”和IR Drop的联动

做完几个项目你就会发现，EM修复和IR修复从来不能独立看。电源网络加宽以后，电阻降低，IR Drop和EM会同时改善；但decap的放置效果则相反：decap可以压低动态IR的电压尖峰，但如果decap本身放置得离某个电源脚太远，反而会通过长线放电，把电流密度导到一条细金属上，加剧局部EM风险。

所以我的习惯是，IR Drop和EM用同一份电源网格、同一套VCD去分析，先把IR和EM的violation叠在一起看。有些区域IR报红但同时EM没有报，说明那里的电流密度还在容限内，这种位置用decap去顶就行。如果IR和EM同时报红，那就要考虑电源网格本身的承载能力不够，得加宽或者增加供电路径。两个报告一起看，才能避免修好一个炸了另一个。

另外还有一个小细节：库里面的EM rule和Signoff Guide一定要匹配。有些项目初期的EM rule没有改到最新版本，导致大量EM violation全是“假的”，浪费了几天时间在无谓的修复上。所以每次拿到新工艺库的第一件事，就是把EM rule版本和代工厂发布的版本核对一遍。

4. Noise：你不想在芯片上看到的毛刺

4.1 Noise的物理来源：容性耦合与信号完整性

Noise问题的根源是电容耦合。芯片内部，两条相邻的信号线之间总有寄生电容，当一条线（aggressor，攻击线）发生快速的电压跳变时，会通过这个耦合电容在另一条线（victim，受害线）上感应出一个电压脉冲。如果victim此时正保持一个稳定的高或低电平，而这个脉冲幅度足够大，就可能让后级逻辑门误判电平状态。

这里要区分两个概念：串扰（Crosstalk）和Noise。串扰影响的是时序，比如aggressor的翻转导致victim路径的延时发生变化，CRPR扣除后还能不能收敛；Noise影响的是功能，它直接看victim上的电压毛刺会不会超过逻辑门阈值。两者都是信号完整性（SI）分析的一部分，但侧重点不同。串扰可以通过STA工具里的SI分析一起看，Noise则需要专门的噪声分析或者看到报告里的crosstalk noise部分。

先进工艺节点下，线间距越来越小、耦合电容占比越来越大，Noise问题比老工艺严重得多。而且核心电压越来越低，噪声容限越来越小，以前根本不构成威胁的毛刺，现在可能直接导致功能出错。我见过某次测试中芯片在某些数据和地址组合下偶发出错，最后追查下来就是地址线翻转时在data线上感应了一个超过门限的毛刺。

4.2 AC Noise Rejection的真正含义

刚开始接触Noise分析的人，最容易犯的一个错误是：打开噪声报告，看到几千条violation就慌了。但实际上，工具在默认情况下并不会把所有毛刺都判定成violation，因为逻辑门本身有一定的滤波能力。这就是AC Noise Rejection的概念。

时序库里面的noise数据通常不是简单的一个噪声容限电压值，而是一条“rejection curve”。它描述的是：一个宽度为w、幅度为v的噪声脉冲，到底能不能被这个逻辑门滤掉。脉冲越窄，能容忍的幅度就越大；脉冲越宽，能容忍的幅度就越小。只有落在曲线之外的脉冲才会被判定为潜在violation。

这样做非常合理，因为真实芯片里的信号本身就充满各种高频分量，一个只有几十皮秒、幅度几十毫伏的毛刺，经过门上RC电路的低通滤波，根本不可能传到输出端。如果没有rejection机制，工具会把大量无关紧要的毛刺报出来，signoff会完全没法收敛。

但是这里有一个“设置”的坑：有的项目在SDC里没有正确设置noise相关的约束，或者库版本里AC noise data缺失，工具就会退回到保守的固定阈值，把很多正常毛刺当violation报出来。这种时候千万不要直接去修版图，先回过去检查noise data和设置。反过来，也有项目因为过度优化，把noise rejection曲线设得太宽，导致漏掉了真实风险。我的习惯是：拿到库之后先做一次spice级对标，确认工具的noise报告和spice仿真结果基本一致，再开始signoff分析。

4.3 Noise修复的优先级和手法

如果确认Noise violation是真实的，修复的时候不要无脑拉开线间距。拉开间距是最有效的方法之一，但代价是面积和绕线资源。实际项目中，我按下面的优先级来处理：

第一优先：保护时钟网络。时钟网络影响到全芯片所有时序路径，它的Noise violation哪怕只有一条，也要优先解决。通常给时钟线做屏蔽（shielding）是最稳妥的，旁边拉一条地线包住它，把耦合电容的噪声泄放到地上。

第二优先：保护异步复位和置位信号。这类信号没有时钟沿来过滤噪声，一旦毛刺出现就可能直接触发复位，导致逻辑状态被重置，很难排查。

第三优先：修复高驱动大扇出的数据线。这些路径本身翻转频率高、幅度大，是主要的aggressor。降低这些aggressor的驱动强度或者调整它们的slew，往往可以间接解决一大堆victim上的Noise violation。

修复Noise的具体手法，我列在下面：

• 增加victim的驱动强度：victim驱动强了，它对耦合噪声的抗性就强，不容易被拉出毛刺。但这个方法可能影响时序和功耗，要评估。
• 降低aggressor的驱动强度：aggressor驱动弱了，它的翻转slew变慢，耦合产生的dI/dt变小，感应出来的噪声幅度也变小。
• 拉开线间距：直接降低耦合电容值，效果最明显，但会占用更多绕线资源，可能造成其他区域拥挤。
• 屏蔽：在关键victim两侧加地线包裹，几乎完全消除耦合噪声，但资源开销更大。
• 调整布局：让victim和aggressor不要走平行长线，或者增加中间插入的缓冲器。

这里有一个经验：Noise修复往往不是单点动作，而是多轮迭代。先修掉最严重的一批，重新提取寄生参数后再看，因为布线上的微小变化可能影响耦合电容的量级。而且Noise修复容易和Timing修复产生冲突，你为了Noise把某条线改粗了、加了buffer，结果时序路径变快了或者变慢了。所以务必在每次Noise ECO之后重新跑一遍STA。

4.4 噪声分析的常用流程细节

噪声分析在工具里的体现，通常是在PrimeTime/Tempus做SI分析时同时输出crosstalk noise报告，或者用专门的RedHawk-SI等工具做更精细的动态噪声分析。前者是静态意义上的噪声检查，基于寄生参数和逻辑门的驱动能力计算脉冲幅度；后者会结合IR Drop和功耗数据，更贴近真实电磁环境。

我建议项目里静态和动态噪声都做：PR完成后的早期用静态SI快速收敛，signoff最后阶段用带实际VCD的动态噪声分析做二次确认。尤其是低功耗设计里带有电压域切换的模块，动态噪声往往比静态报出来的更严重，因为电压域切换瞬间电源电压会抖动，逻辑门的翻转阈值也在变化，叠加起来可能导致更恶劣的噪声影响。

5. Antenna：制造过程中容易被忽略的“隐形雷”

5.1 Antenna效应的原理

Antenna效应和前面三个问题都不同，它不是在芯片工作的时候产生的，而是芯片制造过程中“做”出来的。晶圆厂在用等离子体刻蚀金属层的时候，金属导线会像天线一样收集等离子体中的电荷。如果这根金属导线在某个制造步骤里只连到栅极氧化层，却没有有效的泄放路径，积累的电荷就可能把栅氧击穿。

这个效应在天线比（Antenna Ratio）里体现：被认为是“天线”的金属面积除以它连接到的栅极面积，比值越大，风险越高。代工厂会针对每一层金属给出允许的最大天线比。超过这个比值，芯片在制造后可能直接表现为漏电异常，或者一段时间后功能退化。

注意，天线效应发射的电荷来自未完成所有金属层的“半成品”状态。所以不同金属层的累计、面积、周长都会影响判断。有一些规则还要求把不同层的天线面积按权重累计，因为它可能贯穿多个工艺步骤。这也是为什么天线检查不能简单看单条走线的“总宽度”，而要考虑整条连接的累计路径。

5.2 为什么Antenna检查要在布线后专项做

PR工具在布局布线时确实内置了antenna规则检查，但那个检查通常基于粗略估算，和代工厂正式规则有一定差距。真正的天线签核需要在完整布线后，用版图验证工具跑DRC里的antenna检查，或者用Calibre等工具跑专门的antenna rule deck。

这里有个时间点的问题：PR阶段的天线检查相对粗糙，如果留着一堆隐患到签核前才跑专项检查，一旦发现大量violation，改起来会非常痛苦。因为修天线的操作是全局性的：你要在布线中打断高天线的路径，可能影响整条走线的绕线方向、金属层选择，甚至影响时序和DRC。

我个人的做法是，布线阶段就导入符合代工厂要求的antenna rule deck，并在route前开启PR工具自动修天线的选项。虽然正式签核还是要用独立的DRC工具再跑一遍，但PR阶段自动修过一轮之后，后面的天线violation数量会少很多，收敛快很多。

5.3 天线修复的三个常用手段

修天线和修DRC不一样，修DRC是改几何，修天线是打断电荷的“收集路径”。常用的手段有三类：

第一种是跳线（Metal Jump）或者叫换层。把一根高天线的金属线在中间通过Via跳转到别的金属层，然后再跳回来。跳线相当于把这段“天线”在物理上截断了，电荷收集路径被打断，天线效应风险就降下来。这个方法的优点对时序和布线影响小，缺点是会增加Via数量，可能引入新的EM热点或者IR问题。

第二种是加天线二极管（Antenna Diode）。在靠近高天线风险的位置接一个反向到地的二极管，给积累的电荷提供一条低阻抗泄放通路。这个方法修起来快，但占面积，而且二极管本身会带来漏电，对低功耗模块并不友好。一般除非走线空间实在不允许跳线，我才会优先考虑加二极管。

第三种是把天线面积分散到不同层。通过调整布线层级，让每一层的累计天线面积都不超过对应层的限制。这通常是前端绕线优化的工作，能在不增加额外器件的情况下解决问题，但并不是总能做到，因为绕线资源的限制很大。

5.4 一个真实的天线ECO踩坑记录

我想分享一个真实经历：某个项目在正式签核之前所有天线检查都是干净的，后来为了修一处时序，ECO改动了M3层一个via。重新跑Antenna规则，结果哗啦啦跳出来二三十条violation。当时第一反应是规则更新了？后来发现是因为ECO改动了M3层局部走线的连接关系，导致原先被某层截断的“天线路径”被打通了，整体天线面积比一下子超了。

后面我们花了整整一轮ECO时间，通过跳线把这批violation全部清除，才重新签核通过。这个教训让我养成了一个习惯：任何涉及金属层的ECO，不管改动多小，都要把antenna检查强制加入回归列表。千万不要因为改动很小就跳过，天线规则是跟工艺步骤强相关的，多一个连线关系，累积面积比的结论就可能完全变样。

5.5 天线检查的配置要点

最后补充天线检查配置的细节。天线规则不是一套放到所有项目都能通用的，它依赖代工厂的工艺版本和具体工艺菜单。你在做PR和DRV的时候，必须确认以下信息：

• 天线规则使用的工艺步骤模型（process step model）是否正确；
• 天线比的检查口径是面积比还是周长比，或者两者都有；
• 不同金属层的累计权重系数对不对；
• 是否需要把Vt、栅氧厚度不同的器件分开来判断；
• PR工具里的antenna rule和正式DRC deck是否一致。

这些不核对清楚的后果，要么就是检查结果太乐观，流片后栅氧损伤风险高；要么就是检查结果太悲观，大量根本不会触发效应的Info被报成Violation，修复工作白白耗费几天。每次新工艺平台第一次做signoff，我建议先拿一条已知结果的小模块demo跑通流程，确认报告口径和代工厂预期一致后，再铺开到全芯片。

6. 实战收敛：四大类问题如何一起修

6.1 先修什么，后修什么

前面几节分别讲完了四类问题的原理和修复方法。但在真实项目里，四类问题是同时存在的，你不可能一条一条来。我根据自己的项目经验，整理了一套解决问题的优先级标准。

第一优先级是IR Drop和EM，它们俩要一起分析、一起修复。原因很简单：电源网络是全局性的，你改了电源网络的结构，所有blocks的IR和EM都会变。先把电源网络的承载能力搞定，后面的时序、SI、Noise修复才有一个稳健的基础。如果你先修Noise，把一堆线拉开了，回头一看IR在某个区域又新报了几条，那之前的工作就需要返工。

第二优先级是Noise。Noise violation虽然多，但只要不是时钟和复位网络，数据路径上的个别毛刺风险相对可控。先用工具快速清掉高风险的Noise violation，把报告收敛到一个可控范围，再去处理Signoff的Timing。

第三优先级才是Antenna。因为天线修复属于物理属性操作，对时序和电源网络影响最小。但前面也说了，它必须在任何ECO之后统一回归，不能放到最后一次性修。

6.2 常见问题速查表

我把这几类问题在项目里最常见的错误认知和解决方向整理成了一个速查表，方便你对照排查。

6.3 贯穿整个项目的工程习惯

最后说几条我个人建议贯穿整个项目周期的工程习惯。

第一，signoff环境要在项目早期搭好，不要在项目快结束时才第一次跑完整的IR/EM和Antenna。很多人觉得项目早期数据不准，跑了也白跑。但早期哪怕只能用平均功耗跑一个初步IR云图，也能帮你发现power plan的结构性问题。等到后端全面完成，再发现power network有问题，改动成本就是几何级上涨。

第二，所有的analysis数据要用同一套基准。IR/EM的VCD、Noise的activity、Antenna的rule deck，每次回归都要明确版本。项目后期ECO频繁，很容易出现活动文件更新了但你没同步重新跑IR/EM，最后签核时用的还是旧数据。这样交付出去的风险非常大。

第三，每次修复完成后，不要只看violation数量有没有降，一定要看最差margin的变化方向。比如IR Drop的violation少了，但最差instance的压降从6%变成了7%，那说明你的修复虽然解决了部分边缘case，但主瓶颈反而恶化了。这种时候要停下里重新审视根本原因。

我自己跑过七八个项目的signoff，最大的体会是这四个问题都不是孤立存在的。IR Drop和EM是供电这棵树的根和干，Noise是信号线上的风，Antenna则是工艺那根弦不能松。真正高效的流程，是从设计早期就带着这四个约束去推floorplan和power plan，而不是等后端做完了再来做“体检”。你如果正在为一个新项目搭物理实现环境，我个人建议先把天线规则和IR/EM的分析环境提前搭好，不要拖到第一次signoff才想起补；后面你会感谢这个决定。