简介Cadence Cerebrus User Guide 是面向电子设计自动化工程师与技术人员的官方操作参考文档聚焦 Cadence Cerebrus 工具在优化芯片设计流程中的实际应用。该指南对应产品版本 22.1x最后更新于 2023 年 12 月内容涵盖工具特定指令、核心功能说明与典型使用案例适合已具备一定 EDA 基础、希望借助自动化手段提升设计效率与质量的从业者查阅。资源包为单一 PDF 文件压缩后约 6.19MB结构完整、便于检索可离线阅读与标注。目前已有 541 人学习下载说明其在相关工程社群中具备一定参考热度。通过这份指南读者能够系统了解 Cerebrus 的功能定位与操作要点掌握其在设计优化流程中的使用方式同时明确文档使用中的版权与商标约束为合规、高效地开展电子设计工作提供依据。1. 从一份 22.1x 手册说起Cerebrus 到底替谁省下了那几周如果你正在跑数字后端全流程手头有一版 22.1x 的 Cerebrus 用户指南却一直没敢真正把它接进项目这篇就是写给你的。Cerebrus 是 Cadence 的机器学习驱动 PPA 优化框架核心思路是把综合、布局、CTS、布线、签核这一长串流程里的关键变量——路径组权重、VT 组合、时钟不确定性、derate 系数——交给强化学习去探索而不是靠人一遍遍改脚本、跑通宵、看报告。它面向的是熟悉完整实现流程、能写 Tcl、看得懂时序报告的工程师。手册本身是官方文档但真正落地时卡住人的往往不是概念而是 flow wrapping 怎么写、primitive 怎么注入、scenario 怎么复用、成本函数怎么配。下面按我实际拆文档和跑流程的顺序把这份指南里最值得先吃透的部分捋一遍。2. 理解 Cerebrus 的优化骨架从 manual flow 到 RL workflow2.1 为什么手动调参一定会撞墙手册第 2 章开头就把 manual flow development 和 Cerebrus-based flow development 摆在一起对比这不是凑篇幅。手动流程的典型做法是工程师凭经验挑几个变量比如把某条关键路径的 group weight 调高、换一组 VT、加一点 clock uncertainty然后跑一轮实现看 WNS 和 power 有没有改善。一轮下来几小时到十几小时能覆盖的组合非常有限。更麻烦的是变量之间有耦合——你把 setup 修好了hold 可能崩leakage 降了dynamic power 可能涨。手册里明确写了 manual flow 的局限探索空间小、迭代慢、难以系统性地覆盖多阶段组合。Cerebrus 的 RL workflow 本质上是把这个“猜-跑-看”的循环自动化。它把流程拆成 flow phases 和 scenarios每个 scenario 是一组 primitive 取值的组合RL 引擎根据上一轮各 scenario 的 cost 反馈决定下一轮往哪个方向探索。你不需要预先知道哪个组合最好只需要定义好探索范围和成本函数。2.2 Flow phases、scenarios 与 primitives 三层结构手册第 2 章把 Cerebrus 的 building blocks 分成三层这个分层是后面所有配置的基础Flow phases对应实现流程的阶段比如 syn_opt、prects、postcts、postroute、signoff_opt。22.14 里默认计算 cost 的就是这几个阶段syn_generic、syn_map、floorplan、route 默认被忽略。这个变化很关键——如果你还在用旧版本的 phase 定义去套cost 报告会对不上。Scenarios每个 scenario 是 flow phase 内一组 primitive 的具体取值。Cerebrus 会跑多个 scenario比较它们的 cost。Primitives可调参数的最小单元比如某个 path group 的 weight、VT 类型、clock uncertainty 值。Primitive 有数据类型、属性、定义方式手册第 5 章专门讲这个。理解这三层之后再看配置文件里的set_db cerebrus_path_groups、create_flow_step这些命令就不会觉得是在背咒语了。2.3 一个最小可跑的 flow wrapping 骨架手册第 3 章讲 flow wrapping这是把 Cerebrus 接进你现有流程的第一步。常见做法是写一个 outer control flow把用户原有的实现脚本包进去然后在关键节点注入 Cerebrus 的库和 scenario 分支。下面是一个简化的 Tcl 骨架展示结构不是完整可执行脚本# 定义 Cerebrus 的 flow step名字对应你的实现阶段 create_flow_step -name syn_opt -owner cerebrus { # 注入 Cerebrus 库让 primitive 在流程中生效 inject_cerebrus_libraries # 根据当前 scenario 的 primitive 取值设置对应变量 # 例如 path group weight、VT 类型等 apply_scenario_primitives # 调用用户原有的综合脚本 source ./user_scripts/syn_opt.tcl } # 定义 outer control flow把各阶段串起来 create_flow -name cerebrus_flow { flow_step syn_opt flow_step prects flow_step postcts flow_step postroute flow_step signoff_opt }这段骨架里create_flow_step的-owner cerebrus表示这个阶段由 Cerebrus 控制inject_cerebrus_libraries负责把 Cerebrus 的运行时库加载进来apply_scenario_primitives是根据当前 scenario 把 primitive 值写到流程变量里。实际项目中用户脚本里的变量名和 primitive 的映射关系需要自己维护手册里给了 scenario branching 的写法核心就是在 flow step 内部用条件判断区分不同 scenario。提示flow wrapping 最容易翻车的地方是变量作用域。Cerebrus 注入的库和用户脚本如果在不同的 namespace 里primitive 值可能读不到。建议在 flow step 开头显式声明全局变量或者用set_db把值写到 Cerebrus 能读到的属性上。3. 配置优化成本函数、primitive 与 scenario 推进3.1 成本函数不是越复杂越好手册第 6 章讲 configuring Cerebrus optimization其中 cost metric weights 是核心。Cerebrus 默认会算 timing、power、area 等指标但每个指标在总 cost 里的权重需要你根据项目目标来定。比如一个功耗敏感的设计可以把 power.leakage 的权重调高一个频率优先的设计WNS 的权重就要压过其他。22.14 里 hold cost 变成了默认开启这意味着如果你不显式关掉Cerebrus 会把 hold 违例也算进 cost。这对一些 hold 本来就紧的设计是好事但如果你的流程里 hold 修复是后面单独做的hold cost 可能会干扰 setup 优化方向。手册里给了Enabling hold costing的开关建议先确认你的流程阶段划分再决定是否保留默认。WNS(100) 成为默认 metric 也值得注意。WNS(100) 取的是最差 100 条路径的 WNS比单条最差路径更能反映整体时序健康度。如果你的项目习惯看单点 WNS需要知道这个变化否则会疑惑为什么报告里的数和以前对不上。3.2 Primitive 定义与注入的实操细节手册第 5 章把 primitive 的操作讲得很细这里挑几个落地时最常用的点。定义 primitive 时数据类型决定了它在 scenario 里怎么取值。比如# 定义一个浮点型 primitive表示某 path group 的 weight define_primitive -name pg_weight_core -type float \ -min 0.5 -max 2.0 -default 1.0 # 定义一个枚举型 primitive表示 VT 类型 define_primitive -name vt_type -type enum \ -values {SVT LVT ULVT} -default SVT-min和-max限定探索范围-default是 base scenario 的取值。枚举型用-values列出可选值。定义好之后在 flow step 里通过apply_scenario_primitives把当前 scenario 的值写进去。注入 primitive 时手册提到eval_legacy和 filters。eval_legacy用于兼容旧版写法如果你是从老版本迁移可能会用到。Filters 则是在定义或注入时对 primitive 做筛选比如只对特定 path group 生效。常见做法是# 只对 core 相关的 path group 注入 weight primitive apply_primitive -name pg_weight_core \ -filter {path_group ~ *core*}这个 filter 语法需要参考手册里的具体规则不同版本的匹配方式可能有差异。3.3 Scenario 推进与 early exit 的配置手册第 6 章的高级配置里max_scenarios在 22.13 之后改为根据机器资源和时间自动调整不再单纯依赖 primitive 数量。这个改动的好处是你不用手动算能跑多少个 scenario但坏处是如果机器资源紧张探索空间可能被压缩。建议在 config 里显式设一个上限避免跑太久。Early exit 是另一个实用功能。22.14 支持基于 base scenario metric 值的百分比变化来提前终止。比如你设-early_exit_threshold 5当某个 scenario 的 cost 比 base 差 5% 以上时Cerebrus 可能直接放弃它把资源留给更有希望的 scenario。配置方式大致如下set_db cerebrus_early_exit_enable true set_db cerebrus_early_exit_threshold 5具体参数名以你手头版本的手册为准这里展示的是配置思路。Early exit 用得好能省大量机时用不好会误杀一些前期表现差但后期有潜力的 scenario。建议先在小规模设计上试观察被终止的 scenario 里有没有后来居上的。注意early exit 的阈值不要设得太激进。我见过有人设 2%结果大部分 scenario 在前几轮就被砍掉最后收敛到一个局部最优。稳妥的做法是从 10% 开始逐步收紧。4. 跑起来之后日志、目录结构与常见翻车点4.1 目录结构和日志该看什么手册第 4 章讲了 Cerebrus 的目录结构其中 TMP 目录和 log 文件是排查问题的第一入口。一次 run 的目录大致包含目录/文件用途run/主运行目录存放 config 和 flow 脚本run/TMP/临时文件scenario 的中间结果run/logs/各阶段日志按 flow phase 和 scenario 分run/reports/QoR 报告和 cost 汇总run/html/静态 HTML 报告可在浏览器打开排查时先看logs/下对应 flow phase 的日志确认流程有没有跑完。如果某个 scenario 卡住去TMP/下找它的临时目录看最后一条命令是什么。Distribution logs 在跑 LSF 时特别有用手册里专门有一节讲如何用 distribution log 定位失败点。4.2 避坑五个真实踩过的坑现象一base scenario 跑成功但后续 scenario 全部失败。原因base scenario 用的是默认 primitive 值后续 scenario 改了某个 primitive 后用户脚本里的变量没更新导致流程读到旧值或空值。 解决在 flow step 里加断言检查关键变量是否被正确赋值。手册里Verifying a Distribution Script一节给了检查思路可以借鉴。现象二cost 报告里 hold 违例数异常高但 setup 明明修好了。原因22.14 默认开启 hold costing而你的流程里 hold 修复在 postroute 之后单独做Cerebrus 在中间阶段就把 hold 算进 cost导致优化方向被带偏。 解决如果 hold 不是当前阶段的目标在 config 里显式关掉 hold costing或者调整 flow phase 的定义把 hold 评估放到后面的阶段。现象三model reuse 时多个 input model 合并后结果反而变差。原因22.13 引入的 unified output model 功能在 22.14 变成默认开启但如果你之前的 model 是在旧版本下训练的合并后可能引入噪声。 解决先确认cerebrus_ml_generate_unified_model的值必要时手动设为 false用单个 model 跑一轮对比。手册里Combining Multiple Input Models into a Unified Output Model一节有详细说明。现象四restart 后 scenario 编号错乱之前的结果对不上。原因restart 时没有正确保留 scenario 的映射关系或者-j参数改了之后并行度变化导致 scenario 分配错位。 解决restart 前先备份run/下的 config 和 scenario 记录。手册里Restarting Cerebrus和Increasing -j of an ongoing Cerebrus run两节讲了正确做法核心是保持 scenario 定义不变只调整并行度。现象五HTML 报告里看不到自定义 metric。原因自定义 metric 需要在 HTML YAML 里注册否则即使 cost 函数里加了报告也不显示。 解决参考手册Defining Custom Metrics和Configuring HTML YAML两节在 YAML 里加上 metric 的名称、单位和显示格式。5. 进阶用 RAK 和 Apps 把优化推到具体场景5.1 RAK 不是 demo是能改的起点手册第 8 章讲 Cerebrus RAKRapid Adoption Kit很多人把它当示例一扫而过其实 RAK 里的 flow 脚本和 config 是很好的起点。RAK 输出分命令行和浏览器两种命令行输出适合快速验证浏览器输出适合看 QoR 汇总。Scenario Replay RAK 和 Floorplan Optimizer RAK 是两个独立入口前者用于复现已有 scenario后者用于布局优化。我一般会先把 RAK 跑通确认环境没问题再把自己的设计替换进去。替换时注意 RAK 里的 path group 定义和你的设计是否匹配不匹配的话 primitive 注入会失效。5.2 FP-Opt 和 Margins Optimizer 的配置要点第 9 章讲了几个 Apps其中 Floorplan OptimizerFP-Opt和 Margins Optimizer 最常用。FP-Opt 有 one pass 和 two pass 两种流程one pass 适合快速探索two pass 适合精细优化。配置时 macro place config 是关键手册里给了Setting the Macro Place Config的写法。Margins Optimizer 在 22.14 里可以和 PPA primitives 同时探索这是一个实用增强。配置时注意 cell derate 和 SOCV RC variation factor 的开关这两个参数直接影响时序裕量的计算。Clock uncertainty tuning 也是 Margins Optimizer 的一部分手册里给了 UI config file 的示例。# Margins Optimizer 配置片段 set_db cerebrus_margins_optimizer_enable true set_db cerebrus_cell_derate_enable true set_db cerebrus_socv_rc_variation_factor 1.05 set_db cerebrus_clock_uncertainty_tuning true这些参数的具体取值需要根据工艺和设计特点调整手册里的示例值只能作为起点。5.3 验证优化结果的一个习惯跑完 Cerebrus 之后不要只看它报告的 cost 改善。我习惯做两件事一是把最优 scenario 的 primitive 值导出来手动跑一轮完整流程确认结果可复现二是对比 base scenario 和最优 scenario 的 QoR 报告看改善来自哪个指标有没有以牺牲其他指标为代价。手册第 10 章的 FAQ 里有一些 debug tips但真正的验证还是得靠自己的流程。从那以后我每次跑完 Cerebrus都会强制走一遍手动复现确认最优 scenario 不是过拟合到某个中间阶段的假象。希望帮到你。本文还有配套的精品资源点击获取