后端做到一定程度大家一听到 IR drop脑子里基本就是一套固定动作跑一版 vectorless dynamic全芯片最差点打一颗星跟阈值比一比报告一签完事。但如果你手里已经有一份门级仿真 VCD还在盘算要不要多花两天把它喂给 RedHawk我的建议是别省这一步。这篇文章从我自己被 vectorless 结果“骗”过一次的经历讲起把 vectorless 和 VCD 驱动的 dynamic IR drop 分析之间的差异、RedHawk 的实操流程、以及中间那些坑一条条掰开说清楚。这篇东西适合正在做后端物理实现、电源完整性分析或者 signoff 的工程师也适合刚接触 RedHawk、搞不清楚 VCD 到底该怎么用的朋友。我不打算讲太玄的理论你就当成一个同行在项目间隙跟你聊实操。1. vectorless 和 VCD 驱动到底差在哪1.1 vectorless 是怎么算 dynamic IR drop 的vectorless 这个名字初听有点抽象其实它的核心思路是不依赖任何仿真波形直接给每个标准单元一个活动率toggle rate和翻转概率probability再结合 Liberty 库里的功耗模型算出每个 instance 的平均功耗最后把这些功耗折算成电流源注入到电源网络上求解。RedHawk 做 vectorless dynamic 分析的时候会在平均活动率的基础上构造一个电流波形。它不知道怎么区分“这个模块现在在干活”和“这个模块正在睡觉”它只知道你告诉它这堆单元平均一小时翻转多少次。于是在某个时刻所有单元会按照一定的概率同时翻转形成一个看起来很像“动态最差”的场景。很多人在项目早期用这个结果做 floorplan 评估觉得够用因为它的覆盖面广跑一遍全芯片也就个把小时。但问题也出在这里vectorless 的“动态”带有很强的人造味道。它模拟的是一个在统计意义上比较差的瞬间却未必是产品真实运行时会出现的瞬间。1.2 为什么 vectorless 会高估或低估我见过很多刚入行的工程师天然觉得 vectorless 是保守的因为它会让所有单元一起翻转结果肯定偏大。实际完全不是这么回事。先说高估。如果 SOC 里有一个算力模块和一组总线你把它们都设成 50% 翻转率vectorless 可能在某个 step 让它们所有逻辑同时满翻转这会导致一个非常夸张的峰值电流。这种场景现实里基本不会出现因为数字逻辑的翻转受限于数据依赖、时钟相位和流水线节奏。结果就是 IR drop 被打高逼着你加一堆去耦电容浪费面积。再说低估这个更隐蔽。真实芯片的电流并不是均匀分布的而是存在强相关性的瞬态。举个例子一个 CPU 子系统的寄存器堆被唤醒时上百个触发器会在同一个时钟沿附近同时翻转这会让局部电源网络瞬时抽走一大股电流形成剧烈的 di/dt。而 vectorless 的均匀假设相当于把这一大股电流打散摊平到整个时间窗口里反而淹没了那个最尖锐的电压跌落峰。我自己在某次项目里遇到的情况就是这样。一颗中规模 SoCvectorless dynamic 分析显示最差 IR drop 在某个 IP 角落数值距离阈值还有 20mV 余量看着挺安全。后来门级仿真出来我把一段系统唤醒加总线 burst 的 VCD 喂给 RedHawk同一个角落的 dynamic IR drop 直接比 vectorless 结果恶化了 40mV。不是说 vectorless 错而是它根本覆盖不了那种时间相关的短时电流集中。1.3 什么时候必须上 VCD基于这个教训我现在对“必须上 VCD”的场合心里有杆秤设计里有大电流突发的模块比如 CPU、GPU、DSP 这类计算密集单元或者大带宽 bus。存在多电源域切换、power switch 开关瞬间。这些瞬态的 di/dt 非常猛vectorless 很难建模。设计已经在实现后期网表稳定马上要 signoff。这时候宁可多花时间也要获得贴近真实负载的压降结果。如果 vectorless 结果压在一个可疑的边缘值附近比如离阈值就差 10~30mV那必须用 VCD 驱动交叉验证一下。边缘值的 vectorless 结果既可能虚高也可能虚低不能直接签字。反过来如果项目还在早期 floorplan 阶段或者你只是想比较两个供电方案谁更好vectorless 完全够用因为它快、全、能反映相对趋势。这一点后面单独说。2. 把 VCD 喂给 RedHawk 之前需要想清楚的几件事2.1 VCD 不是“有就行”质量决定生死VCD 是 IEEE 1364 标准定义的一种文本波形格式记录信号值变化的时间和数值。RedHawk 能读 VCD但并不意味着随便一份 VCD 都能用。第一来源。如果你只有 RTL 仿真输出的 VCD那它的信号翻转来自功能模型跟综合后的门级单元没有一对一映射关系直接喂给 RedHawk 会导致 instance 对不上结果基本不可用。真正能用的是带 SDF 反标的门级仿真产生的 VCD因为这时候每个标准单元的翻转是真实发生过的。第二覆盖范围。RedHawk 做全芯片 dynamic IR drop理想情况下需要整个芯片在同一个时间段内的 VCD。如果你只 dump 了某一个子模块的波形其他模块在 VCD 里完全是静止的RedHawk 会把这些静止区域当成近乎 idle 来算功耗IR drop 自然会低估。现实中很多项目因为门级仿真跑不动全芯片只 dump 局部这种做法本身没问题但你要主动给未覆盖区域补一个 vectorless 的 activity backfill让那些单元至少有一个合理的功耗底噪否则结果会乐观得可怕。第三clock 翻转。时钟信号是整个芯片翻转最频繁的信号VCD 里 clock net 的翻转次数可能比数据信号高出几个数量级。如果直接把所有翻转都算成功耗结果会显著偏高。RedHawk 允许你把 clock pin 的 VCD 翻转排除掉改用库里的 clock toggle 数据或者专门的 clock activity 估算这一步不要省。2.2 时间窗口怎么选VCD 动辄几百 MB甚至几个 GB但 RedHawk 动态分析不是要把整个 VCD 从头看到尾。那个代价无论是内存还是 runtime 都无法接受。我的经验是窗口不在长在于覆盖关键瞬态。你真正要找的是那个“最猛烈”的时刻模块从低功耗模式唤醒、一次 cache miss 后的突发读取、总线从 idle 切到满带宽传输这些瞬间才是 dynamic IR drop 最可能触底的地方。具体窗口多大合适大部分情况下 10ns 到 50ns 就够了。RedHawk 内部动态求解的时间步长通常在皮秒量级你要是给个 5ps 的 step跑 10ns 就是 2000 个时间点全芯片的规模下已经是一个不小的计算量。窗口再拉长收益很低成本直线上升。如果 VCD 里有很长一段平稳期比如仿真从 0ns 开始先跑了一段复位然后才开始真正的业务操作那你完全没必要分析那段平稳区。RedHawk 里可以设置分析窗口的开始时间和结束时间直接从 VCD 里截取你关心的区间这种做法比重新生成一遍 VCD 要省事得多。2.3 数据准备清单在动手之前先把这几样东西备齐缺一样后边都会卡壳门级网表。注意网表里的 instance 命名必须跟 VCD 里的层次名完全一致这个是老生常谈但最容易出错。版图数据。做 power grid 拓扑需要 LEF、DEF 或者直接是版图数据RedHawk 需要知道电源走线长什么样、每条线的电阻电容是多少。寄生参数。最好有 SPEF 格式的 RC 提取结果尤其是 power net 上的电阻IR drop 就是 IR 的乘积R 都不准I 再准也算不出对的结果。Liberty 库。要包含 internal power 和 leakage power 模型尽量用带功耗查找表的版本别用那种只支持 timing 的精简库。波形文件。优先门级仿真的 VCD注意 timescale 和编码格式。Package model。对倒装芯片设计来说C4 bump 或者电源 pad 的位置、阻抗、封装 RLC 都需要给 RedHawk。如果没有 package model至少也要提供一个等效电源阻抗否则封装引起的压降完全没算进去。3. RedHawk 中 VCD 驱动的 dynamic IR drop 实操流程3.1 文件准备与目录规划RedHawk 这类工具对文件路径和命名很敏感。我习惯在每个分析开始前建一个干净的目录结构按场景分开避免不同 VCD 混在一起污染结果。比如这样划分design_data 目录放网表、DEF、SPEFlib 目录放各个工艺角下的 Liberty 库vcds 目录放不同场景的 VCDpkg 目录放封装模型run 目录放不同场景的运行脚本和输出结果。命名规范上我建议把场景名、工艺角、电压、温度、时间窗口都写进目录名。比如 run_scenario_wakeup_ss_0p81v_125c。这个东西看起来啰嗦但一个月之后回来看结果你不用重新翻脚本就知道当时跑的是什么状态。路径里绝对不要出现中文和空格EDA 工具对这类字符的兼容性时好时坏别在这种事上浪费时间。3.2 配置 VCD 映射与电源网络RedHawk 读入 design 之后第一件事是建立电源网络的拓扑关系。它会自动识别 power net 和 ground net但我强烈建议你手工确认一遍 VDD、VSS 对应的 net 名。特别是多电压域设计不同 domain 的 VDD 名字往往长得差不多一个字符之差就可能让 RedHawk 把整个 domain 的电源当成悬空。接下来就是在工具里把 VCD 挂到动态分析上。这里有一个关键步骤叫 activity mapping相当于把 VCD 里的信号翻转映射到网表里的 instance pin 上。工具一般会输出一堆 warning告诉你哪些 instance 在网表里找不到、哪些 pin 的信号在 VCD 里不存在。不要忽略这些 warning划拉一眼就关掉。你要看的是未映射比例如果在 1% 以上基本可以直接停掉去排查要么 VCD 与网表不是同一个版本要么层次结构不一致。电源网络配置里还有两个容易被忽略的点。一个是供电来源也就是 package model 的接入位置。如果是倒装芯片要确保 bump map 和设计一致bump 布局的偏差会直接影响电流路径。另一个是去耦电容模型on-die decap 是动态 IR drop 分析里最重要的“蓄水池”工具可以从版图里抽取但前提是你把 decap 单元识别开。如果这一步不做RedHawk 眼里整个电源网络没有任何电容缓冲结果会过于悲观。3.3 运行 Dynamic IR Drop 分析与结果解读设置完 VCD 和电源网络之后就可以设置动态分析参数了。分析类型选定 dynamic然后指定窗口的起止时间。这里我一般会把窗口开始设置在仿真稳定之后不要从 0ns 开始。原因很简单芯片刚开始仿真时信号还未进入正常工作状态那些翻转不代表真实负载。RedHawk 内部会按时间步长逐步求解所以还要设置一个合理的 step。我习惯先用一个比较粗的 step 跑通流程比如 20ps看结果大概没问题了再加密到 5ps 或者 10ps 重跑一次。跑完之后RedHawk 会给出每个时间点或最差时间点的电压云图、电流云图和电迁移结果。看结果的时候我建议你先别急着盯数字先看最差点落在哪、出现在哪个时间点。如果最差位置和 vectorless 结果完全不同那基本可以断定 vectorless 的 coverage 没有覆盖到真实危险区域。如果是数字差异大那就要回去检查前面提到的 VCD 质量问题和时间窗口选择问题。另一个值得看的维度是 power map 和 current map 在时间轴上的变化。你会很直观地看到某个热点模块在哪个时刻抽走电流这个时刻是否与 VCD 里的翻转集中区域吻合。如果不吻合说明 activity mapping 或者功耗计算环节有偏差。3.4 关键设置选项RedHawk 里跟 VCD 驱动 dynamic IR drop 相关的设置项不少我这几年用下来下面几个属于必调项时间步长。这是准确性和效率的平衡点。步长太大电流峰值会被时间平均抹平步长太小比如 1ps全芯片跑起来很痛苦。先用 10ps 跑看电流云图上的毛刺变化是否剧烈如果相邻两个 step 的峰值电流差异超过 30%再把 step 加密。封装模型中的电感 L。package 的 RLC 模型里L 对 di/dt 的影响远大于 R尤其在高频翻转场景下。如果封装模型里只有 R动态 IR drop 会被明显低估。是否包含 on-die decap。我前面提过这个必须开。开了之后结果会相对乐观但那个乐观是真实的因为芯片上真的有那些电容。电源域设置。多电压域设计里每个域要分别指定 VDD net。不要把两个域的 VDD 混在一个 set 里否则域间耦合电流会让结果失真。VCD 中 X 态和 Z 态的处理。VCD 里如果出现 X 或 ZRedHawk 无法判断翻转行为工具一般会按固定状态处理但这种处理会掩盖真实的翻转。最好在门级仿真阶段就通过约束避免 X 态传播别把这个锅甩给 RedHawk。4. 实测中的坑与排查经验4.1 VCD 时间戳同步问题有一次我拿到一份 VCD怎么跑结果都不对IR drop 曲线在某个时间点跳出一个荒谬的尖峰。排查了半天最后发现是 VCD 里$timescale声明的是 1ns而电源模型和库的时间基准是 ps。RedHawk 在转换时间戳时按默认单位处理导致整个翻转时刻被缩放了一千倍所有瞬态电流全部集中在了一个假时间点附近。所以拿到 VCD 的第一件事就是确认 timescale 声明和工具设置一致。另外VCD 从 0 时刻开始无所谓关键是你要检查那个被分析的时间点处于什么状态。我遇到过从 0ns 开始的 VCD 中前 20ns 一直是电源复位状态真正有用的工作负载在 200ns 之后才开始。这种情况下直接把窗口设在后半段别让 RedHawk 花时间算那些无关紧要的复位电流。4.2 结果异常偏大的常见原因我整理了一张自查表每次结果不合理的时侯对着看一遍现象可能原因处理办法全芯片 IR drop 整体偏高clock net 翻转被计入动态功耗在 activity 设置里排除 clock 翻转某个局部热点异常突出VCD 只 dump 了该模块其他区域被当 idle给未覆盖区域做 vectorless backfill所有模块压降趋势都异常陡峭package 模型 L 值过大或缺失 decap 电容检查封装模型与 decap 抽取结果随着时间上下剧烈抖动时间步长选得太大缩小 step 或调整 sample 时刻和 vectorless 差异全芯片一致地差Liberty 库功耗模型太粗换用带内部功耗查找表的库这里面我想特别提一下 clock net 的问题。很多人在 RTL 阶段生成 VCD 时没有意识到门级网表里的 clock 树被综合器插入了一堆 buffer这些 buffer 的翻转次数可能是寄存器的几十倍。如果把它们全部计入RedHawk 会把 clock 树的功耗算到几乎和逻辑功耗一样大动态压降自然整体偏高。更合理的做法是让 RedHawk 使用 clock activity 的预设值这些预设值来自时钟树综合时产生的 toggle rate会比 VCD 里逐周期翻转的记录更稳。4.3 从 IR drop 结果倒推功耗热点VCD 驱动的 dynamic IR drop 分析不只是拿一个最差电压值就完事它可以反过来帮你验证功耗热点。RedHawk 的 current map 会显示出每个区域抽走的电流密度。我曾经在一次分析里看到电源网络的某个远端角落电流密度异常高但那个模块的逻辑规模并不大。我还以为是网格建模错了后来回去翻 VCD发现那个时间段正好是这个模块在反复做乘加运算几十个 MAC 单元在几个周期内密集翻转虽然单元数量不多但翻转密度极高。这个热点在 vectorless 结果里完全看不出来因为 vectorless 会把活动率摊得很均匀。有了这个信息你就可以跟架构团队反馈让软件层面避免把这种突发负载安排到供电薄弱区域或者在后端设计上给这个模块多布几条电源 rail、加几组 decap。这种从结果倒推功耗热点的思路才是 VCD 驱动分析的真正价值。4.4 多个 VCD 场景的处理一个产品通常不只有一种使用场景。有人喜欢把所有场景的 VCD 拼成一个文件喂给 RedHawk觉得这样一次性覆盖所有情况。这个做法我劝你千万别做。因为不同场景之间的衔接处会出现大量伪翻转比如从一个场景切到另一个场景时寄存器状态突变RedHawk 会把这个瞬间当成巨大的同时翻转跑出一个根本不存在的压降尖峰。正确做法是每个场景单独建 run、单独跑、最后把各场景的最差结果取包络。RedHawk 也有一些多场景合并的功能但我个人还是倾向在脚本层面自己管理因为这样每个结果文件里只有单一场景的干净数据后续追溯和跟 signoff 报告对齐都方便。5. 什么时候该用 VCD什么时候 vectorless 足够5.1 快速迭代期vectorless 的适用场景项目早期网表还没稳定floorplan 一天改三版这种时候逼着每个版本都去跑门级仿真生成 VCD显然不现实。vectorless 在这个阶段是绝对的主力。它的优势很明显不需要仿真波形不依赖网表细节工具跑起来快结果能反映不同电源方案之间的相对优劣。比如你想比较两种 bump 布局对最差压降的影响用同一个 vectorless 设置跑两遍看结果差异这种相对比较是可靠的。因为它用的活动率假设一致误差方向也一致横向对比的结论站得住脚。5.2 signoff 前VCD 驱动分析的必要性到了 signoff 阶段情况就变了。网表已经收敛时序基本冻结这时候你唯一缺的就是一个靠谱的动态 IR drop 结果来签字。我的做法是至少准备两个场景的 VCD一个是典型高功耗场景比如全速执行某一组 benchmark一个是电源切换或唤醒场景这类瞬态最容易触发动态压降触底。把这两个场景喂给 RedHawk得到的压降结果才具备 signoff 级可信度。同时我不会彻底扔掉 vectorless 结果而是让两者互相印证。如果 vectorless 的最差点和 VCD 驱动的最差点完全对不上说明之前所有的电源规划都是基于错误的热点假设这个问题必须查到底。如果两个结果的最差点位置接近数值上一个偏大一个偏小那红绿灯判断就非常清晰按偏大的做 decap 预算按偏小的做漏电预算。5.3 成本与收益权衡你可能会算一笔账VCD 驱动分析要额外跑门级仿真要花时间处理波形文件RedHawk runtime 也比 vectorless 多不少整个流程下来多花三五天。值不值从我的经验看太值了。一颗芯片回片之后如果因为 IR drop 导致某一频率点时序失效轻则降频出售重则重新 spin成本是一个分析流程的好几个数量级。更别提那种只在特定唤醒序列下才触发的动态压降问题vectorless 永远不会告诉你它存在回片之后再复现定位难度高到让人崩溃。所以我个人现在的工作习惯是把 vectorless 当筛子把全芯片的各个角落筛一遍找出可疑区域到了 signoff 阶段再找两三个能代表真实产品驱动方式的 VCD 场景喂给 RedHawk看那层窗户纸上还有没有洞。最后说一个我踩过几次坑之后形成的原则拿到 RedHawk 的 dynamic IR drop 结果图别只看最差点颜色深不深先花半小时确认这个最差点出现的时刻在 VCD 里是不是真的有对应的翻转活动。如果那个时刻的 VCD 里一片平静那这个结果八成是配置问题。IR drop 分析这件事工具只能帮你把数学解出来物理上合不合理最后还是得靠工程师自己的判断。
后端做到一定程度大家一听到 IR drop脑子里基本就是一套固定动作跑一版 vectorless dynamic全芯片最差点打一颗星跟阈值比一比报告一签完事。但如果你手里已经有一份门级仿真 VCD还在盘算要不要多花两天把它喂给 RedHawk我的建议是别省这一步。这篇文章从我自己被 vectorless 结果“骗”过一次的经历讲起把 vectorless 和 VCD 驱动的 dynamic IR drop 分析之间的差异、RedHawk 的实操流程、以及中间那些坑一条条掰开说清楚。这篇东西适合正在做后端物理实现、电源完整性分析或者 signoff 的工程师也适合刚接触 RedHawk、搞不清楚 VCD 到底该怎么用的朋友。我不打算讲太玄的理论你就当成一个同行在项目间隙跟你聊实操。1. vectorless 和 VCD 驱动到底差在哪1.1 vectorless 是怎么算 dynamic IR drop 的vectorless 这个名字初听有点抽象其实它的核心思路是不依赖任何仿真波形直接给每个标准单元一个活动率toggle rate和翻转概率probability再结合 Liberty 库里的功耗模型算出每个 instance 的平均功耗最后把这些功耗折算成电流源注入到电源网络上求解。RedHawk 做 vectorless dynamic 分析的时候会在平均活动率的基础上构造一个电流波形。它不知道怎么区分“这个模块现在在干活”和“这个模块正在睡觉”它只知道你告诉它这堆单元平均一小时翻转多少次。于是在某个时刻所有单元会按照一定的概率同时翻转形成一个看起来很像“动态最差”的场景。很多人在项目早期用这个结果做 floorplan 评估觉得够用因为它的覆盖面广跑一遍全芯片也就个把小时。但问题也出在这里vectorless 的“动态”带有很强的人造味道。它模拟的是一个在统计意义上比较差的瞬间却未必是产品真实运行时会出现的瞬间。1.2 为什么 vectorless 会高估或低估我见过很多刚入行的工程师天然觉得 vectorless 是保守的因为它会让所有单元一起翻转结果肯定偏大。实际完全不是这么回事。先说高估。如果 SOC 里有一个算力模块和一组总线你把它们都设成 50% 翻转率vectorless 可能在某个 step 让它们所有逻辑同时满翻转这会导致一个非常夸张的峰值电流。这种场景现实里基本不会出现因为数字逻辑的翻转受限于数据依赖、时钟相位和流水线节奏。结果就是 IR drop 被打高逼着你加一堆去耦电容浪费面积。再说低估这个更隐蔽。真实芯片的电流并不是均匀分布的而是存在强相关性的瞬态。举个例子一个 CPU 子系统的寄存器堆被唤醒时上百个触发器会在同一个时钟沿附近同时翻转这会让局部电源网络瞬时抽走一大股电流形成剧烈的 di/dt。而 vectorless 的均匀假设相当于把这一大股电流打散摊平到整个时间窗口里反而淹没了那个最尖锐的电压跌落峰。我自己在某次项目里遇到的情况就是这样。一颗中规模 SoCvectorless dynamic 分析显示最差 IR drop 在某个 IP 角落数值距离阈值还有 20mV 余量看着挺安全。后来门级仿真出来我把一段系统唤醒加总线 burst 的 VCD 喂给 RedHawk同一个角落的 dynamic IR drop 直接比 vectorless 结果恶化了 40mV。不是说 vectorless 错而是它根本覆盖不了那种时间相关的短时电流集中。1.3 什么时候必须上 VCD基于这个教训我现在对“必须上 VCD”的场合心里有杆秤设计里有大电流突发的模块比如 CPU、GPU、DSP 这类计算密集单元或者大带宽 bus。存在多电源域切换、power switch 开关瞬间。这些瞬态的 di/dt 非常猛vectorless 很难建模。设计已经在实现后期网表稳定马上要 signoff。这时候宁可多花时间也要获得贴近真实负载的压降结果。如果 vectorless 结果压在一个可疑的边缘值附近比如离阈值就差 10~30mV那必须用 VCD 驱动交叉验证一下。边缘值的 vectorless 结果既可能虚高也可能虚低不能直接签字。反过来如果项目还在早期 floorplan 阶段或者你只是想比较两个供电方案谁更好vectorless 完全够用因为它快、全、能反映相对趋势。这一点后面单独说。2. 把 VCD 喂给 RedHawk 之前需要想清楚的几件事2.1 VCD 不是“有就行”质量决定生死VCD 是 IEEE 1364 标准定义的一种文本波形格式记录信号值变化的时间和数值。RedHawk 能读 VCD但并不意味着随便一份 VCD 都能用。第一来源。如果你只有 RTL 仿真输出的 VCD那它的信号翻转来自功能模型跟综合后的门级单元没有一对一映射关系直接喂给 RedHawk 会导致 instance 对不上结果基本不可用。真正能用的是带 SDF 反标的门级仿真产生的 VCD因为这时候每个标准单元的翻转是真实发生过的。第二覆盖范围。RedHawk 做全芯片 dynamic IR drop理想情况下需要整个芯片在同一个时间段内的 VCD。如果你只 dump 了某一个子模块的波形其他模块在 VCD 里完全是静止的RedHawk 会把这些静止区域当成近乎 idle 来算功耗IR drop 自然会低估。现实中很多项目因为门级仿真跑不动全芯片只 dump 局部这种做法本身没问题但你要主动给未覆盖区域补一个 vectorless 的 activity backfill让那些单元至少有一个合理的功耗底噪否则结果会乐观得可怕。第三clock 翻转。时钟信号是整个芯片翻转最频繁的信号VCD 里 clock net 的翻转次数可能比数据信号高出几个数量级。如果直接把所有翻转都算成功耗结果会显著偏高。RedHawk 允许你把 clock pin 的 VCD 翻转排除掉改用库里的 clock toggle 数据或者专门的 clock activity 估算这一步不要省。2.2 时间窗口怎么选VCD 动辄几百 MB甚至几个 GB但 RedHawk 动态分析不是要把整个 VCD 从头看到尾。那个代价无论是内存还是 runtime 都无法接受。我的经验是窗口不在长在于覆盖关键瞬态。你真正要找的是那个“最猛烈”的时刻模块从低功耗模式唤醒、一次 cache miss 后的突发读取、总线从 idle 切到满带宽传输这些瞬间才是 dynamic IR drop 最可能触底的地方。具体窗口多大合适大部分情况下 10ns 到 50ns 就够了。RedHawk 内部动态求解的时间步长通常在皮秒量级你要是给个 5ps 的 step跑 10ns 就是 2000 个时间点全芯片的规模下已经是一个不小的计算量。窗口再拉长收益很低成本直线上升。如果 VCD 里有很长一段平稳期比如仿真从 0ns 开始先跑了一段复位然后才开始真正的业务操作那你完全没必要分析那段平稳区。RedHawk 里可以设置分析窗口的开始时间和结束时间直接从 VCD 里截取你关心的区间这种做法比重新生成一遍 VCD 要省事得多。2.3 数据准备清单在动手之前先把这几样东西备齐缺一样后边都会卡壳门级网表。注意网表里的 instance 命名必须跟 VCD 里的层次名完全一致这个是老生常谈但最容易出错。版图数据。做 power grid 拓扑需要 LEF、DEF 或者直接是版图数据RedHawk 需要知道电源走线长什么样、每条线的电阻电容是多少。寄生参数。最好有 SPEF 格式的 RC 提取结果尤其是 power net 上的电阻IR drop 就是 IR 的乘积R 都不准I 再准也算不出对的结果。Liberty 库。要包含 internal power 和 leakage power 模型尽量用带功耗查找表的版本别用那种只支持 timing 的精简库。波形文件。优先门级仿真的 VCD注意 timescale 和编码格式。Package model。对倒装芯片设计来说C4 bump 或者电源 pad 的位置、阻抗、封装 RLC 都需要给 RedHawk。如果没有 package model至少也要提供一个等效电源阻抗否则封装引起的压降完全没算进去。3. RedHawk 中 VCD 驱动的 dynamic IR drop 实操流程3.1 文件准备与目录规划RedHawk 这类工具对文件路径和命名很敏感。我习惯在每个分析开始前建一个干净的目录结构按场景分开避免不同 VCD 混在一起污染结果。比如这样划分design_data 目录放网表、DEF、SPEFlib 目录放各个工艺角下的 Liberty 库vcds 目录放不同场景的 VCDpkg 目录放封装模型run 目录放不同场景的运行脚本和输出结果。命名规范上我建议把场景名、工艺角、电压、温度、时间窗口都写进目录名。比如 run_scenario_wakeup_ss_0p81v_125c。这个东西看起来啰嗦但一个月之后回来看结果你不用重新翻脚本就知道当时跑的是什么状态。路径里绝对不要出现中文和空格EDA 工具对这类字符的兼容性时好时坏别在这种事上浪费时间。3.2 配置 VCD 映射与电源网络RedHawk 读入 design 之后第一件事是建立电源网络的拓扑关系。它会自动识别 power net 和 ground net但我强烈建议你手工确认一遍 VDD、VSS 对应的 net 名。特别是多电压域设计不同 domain 的 VDD 名字往往长得差不多一个字符之差就可能让 RedHawk 把整个 domain 的电源当成悬空。接下来就是在工具里把 VCD 挂到动态分析上。这里有一个关键步骤叫 activity mapping相当于把 VCD 里的信号翻转映射到网表里的 instance pin 上。工具一般会输出一堆 warning告诉你哪些 instance 在网表里找不到、哪些 pin 的信号在 VCD 里不存在。不要忽略这些 warning划拉一眼就关掉。你要看的是未映射比例如果在 1% 以上基本可以直接停掉去排查要么 VCD 与网表不是同一个版本要么层次结构不一致。电源网络配置里还有两个容易被忽略的点。一个是供电来源也就是 package model 的接入位置。如果是倒装芯片要确保 bump map 和设计一致bump 布局的偏差会直接影响电流路径。另一个是去耦电容模型on-die decap 是动态 IR drop 分析里最重要的“蓄水池”工具可以从版图里抽取但前提是你把 decap 单元识别开。如果这一步不做RedHawk 眼里整个电源网络没有任何电容缓冲结果会过于悲观。3.3 运行 Dynamic IR Drop 分析与结果解读设置完 VCD 和电源网络之后就可以设置动态分析参数了。分析类型选定 dynamic然后指定窗口的起止时间。这里我一般会把窗口开始设置在仿真稳定之后不要从 0ns 开始。原因很简单芯片刚开始仿真时信号还未进入正常工作状态那些翻转不代表真实负载。RedHawk 内部会按时间步长逐步求解所以还要设置一个合理的 step。我习惯先用一个比较粗的 step 跑通流程比如 20ps看结果大概没问题了再加密到 5ps 或者 10ps 重跑一次。跑完之后RedHawk 会给出每个时间点或最差时间点的电压云图、电流云图和电迁移结果。看结果的时候我建议你先别急着盯数字先看最差点落在哪、出现在哪个时间点。如果最差位置和 vectorless 结果完全不同那基本可以断定 vectorless 的 coverage 没有覆盖到真实危险区域。如果是数字差异大那就要回去检查前面提到的 VCD 质量问题和时间窗口选择问题。另一个值得看的维度是 power map 和 current map 在时间轴上的变化。你会很直观地看到某个热点模块在哪个时刻抽走电流这个时刻是否与 VCD 里的翻转集中区域吻合。如果不吻合说明 activity mapping 或者功耗计算环节有偏差。3.4 关键设置选项RedHawk 里跟 VCD 驱动 dynamic IR drop 相关的设置项不少我这几年用下来下面几个属于必调项时间步长。这是准确性和效率的平衡点。步长太大电流峰值会被时间平均抹平步长太小比如 1ps全芯片跑起来很痛苦。先用 10ps 跑看电流云图上的毛刺变化是否剧烈如果相邻两个 step 的峰值电流差异超过 30%再把 step 加密。封装模型中的电感 L。package 的 RLC 模型里L 对 di/dt 的影响远大于 R尤其在高频翻转场景下。如果封装模型里只有 R动态 IR drop 会被明显低估。是否包含 on-die decap。我前面提过这个必须开。开了之后结果会相对乐观但那个乐观是真实的因为芯片上真的有那些电容。电源域设置。多电压域设计里每个域要分别指定 VDD net。不要把两个域的 VDD 混在一个 set 里否则域间耦合电流会让结果失真。VCD 中 X 态和 Z 态的处理。VCD 里如果出现 X 或 ZRedHawk 无法判断翻转行为工具一般会按固定状态处理但这种处理会掩盖真实的翻转。最好在门级仿真阶段就通过约束避免 X 态传播别把这个锅甩给 RedHawk。4. 实测中的坑与排查经验4.1 VCD 时间戳同步问题有一次我拿到一份 VCD怎么跑结果都不对IR drop 曲线在某个时间点跳出一个荒谬的尖峰。排查了半天最后发现是 VCD 里$timescale声明的是 1ns而电源模型和库的时间基准是 ps。RedHawk 在转换时间戳时按默认单位处理导致整个翻转时刻被缩放了一千倍所有瞬态电流全部集中在了一个假时间点附近。所以拿到 VCD 的第一件事就是确认 timescale 声明和工具设置一致。另外VCD 从 0 时刻开始无所谓关键是你要检查那个被分析的时间点处于什么状态。我遇到过从 0ns 开始的 VCD 中前 20ns 一直是电源复位状态真正有用的工作负载在 200ns 之后才开始。这种情况下直接把窗口设在后半段别让 RedHawk 花时间算那些无关紧要的复位电流。4.2 结果异常偏大的常见原因我整理了一张自查表每次结果不合理的时侯对着看一遍现象可能原因处理办法全芯片 IR drop 整体偏高clock net 翻转被计入动态功耗在 activity 设置里排除 clock 翻转某个局部热点异常突出VCD 只 dump 了该模块其他区域被当 idle给未覆盖区域做 vectorless backfill所有模块压降趋势都异常陡峭package 模型 L 值过大或缺失 decap 电容检查封装模型与 decap 抽取结果随着时间上下剧烈抖动时间步长选得太大缩小 step 或调整 sample 时刻和 vectorless 差异全芯片一致地差Liberty 库功耗模型太粗换用带内部功耗查找表的库这里面我想特别提一下 clock net 的问题。很多人在 RTL 阶段生成 VCD 时没有意识到门级网表里的 clock 树被综合器插入了一堆 buffer这些 buffer 的翻转次数可能是寄存器的几十倍。如果把它们全部计入RedHawk 会把 clock 树的功耗算到几乎和逻辑功耗一样大动态压降自然整体偏高。更合理的做法是让 RedHawk 使用 clock activity 的预设值这些预设值来自时钟树综合时产生的 toggle rate会比 VCD 里逐周期翻转的记录更稳。4.3 从 IR drop 结果倒推功耗热点VCD 驱动的 dynamic IR drop 分析不只是拿一个最差电压值就完事它可以反过来帮你验证功耗热点。RedHawk 的 current map 会显示出每个区域抽走的电流密度。我曾经在一次分析里看到电源网络的某个远端角落电流密度异常高但那个模块的逻辑规模并不大。我还以为是网格建模错了后来回去翻 VCD发现那个时间段正好是这个模块在反复做乘加运算几十个 MAC 单元在几个周期内密集翻转虽然单元数量不多但翻转密度极高。这个热点在 vectorless 结果里完全看不出来因为 vectorless 会把活动率摊得很均匀。有了这个信息你就可以跟架构团队反馈让软件层面避免把这种突发负载安排到供电薄弱区域或者在后端设计上给这个模块多布几条电源 rail、加几组 decap。这种从结果倒推功耗热点的思路才是 VCD 驱动分析的真正价值。4.4 多个 VCD 场景的处理一个产品通常不只有一种使用场景。有人喜欢把所有场景的 VCD 拼成一个文件喂给 RedHawk觉得这样一次性覆盖所有情况。这个做法我劝你千万别做。因为不同场景之间的衔接处会出现大量伪翻转比如从一个场景切到另一个场景时寄存器状态突变RedHawk 会把这个瞬间当成巨大的同时翻转跑出一个根本不存在的压降尖峰。正确做法是每个场景单独建 run、单独跑、最后把各场景的最差结果取包络。RedHawk 也有一些多场景合并的功能但我个人还是倾向在脚本层面自己管理因为这样每个结果文件里只有单一场景的干净数据后续追溯和跟 signoff 报告对齐都方便。5. 什么时候该用 VCD什么时候 vectorless 足够5.1 快速迭代期vectorless 的适用场景项目早期网表还没稳定floorplan 一天改三版这种时候逼着每个版本都去跑门级仿真生成 VCD显然不现实。vectorless 在这个阶段是绝对的主力。它的优势很明显不需要仿真波形不依赖网表细节工具跑起来快结果能反映不同电源方案之间的相对优劣。比如你想比较两种 bump 布局对最差压降的影响用同一个 vectorless 设置跑两遍看结果差异这种相对比较是可靠的。因为它用的活动率假设一致误差方向也一致横向对比的结论站得住脚。5.2 signoff 前VCD 驱动分析的必要性到了 signoff 阶段情况就变了。网表已经收敛时序基本冻结这时候你唯一缺的就是一个靠谱的动态 IR drop 结果来签字。我的做法是至少准备两个场景的 VCD一个是典型高功耗场景比如全速执行某一组 benchmark一个是电源切换或唤醒场景这类瞬态最容易触发动态压降触底。把这两个场景喂给 RedHawk得到的压降结果才具备 signoff 级可信度。同时我不会彻底扔掉 vectorless 结果而是让两者互相印证。如果 vectorless 的最差点和 VCD 驱动的最差点完全对不上说明之前所有的电源规划都是基于错误的热点假设这个问题必须查到底。如果两个结果的最差点位置接近数值上一个偏大一个偏小那红绿灯判断就非常清晰按偏大的做 decap 预算按偏小的做漏电预算。5.3 成本与收益权衡你可能会算一笔账VCD 驱动分析要额外跑门级仿真要花时间处理波形文件RedHawk runtime 也比 vectorless 多不少整个流程下来多花三五天。值不值从我的经验看太值了。一颗芯片回片之后如果因为 IR drop 导致某一频率点时序失效轻则降频出售重则重新 spin成本是一个分析流程的好几个数量级。更别提那种只在特定唤醒序列下才触发的动态压降问题vectorless 永远不会告诉你它存在回片之后再复现定位难度高到让人崩溃。所以我个人现在的工作习惯是把 vectorless 当筛子把全芯片的各个角落筛一遍找出可疑区域到了 signoff 阶段再找两三个能代表真实产品驱动方式的 VCD 场景喂给 RedHawk看那层窗户纸上还有没有洞。最后说一个我踩过几次坑之后形成的原则拿到 RedHawk 的 dynamic IR drop 结果图别只看最差点颜色深不深先花半小时确认这个最差点出现的时刻在 VCD 里是不是真的有对应的翻转活动。如果那个时刻的 VCD 里一片平静那这个结果八成是配置问题。IR drop 分析这件事工具只能帮你把数学解出来物理上合不合理最后还是得靠工程师自己的判断。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
