简介Cadence Cerebrus User Guide 是面向电子设计自动化工程师与技术人员的官方操作参考文档聚焦 Cadence Cerebrus 工具在优化芯片设计流程中的指令、功能与典型使用案例。资源包内仅含 1 个 PDF 文件整体约 6.19MB对应产品版本 22.1x最后更新于 2023 年 12 月内容反映该软件较新的功能状态。文档由 Cadence Design Systems 出版涵盖工具操作说明、商标与版权声明、受限使用条件等模块并因采用 OCR 扫描生成个别字符可能存在识别偏差阅读时需结合上下文校正。目前已有 541 人学习下载适合希望系统掌握 Cerebrus 高级功能、提升设计效率与质量的工程师作为案头查阅资料也可帮助读者理解该工具在电子设计自动化流程中的定位与合规使用边界。1. 从一份 22.1x 手册说起Cerebrus 到底解决什么EDA场景数字后端工程师大概都有过这种体验综合、布局、CTS、布线跑完一轮PPA 不达标于是回头改约束、调参数、换策略再跑一轮。一轮下来少则几小时多则一两天而真正有效的探索可能只有两三次。Cadence Cerebrus 就是冲着这个痛点来的——它是一套基于强化学习的 RTL-to-GDS 流程自动化优化框架把「人工试参数」变成「机器按策略搜索」。这份 22.1x 用户指南2023 年 12 月更新覆盖了从环境搭建、primitive 定义、配置文件编写到 Web UI 监控、RAK 快速上手、FP-Opt / VT Optimizer 等专用 App 的完整链路。它面向的是熟悉综合、布局布线、STA 全流程且能写 Tcl/Tk 的资深设计者。如果你正在评估要不要把 Cerebrus 引入团队流程或者已经装了工具但卡在配置阶段这份手册就是那本「翻到某一页就能照着做」的参考书。2. Cerebrus 强化学习工作流从 flow phase 到 primitive 的映射逻辑2.1 为什么不是「脚本套壳」RL 工作流与手工流程的本质差异手工流程开发模型的核心是「人定策略、工具执行」工程师根据经验写一套 Tcl 脚本固定综合选项、固定 place 策略、固定 CTS 参数跑完看结果不行再改。这种模式的上限取决于工程师的经验覆盖范围而且每次调整都是全流程重跑时间成本极高。Cerebrus 的强化学习工作流把这件事拆成了三层最底层是flow phase也就是综合、prects、postcts、postroute、signoff_opt 这些阶段中间层是primitive即每个阶段里可调的那些「旋钮」——比如综合的 effort 等级、place 的 density 目标、CTS 的 useful skew 开关最上层是scenario一个 scenario 就是一组 primitive 取值的组合Cerebrus 通过 RL 算法决定下一轮探索哪些 scenario。关键差异在于手工流程一次只跑一个配置Cerebrus 一次跑一批 scenario并且根据上一批的 PPA 结果动态调整下一批的探索方向。手册里提到的「Cerebrus Layers」概念说的就是这种从底层 flow phase 到上层优化目标的抽象分层。理解了这个分层后面配 config 文件时才知道每一行在控制哪一层。2.2 22.14 版本的关键变更hold costing 默认开启与 flow phase 合并这份手册覆盖的是 22.1x 系列其中 22.14 有几个变更值得单独拎出来说因为它们直接影响 config 文件的写法。第一个是hold costing 默认开启。在 22.14 之前hold 的代价计算需要手动在 config 里打开22.14 之后默认就算 holdCost Weights 表的格式也跟着变了。如果你从旧版本迁移过来原来 config 里关于 hold 的开关可以删掉但要注意输出报告里多了一列 hold 相关的权重别以为是工具报错了。第二个是flow phase 合并。22.14 把 cts 和 postcts 的 primitive 统一放到 postcts 阶段评估route 和 postroute 的 primitive 统一放到 postroute 阶段评估。这意味着你原来写在 cts 阶段的 primitive现在实际生效的位置变了。手册里「Primitives table」那张表要仔细看否则会出现「明明设了参数但结果没变化」的玄学问题。第三个是WNS(100) 成为默认时序指标。原来用 WNS现在用 WNS(100)也就是第 100 条最差路径的 WNS。这个改动对优化方向有实际影响WNS 只盯最差的一条路径WNS(100) 会兼顾一批路径优化出来的结果通常更均衡但单点最差路径可能不如原来激进。2.3 配置文件的骨架path group、primitive 开关与 cost weight一份典型的 Cerebrus config 文件核心就三块path group 定义、primitive 启用/禁用、cost metric 权重。下面是一个最小可用的骨架我按手册里的字段名写参数值用占位符你替换成自己项目的实际值。# 设置 Cerebrus 的 path group用于时序代价计算 set_db cerebrus_path_groups {clk_main clk_aux data_path} # 启用或禁用 primitive这里只启用综合阶段的 effort 和 place 的 density set_db cerebrus_primitive_syn_effort true set_db cerebrus_primitive_place_density true set_db cerebrus_primitive_cts_useful_skew false # 设置 cost metric 权重时序为主面积和功耗为辅 set_db cerebrus_cost_weight_timing 1.0 set_db cerebrus_cost_weight_area 0.3 set_db cerebrus_cost_weight_power 0.2 # 设置 bootstrap 范围primitive 的初始探索区间 set_db cerebrus_bootstrap_syn_effort {medium high} set_db cerebrus_bootstrap_place_density {0.65 0.75 0.85}这段配置的逻辑是先告诉 Cerebrus 哪些 path group 参与时序计算然后明确哪些 primitive 允许被探索、哪些锁死。cerebrus_cost_weight_*控制优化目标的偏向时序权重给 1.0 意味着时序是硬指标面积和功耗作为次要项参与打分。cerebrus_bootstrap_*定义每个 primitive 的初始搜索空间Cerebrus 会在这个范围内选第一批 scenario。参数怎么改如果发现优化结果面积膨胀太厉害把cerebrus_cost_weight_area从 0.3 提到 0.5 以上如果时序始终压不下去检查cerebrus_path_groups是否漏了关键时钟域。手册里「Typical Configuration File Settings」那一节有更完整的字段列表建议对照着过一遍。3. 跑通第一次 Cerebrus Run命令、目录结构与 LSF 投递3.1 启动命令与 Live Web UI 的访问方式Cerebrus 的启动命令本身不复杂但前置条件容易漏。手册里「Prerequisites」一节明确要求UNIX 环境、Tcl/Tk 可用、底层实现工具Genus/Innovus 等已配置好 license 和路径。满足之后最基本的启动方式是# 在项目工作目录下启动 Cerebrus cerebrus -f config.tcl -j 8 -dir ./cerebrus_run # -f 指定配置文件 # -j 指定并行 job 数22.13 之后 max_scenarios 会根据机器资源自动调整 # -dir 指定运行目录所有中间文件和日志都放在这里启动后Cerebrus 会在-dir指定的目录下建立一套固定的目录结构。手册里「Cerebrus Directory Structure」列得很细实际用起来最常打交道的是这几个TMP目录放临时文件logs放每个 scenario 的日志reports放 QoR 报告html放 Web UI 的静态页面。Live Web UI 的访问方式是在浏览器里打开http://host:port端口号在启动日志里会打印出来。Live 模式下可以看到每个 scenario 的实时状态、cost 曲线、QoR summary。如果跑在 LSF 集群上注意 Web UI 的 host 要填提交节点的主机名而不是计算节点。3.2 LSF 投递与 distribution script 的写法Cerebrus 支持把 scenario 投递到 LSF 集群上跑这是实际项目里最常用的模式因为单机跑几十个 scenario 根本不现实。手册里「Launching Jobs onto LSF」和「Distribution Scripts」两节讲的就是这件事。核心是写一个 distribution script告诉 Cerebrus 怎么把 job 提交到 LSF。下面是一个简化版的模板#!/bin/bash # distribution script: 把单个 scenario 提交到 LSF # Cerebrus 会传入 scenario 相关的环境变量这里直接透传 bsub -q normal -n 4 -R rusage[mem8192] \ -o $CEREBRUS_SCENARIO_LOG \ -e $CEREBRUS_SCENARIO_ERR \ cd $CEREBRUS_SCENARIO_DIR source run_scenario.sh这个脚本的关键点bsub是 LSF 的提交命令-q指定队列-n指定核数-R指定资源需求。Cerebrus 在调用这个脚本时会通过环境变量传入 scenario 的目录、日志路径等信息脚本里直接用$CEREBRUS_SCENARIO_*引用即可。写完 distribution script 后手册建议先做一次「Verifying a Distribution Script」的验证手动跑一次脚本确认 job 能正常提交、日志能正常写、退出码是 0。这一步别省否则 Cerebrus 跑起来之后一堆 job 失败排查起来更费时间。3.3 判断 base scenario 是否成功看什么日志、查什么指标Cerebrus 跑起来之后第一件事是确认 base scenario 成功了。base scenario 是不做任何 primitive 探索的基准配置它的结果决定了后续所有 scenario 的比较基准。如果 base scenario 挂了后面全是白跑。判断方法在logs目录下找到 base scenario 对应的日志文件搜索Cerebrus Base Scenario Run相关的标记。手册里「Identifying a Successful Cerebrus Base Scenario Run」一节提到成功的 base scenario 会在日志里输出完整的 QoR 指标包括 timing、area、power 的汇总值。如果日志里只有工具启动信息没有 QoR 输出说明底层实现工具没跑完去查底层工具的日志。另一个快速判断方式是看reports目录下有没有生成 base scenario 的 QoR 报告文件。有报告文件且内容完整基本就是成功了没有报告文件或者文件是空的回去查底层工具的报错。4. Primitive 与 Scenario 配置数据类型、注入方式与动态添加4.1 primitive 的数据类型与属性哪些能调、哪些不能调Primitive 是 Cerebrus 优化的基本单元理解它的数据类型是配好 config 的前提。手册里「Primitive Data Types」和「Primitive Attributes」两节把 primitive 分成了几类布尔型开关类比如 useful skew 开或关、枚举型有限选项比如 effort 的 low/medium/high、数值型连续或离散数值比如 density 目标值。不是所有工具参数都能做成 primitive。一个参数要成为 primitive需要满足两个条件一是它对 PPA 有可观测的影响二是它的取值空间是有限的或者可枚举的。像「随机种子」这种参数就不适合做 primitive因为它的影响不可预测。在 config 文件里定义 primitive 时用set_db cerebrus_primitive_name的格式。手册里「Defining Primitives」一节给了完整的语法关键是要把 primitive 的名字和底层工具的实际参数对应起来。比如cerebrus_primitive_syn_effort对应的是 Genus 的syn_effort参数名字对不上工具就不认。4.2 动态添加 primitive在 run 中途调整探索空间22.13 引入了一个实用功能可以在 Cerebrus run 进行中动态添加 primitive。手册里「Adding Primitives Dynamically」和「Delayed Primitives」两节讲的就是这个。典型场景你启动 Cerebrus 时只启用了综合阶段的 primitive跑了几轮之后发现综合阶段的优化空间已经榨干了想加入 place 阶段的 primitive 继续探索。以前的做法是停掉当前 run改 config重新启动现在可以在 run 进行中通过命令动态添加。# 在 Cerebrus run 进行中动态添加 place 阶段的 primitive # 这条命令通过 Cerebrus 的交互接口发送 add_cerebrus_primitive -name place_density -type enum \ -values {0.65 0.75 0.85} -phase place # 添加 delayed primitive延迟到指定 flow phase 才评估 add_cerebrus_primitive -name cts_useful_skew -type bool \ -values {true false} -phase postcts -delayedadd_cerebrus_primitive的参数说明-name是 primitive 名称-type是数据类型-values是取值集合-phase指定在哪个 flow phase 生效-delayed表示延迟评估。延迟评估的意思是这个 primitive 虽然在 config 里定义了但 Cerebrus 不会立即把它加入探索空间而是等到指定的 flow phase 才纳入。这个功能的好处是避免「一次性开太多 primitive 导致搜索空间爆炸」。RL 算法在搜索空间太大的时候收敛会变慢分批加入 primitive 可以让算法先在小空间里找到方向再逐步扩大。4.3 scenario replay把优化结果重新套回流程验证Cerebrus 跑完之后最有价值的产出是「哪些 scenario 的 PPA 最好」。但 RL 算法找到的最优 scenario不一定在真实流程里也能复现同样的结果——因为 Cerebrus 内部的评估可能用了简化模型或者不同的 corner。手册里「Scenario Replay」一节就是解决这个问题的把 Cerebrus 找到的最优 scenario 重新套回完整的实现流程验证 PPA 是否真的达标。Replay 的方式有几种对应不同的 flow wrapping 模式。# 用 Outer Control Flow Wrapping 模式 replay 指定 scenario cerebrus -replay -scenario scenario_id -flow outer_control # 用 Stylus Common UI Flow Wrapping 模式 replay cerebrus -replay -scenario scenario_id -flow stylus_common # replay 时禁用某些 primitive用于对比分析 cerebrus -replay -scenario scenario_id -disable_primitive cts_useful_skewReplay 的关键参数是-scenario指定要 replay 的 scenario ID这个 ID 在 Cerebrus 的 QoR summary 里能看到。-flow指定 flow wrapping 模式要和当初跑 Cerebrus 时用的模式一致否则 primitive 的注入点会对不上。-disable_primitive用于对比分析把某个 primitive 禁掉再 replay看结果变化从而判断这个 primitive 对 PPA 的实际贡献。5. 避坑与排查Cerebrus 跑不起来时先查这几处5.1 坑一base scenario 日志正常但 QoR 为空现象Cerebrus 启动后base scenario 的日志文件有内容工具也正常退出了但reports目录下没有 QoR 报告或者报告文件是空的。原因最常见的原因是底层实现工具的 license 不够或者底层工具在跑的过程中报了 warning 但没报 errorCerebrus 以为跑完了实际上关键步骤被跳过了。另一个原因是 path group 定义有问题Cerebrus 找不到有效的时序路径导致 QoR 计算失败。解决先去看底层工具自己的日志通常在 scenario 目录下的genus.log或innovus.log搜索Error和Warning。如果 license 不够联系 IT 加 license如果 path group 有问题检查cerebrus_path_groups里的时钟名是否和设计里的实际时钟名一致。5.2 坑二primitive 设了但结果没变化现象在 config 里启用了某个 primitive也设了 bootstrap 范围但跑了几轮之后发现这个 primitive 的取值始终没变或者变了但 PPA 没反应。原因22.14 之后 flow phase 合并了原来在 cts 阶段生效的 primitive 现在实际在 postcts 阶段评估。如果你还在 cts 阶段找它的影响自然看不到变化。另一个原因是 primitive 的名字和底层工具参数名没对上Cerebrus 实际上没把这个 primitive 注入到工具里。解决先确认 primitive 对应的 flow phase 是否正确手册里「Primitives table」那张表要对照着看。然后检查 primitive 名称用report_cerebrus_primitives命令列出当前实际生效的 primitive 列表看你要的那个在不在里面。5.3 坑三LSF 投递后 job 一直排队现象Cerebrus 启动了distribution script 也写了但 job 提交到 LSF 后一直处于 PEND 状态不开始跑。原因LSF 队列的资源限制。Cerebrus 默认提交的 job 可能请求了较多的核数或内存而队列里没有足够的空闲资源。另一个原因是 distribution script 里的bsub参数写错了比如队列名不对、资源需求格式不对。解决先用bqueues和bhosts看队列和节点的资源情况。如果资源确实紧张调低 distribution script 里的-n和-R参数。如果队列名不对找 LSF 管理员确认可用的队列名。手册里「Tips for a Successful Cerebrus Run」一节也提到建议先用小规模 job 测试 distribution script确认能跑通再放大。5.4 坑四Web UI 打不开或显示不全现象Cerebrus 跑起来了日志里也打印了 Web UI 的地址但浏览器打开后页面空白或者部分图表加载不出来。原因Live Web UI 依赖 Cerebrus 进程的实时数据推送如果 Cerebrus 进程被挂起或者网络不通页面就会卡住。另一个原因是浏览器版本太旧不支持 Web UI 用的前端特性。解决先确认 Cerebrus 进程还在跑ps -ef | grep cerebrus。如果进程正常换一个现代浏览器Chrome 或 Firefox 的较新版本再试。如果还是不行看 Cerebrus 日志里有没有 Web UI 相关的报错。手册里「Cerebrus Live Web UI」一节提到Live 模式对网络稳定性有要求如果网络环境不稳定可以改用 Static HTML 模式等 run 结束后再看报告。5.5 坑五restart 后 scenario 状态丢失现象Cerebrus run 中途因为机器故障或手动 kill 中断了用-restart重启后发现之前跑过的 scenario 状态丢了Cerebrus 从头开始跑。原因Cerebrus 的 restart 依赖TMP目录下的状态文件。如果中断时状态文件没写完整或者TMP目录被清理了restart 就会失败。另一个原因是 restart 时用的 config 文件和原来的不一致Cerebrus 检测到配置变化选择重新开始。解决restart 前先确认TMP目录还在里面的状态文件没被删。restart 时用和原来完全相同的 config 文件和命令行参数。手册里「Restarting Cerebrus」一节提到如果只是想让 Cerebrus 继续跑但增加并行度可以用-j参数调整不需要改 config。6. 进阶技巧用 RAK 快速验证与 FP-Opt 的 one-pass/two-pass 选择RAKRapid Adoption Kit是这份手册里最容易被忽略但实际价值很高的部分。它本质上是一套预置的示例流程包含 config 文件、distribution script、测试数据拿来就能跑。手册第 8 章「Running the RAK」给了完整的步骤我一般建议新上手 Cerebrus 的人先跑一遍 RAK确认环境没问题再换成自己的设计。RAK 有两种输出模式命令行模式和浏览器模式。命令行模式下RAK 跑完会在终端打印 QoR summary浏览器模式下会生成一套静态 HTML 报告用浏览器打开就能看。两种模式的数据来源是一样的只是展示方式不同。FP-OptFloorplan Optimizer是 Cerebrus 的一个专用 App用于优化 floorplan 阶段的 macro 摆放和布局。手册第 9 章讲了 FP-Opt 的配置其中最关键的选择是 one-pass 还是 two-pass。模式适用场景优点缺点One Pass设计规模较小macro 数量少跑得快一轮出结果探索空间有限可能错过更优解Two Pass设计规模大macro 数量多探索更充分结果更优跑得慢需要更多计算资源One Pass 的逻辑是Cerebrus 直接在一个 pass 里探索 macro 摆放的 primitive跑完就出结果。Two Pass 的逻辑是第一个 pass 先做粗粒度的探索找到大致方向第二个 pass 在这个方向附近做细粒度探索。手册里「FP-OPT One Pass Flow」和「FP-OPT Two Pass Flow」两节分别给了配置示例。我的经验是如果 macro 数量在 20 个以内One Pass 够用超过 20 个直接上 Two Pass否则很容易陷入局部最优。Two Pass 的配置里要注意fp_opt_pass参数第一个 pass 设coarse第二个 pass 设fine中间的衔接由 Cerebrus 自动处理。VT Optimizer 是另一个常用 App用于多阈值电压单元的优化。手册第 9 章「VT Optimizer」一节讲了配置方法核心是设置 VT 类型的 primitive 和对应的 cost weight。VT 优化的目标通常是在满足时序的前提下尽量用高阈值单元降低 leakage power。配置时要注意cerebrus_cost_weight_power的权重如果 leakage 是主要矛盾把这个权重调高。Margins Optimizer 和 PPA primitive 的并发探索是 22.14 的新功能。以前这两个是分开跑的现在可以在一个 run 里同时探索。配置上的变化是在 config 里同时启用 margins 相关的 primitive 和 PPA 相关的 primitiveCerebrus 会自动协调两者的探索节奏。手册里「Exploring Margins Optimizer and PPA Primitives Concurrently」一节给了具体的配置示例。从那以后我每次配 Cerebrus 都强制走一遍 RAK 验证环境再上自己的设计。这个习惯帮我省了很多「以为是 config 写错了其实是环境没配好」的排查时间。希望帮到你。本文还有配套的精品资源点击获取
