AI 写 RTL 越快,验证越值钱

最近这篇 STG 论文，值得把它从一堆 AI+芯片设计论文里单独拎出来。

它不讲“让大模型再写一段更漂亮的 Verilog”，也不讲“再做一个更复杂的 RTL agent”。它盯着一个更朴素的问题：当 LLM 可以一口气生成很多 RTL 候选以后，谁来快速、稳定、便宜地判断这些东西到底对不对？

论文题目可以译作《面向 LLM 驱动 HDL 设计与验证导向数据筛选的结构化 Testbench 生成》。作者提出 STG，也就是 Structured Testbench Generation。说白了，它想把 testbench 生成从“让 LLM 自由写代码”改成“先读懂 HDL 结构，再按确定模板生成 testbench”。

这个方向没有端到端大模型那么热闹，但它可能更接近 AI 进入芯片研发流程后的真实瓶颈。

问题不在能不能写 RTL

过去一年，LLM 生成 RTL 的系统越来越多。自然语言规格到 Verilog、自动修 bug、迭代搜索、test-time scaling、SFT、强化学习，几条路线都在往同一个方向走：让模型不只写软件代码，也能写硬件描述。

但这里有个麻烦。RTL 可以生成很多份，验证不能跟不上。

如果每生成一个待测设计（DUT），都要再调用 LLM 写 testbench、写 checker、生成 silver reference，然后多轮修正，成本会被迅速放大。更麻烦的是，LLM 写出来的验证工件本身也可能错。DUT 是模型写的，oracle 也是模型写的，最后二者不一致，到底是谁错了？这个判断天然不稳。

STG 把问题放进 known-reference RTL verification 场景：给定一个 DUT 和一个可信 golden implementation，自动生成 testbench，用同一组输入驱动 DUT 与 golden reference，再比较输出。

这不是覆盖所有芯片验证问题的万能设定。真实项目里经常没有现成 golden reference，UVM 环境也复杂得多。但这个设定非常适合 LLM-driven RTL workflow 里的三类任务：benchmark 评估、候选 RTL 筛选、test-time scaling 的反馈判断。

换句话说，STG 不是来替代验证工程师的。它更像是给“模型批量产出 RTL”这条新流水线补一个便宜闸门。

testbench 生成，被拆回工程问题

很多 prompt-based 方法会把 testbench generation 当成开放式代码生成。模型看到规格或 RTL，然后吐出一段完整 testbench。

这当然灵活。但问题也很硬：输出随机，格式不稳，token 成本高，覆盖率也不一定可靠。

STG 的思路反过来。它先承认硬件设计本身是有结构的。

论文里的流程大致是这样：先分析 HDL，识别 top module、端口、时钟、复位、控制信号、数据信号和设计类型。然后根据设计类型选择 stimulus strategy，再用参数化 Jinja 模板渲染 testbench。

设计类型分三类。

如果端口里没有 clock，就按组合逻辑处理。STG 会枚举控制信号，对数据信号做随机采样，同时设置上限，避免测试向量爆炸。

如果是一般时序逻辑，它不会只在每个正边沿看一次输出，而是用 reset-aware 的两阶段随机激励，并在周期内输入变化、负边沿、正边沿等位置插入比较点。这样做是为了同时观察 Mealy 风格的周期内响应和 Moore 风格的寄存器输出。

如果是 FSM 主导设计，STG 会先用模式匹配找 always_ff 或 always @(posedge clk) 里的 case/casez 状态跳转结构；如果结构不够明确，再用结构化 LLM query 提取状态变量、编码、静态参数和转移条件，最后生成面向状态转移的 stimulus。

这里最有意思的地方，不是“LLM 又能生成 testbench 了”。恰恰相反，是 LLM 不再负责写完整 testbench。真正批量执行的是解析、分类、模板渲染和仿真比较。模型只在必要的位置补一点结构理解。

这才像工程系统。

720 倍，真正说明的是任务边界

论文摘要里最抓眼的数字，是 STG 作为直接验证工具时，生成 testbench 的速度比迭代式 LLM testbench generation pipeline 快 720 倍。作者还称，它有更高的编译成功率、更高的 line/toggle coverage，并减少了错误 DUT 的 false-pass。

这个 720 倍要放在论文设置里看，不能直接外推到所有 RTL 验证场景。真实项目不会因为这个数字就把完整验证流程替换掉。

但它说明了一件事：AI+EDA 里的性能差距，不一定都来自模型大小。有时差距来自任务定义。

如果让 LLM 每次从零生成 testbench，本质上是在用概率模型处理大量确定性样板。模块实例化、端口连接、输出比较、错误计数、报告格式，这些东西不需要模型每次重新想一遍。模型真正可能有价值的地方，是帮助理解难解析结构，或者在复杂语义上提供辅助判断。

把确定性部分交给程序，把不确定判断留给模型。STG 的路线，更像 AI 工具真正进入 EDA flow 后会长出来的样子。

这也是中科麒芯关注的方向：不是把 AI 停留在个人问答助手，而是围绕模型、知识库、设计流程和 Agent 治理，构建可用、可控、可落地的芯片研发智能体能力体系。

很多人谈 AI+EDA，第一反应是“让模型自动完成整个设计”。但真实研发流程里，最先规模化落地的往往不是端到端替代，而是把高频、重复、可约束的环节拆出来，让模型和传统工具各做自己擅长的部分。

真正的大题，是数据筛选

STG 更值得看的地方，其实是 verification-oriented data curation，也就是为了验证质量反过来筛训练数据。

现在很多 RTL 大模型训练流程都依赖一条路：模型生成数据，系统筛选数据，再把筛选后的数据拿回去训练模型。问题在于，筛选这一步如果还靠 LLM 写验证工件，就会又贵又不稳定。

验证误判会直接污染训练集。错误 RTL 被当成正确样本留下，正确 RTL 又可能被弱 testbench 错杀。后面你再怎么训练，吃进去的信号已经脏了。

论文称，在数据筛选场景下，STG 在单个 CPU core 上比 LLM-based filtering 快 11 倍，能耗低 127 倍。作者还报告称，用 STG 筛出的数据走简单 SFT pipeline，也能在多项 RTL generation benchmark 上取得有竞争力甚至更好的结果。

这个点比 720 倍更值得关注。

因为它触到了 AI 芯片设计模型的飞轮：模型生成候选设计，验证系统给标签，筛选后的样本再回到训练。这里真正稀缺的不是“更多文本”，而是更可信的工程反馈。验证信号越稳定，后面的训练、蒸馏和搜索才越可能变成正循环。

从这个角度看，STG 像一台低成本标签机。它不创造设计能力本身，但它在大规模候选 RTL 和训练数据之间，放了一个确定性更强的筛选层。

让搜索少走弯路

论文还把 STG 放进 test-time scaling 里看。现在不少 LLM RTL 系统已经不满足于一次生成，而是采用搜索、回溯、迭代修复，让模型在推理时探索多个候选解。

这类系统有一个前提：每一步反馈必须便宜，也必须可信。

验证信号慢，搜索树跑不动。验证信号噪声大，搜索就会被错误反馈带偏。

论文称，STG 作为 test-time scaling oracle，可以把 solved-problem node count，也就是解决一个问题所需访问的搜索节点数，降低 14%-47%。意思是，在同样解决问题的情况下，搜索需要访问的节点更少。

这不是说 STG 让模型突然变聪明了。更准确地说，它让模型更快知道哪条路不该继续走。

对 AI 生成 RTL 来说，这可能比“多生成几个候选”还重要。候选越多，验证越要便宜；搜索越深，反馈越要稳定。

边界必须说清楚

STG 的设定很强：它主要工作在 DUT 和 golden reference 都可用的场景。

这意味着，在真实项目里，规格不完整、golden reference 不存在、UVM 环境复杂、跨模块交互密集的大 SoC 验证，它不能直接替代现有 verification flow。

它生成的是面向比较和覆盖的 testbench，不是 sign-off。CDC、低功耗、电源域、异步边界、性能约束、安全属性，这些仍然需要专业验证方法和工程师 review。

所以更准确的判断是：STG 解决的是 LLM-driven RTL workflow 里的“批量候选判断”和“训练数据筛选”问题，而不是整个芯片验证问题。

但这恰恰让它更现实。AI+EDA 的早期落地，通常不是一口吃掉完整流程，而是在一个边界清楚的子问题上，把成本曲线打下来。

写在最后

AI 写 RTL 越快，验证信号就越值钱。

如果未来芯片设计真的进入“模型批量生成、系统自动筛选、数据持续回流”的阶段，那么 testbench 就不只是验证工程里的一个文件，而会变成模型训练和推理搜索的基础设施。

STG 这篇论文提醒了一件事：AI+EDA 不一定总是更大的模型、更长的推理链、更复杂的 agent。很多时候，真正能把系统跑起来的，是把硬件工程里的结构重新用起来。

让模型做判断，让工具做结构化执行，让验证反馈成为训练和搜索的硬信号。这可能才是 AI 进入芯片研发流程后更可持续的路线。

如果你的团队正在评估 AI+EDA、研发知识库、流程自动化或私有化 Agentic AI 落地路径，可以关注并回复「合作」，一起交流适合芯片研发现场的实施方案。

💬 加入 IC Agent 技术交流群

群里聚集了芯片设计工程师、IT/CAD 负责人和 AI+EDA 从业者，聊技术、聊工具、聊行业趋势。

👉 关注回复「加群」，拉你进群一起聊

👉 关注回复「合作」，如果你在做 AI+ 芯片/EDA 相关，欢迎来聊

后续会持续更新这个系列，关注不迷路。