1. 从“画版图”到“写约束”芯片设计流程正在被重新切分过去两年我陆续参与过几个把机器学习塞进芯片设计流程的项目有做布局布线的有做参数调优的也有做验证用例生成的。说实话第一次看到工具自动跑出一版比手工调优还紧凑的布局时心里是有点发毛的。但做得越多越明白一件事AI 并没有把工程师从流程里踢出去它只是把流程重新切了一刀把原来靠人肉试错的部分拿走了把定义问题、约束边界、判断结果的部分留了下来。这个标题问的是“护城河还剩什么”我觉得这个问题本身就问偏了。护城河从来不是某一项具体技能比如你会写某段脚本、你会调某个工具的参数。护城河是你对“什么问题值得解、什么结果算好、边界在哪里”的判断力。AI 擅长在给定目标下搜索最优解但它不擅长定义目标本身。芯片设计里最贵的从来不是算力是定义错方向之后浪费的那几个月流片周期。所以这篇我想聊的不是“AI 会不会取代工程师”这种空对空的话题而是把芯片设计流程拆开看看哪些环节已经被 AI 实质性地改变了哪些环节它暂时还碰不动以及在这个变化里一个普通工程师应该把精力往哪里挪。适合正在做数字前端、后端、验证、DFT 的朋友看也适合刚入行、担心自己学的技能会不会很快过时的新人。我会尽量把原理讲清楚把能落地的操作和判断标准写出来而不是只给结论。2. 芯片设计里到底哪些环节在被 AI 实质性地改写2.1 布局布线从“手工摆楼层”到“目标驱动的搜索”布局布线是 AI 介入最早、也最见效果的环节。传统流程里一个后端工程师拿到网表之后要花大量时间做 floorplan摆 macro、规划电源网络、估拥塞。这个过程高度依赖经验同一个设计不同的人摆出来面积和时序能差出一大截。AI 在这里做的事情本质上是把“摆布”变成一个带约束的优化问题。你给它一个目标函数比如在满足时序的前提下最小化面积或者给定面积预算下最大化频率它就在巨大的解空间里搜索。强化学习在这块用得比较多因为布局本身是一个序列决策过程先放哪个、后放哪个、放哪里每一步都会影响后续可选空间。但这里有个很多人忽略的点AI 搜索出来的结果质量高度依赖你给它的约束和目标函数。约束写松了它给你一个面积很小但时序一塌糊涂的方案约束写死了它又找不到可行解。我见过一个项目团队把时序约束写得过于激进工具跑了两天两夜最后吐出来一个根本没法收敛的结果白白浪费了算力。后来把约束按优先级分层先保证关键路径再优化次要路径结果就正常了。所以这个环节里工程师的价值从“会摆”变成了“会定义问题”。你得知道哪些路径是真的关键哪些约束是可以放松的哪些物理效应在这个工艺节点下必须考虑。这些判断AI 目前给不了你因为它不知道这个芯片最终要装在什么产品里、工作环境是什么样。2.2 参数调优把“老师傅手感”变成可复现的搜索策略参数调优是另一个被 AI 改变得很彻底的环节。不管是模拟电路里的偏置电流、补偿电容还是数字后端里的各种优化选项传统做法都是老师傅凭手感试。试出来了但说不清楚为什么换个人、换个工艺节点又得重新试。贝叶斯优化在这块用得很多。它的核心思想是用一个代理模型去近似真实的代价函数然后根据当前模型的不确定性来决定下一个采样点。简单说就是“在探索未知区域和利用已知好区域之间找平衡”。相比网格搜索和随机搜索贝叶斯优化在样本效率上有明显优势通常几十次迭代就能找到不错的解而网格搜索可能要几百上千次。我实际用下来贝叶斯优化最适合的场景是单次评估成本高、参数维度在 5 到 20 之间、参数之间有耦合但不算特别强。如果维度再高代理模型本身就不准了效果会打折扣。这时候可以考虑降维或者用遗传算法这类基于种群的搜索策略。但这里有个坑很多人把参数调优当成一个纯黑盒问题扔给工具就不管了。实际上参数之间的物理关系决定了搜索空间的结构。比如某个偏置电流和某个晶体管尺寸之间是有物理关联的如果你在搜索空间里把它们当成独立维度工具会浪费大量时间在物理上不合理的组合上。正确的做法是把已知的物理约束编码进搜索空间缩小无效区域。这个编码过程就是工程师的经验在起作用。2.3 验证与测试用例生成和覆盖率收敛的自动化验证是芯片设计里最耗人力的环节之一。一个中等规模的 SoC验证用例动辄几千上万条覆盖率收敛往往要跑几周甚至几个月。AI 在这块的介入主要有两个方向一是自动生成激励二是智能选择回归用例。自动生成激励这块常用的是基于覆盖率反馈的方法。工具会根据当前覆盖率缺口生成更有可能打到未覆盖区域的激励。这比随机生成效率高很多因为随机生成大部分时间都在重复覆盖已经覆盖过的区域。智能选择回归用例则是另一个思路。每次代码改动之后不需要跑全量回归而是根据改动影响范围挑选最相关的用例跑。这个思路在软件测试里已经很成熟了芯片验证里也在逐步应用。我见过一个项目用这个方法把回归时间从三天压缩到半天效果很直接。但验证这块有个特殊性覆盖率数字好看不代表验证充分。有些 bug 藏在覆盖率已经 100% 的地方因为覆盖模型本身没建对。AI 可以帮你更快地达到覆盖率目标但它不能帮你判断“这个覆盖率模型是否合理”。这个判断还是得靠对设计规格的深入理解。2.4 DFT 与测试模式生成和诊断的智能化DFT 这块相对小众但 AI 的介入也很明显。测试模式生成、测试压缩、故障诊断这些环节都有 AI 的身影。比如测试压缩传统方法是靠算法做确定性压缩AI 可以在压缩率和测试时间之间找更好的平衡点。故障诊断这块AI 的价值在于从大量测试失败数据里找规律。一个芯片测试失败可能是设计问题、工艺问题、封装问题也可能是测试程序本身的问题。传统做法是靠人一条条看 log效率很低。用聚类或者分类模型先做一轮筛选把明显相似的失败模式归到一起工程师再重点看那些异常的效率会高很多。但这个环节里AI 的输出只能作为参考。因为测试失败的原因往往涉及物理层面的东西比如某个金属层在特定工艺角下电阻偏大这种问题 AI 从数据里不一定能直接看出来需要工程师结合工艺知识去判断。3. 为什么“定义问题”比“解决问题”更难被替代3.1 目标函数写不对AI 只会更快地跑偏这是我在实际项目里体会最深的一点。AI 是一个极其高效的执行者但它执行的是你给它的目标。目标写错了它不会质疑只会用更快的速度、更大的算力把你带到一个更离谱的地方。举个芯片设计里的例子。假设你在做一个低功耗设计目标函数写的是“最小化动态功耗”。AI 可能会给你一个方案把所有时钟频率降到极低动态功耗确实下来了但性能完全不达标。如果你把目标函数改成“在满足性能约束的前提下最小化动态功耗”结果就完全不同。这个道理听起来简单但实际操作里目标函数的写法非常讲究。你得考虑哪些是硬约束哪些是软约束多个目标之间怎么加权约束是写在目标函数里作为惩罚项还是作为独立的可行性判断。这些选择直接决定了 AI 搜索的方向和最终结果的质量。我个人的经验是写目标函数之前先问自己三个问题第一这个设计最不能妥协的是什么第二哪些指标是可以 trade-off 的第三如果两个方案在主要指标上打平我用什么次要指标来区分把这三个问题想清楚目标函数基本就成型了。3.2 约束边界来自物理世界不来自数据AI 模型是从数据里学规律的但芯片设计里很多约束来自物理世界数据里不一定有。比如某个工艺节点下金属线的电迁移限制、晶体管的匹配要求、封装的散热能力这些是物理规律决定的不是从历史数据里统计出来的。我见过一个案例团队用历史项目数据训练了一个模型来预测布局后的时序模型在训练集上表现很好但换到一个新工艺节点上就完全不准了。原因很简单新工艺的器件特性变了历史数据里的规律不适用了。这时候工程师对工艺的理解就成了关键。你得知道新工艺和旧工艺在哪些方面有本质差异这些差异会如何影响时序然后手动调整模型或者约束。所以 AI 在芯片设计里的一个根本局限是它只能在它见过的数据分布里工作。一旦超出这个分布它的输出就不可靠了。而芯片设计恰恰是一个不断面对新工艺、新架构、新场景的领域分布外的情况非常常见。3.3 结果判断需要系统级视角AI 只看局部指标AI 优化出来的结果往往在它被训练的那个指标上表现很好但放到整个系统里看可能有问题。比如布局工具优化了线长但可能增加了某个关键模块的拥塞导致后续布线失败。或者参数调优工具优化了某个子模块的功耗但增加了整体电源网络的噪声。这种局部最优和全局最优的冲突在芯片设计里非常普遍。因为芯片是一个高度耦合的系统任何一个局部的改动都可能产生连锁反应。AI 目前还很难理解这种系统级的耦合关系它擅长的是在给定边界内找最优解不擅长判断这个边界本身是否合理。工程师的价值就在这里你得有系统级视角知道各个模块之间怎么相互影响知道哪些指标是真正重要的哪些只是中间变量。这种判断力来自对完整设计流程的理解来自踩过足够多的坑之后的直觉。4. 工程师的护城河从“会操作”到“会判断”的迁移路径4.1 把工具当黑盒用的人最先被替代这句话可能有点刺耳但我觉得是事实。如果你的工作内容是“打开工具、导入数据、点运行、看报告”那这部分工作确实很容易被自动化。因为 AI 做这些事情比你快、比你稳定、还不用休息。但如果你能理解工具背后的原理知道它在什么情况下会失效知道怎么调整输入来获得更好的输出那你的价值就不一样了。因为 AI 工具本身也需要人来调、来维护、来判断它的输出是否可信。我自己的做法是每用一个新工具都会花时间搞清楚它的核心算法是什么、关键参数控制什么、在什么边界条件下会出问题。比如用贝叶斯优化做参数调优我会去看它的采集函数是怎么定义的是偏向探索还是偏向利用然后根据我的问题特点去调整。这些理解让我在工具给出不合理结果时能快速判断是哪里出了问题而不是盲目地重新跑一遍。4.2 跨层理解前端懂后端后端懂前端芯片设计的分工越来越细前端、后端、验证、DFT、封装每个环节都有自己的工具和流程。但 AI 的介入正在打破这些边界因为 AI 优化往往需要跨层的信息。比如布局优化需要知道时序的关键路径时序分析需要知道物理布局的寄生参数验证需要知道设计的实际使用场景。在这种情况下只懂自己那一层的人会越来越被动。因为 AI 工具需要跨层输入而提供这些输入、判断这些输入是否合理的人必须是懂多层的人。我认识一个做后端的工程师他花了很多时间学前端的设计流程和验证方法。一开始大家觉得没必要但后来他在做布局优化时能直接和前端工程师讨论时序约束的合理性能判断哪些路径是真的关键哪些是约束写得太保守。这种跨层理解让他在项目里的价值明显高于只懂后端的同事。4.3 数据素养知道什么数据能用什么数据是垃圾AI 模型的效果很大程度上取决于训练数据的质量。芯片设计里数据来源很多仿真数据、测试数据、历史项目数据、工艺厂提供的模型数据。这些数据的质量参差不齐直接用很容易出问题。工程师需要具备的基本数据素养包括知道数据是怎么产生的、知道数据的适用范围、知道数据里可能有哪些偏差。比如仿真数据你得知道仿真模型在什么条件下是准的在什么条件下会偏离实际。测试数据你得知道测试条件是什么是否覆盖了所有工作场景。我见过一个团队用历史项目的功耗数据训练了一个预测模型结果在新项目上预测偏差很大。后来发现历史项目的数据是在某个特定工作模式下采集的而新项目的工作模式完全不同。这就是典型的数据适用范围问题。如果工程师有基本的数据素养在训练模型之前就会先检查数据的适用范围而不是等模型出问题再回头找原因。4.4 沟通与翻译把工程问题翻译成 AI 能理解的形式这一点经常被忽略但我觉得越来越重要。AI 工具需要明确的输入目标函数、约束条件、搜索空间。但实际工程问题往往是模糊的、多目标的、有隐含约束的。把工程问题翻译成 AI 能理解的形式本身就是一个高价值的工作。比如老板说“这个芯片要又小又省电还得快”这是一个模糊的需求。你需要把它翻译成面积上限是多少、功耗预算是多少、关键路径的频率目标是多少、哪些指标是硬约束、哪些可以 trade-off。这个翻译过程需要对设计、对工艺、对产品都有理解。而且这个翻译不是一次性的AI 跑出结果之后你可能需要根据结果反过来调整翻译。比如发现面积和功耗无法同时满足就需要回去和老板沟通看哪个指标可以放松。这种来回沟通和调整的能力AI 目前完全不具备。5. 一个具体的例子用 AI 做布局优化时工程师到底在做什么5.1 问题定义阶段把设计意图翻译成约束假设我们要做一个模块的布局优化。第一步不是打开工具而是理解这个模块的功能和性能要求。它工作在什么频率有哪些关键接口有没有特殊的物理约束比如模拟部分需要远离数字噪声源这些信息工具不知道只有工程师知道。你需要把它们翻译成工具能理解的约束频率目标、时序路径分组、物理禁区、电源域划分。这个翻译过程直接决定了后续优化的方向。我通常会先画一张草图标出必须放在一起的模块、必须分开的模块、对时序最敏感的路径、对噪声最敏感的区域。然后根据这张草图去写约束文件。这张草图不一定要很精确但必须把关键关系表达清楚。5.2 约束编写阶段哪些写死哪些留活口约束编写是最考验经验的地方。写得太死工具找不到可行解写得太松工具给你一个没法用的结果。我的原则是物理约束写死性能约束留活口。比如某个模块必须放在芯片的某个角落这是物理约束写死。但时序目标可以给一个范围让工具在范围内搜索。如果工具在范围内找不到解再逐步放松。另外约束的优先级要明确。哪些是必须满足的哪些是尽量满足的。工具在搜索时会优先满足高优先级的约束。如果所有约束都是同一优先级工具可能会为了满足一个次要约束而牺牲主要约束。5.3 结果评估阶段看数字之外的东西工具跑完之后会给你一堆报告面积、线长、时序余量、拥塞图。但光看这些数字不够你得看数字之外的东西。比如时序余量工具报告说所有路径都满足了但你要看关键路径的余量分布。如果大部分路径余量很大只有少数路径余量很小说明约束可能写得太松了还有优化空间。如果所有路径余量都很小说明约束写得太紧工具已经尽力了。再比如拥塞图工具报告说拥塞在可接受范围内但你要看拥塞的分布。如果拥塞集中在某个区域可能是那个区域的模块摆放不合理需要手动调整。如果拥塞均匀分布可能是整体布局密度太高需要降低利用率。这些判断需要你对设计有深入理解知道什么样的结果算好什么样的结果虽然数字达标但实际有问题。5.4 迭代调整阶段什么时候该信 AI什么时候该信自己AI 跑出来的结果不一定是最优的。有时候工具陷入局部最优你需要手动干预。有时候工具的结果看起来奇怪但实际测试下来是好的你需要相信它。我的经验是如果工具的结果和我的直觉冲突先别急着否定花时间理解它为什么给出这个结果。如果我能理解它的逻辑并且逻辑是合理的那就接受。如果我理解不了或者逻辑明显有问题那就手动调整。比如有一次工具把一个关键模块放在了离它的通信伙伴很远的地方我一开始觉得不合理。但仔细看时序报告发现这个模块的通信路径不是关键路径而它占的面积很大放在边缘反而减少了整体线长。这就是工具看到了我没看到的东西。但也有反例。有一次工具为了优化线长把一个模拟模块放在了数字模块中间完全忽略了噪声隔离的要求。这就是约束没写清楚工具不知道这个物理限制。后来我把噪声隔离写成硬约束结果就正常了。6. 新人该往哪个方向积累才不会被工具甩下车6.1 先把一个环节吃透再横向扩展我见过一些新人什么工具都想学什么流程都想碰结果每个都只懂皮毛。这种“广度优先”的策略在 AI 时代反而危险因为皮毛层面的操作最容易被自动化。更稳妥的做法是先选一个环节比如时序分析或者布局布线把它吃透。吃透的标准不是会用工具而是理解工具背后的原理知道它在什么情况下会失效知道怎么调整输入来获得更好的输出。这个过程可能需要一两年但值得。吃透一个环节之后再横向扩展。这时候你有了一个参照系学其他环节会快很多而且能理解各个环节之间的关联。这种“T 型”能力结构在 AI 时代更有竞争力。6.2 学会写脚本但别只满足于写脚本脚本能力是基础能帮你自动化重复工作。但只会写脚本不够因为脚本实现的是你已经知道的流程而 AI 能做的是探索你不知道的流程。比写脚本更重要的是理解脚本背后的算法和数据结构。比如你写了一个脚本做时序分析你得知道时序分析的基本算法是什么关键路径是怎么找的 slack 是怎么算的。这些理解让你在 AI 工具给出结果时能判断结果是否合理。另外学会用 AI 工具本身也是一项技能。不是会用界面就行而是理解它的输入输出、理解它的适用边界、理解怎么调参。这些技能需要在实际项目里慢慢积累。6.3 培养“端到端”的视角别只盯着自己的工位芯片设计是一个长链条从规格定义到最终产品中间经过很多环节。只盯着自己工位的人很难理解自己的工作在整体中的位置也很难判断什么结果是真正重要的。培养端到端视角的方法有很多多参加跨部门会议、多和上下游同事聊天、多读项目文档、多了解最终产品的使用场景。这些看起来和具体技术无关但长期来看它们决定了你的判断力上限。我自己的体会是当我开始理解整个芯片从定义到量产的全流程之后我在做自己那一小块工作时判断标准完全不一样了。以前我只关心我的模块时序是否满足现在我会关心这个模块在整个系统里的功耗占比、面积占比、对良率的影响。这种视角让我在做技术决策时更有依据。6.4 保持对物理世界的理解别被纯数据思维带偏AI 是数据驱动的但芯片设计最终要落到物理世界上。器件有物理特性、连线有寄生参数、封装有热阻、系统有噪声。这些物理层面的东西数据里不一定有但决定了设计的成败。所以不管 AI 工具多强大保持对物理世界的理解都很重要。知道一个晶体管在物理上是怎么工作的、知道一条金属线在物理上有什么限制、知道一个封装在物理上能承受多少功耗。这些理解让你在 AI 给出违反物理规律的结果时能第一时间发现。我见过一些新人过度依赖仿真工具工具说行就行工具说不行就不行。但工具本身也是基于模型的模型有适用范围。超出适用范围工具的结果就不可信了。这时候对物理世界的理解就是最后的防线。7. 工具越强判断力越贵做了这么多年芯片设计我最大的感受是工具一直在变强从手工画版图到自动布局布线从手工写测试到自动生成激励每一次工具升级都会淘汰一批只会操作的人同时让会判断的人更值钱。AI 只是这个趋势的延续不是颠覆。它把搜索和优化的效率提升了一个数量级但搜索和优化的目标、约束、边界还是得人来定。而且因为 AI 跑得更快定义错方向的代价反而更大了。以前手工试错试错了还能及时回头现在 AI 一晚上跑几千个方案方向错了浪费的是算力和时间还有可能错过项目窗口。所以我的建议是别把精力花在担心 AI 会不会取代你上把精力花在提升自己的判断力上。判断力来自对原理的理解、对流程的熟悉、对物理世界的认知、对系统级权衡的把握。这些东西AI 短期内学不会长期来看也不容易替代因为它们需要真实世界的反馈和跨领域的整合。最后分享一个我自己的小习惯每次用 AI 工具跑出一个结果我都会问自己一句“如果是我手工做我会怎么做和这个结果差在哪里”。如果差得不多说明工具已经学到了我的经验如果差得很多说明要么工具没学好要么我该更新自己的认知了。这个习惯让我在工具越来越强的同时自己的判断力也在跟着涨。
