刚听到“用AI写RTL”这句话的时候我第一反应是终于可以不用自己手敲verilog了。可真等自己在项目里跑了一轮下来我才明白那句话背后的意思——第一批用AI写RTL的人快被折腾疯了。芯片设计行业里RTL是硬件描述语言的核心是芯片逻辑设计的源头AI在通用代码领域可以写出看起来像模像样的软件代码可一旦到了RTL这里画风就完全不一样了。我身边好几个做数字IC设计的同事都说会拿AI辅助写点模块但问起来几乎人人都有被坑过的经历有人把状态机写到死锁有人综合出来组合逻辑环还有人因为复位风格不对导致DFT插复位失败。这些坑单看都不大但每一个都实实在在地吃掉了一到两天的时间。这篇博文就是记录我从“AI好厉害”到“AI把我折腾疯了”再到“终于摸索出一套能用的工作流”的全过程涉及的RTL基础、AI协作思路、时序和复位那些让人头疼的细节我都会尽量讲透希望能帮正在尝试或者准备尝试用AI写RTL的同仁少走点弯路。1. 为什么RTL不是AI的舒适区——先搞清楚问题在哪1.1 RTL和普通代码差的不只是语言AI写普通软件代码之所以看着很厉害是因为软件世界里的规则相对统一函数调用、循环、异常处理这些东西有大量公开资料可以学习。RTL则完全是另一个世界它描述的是硬件电路是真正在硅片上并行跑起来的东西。我第一次让AI写一个简单的FIFO时它给出的代码语法完全正确用always块也像模像样乍一看毫无问题。但真正放进综合工具里问题立刻暴露出来——某个信号在组合逻辑路径上生成了一个本不存在的锁存器这个锁存器在综合时会产生警告甚至报错。软件代码里你写个if不加else可能只是逻辑不完整RTL里不加else就会综合出锁存器这是硬件设计独有的坑。AI在训练时看过无数RTL代码但它并不会真正理解“这段代码会被综合工具转换成门级网表”这件事它只是在模仿文本模式。更关键的是RTL设计讲究并行和时序。软件里的语句是顺序执行的RTL里每个always块并行触发信号赋值还分阻塞赋值和非阻塞赋值。AI经常把这两种赋值混用写出在仿真里没问题、一到综合就行为异常的代码。这种错误不是语法错误而是语义层面和硬件实现层面的偏差LLM再强大也难以靠训练数据彻底规避。1.2 AI写RTL时最典型的“幻觉”通用AI圈子里很爱提“幻觉”这个词就是模型一本正经地编造看似合理实际错误的内容。在RTL领域这种幻觉会以极其隐蔽的方式出现。我自己遇到最多的第一类幻觉是状态机编造状态。让AI生成一个简单的UART接收状态机它会给每个状态编一个华丽的命名甚至画出一套带多个嵌套分支的转移逻辑看起来结构很清晰但你仔细检查就会发现其中两个状态根本不可能到达还有一条转移路径在同一时钟周期内同时改变了两个状态寄存器的值这在真实硬件里是要闹出大事的。仿真也许能跑通某几条路径一到覆盖率统计的时候你会发现那些所谓的“保护状态”永远进不去可代码里又确实写了一大堆逻辑白白浪费面积和功耗。第二类幻觉是跨时钟域处理。AI非常喜欢在两个不同时钟域的模块之间直接打拍同步却完全不考虑信号本身是不是脉冲信号、需不需要握手、CDC结构符不符合项目规范。它甚至会在同一段代码里混用posedge clk_a和posedge clk_b的触发逻辑这在RTL静态检查里直接就是违规。真实芯片设计里跨时钟域处理是重中之重如果只是打两拍就能解决那CDC工程师早就失业了。第三类幻觉是“自我感动式”的注释和断言。AI会生成大量看起来专业感十足的注释比如“此处防止亚稳态传播”但代码里根本没有做任何防止亚稳态的处理。它还会写一些断言看起来像模像样实际触发条件写错永远不可能失败。如果你把这些断言当成验证依据那你的验证环境就是一个定时炸弹。1.3 可综合性、DFT和规范是绕不过去的三道坎RTL不是写给人看的是写给综合工具、仿真工具和其他工程师看的。这里面有三个绕不过去的坎AI如果没有被明确约束几乎必然踩中。第一道坎是可综合性。可综合RTL是指综合工具能把它映射成标准单元网表的代码风格像always (*)里不能有initial循环次数必须是编译期可确定的不能用动态内存分配。AI经常写一些在仿真库能跑、但综合工具完全不认的代码比如用fork和join来模拟并行行为这在SystemVerilog测试平台里是合法的但如果在可综合模块里出现综合工具直接翻脸。第二道坎是DFT。DFT即可测试性设计芯片流片之后要靠扫描链和复位设计来测试制造缺陷。这里特别要强调“插复位”这个问题。DFT工具通常需要RTL里有清晰可控的复位策略但AI生成复位逻辑时经常犯两种错一种是复位信号只在部分触发器的敏感列表里出现导致DFT工具没办法把整条扫描链统一复位另一种是复位电平定义和项目规范相反比如项目规定高电平复位AI按照训练数据里的主流写法给了低电平复位然后整个DFT流程的约束脚本全部作废。网上还有一个热搜词叫“DFT插复位怎么改RTL”说明这个问题已经成了普遍痛点我在后面专门展开讲。第三道坎是公司和团队的代码规范。芯片公司几乎都有自己的RTL编码规范包括信号命名、时钟命名、复位风格、状态机写法、寄存表结构等等。AI在训练数据里学的是互联网上各种来源的混合风格和公司规范天然冲突。除非你把规范完整喂给它否则它产出的代码必然是“野蛮生长”的。越是大型SoC项目这种规范冲突带来的返工成本越高因为每个模块都要人工再审一遍等于AI帮你写的活儿你用两倍时间检查。2. 被AI折腾的三大名场面2.1 综合出来一个组合逻辑环我印象最深的一次事故是在一个总线桥接模块里。当时我用AI生成了一段ARBITER逻辑处理多主机访问输入的需求描述写得比较长AI给出了一段非常工整的always (*)代码每个分支都覆盖到没有锁存器风险仿真也通过了。真正发现问题是在综合后的形式验证阶段。工具报了一个组合逻辑环定位到这段ARBITER的反相路径上——一个信号通过两级组合逻辑反过来影响了自己的输入。在RTL仿真里这种环因为延迟设置原因可能表现正常但实际电路里它就是一个振荡源轻则功能紊乱重则芯片电流异常。排查了很久才找到根因AI在处理同一个内层判断条件时同时使用了两个命名不同但逻辑等价的中间信号一个是我让它加的req_priority另一个是它自己从上下文推断出的req_level两个信号组合起来形成了一个互相依赖的环。如果是我自己写代码绝不可能给同一个逻辑起两个名字但AI在生成代码时根本不记得前几十行里它自己定义过哪个信号于是又“创造”了一个新名字。这让我彻底意识到用AI写RTL必须做严格的代码审查尤其是组合逻辑里的信号依赖关系。2.2 时序约束AI完全不理解的“玄学”时序约束对AI来说就是玄学。RTL代码本身没有“频率”这个概念让AI去写一个高速接口模块它会默认按照最理想的情况来写组合逻辑的级数完全不管路径延迟是否满足时钟周期。我让AI优化过一段数据通路目标是5GHzAI给出一版看起来很精简的组合逻辑链用的全是行为级描述。放进综合工具里一跑时序报告显示关键路径差了整整0.2ns。为什么因为AI把三段独立的判断逻辑串联成了一条长组合链没有考虑插入流水寄存器。这根本怪不了AI它并不知道综合库里的门延迟是多少也不会主动想到跨周期打拍。这里必须强调一个核心观点时序收敛不是AI能替你解决的它甚至不能在RTL层面给你提供靠谱的预判。RTL设计者自己心里必须清楚组合逻辑到寄存器的延迟预算该拆的流水段要拆该并行的判断要并行。AI能帮你写代码但写出来的组合深度需要你自己心中有数。很多新人以为AI能“一键优化时序”这是最危险的误解。2.3 复位策略DFT插不进去的经典事故“DFT插复位怎么改RTL”这个热搜词精准描述了我们组踩过的大坑。项目里有一个模块需要做扫描链插入我们用AI生成了模块的所有复位逻辑。AI不负众望地给出了一套漂亮的复位管理代码每个触发器都接了异步复位端看起来非常规范。但当DFT工具真正开始插扫描链的时候问题来了。工具要求扫描单元在测试模式下能够通过复位端口统一初始化可AI生成的代码里部分寄存器的复位信号是经过组合逻辑处理后的衍生复位并不直接来自顶层复位端口。DFT工具在分析时发现这些寄存器的复位不可控直接把整条扫描链的报告标红表示无法满足复位要求。改起来更是噩梦。你必须在RTL层面把复位策略统一所有触发器要么都用同步复位要么都用异步复位而且还是同一个复位网络不能有的模块用异步、有的复位用同步。同时复位信号必须是可测试的测试模式下要能绕过功能复位直接由外部引脚控制。AI不具备这种全局视角它只会按照训练样本里最常见的风格去写不会主动考虑DFT约束。那次事故花了团队里一位工程师三天时间改了一百多处代码从此以后我们定下规矩复位和时钟相关的RTLAI一个字都不能碰。3. 硬核实践把AI当结对工程师而不是自动生成器3.1 整个工作流长什么样踩过足够多的坑之后我总结出一条核心原则别把AI当自动生成器把它当结对工程师。结对工程师不会直接甩给你一坨代码就完事他会先问需求、给方案、写代码、自测然后等你评审。AI在你给的上下文足够充分时也能表现出类似的行为前提是你得建一套工作流。我现在的工作流大致分五步第一步用RAG知识库把项目规范喂给AI包括公司RTL编码规范、复位规则、CDC规则、低功耗相关约束等。第二步把模块需求写成结构化的提示词明确信号接口、时钟域、复位极性、时序要求、DDL功能描述。第三步让AI生成RTL代码并明确要求在关键位置加注释说明设计意图但代码风格必须符合规范模板。第四步把AI生成的代码放进我们的回归测试环境里跑一遍包括Lint、仿真、形式化验证。第五步人工评审重点检查时钟复位、跨时钟域、状态机可达性和组合逻辑环路。这套流程下来AI并没有让我工作量减半但让我把精力从“敲代码”重新分配到“定规范和查问题”上这才是一个工程师真正的价值所在。3.2 提示词工程把RTL规范灌给AI给AI写提示词和给人类工程师写设计文档是两回事。人类工程师有默会知识你说“按照规范来写”他就懂了AI不懂你必须把它能查到的一切都写进上下文里。我常用的一段提示词模板是这样的分享给大家参考你是资深数字IC设计工程师现在要设计一个[模块名]模块。 接口规范 - 模块名xxx - 时钟clk_a500MHzclk_b250MHz异步关系 - 复位por_rst_n异步低电平复位必须直接连到每个触发器的复位端不允许衍生复位 - 信号列表请按下面表格实现 功能要求 - 描述数据通路、控制状态机、错误处理逻辑 - 状态机必须完整定义所有状态和转移条件不允许不可达状态 - 跨时钟域处使用标准两级同步器不允许在组合逻辑中直接本地跨时钟 可综合要求 - 只使用可综合的Verilog/SystemVerilog子集 - 禁止initial、fork/join、动态数组、delay语句 - always中敏感列表必须完整 - 组合逻辑中每个分支都必须有默认赋值禁止锁存器 - 非阻塞赋值用于时序逻辑阻塞赋值用于组合逻辑 输出要求 - 给出完整编码按项目命名规范命名所有信号 - 在每个模块上方用注释说明设计意图 - 注释用中文控制在合理长度这段提示词我每次都会微调但核心不变接口、复位、时钟域、可综合子集、输出规范。按理说把这些都写清楚AI生成的代码质量会高很多但依然不能掉以轻心因为AI可能在不显眼的地方偷偷用了一个没声明的信号或者在状态机里漏掉了某个转移条件。3.3 验证环节不能省仿真、Lint、CDC至少留两样有些朋友问是不是提示词写好了、AI生成的代码直接能过仿真就可以省掉验证流程我的答案是绝对不行。仿真只能验证特定激励下的行为覆盖率再高也不能保证所有场景。AI代码最危险的往往是那些看似合理的角落逻辑你自己写代码时天然会规避很多无效路径但AI不会它把每一种可能的分支都写得满满当当看起来防御性强实际上很多分支根本不会触发。所以我现在对AI生成的RTL至少会过Lint和仿真回归两项。Lint能抓到信号悬空、位宽不匹配、状态机不完备、时钟域交叉等结构性问题。仿真回归能验证基础功能。如果项目有CDC验证和形式化验证工具那更好特别是形式化验证可以直接证明状态机的可达性和死锁性质这是AI代码最需要被“照顾”的弱点。我们这个行业里有个隐形成本叫“验证的沉默成本”。AI生成的代码会让验证工作量比预期增加不少因为你不知道它会在哪个角落埋雷。你必须在验证环节投入足够多提前把雷挖出来而不是等到tapeout前的仿真阶段才崩溃。3.4 我踩坑后整理的AI写RTL协作清单经过几个月的磨合我总结了一份协作清单现在团队里新来的同学我都会让他们先看一遍严格限定AI只负责小型、独立、功能清晰的模块复杂模块拆成子模块再交给AI。时钟和复位相关的RTL一律人工编写AI只做辅助审查。状态机、FIFO、跨时钟域等经典结构必须人工评审状态转移表。所有AI生成的代码必须过Lint和仿真回归不允许跳过。如果AI给出了“看似高级”的写法比如复杂的宏定义或者多层嵌套优先怀疑它的可综合性。每次让AI改代码前先保存当前能通过测试的版本不要让它直接在前一版上打补丁。提示词里永远写一句如果某个功能你不敢确定可综合请直接说明并保持简单实现。这份清单不一定适合所有团队但它至少能帮你规避70%的AI写RTL翻车事故。剩下的30%就是那些绕不开的“人肉debug”时间。4. 三个月团队实测哪些活能交给AI哪些千万别碰4.1 真的好用的场景虽然开篇说了那么多坑但AI写RTL并不是一无是处。三个月的团队实测下来有几个场景AI确实能稳定提高效率。第一个是寄存器配置类代码。比如SPI配置寄存器、AXI-Lite寄存器堆、中断状态寄存器这类代码结构固定、命名规律、位域定义清晰AI只要拿到一张寄存器表就能生成结构基本正确的RTL。这类代码人工写起来繁琐且容易出错AI反而是强项。第二个是粘合逻辑和简单转换。比如字节序转换、位宽转换、CRC计算模块、简单的编解码逻辑这些模块功能独立、边界清晰AI生成质量不错稍微检查就能用。第三个是生成测试平台和激励。SystemVerilog的UVM环境里给AI明确要求和接口定义它写出来的driver、monitor、sequence往往比很多初级工程师写得还规整。这部分不涉及可综合问题验证本来就是用仿真软件跑AI的“幻觉”危害小很多即便错了也容易在仿真中暴露。第四个是代码注释和文档转换。AI把一段原本没有注释的RTL解释清楚并按照公司模板生成模块级文档这个能力非常实用至少能帮我们省出半天时间。4.2 千万别碰的场景反过来有几类场景我们明确禁止使用AI生成RTL。第一时钟树和复位树相关代码。时钟门控、复位同步器、异步复位同步释放电路这类代码直接影响芯片的可靠性和DFT必须由资深工程师逐行手写。原因前面已经讲了AI不懂全局复位策略更不懂DFT要求。第二复杂状态机和协议控制。比如AXI协议的主从状态机、DDR控制器的命令调度状态机这类模块的状态存在大量时序交互和异常处理AI生成的状态图看着完整实际可达性分析很容易出问题。一旦流片回来才发现状态机BUG代价是以百万美元计的。第三和时序预算紧密相关的数据通路。比如高速SerDes的收发数据通路、CPU流水线控制逻辑这些地方的关键路径延迟必须靠人工精心设计AI生成的组合逻辑深度完全不可控很可能直接让时序收敛失败。第四低功耗相关的isolate、retention、level shifter控制逻辑。这些逻辑牵扯UPF文件、ISO单元、电源域切换AI不仅不懂这些还会生成一些“看起来像低功耗”的伪代码。4.3 RTL评审清单AI代码过检必查项不管AI在哪个场景帮了忙评审这关绝对不能省。我列了一个AI代码过检必查项每个细项都是踩坑换来的检查项具体内容后果复位连接每个触发器复位端是否正确连接是否有衍生复位DFT失败、复位不可控敏感列表always块敏感列表是否完整是否包含多余信号仿真与综合不一致阻塞/非阻塞赋值时序逻辑是否全用非阻塞组合逻辑是否全用阻塞仿真行为异常、综合警告组合逻辑闭环是否存在信号不经过寄存器自己影响自己的路径综合出振荡环位宽匹配所有运算和赋值是否做了位宽对齐扩展数据截断或符号错误状态机完备性是否有默认状态、是否可到达所有状态、是否有死锁功能异常、覆盖率难收敛跨时钟域结构是否使用标准同步器/异步FIFO亚稳态风险可综合性是否有initial、fork/join、delay、动态数组等综合直接失败命名规范信号名、模块名、前缀是否符合团队规范可读性差、集成困难覆盖率空点是否存在永远无法触发的分支验证效率低、隐藏风险这张表我打印出来贴在工位上每次评审AI代码时一键对照。老实说一开始每次都能查出好几个问题现在随着提示词优化问题数量在逐步下降但依然没有一次是“零问题”直接通过的。5. 常见问题与排查实录5.1 AI为什么总爱写满触发器有朋友吐槽AI生成一个简单的计数器结果给它写了一个32位宽的计数器每拍都判断是否等于某个值再置零功能没错但面积和功耗白白翻了一倍。这是AI非常典型的“过设计”倾向。原因在于训练数据里大量的工程师会采用“通用性强”的写法把计数位宽留得很宽把判断条件写成全量比较。AI学到了这种保守风格但它不理解你的场景只需要一个4位计数器每16拍翻转一次。面对这种情况我的建议是在提示词里明确写出位宽和计数目标甚至给出计数行为的伪代码让AI照着实现而不是自由发挥。5.2 状态机死锁怎么定位AI写的状态机多了之后最容易遇到的就是死锁。现象是仿真跑到某一拍之后某个状态就再也不变了而看起来代码里的转移条件似乎都有覆盖。定位方法我推荐两步走。第一步用形式化验证工具做可达性分析直接列出每个状态在约束条件下是否可达、是否存在所有状态都无法跳出的死区。没有形式化工具的话就用最笨的办法在仿真里把状态寄存器的值拉出来遍历所有跳转条件逐个排除。第二步检查状态机的默认分支AI经常把默认状态设成一个“保留状态”但实际上永远无法跳转到正常流程这就是死锁陷阱。说到底状态机的本质是一个反馈系统任何一步转移到你没想到的死区系统就再也回不来了。AI生成的代码尤其容易出现这种情况因为它总是想把所有防御性分支都画满结果反而把系统复杂化。5.3 一次完整的AI开发RTL复盘这里以一个具体的项目做一次完全复盘。项目需求是做一个AHB到APB桥的最低配模块我把它交给AI从结果来看整体可用但经历了三轮返工。第一轮AI生成的代码综合后报Latch warning原因是在组合逻辑里没有给某个分支赋默认值。第二轮仿真通过但Lint报跨时钟域违规原来AI在桥接模块里插入了一个多余的异步FIFO而我们项目这个桥根本不需要跨时钟域处理我要求的跨时钟域保护被它“贴心”地扩张了。第三轮形式化验证发现状态机存在一个不可达的保护状态于是把状态数砍掉最终才得到一版能用的RTL。整个过程大概花费了半天时间但如果我们没有完整验证流程可能直接就把不可达状态带进下个阶段了。所以我的结论是AI写RTL的效率红利真实存在但前提是团队必须有足够的验证能力和评审能力。如果你所在的团队连仿真环境都不完善那我不建议你让AI参与RTL开发否则你就是在给自己埋雷。5.4 我的安全边界建议最后说一说安全边界。我个人的建议是AI可以成为RTL工程师的加速器但绝不能成为设计决策者。时钟、复位、DFT、跨时钟域、低功耗这些关系到芯片能否点亮、量产良率的领域必须保留人工把控。模块级的小型功能、寄存器配置、测试平台生成、文档注释这些领域可以大胆交给AI并配合评审闭环。不少同行会问“那AI以后会不会取代RTL工程师”我的看法是它先能把状态机写得不死锁、把复位风格统一、把组合逻辑环问题解决掉再说。在那之前它折腾我们我们也折腾它这个过程本身就是行业技术更好用的预演。说到底所有这一轮轮的折腾都是为了让AI在芯片设计里真正落地的那天我们已经有足够经验去驾驭它。