最近半年我一直在做一件可能有点“自找麻烦”的事把一套 IP 的研发流程彻底倒过来不是先写 RTL 再补文档而是让 Spec 本身成为设计、验证、评审的共同基线并且让生成式 AI 深度参与到从 Spec 到 RTL 的翻译和校验过程中。这套流程我暂时叫它 AI-Native IP 研发流程。说是“正在尝试”因为到目前为止它还没完全跑通但中间踩过的一些坑、沉淀下来的几条方法我觉得值得拿出来聊聊。先说结论我试到现在最深的感受是AI-Native 的价值根本不在于“让 AI 自动写 Verilog”而在于它逼着我们把 Spec 里的每一句话都变成可检查、可判定的东西。RTL 只是这条链路的一个出口。这篇文章是我这段时间的工作笔记适合正在做 IP 设计、验证并且对 AI 辅助硬件开发感兴趣的工程师参考。1. 传统 Spec 到 RTL 的断层到底断在哪1.1 自然语言的多义性是第一层损耗我在维护一个大约 5 万行 RTL 的数据通路 IP 时经常被 Spec 里的自然语言逼疯。比如 Spec 里写着“当总线空闲时FIFO 指针需要被释放”就这么一句话三个工程师能给出四种理解第一种理解是总线没有 pending 请求时就释放第二种理解是当前读操作完成且下一拍没有新请求时才释放第三种理解是只要 FIFO 空指针立即归零第四种理解更夸张直接把“总线空闲”理解成了时钟门控信号。这种多义性在真实 IP 项目里比比皆是只是大部分时候我们察觉不到因为 RTL 写出来之后仿真一跑大家默认“能跑通就是理解一致”。但实际上Spec 的歧义会潜伏到系统集成阶段才爆炸。一旦两个模块对接时对“空闲”的定义不一样debug 起来就是跨团队的扯皮谁都不认为自己错。另外Spec 里的时序图也存在覆盖盲区。时序图只能画理想情况画不出“如果 valid 和 ready 同时拉高后立刻撤掉”这种 corner case。而 corner case 恰恰是 IP 验证里最容易出问题的地方。1.2 变更传播和验证滞后是第二层、第三层损耗IP 开发里Spec 变更的传播成本高得吓人。举个具体例子如果 Spec 里把 outstanding transaction 的最大值从 8 改成 16那 RTL 里有好几处地方都得跟着改——请求计数器的位宽要从 3 bit 变成 4 bitFIFO depth 要重新核算scoreboard 里的 in-flight 数量上限要改甚至断言里的参数化常量也要同步。问题是很多团队在改 Spec 时根本没有机制把关联代码全部找出来于是总有几处漏改等到验证回归失败才发现。验证滞后的问题也很典型。大多数项目里DV 团队要等 RTL 基本稳定后才开始写 testbench因为 TB 和 RTL 强耦合。这导致一个尴尬局面RTL 写得越快Spec 里的问题反而暴露得越晚。最终回归失败的根因往往不在代码而在需求本身。1.3 所以我把切入点从“生成代码”挪到了“解析规格”传统流程里Spec 被当成一份给“人”看的文档EDA 工具和验证环境都读不懂它。直接把 Spec 扔给 AI 让它生成 RTL结果一定是灾难——因为原文本身就含糊AI 只会“自信地”把一个含糊表述随机落在某个具体语义上然后把错误放大到每一行代码里。所以我的切入点是先把 Spec 变成三层结构化基线再让 AI 在这个基线上做翻译。这就是 AI-Native 和普通“AI 辅助写代码”最根本的区别。后面几节我会详细说这三层基线怎么落地。2. 我在做的三层基线需求条目、接口参数、行为场景2.1 第一层需求条目化让每条规格都有一个身份证第一条基线是给 Spec 里的每一条需求分配唯一 ID。这不是普通的编号而是带属性标签的条目化。我自己实践下来每条需求至少要有这么几个字段需求编号、功能分类、优先级、关联模块、可验证性标记。比如说我们要做一个带 AXI4-Lite 接口的中断控制器模块。原版 Spec 里可能写着“支持独立的中断使能控制。”这句话就不能算作一条合格的需求条目因为“支持独立”这四个字没有任何可判定标准。我会把它拆成REQ-001提供 32 个中断源输入每个中断源对应 1 bit 状态寄存器REQ-002提供中断使能寄存器IER每个中断源有独立使能位REQ-003当某个中断源拉高且对应使能位置 1 时中断输出信号 INT 必须在一个时钟周期内拉高REQ-004提供中断状态清除机制写 1 清零写 0 无效。每个 REQ 后面还必须带一栏“验证方式”如果这条需求无法对应到某个断言或某个覆盖点那就说明它还没拆到位需要继续细化。等于把需求审查从“拍脑袋评审”变成了“可判定性检查”。这一层看着简单却是整个 AI-Native 流程里最耗时间、也最值得投入的部分。我做过对比以前人工读 30 页 PDF Spec提取有效需求大约要 1-2 天现在用 AI 辅助产出候选需求条目再人工逐条确认消歧半天到一天能完成。但注意决策权永远在人工手里AI 只是把“需要人拍板的地方”从一大堆自然语言里拎了出来。2.2 第二层接口参数表把“协议”变成可机器核对的清单第二层基线是接口参数表它专门处理端口和配置参数。这一步非常机械但恰恰是 AI 生成 RTL 时最容易出幻觉的地方。我维护的模块接口表大概长这样信号名方向位宽协议/时序要求来源s_axi_aclkinput1全局时钟上升沿采样REQ-010s_axi_aresetninput1异步复位低有效REQ-010s_axi_awaddrinput12AXI4-Lite 写地址通道REQ-011s_axi_wdatainput32AXI4-Lite 写数据通道REQ-011s_axi_wstrbinput4写 strobe逐字节有效REQ-012ext_irq[31:0]input32外部中断输入电平触发REQ-003int_outoutput1中断汇总输出组合逻辑直通REQ-003注意“来源”这一列每个信号必须能追溯到需求条目。这张表的作用有两个一是给 AI 生成 RTL 时当强约束二是生成之后做反向 diff 的依据。我把这张表直接粘贴进 prompt并明确要求 AI“不允许新增、修改、删除任何端口”。后面会讲到即使加了这条要求AI 还是偷偷加过信号所以光靠 prompt 不够还得靠脚本硬校验。2.3 第三层行为场景表把模糊描述变成可判定的条件第三层基线是行为场景表。它解决的是“状态机怎么走”“异常情况下怎么办”“握手时序怎么保证”这一类问题。原始 Spec 可能写的是“当读取一个无效地址时模块应该返回错误响应”这算是一个场景但不够精确。细化之后的行为场景表应该是场景 IDSCN-005触发条件AXI4-Lite 读请求访问地址位于未分配寄存器区间期望行为AXI 读通道返回 SLVERR2b10读数据为 0完成时间必须在 1 个 ACK 周期内返回不允许延迟超过 2 拍对应断言assert_read_error_on_invalid_addr还有对状态机的描述。给 AI 的 prompt 里我通常会把状态转移写成非常机械的文本状态 IDLE当 !req_empty 时跳转 READ否则保持状态 READ采样地址产生读数据跳回 IDLE任何状态下复位信号拉低无条件回到 IDLE。你可能会觉得这跟直接写 RTL 没什么区别了。但区别在于这份行为场景表同时还能用于生成断言、生成覆盖点、生成验证计划。它是人和 AI、人和验证环境之间共享的中间语言。这才是 AI-Native 里“Native”两个字的价值——不是让 AI 适配我们而是我们把工程资料重构成 AI 和工具都能真正读懂的形态。3. AI 干活时我最看重的三个 RTL 约束3.1 接口表是唯一端口来源禁止 AI 发明新信号把三层基线准备好之后我会让 AI 逐模块生成 RTL。这里有个我踩过好几次的教训如果不给强约束AI 会自作主张地加“辅助信号”。有一次我只是让 AI 生成一个中断控制器的寄存器读写逻辑它居然在模块端口列表里加了一个 1 bit 的输出信号debug_capture_en。这个信号 Spec 里完全没有接口表里也没有代码里也只用了一处像模像样地接到了一个内部寄存器的输出上。如果直接拿去综合这个多余端口会一路传到顶层集成最后免不了要改好几层布线。所以后来我养成了一个习惯任何 AI 生成的模块第一步不是看代码而是用脚本核对端口。我一般用一段 Python 脚本快速解析生成的 Verilog 端口再跟接口表比import re, sys def extract_ports(filepath): with open(filepath) as f: text f.read() # 简单提取 module 端口列表真实场景建议用 yosys/verible 做 AST pat re.compile(rmodule\s\w\s*#?\(?.*?\)\s*\(([^)]*)\)\s*;, re.S) m pat.search(text) if not m: return set() ports set() for line in m.group(1).splitlines(): line line.strip().rstrip(,) if not line: continue token line.split()[-1] ports.add(token) return ports spec_ports {s_axi_aclk, s_axi_aresetn, s_axi_awaddr, s_axi_wdata, s_axi_wstrb, ext_irq, int_out} rtl_ports extract_ports(interrupt_ctrl.v) print(Missing:, spec_ports - rtl_ports) print(Extra:, rtl_ports - spec_ports)这个脚本不到 20 行但实测下来帮我们抓到了至少三个 AI 生成的“幽灵端口”。注意真实项目里端口数量多、参数化复杂脚本要做得更严谨但思路就是这么个思路——接口表是唯一真相源AI 生成之后必须接受机器校验。3.2 时钟复位与代码风格提前锁死AI 生成的 RTL 里时钟复位风格不统一是第二大问题。同一个模块里它可能给一部分寄存器用异步复位给另一部分用同步复位然后复位极性还不一致。这在功能仿真阶段通常不会暴露因为仿真模型的复位行为可能都被统一处理了但到了 FPGA 原型或流片前检查阶段综合工具会报一堆 synchronizer 或 reset 相关的 warning。我在 prompt 里明确规定四件事复位风格统一为异步复位、低有效所有跨时钟域信号必须经过专用同步器模块不允许直接打拍不允许出现initial块组合逻辑必须写在always_comb里时序逻辑必须在always_ff里。还有一个细节命名风格。很多团队对信号命名有严格要求比如端口信号用s_axi_前缀内部寄存器用r_前缀wire 用w_前缀。这些约束不需要程序员逐条叮嘱直接写进 prompt 的 style guide 段落即可。AI 在遵循明确命名规则方面表现得相当好至少比我见过的一些外包 RTL 更守规矩。3.3 用“模块级小循环”代替一次性生成最开始我试过一次让 AI 直接生成整个 IP 的 RTL几千行代码哗啦一下全出来看起来有模有样。但 review 时根本看不过来而且一旦有一个接口约定理解错后面整片代码都要返工。现在我把流程改成“逐模块生成 人工 review 模块级 testbench 循环”。一个模块大概一两百行到几百行 RTL生成速度快review 难度低发现问题也能精准定位。我把每次 review 提出的问题整理成“风格注记”追加到后续 prompt 里等于让 AI 在同一个项目的上下文里持续学习。举个例子第一次生成时AI 把寄存器读回路径做成了“读时锁存”需要两个周期才能返回数据。我告诉它本项目要求读操作在地址采样后一拍内返回。第二次生成时它就修正了。这个小循环跑下来每个模块大概经历三轮左右的质量调优最终代码与其说是 AI 写出来的不如说是 AI 和我共同改出来的——它的第一版打底我的 review 意见逐条推翻重来。4. 从 RTL 反向打回 Spec校验闭环才是 AI-Native 的重心4.1 端口和参数 diff把 RTL 和基线对齐AI 生成完 RTL 之后我以为最重的活已经干完了其实没有。有一次自动生成的代码在功能仿真里跑得非常好但我在反向检查接口参数时发现AI 把寄存器基地址偏移量的 4 bit 参数悄悄改成了 5 bit代码里所有地址译码逻辑都跟着变了。仿真为什么过了因为 testbench 用的也是同一个参数化版本两边一起错仿真当然全绿。这就是为什么反向校验不能只靠仿真。我现在每次生成完 RTL除了端口比对还会做参数表比对参数名、位宽、默认值、是否可配置全部跟基线表格对齐。这个步骤用脚本半自动完成参数信息从代码里提取出来后和 Spec 基线文件做 diff任何差异都人工确认后才允许继续。4.2 用断言和覆盖点承接 Spec 场景RTL 生成的输出只是流程的一个中间产物。真正让 Spec 的价值流动起来的是把行为场景表转成 SVA 断言和覆盖率模型。拿前面那个中断控制器举例。REQ-003 的期望行为是“当中断源拉高且使能位置 1 时INT 在一个时钟周期内拉高”。这个需求转化为断言就是property irq_assert_speed; (posedge s_axi_aclk) disable iff (!s_axi_aresetn) (ext_irq[0] ier[0]) | int_out; endproperty assert property (irq_assert_speed);类似这种“Spec 场景表到 SVA 断言”的翻译AI 做得很好因为场景表已经把语义约束拆到了足够细的颗粒度。这比让 AI 直接凭空写断言靠谱得多。同时我会为每条需求建立一个功能覆盖点确保验证回归不是只测代码覆盖率。比如“写 1 清零”这个行为必须通过 functional coverage 确认覆盖到了“状态寄存器位为 1 时写入 1”和“状态寄存器位为 0 时写入 1”两种情况。否则代码覆盖率可能是百分之百但关键功能分支根本没被激励到。4.3 当 RTL 和 Spec 不一致时先问谁是对的这是反向校验流程里最容易被人忽略但最考验工程师判断力的环节。RTL 和 Spec 不一致不一定是 RTL 错了。有一次AI 生成的中断控制器把“读状态寄存器后自动清中断”实现成了“读操作对状态位做清除”而 Spec 基线里明明是“写 1 清零”。刚开始我以为是 AI 理解错需求后来翻看代码发现团队之前某位同事在讨论记录里提出过“读清零可以避免 SW 额外写一次寄存器”这个提议当时没被采纳到正式 Spec 里。也就是说RTL 实现了一个更合理的版本但 Spec 没跟上。这种情况下正确的处理不是改 RTL而是把 Spec 升级。我在流程里专门加了一步反向校验发现不一致时由设计负责人判定 RTL 和 Spec 哪个才是“意图”如果是 RTL 修掉了 Spec 的 bug那就反向把 Spec 更新到新版本。这个过程保证了基线文档永远是可交付的状态而不是越漂越远。5. 踩坑实录AI 编造端口、latch、以及它自认为的“合理优化”5.1 编造端口AI 加了 debug_capture_en前面提到debug_capture_en的事我再补充一下细节。那次我检查端口脚本只花了不到一分钟但如果没有这一步这个端口可能要到后端集成阶段才会被发现。它造成的实际成本远不止改一行代码而是要重新综合、重新跑时序约束甚至可能影响 pin 规划。从这之后我给自己定了一条铁律AI 生成的 RTL不经过程序化接口比对坚决不进入下一步。5.2 状态机漏 default 导致的 latch第二个常见坑是状态机没有 default 分支。AI 生成的状态转移代码如果漏掉 default综合工具会推断出一个锁存器。功能仿真阶段因为状态向量初值为 0恰好落在已经定义的状态上所以仿真结果看起来正常。一旦状态受到干扰或者初始化顺序变化行为就完全不可预测。这个坑的排查成本也不低。我在 lint 阶段用工具检查出 latch 警告后第一反应是检查自己写的 prompt 里有没有强调“所有状态机必须包含 default 分支”。答案是没有。后来我干脆在 style guide 里加了一条固定规则“凡涉及状态机的模块必须显式写出 default 状态且 default 必须回到 IDLE。”就这么一个简单约束后面生成的模块再没出现过 latch 问题。5.3 “合理优化”是最大的隐性风险比端口幻觉、latch 更危险的是 AI 自作主张的“合理优化”。有一次Spec 要求写操作支持按字节 strobe即wstrb[3:0]为 0 的字节不能被写入。AI 生成的代码初看完全正确但仔细跟踪后发现它把wstrb的语义给改成了整字写入——也就是无论 strobe 什么样只要写请求有效就整 32 bit 写进去。它为什么要这么改因为从代码行数上看“更简洁”从功能角度上看某些场景可能“更高效”。可问题在于这违背了 Spec 的协议要求后续挂上真实外设时行为就是错的。这种逻辑层面的偏差靠端口比对、语法 lint 都查不出来只能靠断言和覆盖率。我后来专门给写数据路径加了断言如果wstrb[0]0则写操作不能改变reg_bank[0]对应字节。这类断言把协议要求固化在仿真环境里。可以说在 AI-Native 流程里断言的数量比传统流程多出一截但这恰恰是我们用 AI 提效之后必须补上的安全网。6. 当前边界和下一步我想做的事6.1 流程现在的边界在哪目前这套流程能稳定处理的是模块级 RTL大概几百行到两三千行的规模。再往上走到子系统集成阶段我还没有完全跑通原因在于跨时钟域约束、物理设计反馈这些环节还没能和 Spec 基线形成闭环。AI 可以把 RTL 写得像模像样但它对“综合后时序满足不了时到底是改 RTL 结构还是改 Spec 指标”这种工程权衡基本没有判断力。另外必须说清楚这个流程不是取代验证工程师的。UVM testbench、formal verification、系统级回归这些东西依然是人工主导AI 只是把验证计划和断言骨架准备得更快。目前覆盖率收敛这件事还是得靠有经验的 DV 工程师去布局。6.2 下一步基线升级成可执行的验证资产我下一步想做的是把三层基线自动转换成验证资产从需求条目生成验证计划vplan从接口参数表生成寄存器读写测试模板从行为场景表生成 scoreboard 的参考逻辑。理想状态下Spec 改一个参数RTL、断言、覆盖点、测试模板全部同步更新这样 IP 团队才真正摆脱“文档归文档、代码归代码”的碎片化状态。这个目标的难度不小但方向我认为是对的。我还会继续走这条路因为退回到纯人工去对 Spec 和 RTL 的老路面对越来越复杂的 IP 需求效率上确实撑不住。最后说一点个人体会吧。AI-Native 听起来很酷但做下来会发现最难的部分根本不是 RTL 生成而是把人的模糊想法逼成一个可以机器检查的参考基线。这个工作没有捷径但一旦做扎实后面每一步都是顺的。与其说 AI 帮我们写了代码不如说它逼着我们把自己的设计意图想得更清楚了。这一点可能是这套流程对我个人最大的价值。