让 RTL 优化跑进真实 EDA 流程：Dr. RTL 如何用智能体改写芯片设计

芯片设计里的很多性能问题，并不是到了后端才突然出现。它们常常早早埋在 RTL 代码里：一段控制逻辑太深、一个选择器链太长、某个信号扇出太大，都会在综合后变成难缠的时序路径。过去，这类问题主要靠工程师盯着报告、改代码、再跑工具，一轮一轮试出来。Dr. RTL 这篇论文讨论的，正是一个更接近工业现场的问题：能不能让大语言模型智能体进入真实 EDA 流程，自己分析报告、改写 RTL、验证结果，并把经验沉淀下来？

图 1 Dr. RTL 的整体思路：让智能体在 EDA 反馈中循环优化 RTL，并沉淀可复用技能

为什么 RTL 优化值得单独拿出来谈

RTL，也就是寄存器传输级描述，是芯片从架构想法走向门级电路的重要中间层。工程师在这里决定数据通路怎么组织、寄存器放在哪里、控制信号如何驱动计算单元。后续逻辑综合当然很强，可以做布尔重写、技术映射和局部优化，但它仍然受限于原始 RTL 的结构。换句话说，如果代码本身把计算路径写得很长，或者把控制和数据紧紧缠在一起，综合工具未必能从根上改变这种结构。

论文关注的 PPA，指的是性能、功耗和面积。本文实验主要优化时序，同时把面积作为约束和权衡指标；功耗没有纳入当前目标，因为论文指出，准确功耗估计依赖具体工作负载，静态评估难以可靠覆盖。时序里又有两个常见指标：WNS 表示最差负裕量，TNS 表示所有违例路径的总负裕量。它们越接近 0，通常说明设计离满足时钟约束越近。

这也是 Dr. RTL 选题的现实意义：它不是让模型从自然语言直接写一个小 Verilog 模块，而是让模型面对已经由人写好的 RTL，在商业综合和形式验证的反馈下继续挖优化空间。这更像工程团队每天会遇到的工作，而不是一个被简化过的代码生成题。

现有 LLM 优化方法离真实场景差在哪里

论文首先指出，已有 LLM-based RTL 优化工作存在两个层面的距离。第一是评测不够真实：不少方法从人工“降级”的 RTL 出发，比如人为注入冗余或退化写法，然后让模型把它修回来。这类任务更像 PPA 修复，而不是对高质量人类 RTL 的继续优化。第二是工具链偏弱：一些工作依赖开源综合工具或仿真验证，可能让简单改写看起来有效，但这些收益未必能通过更强的商业综合工具保留下来。

Dr. RTL 的评测设置明显更严格。论文使用 20 个来自开源项目、可综合的人类手写 Verilog 设计，覆盖 buffer、处理器、信号处理模块、密码设计和 SoC 等类型。数据集平均 812 行代码，最小 128 行、最大 4615 行，平均每个设计 3 个模块；相比论文对比的已有数据集，规模约大一个数量级。

工具链上，实验采用 Synopsys Design Compiler、Nangate 45 nm 工艺库，并用 Cadence Jasper 的顺序等价检查（SEC）验证功能一致性。这里的 SEC 很关键：组合等价检查只能覆盖组合逻辑等价，而 RTL 优化常常会涉及保持延迟不变的寄存器重分布、复制或类似 retiming 的重构，必须用能覆盖时序状态变化的验证方式。

图 2 论文构建的真实 RTL 优化评测环境与 Dr. RTL 框架总览

Dr. RTL 做了什么：把 RTL 优化变成闭环搜索

从系统角度看，Dr. RTL 把 RTL 优化定义成一个“工具接地”的闭环搜索问题。给定初始设计，智能体不是一次性输出最终答案，而是在每一轮读取综合后的时序报告，定位关键路径，再生成多个候选 RTL，交给 EDA 工具综合和 SEC 验证。只有通过验证、并在 PPA 评分上更好的候选，才会被提升为下一轮的起点。

论文中每个设计运行 10 轮优化，每轮并行生成 5 个候选，也就是每个设计最多有 50 次优化尝试。选择候选时，系统综合考虑 WNS、TNS 和面积，并对明显面积开销设置惩罚。这样的设计让模型不只是“敢改”，还要在工具反馈里学会“改得值不值”。

三个智能体各司其职

Dr. RTL 的多智能体框架由一个 orchestrator 统筹，下面分成三个专门角色。时序分析智能体负责读报告，把最关键的路径映射回 RTL 结构，并判断延迟根因，比如组合深度过大、高扇出、控制数据耦合或重汇聚逻辑。RTL 优化智能体负责生成候选改写，既可以调用已有技能，也可以基于当前瓶颈提出新策略。评估智能体则只负责执行综合和 SEC，并返回 WNS、TNS、面积和验证结果。

这种分工看似工程化，却很重要。论文的消融实验显示，如果拿掉多智能体设计、改成单智能体，WNS/TNS 改善会从 21%/17% 降到 10%/7%。这说明 RTL 优化不是单纯“让模型多想一想”就够了，任务拆分、反馈边界和工具调用方式会直接影响结果。

图 3 多智能体闭环：时序分析、RTL 改写与 EDA 验证分工协作

更有意思的是：它会把经验变成技能库

Dr. RTL 的第二个核心设计，是 group-relative skill learning，直译为“组内相对技能学习”。它解决的是一个很实际的问题：EDA 结果很噪声，设计之间也不可直接比较。一个改写在 A 设计上提升 5%，不代表它比另一个在 B 设计上提升 3% 的策略更好，因为初始结构、约束和综合难度都不同。

论文的做法是只在同一轮、同一个父 RTL、同一份时序反馈下比较并行候选。也就是说，5 个候选站在同一条起跑线上，谁通过 SEC、谁让 WNS/TNS 更接近 0、谁面积代价更低，就更有资格被认为用了有效策略。系统再把这些优化轨迹整理成“模式-策略”条目，例如遇到重复比较或复杂条件，可以抽取条件预计算；遇到高扇出组合信号，可以为不同逻辑锥复制信号；遇到重复算术或逻辑表达式，可以提取公共子表达式。

图 4 组内相对技能学习：比较同一轮候选设计，从成功轨迹中抽取策略

截至论文当前实现，Dr. RTL 从轨迹中沉淀出 47 条模式-策略条目，其中包括 12 条高置信策略、16 条中置信策略、6 条低置信或风险策略，以及 13 条“避免使用”的策略。后者同样有价值：有些改写已经会被综合工具吸收，有些会破坏等价性，有些看似减少逻辑层级却会恶化时序。把这些失败经验显式记录下来，等于让智能体少走重复弯路。

图 5 从优化轨迹到技能库：论文给出的可解释策略与避坑经验示例

把论文的创新点拆开看

创新点一：先把问题放回真实流程里

很多自动化方法看起来效果很好，但前提是题目本身被简化了。Dr. RTL 的第一层贡献，是把评测对象换成原始人类手写 RTL，并把后端工具换成商业综合和顺序等价检查。这样做会让任务明显变难，因为模型面对的不是“把坏代码修回正常”，而是要在已经可综合、已经由强综合工具优化过的设计上继续找结构机会。论文也专门提出，真实 RTL 优化应该看能否超过人类手写 RTL 经商业综合后的结果，而不应只看能否恢复被人工降级的版本。

创新点二：用细粒度 EDA 反馈约束模型

第二层贡献，是让模型不只看到一个最终 PPA 数字，而是能利用关键路径、起点终点寄存器、路径到 RTL 的映射和 slack 信息。对工程师来说，这相当于从“这个模块慢了”变成“这条控制数据 mux 链导致了负裕量”。粒度越细，模型越可能提出有针对性的改写，而不是泛泛地套用代码重排模板。消融实验中，去掉寄存器级 slack 反馈带来的性能下降最大，也从侧面说明了这一点。

创新点三：把一次次试错沉淀为可解释知识

第三层贡献，是技能库。它不像普通 prompt 示例那样只是堆几段代码，而是把“什么结构模式下，什么策略可能有效，什么策略应该避免”组织成可以复用的条目。更重要的是，这些技能来自同一轮候选之间的相对比较，而不是凭绝对 PPA 值下结论。对芯片设计这种高度依赖上下文的任务来说，这种相对评价更接近工程判断：同一约束、同一报告、同一父设计下表现更好的候选，才更能说明策略本身有效。

实验结果：不是修坏代码，而是继续优化好代码

论文最关键的结果来自 20 个真实 RTL 设计。在商业综合作为基线的情况下，Dr. RTL 在全部 20 个设计上都带来了时序改善，平均 WNS 改善 21.3%，平均 TNS 改善 16.9%，同时面积平均减少 5.8%，平均 SEC 通过率为 86%。这组结果说明，收益并不是单纯用面积换时序；论文还报告有 9/20 个设计实现了 Pareto 改善，8/20 个设计只有小于 5% 的轻微面积开销，只有 3/20 个设计出现较明显面积增加。

具体到单个设计，cpu_pipe 的 WNS 改善 71.1%、TNS 改善 88.4%、面积减少 11.8%；pcie 的 WNS 改善 44.3%、TNS 改善 17.1%、面积减少 33.9%；ticket 的 WNS/TNS 分别改善 60.9%/62.1%，面积减少 41.8%。当然也有更难优化的设计，例如 dsp、datapth、arm_cpu1 的改善幅度较小，这也让结果看起来更可信：真实 RTL 优化并不是每个模块都能被轻松“榨出”巨大收益。

读这张结果表时，还需要注意一个细节：WNS 和 TNS 原本是负值，所谓改善通常意味着负裕量绝对值变小、更接近 0。例如 cpu_pipe 的 WNS 从 -0.38 ns 变为 -0.11 ns，TNS 从 -23.24 ns 变为 -2.69 ns；这不是简单的百分比游戏，而是违例路径整体压力明显减轻。面积列同样重要，因为如果所有时序收益都来自大幅堆硬件，工程价值会打折。Dr. RTL 的平均面积反而下降，是论文最值得关注的结果之一。

图 6 Dr. RTL 在 20 个真实 RTL 设计上的 PPA 优化结果

和基线方法相比，优势来自框架而不只是模型

论文把 Dr. RTL 与单次调用 LLM、以及 RTLRewriter、SymRTLo 等已有 RTL 优化方法比较，并在迭代基线中使用同一个 Claude Opus 作为骨干模型，以减少“只是模型更强”的干扰。结果显示，单次 Claude Opus 的 WNS/TNS/面积改善分别为 2.4%/2.8%/0.7%，RTLRewriter 为 4.9%/6.3%/3.1%，SymRTLo 为 7.1%/5.7%/1.4%，而 Dr. RTL 达到 21.3%/16.9%/5.8%。这意味着论文真正强调的是闭环工具反馈、多候选搜索和技能沉淀的组合。

消融实验进一步支持这一点。去掉寄存器级 slack 反馈后，WNS/TNS 改善降到 9%/9%，说明细粒度时序信息对定位根因很关键；去掉学习到的技能库后，WNS/TNS 改善降到 14%/11%，SEC 通过率也从 86% 降到 78%。也就是说，技能库不只是让结果更好，还提高了候选改写的可靠性。

模型越强越好，但系统设计同样重要

论文还比较了不同 LLM 骨干。随着模型能力增强，优化质量和可靠性都上升：Qwen Coder 8B 的平均 WNS/TNS 改善为 1%/0%，SEC 通过率 22%；Claude Haiku 为 3%/2%、57%；Claude Sonnet 为 12%/9%、73%；Claude Opus 为 21%/17%、86%。这说明 Dr. RTL 能随模型能力扩展，同时也暗示未来可以用更小的领域模型或微调模型，降低成本并满足隐私部署需求。

成本方面，论文给出的说法也比较务实：真正耗时的是 EDA 执行，每个候选都要综合和 SEC；由于同一轮的候选可以并行评估，墙钟时间主要随迭代轮数增长。在论文设置中，K=10，优化全部 20 个设计大约需要一周墙钟时间，LLM 使用成本约 50 美元。对于工业 RTL 优化来说，这个数字并不夸张，尤其是它可以 24×7 持续运行，减少人工反复试错。

这项工作的意义：让“会用工具的智能体”进入芯片设计

Dr. RTL 的意义，不只是给出一组更好的 PPA 数字。更重要的是，它把 LLM 在硬件设计中的角色从“生成代码”推进到“参与工程流程”：读取真实报告、理解关键路径、提出候选改写、接受商业 EDA 和形式验证的裁决，再把可复用经验留下来。这种范式对 EDA 很有启发，因为芯片设计本来就是强工具链、强反馈、强约束的工作。

当然，论文也没有把问题说成已经完全解决。当前目标主要是时序和面积，功耗没有纳入；优化仍依赖商业工具的执行成本；技能库虽然可解释，但还需要在更多设计和更多专家知识中继续扩展。未来如果结合更丰富的探索策略、领域专用模型，以及人类工程师的审阅反馈，这类系统有机会成为 RTL 工程师的长期助手，而不是一次性的代码生成器。

结语

过去我们常说，LLM 写 Verilog 容易，写出可综合、可验证、PPA 好的 RTL 很难。Dr. RTL 这篇论文给出的答案不是让模型脱离工具“凭空变聪明”，而是把它放进真实 EDA 环境里，用报告约束它，用验证筛选它，用历史轨迹训练它。对芯片设计自动化来说，这也许是一条更实际的路线：不是替代工程流程，而是让智能体在流程里持续学习、持续试错、持续积累。

图片来源说明

文中部分图片整理自原论文，仅用于论文解读与学术交流。