Cerebrus 22.1x用户指南：三层模型与PPA收敛避坑

简介《Cadence Cerebrus User Guide》面向借助 Cadence Cerebrus 优化电子设计自动化流程的工程师和技术人员围绕 22.1x 版本说明工具的功能、特定指令与使用案例帮助读者理解软件在真实设计流程中的定位与操作要点。资源包仅含 1 个 PDF 文件大小约 6.19MB单文件便于本地保存、关键词检索和按章节查阅。目前已有 543 人学习下载在同类工具文档中具备一定参考需求。指南更新至 2023 年 12 月可用于了解 Cerebrus 的功能入口、应用场景与流程优化思路适合作为日常查询和方案比对资料对希望系统掌握该版本功能、提升设计效率的读者较为实用也可用于团队内部培训和技术交流时快速定位知识点由于内容由 OCR 扫描生成个别字词可能存在识别偏差阅读时需结合上下文核对。文档还附有版权、商标和受限使用声明提醒读者在引用与传播时注意合规边界。1. 一份 22.1x 的 Cerebrus 用户指南能替你挡掉多少次白跑的 run去年冬天我盯着一轮跑了十几个小时的 Cerebrus run几十个 scenario 的 cost 曲线像心电图一样上下跳最后定位到的问题很朴素primitive 的注入时机压在 flow phase 之前那个阶段压根不参与成本核算等于白调。这类问题不需要多深的数学只需要有人提前告诉你哪个阶段算什么、哪个旋钮在哪一步才有效。这份 22.1x 的用户指南2023 年 12 月更新就是干这个的它把 Cerebrus 这套 ML 驱动的 RTL-to-GDS 流程优化框架拆成 flow phase、primitive、scenario 三层再往上叠 config、Web UI、RAK 和几个专用 App。适合已经能跑通综合到 STA 全流程、但一提到 PPA 收敛就靠手工试参数的实现工程师也适合刚接手集群、需要判断这次 run 值不值得等的负责人。2. 先把三层模型立住flow phase、primitive 与 scenario在动手改任何一行配置之前得先接受一个事实Cerebrus 不是自动帮你调参的黑盒它是一台把设计师经验编码成可搜索空间的机器。你对 flow 的理解越结构化它搜得越准你糊弄它它就还你一堆看起来收敛、signoff 时全崩的解。这三层模型就是编码方式。2.1 手工调参为什么在 signoff 前失效手工调参的隐含假设是参数之间近似独立改一下 placement 的 effort面积涨一点时序好一点凭经验能预判方向。这个假设在单个 phase 内勉强成立跨 phase 就崩了。prects 阶段为了 WNS 把某条路径的逻辑层级压平到 postcts 时钟树一插这条路径的 skew 变成主导项前面省下的裕量全被吃掉再往后到 postrouteRC 提取一上来原本靠估算撑住的 slack 直接翻负。更麻烦的是搜索空间本身就是乘积级的。假设你有 6 个 primitive每个 4 个取值那就是 4096 种组合而每种组合要跑完一整条 flow 才能拿到真实 PPA。人肉试 20 组已经是极限采样率不到 0.5%剩下的空间里有多少个更优解完全靠运气。血泪经验是手工调参出来的最优解往往只是你试过的那几个里最好的不是空间里最好的。Cerebrus 换了个思路它不要求参数独立而是把整条 flow 的每个 phase 当作一次可观测的状态转移用强化学习在组合空间里做有偏采样——跑到当前看起来有希望的区域就多采明显变差的区域就少采。这解释了为什么它能在几十个 scenario 内找到比手工试两百组更好的解也解释了为什么 cost function 写错时它比手工更容易跑偏它真的会朝你写的方向全力优化。2.2 flow phase 是成本核算的坐标系flow phase 是这份指南里最容易被跳过的概念也是最容易踩坑的地方。Cerebrus 把一条实现流程切成若干可命名的阶段成本核算和 primitive 评估都挂在这些阶段上。指南里反复出现的是 syn_opt、prects、postcts、postroute、signoff_opt 这五个22.1x 版本默认对它们计算 cost而 syn_generic、syn_map、floorplan、route 这几个在早期版本里默认是被忽略的。这里有个版本差异必须记牢。22.14 起cts 和 postcts 的 primitive 统一在 postcts 阶段评估route 和 postroute 的 primitive 统一在 postroute 阶段评估——也就是说同一个物理动作的旋钮被归并到同一个成本观测点上避免在 cts 阶段评估、但效果要到 postroute 才显形这种错位。如果你拿的是更早版本的指南看到 primitive 表里的评估阶段和 22.14 不一致不是你理解错了是版本真的改了。为什么这个坐标系重要因为 cost 是在 phase 结束时采样的。你在一个不参与 cost 计算的 phase 里定义 primitive它照样会被注入、照样改变网表但优化器看不到它的贡献于是它在这一轮里学到的这个方向没用其实是假信号。后面第 5 章会专门讲这个坑。2.3 primitive 是唯一可以被机器拧的旋钮primitive 这个词在指南里出现频率最高本质就是把一条 set_db 命令、一个 Tcl 变量或者一个 flow step 命令包装成带类型、带取值范围、带作用阶段的可调参数对象。它规定了三件事调什么命令模板、能调到哪取值范围或枚举、什么时候调作用阶段。数据类型上指南列的是整型、浮点、字符串、枚举、布尔这几类属性上关键的是默认值、取值范围、作用阶段applies_to和过滤条件filter。过滤条件的作用是让某个 primitive 只在特定条件下才进入搜索空间比如只在某个 design 或某种 flow 变体下生效避免把不适用的旋钮也塞进去稀释采样预算。有个容易被忽略的区分不是所有 primitive 都在同一个时刻被评估。指南里专门有一节讲延迟评估delayed assessment意思是某些旋钮的效果必须等后续 phase 才稳定那就不在注入它的那个 phase 打分而是延后到效果可见的阶段。这跟 2.2 说的合并评估是同一个设计哲学的两面。2.4 scenario 是 phase 与取值的一次采样一个 scenario 就是在某个 flow phase 上给一组 primitive 赋一组具体取值的一次完整执行。base scenario 是不做任何调整的基线其他所有 scenario 的 cost 都相对它计算。指南里两处默认值变动值得注意max_scenarios 在 22.13 起不再依赖 primitive 的数量而是根据可用机器资源和时间预算自动调整WNS(100) 在 22.14 起取代 WNS 成为默认的时序指标显示在 HTML 报告的 QoR 页面。WNS(100) 这个改动看起来小实际影响不小。WNS 只取最差的那一条路径噪声极大一条路径的估算误差就能让整个 cost 抖动WNS(100) 取最差的一百条路径做聚合对单点噪声更鲁棒优化器收到的梯度信号更平滑。如果你发现升级后 cost 曲线比以前平了不是优化器变懒了是评价指标变稳了。2.5 用目录结构反查哪一章解决你的问题指南正文十章加一个 FAQ从头读到尾大概要两天实际没人这么干。我的用法是把它当查询手册按症状找章节你现在的症状翻哪一章关键内容不知道 config 里该写什么第 6 章 配置优化路径组、权重、bootstrap 取值、cost 函数primitive 定义了但没效果第 5 章 使用 primitive数据类型、属性、注入命令、延迟评估run 卡住或作业排队不动第 4 章 运行与第 10 章 FAQ日志、distribution script、TMP 目录、重启想复用上一轮的模型第 4 章 模型复用统一输出模型、scenario 重放想看实时状态或报告第 7 章 Web UILive 模式、静态 HTML、cost 改善图想先跑个现成的例子第 8 章 RAK快速上手包、命令行与浏览器输出要做 floorplan 或 VT 专项第 9 章 AppsFP-Opt、Margins、VT、Clock 等环境或 setup 报错第 10 章 FAQsetup 指南、输出检查、调试技巧这张表的价值在于它省掉的是通读两章才发现答案在第三行的时间。新手建议从第 2 章和第 4 章起把三层模型和一次完整 run 的骨架建立起来再回头补第 5、6 章的细节。3. 跑通第一个 run从 config 到 live UI 的最小闭环理论立住之后就该动手。这一章的目标很明确在你自己的机器或集群上用最小的配置量跑出一个有 base scenario、有 cost 比较、能在浏览器里看的 run。跑通一次比读十遍指南有用。3.1 前置条件不止是 license指南开篇列的前置条件写得客气熟悉完整实现流程综合、布局布线、静态时序分析、熟悉 UNIX 和 Tcl/Tk。翻译成人话是——你得能手工把这条 flow 跑通能看懂 log 里的时序报告能自己写 Tcl 改 flow step。Cerebrus 不负责帮你搭 flow它负责在你搭好的 flow 上做搜索flow 本身有错它会忠实地把错误放大几十倍。动手前我会强制检查四件事。第一版本对齐cerebrus -version出来的版本号要和你手上这份指南的 22.1x 对得上跨大版本的配置语法和默认值差异足以让你怀疑人生。第二flow 能否单跑不加任何 Cerebrus 参数用原始脚本跑一遍完整流程确认没有 setup 违例、没有缺失的库、STA 能出报告。第三路径组是否定义时序成本离不开路径组指南把路径组列为必需项空着跑出来的 cost 没有意义。第四集群侧是否通如果用 LSF先确认提交一个空作业能正常排队和回收再让 Cerebrus 去派发。flow 接入方式有两种指南第 3 章讲得很细。一种是外层控制流包装outer control flow wrapping把现有脚本拆成一个个 flow step由 Cerebrus 调度另一种是在现有脚本里注入 Cerebrus 的库调用改动量小但耦合深。新手优先选前者因为出问题时边界清晰日志也好定位。包装的骨架大概是# flow_wrap.tcl —— 把已有的实现脚本拆成可调度的 flow step create_flow_step -name synth_opt -command {source scripts/synth.tcl} create_flow_step -name place -command {source scripts/place.tcl} create_flow_step -name cts -command {source scripts/cts.tcl} create_flow_step -name route -command {source scripts/route.tcl} create_flow_step -name signoff -command {source scripts/sta.tcl}这段的作用是把整条 flow 切成五个可命名的阶段。-name必须和后续 config 里引用的 phase 名一致写错一个字母对应的 primitive 就找不到挂载点表现是配置没报错但成本纹丝不动。-command里用source而不是直接内联几千行脚本是为了让每个 step 的失败点能单独定位——哪个 step 挂了看它 source 的那个脚本的日志就行。3.2 一份最小可跑配置配置文件的字段很多但第一次跑不需要全写。能撑起一次有效搜索的最小集合是路径组、scenario 数量上限、cost 权重、统一模型开关。其余的先留默认。# config.tcl —— 最小可跑骨架属性名以本地 get_db -help cerebrus_* 为准 # 1) 时序成本依赖的路径组必填空着 cost 没有意义 set_db cerebrus_path_groups {clk_group reg_group} # 2) 本轮最多生成多少个 scenario按机器核数和时间预算估 set_db cerebrus_max_scenarios 24 # 3) 多输入模型合并成统一输出模型22.14 起默认 true set_db cerebrus_ml_generate_unified_model true # 4) cost 权重时序占大头 leakage 和面积做约束 set_db cerebrus_cost_metric_weights { timing.setup.wns 0.60 power.leakage 0.25 area 0.15 }逐项说清楚。路径组是成本计算的分组维度指南把它标为必需项实际含义是你关心哪些路径的时序常见做法是按时钟域和关键数据路径分两组不要图省事只写一个全局组。scenario 数量上限不要拍脑袋往大里写先在单机小规模验证 10 到 20 个能跑通、cost 曲线有区分度再上集群放大。统一模型开关在 22.13 是新功能、22.14 变成默认只有在用-in_models复用人模型时才有意义第一次跑保持默认即可。cost 权重这块最容易翻车。三个数加起来必须是 1或者按比例归一时序权重低于 0.5 基本等于放弃时序跑出来的解面积漂亮但 signoff 全红。另外注意 22.14 起 hold 成本默认参与计算你如果在旧版本上调过关闭 hold 成本的开关升级后要重新确认权重表——报告的权重表格式也跟着变了。3.3 启动命令与参数配置齐了之后启动就一行但每个参数都影响后续几小时的资源占用# 启动一轮 Cerebrus-j 是并行作业数-max_scenarios 与 config 取其一即可 cerebrus \ -design top_core \ -flow flow_wrap.tcl \ -config config.tcl \ -j 32 \ -max_scenarios 24-design是这次 run 的标识日志目录、临时目录、HTML 报告都按它命名起名要能一眼看出是哪个模块哪一轮。-flow指向 3.1 里的包装脚本。-config指向 3.2 的配置。-j是同时跑多少个 scenario 的并行度这个数字直接决定你会不会把集群打爆——常见错误是按机器总核数填结果每个 scenario 自己还要多线程实际占用翻三倍。我的经验值是总可用核数除以单 scenario 峰值核数再留两成余量。启动后终端会打印 live UI 的访问地址。指南第 7 章把 Web UI 分成 live 模式和静态 HTML 模式live 模式连着正在跑的 run能看到 scenario 的实时状态、过滤基线值、cost 改善图还能对单个 scenario 做 kill、重跑、下压、解压这些交互操作静态模式是 run 结束后生成的报告适合发给不看命令行的人。第一次跑建议全程挂着 live 页面它对这次 run 是不是在正常工作的判断比翻日志快得多。3.4 日志、临时目录与 base scenario 健康判断run 启动后最该做的不是等结果是确认 base scenario 是否健康。指南第 4 章专门有一节讲怎么判断 base scenario 跑成功核心逻辑是base scenario 是零调整的基线它挂了后面所有对比都没意义。判断方式不复杂看三处——日志里有没有 setup 阶段的致命错误、distribution 日志里每个子作业的退出码是不是零、base scenario 的 cost 是否落在你手工跑一遍时的合理区间。日志的组织方式值得提前摸清因为出问题时你要在两分钟内定位到是哪一步挂的。cerebrus 主日志记录调度和决策每个 scenario 有自己的子日志distribution 日志记录作业派发和回收。指南里提到的 TMP 目录是临时工作区每个 scenario 在这个目录下有一份独立的中间产物磁盘水位要盯着——一轮几十个 scenario每个都留一份网表和报告几百 GB 很容易吃满吃满之后的表现是作业莫名其妙失败报错还跟你说是 license 问题。3.5 run 之间怎么接续restart、加 -j、model reuse第一次跑完通常会遇到三种情况指南第 4 章各给了一条路。第一种跑到一半想加并行度。正在跑的 run 不能直接改-j但可以重启并继承已完成的 scenario不必从头再来。第二种跑完想接着跑更多 scenario。这时候用模型复用把上一轮的模型作为输入喂给下一轮避免从零开始重新学。22.13 起支持把多个输入模型合并成一个统一输出模型22.14 把这个特性变成默认开启对多轮迭代的场景很实用。第三种想复现某个特别好的 scenario。用 scenario replay把那一组 primitive 取值单独重放一遍验证它是真的更优还是采样噪声——这个动作后面第 6 章会展开。有一点要提醒模型复用的前提是输入模型的维度对得上。如果你上一轮用的是 6 个 primitive这一轮加了 2 个新的直接复用会报维度不匹配正确做法是先只复用旧的那 6 个跑一轮让新 primitive 从 bootstrap 区间开始探索。4. 把 primitive 写对定义、注入与评估这一章是整份指南密度最高的部分也是最值得反复读的。primitive 写错的表现往往不是报错而是跑了很久但结果没变化排查成本极高。4.1 数据类型与属性先想清楚这个旋钮的形状定义 primitive 之前先回答四个问题它是连续的还是离散的、取值范围是多少、在哪个 phase 生效、什么条件下才启用。这四个问题对应指南里的类型、取值、作用阶段、过滤条件。类型适用场景取值写法常见误用整型线程数、迭代次数、切割份数上下界或离散列表范围给太宽采样大量落在无效区浮点目标裕量、derate 系数、RC 因子上下界加步长步长太小几十个 scenario 才覆盖一小段枚举effort 档位、策略选择有限字符串列表混入当前版本不支持的档位布尔开关类特性true / false与实际生效条件冲突开了也不起作用类型选错的代价是采样浪费。一个本该是枚举的 effort 档位你写成整型 0 到 10优化器会在 3、4、7 这些不存在的档位上反复试探每次都要跑完整个 phase 才知道无效。反过来一个本该连续调节的裕量你写成三档枚举搜索精度直接砍掉一个数量级。4.2 定义一个 primitive 的四个必填信息定义语句的形态在各版本略有差异但结构稳定名字、类型与取值、作用阶段、命令模板。下面是一个贴近实际用法的骨架# 定义一个作用于 postcts 阶段的连续型 primitive define_primitive \ -name cts_target_margin \ -type float \ -range {0.00 0.30} \ -applies_to postcts \ -command {set_db ccopt_target_margin $VALUE} \ -description CTS 阶段的目标裕量单位 ns-name是唯一标识后面 config 里引用、报告里显示都用它起名要能看出物理含义别用 p1、p2。-type配-range连续型或-values离散型两者不要同时给。-applies_to决定它在哪个 phase 被注入和评估这是最容易写错的一项见 5.1。-command里用$VALUE做占位符Cerebrus 在生成 scenario 时把它替换成具体取值如果你的命令需要拼接多个参数模板里的引号和转义要格外小心Tcl 的解析顺序会让一个多余的引号变成运行时错误而不是语法错误。命令模板写完后强烈建议先在交互式环境里手工替换一次取值跑一遍确认命令本身能执行、效果能被观测到再交给优化器。指南里提到用 eval_legacy 定义 primitive 的旧方式新写的一律走标准路径旧方式只在维护历史脚本时用。4.3 注入时机与 filter让旋钮只在该出现的时候出现注入不是把所有 primitive 一股脑塞进每个 scenario而是按作用阶段和过滤条件决定谁上场。指南里有一节专门讲在定义或注入时应用过滤用途是控制搜索空间的维度——每多一个 primitive组合空间翻好几倍无关的旋钮会稀释采样预算。常见做法是按 design 变体和 flow 变体做两级过滤只在特定模块上生效的 primitive 加模块过滤只在开启某条 flow 分支时才有效的 primitive 加条件过滤。这样同一份 primitive 定义可以在多个项目间复用不用为每个项目维护一份拷贝。另一个容易忽略的点是注入的层级。指南第 3 章讲在现有 flow 脚本里注入 Cerebrus 库时提到注入位置决定了 primitive 相对于用户自定义 flow step 的执行顺序。如果你的 primitive 必须在某个 setup 步骤之后才生效注入点就要放在那个步骤之后否则命令执行时依赖的对象还不存在。4.4 动态添加与延迟评估run 跑起来之后还能改22.13 引入了在 run 进行中动态添加 primitive 的能力这对长时间跑的场景很实用发现某个方向值得探索不用停掉整轮重启直接追加 primitive后续 scenario 会用上。用法上有约束——新加的 primitive 只影响尚未生成的 scenario已经跑完的不受追溯影响所以追加的时机越早越好。延迟评估delayed assessment解决的是另一类问题某些旋钮的效果要等好几个 phase 才稳定在注入点直接打分等于用噪声训练模型。延迟评估允许你把打分点挪到效果可见的阶段代价是这一轮反馈变慢需要更多的 scenario 才能收敛。典型的取舍是CTS 相关的旋钮如果直接影响时钟树结构延后到 postcts 阶段统一评估纯 setup 类的约束调整可以在本阶段就评估。4.5 校验注入有没有真的生效写完 primitive 别急着跑大轮先做一次单点验证。最省事的办法是用 scenario replay 只跑一个指定取值的 scenario然后翻两个地方一是该 scenario 的子日志搜索你命令模板里的关键字确认命令被执行且没有报错二是 HTML 报告的 QoR 页面确认 cost 分项确实发生了变化。两处都对上才说明这个 primitive 从定义到注入到评估整条链路是通的。这一步花十分钟能省掉后面几小时的无效 run。我见过太多次primitive 定义得很漂亮但作用阶段写错整轮跑完才发现 cost 曲线是平的那时候已经浪费掉的时间和机时都回不来了。5. 避坑五类把 run 跑废的操作这一章的每一条都是能让你损失半天到两天的坑。指南 FAQ 里有一部分剩下的是我在实际 run 里撞出来的。按现象 → 原因 → 解决写照着比对。5.1 坑一primitive 作用阶段写错cost 根本没算进去现象run 正常结束scenario 之间的 cost 差异极小几乎是一条直线但翻日志能看到 primitive 命令确实被执行了。原因primitive 的-applies_to指向了一个不参与成本核算的 flow phase。22.1x 默认只对 syn_opt、prects、postcts、postroute、signoff_opt 计算成本早期版本还会忽略 syn_generic、syn_map、floorplan、route 这几个阶段的成本。把旋钮挂在这些阶段上命令照样注入、网表照样变但优化器看不到收益于是判定这个方向没用后续采样就会避开它。解决先确认你手上的版本对哪些 phase 计算成本再把-applies_to改到效果真正被观测的那个阶段。注意 22.14 起 cts 和 postcts 合并到 postcts 评估、route 和 postroute 合并到 postroute 评估跨版本迁移时这张映射表要对一遍。改完用 4.5 的单点验证法确认 cost 分项真的有变化别只看日志里命令执行成功。5.2 坑二max_scenarios 拍脑袋设大机器被撑爆现象run 启动后大量作业卡在排队live 页面上一片 pending跑了几个小时完成的 scenario 数还是个位数。原因scenario 数量上限和并行度是两个独立参数一起放大会产生乘法效应。每个 scenario 自身还要多线程按机器总核数填-j会让实际占用远超物理核数调度器开始频繁换页单个 scenario 的耗时翻倍。指南在 22.13 说明里特别提到 max_scenarios 的默认值改成了按机器资源和时间可用性自适应就是在堵这个口子。解决先用小规模摸清单个 scenario 的峰值核数和平均墙钟时间再反推合理的-j和 scenario 上限。经验公式是可用核数 / 单 scenario 峰值核数 × 0.8scenario 上限按能在你愿意等待的时间窗口内跑完倒推。跑的过程中盯 live 页面的完成速率如果每个 scenario 的耗时随着并发上升而明显变长说明已经超过机器的舒适区降并发比加 scenario 划算。5.3 坑三cost 权重只写时序跑出一堆面积爆炸的解现象时序指标确实改善了但面积涨了三成以上后端评估时被直接打回。原因cost 权重表里只配了 timing 一项或者时序权重给到 0.8 以上其余分项可以忽略不计。优化器没有价值观你写什么它就优化什么没有面积约束它就朝面积无限膨胀的方向走——反正面积不进 cost。解决至少配三项时序、漏电功耗、面积权重按项目实际的约束优先级分配时序通常占 0.5 到 0.6剩下两项分配余量。指南第 6 章给了功耗分项的计算示例也支持把运行时加进 cost 函数、支持约束驱动的成本计算这些在项目早期就该配好。另外 22.14 起 hold 成本默认参与计算、WNS(100) 成为默认时序指标升级后要重新核对权重表和报告格式别沿用旧的心算。5.4 坑四distribution script 没验证作业排队排到天亮现象本地小规模跑得好好的一上集群就大面积失败报错信息五花八门有的说路径不存在有的说环境变量未定义。原因distribution script 负责把 scenario 派发到集群节点它继承的是提交节点的环境但执行节点上的工作目录、环境变量、库路径可能完全不同。指南第 4 章专门讲怎么验证 distribution script、怎么通过 distribution 日志定位失败点这段被跳过的后果就是本地能跑、集群不能跑。解决在正式跑大轮之前先用 distribution script 提交一个极小的测试作业确认三件事——工作目录在执行节点上可写、依赖的环境变量在执行节点上可见、作业结束后临时文件能被正确回收。出问题时直接看 distribution 日志它会记录每个子作业的提交命令和退出码比自己猜快得多。集群环境有变动换了队列、改了挂载点之后要重新验一遍。5.5 坑五拿旧模型直接复用输入维度对不上现象模型复用启动后立刻报错退出或者跑起来了但优化效果还不如不复用。原因两种情况。一是这一轮的 primitive 集合和上一轮不一致模型输入的特征维度对不上直接加载就崩。二是维度碰巧对上了但语义变了——某个 primitive 的取值区间被改过模型学到的高值更好在新区间里可能是反的。解决复用前先对齐 primitive 集合新增的 primitive 从 bootstrap 区间独立探索不要指望旧模型对它有先验。22.13 起支持把多个输入模型合并成统一输出模型22.14 起默认开启多轮迭代时按这个机制接续比手工拼模型可靠。如果升级过版本复用前还要确认 cost 函数的定义没变——权重或指标定义一变模型学到的映射就失效了。6. 复现一个好结果用 scenario replay 加自定义指标做验收前面几章讲的是怎么让 run 跑起来、跑对。真正决定这套流程能不能沉淀下来的是你能不能把一个看起来不错的结果复现并验证。我的做法固定成三步每轮 run 结束都走一遍。6.1 先重放再相信优化器给出的最优 scenario 有可能只是采样噪声尤其在 scenario 数量偏少、指标方差偏大的时候。指南第 4 章给的 scenario replay 就是干这个把那一组 primitive 取值单独拎出来重跑一遍看 cost 是否落在同一区间。重放支持几种包装方式用外层控制流包装的 flow 直接用对应的 replay RAK用 Stylus 流程包装的走另一套还能通过禁用指定 primitive 的方式做消融——把某个旋钮关掉再跑看它到底贡献了多少。消融这一步很多人省掉但它能告诉你这 8 个 primitive 里其实只有 2 个在起作用下一轮就可以把搜索空间砍掉四分之三。6.2 自定义指标进报告默认的 QoR 页面只显示内置指标项目里真正关心的往往是别的量比如某个特定路径组的 slack、某个模块的动态功耗。指南第 4 章讲怎么定义自定义指标并配置 HTML 的 YAML把自定义量挂进报告页面。我的习惯是每接一个新模块先花二十分钟把两三个项目特有指标接进去后面每一轮 run 的报告都能直接看出这些量有没有被牺牲掉不用再翻原始报告。验收项判断标准不通过时的动作最优 scenario 重放一致性cost 落在原值 ±5% 以内增加 scenario 数量重跑判定为噪声primitive 消融至少能定位出 2 个有效旋钮检查作用阶段和过滤条件自定义指标在 HTML 报告中正常显示且趋势合理检查 YAML 配置和指标名拼写权重表与项目当前阶段优先级一致调整权重后小规模重跑验证6.3 从那以后我每次都要走一遍有一轮我图快跳过重放直接把最优 scenario 的配置推给了下游结果下游复跑时时序差了 40ps回头一查是那一轮的 WNS 采样恰好落在一次库加载抖动上纯粹是噪声。从那以后我每次 run 结束都强制走一遍重放 消融 自定义指标核对哪怕只花二十分钟也比返工一天划算。这份 22.1x 指南里那些看起来啰嗦的验证章节恰恰是最该先读的部分。希望帮到你。本文还有配套的精品资源点击获取