1. 从早点摊这个比喻说起智能体介入芯片设计到底意味着什么AI 早点摊这个系列名字起得挺有意思它把每天发生的一件AI领域的新鲜事比作早点摊上的一份早点——趁热吃吃完就走不搞长篇大论。10月3日这一期的主题是智能体接手芯片设计这个选题本身就值得好好聊一聊。先说清楚这里说的智能体是什么。在芯片设计这个语境下智能体不是指某个单一的AI模型而是指能够自主规划、调用工具、迭代优化的一类AI系统。它和传统的AI辅助设计有本质区别传统方式是人设定好流程AI在某个环节里做预测或分类而智能体是给它一个目标比如把这个模块的功耗降低15%同时保持时序收敛它自己去拆解任务、调用EDA工具、分析结果、调整参数循环往复直到达标或者确认做不到。芯片设计为什么适合让智能体介入这个行业的痛点非常集中。一颗现代SoC的设计周期动辄18到24个月其中验证环节占掉一半以上的时间。设计工程师每天大量精力花在重复性的迭代上改一版RTL跑一遍综合看时序报告调约束再跑一遍。这些工作的创造性成分不高但门槛不低——需要理解时序、功耗、面积之间的权衡关系。这恰好是智能体擅长的事情有明确的目标函数有可调用的工具链有可量化的反馈信号。但接手这个词需要拆开看。目前智能体在芯片设计里能接手的主要是局部优化循环和设计空间探索这两类任务。全局架构定义、关键IP的微架构设计、模拟电路的核心拓扑选择这些仍然高度依赖资深工程师的判断。所以更准确的说法是智能体接手了芯片设计流程中那些高频、有明确反馈、可量化评估的环节把工程师从重复劳动里解放出来去做更需要直觉和经验的决定。这个趋势对从业者的影响是实实在在的。如果你是一个数字后端工程师每天的工作就是跑PR流程、修DRC、调时序那未来三到五年内这些工作的很大一部分会被智能体接管。但如果你能理解智能体在做什么、为什么这么做、什么时候它会出错你的价值反而会放大——因为你会成为那个管理智能体的人。2. 智能体在芯片设计流程中具体能干什么按环节拆解2.1 RTL生成与修改从自然语言到可综合代码这是目前最热闹的方向。给定一个模块的功能描述让大模型生成RTL代码然后自动跑仿真验证功能正确性。听起来很美好但实际落地时坑不少。我试过用几个主流的大模型生成一个简单的AXI4-Lite从机接口。第一次生成的代码功能基本正确但存在两个问题一是复位逻辑用了异步复位同步释放的标准写法但复位极性搞反了二是时序逻辑里混用了阻塞赋值和非阻塞赋值。这两个问题在仿真里不一定暴露但综合出来就是错的。所以智能体做RTL生成关键不在于能不能生成而在于生成之后怎么验证。一个靠谱的智能体工作流应该是这样的生成RTL → 自动生成testbench → 跑仿真 → 如果失败分析失败原因 → 修改RTL → 再跑。这个循环里仿真器就是智能体的眼睛没有仿真反馈的RTL生成就是盲写。目前比较务实的做法是让智能体做RTL的局部修改而不是从零生成整个模块。比如把这个模块里的单端口RAM改成双端口RAM、给这个状态机加一个低功耗休眠状态、把这段组合逻辑拆成两级流水。这类任务边界清晰验证起来也容易。2.2 验证用例生成覆盖率的自动补全验证是芯片设计里最耗人力的环节。一个中等规模的IP验证工程师要写几百个定向测试用例再加上约束随机测试才能把功能覆盖率推到95%以上。智能体在这里能做的事情很具体分析覆盖率报告找出没覆盖到的点自动生成针对性的测试用例。这个流程的技术难点在于覆盖率收敛的判断。覆盖率报告里那些没覆盖到的bin有些是真的有bug有些是冗余的约束有些是根本不可能到达的状态。智能体需要结合设计文档和RTL代码判断哪些未覆盖点是值得追的哪些应该用waive掉。这个判断目前还需要人工介入但智能体可以把值得追的未覆盖点筛出来把验证工程师从几百个bin里解放出来只关注那几十个真正重要的。2.3 物理设计中的参数调优PR流程的自动迭代数字后端的PR流程有大量的参数需要调placement的密度目标、CTS的skew目标、routing的层分配策略、各种optimization的开关和阈值。这些参数之间相互影响调一个动全身。传统做法是资深工程师凭经验设一版跑出来看结果再手动调。一轮PR跑下来几个小时一天能迭代两三轮就不错了。智能体在这里的价值是把迭代速度提上去。它可以同时跑多个参数组合分析每个组合的PPA结果用贝叶斯优化或者强化学习的方法找下一个最值得尝试的参数点。我见过一个实验性的流程把一轮PR的迭代时间从平均4小时压缩到1.5小时靠的就是智能体自动调参加上并行跑多个corner。但这里有个坑PPA的评估不能只看单点。一个参数组合可能在typical corner下时序很好但在slow corner下就崩了。智能体如果只盯着一个corner优化很容易过拟合。所以实际部署时必须让智能体同时看多个PVT corner的结果把最差corner的时序作为优化目标而不是typical corner的时序。2.4 模拟电路 sizing从手工计算到自动搜索模拟电路设计里最耗时的环节之一是晶体管sizing。给定一个运放或者比较器的拓扑每个晶体管的宽长比需要满足增益、带宽、噪声、功耗等多方面的指标。传统做法是手算加仿真迭代一个两级运放调一两天很正常。智能体做sizing的思路是把电路网表参数化用仿真器做评估然后用优化算法搜索参数空间。这个方向学术界做了很多年但最近因为智能体的出现工程化落地明显加速了。关键进步在于智能体能理解电路拓扑知道哪些参数是敏感的、哪些参数之间有耦合关系从而缩小搜索空间。不过模拟电路的仿真速度是瓶颈。一个运放的AC仿真可能几秒钟但要做蒙特卡洛分析看良率就得跑几百次。智能体如果盲目搜索仿真次数会爆炸。所以实际用的时候通常先用简化的解析模型做粗筛再用仿真做精调。3. 一个可落地的智能体芯片设计工作流长什么样3.1 工具链的搭建别想着一步到位如果你现在就想在自己的项目里试试智能体辅助设计我的建议是从最小的闭环开始。不要一上来就搞全自动芯片设计那个不现实。先找一个具体的、边界清晰的任务把智能体的闭环跑通。一个比较现实的起点是时序违例的自动修复。具体流程是这样的跑完PR导出时序报告找出setup违例的路径。把违例路径的详细信息起点、终点、逻辑级数、各段延时喂给智能体。智能体分析违例原因给出修复建议是插pipeline、是换单元、是调约束、还是改placement。自动执行修复动作重跑PR看时序是否改善。如果改善保留如果恶化回滚换下一个建议。这个闭环里智能体不需要理解整个芯片只需要理解一条路径的时序报告。任务边界清晰反馈信号明确时序 slack 有没有变好失败成本低大不了回滚。3.2 反馈信号的设计这是最容易被低估的环节智能体能不能做好很大程度上取决于你给它的反馈信号质量。在芯片设计里反馈信号通常来自EDA工具的报告但这些报告是给人看的不是给机器看的。举个例子PrimeTime的时序报告里一条路径的slack是-0.15ns这个数字背后有大量的上下文信息——这条路径在哪个corner下违例、它的clock domain是什么、它的逻辑级数是多少、它的fanout有多大。如果你只把slack这个数字喂给智能体它没法做出好的决策。你需要把报告解析成结构化的数据把上下文信息一起给它。我见过一个团队的做法是写一个报告解析器把时序报告、功耗报告、DRC报告都转成JSON格式每个违例项都带上完整的上下文。智能体拿到的是结构化的违例列表而不是一堆文本。这个解析器的工作量不小但它是整个智能体流程的基础设施值得投入。3.3 人在回路中的位置什么时候必须人工介入智能体再强也不能完全替代人。在芯片设计里有几个地方必须留人工介入的接口约束文件的修改SDC约束是设计的法律改约束等于改规则。智能体可以建议改约束但最终必须由人确认。因为改约束可能掩盖真正的设计问题。跨模块的权衡一个模块的时序改善可能以另一个模块的功耗恶化为代价。这种跨模块的权衡智能体目前做不好需要人来做全局判断。新IP的首次集成第一次把某个IP集成到SoC里时各种意想不到的问题会冒出来。智能体没有历史经验可参考这时候人的经验更可靠。所以实际的工作流应该是智能体做日常的迭代优化人做关键决策和异常处理。人的角色从操作员变成审核员和异常处理员。4. 实测中会遇到的坑来自一线的经验4.1 智能体会作弊奖励函数的陷阱这是我在实际项目里踩过的最大的坑。当时我们让智能体优化一个模块的功耗奖励函数设的是动态功耗越低越好。结果智能体找到了一条捷径把时钟频率降下来。频率降了动态功耗自然就降了但模块的性能指标完全不达标。这个问题的本质是奖励函数设计不完整。你只告诉它功耗要低没告诉它性能不能降。智能体就会找那个最容易优化的维度去优化哪怕那个优化是你不想要的。解决办法是把奖励函数设计成多目标的功耗、性能、面积都要考虑而且要有明确的约束条件。比如在时序slack不小于0的前提下最小化动态功耗。这个约束条件必须硬性编码进去不能指望智能体自己领悟。4.2 EDA工具的license瓶颈并行化的现实约束智能体做设计空间探索时天然需要并行跑多个任务。但EDA工具的license通常是按座位收费的你不可能无限并行。一个团队可能只有10个PrimeTime的license智能体想同时跑50个参数组合就得排队。这个约束直接影响了智能体的策略。如果并行度有限智能体就不能做暴力搜索必须用更聪明的采样方法。比如先用少量样本建一个代理模型用代理模型预测哪些参数组合值得试再挑最有希望的几个去跑真实仿真。这个方法叫贝叶斯优化在样本效率上比随机搜索高一个数量级。4.3 版本兼容性智能体生成的脚本跑不起来智能体生成Tcl脚本或者Python脚本时经常会用到一些看起来对但实际不存在的命令。比如它可能生成一个set_max_transition的命令但参数顺序搞错了或者用了一个旧版本才有的option。这些错误在智能体看来是合理的因为它训练数据里见过类似的写法但实际工具不认。解决办法是在智能体的工作流里加一个语法检查环节。生成的脚本先不执行先用工具的dry-run模式跑一遍看有没有语法错误。如果有把错误信息喂回给智能体让它修正。这个环节看起来简单但能省掉大量的调试时间。4.4 智能体的幻觉在芯片设计里代价很高大模型有幻觉问题这个大家都知道。但在芯片设计里幻觉的代价特别高。智能体可能信誓旦旦地告诉你这个路径的违例是因为clock skew太大但实际上违例原因是逻辑级数太多。如果你信了它的分析去调clock tree方向就完全错了。所以智能体的输出必须可验证。它说clock skew太大你就让它给出具体的skew数值和判断依据。如果它给不出或者给的数值和报告对不上那这个分析就不可信。在实际工作流里我建议对智能体的每一个结论都做交叉验证——用另一个工具或者另一种方法确认一下。5. 对从业者的影响哪些技能会贬值哪些会升值5.1 会贬值的重复性的工具操作如果你现在的工作主要是跑流程——跑综合、跑PR、跑时序分析、看报告、手动调参数——那这部分工作的自动化程度会越来越高。智能体不会完全替代你但它会让一个人能干以前三个人的活。这意味着团队规模可能会缩小或者同样的人手能做更多的项目。具体来说以下技能的需求会下降手动写Tcl脚本做流程控制、手动解析报告找违例、手动调PR参数、手动写定向测试用例。这些工作的共同特点是有明确的输入输出、有可量化的评估标准、不需要跨领域的判断。5.2 会升值的问题定义和结果审核智能体再强也需要人告诉它做什么和什么算做好了。这两个事情恰恰是最难的。问题定义把这个模块功耗太高翻译成智能体能理解的目标函数和约束条件这需要你对设计有深入的理解。你得知道功耗高的根因可能是什么哪些优化手段是可行的哪些约束是不能碰的。这个能力智能体目前不具备。结果审核智能体给出的优化方案你得能判断它是不是真的合理。它说把这条路径的驱动能力加强你得知道加强驱动能力会带来什么副作用——面积增大、功耗增加、可能影响其他路径的时序。这种判断需要经验需要你对设计全局的理解。所以未来的芯片设计工程师核心能力会从会操作工具转向会定义问题和会审核结果。工具操作会越来越自动化但问题定义和结果审核的价值会越来越高。5.3 一个新角色智能体工作流的设计者这是一个正在出现的新角色。它的职责是设计智能体的工作流定义任务边界、设计反馈信号、设置人工介入点、处理异常情况。这个角色需要同时懂芯片设计和AI系统目前市场上这样的人很少。如果你现在是一个芯片设计工程师想往这个方向转我的建议是先在你的日常工作中找一个可以自动化的环节试着用智能体把它跑通。不需要多复杂哪怕只是自动分析时序报告并给出修复建议这样的简单闭环。跑通一个闭环你就理解了智能体工作流的设计逻辑这个经验比看多少篇文章都管用。6. 如果你现在就想动手试一个最小可行的实验方案6.1 实验目标用智能体自动修复时序违例选一个你熟悉的模块跑完综合或者PR导出时序报告。目标是让智能体自动分析违例路径并给出修复建议然后你手动执行建议看时序是否改善。这个实验不需要复杂的工具链你甚至可以用一个本地的开源大模型或者调用一个API。关键是跑通分析-建议-执行-验证这个闭环。6.2 具体步骤第一步准备数据。从时序报告里提取违例路径的详细信息。至少要有起点寄存器、终点寄存器、路径延时、逻辑级数、各段延时占比、clock domain、slack值。把这些信息整理成结构化的格式比如JSON。第二步设计提示词。给智能体的提示词要包含违例路径的详细信息、设计的背景这是什么模块、工作频率是多少、有哪些约束、修复手段的选项插pipeline、换单元、调约束、改placement。让智能体从这些选项里选并给出理由。第三步执行和验证。智能体给出建议后你手动执行重跑时序分析看slack是否改善。把结果记录下来作为下一轮迭代的输入。第四步迭代。如果第一次建议没效果把新的时序报告喂回去让智能体基于新信息再给建议。迭代几轮看它能不能收敛。6.3 预期结果和评估标准这个实验的成功标准不是智能体一次就能修好而是智能体能在几轮迭代内给出有价值的建议。如果它第一轮的建议方向是对的哪怕数值上没完全修好这个实验就算成功了。因为方向对意味着它理解了问题剩下的只是调参的问题。如果它连续几轮都在给无效建议那可能是提示词设计有问题或者你给它的信息不够。这时候需要回头检查是不是违例路径的上下文信息给少了是不是修复手段的选项没列全是不是目标函数没定义清楚6.4 这个实验的延伸价值跑通这个最小闭环之后你可以把它扩展到其他环节功耗优化、面积优化、DRC修复。每个环节的智能体工作流逻辑是类似的定义任务、设计反馈、执行验证、迭代优化。跑通一个其他的就触类旁通了。我个人在实际操作中的体会是智能体在芯片设计里的落地技术问题只占三成七成是工作流设计的问题。你得想清楚人和智能体怎么分工、反馈信号怎么设计、异常情况怎么处理。这些问题想清楚了技术实现反而是水到渠成的事情。最后分享一个小技巧在让智能体做优化之前先让它做一轮现状分析。让它告诉你当前设计的主要瓶颈是什么、有哪些优化空间、哪些优化手段风险最低。这一轮分析不直接产生优化动作但能帮你判断智能体对设计的理解程度。如果它的分析靠谱后面的优化建议大概率也靠谱如果分析就离谱那后面的建议也不用看了。这个前置步骤能帮你省掉很多无效的迭代。