最近某家海外大型科技公司公开了一份关于“AI-native芯片设计”的研究报告核心观点很直白让大模型直接从自然语言描述生成RTL代码这件事就是芯片设计领域最稀缺的能力。我完整读下来之后反而觉得不太一样。能生成RTL当然重要但如果你把“AI-native芯片设计”等同于“大模型写Verilog”那很可能把整个范式看窄了。真正稀缺的从来不是那一段可综合代码而是围绕这段代码的数据、闭环、约束理解和评测体系。这篇文章我就以自己这几年做AI辅助EDA和处理器前端设计的实际体验谈三点不同看法也聊聊到底哪些能力最值得投入。1. 先搞清楚AI-native芯片设计和我们以前说的“AI辅助设计”差在哪1.1 传统AI辅助EDA的尴尬过去十年芯片设计领域其实一直在用AI但大家说的“AI辅助EDA”和“AI-native”完全是两码事。传统的做法是在EDA工具链的某个节点上嵌入一个机器学习模型比如用图神经网络预测关键路径的时序违规用强化学习做布局布线优化或者用回归模型估计模块的功耗。这类工具的特征是整个设计数据流还是人类工程师在驱动RTL由人来写综合、布局布线、静态时序分析、物理验证都是既有的工业流程AI只是在某个环节充当一个更聪明的启发式算法。说白了它解决的还是传统设计里“某个优化子问题收敛太慢”的痛点没有改变设计流程本身的形态。所以我一直觉得传统AI辅助EDA很像汽车上的定速巡航而AI-native更像是从设计一个汽车转向设计一套自动驾驶系统。前者的目标是让某个指标变好后者的目标是让一段人类描述变成可流片的硬件中间几乎所有决策都由AI参与。1.2 AI-native范式的本质变化所谓AI-native芯片设计核心不是“用AI改善某个EDA工具”而是把模型当作设计流程里的一等公民。整个流程的数据流从“工程师写RTL→工具链处理→签核”变成“工程师提供高层规格和约束→模型生成设计表示→自动验证和反馈→模型迭代设计”。这个变化最关键的变量是设计意图的表达方式变了。以前我们用SystemVerilog来精确表达微架构现在我们希望计算机能理解自然语言描述、伪代码、架构约束并自动映射到可综合的硬件描述。这不是在EDA链路上多一个插件这是把整个芯片前端设计重新拆解成了“理解规格”“生成设计”“验证设计”“反馈修改”四个AI可参与的环节。我去年参与过一个小型处理器核的重构项目当时团队想试用开源大模型直接生成一个指令译码模块。结果发现单看模块代码生成质量真的不差但如果把它当作一个AI-native流程去看模型给出的RTL往往无法通过覆盖率收敛边界条件处理也存在大量盲区。这说明一个很现实的问题生成RTL只是入口入口背后是一条完整的、由数据、验证和反馈构成的环形通路。没有这条通路AI生成的代码就是一堆“看起来很像硬件”的文本。1.3 为什么大家的注意力都集中在“生成RTL”上行业注意力高度集中在“大模型写RTL”这件事原因其实不复杂。RTL是芯片前端设计人力最密集、最容易被量化的环节它也是所有后续后端流程的固定输入。你让模型生成一段可综合的Verilog发给综合工具立刻能跑到时序报告和面积报告效果非常直观也适合做技术演示和宣传。但这里有个陷阱。就像自动驾驶分级一样模型能生成一段“可以仿真的RTL”并不等价于“能够承担设计责任”。真正的检验标准非常简单这段RTL能否在随机测试和定向压力测试下证明功能正确能否在不违反设计约束的情况下收敛到目标时序能否在物理实现时不给后端团队埋一堆雷。我经常打一个比方一个大模型能写出一篇语法通顺的技术文档不代表它理解文档所描述系统的运行逻辑。同样地模型能生成一段长得像RTL的文本不代表它理解流水线冲突、写后写相关、跨时钟域同步这些真实硬件问题。把“生成代码”当稀缺能力就像把“会打字”当稀缺技能这是对问题层级的一次降维误判。2. 真正稀缺的第一项能力高质量数据集与验证闭环2.1 模型训练最难的不是算法是“数据从哪来”现在公开可用的RTL代码量跟自然语言语料相比小到可以忽略。GitHub上能爬到的RTL项目大多来自教学实验、开源IP核和小型业余项目真实工业级设计的RTL通常是不公开的。即便在一个公司内部不同项目组之间的RTL风格、接口协议、约束体系也相差很大很难直接拼成一套训练语料。更麻烦的是光有RTL没有用。AI-native芯片设计需要一个完整的“规格-实现-验证”三元组一段自然语言或伪代码描述的规格一段对应的RTL实现一组覆盖了功能边界的测试约束和断言。这三样东西缺一不可。你只给模型一堆RTL代码它学到的是代码风格和功能语义的模糊映射却学不会“一段规格如何被验证需求约束”。我在实际做数据准备时发现工业界真正有价值的不是那些RTL本身而是RTL伴随的验证计划、覆盖率报告和缺陷修复记录。一个模块最初版本是什么样出了哪些bug工程师怎么改验证环境怎么收敛这些过程数据才是AI理解“设计正确性”的黄金教材。2.2 黄金数据的三层结构我建议把AI-native芯片设计训练数据分成三层每层解决的问题完全不同。第一层是“自然语言或伪代码到RTL”的映射数据。这一层的数据主要训练模型理解规格描述、指令集语义、接口时序输出可综合RTL。这层数据相对容易积累因为很多旧项目的文档里都残留着模块级的规格说明。第二层是“RTL到验证环境”的映射数据。一条RTL对应一组testbench、系统Verilog断言、覆盖率收集配置。这一层的数据非常稀缺因为验证工程师写的代码很少被当作“语料”保存下来它们更像是工程产物而不是资产。第三层是“RTL到物理指标”的回归数据。一份RTL经过综合、布局布线之后得到面积、功耗、关键路径延迟以及这些指标随约束变化的趋势。这一层数据是模型理解“可综合性”“时序可收敛性”的关键支撑。芯片设计之所以不能用通用代码生成模型直接解决很大程度就是因为通用代码的“正确性”是逻辑层面的而芯片设计的“正确性”还包括物理层面的可实现性。这个三层数据形成了AI-native芯片设计的燃料链。没有第一层模型不会写硬件没有第二层模型不知道什么叫“验证充分”没有第三层模型无法理解性能和功耗的代价。当前公开研究大多卡在第二层和第三层这也是为什么很多demo看起来惊艳却始终无法进入真实流片流程。2.3 验证闭环比生成能力更稀缺我在前文反复提到闭环这里展开说。一个真正可用的AI-native芯片设计流程应该包括三个角色生成器、检查器、回归环境。生成器负责把规格转换成设计候选检查器负责对候选设计进行静态和动态检查包括语法检查、可综合性检查、断言仿真、形式化验证回归环境负责把测试结果、覆盖率数据、时序报告结构化地反馈给生成器驱动下一轮生成。三者之中生成器反而是最不稀缺的。因为大模型技术是通用的任何一个团队都能通过微调得到一个“能写RTL”的模型只是质量高低不同。真正难的是检查器和回归环境。检查器需要工业级验证工具链的深度集成回归环境需要把EDA工具输出变成模型可以学习的结构化信号。以覆盖率反馈为例。如果模型生成一个模块测试平台跑完之后给出65%的覆盖率模型需要知道“到底是哪些用例没覆盖到”“哪些分支状态没进入”“是因为生成代码漏了逻辑还是因为生成的testbench漏了激励”。这些信息要经过一层转换变成能够指导下一次生成的自然语言或向量表示。这个转换流程没有现成工具能做需要芯片验证团队和机器学习团队一起从零搭建。我见过很多团队在“生成RTL”上投入大量精力却忽略验证闭环。结果就是模型生成的代码在demo工程里跑得很漂亮放到真实项目中一个随机化测试就跑出一堆协议违规。这背后的原因不是模型“不会写代码”而是流程里缺少“知道自己错了”的机制。2.4 实操中怎么积累这类数据如果你的团队想入局AI-native芯片设计我不建议一上来就训练大模型。最务实的起点是“验证资产结构化”。具体做法是把过去几年所有IP模块的bug报告、RTL修改记录、回归测试用例、覆盖率报告收集起来整理成结构化的数据仓库。每个数据项至少包含四个字段原始规格片段、缺陷RTL、修复后的RTL、触发缺陷的测试向量。这个过程听起来很笨但它有两个好处。第一它让团队对“AI-native需要什么样的数据”有了具体的感知而不是停留在概念层面。第二它提供了一个高质量的微调数据集哪怕规模不大也足够让模型学会“哪些写法容易在验证中出问题”。等到这个数据仓库积累了七八个月再开始尝试用开源模型做微调你会发现模型学到的远远不仅是“写代码”它学会了“避免常见缺陷”“遵循验证友好风格”。这比堆算力去训练一个通用代码模型的收益大得多。3. 真正稀缺的第二项能力系统级架构理解的可执行表达3.1 芯片设计的本质是跨层次稠密约束传播芯片设计和普通软件开发有一个根本区别软件的正确性主要停留在逻辑层芯片设计的正确性必须同时跨越架构层、微架构层、逻辑层、电路层和物理层。任何一个层次的决策偏差都会向下游传导而且越晚发现修复成本越高。我举一个例子。某个AI加速器项目早期的关键决策是“采用统一MAC阵列还是专用DSP单元”。这个决策涉及到工作负载分析、带宽估算、面积预算和能效目标。如果决策错了即使RTL写得再漂亮整个芯片的PPA也是偏离目标。而这一决策恰恰是通用大模型最不擅长的部分因为它不是一个“文本到文本”的翻译问题而是一个“从高度非结构化需求到高维设计空间”的搜索问题。所以我说系统级架构理解的可执行表达比RTL生成能力稀缺得多。模型只有具备“理解工作负载特征→分解为架构约束→映射到微架构模板→评估PPA影响”这一链条的能力才能真正融入芯片设计的前端流程。3.2 架构探索中AI能发挥作用的三个点结合我接触过的项目我认为AI在架构探索层面有三个切入点最值得投入。第一个是工作负载感知。现在的AI芯片设计起点往往是一批PyTorch或TensorFlow模型这些模型的计算图、算子类型、张量形状、访存模式决定了硬件架构的长相。传统做法是工程师手工跑profile再凭经验挑选代表性工作负载。如果能让模型自动从网络结构和工作负载特征中生成“硬件设计需求摘要”架构探索就会快很多。第二个是设计空间探索。给定一个加速器架构模板参数空间可能包含MAC阵列大小、缓冲深度、流水线级数、内存端口数、调度策略等。组合爆炸非常严重传统方式靠专家经验加随机搜索。AI可以基于前面提到的第三层数据学习“参数组合到PPA”的映射用代理模型指导迭代搜索效率高一个数量级。第三个是约束生成。系统级指标比如端到端延迟小于5微秒能效达到10TOPS/W需要通过分解变成RTL级的约束例如时钟频率目标、流水线深度限制、内存带宽上限。这个过程以前靠架构师手写拆解现在有机会靠模型自动生成候选分解方案。这三个点都指向同一个方向AI解决的不是“用Verilog描述一个已知架构”而是“在巨大设计空间里找到那个值得用Verilog描述的架构”。3.3 把系统知识变成可学习任务的方法有些人会说架构设计是艺术很难让AI学会。我承认架构设计里有很多经验成分但经验并不等于不可建模。我自己尝试过一种比较有效的方法叫“参数化模板加约束生成”。具体来说团队会预先定义一套可配置的微架构模板比如输入缓冲区、计算阵列、累加器、输出缓冲、控制状态机。模板里的每个维度都有离散选项。模型的任务不是从零写RTL而是从模板的配置空间中选择一组参数并说明选择理由再由模板自动化生成RTL。这样做有三个好处。第一它把系统级知识的范围缩小到“架构参数选择”问题更容易学习。第二它天然是可综合的不会像开放生成那样产生一堆不可综合的代码。第三它保留了工程师对架构方案的审查能力模型给出配置工程师检查配置是否符合设计意图形成人机协作闭环。这个思路的实验效果我不说有多惊艳但至少比让模型自由发挥“设计一个AI加速器”要实用得多。对大多数芯片设计团队来说“受约束生成”远比“自由生成”接近落地。4. 真正稀缺的第三项能力面向AI-native流程的评测基准和领域EDA工具4.1 没有可信的评测AI-native芯片设计就是空中楼阁任何一项AI技术如果没有可靠的评测方法就只能停留在demo阶段。芯片设计领域尤其如此。我们不能拿“代码能编译”当标准因为RTL能编译、能仿真和它能流片、能signoff之间差着十万八千里。通用代码生成的评测基准比如函数级代码补全、单元测试通过率对芯片设计来说完全不适用。芯片设计的正确性不是“单点逻辑正确”而是“功能正确、可综合、时序可收敛、功耗可接受、验证覆盖率达标”五重标准的交集。我在团队内部尝试搭建一套分层评测体系分别对应三种能力。评测层输入输出通过标准L1 模块级RTL生成自然语言规格、接口定义、时序约束可综合RTL语法检查通过、仿真结果与参考模型一致、逻辑综合无严重违例L2 验证闭环能力模块规格和不完整验证环境完整RTL与配套testbench/断言回归测试全通过覆盖率超过指定阈值能定位并修复单个缺陷L3 系统级架构探索工作负载描述、PPA目标、工艺库信息候选架构配置与PPA估算配置可映射到RTL模板PPA估算收敛到目标范围与人工基线对比不差于指定比例这套体系的重点不是“考倒模型”而是让模型的每一次迭代都能通过量化指标反映出来。有了这套评测团队才有底气说“我们的AI-native流程提升了设计效率”。4.2 领域EDA工具链为什么严重缺位AI-native芯片设计另一个被低估的缺口是“面向模型的EDA工具接口”。传统EDA工具的使用对象是工程师交互方式是人通过图形界面或脚本操作。AI-native流程里模型要跟工具链进行大量自动化交互生成阶段调用综合器做粗略评估验证阶段调用仿真器采集覆盖率迭代阶段把工具的反馈转换成下一个prompt。现在的EDA工具大多没有为这种“程序化、可批量、短时延、语义化反馈”的调用方式准备接口。我举个具体例子。模型生成RTL之后团队想让它知道综合报告里关键路径长度和扇出数量。现有综合工具能输出文本报告但这份报告是给工程师读的不是给模型读的。你需要额外写一套解析器把文本报告转成结构化JSON再封装成反馈提示词。这个“工具与模型之间的转换层”在整个AI-native流程里非常关键但几乎没有现成方案。此外仿真覆盖率数据的反馈也存在同样问题。覆盖率数据库的格式非常底层模型根本无法直接使用。需要验证团队和软件团队共同定义一套“覆盖率摘要语言”让模型知道哪些状态没覆盖、哪些分支漏掉了。4.3 我的一些小建议在我过去的实操中有四个点可以立刻开始做。第一选一个最小的RTL模块比如一个FIFO控制器或一个CRC运算器搭建“LLM加形式验证工具”的回环。让模型生成代码形式验证工具给出反例把反例翻译成提示词再让模型修改。第二把综合报告解析成结构化数据反馈给模型时不仅给最终数值还要给出关键路径的路径描述。模型如果能看到“某一条路径经过了三个串联加法器”它就知道应该调整流水线结构而不是一味优化逻辑表达。第三为每个失败样本打上类别标签比如“接口时序不匹配”“状态机缺少默认态”“组合逻辑环路”“可综合性错误”。这些标签会变成训练模型判断常见缺陷类型的宝贵信号。第四拒绝“一次生成直接采用”的做法。哪怕模型生成的模块通过前几个检查项也必须走团队既有的代码评审和形式化验证流程。AI-native是提升效率的工具不是删除质量门禁的理由。5. 对工程师和团队来说这意味着什么5.1 个人技能树的迁移如果你现在还在把自己定位成“RTL编码员”建议赶紧思考转型。AI-native芯片设计落地之后RTL编码会越来越像今天的“写汇编”变成模型辅助下的体力活。真正有价值的能力会向三个方向迁移。第一个方向是架构验证能力懂得如何把模糊的产品需求翻译成可验证的架构约束。第二个方向是数据工程能力能把芯片设计过程中的资产转成高质量训练数据。第三个方向是模型集成能力知道怎么把大模型接进EDA工具链让模型的输出变成工业流程可接受的设计。我认识的不少资深RTL工程师转型路径都是从“多学一点Python脚本和机器学习基础”开始的。这并不难难的是放下“RTL写得漂亮才是硬功夫”的执念。5.2 团队组织与项目流程的变化从组织角度看AI-native芯片设计不是给现有设计团队配两个会写prompt的人就完事了。它需要一种“双语”角色既懂硬件抽象层次又懂模型训练和评估闭环。我更倾向于建议成立一个专门的AI-infra小组负责模型微调、数据管道、评测基准和工具接口而不是让每个工程师各自为战地用大模型写代码。AI-infra小组可以作为内部平台团队向各设计团队提供模型服务、验证闭环模板和失败案例库。流程上建议以“回归最频繁的RTL模块”作为切入点。一个模块如果在每次架构改动中都要花大量时间改代码那么它就是AI-native改造的最高价值目标。先把它做成“模型生成加自动回归验证”的样板再向其他模块复制。5.3 实际操作中必须避开的三个坑第一个坑是拿代码生成demo当成果汇报没有验证闭环逻辑上可能产生大量伪正确的设计。第二个坑是把内部敏感设计数据直接抛给外部API服务。芯片设计的RTL往往涉及产品核心机密我强烈建议部署私有化模型至少也要在做数据脱敏和访问审计后再谈调用。第三个坑是期望一步到位把AI-native当成一个“项目”而不是一个“长期工程”。它更像组织能力的演进需要持续投入。最后分享一个我自己的经验。去年我们尝试对一个教学级处理器核做AI辅助设计过程中真正卡住团队的环节不是生成指令译码器也不是生成ALU而是如何让覆盖率报告以自然语言的形式回流到模型再变成下一轮修改意见。这个过程我们反复调了三周后来发现一个很朴素的道理AI-native芯片设计的每一次进步都来自让机器“明白自己哪里错了”的能力而不是来自它“写得有多快”。所以我建议如果条件允许可以先从自己手头最小的模块开始把“生成-验证-反馈”闭环跑通。哪怕这个模块只是十二行断言加一个简单的状态机你能从中获得的流程经验会比看十份研究报告都管用。这种贴近地面的积累才是芯片设计行业真正需要的那份稀缺能力。 
长河君 · 2026/10/14 7:05:51 · 阅读 1.2k AI-native芯片设计：生成RTL只是入口，验证闭环与数据更稀缺
最近某家海外大型科技公司公开了一份关于“AI-native芯片设计”的研究报告核心观点很直白让大模型直接从自然语言描述生成RTL代码这件事就是芯片设计领域最稀缺的能力。我完整读下来之后反而觉得不太一样。能生成RTL当然重要但如果你把“AI-native芯片设计”等同于“大模型写Verilog”那很可能把整个范式看窄了。真正稀缺的从来不是那一段可综合代码而是围绕这段代码的数据、闭环、约束理解和评测体系。这篇文章我就以自己这几年做AI辅助EDA和处理器前端设计的实际体验谈三点不同看法也聊聊到底哪些能力最值得投入。1. 先搞清楚AI-native芯片设计和我们以前说的“AI辅助设计”差在哪1.1 传统AI辅助EDA的尴尬过去十年芯片设计领域其实一直在用AI但大家说的“AI辅助EDA”和“AI-native”完全是两码事。传统的做法是在EDA工具链的某个节点上嵌入一个机器学习模型比如用图神经网络预测关键路径的时序违规用强化学习做布局布线优化或者用回归模型估计模块的功耗。这类工具的特征是整个设计数据流还是人类工程师在驱动RTL由人来写综合、布局布线、静态时序分析、物理验证都是既有的工业流程AI只是在某个环节充当一个更聪明的启发式算法。说白了它解决的还是传统设计里“某个优化子问题收敛太慢”的痛点没有改变设计流程本身的形态。所以我一直觉得传统AI辅助EDA很像汽车上的定速巡航而AI-native更像是从设计一个汽车转向设计一套自动驾驶系统。前者的目标是让某个指标变好后者的目标是让一段人类描述变成可流片的硬件中间几乎所有决策都由AI参与。1.2 AI-native范式的本质变化所谓AI-native芯片设计核心不是“用AI改善某个EDA工具”而是把模型当作设计流程里的一等公民。整个流程的数据流从“工程师写RTL→工具链处理→签核”变成“工程师提供高层规格和约束→模型生成设计表示→自动验证和反馈→模型迭代设计”。这个变化最关键的变量是设计意图的表达方式变了。以前我们用SystemVerilog来精确表达微架构现在我们希望计算机能理解自然语言描述、伪代码、架构约束并自动映射到可综合的硬件描述。这不是在EDA链路上多一个插件这是把整个芯片前端设计重新拆解成了“理解规格”“生成设计”“验证设计”“反馈修改”四个AI可参与的环节。我去年参与过一个小型处理器核的重构项目当时团队想试用开源大模型直接生成一个指令译码模块。结果发现单看模块代码生成质量真的不差但如果把它当作一个AI-native流程去看模型给出的RTL往往无法通过覆盖率收敛边界条件处理也存在大量盲区。这说明一个很现实的问题生成RTL只是入口入口背后是一条完整的、由数据、验证和反馈构成的环形通路。没有这条通路AI生成的代码就是一堆“看起来很像硬件”的文本。1.3 为什么大家的注意力都集中在“生成RTL”上行业注意力高度集中在“大模型写RTL”这件事原因其实不复杂。RTL是芯片前端设计人力最密集、最容易被量化的环节它也是所有后续后端流程的固定输入。你让模型生成一段可综合的Verilog发给综合工具立刻能跑到时序报告和面积报告效果非常直观也适合做技术演示和宣传。但这里有个陷阱。就像自动驾驶分级一样模型能生成一段“可以仿真的RTL”并不等价于“能够承担设计责任”。真正的检验标准非常简单这段RTL能否在随机测试和定向压力测试下证明功能正确能否在不违反设计约束的情况下收敛到目标时序能否在物理实现时不给后端团队埋一堆雷。我经常打一个比方一个大模型能写出一篇语法通顺的技术文档不代表它理解文档所描述系统的运行逻辑。同样地模型能生成一段长得像RTL的文本不代表它理解流水线冲突、写后写相关、跨时钟域同步这些真实硬件问题。把“生成代码”当稀缺能力就像把“会打字”当稀缺技能这是对问题层级的一次降维误判。2. 真正稀缺的第一项能力高质量数据集与验证闭环2.1 模型训练最难的不是算法是“数据从哪来”现在公开可用的RTL代码量跟自然语言语料相比小到可以忽略。GitHub上能爬到的RTL项目大多来自教学实验、开源IP核和小型业余项目真实工业级设计的RTL通常是不公开的。即便在一个公司内部不同项目组之间的RTL风格、接口协议、约束体系也相差很大很难直接拼成一套训练语料。更麻烦的是光有RTL没有用。AI-native芯片设计需要一个完整的“规格-实现-验证”三元组一段自然语言或伪代码描述的规格一段对应的RTL实现一组覆盖了功能边界的测试约束和断言。这三样东西缺一不可。你只给模型一堆RTL代码它学到的是代码风格和功能语义的模糊映射却学不会“一段规格如何被验证需求约束”。我在实际做数据准备时发现工业界真正有价值的不是那些RTL本身而是RTL伴随的验证计划、覆盖率报告和缺陷修复记录。一个模块最初版本是什么样出了哪些bug工程师怎么改验证环境怎么收敛这些过程数据才是AI理解“设计正确性”的黄金教材。2.2 黄金数据的三层结构我建议把AI-native芯片设计训练数据分成三层每层解决的问题完全不同。第一层是“自然语言或伪代码到RTL”的映射数据。这一层的数据主要训练模型理解规格描述、指令集语义、接口时序输出可综合RTL。这层数据相对容易积累因为很多旧项目的文档里都残留着模块级的规格说明。第二层是“RTL到验证环境”的映射数据。一条RTL对应一组testbench、系统Verilog断言、覆盖率收集配置。这一层的数据非常稀缺因为验证工程师写的代码很少被当作“语料”保存下来它们更像是工程产物而不是资产。第三层是“RTL到物理指标”的回归数据。一份RTL经过综合、布局布线之后得到面积、功耗、关键路径延迟以及这些指标随约束变化的趋势。这一层数据是模型理解“可综合性”“时序可收敛性”的关键支撑。芯片设计之所以不能用通用代码生成模型直接解决很大程度就是因为通用代码的“正确性”是逻辑层面的而芯片设计的“正确性”还包括物理层面的可实现性。这个三层数据形成了AI-native芯片设计的燃料链。没有第一层模型不会写硬件没有第二层模型不知道什么叫“验证充分”没有第三层模型无法理解性能和功耗的代价。当前公开研究大多卡在第二层和第三层这也是为什么很多demo看起来惊艳却始终无法进入真实流片流程。2.3 验证闭环比生成能力更稀缺我在前文反复提到闭环这里展开说。一个真正可用的AI-native芯片设计流程应该包括三个角色生成器、检查器、回归环境。生成器负责把规格转换成设计候选检查器负责对候选设计进行静态和动态检查包括语法检查、可综合性检查、断言仿真、形式化验证回归环境负责把测试结果、覆盖率数据、时序报告结构化地反馈给生成器驱动下一轮生成。三者之中生成器反而是最不稀缺的。因为大模型技术是通用的任何一个团队都能通过微调得到一个“能写RTL”的模型只是质量高低不同。真正难的是检查器和回归环境。检查器需要工业级验证工具链的深度集成回归环境需要把EDA工具输出变成模型可以学习的结构化信号。以覆盖率反馈为例。如果模型生成一个模块测试平台跑完之后给出65%的覆盖率模型需要知道“到底是哪些用例没覆盖到”“哪些分支状态没进入”“是因为生成代码漏了逻辑还是因为生成的testbench漏了激励”。这些信息要经过一层转换变成能够指导下一次生成的自然语言或向量表示。这个转换流程没有现成工具能做需要芯片验证团队和机器学习团队一起从零搭建。我见过很多团队在“生成RTL”上投入大量精力却忽略验证闭环。结果就是模型生成的代码在demo工程里跑得很漂亮放到真实项目中一个随机化测试就跑出一堆协议违规。这背后的原因不是模型“不会写代码”而是流程里缺少“知道自己错了”的机制。2.4 实操中怎么积累这类数据如果你的团队想入局AI-native芯片设计我不建议一上来就训练大模型。最务实的起点是“验证资产结构化”。具体做法是把过去几年所有IP模块的bug报告、RTL修改记录、回归测试用例、覆盖率报告收集起来整理成结构化的数据仓库。每个数据项至少包含四个字段原始规格片段、缺陷RTL、修复后的RTL、触发缺陷的测试向量。这个过程听起来很笨但它有两个好处。第一它让团队对“AI-native需要什么样的数据”有了具体的感知而不是停留在概念层面。第二它提供了一个高质量的微调数据集哪怕规模不大也足够让模型学会“哪些写法容易在验证中出问题”。等到这个数据仓库积累了七八个月再开始尝试用开源模型做微调你会发现模型学到的远远不仅是“写代码”它学会了“避免常见缺陷”“遵循验证友好风格”。这比堆算力去训练一个通用代码模型的收益大得多。3. 真正稀缺的第二项能力系统级架构理解的可执行表达3.1 芯片设计的本质是跨层次稠密约束传播芯片设计和普通软件开发有一个根本区别软件的正确性主要停留在逻辑层芯片设计的正确性必须同时跨越架构层、微架构层、逻辑层、电路层和物理层。任何一个层次的决策偏差都会向下游传导而且越晚发现修复成本越高。我举一个例子。某个AI加速器项目早期的关键决策是“采用统一MAC阵列还是专用DSP单元”。这个决策涉及到工作负载分析、带宽估算、面积预算和能效目标。如果决策错了即使RTL写得再漂亮整个芯片的PPA也是偏离目标。而这一决策恰恰是通用大模型最不擅长的部分因为它不是一个“文本到文本”的翻译问题而是一个“从高度非结构化需求到高维设计空间”的搜索问题。所以我说系统级架构理解的可执行表达比RTL生成能力稀缺得多。模型只有具备“理解工作负载特征→分解为架构约束→映射到微架构模板→评估PPA影响”这一链条的能力才能真正融入芯片设计的前端流程。3.2 架构探索中AI能发挥作用的三个点结合我接触过的项目我认为AI在架构探索层面有三个切入点最值得投入。第一个是工作负载感知。现在的AI芯片设计起点往往是一批PyTorch或TensorFlow模型这些模型的计算图、算子类型、张量形状、访存模式决定了硬件架构的长相。传统做法是工程师手工跑profile再凭经验挑选代表性工作负载。如果能让模型自动从网络结构和工作负载特征中生成“硬件设计需求摘要”架构探索就会快很多。第二个是设计空间探索。给定一个加速器架构模板参数空间可能包含MAC阵列大小、缓冲深度、流水线级数、内存端口数、调度策略等。组合爆炸非常严重传统方式靠专家经验加随机搜索。AI可以基于前面提到的第三层数据学习“参数组合到PPA”的映射用代理模型指导迭代搜索效率高一个数量级。第三个是约束生成。系统级指标比如端到端延迟小于5微秒能效达到10TOPS/W需要通过分解变成RTL级的约束例如时钟频率目标、流水线深度限制、内存带宽上限。这个过程以前靠架构师手写拆解现在有机会靠模型自动生成候选分解方案。这三个点都指向同一个方向AI解决的不是“用Verilog描述一个已知架构”而是“在巨大设计空间里找到那个值得用Verilog描述的架构”。3.3 把系统知识变成可学习任务的方法有些人会说架构设计是艺术很难让AI学会。我承认架构设计里有很多经验成分但经验并不等于不可建模。我自己尝试过一种比较有效的方法叫“参数化模板加约束生成”。具体来说团队会预先定义一套可配置的微架构模板比如输入缓冲区、计算阵列、累加器、输出缓冲、控制状态机。模板里的每个维度都有离散选项。模型的任务不是从零写RTL而是从模板的配置空间中选择一组参数并说明选择理由再由模板自动化生成RTL。这样做有三个好处。第一它把系统级知识的范围缩小到“架构参数选择”问题更容易学习。第二它天然是可综合的不会像开放生成那样产生一堆不可综合的代码。第三它保留了工程师对架构方案的审查能力模型给出配置工程师检查配置是否符合设计意图形成人机协作闭环。这个思路的实验效果我不说有多惊艳但至少比让模型自由发挥“设计一个AI加速器”要实用得多。对大多数芯片设计团队来说“受约束生成”远比“自由生成”接近落地。4. 真正稀缺的第三项能力面向AI-native流程的评测基准和领域EDA工具4.1 没有可信的评测AI-native芯片设计就是空中楼阁任何一项AI技术如果没有可靠的评测方法就只能停留在demo阶段。芯片设计领域尤其如此。我们不能拿“代码能编译”当标准因为RTL能编译、能仿真和它能流片、能signoff之间差着十万八千里。通用代码生成的评测基准比如函数级代码补全、单元测试通过率对芯片设计来说完全不适用。芯片设计的正确性不是“单点逻辑正确”而是“功能正确、可综合、时序可收敛、功耗可接受、验证覆盖率达标”五重标准的交集。我在团队内部尝试搭建一套分层评测体系分别对应三种能力。评测层输入输出通过标准L1 模块级RTL生成自然语言规格、接口定义、时序约束可综合RTL语法检查通过、仿真结果与参考模型一致、逻辑综合无严重违例L2 验证闭环能力模块规格和不完整验证环境完整RTL与配套testbench/断言回归测试全通过覆盖率超过指定阈值能定位并修复单个缺陷L3 系统级架构探索工作负载描述、PPA目标、工艺库信息候选架构配置与PPA估算配置可映射到RTL模板PPA估算收敛到目标范围与人工基线对比不差于指定比例这套体系的重点不是“考倒模型”而是让模型的每一次迭代都能通过量化指标反映出来。有了这套评测团队才有底气说“我们的AI-native流程提升了设计效率”。4.2 领域EDA工具链为什么严重缺位AI-native芯片设计另一个被低估的缺口是“面向模型的EDA工具接口”。传统EDA工具的使用对象是工程师交互方式是人通过图形界面或脚本操作。AI-native流程里模型要跟工具链进行大量自动化交互生成阶段调用综合器做粗略评估验证阶段调用仿真器采集覆盖率迭代阶段把工具的反馈转换成下一个prompt。现在的EDA工具大多没有为这种“程序化、可批量、短时延、语义化反馈”的调用方式准备接口。我举个具体例子。模型生成RTL之后团队想让它知道综合报告里关键路径长度和扇出数量。现有综合工具能输出文本报告但这份报告是给工程师读的不是给模型读的。你需要额外写一套解析器把文本报告转成结构化JSON再封装成反馈提示词。这个“工具与模型之间的转换层”在整个AI-native流程里非常关键但几乎没有现成方案。此外仿真覆盖率数据的反馈也存在同样问题。覆盖率数据库的格式非常底层模型根本无法直接使用。需要验证团队和软件团队共同定义一套“覆盖率摘要语言”让模型知道哪些状态没覆盖、哪些分支漏掉了。4.3 我的一些小建议在我过去的实操中有四个点可以立刻开始做。第一选一个最小的RTL模块比如一个FIFO控制器或一个CRC运算器搭建“LLM加形式验证工具”的回环。让模型生成代码形式验证工具给出反例把反例翻译成提示词再让模型修改。第二把综合报告解析成结构化数据反馈给模型时不仅给最终数值还要给出关键路径的路径描述。模型如果能看到“某一条路径经过了三个串联加法器”它就知道应该调整流水线结构而不是一味优化逻辑表达。第三为每个失败样本打上类别标签比如“接口时序不匹配”“状态机缺少默认态”“组合逻辑环路”“可综合性错误”。这些标签会变成训练模型判断常见缺陷类型的宝贵信号。第四拒绝“一次生成直接采用”的做法。哪怕模型生成的模块通过前几个检查项也必须走团队既有的代码评审和形式化验证流程。AI-native是提升效率的工具不是删除质量门禁的理由。5. 对工程师和团队来说这意味着什么5.1 个人技能树的迁移如果你现在还在把自己定位成“RTL编码员”建议赶紧思考转型。AI-native芯片设计落地之后RTL编码会越来越像今天的“写汇编”变成模型辅助下的体力活。真正有价值的能力会向三个方向迁移。第一个方向是架构验证能力懂得如何把模糊的产品需求翻译成可验证的架构约束。第二个方向是数据工程能力能把芯片设计过程中的资产转成高质量训练数据。第三个方向是模型集成能力知道怎么把大模型接进EDA工具链让模型的输出变成工业流程可接受的设计。我认识的不少资深RTL工程师转型路径都是从“多学一点Python脚本和机器学习基础”开始的。这并不难难的是放下“RTL写得漂亮才是硬功夫”的执念。5.2 团队组织与项目流程的变化从组织角度看AI-native芯片设计不是给现有设计团队配两个会写prompt的人就完事了。它需要一种“双语”角色既懂硬件抽象层次又懂模型训练和评估闭环。我更倾向于建议成立一个专门的AI-infra小组负责模型微调、数据管道、评测基准和工具接口而不是让每个工程师各自为战地用大模型写代码。AI-infra小组可以作为内部平台团队向各设计团队提供模型服务、验证闭环模板和失败案例库。流程上建议以“回归最频繁的RTL模块”作为切入点。一个模块如果在每次架构改动中都要花大量时间改代码那么它就是AI-native改造的最高价值目标。先把它做成“模型生成加自动回归验证”的样板再向其他模块复制。5.3 实际操作中必须避开的三个坑第一个坑是拿代码生成demo当成果汇报没有验证闭环逻辑上可能产生大量伪正确的设计。第二个坑是把内部敏感设计数据直接抛给外部API服务。芯片设计的RTL往往涉及产品核心机密我强烈建议部署私有化模型至少也要在做数据脱敏和访问审计后再谈调用。第三个坑是期望一步到位把AI-native当成一个“项目”而不是一个“长期工程”。它更像组织能力的演进需要持续投入。最后分享一个我自己的经验。去年我们尝试对一个教学级处理器核做AI辅助设计过程中真正卡住团队的环节不是生成指令译码器也不是生成ALU而是如何让覆盖率报告以自然语言的形式回流到模型再变成下一轮修改意见。这个过程我们反复调了三周后来发现一个很朴素的道理AI-native芯片设计的每一次进步都来自让机器“明白自己哪里错了”的能力而不是来自它“写得有多快”。所以我建议如果条件允许可以先从自己手头最小的模块开始把“生成-验证-反馈”闭环跑通。哪怕这个模块只是十二行断言加一个简单的状态机你能从中获得的流程经验会比看十份研究报告都管用。这种贴近地面的积累才是芯片设计行业真正需要的那份稀缺能力。