AI-native芯片设计：真正稀缺的不是提示词，而是三大能力

最近某头部科技公司放出一批AI-native芯片设计的研究组里的群又热闹起来。大家转发最多的几乎都是“AI自动写RTL”“大模型参与布局布线”这类关键词结论也出奇一致芯片设计门槛要被AI拉下来了。我做芯片设计这么多年看过太多“新技术发布”之后的过山车——初期亢奋、中期怀疑、最后沉淀成少数人能驾驭的技能。所以这篇文章不打算复述那批材料的内容而是从一个在一线画过版图、跑过时序收敛、也debug过AI生成代码的人的角度聊聊我认为AI-native芯片设计里真正稀缺的三项能力以及大多数人容易忽略的三个关键环节。无论你是一线设计工程师、后端实现工程师还是团队里的验证负责人应该都能在下面的内容里找到属于自己的坑。1. 先从这场讨论看起大家都在夸什么我为什么想泼冷水1.1 大家都在夸什么先说清楚什么叫AI-native芯片设计。它不是“拿AI辅助一下某个点工具”而是把AI作为一个原生组件嵌入整个设计流程从需求分析、微架构探索、RTL生成、功能验证到布局布线数据和反馈在人和AI之间反复闭环。好处是显而易见的原来以周计的迭代可以压缩到以天计甚至以小时计。那家公司的材料里最抓眼球的是用大模型对已有设计做分析和生成以及用强化学习来解决一些组合优化问题。这些方向都值得做也一定会落地。但我也注意到一个现象很多人把“AI能做到什么”和“建设AI-native体系需要什么”混为一谈。Demo里AI能生成模块不代表一个团队靠几个会写提示词的人就能把产品做好。我翻了大量讨论点赞最高的永远是“怎么把Prompt写得更好”很少有人讨论验证责任、问题建模、物理约束这些不性感的环节。而这恰恰决定AI-native流程能不能在真实项目中活下来。1.2 我为什么要泼冷水我泼冷水不是否定AI-native这个方向而是觉得我们讨论问题时关注的焦点偏了。芯片设计里逻辑正确只是入场券真正的门槛在验证收敛、物理实现、良率与功耗约束。AI-native如果只是让“写代码”变快了那它带来的是更多需要检查的代码如果它不能帮助人把设计空间探索得更清楚那自动化程度越高潜在风险反而越大。我把话放这里未来两三年里会写提示词的人会越来越不值钱因为大模型本身在快速迭代提示词的技巧会被产品能力吸收。真正稀缺的是那些藏在“写一句自然语言”背后的硬功夫。它不性感但决定系统能不能稳定跑起来。1.3 我的三点不同看法概览这篇文章想展开的就三件事。第一最稀缺的不是“会用大模型”而是把模糊需求翻译成机器可判定问题规格的能力。第二最稀缺的不是“让AI多干活”而是敢信AI时仍然具备系统性审查AI结果的能力。第三最稀缺的不是“新算法新工具”而是对物理世界约束的理解并且能把这种手感沉淀为数据和约束。这三条都不是什么新奇方法论但每条都是项目落地时最先暴露的短板。工具可以进步得很快人的思维习惯却很难改变。下面我逐条说透。2. 稀缺能力之一把芯片问题翻译成“机器听得懂”的话2.1 会写提示词不等于会做问题模型现在流行各种提示词课程但芯片设计里的输入本质上不是自然语言写得好不好而是约束给得全不全。很多人给大模型一句“写个FIFO”拿到代码就跑结果发现深度参数是写死的、读写冲突没处理、复位行为不明确。这不是模型笨是你没有定义问题。模型只能在它的经验分布里猜你的需求你猜得越少它替你做的“假设”就越多。一个合格的“问题模型”至少需要回答这些方面的内容输入输出的位宽、最大深度、流量模型时钟域、复位方式、握手协议空读、满写、非法访问、缓冲溢出这些异常行为寄存器数量、RAM块位置、功耗与频率目标是否要插可测试性设计是否需要扫描链是否需要断言。每一项都要尽量变成机器可以判定的描述。比如不要只说“处理异常”要说“当写入请求到来但FIFO满时写使能必须被拉低写入方不得采样数据”。后者才能被验证工具自动检查。2.2 从“帮我写代码”到“帮我满足规格”我实操里最有效的一个改变是让模型先复述需求而不是直接生成代码。很多模型具备一定的交互能力它可以反问你“深度是多少复位电平是什么读写时钟是不是同一个”如果你的提示词里这些信息都缺失它往往会给出一个看起来特别完整、实际充满假设的版本。与其事后review代码不如事前把问题域收窄。一个我经常用的提示词骨架长这样设计一个参数化同步FIFO 参数DEPTH必须是2的幂、DATA_WIDTH 接口clk、rst_n、wreq/wdata/full、rreq/rdata/empty 行为约束 - 当full1且wreq1时不得发生覆盖写入 - 当empty1且rreq1时rdata保持当前值且empty保持为高 - 同步场景使用二进制指针若用于跨时钟域请使用格雷码 - 输出必须是寄存器输出不允许组合逻辑直接读RAM - 异步复位低电平有效。 风格可综合RTL禁止使用initial和仿真专用语法。对比过很多次这种描述生成的代码质量比“帮我写一个FIFO”高得多。原因是它把模型的“创作空间”压缩到了一个可控范围内而AI最大的问题就是给没约束的地方瞎发挥。2.3 把未知变成断言让AI帮你补全我还有一个习惯先让AI生成断言再让它生成RTL。为什么因为断言让需求从自然语言变成可自动检查的语言。设计师问自己“什么条件下系统不能做某件事”把这些写成SystemVerilog断言比写实现难多了但价值也高得多。比如对于上面这个同步FIFO我会在动手设计前先写property p_no_overwrite; (posedge clk) disable iff (!rst_n) full |- !wreq; endproperty assert property (p_no_overwrite); property p_read_on_empty; (posedge clk) disable iff (!rst_n) empty |- !rreq; endproperty assert property (p_read_on_empty);这些断言就是“机器可判定的契约”。AI生成的RTL如果违反了其中任何一条仿真器会在具体的那一拍报错而不是等到系统级验证时才发现问题。我认为设计师最稀缺的能力就是把自己脑中的隐式约束写成这种契约。有了契约AI才不是碰运气而是在一个有边界的花园里做搜索。3. 稀缺能力之二敢信AI更会查AI3.1 自动化程度越高验证责任越重有个数字游戏值得想清楚。如果AI生成代码的正确率是95%你生成1000个模块里面会有50个有问题。传统流程里这些代码是人写的review的人天然带着怀疑去看每一行容易发现风格突兀、状态不对劲的地方。而AI生成的代码看起来结构整齐、命名规范审查者的警惕性反而会下降。一旦一个错误溜过验证进入流片环节代价可能是几个月的时间和巨大的流片费用。软件项目可以热修复芯片不行。所以AI-native的真正含义不是“把正确性交给模型”而是“把人工审查的重点从写代码转移到验证和证据搜集”。这个转变非常反直觉。自动化程度越高验证责任反而越重因为机器替你制造了大量看起来没问题的内容真正需要你判断的地方隐藏在统计噪声里。3.2 四种我会常用的审查手段我自己的临时AI辅助流程里固定会做四件事差分对比、断言驱动验证、结构审查、增量回归。差分对比是对同一份需求用不同提示词或不同采样参数生成多版实现然后做功能比对。逻辑行为应当一致如果某一版出现差异通常就是模型在某个边界条件下“发挥”了。断言驱动验证是上面说过的把安全属性全部写成property用约束随机激励去跑覆盖率不到定义阈值之前不进入下一步。结构审查是要看状态机和顶层数据流AI容易生成冗余状态或不可达分支这些隐藏在波形里很难发现看状态转移图更快。增量回归则是每次提示词一变必须全量回归一遍不能因为修改很小就只跑局部用例AI生成的东西不确定性太强局部通过不代表整体没问题。3.3 一次“所有请求同时有效”才暴露的bug讲一个我实际踩过的坑。之前做一个小型仲裁器提示词里写的是“公平优先级”模型生成的状态机看起来不错随机回归跑了一千个用例全部通过。后来我手动构造了一个反例所有master同时请求并且持续多个周期。结果发现grant被锁在其中一个高优master上其他master永远拿不到总线权限。问题出在“公平”两个字上模型默认的公平是“每个请求最终会被响应一次”而我的真实需求是“在长周期内所有请求者获得的带宽比例不能差太多”。这种隐含语义只有人工把反例构造出来才能暴露。后来我把需求改成一条形式化描述任何一个请求者在连续N个周期内至少获得一次grant。这写成断言比写自然语言麻烦但它能稳定守住边界。这个例子说明真正需要投入精力的不是让AI产出更多代码而是识别出你的需求里那部分“不可言说但绝对不能错”的东西。3.4 要学会看覆盖率报告很多工程师把覆盖率当成绩效指标只盯着数字涨没涨。在AI-native流程里覆盖率报告更像是一张“AI搜索盲区地图”。如果某个cross覆盖率一直很低通常意味着你的激励没有覆盖到某些边界组合不代表那部分代码没问题。这时候要主动构造一组“边界胶囊”比如FIFO深度正好占满、空满临界翻转、指针回绕、写请求与满标志同拍拉高。这些定向用例比单纯堆随机种子效率高很多。AI最擅长的就是顺着你给的激励跑但设计最怕的恰恰是你没给的激励。4. 稀缺能力之三物理直觉与工艺约束的“手感”4.1 逻辑正确只是入场券AI生成的RTL能过仿真不代表综合后时序能收敛。芯片是一个物理系统时钟树、金属层、单元密度、电源网络都在给设计上锚。AI不“理解”物理世界它优化目标时只优化你给的目标函数。如果你不能把“这条关键路径不能被单元挡太远”“这里要预留时钟树位置”变成约束或代价函数AI就会在逻辑上给你一个正确、物理上不可实现的网表。很多经验丰富的设计者能一眼看出某段代码“综合后大概率出问题因为状态机嵌套太深或者扇出太大”这种直觉很难写进文档但可以在数据里留痕。AI-native的挑战正是把这种直觉变成可计算的东西。我以前带过的新人做前端设计时脑子里只有逻辑不考虑综合映射做后端的人又往往只关心物理不理解前端为什么这么写。真正能把两边拉通的人在任何流程里都稀缺在AI-native流程里更稀缺因为AI会把错误的目标函数放大成灾难。4.2 工艺约束如何“喂”给AI一个低功耗的例子拿低功耗设计里的时钟门控来说。插入时钟门控能有效降低动态功耗但门控过密会引入面积开销和时序收敛问题。没有AI时工程师会根据经验圈出翻转率高的寄存器组做门控因为“这里收益最大”。有了AI你可以把翻转率、面积开销、时序预算整理成一张表让AI在约束下搜索门控策略。但如果你只告诉模型“尽量门控”它会激进地门控所有寄存器导致面积爆炸、时钟门控单元摆不下。正确做法是告诉它“每个门控单元的时钟偏斜预算不能超过X皮秒门控后节省的动态功耗必须大于Y优先门控翻转率排名前百分之三十的寄存器组。”把经验翻译成数字AI才真正接得住。这跟提示词技巧无关靠的是你对电路功耗来源的理解。模型不会替你判断哪些寄存器翻转率统计可信更不知道一个时钟门控单元在特定工艺库下要占多少面积。这些信息必须由懂物理的人喂进去。4.3 数据治理是手感沉淀的前提那家公司的研究里很强调“数据闭环”从历史设计数据中学习再把模型输出反馈回流程。这个方向我非常认同但实践中的难点在于大多数团队的EDA日志、ECO记录、时序违例报告都散落在个人文件夹里格式五花八门有些连版本号都对不上。模型没有可学习的数据就谈不上经验积累。真正稀缺的工程能力之一是把过去项目里的“失败数据”清洗、打标签、按场景归档。就像保留调试现场一样保留数据这个模块为什么时序违例是因为负载太重还是单元驱动不足最后用哪一种ECO解决这些记录如果能结构化AI-native的数据闭环才有养料。这是件特别不性感的活儿但谁先把数据治理做好谁就真的拿到了复利。5. 实操记录我如何在三天里试跑一个AI辅助设计小实验5.1 实验目标与准备工作与其把上面的观点全当成理论不如看看我实际跑过的一个小实验。目标是用本地部署的通用大语言模型辅助开发一个参数化同步FIFO包含读写指针、空满标志、避免覆盖写和空读。之所以选同步FIFO而不是复杂模块是因为它简单到能看清约束清晰度对结果的影响。换句话说如果连这种模块在AI-native流程里都会出边界问题那复杂模块的问题只会更大。工具链上我用的是内网环境的模型接口不依赖外部网络配合一个开源SystemVerilog仿真器。时间安排是三天第一天写规格和断言第二天生成RTL并迭代第三天做回归和覆盖率统计。整个过程最大的变量不是模型而是我自己对需求的措辞。5.2 从“一句话需求”到“可判定规格”第一天我先尝试用一句话需求去生成结果很典型模型给出一个“常见实现”端口写死深度写死复位极性靠猜空满标志的定义和我想的不完全一致。接着我把需求补成了包含参数、接口、复位方式、握手协议、禁止覆盖、禁止空读、寄存器输出等要点的版本。前后对比如下表需求版本示例结果一句话“写一个FIFO”模型给出常见实现端口固定深度固定行为不明确完善版包含参数、复位、握手、禁止覆盖、寄存器输出模型生成可综合风格RTL仿真通过率明显提高这里的关键动作是让模型先复述需求并主动补全缺失假设。比如它会问“深度参数范围是什么”“复位电平是低还是高”“读写指针用什么编码”。这些反问其实就是需求review比人自己对着文档检查更容易发现遗漏。5.3 迭代过程中的两个关键节点第二天我用完善版提示词生成了第一版RTL把之前写的断言放进仿真跑立刻发现一个违例当full1且wreq1同时到来时内部写指针没有做保护数据被覆盖。原因不是模型不会写FIFO而是我的提示词里只写了“full信号拉高”没有明确“当full为高时wreq应当被忽略”。补上这句后重新生成断言通过。第二个节点更微妙。我手动构造了“深度2连续写入两个数据后再读一个”的定向用例发现empty标志的时序不对读数据输出打了一拍empty却提前拉高。追溯需求发现是我没有定义清楚“rdata是寄存器输出”和“empty与读请求在同一拍更新”之间的关系。模型只能根据常见惯例选择一种时序而我的场景需要另一种。把需求改精确后重新生成这次行为完全正确了。第三天的时间用在回归和覆盖率上。我把随机激励种子跑了几十组功能覆盖率拉到了接近100%又额外补了全满、全空、满写、空读、回绕这几个定向用例。最后这个模块在仿真里稳定通过。5.4 三天后的结论这个实验真正的产出不是那个FIFO而是一套“需求规格→断言→RTL→回归”的骨架。如果我不会验证那第二天上午的调试就会被误认为“AI生成质量不行”实际上问题出在规格不够精确。我和团队的体会是AI-native流程不会降低设计师的标准它会把设计师从“手写代码”中解放出来同时逼你把“心里知道但没说过”的规则全部摆到桌面上。想享受AI红利就要先接受这种透明化。6. 常见问题与陷阱速查6.1 一张问题排查速查表常见症状背后的原因排查与对策RTL仿真通过但综合阶段报错提示词缺少可综合性约束强制模型先输出“可综合风格”声明加入lint检查功能覆盖率低随机激励不收敛约束条件太宽松权重设置不合理用边界导向的定向用例约束关注交叉覆盖率模型一本正经地输出错误断言断言条件抄错信号名或时序关系单独review断言用形式化仿真证明关键属性同一需求生成不同结果时好时坏采样温度过高提示词不稳定固定随机种子降低温度要求结构化输出模型在复杂状态机里“幻觉”缺失状态状态转移约束给得不完整手写状态转移表让模型基于FSM表填充实现6.2 关于提示词的两个常见误区第一个误区是觉得提示词越详细越好。实际上当提示词长到几百行时模型容易出现注意力分散反而忽略关键约束。更好的做法是分层先给一份“接口与行为规格”再给“风格要求”分两轮提问比一次性塞给模型所有内容稳定得多。第二个误区是迷信“告诉模型不要做什么”。对AI来说“不要覆盖写”不如“当full为高时wreq必须被忽略并保持数据”有效因为后者给出了可判定的行为边界前者只描述了一个非法状态。我还见过很多团队把提示词当成文档管理版本散落在聊天记录里。建议把提示词当作工程产物跟RTL代码一样做版本控制每次修改记录原因。模型可以升级但提示词的演进历史本身就是宝贵的项目资产。6.3 数据污染与“背标准答案”另一个容易被忽视的坑是数据污染。公开数据集里有大量芯片设计示例模型可能“背诵”过一个常见FIFO实现然后在你的需求面前直接默写。结果看起来完美但你稍微改一下参数或加一点特殊行为它就开始出错。这不是模型能力问题而是它在掩盖自己对本地约束的不敏感。对策有两个一是故意使用非典型参数和接口命名让模型无法直接套模板二是用自己团队的内部数据做微调让模型真正学会你们的设计规范和模块库习惯。这个投入短期看性价比不高但长期是把AI-native流程变成团队核心资产的关键步骤。写在最后跑完那个小实验之后我最大的体会是AI-native最性感的词是AI但最致命的却往往是native。它要求我们所有人老老实实地把原本靠感觉和经验完成的工作重新用机器可理解的方式定义一遍。这没法外包给提示词工程也没法靠换一个更大的模型解决。如果你也想往这个方向走我的建议是先不急着追求自动化率而是找一个小模块把需求、断言、回归这套流程扎实跑通亲身感受一次“因为规范所以AI好用”的红利。很多认知只有在一次完整的调试循环里才能真正建立起来。