MAGE：AI Agent自动生成RTL与Testbench，如何破解自判卷陷阱？

DAC 2025 的论文列表刚出来时讨论度最高的几篇基本都围着 AI Agent 转。当时大家热议的要么是 Agent 框架怎么编排要么是 agent 开发路线图但真正让我停下来反复读了不止一遍的是 MAGE 这篇论文。先说一句题外话这里的 DAC 是 Design Automation Conference设计自动化大会不是经常被折腾dac 输出模拟电压波形的那种数模转换器 DAC。两个缩写撞车搜资料时容易来回横跳我一开始就踩过这个坑。MAGE 引起我注意的原因很简单——它把用大模型生成 RTL这件事从单点工具升级成了完整闭环同一个 Agent先读自然语言 spec 写 RTL再自己写 Testbench最后用这套 Testbench 来给自己写的 RTL判卷。做验证的同事看到这个设定第一反应几乎都是同一句话这不是既当裁判又当运动员吗这篇文章我先把 MAGE 的核心思路拆开再结合我在 RTL 级验证项目里踩过的坑逐层分析Agent 写 RTLAgent 写 TestbenchAgent 自判卷这三个环节哪些是真本事哪些是隐藏的雷最后聊聊如果团队想落地这类工具应该在哪些位置设防。1. MAGE 想解决的问题为什么能生成 RTL和能交付 RTL是两回事1.1 从文生代码到自动迭代Agent 化到底改变了什么先把时间线捋一遍。最早一波用大模型写 Verilog的工作本质是文生代码你输入写一个支持突发传输的 AXI 主机接口模型输出一段 RTL。这种单次生成模式有个天然缺陷——没有反馈回路。模型写完就算完事语法错误、位宽不匹配、状态机缺 default 分支这些问题全部堆在一起等你去仿真时才逐个爆炸。到了后面几篇工作开始有人给模型接上 lint、仿真器、综合工具让模型看到报错自己改这就是 Agent 化的雏形。真正意义上的 Agent 不再是被动生成代码而是像实习生一样有终端权限它能编译、跑仿真、读日志、迭代修改直到目标达成。MAGE 在 DAC 2025 上引起我注意的点是它把这个循环直接推到验证环节。它的链路大致是自然语言规格 → RTL 生成 → Testbench 生成 → 自动仿真 → 根据结果迭代。也就是说Agent 不仅负责把代码写出来还要负责证明自己写得对。这个目标指向的痛点很现实——验证工作量通常占芯片前端开发的百分之五六十甚至更多。如果能自动生成一套像样的 Testbench 并完成回归省下的人力不是一点半点。1.2 闭环越完整自我评价的可靠性问题就越尖锐但这里有一个绕不开的认识论问题当同一个模型既写答案又写标准答案时这个分数到底意味着什么打个比方让学生自己出题、自己答题、自己改卷他可能每次都得一百分但这个一百分说明不了任何问题。在硬件设计里DUT被测设计和 Testbench 出自同一个模型两者共享同一套对规格的理解——如果模型理解错了某个协议细节它会在 RTL 里错一次在参考模型里再错一次但仿真结果却是完美通过。这种同源错误是自验证闭环最大的暗礁。仿真器本身只是一个执行环境它不会判断这行代码是否实现了 spec 的真实意图它只会验证在这组激励下输出是否符合你提供的预期。如果预期本身就是错的仿真必然绿灯。所以判断 MAGE 这一类工作靠不靠谱核心不是看它能不能跑通 demo而是看它在多大程度上引入了独立于自身理解之外的外部锚点。所谓外部锚点包括手工断言、覆盖率要求、形式化验证、独立的参考模型、以及人的代码评审。这些锚点越多自我判卷的可信度越高如果什么都没有整套系统只是在自己哄自己。2. Agent 写 RTL表面是代码生成本质是规格理解和时序认知的较量2.1 从自然语言到可综合代码Agent 要过五关很多人觉得 LLM 写 RTL 难在语法其实不是。如果只是语法模型训练语料里有海量 Verilog它不会比写 Python 差太多。真正的难点在下面五关第一关是规格解析。自然语言里的大约每隔 1us 产生一个脉冲当 fifo 快满时拉高这类模糊表述需要被翻译成精确的周期行为。第二关是架构决策。同样的功能可以有十种写法状态机怎么写、数据通路上几个流水级、握手信号怎么安排这些直接决定后续面积和时序。第三关是代码编译与可综合性。语法没错还不够综合工具能不能接受、会不会推断出 latch、会不会产生组合环路这些都是问题。第四关是仿真行为是否与预期一致。第五关是代码的可维护性和规范程度比如命名、注释、模块划分这在多人协作时尤其重要。我自己试过几款 RTL 生成类工具也看过团队里实习生用 Agent 写的模块前两关 Agent 通常能应付六成到八成第三关和第四关要靠迭代来兜底第五关基本是随缘。换句话说Agent 写 RTL 的上限从来不是代码生成能力而是它对自己生成的代码的验证能力——这就正好落回 MAGE 的主线。2.2 实测中最容易翻车的 RTL 细节下面挑几个我在生成代码里反复见到的问题都贴过比较惨的案例问题类型典型表现为什么仿真可能还是绿的落地影响阻塞/非阻塞混用always 块里对同一变量既 blocking 又 non-blocking部分仿真器行为可能碰巧符合预期综合后行为和 RTL 仿真不一致case 缺 default状态机没有 default 或非法状态恢复仿真时很少进入非法状态上电乱跳、卡死没有恢复路径异步复位无同步释放rst_n 直接做异步置位复位释放时刻恰好不在时钟沿时可能通过真实芯片存在亚稳态风险位宽截断/符号问题加法结果直接赋给窄位宽 reg定向测试没覆盖到大数场景边缘数据出错跨时钟域处理跨域信号直接打两拍就算 CDC功能测试跑不出同步失败真实系统的稳定性和 MTBF 问题今天在群里聊DFT 插复位怎么改 RTL时我跟同事说了一个判断这种问题恰恰是 Agent 生成型工具的软肋之一。DFT 场景下插入扫描复位、改动复位树不只是加一行代码它牵扯到时钟门控、scan enable、上游下游逻辑的一致性。Agent 没有全局工程上下文时很容易只改局部把时序修坏。所以说一个模块能生成、能通过仿真和它能真正融入一个带 DFT、带功耗管理、带多时钟域的 SoC中间还隔着很长的路。2.3 怎么量化一次 RTL 生成的质量实战里我建议至少看四类指标不要只盯仿真通过率Lint/CDC 报告有没有 inferred latch、位宽不匹配、跨域信号未约束。综合结果面积、关键路径时序、时钟门控数量。同一个功能写得好的和写得差的综合结果可能差出 30% 面积。代码评审成本一个 500 行的生成模块有经验的工程师 review 要多久。如果每次都要花半天那自动生成的效率红利就被磨掉了。回归覆盖率语句覆盖率、分支覆盖率、条件覆盖率、状态机状态覆盖率这些数字比一句通过了更能说明问题。3. Agent 写 Testbench激励只是入场券检查设计意图才是正赛3.1 为什么写 Testbench 比写 RTL 更难做验证的人都知道一个反直觉的事实写 Testbench 比写 RTL 难得多。RTL 只需要实现你理解到的功能Testbench 却要负责把你理解到的功能变成可检查的断言还要想办法触发所有边界情况。很多刚入行的同学写的第一版 TB 其实是激励产生器——给一组时钟和复位灌一些数据然后拿仿真波形肉眼对比。这不叫 Testbench这叫看戏。真正的自检 TB 必须能回答输出为什么是对的这个问题而不能只是输出了。对 Agent 来说这个难度被放大了。LLM 最擅长的是文本流畅性它生成激励代码很容易生成能证明实现正确的检查逻辑却很吃力因为它需要把规格里的隐含条件显式化。更麻烦的是当同一个 Agent 刚写完 RTL它脑子里充满了自己刚才的实现细节写出来的检查逻辑往往会顺着实现来而不是顺着规格来。这就是前面说的同源偏差在 Testbench 环节会体现得淋漓尽致。3.2 一套像样的自检 Testbench 至少需要五个零件接口驱动正确的时钟、复位时序、握手协议这是地板。激励生成定向加随机约束结合既覆盖典型场景也探索边界。参考模型独立于 RTL 实现的黄金模型输出期望值。计分板/监测器比对 DUT 输出和参考模型输出给出 pass/fail。断言SVA把关键时序性质写成 property仿真时实时监控。覆盖率功能覆盖率定义哪些场景算被验证过。我在团队里推行过一个简单的验收标准Agent 生成的 TB如果只有一个顶层任务在跑完整流程没有断言、没有随机约束、没有覆盖率收集那基本可以判定为不合格。这类 TB 的通过没有任何说服力。FPGA 开发群里经常有人问如何正确写 testbench我一般回答先别管写得好不好先确认你的 TB 能在 DUT 出错时真的变红。如果 DUT 故意改错一行TB 还是绿灯那它等于没写。3.3 写参考模型时的递归陷阱这里有一个值得单独拎出来的坑Agent 写参考模型时很容易直接把 RTL 的逻辑原样复制一遍或者用同一个 prompt 上下文里的思路生成。一旦参考模型和 DUT 是同构的任何共享的 bug 都会被掩盖。我建议在实际使用中这样强制隔离第一步让 Agent 只读规格文档生成参考模型明确禁止看它自己写的 RTL。第二步参考模型用不同描述层级比如 C/C 或者 SystemVerilog class 而非相同风格的 RTL这样即便语义错误至少实现路径不同。第三步把已知 bug 清单喂给另一个 Agent 实例让它写专门的陷阱测试专门验证那些容易出错的边界。这三步不能保证消除同源问题但至少能把偏差从完全共享降到部分独立。4. 自己判卷的信任边界仿真通过不等于功能正确先看清四种假阳性4.1 四种最典型的假通过如果 Agent 的闭环里只有激励 仿真 输出比对它必然会出现假阳性。我在实际评审生成型验证方案时会先检查下面四类。第一激励太弱。如果 Testbench 只在最常规的路径上跑了几笔交易时钟、复位、数据宽度都是理想值大概率测不出问题。第二覆盖率盲区。Agent 写的覆盖率收集常常跟着实现路径走比如它只对状态机正常转移定义状态覆盖却漏掉异常中断超时重传这类真实风险场景。覆盖率数字好看但它衡量的是实现不是规格。第三参考模型同源。就是 3.3 里说的递归陷阱参考模型复刻了 DUT 的错误理解两边一起错。第四断言缺失。很多生成 TB 只做最终数据比对缺少对中间时序性质的监控。比如一个握手信号应该在两个周期内被响应如果没有断言延迟 10 个周期仿真照样通过。4.2 一个很有效的考卷校准方法突变测试我特别想推荐一个做法突变测试mutation testing。思路很简单把 DUT 里的某一行故意改错然后跑 Agent 生成的 Testbench看它能不能发现。举个最小的例子原始代码是// 突变前正常赋值 data_q data_in;把它突改成// 突变后换成阻塞赋值故意注入的错误 data_q data_in;如果这套 Testbench 没有在时序行为上抓到差异说明它对为什么对的检查能力存在明显漏洞。这个方法最大的价值在于它把判卷本身变成了被考核对象。MAGE 自己判自己不可信没关系你定期往 RTL 里注入一批已知错误看 Testbench 能不能识别出来。如果一个 TB 能杀掉 95% 以上的变异体那它的说服力比任何一句仿真全部通过都强。我在评估团队的验证完备性时已经把突变覆盖率和功能覆盖率并列作为硬指标了。4.3 论文里通常会配哪些监考机制来规避质疑作为论文MAGE 这类工作要自圆其说通常会在实验设计里加入独立锚点。从这类工作的常见做法看大概会有几个方向一是引入断言生成让 SVA property 承担一部分独立检查职责二是做覆盖率驱动的迭代Agent 反复读覆盖率报告把空白区域补上三是做多 Agent 角色分离生成 RTL 的和生成 TB 的不用同一个上下文甚至用不同模型四是把形式化验证作为最终关卡对关键 property 做穷举证明。作为读者看论文时最应该找的就是这些机制到底嵌在流程的哪一步以及它们覆盖了多少设计。我自己对是否靠谱的判断公式是可靠性约等于独立锚点的数量乘以每个锚点的严格程度。如果论文只是生成 → 仿真 → 绿灯那它展示的是 demo 不是方法论如果它有断言、有覆盖率、有突变、有 formal那至少研究态度是够的。5. 实验拆解面对一堆通过率 90%的数字要问作者五个问题5.1 测试用例的复杂度分布第一个要问的是benchmark 里都是什么规模的模块如果全是 FIFO、ALU、简单的状态机通过率高只能说明Agent 能处理教科书级问题不能说明它能处理带复杂协议、多时钟域、低功耗逻辑的真实模块。看论文时要把 benchmark 列表拉出来按门的复杂度、接口数量、状态数排个序再回看通过率曲线。通常你会发现通过率是漂亮的大数但能过的复杂度上限才是真正的边界。5.2 通过的定义是什么是 RTL 能通过编译还是仿真全部 pass还是综合后时序收敛还是功能覆盖率达到某个阈值这四个定义的难度不是一个量级的。有些工作说的通过仅仅是编译通过这在芯片行业里的价值几乎为零。我读这类论文的第一个动作就是查 method 部分对 pass criterion 的定义如果只写了all test cases passed那基本可以预期里面水分不小。5.3 覆盖率是谁说了算覆盖率定义是另一个可以操作的地方。如果覆盖率 bin 由 Agent 自己定义它必然会按实现路径来切任何规格风险视角都会丢失。安全的做法是覆盖率由独立验证工程师或独立模型定义Agent 只能去填充它。论文里如果连覆盖率定义都交给被测对象本身那整套实验只是闭环里的自我确认。5.4 有没有做错误注入这是我最看重的一项。一套 Testbench 如果没经历过突变测试、错误注入、或者人为制造 bug 的挑战它的通过就说明不了验证能力。看论文时可以专门找fault injectionmutation这些词。有说明作者认真想过假阳性没有说明作者很可能在回避最尖锐的质疑。5.5 失败案例长什么样任何严肃的实验都应该有失败案例。如果一篇论文报告 90% 通过率那另外 10% 是因为什么失败的是复杂协议没理解是时序问题资源耗尽失败模式的分布比通过率本身更能说明 Agent 的真实能力边界。反过来如果论文只字不提失败样本那它的结论基本可以打折扣。用这五个问题去套 MAGE 以及同期几篇 Agent 做硬件的论文你会很快看出哪些是方法论突破哪些只是把 demo 包装成了 paper。6. 落到工程实践这类 Agent 应该用在哪防在哪6.1 我建议先上的三个场景第一早期架构探索。需求还在摇摆、spec 还在改的阶段让 Agent 快速生成多个版本的设计草案比人工手写效率高很多反正这些代码大部分是要扔掉的。第二测试脚手架生成。让 Agent 去搭 TB 框架、时钟/复位/接口驱动、寄存器模型这些工作重复性高、创造性低非常适合自动化。做完后人工来填断言和参考模型这些考思维的部分。第三覆盖率缺口分析。拿 Agent 读覆盖率报告提出补测建议能有效减少验证工程师的机械劳动。6.2 我明确不建议碰的地方安全关键 IP 的最终签核、带复杂跨时钟域与功耗管理的子系统、以及任何需要由人承担最终责任的 sign-off 位置短期内我不会放开。原因不在于 Agent 的代码质量差——有些模块它写得还真不错——而在于它的自验证闭环还无法提供足够的独立证据。一个系统如果连它为什么是对的都只能靠它自己来说底层逻辑上就不能作为签核依据。另外遗留代码集成也是重灾区。现有代码里堆满了历史约束、workaround、工艺相关 hackAgent 没有这些背景强行生成代码做局部替换很容易破坏隐性假设。6.3 落地团队的几条实操铁律我的个人建议不管用哪个 Agent 框架团队落地时必须守住这几条DUT 和 TB 必须分离生成。至少用两个相互独立的 Agent 实例或不同模型避免共享上下文导致同源错误。建立突变测试流水线。把错误注入做成自动任务定期用变异体考核 TB 的发现能力当成流水线的红绿灯之一。覆盖率报告必须由人复核。功能覆盖率定义不要完全交给生成方人至少看一遍关键场景列表。保留人工签字节点。生成代码进入主干前必须经过 lint、仿真、覆盖率、至少一次 human review。所有生成产物入库并记录 prompt 版本。出问题时要能追溯是哪一轮生成的方便回滚。6.4 最后一个实际体会我自己对 MAGE 这类工作的态度是认真关注但不会把 tape-out 计划押在它身上。它最有价值的地方不是能自动判卷这个噱头而是它逼着整个行业把验证完备性变成可量化、可审计的流程问题。这比单纯让模型多写几行 RTL 要有意义得多。在我实际拿类似工具跑过几次之后更坚定了之前说的那句话把它当效率极高的实习生用让它快速出活、出草案、出测试架子但在判卷这件事上旁边必须站着一个真正懂行且独立的考官。