ARTICLE DETAIL

资讯详情

深耕网站建设、视觉设计与SEO优化的一线实战洞察。

新思科技与英特尔联手加速系统级芯片设计,破解先进工艺EDA协同瓶颈

新思科技与英特尔联手加速系统级芯片设计,破解先进工艺EDA协同瓶颈

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集成已经是非常明确的方向,但很多人低估了流程上的断裂严重到什么程度。

过去做SoC,Die和封装是两个相对独立的专业分工:前端做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工艺里,供电网络主要在晶圆背面实现,正面金属层走线资源变得更宽松,布线拥塞策略就得跟着调整。对这类工艺差异,新思的工具链里有对应的物理实现流程支持,直接用模板改比从零摸索靠谱得多。

签核口径方面,更是要盯着双方联合校准过的结果来定。时序签核的悲观度设置,也就是CPOC(CRPR Pessimism Removal)和AOCVM这些选项要不要开,需要用典型设计做一轮对比试验。我的习惯是拿两三个有代表性的模块,分别用保守模式和激进模式跑签核,对比一下时序违例数量和总负裕量的变化,再决定全芯片统一用什么口径。省下来的人工迭代时间,往往比多花的那点机时要值钱得多。

3.3 多裸片集成的流程细节与验证闭环

如果项目是走多Die方案,那必须关注新思那套多裸片设计流程在英特尔封装平台上的表现。这个流程最核心的是片间接口的时序预算管理和多裸片协同物理验证。

做多裸片设计时,每个Die可以单独做物理实现,最终却要放在同一个系统级环境中做签核。不同Die使用各自不同的工艺库、不同电压域、不同的时钟频率,怎么把多个Die的时序模型整合到同一个STA环境里,就很考验流程的完备性。用统一的格式把每颗Die的接口时序、接口协议、延迟预算定义清楚,整机仿真才能在流片前暴露大部分片间时序问题。

还有一块容易被忽略的是物理验证的“闭合环”。多Die系统不光每个Die要通过DRC和LVS,Die与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这类中小规模芯片的团队,并不需要一窝蜂跟进。成熟工艺、成熟流程、成熟库的搭配,在成本和效率上仍然是最优解。最怕的就是不管项目定位,听到“合作”就觉得自己也要从零推倒重来,那反而把原有的稳定性给折腾没了。

我个人在实际操作中的感受是,工具链和代工厂的深度协同,解决的是整个行业的系统性效率问题,但回到每个具体的项目上,最根本的还是要有一个熟悉工具、熟悉工艺、熟悉签核的可靠团队。先进设计流程是放大器,团队的能力值才是被放大的底数。底数靠谱,放大器才有意义。

最后分享一个我自己的小习惯:每次换新的工艺库或者新的工具版本,无论合作方写得多成熟,都一定在最开始留出三周“流程验证期”,把典型模块跑一遍完整的综合、布局布线、签核循环,把每个关键步骤的结果横向对比一遍。这个前期投入看着是在“拖时间”,实际上是在给整个项目周期买保险,能避开后面好几倍的返工工时。芯片设计的经验,说到底都是从这类细节里一点一点攒出来的。

返回列表