arXiv:2609.09344 论文解读 我的观点芯片人看AI · 论文精读 约9000字 / 阅读约22分钟AI Native芯片设计EDA论文解读基本功工程经验隐性知识工具链验证人才培养芯片工程师arXiv一篇 Meta、纽约大学和斯坦福合写的论文讲 AI 原生时代芯片工程师还需要哪些基本功。前半部分我把论文核心内容原样搬给你含 14 张原文截图后半部分是我的看法——有三处我和论文的观点不完全一致都标了出来。写在前面这是一篇论文解读也是一篇读后感。论文来自 Meta、纽约大学和斯坦福2026 年 9 月挂在 arXiv 上题目直译过来是《学术界 × 产业界AI 原生时代芯片设计基本功的作用》。Meta 的团队在第一线用 AI 做芯片他们讲「模型越来越会写 RTL 之后真正稀缺的能力是什么」比纯学术视角更值得听。前半部分是论文的完整解读我原样搬过来内容不做修改——它讲的问题值得每个芯片工程师认真读一遍。后半部分是我的观点。有三处我和论文的看法不完全一致我用专门的标注框标了出来你看到橙色框就是分歧点。报告重点论文的五个核心判断论文的核心判断是AI 越深入芯片设计工程师越需要掌握设计原理、表达设计意图、检验结果并解释取舍。这些基本功决定了任务怎样交给 AI以及 AI 产生的结果能否进入工程流程。一、实现加速会把瓶颈推向规格、验证和协作。生成 RTL 的速度提高以后需求是否完整、修改是否满足系统约束、上下游是否接受结果将更直接地影响交付周期。二、隐性经验需要转化为带条件的知识。一条约束、一项豁免或一个优化方法只有同时保留理由、适用范围和检查方法才有条件被其他工程师和 Agent 复用。三、检查工具决定反馈是否有工程意义。仿真、形式验证、STA 和物理检查各自回答不同问题正确选择检查对象、假设和输入比得到一个 PASS 标志更重要。四、快速探索需要与交付基线建立联系。商业 EDA、开源工具和代理模型可以承担不同阶段的工作。工具之间的 correlation 决定快速评估能用于哪些判断。五、人才培养和科研交付都要面向实际使用。学生需要解释和纠正 AI 结果研究成果需要同时提供方法、实现、运行条件和评价方式让后续使用者能够接着工作。全文可以沿着这条关系理解把经验表达出来把候选结果检查清楚再把经过检验的方法交给下一位使用者。一、实现速度提高以后工程瓶颈会移到哪里一次时序优化可以很好地说明这个问题。Agent 发现关键路径过长在数据通路中增加一级寄存器重新运行工具后setup slack 改善了。接下来的问题却属于系统设计接口是否允许增加一个周期valid 与 data 是否仍然对齐背压是否改变复位后的首笔事务能否正确完成。只有这些条件也满足局部改动才有机会被接受。芯片工程里有大量这样的决定。执行一次修改与判断修改是否合理依赖不同层次的能力。随着候选实现更容易获得后者会占据更大的工作比重。这正是论文讨论基本功的出发点把人的职责放到整个设计和交付过程里理解。1.1 图 5 展示的是代码任务能力的变化论文用 CVDP 的代码生成和代码理解成绩说明模型能力正在变化。两张子图观察的是不同任务纵轴都是已解决问题的比例横轴是结果发布日期。原图采用的是截至 2026 年 8 月的成绩快照。从左图可以看到代码生成结果大致落在 17% 至 40% 的区间右图的代码理解结果大致落在 57% 至 82%。这两个范围只是对原图点位的粗读。生成一个满足题目要求的实现与理解一段既有代码所需能力和失败方式并不相同。作者据此预期RTL 代码生成会逐步成为更普遍、获取成本更低的能力工程师的工作也将更多转向任务组织和结果判断。图中比较了不同模型的提交结果原图脚注还说明部分提交并未由 Si2 直接运行或验证。因此评价具体模型时需要连同任务集、上下文、工具和预算一起看图中的成功比例不能直接替换成真实项目的交付成功率。同样的变化也会影响 HLS 和硬件 DSL 的价值定位。作者提出当规格到 RTL 的生成能力提升后应重新评估这些语言所提供的生产率收益。工程上还要同时考虑类型约束、领域表达、编译优化和验证方法即使手写 RTL 的工作量下降这些机制仍可能减少规格歧义或限制不合法结构。1.2 局部十倍加速为什么只得到约一点六六倍整体加速原文表 1 引用了一项软件开发者工时研究表中样本为 5,928 人。编码、修复、测试、代码审查和文档五类工作合计占 44%。作者用这组比例说明当其中一部分工作加速后剩余部分会成为更突出的瓶颈。假设工作总量不变只有这 44% 获得十倍加速剩余时间就是 56% 44% / 10 60.4%整体加速为 1 / 0.604约 1.66 倍。按同一个假设计算可以得到下表。被加速部分的速度总耗时相对原来的比例整体加速2 倍78.0%1.28 倍5 倍64.8%1.54 倍10 倍60.4%1.66 倍该部分耗时趋近于零56.0%1.79 倍这里使用的是软件工时比例和简化计算作用是解释瓶颈转移。芯片项目的工期还取决于任务依赖、EDA 运行、许可证排队、IP 交付、集成复核和返工不能从这张表直接取得一个项目加速倍数。对芯片团队更有用的判断是AI 加速的步骤是否位于当前交付的关键路径上。如果代码已经完成项目仍在等待规格确认那么继续提高生成速度的收益有限如果每次修改都需要长时间工具重跑那么减少无效候选和重复运行可能更有价值。二、从隐性经验到 Agent 能够使用的知识实现可以交给别人判断依据却经常留在原设计者脑中。论文列举的典型知识包括时序例外的理由、特定工艺中的处理经验以及某项设计取舍在什么条件下可以接受。这些内容既影响新人接手也决定 Agent 能否获得足够的上下文。2.1 图 1 的变化发生在知识传递路径上图左侧画的是专家向新人传授经验、新人再向下一位新人传授的过程。每一次传递都依赖具体的工作接触是否一起定位过问题是否见过特殊模式是否讨论过当时放弃其他方案的原因。设计文件保存了最终结果却未必保存得出结果的过程。图中间把知识放入共同载体让工程师和 AI 工具都能使用。右侧的曲线表达作者的组织判断显式保存并持续维护知识有利于减少人员变化带来的经验流失。它是一幅概念示意图讨论的是积累机制。以 false path 为例保存一行约束能够重现当时的工具设置却不足以支持后续判断。接手者还需要知道路径在哪种模式下不可能被有效激励是否依赖控制互斥相关假设由哪个检查支撑以及设计改变后何时需要重新审查。能够迁移的是附带理由和条件的经验。按照这个逻辑整理知识记录对象会从“最终文件”扩展到“设计决定”。下表是对这一观点的工程展开。记录内容保留它的作用缺失后的典型问题设计意图与适用模式说明为什么需要这项处理接手者只看到命令无法判断是否仍成立前提与依赖说明结论依赖哪些时钟、复位、电源或协议条件条件改变后继续沿用旧结论修改与被否定方案说明实际做了什么、为何放弃其他选择重复尝试已知无效方案检查与评价结果说明决定得到了什么支持把经验描述当作已完成验证版本与变更触发条件说明何时应重新检查正确经验在新配置下变成错误假设这类知识既可以供人阅读也可以成为 Agent 的输入。其价值不依赖某一种知识库产品关键是记录能否支撑下一次工程决定。2.2 图 4 解释了芯片数据为什么难以形成训练与评价循环原图把软件与硬件样例放在开源生态、学术机构和产业公司三个环境中。硬件数据并非不存在高价值设计及其运行环境往往受保密约定、工艺绑定和工具格式限制。设计离开原有环境以后可能只剩一份 RTL而缺少解释和评价它的条件。论文把这种稀缺进一步分成了几个相互关联的问题。首先是设计和规格难以获取其次是中间过程难以获取包括错误日志、时序分析、候选修改和评审理由再往后给结果打分的环境也可能依赖内部库、专有工具和项目方法学。即使拿到样例也未必能够运行同样的评价。这使芯片 AI 面临一个双重困难模型需要学习工程过程而组织又必须能够判断模型的行动是否有效。扩大公开 RTL 数据可以改善部分代码任务但工业 Agent 还需要获得规格、过程和评价之间的对应关系。对于一项时序优化只有最终网表很难知道最初的违例是什么只有修改脚本很难知道它破坏了哪些其他指标只有一份通过报告又很难知道约束和库是否与目标交付一致。把这些材料关联起来才有可能复用其中的工程经验。2.3 图 6 进一步回答知识留下以后怎样使用图中左侧是 RTL、验证、物理设计和研究领域的专业知识中间是 Rules、Skills、Tools、Agents右侧是不同专业和经验层次的使用者。图 1 关注保存与传递这张图关注知识怎样进入实际任务。这几类载体各有作用。规则表达必须满足的条件技能组织一类任务的步骤和适用范围工具完成计算、转换或检查Agent 根据任务状态选择下一步行动。它们组合起来才可能使一个原本不熟悉该领域的人完成部分工作。作者把这种能力增强称为 superintelligence。在本节语境中它指个人通过外部专业知识和工具扩展能力。例如不熟悉某种向量架构的人可以借助相关知识提出优化再利用工具评价结果。其工程价值首先体现在减少进入陌生领域的成本、提高问题表达质量以及扩大能够尝试的方案范围。对照已有 EDA 和 IP 的发展路径这个观点并不突兀。综合、布局布线和协议 IP 已经把大量专业知识封装在工具与模块中。原文 §2.7 主张在这些已有积累上继续建立 AI 能力。因而把一项经验封装成可调用方法时已有工具、接口和检查结果都应成为它的一部分。三、候选结果怎样获得工程可信度知识能够被调用只解决了任务如何开始。Agent 运行以后还会产生代码、脚本、约束和解释工程师需要判断这些产物满足了什么条件。论文在 §3.4 把芯片工程已有的精确检查手段视为一项优势这些反馈可以用于筛选候选、定位失败并指导下一次修改。3.1 图 2 强调的是复核所需的知识图上半部分把问题交给模型后直接接受结果下半部分加入了人对基本知识的掌握使人能够检验结果。两条路径都使用 AI差异在于使用者是否仍然具备理解和判错的能力。论文将这种把部分任务交给外部工具的行为称为认知卸载。适当卸载可以让人处理更大的问题如果连判断依据也一并放弃使用者就可能无法识别错误方案。工程师不需要重做工具内部的全部计算但需要知道工具回答了哪个问题、采用了哪些条件以及结果与产品要求是什么关系。这一点在验证中尤其具体。同一份含糊需求可以使 DUT 和 testbench 共享同一个错误解释。两者在仿真中相互吻合说明的是它们之间的一致性能否满足产品要求还取决于需求解释和检查器是否正确。验证的独立性来自规格、模型、性质和复核依据不能只按生成了多少文件或调用了多少个 Agent 来判断。3.2 确定的工具结果仍然依赖正确的检查条件把工具接入 Agent 后工程师的一项核心工作是把“怎样判断结果可以接受”写清楚。检查器覆盖的性质、使用的模型和输入条件决定了反馈的含义。原文把等价检查、形式验证、STA、DRC 等列为可供 Agent 使用的反馈。在具体工程中它们的检查对象不同需要分别解释。检查方式能够回答的问题决定结论含义的条件编译、lint代码是否满足语法与所启用的结构规则规则配置、语言支持和输入文件范围仿真被激励的行为是否满足检查器场景、参考模型、检查器与覆盖目标形式属性验证给定假设下声明的性质是否成立假设、性质、抽象及证明完成状态等价检查两个模型在指定条件下是否等价参考模型、映射、约束和比较范围STA指定模式与模型下是否满足时序要求时钟、例外、库、寄生及 cornerDRC、LVS版图是否满足所检查规则、连通性是否一致规则集、器件识别、输入网表与检查范围例如形式工具中的 assume 限定被探索的情况assert 表达需要检查的性质。如果把真实可能发生的行为排除在假设之外证明结果就只对更小的环境成立关键性质没有写入时工具也不会自动补充产品要求。STA 的结果同样依赖输入条件。若 Agent 通过放宽约束或错误增加例外来消除违例报告可能改善电路实际能力却没有相应变化。因此一个时序优化任务需要同时固定比较条件和允许的修改范围。对网表或 RTL 的修改可以进入相应的功能及实现检查对设计约束的修改则需要先判断它是否仍表达原来的需求。把这两类动作混成同一个“降低违例数”目标会使优化方向偏离产品要求。这也是论文观点值得继续展开的地方已有 EDA 检查能够提供反馈而反馈是否适合用作优化目标仍然是一项设计工作。正确性条件、性能目标和资源预算应分别表达避免一个总分掩盖了不可接受的功能变化。3.3 图 7 说明了为什么错误发现时机如此重要图中列出的设计成本估计依次约为 7nm 的 2.49 亿美元、5nm 的 4.49 亿美元、3nm 的 5.81 亿美元和 2nm 的 7.25 亿美元。这些数字来自论文引用的外部估计描述的是复杂芯片的设计成本背景。高投入使检查前置具有直接的经济意义。一份错误候选刚生成时处理成本可能很小当它进入集成、长时间工具运行和后期交付后再回退就会牵动更多工作。因此自动化任务的收益需要同时考虑候选生成速度、检查成本和后续返工。论文还指出AI 可能产生不符合工程师熟悉模式的结构。过去依赖经验辨认常见拓扑的做法在这种情况下会遇到困难。解释设计时需要回到功能性质、结构影响和测量结果它怎样满足要求改变了什么代价后续人员怎样维护。四、AI、固定程序与工程直觉怎样配合把每一步都交给模型会持续引入推理开销和运行波动。论文 §4.2 提出的区分很实用AI 可以参与开发工具也可以成为工具每次运行时的一部分。选择哪种形式应从任务本身出发。4.1 图 8 区分开发阶段与运行阶段的 AI左侧先借助 AI 编写程序再由程序执行设计任务右侧把模型放进运行过程让它根据输入和反馈持续选择行动。两种方式可以组合但需要承担不同的成本和调试责任。以时序报告为例格式稳定后提取起终点、计算数值变化、按路径分组都可以用固定程序完成。面对多个指标同时异常、需要提出原因假设时模型才可能提供额外的分析价值。这样分配任务也使数值计算与解释可以分别检查。任务适合固定程序承担的部分可以交给模型的部分回归报告比较读取结果、对齐条目、计算差异解释异常组合、提出排查假设约束检查按明确规则检查对象与配置结合设计意图识别潜在冲突需求整理检查已定义字段和格式发现歧义、遗漏与条件不一致设计空间探索执行评估、记录配置和结果生成候选、选择下一批探索方向4.2 原文表 2 的重点是迁移已有工程判断芯片工程师已经习惯对运行时间、PPA 和资源使用形成直觉哪些分析很快哪些流程需要排队增加寄存器可能改善哪些路径又会增加哪些代价共享逻辑能够节省资源却可能改变吞吐或控制复杂度。作者主张把这些判断延伸到 AI 工作流在原有芯片工程经验上建立新能力。例如让 Agent 降低功耗时需要说明允许采用哪些技术、使用哪组活动数据、时序和面积有什么限制以及功能怎样保持。让 Agent 优化性能时需要同时说明频率、延迟和吞吐的关系。任务中的这些条件来自对电路和系统的理解。资源判断也扩大了范围。模型 token、计算节点、EDA 许可证、工具运行和人工复核都可能消耗预算。一个较低成本的模型若频繁触发无效的完整重跑总任务成本仍可能较高一个高预算模型若只在少数困难步骤使用也可能减少返工。需要比较的是完成有效任务的总成本。对长时间运行的 EDA 作业这还包括等待和调度。增加 Agent 的并发数可以增加候选和提交但不能增加已有许可证池的容量。当工具已经满负荷运行时更多提交可能只增加排队。4.3 图 9 把持续实验与识别技术突破连接起来图中的阶跃表示一种可能情形许多工具和组件分别成熟后通过组合使过去难以完成的任务变得可行。一个流程可能长期卡在获取中间状态、理解报错或恢复会话上这些连接补齐以后端到端能力才会表现出来。作者因此强调持续实验同时强调需要理解原来的难题在哪里。判断一种方法是否取得进展应观察它在什么任务、预算和完成条件下跨过了原有瓶颈。一次成功演示、通过一个局部检查、完成完整流程和交付可集成结果分别对应不同的能力范围。这将基本功与技术选择联系起来。理解时序收敛、混合信号协同或工艺变化中的困难才能判断一个新系统解决了哪一部分问题理解已有算法和工具才能发现哪些工作可以直接复用。五、商业 EDA、开源工具与代理模型怎样分工芯片 Agent 的可扩展性受到工具运行时间和许可证数量的直接影响。论文 §5.1 预期快速探索与最终检查会使用不同层次的工具。这个观点的工程价值在于把候选数量、评价成本和最终交付联系起来。读这张图时要分别看两个维度。横轴比较商业许可约束和开源工具的使用条件纵轴比较较高精度评价和较快近似评价。许可证决定可获得性和并发约束模型精度决定结果能支持哪些判断两者并不是同一个问题。原文用 cycle accurate model 标示较高精度一端主要表达精度与速度的取舍。实际的 STA、LVS 和其他 signoff 检查具有不同的计算对象不能都按周期精确仿真理解。选择工具时应直接看所需模型、检查项目、工艺支持和交付要求。对已有商业交付要求的项目可以由认可的 EDA 流程建立交付基线再把开源工具和代理模型接入适合的探索环节。快速结果能承担什么决定取决于它与基线在相应任务上的对应关系。5.1 correlation 需要围绕实际决定建立如果快速模型只用于把候选排序最重要的是能否保留值得深算的方案如果用于预测某个硬性阈值阈值附近的错误分类会更重要如果要比较 PPA 的小幅改进还需要关注误差是否已经大于改进本身。一个整体误差指标很难同时回答这些问题。快速评估的用途应观察的对应关系后续处理排除明显不合适的候选是否误删基线评价较好的方案保留进入详细评价的候选空间给候选排序排序是否稳定优质候选能否进入前列对排名靠前者运行更高精度评价预测约束是否满足阈值附近的漏检与误报对接近边界的结果补充精确检查估计优化幅度误差与预期收益的相对大小在同一基线条件下确认实际变化例如在一组微架构候选中代理模型可能足以帮助筛选面积明显偏大的方案到了几个接近的候选之间它的误差就可能影响排序。此时将少量候选送入详细实现比要求同一个近似模型同时承担探索和最终验收更合理。5.2 交付结果沿认可的检查路径确认工具层次之间需要传递配置和结果避免同名指标被直接比较。前端估算面积与物理实现面积、不同 corner 的 slack、不同活动数据下的功耗各自带有条件。只有条件对齐快速评价与生产评价之间的差异才有解释价值。工具组合的收益来自减少不必要的昂贵运行同时保留交付所需的检查。对芯片 Agent 而言能够更快提出候选只是前半段能力能够把少量有价值的候选送到正确的工具和检查路径才把探索效率连接到了工程交付。六、工具接口与 Agent 分工决定知识能否组合工具可以运行并不意味着一个陌生调用者就能正确使用它。EDA 姆的默认行为、适用版本、运行状态和结果含义长期依靠手册与工程师经验共同解释。论文 §5.2 把这种解释工作看作工具厂商在 AI 原生时代需要承担的一部分。6.1 图 11工具厂商应交付可直接使用的知识左侧由工程师读手册、手工调用工具中间由客户把手册整理成模型上下文和技能右侧则由厂商整理并验证这些材料再供不同客户使用。作者关注的是一项重复成本每个客户都重新解释同一套工具语义既耗时也容易产生不一致。将手册切分后接入检索可以帮助找到相关内容要形成可调用能力还需要表达命令的输入要求、参数含义、副作用、异常行为和版本差异。知道一条命令存在还需要进一步理解何时能够调用它以及怎样使用返回结果。以长时间运行的 EDA 作业为例提交成功只说明调度系统接受了请求。工具是否正常启动、是否完成目标分析、是否得到满足条件的结果是后续不同状态。接口如果把这些状态混成一个成功标志Agent 就可能在结果尚未形成时继续向下游传递结论。MCP 等机制提供调用入口具体的工具语义仍由工具和工作流定义。这使厂商维护的技能、样例和检查方法具有实际价值它们可以减少客户反复解释同一个工具的成本也让升级后的变化有明确来源。6.2 任务划分应对应可检查的产物原文 §5.3 建议将复杂芯片任务分解使每一步更容易描述、执行和验证。这样既能降低单次上下文负担也能针对任务选择模型、程序和工具。例如一次修改可以依次形成需求说明、候选实现、运行配置、检查结果和修改解释。它们之间存在明确依赖没有确定需求就难以判断候选输入版本改变后旧检查也不能继续代表新产物。任务划分应使这些依赖能够被观察和检查。6.3 图 12不同组织交换的是带条件的结果图左侧的学术机构、EDA 厂商、设计公司和开源组织各自提供能力需要维护多个适配关系右侧通过共同接口交换能力。若 n 个参与方都直接两两对接无向连接数可达 n(n-1)/2共同规范有机会减少重复适配。实际难点还包括结果语义。两个系统都返回 PASS可能一个完成了 lint另一个完成了指定模式的 CDC 检查两个系统都返回 coverage也可能分别指代码、功能或性质覆盖。字段相同结论覆盖的内容仍可能不同。论文因此强调把已完成检查的保证、证明以及失败信息传给下游。这个观点可以具体落实为几类交接内容检查针对哪个设计版本采用什么配置覆盖哪些范围存在什么豁免结果及日志在哪里。下游据此判断哪些结果能够复用哪些输入变化要求重新检查。证据能够随产物一起传递复用才不会退化为重新相信一段文字。七、基本功训练需要对应新的工程责任到这里论文对人才培养的要求已经变得具体能够表达任务理解约束选择执行手段解释检查结果并把决定交接给其他人。这些能力同时依赖底层知识和系统视角。图中浅蓝色对应产业实践浅黄色对应教学投入。左边表示既有培养与工作内容的关系右边表示 AI 进入后各层次工作可能发生不均匀变化。条形与箭头是示意重点在于培养结构需要随责任变化调整。自下而上的训练帮助工程师理解器件、电路、逻辑和实现约束怎样影响系统。自上而下的训练则要求从目标出发分解规格、接口、资源和验收条件。论文主张重新平衡两者使学生能够承担规格表达和验证组织同时保留识别底层错误所需的知识。7.1 能定义任务也要能识别错误“基础学到什么程度”应与承担的判断联系起来。评估一个复位方案需要理解状态、时钟和释放条件评估流水线调整需要理解延迟、吞吐、协议和时序判断一份功耗结果需要理解其工作负载和活动条件。只有看见可能失效的方式规格和检查才容易完整。这也是作者坚持实践训练的原因。教材通常把条件整理得比较清楚真实工作还包含工具环境、非理想输入、缺失上下文和跨团队依赖。亲手定位过一次失败能够帮助学习者建立对异常的识别能力。7.2 原文的考核建议落在“解释与验证”上原文 §6.2 给出了一种评分安排的例子允许 AI 参与的作业和实验占 10% 至 20%受监考且不能使用设备的考试占 80% 至 90%。作者用它说明怎样调整学习激励使基础掌握与 AI 实践同时得到评价。更直接的例子是 INT8 MAC。学生可以借助 AI 生成 Verilog但要解释位宽、符号扩展、累加范围、溢出处理和结构取舍。两个 8 位有符号数的乘积通常使用 16 位表示累加器还要根据累加项数和溢出策略确定范围。代码能够编译并没有回答这些设计问题。7.3 原文表 3 连接了传统课程与 Agent 工程能力基础在 AI 芯片工作流中的作用具体体现芯片设计基础判断功能、物理和 PPA 约束知道一个局部改动影响哪些条件软件工程管理脚本、组件、版本和回归输入与修改可追溯失败能够重现算法与复杂度拆分问题选择精确或近似方法识别直接编程即可解决的步骤规格与验证表达意图并构造评价条件从失效场景反推性质、测试和约束技术沟通说明设计决定并推动采用让上下游理解取舍及其依据体系结构与系统设计处理组件依赖和整体目标发现局部优化对系统行为的影响随机过程处理模型与搜索的运行波动比较多次运行分析失败分布实验方法与实践识别改进并定位实际问题对齐基线、预算和输入解释结果这里尤其值得重视软件工程和随机过程。芯片 Agent 本身是软件系统需要版本管理、模块化和回归其内部又包含非确定性的模型行为需要用重复实验、运行记录和受约束的执行方式来理解波动。八、科研成果如何从可阅读走向可复用论文最后把前述知识、工具和验证问题带入科研。研究者同样需要搭建流程、解释实验、保存经验并使后来者能够复现和继续使用成果。8.1 AI 可以压缩研究基础工程的搭建时间芯片研究常常先要完成工具接入、模块集成、验证和物理实现之后才具备检验研究假设的条件。作者将这些支撑工作称为 research scaffolding。AI 可以辅助生成脚本、整理运行配置和组织实验使研究者更早进入需要检验的问题。8.2 重新研究旧问题要先判断原来的瓶颈是否改变原文指出部分方向曾受限于过高的工程投入、复杂搜索或一个人难以覆盖的多学科知识。AI 可能改变这些条件使它们值得重新评估。文章举出大型系统、体系结构基准、编译器以及异步电路、替代存储、随机计算和受模拟启发的电路等例子。判断的起点仍是原问题。例如一个方向如果主要卡在实现工具链投入自动化可能降低试验门槛如果主要受器件特性、制造约束或不可忽略的通信代价限制生成实现更快并不会自动改变这些条件。8.3 图 13研究成果同时服务于人和 Agent上半部分先形成研究结果和论文再由工程师阅读、重现并适配到产业流程。图中将人工重现标为劳动密集且容易损失知识的阶段。下半部分把研究成果整理为上下文、技能和工具供后续工作流组合使用。这张图把“能读懂”与“能接着做”之间的距离画了出来。人需要理解问题、方法和证据Agent 要运行方法还需要输入条件、可执行入口、运行步骤和反馈。两种需求可以通过同一套研究材料共同满足。科研交付的扩展方向是让论文中的方法带着运行条件和评价方式进入下一项工作。论文负责说明研究贡献可执行材料帮助贡献被复现、组合和继续改进。8.4 强化学习的机会来自连续决策与延迟反馈RL 问题芯片工程中的表现直接影响奖励延迟早期动作到后端实现后才显现结果难以分辨各步动作的贡献评价昂贵综合、布局布线与 signoff 消耗资源每轮试验需要产生足够有用的信息代理偏差快速评分与最终评价不同搜索可能偏向实际效果较差的方向状态依赖当前动作依赖先前实现和约束过度简化状态会遗漏决定性条件环境变化工艺、IP 或配置改变已有策略需要在新条件下重新评价并非所有自动重试都构成 RL。固定模型在推理时反复读日志、提出修改可以是一种搜索过程策略是否依据奖励更新决定了它与训练方法的关系。九、论文的结论基本功延伸到了工作流和交付物中从全文回看作者讨论的基本功包含两部分一部分是电路、体系结构、验证和实现中的领域知识另一部分是表达问题、检验假设、组织实验、解释结果和协作交付的能力。AI 将更多执行任务自动化以后这两部分知识会更频繁地出现在任务的入口和结果的出口。在入口工程师需要说明设计意图、运行条件、允许修改的范围和评价目标。在执行过程中工具和检查器把这些要求转化为反馈。在出口工程师需要解释改动、确认相应检查并使下游理解结果适用于哪些条件。论文最有持续价值的联系是把个人基本功与组织能力连接了起来。经验被记录为带条件的方法判断被落实为检查工具通过接口组合研究成果带着运行材料交付。这样一位工程师的理解才有机会在离开本人之后继续被使用。对芯片团队而言AI 原生能力可以落实为三件事任务能够说明白结果能够检查清楚经过检验的方法能够继续复用。模型提供了执行和探索的新手段芯片工程积累决定这些手段怎样作用于实际设计。论文部分到这里。原文arXiv:2609.09344v1Vincent T. Lee 等 8 位作者来自 Meta、纽约大学和斯坦福大学。下面是我的部分。十、我的观点先说我们一致的地方先说结论我也是一直认可基本功的这篇论文的核心判断我完全认同。尤其是「隐性经验要转成带条件的知识」「检查工具决定反馈的工程意义」这两条和我这几年做 AI 辅助芯片设计的体感完全一致——我的公众号写过的大部分内容本质上就是在做论文图 1 那件事把脑子里的经验写成 Agent 能用的东西。我的三点不同看法分歧不在「基本功重不重要」——这点没有分歧——而在节奏和重心论文把基本功放在一个相对恒定的位置上我认为 AI 对 EDA 的渗透比论文暗示的更快基本功的内容和用法会跟着变。另外我们站的位置不一样论文作者是 Meta、NYU、斯坦福的视角看到的是开源生态和学术研究能触达的部分我在产业一线看到的是商业 EDA、流片成本和组织现实。视角不同对节奏的判断就不同。另外有一块论文讲得轻、但我认为很重的东西——流片成本、组织问题、国内现状——我也补在后面。分歧一EDA 被攻破只是时间问题论文的谨慎我保留意见论文的通篇语气是「AI 需要人来驾驭基本功决定成败」图 4 讲芯片数据稀缺图 10 讲商业 EDA 的许可证约束整体是谨慎乐观。先把这两张图放回来方便你对照我的说法。△ 分歧点论文与我看法不一致的地方论文认为芯片数据结构性稀缺图 4设计、规格、中间过程难以获取因此 AI 学习工程过程存在双重困难商业 EDA 许可约束下Agent 的可扩展性受限图 10。论文强调工程师基本功是决定性因素。我认为EDA 被攻破是时间问题不是可能性问题。原因很朴素EDA 本质上需要大量数据和大量工程实践来修正而这两样 AI 最不缺——缺的只是时间。论文说芯片数据稀缺这个判断现在是成立的但数据稀缺不是恒定状态工具运行日志、仿真波形、时序报告这些数据每天都在 EDA 公司和芯片公司的服务器上产生一旦有商业模式把它们组织起来比如厂商自营 Agent 平台、数据联盟稀缺性就会被打破。AI 写代码、做工具都没有问题它缺的是实际工程实践的反馈循环而这个循环正在被补上。说得更直白一点论文说的「基本功」我理解为人对工具的调用和经验判断。短期内AI Native 芯片设计确实更多依赖人的经验、人的工作路谱做过什么、踩过什么坑、以及 AI 对既有工具的调用能力。但长期看当工程实践数据循环建立起来天平会向 AI 倾斜。论文把「人的基本功」放在了一个相对恒定的位置上我认为它是移动的。分歧二论文的「superintelligence」是个人能力我更关心组织能力论文讲能力增强的原图是图 6我放在这里。△ 分歧点论文与我看法不一致的地方论文认为图 6 中个人通过 Rules、Skills、Tools、Agents 扩展能力称为 superintelligence——不熟悉向量架构的人也能借助外部知识提出优化。重点在个体能力的增强。我认为个人能力增强我认同但它不是主要矛盾。我在一线看到的瓶颈是组织AI Native 设计团队和传统团队借用 AI 做设计差别不在个人用不用 AI而在团队分工和整体平衡。同样一组 Agent放在一个把经验沉淀成 Skills、有 Golden Flow、有证据审查流程的组织里和放在一个只让个人各自挂个 Copilot 的组织里产出是天壤之别。论文图 1 讲的隐性知识显性化落到实践中首先是组织工程不是个人工程。这也是我为什么在公司内部一直在推的东西不只是工具选型——是流程和分工的重构。分歧三对商业 EDA 的地位我比论文更现实论文讲工具分层的原图是图 10放在这里对照。△ 分歧点论文与我看法不一致的地方论文认为商业 EDA、开源工具、代理模型分层协作商业流程建立交付基线开源和代理模型做快速探索图 10、§5.1。我认为方向我同意但我补一个现实约束流片是很耗钱的耗钱就代表没有人想第一个吃螃蟹。商业 EDA 的 signoff 地位短期内不会被动摇不是技术原因是责任原因——出了问题谁兜底。论文讲的是技术上的最优分层实际落地是经济和责任上的折中。开源工具要进入 signoff 路径先要回答的不是精度问题是出了 bug 谁负责的问题。这也是为什么我认为 EDA 厂商自己推 Agent 平台会比第三方推更有优势数据、责任、更新节奏都在他们手里。论文没细讲、但我认为关键的两件事我的补充流片成本是最硬的过滤器论文图 7 讲先进节点设计成本7nm 2.49 亿、5nm 4.49 亿、3nm 5.81 亿、2nm 7.25 亿美元。但论文没有展开的是流片成本决定了 AI for EDA 的落地速度。变是一定会变的但需要时间——因为没有人愿意拿几亿人民币的流片去试一个新方法。所以你会看到行业的真实状态是「态度很 Open行动很谨慎」大家都在试点、都在评估但真正进主流程的少。这不是技术不行是风险收益算不过来。我的补充系统公司做芯片基因比钱更重要行业分工确实在变云厂商、车企、互联网公司都在自己做芯片。但我的观察是很多公司没有做硬件或做芯片的基因。互联网公司的芯片 team 可能一直都在但人换了一茬又一茬车厂也是。根子上是上层意志不坚定——这些公司的老板不是做芯片出身想做又不想很花钱地做就会摇摆。方向不清晰导致团队反复重建芯片产品即使做出来也不会有竞争力。对传统芯片设计公司的冲击我认为相对较小——甚至传统芯片公司相对这些新玩家是有优势的。真正的压力来自两头一边是系统厂自研芯片一边是 AI 加持下的新兴公司包夹。传统芯片公司如果不变很快就会沦为第三方服务商。第三方服务不代表不赚钱但成长空间有限——当你技术不是最领先、又没有博通那样的护城河时你干的就是苦力活。十一、最后这篇论文值得读不是因为它给了答案而是它把问题问对了AI 原生时代芯片工程师的基本功不是变不重要了而是换了位置——从「执行」挪到「定义、检查、交接」。再强调一次我是认可基本功的一直是。我和论文的分歧只在节奏——论文认为基本功是恒定的锚我认为它是移动的地板EDA 被攻破只是时间问题基本功的内容会随着 AI 渗透不断更新。但在「怎么干」上我们没有分歧把经验变成带条件的知识把检查当作工程底线把交付做成可复用的资产。短期靠人的经验弥补 AI 的工程实践缺口靠 EDA 工具做客观独立的第三方裁判长期把人从执行里解放出来去做定义问题、组织证据、判断边界、承担责任的事。论文在参考文献里说了一句大意芯片工程的积累决定 AI 手段怎样作用于实际设计。这句我完全同意也是我整个公众号的立足点。最后问你一个问题你看完论文的判断和我的分歧点站哪边你觉得 EDA 被 AI 攻破是五年内的事还是十年以上的事评论区聊聊我想看看大家的时间预期。· · ·芯片是视角AI 是目的地。关注「芯片人-晒 AI 笔记」
arXiv:2609.09344 论文解读 我的观点芯片人看AI · 论文精读 约9000字 / 阅读约22分钟AI Native芯片设计EDA论文解读基本功工程经验隐性知识工具链验证人才培养芯片工程师arXiv一篇 Meta、纽约大学和斯坦福合写的论文讲 AI 原生时代芯片工程师还需要哪些基本功。前半部分我把论文核心内容原样搬给你含 14 张原文截图后半部分是我的看法——有三处我和论文的观点不完全一致都标了出来。写在前面这是一篇论文解读也是一篇读后感。论文来自 Meta、纽约大学和斯坦福2026 年 9 月挂在 arXiv 上题目直译过来是《学术界 × 产业界AI 原生时代芯片设计基本功的作用》。Meta 的团队在第一线用 AI 做芯片他们讲「模型越来越会写 RTL 之后真正稀缺的能力是什么」比纯学术视角更值得听。前半部分是论文的完整解读我原样搬过来内容不做修改——它讲的问题值得每个芯片工程师认真读一遍。后半部分是我的观点。有三处我和论文的看法不完全一致我用专门的标注框标了出来你看到橙色框就是分歧点。报告重点论文的五个核心判断论文的核心判断是AI 越深入芯片设计工程师越需要掌握设计原理、表达设计意图、检验结果并解释取舍。这些基本功决定了任务怎样交给 AI以及 AI 产生的结果能否进入工程流程。一、实现加速会把瓶颈推向规格、验证和协作。生成 RTL 的速度提高以后需求是否完整、修改是否满足系统约束、上下游是否接受结果将更直接地影响交付周期。二、隐性经验需要转化为带条件的知识。一条约束、一项豁免或一个优化方法只有同时保留理由、适用范围和检查方法才有条件被其他工程师和 Agent 复用。三、检查工具决定反馈是否有工程意义。仿真、形式验证、STA 和物理检查各自回答不同问题正确选择检查对象、假设和输入比得到一个 PASS 标志更重要。四、快速探索需要与交付基线建立联系。商业 EDA、开源工具和代理模型可以承担不同阶段的工作。工具之间的 correlation 决定快速评估能用于哪些判断。五、人才培养和科研交付都要面向实际使用。学生需要解释和纠正 AI 结果研究成果需要同时提供方法、实现、运行条件和评价方式让后续使用者能够接着工作。全文可以沿着这条关系理解把经验表达出来把候选结果检查清楚再把经过检验的方法交给下一位使用者。一、实现速度提高以后工程瓶颈会移到哪里一次时序优化可以很好地说明这个问题。Agent 发现关键路径过长在数据通路中增加一级寄存器重新运行工具后setup slack 改善了。接下来的问题却属于系统设计接口是否允许增加一个周期valid 与 data 是否仍然对齐背压是否改变复位后的首笔事务能否正确完成。只有这些条件也满足局部改动才有机会被接受。芯片工程里有大量这样的决定。执行一次修改与判断修改是否合理依赖不同层次的能力。随着候选实现更容易获得后者会占据更大的工作比重。这正是论文讨论基本功的出发点把人的职责放到整个设计和交付过程里理解。1.1 图 5 展示的是代码任务能力的变化论文用 CVDP 的代码生成和代码理解成绩说明模型能力正在变化。两张子图观察的是不同任务纵轴都是已解决问题的比例横轴是结果发布日期。原图采用的是截至 2026 年 8 月的成绩快照。从左图可以看到代码生成结果大致落在 17% 至 40% 的区间右图的代码理解结果大致落在 57% 至 82%。这两个范围只是对原图点位的粗读。生成一个满足题目要求的实现与理解一段既有代码所需能力和失败方式并不相同。作者据此预期RTL 代码生成会逐步成为更普遍、获取成本更低的能力工程师的工作也将更多转向任务组织和结果判断。图中比较了不同模型的提交结果原图脚注还说明部分提交并未由 Si2 直接运行或验证。因此评价具体模型时需要连同任务集、上下文、工具和预算一起看图中的成功比例不能直接替换成真实项目的交付成功率。同样的变化也会影响 HLS 和硬件 DSL 的价值定位。作者提出当规格到 RTL 的生成能力提升后应重新评估这些语言所提供的生产率收益。工程上还要同时考虑类型约束、领域表达、编译优化和验证方法即使手写 RTL 的工作量下降这些机制仍可能减少规格歧义或限制不合法结构。1.2 局部十倍加速为什么只得到约一点六六倍整体加速原文表 1 引用了一项软件开发者工时研究表中样本为 5,928 人。编码、修复、测试、代码审查和文档五类工作合计占 44%。作者用这组比例说明当其中一部分工作加速后剩余部分会成为更突出的瓶颈。假设工作总量不变只有这 44% 获得十倍加速剩余时间就是 56% 44% / 10 60.4%整体加速为 1 / 0.604约 1.66 倍。按同一个假设计算可以得到下表。被加速部分的速度总耗时相对原来的比例整体加速2 倍78.0%1.28 倍5 倍64.8%1.54 倍10 倍60.4%1.66 倍该部分耗时趋近于零56.0%1.79 倍这里使用的是软件工时比例和简化计算作用是解释瓶颈转移。芯片项目的工期还取决于任务依赖、EDA 运行、许可证排队、IP 交付、集成复核和返工不能从这张表直接取得一个项目加速倍数。对芯片团队更有用的判断是AI 加速的步骤是否位于当前交付的关键路径上。如果代码已经完成项目仍在等待规格确认那么继续提高生成速度的收益有限如果每次修改都需要长时间工具重跑那么减少无效候选和重复运行可能更有价值。二、从隐性经验到 Agent 能够使用的知识实现可以交给别人判断依据却经常留在原设计者脑中。论文列举的典型知识包括时序例外的理由、特定工艺中的处理经验以及某项设计取舍在什么条件下可以接受。这些内容既影响新人接手也决定 Agent 能否获得足够的上下文。2.1 图 1 的变化发生在知识传递路径上图左侧画的是专家向新人传授经验、新人再向下一位新人传授的过程。每一次传递都依赖具体的工作接触是否一起定位过问题是否见过特殊模式是否讨论过当时放弃其他方案的原因。设计文件保存了最终结果却未必保存得出结果的过程。图中间把知识放入共同载体让工程师和 AI 工具都能使用。右侧的曲线表达作者的组织判断显式保存并持续维护知识有利于减少人员变化带来的经验流失。它是一幅概念示意图讨论的是积累机制。以 false path 为例保存一行约束能够重现当时的工具设置却不足以支持后续判断。接手者还需要知道路径在哪种模式下不可能被有效激励是否依赖控制互斥相关假设由哪个检查支撑以及设计改变后何时需要重新审查。能够迁移的是附带理由和条件的经验。按照这个逻辑整理知识记录对象会从“最终文件”扩展到“设计决定”。下表是对这一观点的工程展开。记录内容保留它的作用缺失后的典型问题设计意图与适用模式说明为什么需要这项处理接手者只看到命令无法判断是否仍成立前提与依赖说明结论依赖哪些时钟、复位、电源或协议条件条件改变后继续沿用旧结论修改与被否定方案说明实际做了什么、为何放弃其他选择重复尝试已知无效方案检查与评价结果说明决定得到了什么支持把经验描述当作已完成验证版本与变更触发条件说明何时应重新检查正确经验在新配置下变成错误假设这类知识既可以供人阅读也可以成为 Agent 的输入。其价值不依赖某一种知识库产品关键是记录能否支撑下一次工程决定。2.2 图 4 解释了芯片数据为什么难以形成训练与评价循环原图把软件与硬件样例放在开源生态、学术机构和产业公司三个环境中。硬件数据并非不存在高价值设计及其运行环境往往受保密约定、工艺绑定和工具格式限制。设计离开原有环境以后可能只剩一份 RTL而缺少解释和评价它的条件。论文把这种稀缺进一步分成了几个相互关联的问题。首先是设计和规格难以获取其次是中间过程难以获取包括错误日志、时序分析、候选修改和评审理由再往后给结果打分的环境也可能依赖内部库、专有工具和项目方法学。即使拿到样例也未必能够运行同样的评价。这使芯片 AI 面临一个双重困难模型需要学习工程过程而组织又必须能够判断模型的行动是否有效。扩大公开 RTL 数据可以改善部分代码任务但工业 Agent 还需要获得规格、过程和评价之间的对应关系。对于一项时序优化只有最终网表很难知道最初的违例是什么只有修改脚本很难知道它破坏了哪些其他指标只有一份通过报告又很难知道约束和库是否与目标交付一致。把这些材料关联起来才有可能复用其中的工程经验。2.3 图 6 进一步回答知识留下以后怎样使用图中左侧是 RTL、验证、物理设计和研究领域的专业知识中间是 Rules、Skills、Tools、Agents右侧是不同专业和经验层次的使用者。图 1 关注保存与传递这张图关注知识怎样进入实际任务。这几类载体各有作用。规则表达必须满足的条件技能组织一类任务的步骤和适用范围工具完成计算、转换或检查Agent 根据任务状态选择下一步行动。它们组合起来才可能使一个原本不熟悉该领域的人完成部分工作。作者把这种能力增强称为 superintelligence。在本节语境中它指个人通过外部专业知识和工具扩展能力。例如不熟悉某种向量架构的人可以借助相关知识提出优化再利用工具评价结果。其工程价值首先体现在减少进入陌生领域的成本、提高问题表达质量以及扩大能够尝试的方案范围。对照已有 EDA 和 IP 的发展路径这个观点并不突兀。综合、布局布线和协议 IP 已经把大量专业知识封装在工具与模块中。原文 §2.7 主张在这些已有积累上继续建立 AI 能力。因而把一项经验封装成可调用方法时已有工具、接口和检查结果都应成为它的一部分。三、候选结果怎样获得工程可信度知识能够被调用只解决了任务如何开始。Agent 运行以后还会产生代码、脚本、约束和解释工程师需要判断这些产物满足了什么条件。论文在 §3.4 把芯片工程已有的精确检查手段视为一项优势这些反馈可以用于筛选候选、定位失败并指导下一次修改。3.1 图 2 强调的是复核所需的知识图上半部分把问题交给模型后直接接受结果下半部分加入了人对基本知识的掌握使人能够检验结果。两条路径都使用 AI差异在于使用者是否仍然具备理解和判错的能力。论文将这种把部分任务交给外部工具的行为称为认知卸载。适当卸载可以让人处理更大的问题如果连判断依据也一并放弃使用者就可能无法识别错误方案。工程师不需要重做工具内部的全部计算但需要知道工具回答了哪个问题、采用了哪些条件以及结果与产品要求是什么关系。这一点在验证中尤其具体。同一份含糊需求可以使 DUT 和 testbench 共享同一个错误解释。两者在仿真中相互吻合说明的是它们之间的一致性能否满足产品要求还取决于需求解释和检查器是否正确。验证的独立性来自规格、模型、性质和复核依据不能只按生成了多少文件或调用了多少个 Agent 来判断。3.2 确定的工具结果仍然依赖正确的检查条件把工具接入 Agent 后工程师的一项核心工作是把“怎样判断结果可以接受”写清楚。检查器覆盖的性质、使用的模型和输入条件决定了反馈的含义。原文把等价检查、形式验证、STA、DRC 等列为可供 Agent 使用的反馈。在具体工程中它们的检查对象不同需要分别解释。检查方式能够回答的问题决定结论含义的条件编译、lint代码是否满足语法与所启用的结构规则规则配置、语言支持和输入文件范围仿真被激励的行为是否满足检查器场景、参考模型、检查器与覆盖目标形式属性验证给定假设下声明的性质是否成立假设、性质、抽象及证明完成状态等价检查两个模型在指定条件下是否等价参考模型、映射、约束和比较范围STA指定模式与模型下是否满足时序要求时钟、例外、库、寄生及 cornerDRC、LVS版图是否满足所检查规则、连通性是否一致规则集、器件识别、输入网表与检查范围例如形式工具中的 assume 限定被探索的情况assert 表达需要检查的性质。如果把真实可能发生的行为排除在假设之外证明结果就只对更小的环境成立关键性质没有写入时工具也不会自动补充产品要求。STA 的结果同样依赖输入条件。若 Agent 通过放宽约束或错误增加例外来消除违例报告可能改善电路实际能力却没有相应变化。因此一个时序优化任务需要同时固定比较条件和允许的修改范围。对网表或 RTL 的修改可以进入相应的功能及实现检查对设计约束的修改则需要先判断它是否仍表达原来的需求。把这两类动作混成同一个“降低违例数”目标会使优化方向偏离产品要求。这也是论文观点值得继续展开的地方已有 EDA 检查能够提供反馈而反馈是否适合用作优化目标仍然是一项设计工作。正确性条件、性能目标和资源预算应分别表达避免一个总分掩盖了不可接受的功能变化。3.3 图 7 说明了为什么错误发现时机如此重要图中列出的设计成本估计依次约为 7nm 的 2.49 亿美元、5nm 的 4.49 亿美元、3nm 的 5.81 亿美元和 2nm 的 7.25 亿美元。这些数字来自论文引用的外部估计描述的是复杂芯片的设计成本背景。高投入使检查前置具有直接的经济意义。一份错误候选刚生成时处理成本可能很小当它进入集成、长时间工具运行和后期交付后再回退就会牵动更多工作。因此自动化任务的收益需要同时考虑候选生成速度、检查成本和后续返工。论文还指出AI 可能产生不符合工程师熟悉模式的结构。过去依赖经验辨认常见拓扑的做法在这种情况下会遇到困难。解释设计时需要回到功能性质、结构影响和测量结果它怎样满足要求改变了什么代价后续人员怎样维护。四、AI、固定程序与工程直觉怎样配合把每一步都交给模型会持续引入推理开销和运行波动。论文 §4.2 提出的区分很实用AI 可以参与开发工具也可以成为工具每次运行时的一部分。选择哪种形式应从任务本身出发。4.1 图 8 区分开发阶段与运行阶段的 AI左侧先借助 AI 编写程序再由程序执行设计任务右侧把模型放进运行过程让它根据输入和反馈持续选择行动。两种方式可以组合但需要承担不同的成本和调试责任。以时序报告为例格式稳定后提取起终点、计算数值变化、按路径分组都可以用固定程序完成。面对多个指标同时异常、需要提出原因假设时模型才可能提供额外的分析价值。这样分配任务也使数值计算与解释可以分别检查。任务适合固定程序承担的部分可以交给模型的部分回归报告比较读取结果、对齐条目、计算差异解释异常组合、提出排查假设约束检查按明确规则检查对象与配置结合设计意图识别潜在冲突需求整理检查已定义字段和格式发现歧义、遗漏与条件不一致设计空间探索执行评估、记录配置和结果生成候选、选择下一批探索方向4.2 原文表 2 的重点是迁移已有工程判断芯片工程师已经习惯对运行时间、PPA 和资源使用形成直觉哪些分析很快哪些流程需要排队增加寄存器可能改善哪些路径又会增加哪些代价共享逻辑能够节省资源却可能改变吞吐或控制复杂度。作者主张把这些判断延伸到 AI 工作流在原有芯片工程经验上建立新能力。例如让 Agent 降低功耗时需要说明允许采用哪些技术、使用哪组活动数据、时序和面积有什么限制以及功能怎样保持。让 Agent 优化性能时需要同时说明频率、延迟和吞吐的关系。任务中的这些条件来自对电路和系统的理解。资源判断也扩大了范围。模型 token、计算节点、EDA 许可证、工具运行和人工复核都可能消耗预算。一个较低成本的模型若频繁触发无效的完整重跑总任务成本仍可能较高一个高预算模型若只在少数困难步骤使用也可能减少返工。需要比较的是完成有效任务的总成本。对长时间运行的 EDA 作业这还包括等待和调度。增加 Agent 的并发数可以增加候选和提交但不能增加已有许可证池的容量。当工具已经满负荷运行时更多提交可能只增加排队。4.3 图 9 把持续实验与识别技术突破连接起来图中的阶跃表示一种可能情形许多工具和组件分别成熟后通过组合使过去难以完成的任务变得可行。一个流程可能长期卡在获取中间状态、理解报错或恢复会话上这些连接补齐以后端到端能力才会表现出来。作者因此强调持续实验同时强调需要理解原来的难题在哪里。判断一种方法是否取得进展应观察它在什么任务、预算和完成条件下跨过了原有瓶颈。一次成功演示、通过一个局部检查、完成完整流程和交付可集成结果分别对应不同的能力范围。这将基本功与技术选择联系起来。理解时序收敛、混合信号协同或工艺变化中的困难才能判断一个新系统解决了哪一部分问题理解已有算法和工具才能发现哪些工作可以直接复用。五、商业 EDA、开源工具与代理模型怎样分工芯片 Agent 的可扩展性受到工具运行时间和许可证数量的直接影响。论文 §5.1 预期快速探索与最终检查会使用不同层次的工具。这个观点的工程价值在于把候选数量、评价成本和最终交付联系起来。读这张图时要分别看两个维度。横轴比较商业许可约束和开源工具的使用条件纵轴比较较高精度评价和较快近似评价。许可证决定可获得性和并发约束模型精度决定结果能支持哪些判断两者并不是同一个问题。原文用 cycle accurate model 标示较高精度一端主要表达精度与速度的取舍。实际的 STA、LVS 和其他 signoff 检查具有不同的计算对象不能都按周期精确仿真理解。选择工具时应直接看所需模型、检查项目、工艺支持和交付要求。对已有商业交付要求的项目可以由认可的 EDA 流程建立交付基线再把开源工具和代理模型接入适合的探索环节。快速结果能承担什么决定取决于它与基线在相应任务上的对应关系。5.1 correlation 需要围绕实际决定建立如果快速模型只用于把候选排序最重要的是能否保留值得深算的方案如果用于预测某个硬性阈值阈值附近的错误分类会更重要如果要比较 PPA 的小幅改进还需要关注误差是否已经大于改进本身。一个整体误差指标很难同时回答这些问题。快速评估的用途应观察的对应关系后续处理排除明显不合适的候选是否误删基线评价较好的方案保留进入详细评价的候选空间给候选排序排序是否稳定优质候选能否进入前列对排名靠前者运行更高精度评价预测约束是否满足阈值附近的漏检与误报对接近边界的结果补充精确检查估计优化幅度误差与预期收益的相对大小在同一基线条件下确认实际变化例如在一组微架构候选中代理模型可能足以帮助筛选面积明显偏大的方案到了几个接近的候选之间它的误差就可能影响排序。此时将少量候选送入详细实现比要求同一个近似模型同时承担探索和最终验收更合理。5.2 交付结果沿认可的检查路径确认工具层次之间需要传递配置和结果避免同名指标被直接比较。前端估算面积与物理实现面积、不同 corner 的 slack、不同活动数据下的功耗各自带有条件。只有条件对齐快速评价与生产评价之间的差异才有解释价值。工具组合的收益来自减少不必要的昂贵运行同时保留交付所需的检查。对芯片 Agent 而言能够更快提出候选只是前半段能力能够把少量有价值的候选送到正确的工具和检查路径才把探索效率连接到了工程交付。六、工具接口与 Agent 分工决定知识能否组合工具可以运行并不意味着一个陌生调用者就能正确使用它。EDA 姆的默认行为、适用版本、运行状态和结果含义长期依靠手册与工程师经验共同解释。论文 §5.2 把这种解释工作看作工具厂商在 AI 原生时代需要承担的一部分。6.1 图 11工具厂商应交付可直接使用的知识左侧由工程师读手册、手工调用工具中间由客户把手册整理成模型上下文和技能右侧则由厂商整理并验证这些材料再供不同客户使用。作者关注的是一项重复成本每个客户都重新解释同一套工具语义既耗时也容易产生不一致。将手册切分后接入检索可以帮助找到相关内容要形成可调用能力还需要表达命令的输入要求、参数含义、副作用、异常行为和版本差异。知道一条命令存在还需要进一步理解何时能够调用它以及怎样使用返回结果。以长时间运行的 EDA 作业为例提交成功只说明调度系统接受了请求。工具是否正常启动、是否完成目标分析、是否得到满足条件的结果是后续不同状态。接口如果把这些状态混成一个成功标志Agent 就可能在结果尚未形成时继续向下游传递结论。MCP 等机制提供调用入口具体的工具语义仍由工具和工作流定义。这使厂商维护的技能、样例和检查方法具有实际价值它们可以减少客户反复解释同一个工具的成本也让升级后的变化有明确来源。6.2 任务划分应对应可检查的产物原文 §5.3 建议将复杂芯片任务分解使每一步更容易描述、执行和验证。这样既能降低单次上下文负担也能针对任务选择模型、程序和工具。例如一次修改可以依次形成需求说明、候选实现、运行配置、检查结果和修改解释。它们之间存在明确依赖没有确定需求就难以判断候选输入版本改变后旧检查也不能继续代表新产物。任务划分应使这些依赖能够被观察和检查。6.3 图 12不同组织交换的是带条件的结果图左侧的学术机构、EDA 厂商、设计公司和开源组织各自提供能力需要维护多个适配关系右侧通过共同接口交换能力。若 n 个参与方都直接两两对接无向连接数可达 n(n-1)/2共同规范有机会减少重复适配。实际难点还包括结果语义。两个系统都返回 PASS可能一个完成了 lint另一个完成了指定模式的 CDC 检查两个系统都返回 coverage也可能分别指代码、功能或性质覆盖。字段相同结论覆盖的内容仍可能不同。论文因此强调把已完成检查的保证、证明以及失败信息传给下游。这个观点可以具体落实为几类交接内容检查针对哪个设计版本采用什么配置覆盖哪些范围存在什么豁免结果及日志在哪里。下游据此判断哪些结果能够复用哪些输入变化要求重新检查。证据能够随产物一起传递复用才不会退化为重新相信一段文字。七、基本功训练需要对应新的工程责任到这里论文对人才培养的要求已经变得具体能够表达任务理解约束选择执行手段解释检查结果并把决定交接给其他人。这些能力同时依赖底层知识和系统视角。图中浅蓝色对应产业实践浅黄色对应教学投入。左边表示既有培养与工作内容的关系右边表示 AI 进入后各层次工作可能发生不均匀变化。条形与箭头是示意重点在于培养结构需要随责任变化调整。自下而上的训练帮助工程师理解器件、电路、逻辑和实现约束怎样影响系统。自上而下的训练则要求从目标出发分解规格、接口、资源和验收条件。论文主张重新平衡两者使学生能够承担规格表达和验证组织同时保留识别底层错误所需的知识。7.1 能定义任务也要能识别错误“基础学到什么程度”应与承担的判断联系起来。评估一个复位方案需要理解状态、时钟和释放条件评估流水线调整需要理解延迟、吞吐、协议和时序判断一份功耗结果需要理解其工作负载和活动条件。只有看见可能失效的方式规格和检查才容易完整。这也是作者坚持实践训练的原因。教材通常把条件整理得比较清楚真实工作还包含工具环境、非理想输入、缺失上下文和跨团队依赖。亲手定位过一次失败能够帮助学习者建立对异常的识别能力。7.2 原文的考核建议落在“解释与验证”上原文 §6.2 给出了一种评分安排的例子允许 AI 参与的作业和实验占 10% 至 20%受监考且不能使用设备的考试占 80% 至 90%。作者用它说明怎样调整学习激励使基础掌握与 AI 实践同时得到评价。更直接的例子是 INT8 MAC。学生可以借助 AI 生成 Verilog但要解释位宽、符号扩展、累加范围、溢出处理和结构取舍。两个 8 位有符号数的乘积通常使用 16 位表示累加器还要根据累加项数和溢出策略确定范围。代码能够编译并没有回答这些设计问题。7.3 原文表 3 连接了传统课程与 Agent 工程能力基础在 AI 芯片工作流中的作用具体体现芯片设计基础判断功能、物理和 PPA 约束知道一个局部改动影响哪些条件软件工程管理脚本、组件、版本和回归输入与修改可追溯失败能够重现算法与复杂度拆分问题选择精确或近似方法识别直接编程即可解决的步骤规格与验证表达意图并构造评价条件从失效场景反推性质、测试和约束技术沟通说明设计决定并推动采用让上下游理解取舍及其依据体系结构与系统设计处理组件依赖和整体目标发现局部优化对系统行为的影响随机过程处理模型与搜索的运行波动比较多次运行分析失败分布实验方法与实践识别改进并定位实际问题对齐基线、预算和输入解释结果这里尤其值得重视软件工程和随机过程。芯片 Agent 本身是软件系统需要版本管理、模块化和回归其内部又包含非确定性的模型行为需要用重复实验、运行记录和受约束的执行方式来理解波动。八、科研成果如何从可阅读走向可复用论文最后把前述知识、工具和验证问题带入科研。研究者同样需要搭建流程、解释实验、保存经验并使后来者能够复现和继续使用成果。8.1 AI 可以压缩研究基础工程的搭建时间芯片研究常常先要完成工具接入、模块集成、验证和物理实现之后才具备检验研究假设的条件。作者将这些支撑工作称为 research scaffolding。AI 可以辅助生成脚本、整理运行配置和组织实验使研究者更早进入需要检验的问题。8.2 重新研究旧问题要先判断原来的瓶颈是否改变原文指出部分方向曾受限于过高的工程投入、复杂搜索或一个人难以覆盖的多学科知识。AI 可能改变这些条件使它们值得重新评估。文章举出大型系统、体系结构基准、编译器以及异步电路、替代存储、随机计算和受模拟启发的电路等例子。判断的起点仍是原问题。例如一个方向如果主要卡在实现工具链投入自动化可能降低试验门槛如果主要受器件特性、制造约束或不可忽略的通信代价限制生成实现更快并不会自动改变这些条件。8.3 图 13研究成果同时服务于人和 Agent上半部分先形成研究结果和论文再由工程师阅读、重现并适配到产业流程。图中将人工重现标为劳动密集且容易损失知识的阶段。下半部分把研究成果整理为上下文、技能和工具供后续工作流组合使用。这张图把“能读懂”与“能接着做”之间的距离画了出来。人需要理解问题、方法和证据Agent 要运行方法还需要输入条件、可执行入口、运行步骤和反馈。两种需求可以通过同一套研究材料共同满足。科研交付的扩展方向是让论文中的方法带着运行条件和评价方式进入下一项工作。论文负责说明研究贡献可执行材料帮助贡献被复现、组合和继续改进。8.4 强化学习的机会来自连续决策与延迟反馈RL 问题芯片工程中的表现直接影响奖励延迟早期动作到后端实现后才显现结果难以分辨各步动作的贡献评价昂贵综合、布局布线与 signoff 消耗资源每轮试验需要产生足够有用的信息代理偏差快速评分与最终评价不同搜索可能偏向实际效果较差的方向状态依赖当前动作依赖先前实现和约束过度简化状态会遗漏决定性条件环境变化工艺、IP 或配置改变已有策略需要在新条件下重新评价并非所有自动重试都构成 RL。固定模型在推理时反复读日志、提出修改可以是一种搜索过程策略是否依据奖励更新决定了它与训练方法的关系。九、论文的结论基本功延伸到了工作流和交付物中从全文回看作者讨论的基本功包含两部分一部分是电路、体系结构、验证和实现中的领域知识另一部分是表达问题、检验假设、组织实验、解释结果和协作交付的能力。AI 将更多执行任务自动化以后这两部分知识会更频繁地出现在任务的入口和结果的出口。在入口工程师需要说明设计意图、运行条件、允许修改的范围和评价目标。在执行过程中工具和检查器把这些要求转化为反馈。在出口工程师需要解释改动、确认相应检查并使下游理解结果适用于哪些条件。论文最有持续价值的联系是把个人基本功与组织能力连接了起来。经验被记录为带条件的方法判断被落实为检查工具通过接口组合研究成果带着运行材料交付。这样一位工程师的理解才有机会在离开本人之后继续被使用。对芯片团队而言AI 原生能力可以落实为三件事任务能够说明白结果能够检查清楚经过检验的方法能够继续复用。模型提供了执行和探索的新手段芯片工程积累决定这些手段怎样作用于实际设计。论文部分到这里。原文arXiv:2609.09344v1Vincent T. Lee 等 8 位作者来自 Meta、纽约大学和斯坦福大学。下面是我的部分。十、我的观点先说我们一致的地方先说结论我也是一直认可基本功的这篇论文的核心判断我完全认同。尤其是「隐性经验要转成带条件的知识」「检查工具决定反馈的工程意义」这两条和我这几年做 AI 辅助芯片设计的体感完全一致——我的公众号写过的大部分内容本质上就是在做论文图 1 那件事把脑子里的经验写成 Agent 能用的东西。我的三点不同看法分歧不在「基本功重不重要」——这点没有分歧——而在节奏和重心论文把基本功放在一个相对恒定的位置上我认为 AI 对 EDA 的渗透比论文暗示的更快基本功的内容和用法会跟着变。另外我们站的位置不一样论文作者是 Meta、NYU、斯坦福的视角看到的是开源生态和学术研究能触达的部分我在产业一线看到的是商业 EDA、流片成本和组织现实。视角不同对节奏的判断就不同。另外有一块论文讲得轻、但我认为很重的东西——流片成本、组织问题、国内现状——我也补在后面。分歧一EDA 被攻破只是时间问题论文的谨慎我保留意见论文的通篇语气是「AI 需要人来驾驭基本功决定成败」图 4 讲芯片数据稀缺图 10 讲商业 EDA 的许可证约束整体是谨慎乐观。先把这两张图放回来方便你对照我的说法。△ 分歧点论文与我看法不一致的地方论文认为芯片数据结构性稀缺图 4设计、规格、中间过程难以获取因此 AI 学习工程过程存在双重困难商业 EDA 许可约束下Agent 的可扩展性受限图 10。论文强调工程师基本功是决定性因素。我认为EDA 被攻破是时间问题不是可能性问题。原因很朴素EDA 本质上需要大量数据和大量工程实践来修正而这两样 AI 最不缺——缺的只是时间。论文说芯片数据稀缺这个判断现在是成立的但数据稀缺不是恒定状态工具运行日志、仿真波形、时序报告这些数据每天都在 EDA 公司和芯片公司的服务器上产生一旦有商业模式把它们组织起来比如厂商自营 Agent 平台、数据联盟稀缺性就会被打破。AI 写代码、做工具都没有问题它缺的是实际工程实践的反馈循环而这个循环正在被补上。说得更直白一点论文说的「基本功」我理解为人对工具的调用和经验判断。短期内AI Native 芯片设计确实更多依赖人的经验、人的工作路谱做过什么、踩过什么坑、以及 AI 对既有工具的调用能力。但长期看当工程实践数据循环建立起来天平会向 AI 倾斜。论文把「人的基本功」放在了一个相对恒定的位置上我认为它是移动的。分歧二论文的「superintelligence」是个人能力我更关心组织能力论文讲能力增强的原图是图 6我放在这里。△ 分歧点论文与我看法不一致的地方论文认为图 6 中个人通过 Rules、Skills、Tools、Agents 扩展能力称为 superintelligence——不熟悉向量架构的人也能借助外部知识提出优化。重点在个体能力的增强。我认为个人能力增强我认同但它不是主要矛盾。我在一线看到的瓶颈是组织AI Native 设计团队和传统团队借用 AI 做设计差别不在个人用不用 AI而在团队分工和整体平衡。同样一组 Agent放在一个把经验沉淀成 Skills、有 Golden Flow、有证据审查流程的组织里和放在一个只让个人各自挂个 Copilot 的组织里产出是天壤之别。论文图 1 讲的隐性知识显性化落到实践中首先是组织工程不是个人工程。这也是我为什么在公司内部一直在推的东西不只是工具选型——是流程和分工的重构。分歧三对商业 EDA 的地位我比论文更现实论文讲工具分层的原图是图 10放在这里对照。△ 分歧点论文与我看法不一致的地方论文认为商业 EDA、开源工具、代理模型分层协作商业流程建立交付基线开源和代理模型做快速探索图 10、§5.1。我认为方向我同意但我补一个现实约束流片是很耗钱的耗钱就代表没有人想第一个吃螃蟹。商业 EDA 的 signoff 地位短期内不会被动摇不是技术原因是责任原因——出了问题谁兜底。论文讲的是技术上的最优分层实际落地是经济和责任上的折中。开源工具要进入 signoff 路径先要回答的不是精度问题是出了 bug 谁负责的问题。这也是为什么我认为 EDA 厂商自己推 Agent 平台会比第三方推更有优势数据、责任、更新节奏都在他们手里。论文没细讲、但我认为关键的两件事我的补充流片成本是最硬的过滤器论文图 7 讲先进节点设计成本7nm 2.49 亿、5nm 4.49 亿、3nm 5.81 亿、2nm 7.25 亿美元。但论文没有展开的是流片成本决定了 AI for EDA 的落地速度。变是一定会变的但需要时间——因为没有人愿意拿几亿人民币的流片去试一个新方法。所以你会看到行业的真实状态是「态度很 Open行动很谨慎」大家都在试点、都在评估但真正进主流程的少。这不是技术不行是风险收益算不过来。我的补充系统公司做芯片基因比钱更重要行业分工确实在变云厂商、车企、互联网公司都在自己做芯片。但我的观察是很多公司没有做硬件或做芯片的基因。互联网公司的芯片 team 可能一直都在但人换了一茬又一茬车厂也是。根子上是上层意志不坚定——这些公司的老板不是做芯片出身想做又不想很花钱地做就会摇摆。方向不清晰导致团队反复重建芯片产品即使做出来也不会有竞争力。对传统芯片设计公司的冲击我认为相对较小——甚至传统芯片公司相对这些新玩家是有优势的。真正的压力来自两头一边是系统厂自研芯片一边是 AI 加持下的新兴公司包夹。传统芯片公司如果不变很快就会沦为第三方服务商。第三方服务不代表不赚钱但成长空间有限——当你技术不是最领先、又没有博通那样的护城河时你干的就是苦力活。十一、最后这篇论文值得读不是因为它给了答案而是它把问题问对了AI 原生时代芯片工程师的基本功不是变不重要了而是换了位置——从「执行」挪到「定义、检查、交接」。再强调一次我是认可基本功的一直是。我和论文的分歧只在节奏——论文认为基本功是恒定的锚我认为它是移动的地板EDA 被攻破只是时间问题基本功的内容会随着 AI 渗透不断更新。但在「怎么干」上我们没有分歧把经验变成带条件的知识把检查当作工程底线把交付做成可复用的资产。短期靠人的经验弥补 AI 的工程实践缺口靠 EDA 工具做客观独立的第三方裁判长期把人从执行里解放出来去做定义问题、组织证据、判断边界、承担责任的事。论文在参考文献里说了一句大意芯片工程的积累决定 AI 手段怎样作用于实际设计。这句我完全同意也是我整个公众号的立足点。最后问你一个问题你看完论文的判断和我的分歧点站哪边你觉得 EDA 被 AI 攻破是五年内的事还是十年以上的事评论区聊聊我想看看大家的时间预期。· · ·芯片是视角AI 是目的地。关注「芯片人-晒 AI 笔记」
