体系结构论文（九十）：Automated Multi-Agent Workflows for RTL Design

Automated Multi-Agent Workflows for RTL Design解决什么问题现有 RTL 生成大致有两条路一条是对 LLM 做 RTL/HDL 专项微调但成本高而且对邻近任务的泛化未必好另一条是直接用强推理模型但推理开销大。作者认为通用的 agent workflow 自动搜索方法虽然在 QA、数学、通用 coding 上有效但未必直接适用于 RTL 设计因为 RTL 任务更依赖 EDA 流程、编译/综合约束和形式化检查。于是他们提出 VeriMaAS把“EDA 工具反馈”接进 agent workflow 里面。核心方法是什么VeriMaAS 会针对一个 RTL 任务自适应地从一组 reasoning operators 中选择工作流步骤。每一轮生成出的 Verilog 候选都会送去跑Yosys和OpenSTA。如果很多候选在编译、验证、面积、运行时、功耗分析上失败系统就判断这个任务更难需要升级到更复杂的 operator否则就提前停止返回当前结果。也就是说它的 controller 不是靠纯语言模型自我反思而是靠真实 EDA 反馈来驱动 workflow 选择。控制器怎么训练这篇文章没有做那种重型的 end-to-end 微调而是只学习一个级联控制器的阈值。它把任务按 stages 逐步升级I/O → CoT → ReAct → Self-Refine → Debate 【I/O 最简单CoT 是显式分步思考ReAct 是边想边做Self-Refine 是自我修改Debate 是多角色辩论。】作者从 VeriThoughts 训练集里随机采样500 个样本统计每个阶段 20 个候选中有多少个在 Yosys/OpenSTA 里失败再根据失败比例的分位数来确定各阶段阈值。优化目标同时考虑效用passk成本平均 token 数所以本质上它是在做一个低成本的 workflow controller tuning而不是大模型再训练。文章强调这只需要“几百条样本”比完整微调所需的上万条监督数据少一个数量级。效果怎么样在VeriThoughts和VerilogEval两个 benchmark 上VeriMaAS 相比单一 prompting 和已有 fine-tuned RTL 模型都有提升论文摘要里说相对 fine-tuned baselinepassk 提升约 5–7%结果部分又指出在开源模型上pass1 相对已有 fine-tuned baseline 可提升到 7–12%。和单一 CoT / ReAct / Self-Refine 比有什么不同文章专门比较了 VeriMaAS 和单一 prompting 策略。结论是VeriMaAS 的提升通常比单一 CoT 更稳token 开销虽然有增加但通常低于 Self-Refine 这种迭代式方法对强闭源模型收益变小但仍然有稳定增益。额外亮点PPA-aware 优化由于它不是把能力固化进模型权重里所以 controller 可以很容易换目标。作者做了一个 proof-of-concept把优化目标从 token cost 改成Yosys 报告的 area尝试让生成结果更偏向 PPA 优化。结果显示在一些子集上面积、延迟能明显下降最大面积下降可到28.79%但代价是有时功耗略增或者pass10 略降。一、INTRO背景Agentic AI 很有潜力但 RTL 领域很特殊文章开头先说agentic AI workflow智能体工作流最近在计算机系统设计和优化里很有前景。但问题是RTL/HDL 代码生成这个领域和普通编程不一样在线可用的 HDL 数据少很多 EDA 资源和设计流程是专有的因此很难像普通代码那样靠海量数据把模型训得很好。所以现有方法往往会陷入几种代价很高的路线任务专项微调fine-tuning更强模型带来的高推理成本人工手工设计 agent orchestration智能体编排流程文章提出了什么VeriMaAS作者提出了一个框架叫VeriMaAS。它是一个multi-agent framework目标是自动组合适合 RTL code generation 的 agent workflow而不是靠人手工指定“先 CoT、再 self-refine、再 debate”这种固定流程也就是说它想做的是让系统自己决定该用什么推理策略、何时升级工作流复杂度。RTL 生成已经是一个重要方向文中提到近年来已经出现了很多 RTL generation / hardware design 相关方法和 benchmark用于RTL 代码生成EDA tool scripting加速器设计HDL 调试后综合指标评估现有两类主流方法各有缺点第一类fine-tuning 路线就是把 LLM 在 RTL/HDL 数据上专门微调。优点任务适配性强性能通常不错缺点成本高需要较多 GPU 预算对相邻 HDL 任务未必泛化好也就是说这类方法像是“为某类 RTL 题专门补课”补完后做这类题很强但换题型不一定稳。第二类纯推理模型路线比如更强的 reasoning model不去微调而靠推理能力直接做 RTL。优点不需要额外训练缺点把成本从训练阶段转移到了推理阶段推理可能很长、很贵这条路的问题不是“省了”而是“换地方花钱”。作者为什么想到 multi-agent workflow作者说他们受到自动化 multi-agent workflow generation 的启发。像一些已有工作已经证明相比单一 prompting自动编排多个 agent/operator往往能更好平衡性能和成本但这些方法主要用在QA数学题通用 coding而 RTL 设计属于更强领域约束的任务不能直接照搬。为什么不能照搬因为在通用 QA 里像 Debate 这种 prompting operator 可能就很好用但在 RTL 设计中真正决定好坏的不只是“推理过程看起来合理”而是代码能不能通过验证综合能不能成功最终电路指标好不好所以文章想表达的是通用 multi-agent 方法有启发但如果不接入 EDA/HDL 反馈就不够懂 RTL。key insight什么叫“integrate HDL verification checks directly into workflow generation process”就是把 HDL/EDA 工具的结果直接用来控制工作流而不是只在最后做个评测。更具体地说系统会把这些信息喂给 workflow 决策过程design logserror messagessynthesis tool results然后根据这些反馈来决定当前生成结果够不够好要不要继续 refinement要不要升级到更复杂的 reasoning strategy应该朝哪个目标继续优化所以它不是“先生成完再离线测一下”而是边生成边根据工具反馈调 agent workflow。为什么这招有效因为 RTL 的“对错”高度依赖工具链。比如一段 Verilog语言上看着没毛病注释也很合理LLM 自己也觉得逻辑通顺但实际上可能综合报错有 latch时序不满足面积过大verification fail所以如果只靠自然语言层面的 self-reflection模型可能会“自我感觉良好”而接入 HDL verification feedback 后系统拿到的是硬约束下的真实反馈。这相当于给 agent workflow 接上了“物理世界的裁判”。它不只是为了功能正确还能支持不同设计目标文中提到这样做后agentic reasoning 可以面向不同目标展开例如PPA-aware prompting功耗 power性能 performance面积 area为什么说监督成本低性能可达到甚至超过已有方法最多提升到7% passk但 controller tuning 只需要几百个样本这说明它的主要优化对象不是大模型本身而是工作流控制器。所以训练压力会比 full fine-tuning 小很多。二、方法图 1 想表达的是简单任务不需要复杂 agent可能用 I/O 或 CoT 就够了中等任务可能要经过 1~2 轮 operator 升级困难任务需要更复杂的多步推理比如 Self-Refine、ReAct 甚至更多 operator。也就是说不是所有 RTL 题都一上来就用最重的 workflow而是按难度逐步升级。第一行简单任务例子是Design 4-input AND gate这个任务很简单所以初始 operator 生成的一批候选大多数都能通过controller 看日志后判断“已经够好了”很快就输出结果不再升级 workflow。这体现的是easy task early stop。第二行中等任务例子是Design 4-bit binary adder这个任务比与门复杂第一轮简单 operator 生成后有一些失败controller 认为还不够进入下一层 operator再生成一批候选后通过率上来了然后输出结果。这体现的是适度升级 reasoning complexity。第三行困难任务例子是PWM signal generator这种任务更复杂通常需要第一轮失败很多第二轮也不够controller 继续升级到更强 operator经过多轮 refinement 才得到更高质量候选。这体现的是hard task needs deeper workflow。图中符号怎么理解1彩色圆点绿色I/O棕色CoT蓝色Self-Refine紫色ReAct还有其他这些圆点表示当前阶段从某个 operator 生成了一批候选样本。2YosysHQ 标志表示生成的候选会送到综合/验证流程中去检查。文中后面说明具体会经过Yosys综合、面积估计、基础检查OpenSTA时序、功耗分析3Controller这是系统核心。它根据上一轮候选的日志和失败情况决定当前结果是不是已经够好是否进入下一层更复杂的 operator还是直接终止并返回现有候选。所以 Controller 本质上是个workflow 决策模块。Methodology具体流程对一个 RTL taskVeriMaAS 会做三件事第一步根据任务和难度采样 reasoning operators也就是先决定当前阶段用什么 agent/operator。第二步执行候选 Verilog把生成结果放进综合和验证流程里跑YosysOpenSTA第三步用日志和错误信息做反馈把这些反馈拿回来告诉 controller下一步该不该继续要不要换更复杂的 reasoning strategy还是现在就终止。作者定义一个解空间 O表示所有可用的 agentic operatorsZero-shot I/OChain-of-Thought (CoT)ReActSelf-RefineDebate也就是说系统可选的“动作库”就是这几种 operator。多智能体解是什么作者把一个多智能体解写成O{Oi∈O∣i1,…,K}它本质上就是说一个 workflow 可以看成若干 operator 的组合序列。例如1只用 CoT那就是单步 workflowO{OCoT}2先 CoT 再 Self-Refine那就是两步 workflowO{OCoT,OSelfRefine}所以作者是在把各种 prompting / agent 方法统一成一个“operator sequence”的框架。它的目标是什么给定用户 query它的目标是找到一个 operator 组合使得生成的 RTL 最好。这个“最好”主要通过passk衡量。passk 在这里是什么意思系统不是只生成 1 个 Verilog 候选而是生成一组看这组候选里有没有通过验证/综合的正确结果如果前 k 个候选里至少有一个对就算成功。文中说通常设置E20 samples∣O∣K20也就是每个 query 会生成 20 个候选再看通过情况。Agentic Controller输入query q当前可选 operator 集合 O当前解生成出的答案集合 A_{O_{current}}输出一个更新后的解 O_{new}翻成白话就是controller 看当前已经试过的 operator 和生成结果然后决定下一步 workflow 怎么改。operator 按复杂度排成一个逐级升级的链条controller 如何决定要不要升级它会在每一层计算一个分数 sc表示当前阶段是否值得继续升级。如果scτc​说明当前阶段已经够好停止返回当前解否则说明还不够继续加入下一层 operator。其中τc 是该阶段的阈值整组阈值记为 T{τ1,τ2,…,τC}所以这个控制器本质上就是用一组 stage-specific threshold 控制 workflow 深度。作者的关键观察formal verification 和 synthesis 的反馈能够很好反映任务复杂度。直觉上如果最初简单 operator 生成的一批候选大多都过不了那么这个任务大概率更复杂就应该用更高级的 reasoning operator。所以这里的 “难度” 不是人工标注的而是通过候选失败率间接测出来的。每一阶段具体怎么做在 cascade 的每个 stage生成 K20个 Verilog candidates跑 Yosys 做综合和面积估计跑 OpenSTA 做时序和功耗分析统计失败比例。作者定义scScore(AOc)它表示这一阶段候选中因以下问题失败的设计所占比例verification errorsynthesis(area) errorruntime errorpower analysis error也就是失败样本百分比 当前阶段难度/不足程度的指标。sc越大失败越多说明当前 operator 不够用要升级sc越小通过越多说明当前阶段已经足够不需要更复杂 workflow。所以它并不是“信心分数越高越好”那种常见设定这里更像是一个failure-driven escalation score。Problem formulation这一段是在把 controller tuning 写成优化问题。它要学什么它不是训练整个大模型而是学习那组阈值T{τ1,…,τC}也就是说真正待学习的是每一层 operator 在什么失败比例下应该继续升级。优化目标是什么公式本质上是在最大化效用−λ×成本其中效用 U(⋅)作者定义为passk成本 C(⋅)定义为平均 token 数所以它追求的是在尽量少用 token 的前提下让 passk 尽可能高。λ 是权衡系数。文中设为λ1e−3意思是主要目标还是性能但也不能完全不顾 token 成本。训练数据作者从VeriThoughts training set中随机采样500 个 datapoints对每个 datapoint 做什么对于每个 query生成 20 个 candidates计算 passk 和 token cost看有多少候选无法通过 Yosys / OpenSTA 检查。也就是把每个样本都转换成性能信息成本信息失败比例信息阈值怎么定作者把所有样本的 failure counts 聚合起来然后取20th percentile40th percentile60th percentile80th percentile这些分位点对应五个 operator 阶段。这个做法其实非常“轻量”不需要大规模梯度训练更像是用统计分位数来设置 cascade threshold。所以这篇文章的方法并不是复杂 RL controller 或神经控制器而是一个非常工程化、很实用的 threshold-based controller。三、实验两个 benchmarkVerilogEval和VeriThoughts指标pass1、pass10每题生成20 个 samples工具链Yosys做验证与面积估计OpenSTA做时序和静态功耗分析综合环境Skywater 130nm PDKMain ResultsVeriMaAS 在两个 benchmark 上都比强单 agent 方法更好也比已有的 fine-tuned RTL 模型更强对开源模型提升尤其明显不只是 pass1 提高pass10 也经常提高具体内容论文直接总结说在开源 LLM 上相比已有 fine-tuned baselinepass1 可以提升到 7–12%同时VeriMaAS 还会提升pass10说明它不只是把“最好那个答案”变好还把整个候选池里有效设计的比例也提高了。这个点很重要因为 RTL 生成通常不是只看单发命中而是看能不能多生成一些可用候选。Table 1Instruct LLMsReasoning LRM/强推理模型RTL fine-tuned models几个你最该记住的数字例 1Qwen2.5-7BVeriThoughts44.90 → 56.62pass111.72VerilogEval22.92 → 29.10pass16.18这说明对中等规模开源模型VeriMaAS 的帮助非常明显属于“比较硬的提升”。例 2Qwen3-14BVeriThoughts89.35 → 92.16pass12.81VerilogEval65.87 → 66.96pass11.09这说明底座已经很强时提升会变小但依然稳定存在。例 3GPT-4o-miniVeriThoughts80.64 → 83.09VerilogEval50.26 → 52.05pass10 也分别提升到92.85和64.02这说明即使是闭源强模型agent workflow 也不是没用而是还能继续挖出一点增益。开源模型收益大闭源强模型收益小但稳定VeriMaAS 往往不输专门 RTL 微调模型Table 2这张表回答的是VeriMaAS 的提升究竟来自“多智能体编排”本身还是随便换个 CoT / ReAct 就行对比对象CoTReActSelfRefineVeriMaAS具体内容也就是在同一个 base model 上把不同 prompting/operator 单独拿出来比较看谁精度更高、token 成本更低。对 o4-mini 的结果VeriThoughts 上SelfRefine 的 pass1 最好94.31但VeriMaAS 的 pass10 最好98.17VerilogEval 上VeriMaAS 的 pass1 / pass10 都最好76.15 / 84.50对 GPT-4o-mini 的结果VeriThoughtsVeriMaAS 的 pass1 达到83.09VerilogEvalVeriMaAS 的 pass1 达到52.05但 ReAct 在部分指标上也很强比如 VeriThoughts pass10 达到93.10对 Qwen2.5-14B 的结果VeriThoughtsVeriMaAS 的 pass10 95.78VerilogEvalSelfRefine 的 pass10 63.55略高于 VeriMaAS 的 62.48但 VeriMaAS 的pass1 41.47明显高于 CoT / ReAct也接近或优于其他方法具体内容这说明 VeriMaAS 不是“所有格子都最优”但总体趋势是在 pass1 和 pass10 上都有稳定竞争力而且更适合作为通用 workflow。Token 成本VeriMaAS 有额外 token 开销但开销是“中等”的通常接近 CoT低于 Self-Refine 这种重迭代方法比如o4-mini 上VeriThoughts token 大约1.21k而 SelfRefine 是2.24kCoT 只有1.10kTable 3不再把 cost 定义成 token cost而是改成Yosys 报告的 area然后重新优化 controller看最终面积、功耗、延迟会不会更好具体内容也就是说VeriMaAS 的 controller 不是只能为“更高 passk”服务它还可以换目标函数去朝 PPA 优化。作者也承认不是所有 benchmark 题都有明显的 PPA 优化空间。例如 NAND gate 这种很简单的题RTL 怎么改都很难让下游 PPA 差很多。所以他们用 o4 先挑出那些“RTL 改动更可能影响 PPA”的 top 20 design 子集称为PPA-Tiny。面积最大下降 28.79%延迟很多情况下也下降功耗多数下降但也有少数上升pass10 有时会轻微下降具体内容比如在 VerilogEval-PPA-Tiny 上Qwen2.5-7B 的ΔArea 28.79%↓ΔDelay 也达到24.58%↓但 ΔPower 是4.07%↑。