RTL 氛围编程时代,工程师必须守住的 5 道验证关卡
AI 正在生成 RTL 和 testbench。本文从从业者视角梳理实际项目和作品集中必须检查的五道验证关卡。
“可以用 AI 编写 RTL 吗?”,“能相信 LLM 生成的 testbench 吗?”这是最近经常从身边的设计、验证工程师和求职者那里听到的问题。本文不引用具体个人或项目,只将反复出现的匿名疑问加以归纳,并从从业者视角作答。
一句话回答:可以用 AI 生成 RTL 初稿。但必须由人来批准 规范 → lint → simulation·coverage → formal·CDC → synthesis·STA·PPA 这五道验证关卡。
AI 辅助编写几行 Verilog 的阶段已经过去了。Cadence 表示,ChipStack AI Super Agent 通过专业 agent 串联 RTL 生成、testbench 生成、regression orchestration 和 debug。2026 年 4 月,Cadence 宣布其早期客户项目的生产率最高提升 10 倍。该数字来自供应商披露,并非独立 benchmark,因此不应直接泛化。但 EDA 交互方式正从以 GUI 和 Tcl 为中心,转向“给定目标,再将工具结果反馈给 agent”,这一方向已经十分明确。
关于 AI EDA 将首先改变产业哪个环节的总体趋势,我们在 AI EDA 生产力栈:验证与 closure 会先于 RTL 改变 一文中已有讨论。本文聚焦可用于实际项目和作品集的批准关卡。
问题出在将软件氛围编程中“能够编译、演示能够运行就算完成”的标准套用到 RTL 上。RTL 并不是功能正确就结束的代码,而是必须同时满足 clock、reset、protocol、CDC、power intent、可综合性、PPA 和 signoff constraint 的实现规范。
关卡 1:是否已将自然语言转换为可执行规范
“帮我做一个 AXI slave”并不是规范。至少必须确定以下内容。
- 支持的 protocol 及 subset
- data/address width
- 未完成 transaction 数量
- latency 与 throughput 目标
- reset 类型与 polarity
- invalid access 处理方式
- backpressure 条件
- clock domain 与 power domain
不要让 AI 随意填补空白。应让它将尚未确定的事项作为问题返回。近期的 LLM RTL 研究也表明,大量错误不仅源于模型的推理能力,还来自模糊描述以及对电路概念的误解。
通过条件:需求清单、I/O 表、状态转换、timing example 和 error behavior 均已文档化,并分别拥有可追踪的 ID。
关卡 2:是否检查了 RTL 质量,而不只是语法
编译成功只是最低门槛。必须通过静态检查排查 latch inference、width truncation、signedness、incomplete assignment、combinational loop、遗漏 reset 以及 simulation-synthesis mismatch 的可能性。
即使 AI agent 能够读取 lint 结果并自动修改,也不能允许它随意 suppress 警告。waiver 必须包含原因、责任人、适用范围和失效条件。
通过条件:compile/elaboration 成功,满足 lint severity 标准,且所有 waiver 均记录依据。
关卡 3:是否具备 self-checking simulation 和 coverage
如果 AI 同时生成 RTL 和 testbench,同一种误解可能被复制到两个文件中。reference model、assertion 和 testbench 应尽可能采用相互独立的表达方式。
最低测试集应包含以下内容。
- reset 与 reset release
- 正常的 single transaction 与连续 transaction
- backpressure 与最大延迟
- 边界值与 illegal input
- protocol ordering 的各种可能组合
- long random regression
VerilogEval 系列研究使用 testbench 评估 LLM RTL,而近期研究通过加入 simulation-error localization-correction loop 提升性能,原因也在于此。与 one-shot 生成相比,基于工具的反馈循环更为关键。
通过条件:每个需求 ID 都关联 test 或 assertion,regression 可复现,并对 functional coverage 中未命中的项目作出说明。
关卡 4:是否通过了独立的 formal·CDC·equivalence
simulation 只能检查实际执行过的路径。对于 control logic、arbitration、protocol safety property 等状态空间至关重要的模块,formal property 更有优势。若存在多个 clock 或 asynchronous reset,CDC/RDC 分析应成为单独的关卡。
如果 AI 优化了现有 RTL 或生成了 ECO,equivalence 尤为重要。Cadence 将 Conformal 系列 equivalence 工具描述为独立 auditor,用于确认实现工具生成的结果在逻辑上是否相同。这里的关键词不是 AI,而是独立。不能让生成器和判定器依赖同一套推理。
通过条件:保留 assertion proof 或明确的 bound、CDC/RDC violation disposition,以及变更前后的 equivalence 结果。
关卡 5:是否满足 synthesis·STA·PPA·物理条件
功能正确的 RTL 也可能在综合后失败。常见原因包括过长的 combinational path、过度的 priority chain、错误的 clock gating、过大的 fanout 以及 memory inference 失败。
不要只给 AI 一个数字作为 PPA 目标。它可能为了缩小 area 而破坏 timing 或 testability。应先固定 constraint、library、corner 和 tool version,再同时比较以下指标。
- worst/total negative slack
- area 与 cell count
- dynamic/leakage power estimate
- congestion 与 physical feasibility
- 对 DFT 与 low-power rule 的影响
通过条件:在保持与基准 RTL 功能 equivalence 的同时,满足约定的 timing·area·power·physical feasibility 范围。
可以交给 AI 的工作与必须由人批准的工作
| Work suitable for AI | Work requiring human approval |
|---|---|
| Boilerplate RTL and testbench drafts | Architecture and state behavior |
| Candidate fixes for lint and compile errors | Warning waivers and reset policy |
| Generate candidate test scenarios and assertions | Verification-plan completeness and oracle independence |
| Regression failure classification and log summaries | Root-cause analysis and release decisions |
| Propose PPA exploration candidates | Constraint, signoff, and tape-out approval |
AI 时代更加稀缺的工程师能力
代码输入所占的比重可能下降,但以下四种能力的价值将会上升。
- 将模糊需求转换为可执行契约的能力
- 从工具日志和 waveform 中找到真正根因的能力
- 设计生成器与验证器独立性的能力
- 解释功能、性能、功耗和物理实现之间 trade-off 的能力
常见问题
Q. 可以在作品集中使用 ChatGPT 或 Claude 生成的 RTL 吗?
可以。但请展示验证证据,而不只是 prompt。应提供规范、test plan、assertion、coverage、综合结果,以及发现并修复 AI 所生成错误的记录。
Q. 如果 AI 连 testbench 都生成了,验证不就完成了吗?
不是。RTL 和 testbench 可能共享同一种错误解释。还需要独立的 reference model、protocol assertion、formal、商业 VIP 等其他 oracle。
Q. 那么 RTL 工程师的岗位会减少吗?
重复编码和日志分类所占的比重可能下降。相反,负责 spec、architecture、verification closure 和 physical trade-off 的人员将变得更加重要。岗位消失的可能性较小,责任重心发生转移的可能性更大。
Q. 可以把公司的代码输入外部 AI 吗?
如果没有公司政策和安全审批,请勿输入。RTL、constraint、log 和 waveform 可能包含产品结构与漏洞信息。必须先具备经过批准的 enterprise 环境和数据边界。
结语
“能否信任 AI 生成的 RTL”并不是一个准确的问题。更好的问题是:
无论由谁生成,是否都让它通过了相同的五道验证关卡。
氛围编程能够快速生成初稿。真正制造出硅芯片的,依然是可验证的证据。
公开来源
- Cadence ChipStack AI Super Agent
- Cadence–NVIDIA agentic AI 发布
- Cadence Conformal AI Studio
- OpenLLM-RTL 论文
- Understanding and Mitigating Errors of LLM-Generated RTL Code
- NVIDIA VerilogEval 代码库
编辑说明:本文对身边反复听到的匿名疑问进行了归纳。未使用可识别具体个人或项目的非公开信息,并将供应商披露的性能数据明确标注为供应商主张。