1. 这次合作到底在加速什么撕开系统级芯片设计的真实瓶颈芯片圈最近有个消息挺值得拿出来聊聊的新思科技和英特尔双方在系统级芯片设计上又往前推了一把。如果你不是做数字前端或物理实现的人可能觉得这就是两家大厂例行发了个新闻稿。但你只要真正碰过先进工艺节点的SoC项目就会知道这事儿的份量。先说说系统级芯片设计目前面临的处境。今天的SoC早就不只是“把CPU、GPU、NPU拼在一颗Die上”这么简单了单颗裸片上集成的晶体管数量动辄上百亿一个项目下来要把几十个不同来源的IP、第三方核、自研模块全部整合进一个物理实现流程里。更麻烦的是越往先进节点走设计的复杂度根本不是线性增长而是像滚雪球一样往上翻。你在5nm、4nm甚至更往后的工艺上跑一版布局布线仅仅一次时序收敛迭代的成本就高得吓人更别提功耗分析、信号完整性、电迁移这些签核项目统统要重跑一遍。我查了下双方提到的方向核心其实是解决两件事第一让EDA工具链更懂英特尔代工的工艺特性第二把芯片从架构探索到物理签核整个链条上的“经验差”抹平。说白了EDA公司出工具代工厂出工艺和标准单元库但工具跟工艺之间怎么才能做到“技术对齐”而不是“各干各的”这才是真正的深水区。这篇文章我打算从三个角度看这次合作一是系统级芯片设计在先进节点下到底卡在哪二是新思和英特尔联合优化的实质内容有哪些三是对咱们做设计、做验证、做物理实现的工程师来说这套流程里哪些东西可以直接借鉴、哪些坑可以提前绕开。这次合作的本质是一次典型的产业链深度协同值得所有关注先进芯片设计的人认真看一眼。1.1 系统级芯片设计为什么越来越“急”了先说一个真实感受十年前做SoC设计RTL写完到GDSII出来用的工具流相对固定签核口径也相对成熟。现在不一样了尤其是进入先进封装和多裸片时代之后系统级芯片的概念被彻底撑大了。过去你只要管好一颗Die内部的时钟树、布局布线和静态时序分析就够了现在要操心的是整个系统怎么拆成多颗Chiplet、每颗Chiplet之间走什么互连接口、UCIe通用芯粒互连标准物理层怎么布、跨Die的信号怎么建模、封装基板上的走线寄生怎么反标回设计里。这一整套逻辑下来早就不再是传统SoC流程能覆盖的范畴而是系统级协同设计。为什么说“急”因为摩尔定律的节奏在单芯片维度已经明显放缓大家全在往异构集成、先进封装、芯粒复用这些方向上找出路。市场上所有做高性能计算的团队几乎在同一时间涌向先进工艺节点和2.5D/3D封装方案。但专业的EDA实现工具、签核工具对封装和芯粒场景的支持长期是滞后于工艺进展的。设计团队一边在先进工艺上等PDK稳定一边在芯粒设计上等工具链补课这就是真实存在的“等米下锅”状态。所以这次新思和英特尔坐到一起干的活本质上是在给整套系统级芯片设计流“开路”。一端是工具链怎么更好的支持英特尔代工的最新工艺特性另一端是工具链怎么对芯粒级设计、多裸片签核做原生级别的优化。1.2 EDA公司要和代工厂“坐在一起”的原因芯片行业有个老规矩EDA工具、设计团队、代工厂三者的关系是“三角协同”。过去EDA公司把工具做好代工厂把工艺库做好两边各出一份文档设计团队拿着工具和库在中间做“翻译”。但到了先进节点这种“翻译”模式已经撑不住了。举一个最直观的例子静态时序分析里需要用工艺角模型去算路径延迟。同一个标准单元在新思的库里和在英特尔的PDK里延迟数值、压摆模型、寄生参数提取规则可能都有细微差异。差异不大的时候无所谓但先进节点下时序余量本来就紧张很多时候连几十个皮秒都要抠。如果工具对工艺库的理解不够深签核结果就会和实际硅片表现对不上流片回来才发现时序违例这种损失是无法补救的。新思和英特尔的合作模式从技术侧看是把新思的整套数字实现流程——逻辑综合、布局布线、STA、功耗分析、物理验证——针对英特尔代工的PDK做深度校准和联合优化。相当于工程师在用工具的时候工具本身就“知道”英特尔这套工艺的脾气哪里模型保守、哪里需要特殊关照都不需要人来盲猜。这跟买了通用工具自己再花三个季度调沙拉库完全是两码事。另外还有一个重点方向英特尔在先进封装上的布局已经到了规模化商用阶段EMIB和Foveros的生态逐步成熟。而新思这边的多裸片系统级设计方案为UCIe、3Dblox等标准建立了数字底座。两边一合就是在给“系统级芯片设计”搭一个从裸片到封装端到端打通的快车道。2. 从工具链到工艺库合作落地的那几件关键事情光说“合作”两个字有点虚还是得落到具体的技术环节上才能看清这套东西到底动了谁的奶酪。我看了一下目前能看到的技术方向合作的落地内容大致可以分成三层签核工具和工艺库的对齐、芯粒设计流程的支撑、以及电源热可靠性这类“物理签核”层面的打通。这三层正好对应了系统级芯片设计当中最烧时间、最烧机时也最烧人力的三个环节。2.1 签核工具与工艺库的“对齐”逻辑签核是芯片设计里最较真的环节没有之一。所谓签核就是设计要“封版”之前把时序、功耗、电压降、信号完整性、物理规则这些项目全部按代工厂的标准跑一遍确认到了硅片上不会出问题。签核工具的特性库描述和代工厂的工艺物理行为是否一致直接决定了你能不能在合理迭代次数之内得到可信的结果。新思在签核侧的看家工具是PrimeTime静态时序分析、StarRC寄生参数提取和PrimeRail功耗/电压降分析。这一套组合拳在业内算是广泛部署的“标准答案”。英特尔这边则需要在PDK、标准单元库、IO库、硬宏模型里把这些工具需要的视图全部做到完备且准确。对双方的合作来说“对齐”这个词看着轻巧做起来极其繁重。我提一个细节一个先进节点的标准单元库里面可不只是几百个逻辑门的时序功耗表而是要根据不同的阈值电压档位、不同的沟道长度偏置、不同的版图结构分别描述。库里的每一张查表背后都对应一串硅片实测数据或者经过校准的仿真数据。签核工具和库对齐得越好设计团队做时序签核时越不用靠大量的悲观系数去“防御式设计”PPA功耗、性能、面积能拿到手的空间就越大。有做物理实现的工程师可能都经历过这种事在综合阶段看起来频率能跑到2.5GHz到了后端布局布线以后时序全面飘红一查发现是库模型里的上升下降时间表给得太乐观。这种问题不完全怪工艺很多时候是工具和库之间缺少充分的交互验证。新思和英特尔这种级别的合作本质上就是在源头上减少这类“预期和现实的不匹配”。2.2 芯粒与先进封装设计的流程支撑如果说签核对齐是“地基”那芯粒设计流程就是这次合作的“主楼”。系统级芯片设计走到当下这个阶段从一颗单Die转向多Die集成已经是非常明确的方向但很多人低估了流程上的断裂严重到什么程度。过去做SoCDie和封装是两个相对独立的专业分工前端做RTL的人不太关心封装封装设计的人拿到的是GDSII就算完工。多裸片方案直接把这两拨人强行绑在一起——Die与Die之间的走线延迟、基板上的电源完整性、微凸点和混合键合的热应力全都必须在设计早期就纳入考量。新思的3DIO、Multi-Die设计流程这一整套方案配合英特尔代工的先进封装平台我认为最关键的价值不是画几条新流程线而是让设计团队在同一个平台里就能把多个裸片的布局、Die-to-Die接口的时序预算、封装基板的物理实现串起来走。UCIe联盟对互连层做了标准化但标准之下还需要完整的设计工具支撑否则各家用各家的私房流程根本形不成规模化的芯粒生态。举个例子做多裸片设计的时候Die-to-Die接口的时钟域和数据通道怎么建模非常考验工具功底。你在单Die内部可以靠CDC跨时钟域检查工具把亚稳态问题管住但Die和Die之间隔着封装基板和微凸点回传的寄生参数完全不同信号延迟量级也跟Die内部不是一个维度。如果没有一套专门为多Die场景定制的时序预算和签核流程设计团队很容易陷入“裸片内部都快片间一联就出事”的怪圈。2.3 电源、热和机械应力比时序更难啃的骨头大多数做数字设计的人早期的精力全放在时序上到了一定规模之后才意识到真正卡住项目周期的往往是功耗、电压降和热。先进工艺下的电流密度极大电源网络上任何一小段金属不够宽就可能出现IR-drop超标模块直接逻辑翻错。新思这边的PrimeRail做电源完整性签核分析电流密度时可以结合后端物理实现的数据做精确的动态压降分析。在英特尔代工平台上配合PowerVia背面供电这类技术供电网络的设计自由度跟传统正面供电完全不同。如果EDA工具不理解背面供电的物理模型做出来的电源分析就跟实际差了一大截。这属于工艺特性和EDA工具紧密结合的范畴也是这次合作当中的一个技术深水区。热问题更头疼。高性能SoC芯片的热密度已经高到能影响时序签核的准确性因为金属走线的电阻率随温度变化很敏感迁移率也随温度漂移。先进封装里多个裸片叠在一起热源互相影响芯片到封装、到系统散热路径上的每一层都必须建模。这类多物理场问题说实话回头去看那些“流程跑通就算拉倒”的老做法根本经不起推敲。所以我对这次合作的评价是它不是在某个单点上做一次“锦上添花”而是在把系统级芯片设计最脆弱的几个环节全部拿工具链兜住。签核可信度、多Die协同设计、供电与热可靠性这三座大山正好是当前先进芯片团队最头疼的痛点。3. 实操视角把“新思英特尔”流程用起来的几个关键环节新闻稿归新闻稿落到咱们做项目的团队手里关心的始终是一件事这套流程到底怎么跑、参数怎么设、跟以前有什么区别。下面我用实际做项目会遇到的几个节点把能直接用的思路拆开来说。3.1 设计流程起点从架构探索到RTL手写之前很多人以为先进工艺项目的起点是写RTL其实真正专业的大项目第一步是架构与IP选型评估。在这个阶段不会把代码全部写完再去综合而是先用工具拉一个快速原型流程把关键模块的RTL做初步综合拿到门数、面积、功耗、频率的初估值然后判断这个方案到底能不能满足指标。新思联合英特尔做的优化在这个阶段就有作用了。因为工具链对英特尔PDK的支持是“开箱即用”的你在Design Compiler里选好目标工艺库跑一把RTL综合出来的时序面积数据可信度比拿着老库硬凑要高得多。如果一连跑几个版本的架构探索每次都能稳定反映出工艺的真实开销那架构方向就不容易走偏。否则等RTL全部写完才发现关键模块面积爆掉、频率差一截再回头改架构代价是灾难级的。我在这个环节的建议是开工之前先花一周时间拉起一个最小可运行流程用工艺评估套件跑几轮真实RTL做一次“工艺可实施性”摸底。别偷懒直接沿用上一代项目的老脚本先进节点的库特征差异非常明显一个综合策略选项改错最大频率能差10%以上。3.2 物理实现的参数与签核口径物理实现是把RTL变成版图的关键环节也是新思和英特尔合作最出效果的地方。做布局布线的时候工具要自动完成摆放、时钟树综合、布线、时序优化、功耗优化。如果工具对工艺特性理解不到位结果就是要靠工程团队手动去调无数个局部问题谁调谁知道。实际做项目时值得留意的参数大概这么几个时钟树综合的目标偏斜和插入延迟、buf/inverter的最大扇出限制、金属层利用率上限、信号线长阈值、电源网络目标IR-drop。每一类参数都要结合工艺库推荐值做设定千万不要照抄老工艺脚本上的数字。举个例子在PowerVia工艺里供电网络主要在晶圆背面实现正面金属层走线资源变得更宽松布线拥塞策略就得跟着调整。对这类工艺差异新思的工具链里有对应的物理实现流程支持直接用模板改比从零摸索靠谱得多。签核口径方面更是要盯着双方联合校准过的结果来定。时序签核的悲观度设置也就是CPOCCRPR Pessimism Removal和AOCVM这些选项要不要开需要用典型设计做一轮对比试验。我的习惯是拿两三个有代表性的模块分别用保守模式和激进模式跑签核对比一下时序违例数量和总负裕量的变化再决定全芯片统一用什么口径。省下来的人工迭代时间往往比多花的那点机时要值钱得多。3.3 多裸片集成的流程细节与验证闭环如果项目是走多Die方案那必须关注新思那套多裸片设计流程在英特尔封装平台上的表现。这个流程最核心的是片间接口的时序预算管理和多裸片协同物理验证。做多裸片设计时每个Die可以单独做物理实现最终却要放在同一个系统级环境中做签核。不同Die使用各自不同的工艺库、不同电压域、不同的时钟频率怎么把多个Die的时序模型整合到同一个STA环境里就很考验流程的完备性。用统一的格式把每颗Die的接口时序、接口协议、延迟预算定义清楚整机仿真才能在流片前暴露大部分片间时序问题。还有一块容易被忽略的是物理验证的“闭合环”。多Die系统不光每个Die要通过DRC和LVSDie与Die之间的连接性、微凸点的位置、封装基板的布线规则也要做系统级的物理检查。把这些检查全串在同一个环境里设计团队才能保证送出去的GDSII在工厂端不会因为低级连接错误被打回重来。我自己做多Die项目最深的感受是Die内部频繁迭代的同时片间的接口定义必须保持“冻结”。片间协议哪怕只改一个信号极性也会引发连锁的验证返工。所以在项目一开始就找齐所有参与Die的Owner把接口规格书当作合同来维护比任何工具优化都更能防止后期混乱。这个经验放到新思英特尔的流程里同样适用。4. 常见问题与排查实录合作流程里踩过的那些坑任何工具链和工艺库的合作都不可能一开始就顺滑。先进节点的设计项目里很多问题看起来是流程问题实际是工艺理解问题。我挑几个典型场景写出来都是实际操作里反复会碰到的。4.1 时序收敛慢到底卡在哪最让人头疼的场景布局布线跑完时序报告出来一看关键路径延迟超了300ps而且违例路径还不止一条。很多新手工程师的第一反应是调整综合约束、加大优化力度但改完发现效果有限原因往往在于没有定位到真正的瓶颈。常见瓶颈有四种。第一种是布线拥塞导致的绕线过长信号延迟被走线电阻电容拉得老高第二种是扇出太大一个驱动门的负载超过自身驱动能力上升下降时间全线恶化第三种是长距离跨模块传输物理上两个模块距离远信号横穿整个Die延迟自然压不住第四种是库单元驱动强度选得太弱驱动门和负载门之间的阻抗失配。排查方法很简单但需要耐心打开时序报告按路径延时分段看找出哪些路径是被线延迟主导、哪些是单元延迟主导。线延迟主导就去物理层调整布局和布线约束单元延迟主导就把薄弱单元周围的门换强一档。用不着一次性做全身按摩找准两三个最麻烦的点反复三轮迭代比一把全跑收敛来得更快。4.2 签核精度差异引发的“设计反复”流程做签核的时候发现PR工具里跑出来的时序结果和签核工具里跑出来的结果总是差很多这属于工程项目里最烦的一种情况。不仅浪费时间还让人对到底以哪个数字为准产生严重怀疑。要根治这个问题入口在于保证两边的寄生参数提取规则完全一致。布局布线工具里的RC提取和签核工具StarRC提取如果用了不同的提取模式得到的延时一定对不上。我在实际项目里遇到过一种情况布线工具里默认开启了几何邻近效应修正而签核提取用的老提取模式没有打开这个选项结果两边关键路径总延迟差了近8%。解决方法是流程开始前拉个对照表把布局布线工具和签核工具的所有提取选项逐项核对。这个环节不能靠工程师个人习惯必须有项目级的文档约束。越早核对好后头省的事越多。遇到两边工具版本号不一样的情况优先保证签核侧的口径因为最终判项目过不过的是签核报告。4.3 芯粒接口验证的隐性风险多裸片设计最难验证的是片间接口功能是否正确。功能仿真平台上可能跑得通但到了真实硅片上因为时序偏差和信号完整性问题导致误码这种风险单靠仿真根本抓不住。关键要处理的是接口训练序列和初始化时序。Die和Die之间的数据通道往往有训练机制双方连续发送握手序列来校准时钟和数据的相位关系。如果物理设计环节没有给训练逻辑留足够的时序余量上电流程就会不稳定。这种问题在签核报告里不一定以“时序违例”的方式呈现而是变成一个“软错误”的源头。我建议团队在做多Die验证时专门抽出时间建立片间接口的故障注入测试用例把信号完整性问题用系统性验证的方式抛出来比如对数据通道人为加抖动、模拟微凸点阻抗偏差。提前把这些边界条件写进验证计划比等流片回来靠ATE去筛要便宜太多。5. 合作之外这套协同模式的实际影响新思和英特尔的这次携手对产业的影响范围肯定不止两家公司本身。对做系统级芯片设计的团队来说这传递了一个明确信号先进工艺节点的竞争已经从前端设计能力转向全流程的协同能力。5.1 对芯片设计团队意味着什么最大的变化是工具链试错成本的降低。以前设计师用某个新工艺前半年基本都是在跟工具和库的磨合期较劲攒下的经验还不一定带得走。现在大厂直接把“工艺库调优”这个脏活累活前置到工具链里面设计团队拿到手的是一套已经跑顺的基础环境人力可以更集中在架构创新和PPA优化上。对团队人才结构也会产生影响。未来更抢手的一定是既懂前端RTL设计、又懂后端物理实现、还了解先进封装和工艺特性的人。纯做单一环节的工程师在系统级芯片设计语境下面临的挑战会越来越大。5.2 对芯粒生态的带动作用芯粒这个方向喊了好几年真正的阻碍其实不完全是技术本身能不能实现而是生态碎片化。各家EDA厂商都有自己的私房流程各代工厂的先进封装平台也各有特点导致芯粒设计很难形成一套通用、可靠的标准化路径。新思与英特尔联手实际上是在用商业手段推动大家往同一个生态方向上走。工具链对英特尔的工艺和封装平台是“一等公民”支持客户自然更愿意选这条路。一旦跑通几个量产级的多Die项目后来者再想绕开这套成熟生态去另起炉灶难度就越来越大了。5.3 什么类型的项目最适合直接受益如果站在设计团队的选型角度判断自己要不要吃这套红利可以从三类需求来看。第一类正在往先进工艺节点迁移的高性能计算SoC。这类项目对PPA的追求到了极致级别工具与工艺库的深度校准价值最大签核可信度高不高直接决定流片成败。第二类涉及多裸片集成的项目尤其是CPU、GPU、NPU异构组合加UCIe互连的方案。这类项目赶的都是市场窗口期谁能少走弯路谁就能抢先发布。第三类面向AI加速和高带宽互联的芯片设计。这些场景要求大量并行计算单元和超高带宽内存接口系统的时序收敛和电源完整性挑战极大协同优化的价值会被进一步放大。当然做IoT、MCU这类中小规模芯片的团队并不需要一窝蜂跟进。成熟工艺、成熟流程、成熟库的搭配在成本和效率上仍然是最优解。最怕的就是不管项目定位听到“合作”就觉得自己也要从零推倒重来那反而把原有的稳定性给折腾没了。我个人在实际操作中的感受是工具链和代工厂的深度协同解决的是整个行业的系统性效率问题但回到每个具体的项目上最根本的还是要有一个熟悉工具、熟悉工艺、熟悉签核的可靠团队。先进设计流程是放大器团队的能力值才是被放大的底数。底数靠谱放大器才有意义。最后分享一个我自己的小习惯每次换新的工艺库或者新的工具版本无论合作方写得多成熟都一定在最开始留出三周“流程验证期”把典型模块跑一遍完整的综合、布局布线、签核循环把每个关键步骤的结果横向对比一遍。这个前期投入看着是在“拖时间”实际上是在给整个项目周期买保险能避开后面好几倍的返工工时。芯片设计的经验说到底都是从这类细节里一点一点攒出来的。
