乐于分享
好东西不私藏

AI生成RTL:四把钥匙与下一个范式

AI生成RTL:四把钥匙与下一个范式

绕过结构性瓶颈的四个方向与下一个RTL开发范式

上一篇文章AI生成RTL:瓶颈、验证与协作边界我们拆了AI写RTL的几个结构性瓶颈,包括序列模型与并发电路的架构错配、RTL语言本身的不安全性、训练数据的结构性缺失、生成结果的不可复现,以及验证侧的分布错位。问题既然已经清楚,接下来就轮到怎么开药方了。

这篇聊四个可能绕过这些结构性瓶颈的方向,或者说开发范式。每个方向都符合工程直觉与数学原理,只是工程落地的时间尺度各不相同:有的今天就能搭原型,有的可能要等下一代架构。我把它们叫做四把钥匙。

  • 从序列到图——RTL的内在结构是信号依赖图,不是token序列,用图结构做推理才是对的表征空间

  • 从描述到编译——在语义安全的高层语言里做设计,通过确定性编译生成RTL,把语言陷阱留给编译器

  • 从生成到求解——不让AI猜对答案,让求解器证明答案对,把生成和验证合成一步

  • 从代码到硬件——跳过RTL文本层,直接在硬件配置空间里搜索,用emulation做秒级闭环迭代

故事先从第一把钥匙开始。

第一把钥匙:从序列到图

思考这样一个问题: RTL的内在结构是什么?

它是一张由信号的驱动与负载关系构成的有向图。每个信号沿fanin追溯驱动源,沿fanout追踪负载,工程师在Verdi里debug一条信号路径,本质上就是在脑海中遍历这张有向图。

但这张图不是静态的。信号在哪个时钟域被采样、采样时需要满足什么约束,这些条件会改变图的拓扑结构。

举一个最常见的例子:同一个状态机的输出信号,在同一个时钟域内它的依赖关系就是组合逻辑锥里的那几个输入;但一旦它被另一个时钟域采样,就多出了一条跨时钟的依赖路径,同步器、握手信号、使能条件全部加入这张图。

同一段RTL,换一组时钟约束,依赖关系就不一样了。如果非要用序列模型来重建这张条件有向图,就是在用错误的表征空间去逼近正确的结构。能逼近,但上限有限。

既然识别了这层错配,解决思路就很自然: 问题的内在结构是图,就应该用原生适配图结构的模型来处理它,而不是强迫序列模型从文本中有损地重建图的关系。

这个想法并不新奇。图神经网络(GNN)在电路分析领域已有不少工作,包括表征学习、时序预测、功耗估计。

它的核心优势在于:序列模型只能沿着token的线性顺序传递信息,而GNN可以沿着信号的实际依赖关系传递信息,一个节点能同时感知它所有fanin和fanout的状态。这意味着并发关系不再需要被压扁成线性序列,模型直接在图上做推理,表征效率高出一个维度。

但目前这些工作有一个共同局限: 全是在分析已有电路,而不是在生成新电路。这两件事在搜索空间上有本质区别

分析是给你一张确定的图,从中读取属性;生成是在所有可能的图里找到一张满足全部约束的,搜索空间随节点数量爆炸式增长。从”看懂电路”到”在爆炸的空间里找到正确的设计”,中间还隔着一道很宽的鸿沟。要跨过去,大概率需要一个原生支持图结构生成的全新架构,短期内应该还比较难实现。

但也不一定要一步跨到对岸。一个更近的中间态已经可以想象:模型还是做token生成,但在外面挂一个图结构的工作记忆。

每一轮代码生成之后,模型调用外部的静态分析工具对当前代码做一次完整的依赖关系解析。Yosys、Slang这类分析器可以精确提取信号的驱动和负载关系,输出结构化的图描述,这一步是确定性的,不存在概率和猜测。

解析出的图关系通过MCP之类的接口注入大模型的上下文空间,模型在下一步决策时可以直接查询任意信号的上下游依赖,而不是靠自己从代码文本中推断。本质上就是给一个容易迷路的人配了GPS导航:不需要在脑子里维护整张地图,到了岔路口查一下就行。

这条路对应的是上一篇”序列生成器遇上并发电路”这个核心矛盾。中间态有清晰的工程路径,现有工具链就能搭出原型,对模块级的设计来说这条路已经走得通。

但如果想走到尽头,让AI原生具备事件驱动的并行信号追踪能力,还会撞上规模的墙。模块内的依赖图规模可控,几百个信号的fanin cone,图遍历一轮就能完成。但SoC级别的设计不是这个量级。信号穿透几十层模块边界,fanout在每一层都在扇出,依赖树的规模是指数级膨胀的。

人类工程师处理这个问题靠的是剪枝直觉: “我知道这个模块的行为,不需要穿透进去看。”

一个经过充分验证的模块,工程师会把它当作黑盒只关注它的接口时序,不去追它内部的信号依赖。这种判断看起来是经验,但背后有形式验证的原理在支撑:如果一个模块的接口行为已经被SVA或者等价性检查完整约束住了,那它的内部实现就可以被安全地抽象掉。

AI要获得同等的剪枝能力,可能需要把这层隐含的工程判断显式化,用形式化的接口规范来定义哪些模块边界可以安全截断。这件事能做,但工作量不小。

这是第一把钥匙,它解决的是AI感知并发结构的能力问题。

第二把钥匙:从描述到编译

上一篇讲过,Verilog语言本身把可综合子集和仿真语法混在一起,从仿真到综合到时序,每一层都有自己的规则,前一层通过不代表后一层没问题。问题出在语言,不在模型。

既然语言不安全,自然的想法是换一门更完善的高层语言,在语义清晰的环境里做设计,然后通过确定性的编译变换生成RTL。上半部分交给AI或工程师做设计决策,下半部分交给编译器,就不会引入概率性错误。

这条路行业已经探索了几十年。HLS是最早的大规模尝试,从C/C++出发,用编译器自动完成调度、绑定和流水线划分。但HLS在工业界始终没有真正普及开来,根本原因在于它选错了出发点:C/C++是为顺序执行设计的语言,用它描述并发硬件,编译器必须从串行代码中推断并行性。

这本质上是在用软件思维描述硬件,设计者对微架构的控制被隔在了编译器后面。结果就是代码的QoR始终跟手写RTL有差距,而且出了问题很难定位,因为编译器的调度决策对设计者是不透明的。

Chisel、SpinalHDL这类语言正是在这个背景下出现的。它们吸取了HLS的教训,不再从软件语言出发,而是用宿主语言的类型系统和函数式范式来原生表达硬件结构

设计者在Chisel里仍然显式地放寄存器、定义状态机、连接信号,微架构的控制权没有被交给编译器。生成的中间表示可以做形式化变换,编译到Verilog的过程是确定性的。在RISC-V生态里,RocketChip、BOOM、香山这些处理器核心都用Chisel完成了流片,QoR基本与手写RTL相当。

但即便如此,这些语言在工业界的渗透率仍然有限,绝大多数项目的生产代码还是手写Verilog和SystemVerilog。产业惯性、教育体系、工程师个人的学习成本都是阻力,语言范式的切换从来不是一朝一夕的事。

但除了这些现实因素,这条路上还有一个更根本的trade-off,它与产业生态无关,而是数学层面的必然难题。

抽象的本质是信息压缩。当你在Chisel里写val fifo = new Queue(UInt(8.W), 16)的时候,一行代码表达了”我要一个8bit位宽、深度16的FIFO”。简洁清晰,不容易出错。

但代价是你把满标志的输出方式、空读的保护逻辑、指针的编码方式这些实现细节全部交给了库组件的默认实现。这不是Chisel设计得不好,而是抽象本身就意味着丢弃信息。你在上层省掉的东西,要么由库的默认实现填充,要么你还是得写自己的版本把控制权拿回来。

这跟上一篇讨论形式验证时的信息论判断是同一个道理的另一面。那里说的是:当你把spec精确到机器可检查的程度,信息量就等于RTL本身,压不下去。这里说的是:当你把设计抬到高层语言,信息量必然小于RTL,丢掉的那部分就是微架构的控制权。两个观察合在一起构成一个完整的图景:设计信息有一个守恒量,你在哪一层省掉,就得在另一层补回来。

所以高层语言并没有消除微架构决策的复杂度,只是转移了它的形态。HLS把复杂度转移到了pragma配置和编译器调优上,Chisel把复杂度转移到了库组件的选择和参数化上。当默认方案不满足PPA要求时,HLS设计者要学会配置编译器的调度策略,Chisel设计者要决定是调整参数、换一个库实现、还是用黑盒接入手写Verilog。形式不同,但本质相同:抽象层级越高,你需要推翻默认决策的场景就越多,而每一次推翻都是在把省掉的信息补回来

不过,这条路的意义不只在于它自身。把设计语言从Verilog换到一门形式化更强的语言,同时也是下一把钥匙的前置条件。这个关系到了下一节会更清楚。

第三把钥匙:从生成到求解

前两条路不管怎么变,本质上都还是生成范式:AI产出一段代码,然后验证对不对。生成和验证是割裂的两步,AI写的时候不知道对不对,写完了才能检查。

上一篇的”不可复现性”和”验证越来越难”这两个问题,根源都在这里。第三条路的想法是把这两步合成一步。不让AI”写”RTL,让它”解”RTL

具体来说,把设计意图表达成一组形式化约束:接口时序用SVA描述,功能行为用参考模型描述,物理约束用面积和时序上界描述。然后让求解器去找一个满足所有约束的实现。不是一次性生成,而是在”综合、验证、反例、再综合”的闭环里迭代收敛。

这个思路在学术上叫CEGIS(反例引导的归纳综合),其数学基础是SAT/SMT求解。SAT是布尔可满足性问题:给定一组逻辑约束,能不能找到一组变量赋值同时满足所有约束?SMT在此基础上扩展到算术和位向量等更丰富的理论。本质上就是一个形式化的求解引擎,和LLM的概率采样是完全不同的范式。

这条路的直觉很朴素:不是让AI猜对答案,是让求解器证明答案对。LLM选的是”概率最大的下一个token”,求解器找的是”满足所有约束的解”。前者可能找到一个看起来对但实际上违反了某条约束的答案,后者要么给你一个被证明正确的解,要么告诉你在当前约束下无解。

如果这条路走通,上一篇的两个问题将同时消失。输出是约束求解的结果而不是概率采样的结果,同样的约束出同样的解,不存在不可复现性。而且解本身被形式化证明满足约束,验证这一步直接内化在生成过程中了。

但这条路线的瓶颈也很清楚:SAT/SMT的求解空间随变量数指数爆炸。目前CEGIS能处理的电路规模在几百个门级别,离工业设计差几个数量级。那这个限制是暂时的,等算力增长就能解决,还是根本性的?

答案是后者。SAT问题是NP-complete的。直觉上说,给你一个答案,验证它对不对很快;但从头搜索出这个答案,目前已知的所有算法都需要随问题规模指数级增长的时间。学术界几十年来的主流判断是:不存在通用的快速算法。这意味着算力翻倍,能多处理的门数只是常数级的增长,不会翻倍。这是数学定律的限制。

不过有一个关键的转折:工业界从来不是在解通用SAT。电路有结构信息:信号的fanin cone是局部的,流水级之间的约束可以分解,模块边界天然提供了切割点。现代SAT solver在这类结构化实例上的表现远好于最坏情况的理论界,这也是为什么形式验证今天已经能处理百万门级的性质检查。

那这对CEGIS意味着什么?意味着瓶颈不在”能不能解”,在”能不能拆”。把一个大模块分解成足够小的子问题,让每个子问题落在CEGIS能处理的规模内,这件事本身需要架构判断:在哪里切模块边界、哪些接口约束可以独立检查、哪些全局性质必须整体验证。这恰恰是人类架构师最擅长的工作。人做分解,求解器做求解,这才是合理的分工

换一个角度理解这件事:每增加一条形式化约束,就是在可行解空间里切掉一块,搜索空间严格缩小。约束不是限制,约束是让求解成为可能的前提。

这个道理对IC工程师来说并不陌生,SDC本质上就是一组线性不等式约束。综合器和STA分析工具在这组约束下做优化,整个时序分析流程能work的基础就是这个。从SDC约束时序到SVA约束行为,逻辑是一样的:约束写得越精确,求解器的搜索空间越小,找到正确实现的可能性越高。

所以一个更现实的折中路径是:不用CEGIS做整个模块的综合,而是把它嵌进LLM的生成流程做局部检查。LLM负责大尺度的代码结构生成,每生成一个always块,后台的SMT solver实时检查它是否违反已声明的SVA约束,违反就回退重新采样,通过才往下走。相当于给自回归生成装了一个形式化的保险杠。

这里也能看出为什么第二条路是第三条路的前置条件。你要做约束求解,约束就得用形式化语言写清楚。而在Verilog里,连”这个信号应该在时钟上升沿之前稳定10ns”这种约束都要靠注释或者另外的SDC约束文件来表达,语言本身没有一等公民级别的约束表达能力。设计语言不干净,约束就写不干净;约束写不干净,求解器就没有可靠的输入。这是一条环环相扣的依赖链。

第四把钥匙:从代码到硬件

前三条路都还在跟代码打交道。第四条路讲的是,我们为什么不换一个角度想:AI真的需要”写RTL代码”吗?

RTL本质上是一个中间表示,它存在的意义是让人类能读懂电路描述。但AI不需要读懂,它需要的是快速试错和验证。

如果把电路设计问题从”写一段描述电路的文本”变成”搜索一组让FPGA表现出目标行为的配置”,那AI的工作方式就彻底变了:不再逐行生成代码,而是在配置空间里做搜索优化。软件仿真一个case跑几分钟甚至更久,emulation可能只要几秒,速度差了几个数量级。有了这个速度,AI就可以在短时间内跑成百上千次试错迭代,用搜索代替生成。

这个问题的数学结构跟前三条路完全不同,它不是序列生成,不是图推理,不是约束求解,而是在一个离散但极其庞大的配置空间里做搜索优化。FPGA的bitstream本质上就是一张查找表配置加布线开关的状态矩阵,直接搜索这个空间跟搜索晶体管级网表一样不现实。

但跟前面几条路一样,一步到位不行,不代表中间态没有价值。如果把搜索的粒度从LUT级别抬高到功能块级别,问题就变得可解了。AI不去决定每一个LUT的真值表,而是决定“这个DMA控制器用几个通道、burst长度设多少、地址对齐策略选哪种”,然后由工具链把这些决策编译成bitstream在emulation上跑。每一次配置就是一次架构方案,每一次emulation就是一次验证,反馈回来再调配置,形成闭环。

这条路跟第二条路有一个交汇点:一个是在高层语言里描述设计然后编译到RTL,一个是在高层配置空间里做搜索然后编译到bitstream。两者共享同一个核心思想,就是把AI的工作层级抬高,把确定性的编译工作留给工具链

不过说到这里需要补一个边界。这条路加速的是设计探索阶段的试错循环,不是替代流片流程。芯片公司最终要的是可签核的RTL和网表,不是FPGA配置。在emulation上验证过的架构决策,最终还是要编码回RTL或高层语言,走完综合、后端和签核。这条路解决的是”怎么更快地找到对的方案”,而不是”怎么省掉从方案到芯片的最后一程”

还有一个更现实的问题:Emulation平台极其昂贵。Palladium、Zebu这类设备一台几千万,license按小时计费。让AI在上面跑成百上千次搜索迭代,按今天的价格不容易算过来。这条路要走通,要么Emulation硬件的成本降到足够低,类似GPU之于深度学习,从奢侈品变成基础设施;要么AI的搜索效率高到不需要那么多次迭代就能收敛。前者取决于硬件产业的演进,后者取决于搜索算法的进步。

回头看这四个方向,它们表面上各自独立,底下其实共享一个观察:RTL设计的真正瓶颈不在”写代码”这个动作上,而在”做决策”上。写代码只是把决策编码成文本,现有的AI恰恰卡在编码这一步。四把钥匙本质上都在试图把决策和编码分离,让人专注做决策,让机器负责把决策变成电路。

这些方向今天都还在路上,有的已经能搭原型,有的还停留在数学原理的层面。几年后回头看,哪些直觉被验证了、哪些被推翻了,应该会很有意思。

— END —