简介Cadence Cerebrus User Guide 是面向电子设计自动化工程师与技术人员的官方操作指南聚焦 Cadence Cerebrus 工具在芯片设计流程优化中的实际应用。该指南对应产品版本 22.1x最后更新于 2023 年 12 月内容涵盖工具特定指令、核心功能说明与典型使用案例适合希望借助 Cerebrus 提升设计效率与质量的从业者参考。资源包为单一 PDF 文件压缩包大小约 6.19MB便于下载后离线查阅与检索。目前已有 539 人学习下载说明其在 EDA 学习群体中具有一定关注度。文档由 Cadence Design Systems 出版包含版权、商标及受限许可声明并涉及 Open SystemC Initiative 相关商标授权说明读者可借此了解工具使用边界与知识产权规范。由于内容由 OCR 扫描生成可能存在个别字词识别偏差阅读时需结合上下文理解与修正以保证操作指引的准确性。1. 数字后端 PPA 调优的“黑匣子”Cerebrus 用户指南到底能帮你解决什么如果你正在跑数字 IC 的后端实现流程大概率经历过这种场景Genus 综合完Innovus 跑完 place 和 route时序报告里 WNS 差那么几十皮秒功耗比预期高了 8%面积还有压缩空间。手动调参改一轮 primitives 跑一次 PR几个小时就没了跑完还不一定收敛。Cadence Cerebrus 就是冲着这个痛点来的——用强化学习的方式自动探索综合、布局、CTS、布线各阶段的参数组合把 PPA 往帕累托前沿上推。这份《Cerebrus User Guide》对应的是 22.1x 版本最后更新在 2023 年 12 月覆盖了从 flow wrapping、primitive 定义、cost function 配置到 Web UI 监控和 RAK 快速上手的完整链路。它适合已经熟悉完整实现流程、能写 Tcl、看得懂时序和功耗报告的工程师。如果你还在纠结怎么让 Innovus 跑通第一个 floorplan这份文档暂时帮不上忙但如果你已经在手动 tune 参数、想把这活儿交给机器那它就是你的操作手册。2. 理解 Cerebrus 的强化学习工作流从 flow wrapping 到 scenario 分支2.1 为什么不能直接拿手动 flow 喂给 Cerebrus手动 flow 开发模型有个根本问题每次调参都要重新跑一遍完整流程而且参数之间的相互影响靠人脑记不住。Cerebrus 的强化学习工作流把这件事拆成了三层最外层是 outer control flow负责定义整个探索的边界和场景分支中间层是 flow phases把综合、place、CTS、route 这些阶段切成可独立评估的单元最内层是 primitives也就是真正被调的那些参数——比如 clock uncertainty、cell derate、VT mix、floorplan 的 macro 位置。常见做法是先用 flow wrapping 把现有的 Genus/Innovus 脚本包一层让 Cerebrus 能在每个 flow phase 结束时抓取 metrics然后根据 cost function 决定下一轮探索方向。这里的关键是Cerebrus 不替你写 RTL 综合脚本也不替你修 timing violation它做的是在你给定的参数空间里找最优组合。所以 flow wrapping 的质量直接决定了探索结果的上限。2.2 Flow wrapping 的两种模式与注入方式文档里把 flow wrapping 分成了 outer control flow wrapping 和 stylus common UI flow wrapping。前者更灵活适合已经有成熟脚本体系的团队后者和 Cadence 的 Stylus 界面集成更紧适合已经在用这套 UI 的流程。Outer control flow wrapping 的核心是定义一个 control flow 脚本里面用create_flow_step把用户 flow 的每个步骤包起来然后在步骤之间注入 Cerebrus 的库和场景分支逻辑。一个典型的包装脚本长这样# 定义 flow step把用户原有的 Genus 脚本包进来 create_flow_step -name syn_generic -owner cadence { # 注入 Cerebrus 库让框架能抓取 metrics inject_cerebrus_libs # 执行用户原有的综合脚本 source ./user_scripts/syn_generic.tcl # 评估当前 step 的 primitives assess_primitives -phase syn_generic } create_flow_step -name place -owner cadence { inject_cerebrus_libs source ./user_scripts/place.tcl assess_primitives -phase place }这段代码的逻辑是每个 flow step 执行前先注入 Cerebrus 的监控库执行完用户脚本后立刻评估当前阶段的 primitives 表现。-phase参数指定了当前 step 对应的 flow phase 名称必须和后面 cost function 配置里的 phase 名一致否则 metrics 抓不到。inject_cerebrus_libs这个命令会把 Cerebrus 需要的 Tcl 过程和变量注入到当前解释器里不注入的话后面assess_primitives会报 command not found。场景分支scenario branching是在 outer control flow 里根据不同的 primitive 组合走不同的分支。比如你定义了clock_uncertainty和cell_derate两个 primitiveCerebrus 会在每一轮探索时给它们赋不同的值然后 control flow 根据这些值决定走哪条路径。文档里给的写法是用if判断 primitive 的当前值然后 source 不同的配置脚本。这里有个坑分支条件里不要写太复杂的逻辑Cerebrus 的 RL 引擎需要快速评估每个 scenario 的 cost分支太深会拖慢收敛速度。2.3 Primitives 的数据类型与评估时机Primitives 是 Cerebrus 调优的基本单元文档里列了几种数据类型整数、浮点数、布尔值、枚举、范围。定义的时候要指定类型和取值范围比如# 定义一个浮点型 primitive控制 clock uncertainty define_primitive -name clock_uncertainty -type float \ -range {0.0 0.15} -default 0.05 # 定义一个枚举型 primitive控制 VT mix define_primitive -name vt_mix -type enum \ -values {SVT LVT ULVT} -default SVT-range参数决定了 RL 引擎的搜索空间范围给太宽会导致探索效率低给太窄又可能错过最优解。我一般会先跑一轮 base scenario看看当前设计在这些参数上的实际值然后以 base 值为中心上下浮动 30% 作为初始范围。-default是 base scenario 用的值必须设成你当前手动 flow 里实际用的值否则 base scenario 的 metrics 没有参考意义。评估时机这块22.14 版本有个重要变化cts 和 postcts 的 primitives 现在统一在 postcts phase 评估route 和 postroute 的 primitives 在 postroute phase 评估。之前版本里这些是分开的升级后如果 cost function 里还按老 phase 名配会直接报 phase not found。另外 hold cost 现在默认开启cost weights 表的格式也变了老脚本迁移时要注意。3. 配置 Cerebrus 优化cost function、scenario progression 与约束处理3.1 配置文件的结构与必填项Cerebrus 的配置文件是一个 Tcl 脚本里面用set_db设置各种 root attribute。文档里给的典型配置包括 path groups、primitive 启用/禁用、bootstrap 值、cost metric weights、user defined primitives。其中 path groups 是必填的因为 timing costing 需要知道按哪些 path group 来算 WNS 和 TNS。# 设置 path groups必须和 SDC 里的 group 名一致 set_db cerebrus_path_groups {clk_reg2reg clk_in2reg clk_reg2out} # 启用或禁用特定 primitive set_db cerebrus_primitive_enable(clock_uncertainty) true set_db cerebrus_primitive_enable(vt_mix) true # 设置 cost metric weights set_db cerebrus_cost_weights(timing.setup.wns) 1.0 set_db cerebrus_cost_weights(power.leakage) 0.3 set_db cerebrus_cost_weights(area) 0.1cerebrus_path_groups里的名字必须和 SDC 里create_clock或group_path定义的名字完全一致大小写敏感。如果 SDC 里用的是默认 group这里可以写{reg2reg in2reg reg2out}。cost weights 的数值是相对权重不是绝对值Cerebrus 会把每个 metric 归一化后再加权求和。timing 的权重一般给最高power 和 area 按项目目标调整。如果某个 metric 你完全不关心权重设 0 就行但不要删掉这一行否则默认权重可能不是你想要的。3.2 Scenario progression 与 max_scenarios 的调整逻辑22.13 版本对max_scenarios的默认值做了调整不再依赖 primitive 的数量而是根据可用机器资源和时间自动计算。这个改动的好处是以前 primitive 多的时候 max_scenarios 会被设得很大跑一轮要等很久现在框架会根据你给的 CPU 核数和时间预算动态调整。如果你要手动控制可以在配置文件里显式设置# 手动设置最大 scenario 数 set_db cerebrus_max_scenarios 20 # 设置每个 scenario 的超时时间分钟 set_db cerebrus_scenario_timeout 120cerebrus_max_scenarios设太小会导致探索不充分设太大又可能跑不完。我一般会先看 base scenario 跑一轮要多久然后按总时间预算除以单轮时间再打个七折来设。cerebrus_scenario_timeout是单个 scenario 的硬超时超时后这个 scenario 会被 kill 掉cost 记为无穷大。这个值不要设得太紧否则一些本来能收敛的 scenario 会被误杀。3.3 约束驱动的 costing 与 WNS/Fmax 指标22.14 版本把timing.setup.wns.cerebrus这个 metric 从 WNS 改成了 WNS(100)也就是取最差的 100 条 path 的平均 WNS。这个改动是为了避免单条极端 path 主导 cost function导致优化方向跑偏。WNS(100) 在 HTML 的 QoR 页面里会单独显示配置的时候直接用timing.setup.wns.cerebrus这个 key 就行框架内部会自动用 WNS(100) 的值。Constraint based costing 是另一个实用功能你可以给特定的 path group 或 clock domain 设置额外的 cost 约束。比如某个 clock domain 必须满足 500MHz可以在配置文件里加# 给特定 clock domain 设置频率约束 set_db cerebrus_constraint(fmax) {clk_core 500.0}这样 Cerebrus 在探索时会优先满足这个约束如果某个 scenario 的 Fmax 低于 500MHzcost 会被显著抬高。这个功能在 multi-clock 设计里特别有用避免优化器为了整体 WNS 牺牲某个关键 clock domain。4. 避坑与排查Cerebrus 跑不起来时先看这几个地方4.1 Base scenario 跑失败日志里只报 “flow step failed”现象启动 Cerebrus 后 base scenario 直接挂掉log 文件里只有一行 “flow step failed”没有具体错误信息。原因最常见的是 flow wrapping 脚本里的路径不对或者inject_cerebrus_libs没有在用户脚本之前执行。另一个可能是用户脚本里用了exit命令把整个 Cerebrus 进程杀掉了。解决先检查 flow wrapping 脚本里 source 的用户脚本路径是不是绝对路径相对路径在 Cerebrus 的工作目录下可能找不到。然后在用户脚本开头加一行puts DEBUG: starting user script确认脚本确实被执行了。如果用户脚本里有exit改成return。最后看cerebrus.log和flow_step.log两个文件后者通常有更详细的报错。4.2 Primitives 定义了但探索时没生效现象配置文件里明明定义了clock_uncertainty和vt_mix但跑完一轮发现所有 scenario 的这两个参数值都一样。原因可能是 primitive 的-range或-values设成了单值RL 引擎没有探索空间。也可能是cerebrus_primitive_enable没有设成 true或者 primitive 定义在了错误的 phase 下。解决先检查-range是不是{0.05 0.05}这种单值范围改成有宽度的范围。然后确认cerebrus_primitive_enable(primitive_name)在配置文件里显式设成了 true。最后看 primitive 定义时的-phase参数如果有的话确保它和 flow wrapping 里assess_primitives -phase的名字一致。4.3 Cost 不降反升或者震荡不收敛现象跑了几轮之后 cost 比 base scenario 还高或者在不同 scenario 之间来回跳没有收敛趋势。原因cost weights 设置不合理比如 timing 权重太低导致优化器去追 power 了或者 primitive 的搜索范围太宽RL 引擎在无效区域浪费了大量探索。解决先把 cost weights 里 timing 的权重调到 1.0 以上power 和 area 降到 0.1 以下确认优化方向正确后再逐步调整。然后缩小 primitive 的-range以 base 值为中心上下浮动 20% 到 30%。如果还是震荡检查max_scenarios是不是设得太小RL 引擎还没学到有效策略就被迫停止了。4.4 HTML 报告里 metrics 显示为 N/A现象跑完一轮后打开 HTML 报告QoR 页面里 WNS、TNS、power 这些 metrics 全是 N/A。原因通常是assess_primitives没有在正确的 flow phase 执行或者 metrics 的名字和 cost function 里配的不一致。22.14 版本改了 phase 合并逻辑后老脚本里按cts和postcts分开评估的写法会失效。解决检查 flow wrapping 脚本里每个assess_primitives的-phase参数确保和配置文件里 cost function 的 phase 名一致。22.14 之后cts 和 postcts 统一用postctsroute 和 postroute 统一用postroute。然后确认cerebrus_path_groups里的 group 名和 SDC 一致否则 timing metrics 抓不到。4.5 重启后 model reuse 不生效现象第一次跑完 Cerebrus 后想用-in_models复用之前的模型但新 run 的探索结果和从头跑一样没有利用历史信息。原因22.14 版本把cerebrus_ml_generate_unified_model的默认值从 false 改成了 true但如果你用的是老配置文件这个 attribute 可能还是 false。另外-in_models指定的模型文件路径不对或者模型文件和当前设计的 flow phase 不匹配。解决在配置文件里显式加上set_db cerebrus_ml_generate_unified_model true确保每次 run 都会生成统一的输出模型。然后用-in_models指定之前生成的模型文件时确认文件路径是绝对路径并且模型文件里的 flow phase 定义和当前 run 一致。如果 flow phase 变了模型需要重新训练。5. 用 RAK 快速跑通第一条 Cerebrus 流程从命令行到浏览器RAKRapid Adoption Kit是文档里最实用的部分之一它给了一套完整的示例流程包括输入数据库、配置文件、flow wrapping 脚本跑完能直接看到 HTML 报告。我一般建议新上手的人先跑 RAK确认环境没问题后再换成自己的设计。5.1 RAK 的命令行执行与输出解读RAK 的入口脚本通常叫run_rak.tcl或类似名字执行方式是在 Cerebrus 的 shell 里 source 这个脚本# 启动 Cerebrus 并加载 RAK 配置 cerebrus -f ./rak/run_rak.tcl -j 8-j 8指定用 8 个 CPU 核并行跑 scenario这个值根据你的机器资源调整。跑完后会在当前目录下生成cerebrus_rak_output文件夹里面有 HTML 报告、log 文件、每个 scenario 的配置和结果。命令行输出里会实时打印每个 scenario 的 cost 和状态看到Scenario completed successfully就说明这一轮没问题。RAK 的 HTML 报告里重点看三个页面QoR Summary 看最终 metrics 对比Cost Improvement Graph 看收敛曲线Scenario Status 看每个 scenario 的详细配置。如果 Cost Improvement Graph 是一条平线说明 primitive 的搜索空间没设对或者 cost weights 有问题。5.2 Scenario replay 的两种方式与适用场景Scenario replay 是 Cerebrus 的一个实用功能跑完一轮后你可以把某个 scenario 的配置单独拿出来重跑验证结果是否可复现。文档里给了两种方式outer control flow wrapping 和 stylus common UI flow wrapping。Outer control flow 的 replay 方式是在 flow wrapping 脚本里加一个replay_scenario命令指定要 replay 的 scenario ID# Replay 指定 scenario replay_scenario -id 5 -output_dir ./replay_scenario_5-id是 scenario 在 HTML 报告里的编号-output_dir是 replay 结果的输出目录。Replay 的时候 Cerebrus 会用和原始 run 完全相同的 primitive 值重新跑一遍 flow用来确认结果不是随机波动导致的。Stylus common UI 的 replay 方式更简单直接在 UI 里选 scenario 然后点 Replay 按钮就行。但这种方式依赖 Stylus 环境如果你们团队没用这套 UI还是用 outer control flow 的方式更通用。5.3 从 RAK 迁移到自己设计的检查清单RAK 跑通后换成自己的设计需要改几个地方输入数据库路径、SDC 文件路径、flow wrapping 脚本里的用户脚本路径、path groups 定义、primitive 的搜索范围。我一般会按这个顺序改先把输入数据库和 SDC 换成自己的跑一轮 base scenario 确认 flow 能通然后改 path groups 和 cost weights再跑一轮看 metrics 能不能抓到最后加 primitive 定义和搜索范围开始正式探索。这里有个血泪经验改 path groups 的时候一定要和 SDC 里的 group 名逐字核对大小写和空格都不能差。我有一次因为 SDC 里写的是clk_core配置文件里写成了clk_Core跑了一整夜发现 timing metrics 全是 N/A白白浪费了机器时间。从那以后我每次改完 path groups 都会先用report_clocks和report_path_groups确认一遍名字再启动 Cerebrus。希望帮到你。本文还有配套的精品资源点击获取