1. 从“全员买IP”说起一颗SoC到底在拼什么这两年跟做芯片的朋友聊天绕不开一个话题IP采购。以前一颗SoC里自研模块还能占个三四成现在打开任何一个中高端手机SoC或者车规芯片的架构图CPU核、GPU核、NPU、ISP、DSP、各种控制器和PHY几乎清一色是外购IP攒起来的。有人开玩笑说现在做SoC设计越来越像“搭乐高”——只要预算够货架上什么都有。但真正做过完整流片的人都知道买IP只是开始把几十上百个IP塞进一颗芯片还能跑起来才是噩梦的开始。SoCSystem on Chip的本质不是“把IP堆在一起”而是要让这些来自不同供应商、不同工艺节点、不同时钟域、不同电源域的模块在同一个硅片上和谐共处。这中间的难点远比“买什么IP”要复杂得多。这篇文章我想聊的就是这件事在全员买IP的大背景下大型SoC芯片设计真正的难点在哪里。适合正在做SoC集成、验证、后端实现的工程师也适合想了解芯片设计全貌的产品和项目管理者。我会从架构选型、IP集成、验证、物理实现、低功耗、启动流程几个维度拆开讲尽量把每个“为什么”说清楚而不是只丢结论。2. 大型SoC设计的整体思路与架构选型2.1 为什么“买IP”反而让架构设计更难很多人有个误解IP都是买来的架构设计应该变简单了。实际情况恰恰相反。当你自研模块时你可以为了系统整体最优去调整模块的接口、时序、功耗策略。但当你买IP时每个IP都带着供应商的假设和约束你只能去适配它。举个最典型的例子总线协议。一颗大型SoC里可能同时存在AXI、AHB、APB、ACE、CHI等多种协议。CPU集群可能用的是CHIGPU用的是ACE-Lite外设用的是AXI4-Lite。你要设计一个互联总线NoC或Crossbar把这些协议打通还要保证带宽、延迟、QoS满足各个主设备的需求。这个互联结构的设计直接决定了芯片的性能上限。我个人的经验是架构阶段最花时间的不是画框图而是做带宽预算和延迟预算。比如一个4K视频编码场景ISP要往内存写多少数据DDR控制器要提供多少带宽NoC的哪条路径会成为瓶颈这些都要在架构阶段用Excel或者Python脚本算清楚。等RTL写完再发现带宽不够那就只能改架构代价是几个月的时间。2.2 工艺节点选择与IP可用性的博弈大型SoC设计还有一个绕不开的决策选哪个工艺节点。先进工艺比如5nm、4nm能带来更好的PPAPower, Performance, Area但问题是——你需要的IP在先进工艺上不一定有。我见过不少项目架构定完了去问IP供应商发现某个关键的PHY IP只有7nm的版本5nm还在开发中。这时候要么换工艺要么换IP要么等。IP的工艺可用性往往比工艺本身的性能更重要。所以在项目立项阶段一定要先做一轮IP可用性调研把关键IP的工艺路线图摸清楚。另外先进工艺的流片成本极高。一套5nm的掩膜版费用可能够买好几套房所以一次流片成功的压力非常大。这就要求验证和物理实现的成熟度必须跟上不能有“先流一版试试”的心态。2.3 从系统需求到架构拆解的实际步骤我通常会把架构设计分成这么几步走场景分析列出芯片要支持的所有应用场景比如手机SoC要覆盖拍照、游戏、视频通话、AI推理等。性能建模对每个场景做带宽、算力、延迟的估算形成量化指标。IP选型根据指标去市场上找匹配的IP同时评估自研的必要性。互联设计设计NoC或总线结构做带宽和QoS分配。时钟与电源域划分确定哪些模块可以共时钟、共电源哪些需要独立控制。地址空间分配给每个IP分配寄存器地址规划内存映射。这六步里地址空间分配看起来最简单其实最容易出问题。我踩过的坑是早期地址分配没做好后期加了一个IP发现地址空间不够了只能重新分配导致所有软件的驱动都要改。所以地址空间一定要留足余量至少预留20%到30%的空闲区域。3. IP集成中的核心难点与实操要点3.1 时钟域交叉那些让人头秃的CDC问题大型SoC里通常有几十个时钟域。CPU跑在2GHz以上外设可能只有几十MHzDDR控制器有自己的时钟USB PHY又有自己的时钟。不同时钟域之间的信号传递必须做CDCClock Domain Crossing处理。CDC做不好轻则功能异常重则芯片直接挂掉。常见的CDC问题包括亚稳态信号在时钟边沿附近变化导致接收端采样到不确定的值。多比特信号同步如果多个比特同时跨时钟域可能采样到中间状态。脉冲丢失快时钟域的脉冲信号传到慢时钟域可能被漏采。实操中我一般会要求所有跨时钟域信号必须经过两级触发器同步多比特信号用握手协议或者格雷码。对于异步FIFO一定要用供应商提供的经过硅验证的版本不要自己写。注意CDC检查工具如SpyGlass CDC报出的warning不能随便waive每一条都要有明确的理由。我见过项目因为waive了一条CDC warning流片后出现偶发性死机查了三个月才定位到。3.2 电源域与Power Rail设计低功耗的代价现在的SoC没有不做低功耗的。电源域划分是低功耗设计的基础。一个典型的手机SoC可能有十几个电源域CPU集群、GPU、ISP、显示、音频、Always-On区域等等。电源域划分的核心矛盾是划分越细功耗控制越灵活但设计复杂度越高。每个电源域都需要独立的Power Rail、电源开关、隔离单元Isolation Cell、电平转换器Level Shifter和保持寄存器Retention Flop。Power Rail的设计尤其关键。IR Drop是这里最大的敌人——如果电源网络设计不好芯片工作时电压会下降导致时序违例甚至功能错误。我做过的一个项目就是因为某个高功耗模块的Power Rail宽度不够导致局部IR Drop超过10%最后不得不加宽金属线牺牲了面积。实操建议早期做Power Plan时一定要用工具做IR Drop分析不要凭经验拍脑袋。电源开关的尺寸要算清楚太大浪费面积太小压降太大。隔离单元的位置和使能信号要仔细检查避免上电时出现浮空信号。3.3 地址映射与寄存器管理软件和硬件的契约地址映射是软硬件之间的接口契约。一旦流片地址就改不了了。所以地址分配必须慎之又慎。我通常的做法是用脚本自动生成地址映射表避免手工出错。每个IP的地址空间按4KB对齐方便MMU页表管理。预留足够的地址空洞方便后期扩展。对安全相关的寄存器单独划分区域加访问权限控制。寄存器管理还有一个容易被忽视的点寄存器复位值。有些寄存器的复位值会影响芯片启动行为如果复位值不对可能导致芯片上电后无法启动。我建议所有寄存器的复位值都要在验证阶段逐一确认不能想当然。3.4 中断与调试子系统被低估的复杂度大型SoC里可能有几百个中断源。中断控制器的设计直接影响到系统的实时性和软件复杂度。GICGeneric Interrupt Controller是ARM体系里的标准方案但配置起来并不简单。中断的难点在于优先级分配哪些中断可以抢占哪些中断要跟软件团队对齐。中断路由多核系统中中断应该发给哪个核需要精细配置。中断聚合大量低速中断如果直接发给CPU会严重影响性能需要做聚合处理。调试子系统同样重要。JTAG、Trace、Performance Monitor这些模块平时不起眼但芯片回来后如果发现问题没有调试手段就是抓瞎。我建议在架构阶段就把调试方案定下来不要等到后端再补。4. 验证与物理实现流片前的最后关卡4.1 SoC验证的策略与开源方案验证占了SoC设计周期的一半以上时间。大型SoC的验证难点在于状态空间太大无法穷举。所以验证策略必须是基于覆盖率的、分层的。我通常把验证分成几层IP级验证供应商通常会提供IP的验证环境但你不能完全信任关键功能要自己再验一遍。子系统级验证把几个相关的IP集成在一起验证比如CPU子系统、显示子系统。SoC级验证全芯片验证重点验证互联、中断、启动流程、低功耗序列。这几年开源验证方案越来越成熟。比如基于UVM的验证框架还有RISC-V生态里的开源验证IP。对于预算有限的团队合理利用开源方案可以省下不少成本。但要注意开源方案的质量参差不齐用之前一定要做充分评估。提示验证环境本身也是代码也需要review和版本管理。我见过验证环境里的bug导致漏验最后流片失败的案例。4.2 形式验证与等价性检查形式验证Formal Verification在大型SoC里越来越重要。它不需要激励而是通过数学方法证明设计满足某些属性。常用的场景包括CDC检查证明跨时钟域处理是正确的。等价性检查证明RTL和网表的功能一致。协议一致性检查证明总线行为符合协议规范。形式验证的优点是完备性缺点是状态空间爆炸。对于大型设计通常需要做黑盒化处理把不相关的模块屏蔽掉只验证关键路径。4.3 物理实现从网表到GDSII的最后一公里物理实现Physical Implementation是把RTL变成可以流片的版图。这一步的难点在于同时满足时序、功耗、面积、可制造性四个维度的约束。大型SoC的物理实现通常分块进行每个模块单独做Place Route最后在顶层集成。这里最大的挑战是顶层布线拥塞。如果模块的引脚分配不合理顶层布线会非常困难甚至无法收敛。我的经验是早期做Floorplan时就要考虑顶层布线的需求给关键信号预留通道。Pin Assignment要用工具辅助不要手工摆。时序收敛要分阶段做先解决建立时间Setup再解决保持时间Hold。DRC/LVS检查必须干净任何一条违规都可能导致流片失败。4.4 低功耗序列验证容易被忽略的角落低功耗设计的功能验证往往被放在最后但它其实非常关键。电源开关序列、隔离使能、保持寄存器的保存与恢复这些如果出错芯片可能在某些场景下直接死机。我建议专门为低功耗序列写一套验证用例覆盖正常上电和下电流程。电源域的动态开关。低功耗模式之间的切换。异常情况下的电源管理比如突然断电。这些用例要跑在带电源信息的仿真环境里比如UPFUnified Power Format流程。普通的RTL仿真无法验证电源行为。5. 芯片启动与常见问题排查5.1 SoC启动流程从上电到操作系统SoC的启动流程是芯片设计里最复杂的序列之一。一个典型的启动流程包括上电复位所有寄存器恢复到复位值。Boot ROM执行芯片内部固化的启动代码开始运行。时钟初始化配置PLL把时钟切到目标频率。DDR初始化训练DDR控制器让内存可用。加载Bootloader从Flash或外部接口加载二级启动代码。加载操作系统把OS内核搬到内存跳转执行。这个流程里DDR初始化是最容易出问题的环节。DDR训练涉及大量的时序参数不同批次的DDR颗粒可能表现不一样。我见过项目因为DDR训练失败导致芯片无法启动最后只能改Boot ROM重新流片。5.2 常见问题速查表问题现象可能原因排查思路芯片上电无反应电源域未上电、复位信号异常检查Power Rail电压、复位时序启动卡在Boot ROM时钟未锁定、Boot ROM代码bug用JTAG读PC指针检查PLL锁定状态DDR训练失败时序参数不对、PCB走线问题调整训练参数检查PCB阻抗系统偶发死机CDC问题、亚稳态跑CDC检查加同步逻辑功耗超标电源域未关断、时钟未门控检查低功耗序列用功耗分析工具中断丢失中断控制器配置错误检查GIC配置确认优先级和路由5.3 调试手段与经验技巧芯片回来后调试手段非常有限。JTAG是最基本的调试接口但速度慢。Trace可以记录CPU的执行轨迹但需要额外的引脚和存储。Performance Monitor可以统计性能事件帮助定位瓶颈。我的经验是在芯片里多留调试寄存器哪怕流片时用不到后期调试时可能救命。Boot ROM里加自检代码上电时自动检查关键模块是否正常。保留一个Always-On的调试通道即使系统挂死也能访问。注意调试接口也可能成为安全漏洞量产芯片里一定要做访问控制。6. 一些个人体会与后续可扩展的方向做大型SoC设计这些年我最大的体会是买IP容易集成难画框图容易收敛难流片容易量产难。每一个环节都有无数的细节任何一个细节出错都可能导致项目延期甚至失败。如果让我给新入行的工程师一个建议那就是不要只盯着自己负责的模块要理解整个系统的运作。做集成的要懂验证做验证的要懂物理实现做后端的要懂架构。只有站在系统层面看问题才能做出真正可靠的芯片。后续如果大家感兴趣我可以再展开聊聊Chiplet技术对SoC设计的影响或者RISC-V生态下的SoC设计新范式。这两个方向都在快速演进值得持续关注。 
长河君 · 2026/10/1 1:21:58 · 阅读 1.2k 大型SoC芯片设计：IP集成、验证与物理实现的核心难点
1. 从“全员买IP”说起一颗SoC到底在拼什么这两年跟做芯片的朋友聊天绕不开一个话题IP采购。以前一颗SoC里自研模块还能占个三四成现在打开任何一个中高端手机SoC或者车规芯片的架构图CPU核、GPU核、NPU、ISP、DSP、各种控制器和PHY几乎清一色是外购IP攒起来的。有人开玩笑说现在做SoC设计越来越像“搭乐高”——只要预算够货架上什么都有。但真正做过完整流片的人都知道买IP只是开始把几十上百个IP塞进一颗芯片还能跑起来才是噩梦的开始。SoCSystem on Chip的本质不是“把IP堆在一起”而是要让这些来自不同供应商、不同工艺节点、不同时钟域、不同电源域的模块在同一个硅片上和谐共处。这中间的难点远比“买什么IP”要复杂得多。这篇文章我想聊的就是这件事在全员买IP的大背景下大型SoC芯片设计真正的难点在哪里。适合正在做SoC集成、验证、后端实现的工程师也适合想了解芯片设计全貌的产品和项目管理者。我会从架构选型、IP集成、验证、物理实现、低功耗、启动流程几个维度拆开讲尽量把每个“为什么”说清楚而不是只丢结论。2. 大型SoC设计的整体思路与架构选型2.1 为什么“买IP”反而让架构设计更难很多人有个误解IP都是买来的架构设计应该变简单了。实际情况恰恰相反。当你自研模块时你可以为了系统整体最优去调整模块的接口、时序、功耗策略。但当你买IP时每个IP都带着供应商的假设和约束你只能去适配它。举个最典型的例子总线协议。一颗大型SoC里可能同时存在AXI、AHB、APB、ACE、CHI等多种协议。CPU集群可能用的是CHIGPU用的是ACE-Lite外设用的是AXI4-Lite。你要设计一个互联总线NoC或Crossbar把这些协议打通还要保证带宽、延迟、QoS满足各个主设备的需求。这个互联结构的设计直接决定了芯片的性能上限。我个人的经验是架构阶段最花时间的不是画框图而是做带宽预算和延迟预算。比如一个4K视频编码场景ISP要往内存写多少数据DDR控制器要提供多少带宽NoC的哪条路径会成为瓶颈这些都要在架构阶段用Excel或者Python脚本算清楚。等RTL写完再发现带宽不够那就只能改架构代价是几个月的时间。2.2 工艺节点选择与IP可用性的博弈大型SoC设计还有一个绕不开的决策选哪个工艺节点。先进工艺比如5nm、4nm能带来更好的PPAPower, Performance, Area但问题是——你需要的IP在先进工艺上不一定有。我见过不少项目架构定完了去问IP供应商发现某个关键的PHY IP只有7nm的版本5nm还在开发中。这时候要么换工艺要么换IP要么等。IP的工艺可用性往往比工艺本身的性能更重要。所以在项目立项阶段一定要先做一轮IP可用性调研把关键IP的工艺路线图摸清楚。另外先进工艺的流片成本极高。一套5nm的掩膜版费用可能够买好几套房所以一次流片成功的压力非常大。这就要求验证和物理实现的成熟度必须跟上不能有“先流一版试试”的心态。2.3 从系统需求到架构拆解的实际步骤我通常会把架构设计分成这么几步走场景分析列出芯片要支持的所有应用场景比如手机SoC要覆盖拍照、游戏、视频通话、AI推理等。性能建模对每个场景做带宽、算力、延迟的估算形成量化指标。IP选型根据指标去市场上找匹配的IP同时评估自研的必要性。互联设计设计NoC或总线结构做带宽和QoS分配。时钟与电源域划分确定哪些模块可以共时钟、共电源哪些需要独立控制。地址空间分配给每个IP分配寄存器地址规划内存映射。这六步里地址空间分配看起来最简单其实最容易出问题。我踩过的坑是早期地址分配没做好后期加了一个IP发现地址空间不够了只能重新分配导致所有软件的驱动都要改。所以地址空间一定要留足余量至少预留20%到30%的空闲区域。3. IP集成中的核心难点与实操要点3.1 时钟域交叉那些让人头秃的CDC问题大型SoC里通常有几十个时钟域。CPU跑在2GHz以上外设可能只有几十MHzDDR控制器有自己的时钟USB PHY又有自己的时钟。不同时钟域之间的信号传递必须做CDCClock Domain Crossing处理。CDC做不好轻则功能异常重则芯片直接挂掉。常见的CDC问题包括亚稳态信号在时钟边沿附近变化导致接收端采样到不确定的值。多比特信号同步如果多个比特同时跨时钟域可能采样到中间状态。脉冲丢失快时钟域的脉冲信号传到慢时钟域可能被漏采。实操中我一般会要求所有跨时钟域信号必须经过两级触发器同步多比特信号用握手协议或者格雷码。对于异步FIFO一定要用供应商提供的经过硅验证的版本不要自己写。注意CDC检查工具如SpyGlass CDC报出的warning不能随便waive每一条都要有明确的理由。我见过项目因为waive了一条CDC warning流片后出现偶发性死机查了三个月才定位到。3.2 电源域与Power Rail设计低功耗的代价现在的SoC没有不做低功耗的。电源域划分是低功耗设计的基础。一个典型的手机SoC可能有十几个电源域CPU集群、GPU、ISP、显示、音频、Always-On区域等等。电源域划分的核心矛盾是划分越细功耗控制越灵活但设计复杂度越高。每个电源域都需要独立的Power Rail、电源开关、隔离单元Isolation Cell、电平转换器Level Shifter和保持寄存器Retention Flop。Power Rail的设计尤其关键。IR Drop是这里最大的敌人——如果电源网络设计不好芯片工作时电压会下降导致时序违例甚至功能错误。我做过的一个项目就是因为某个高功耗模块的Power Rail宽度不够导致局部IR Drop超过10%最后不得不加宽金属线牺牲了面积。实操建议早期做Power Plan时一定要用工具做IR Drop分析不要凭经验拍脑袋。电源开关的尺寸要算清楚太大浪费面积太小压降太大。隔离单元的位置和使能信号要仔细检查避免上电时出现浮空信号。3.3 地址映射与寄存器管理软件和硬件的契约地址映射是软硬件之间的接口契约。一旦流片地址就改不了了。所以地址分配必须慎之又慎。我通常的做法是用脚本自动生成地址映射表避免手工出错。每个IP的地址空间按4KB对齐方便MMU页表管理。预留足够的地址空洞方便后期扩展。对安全相关的寄存器单独划分区域加访问权限控制。寄存器管理还有一个容易被忽视的点寄存器复位值。有些寄存器的复位值会影响芯片启动行为如果复位值不对可能导致芯片上电后无法启动。我建议所有寄存器的复位值都要在验证阶段逐一确认不能想当然。3.4 中断与调试子系统被低估的复杂度大型SoC里可能有几百个中断源。中断控制器的设计直接影响到系统的实时性和软件复杂度。GICGeneric Interrupt Controller是ARM体系里的标准方案但配置起来并不简单。中断的难点在于优先级分配哪些中断可以抢占哪些中断要跟软件团队对齐。中断路由多核系统中中断应该发给哪个核需要精细配置。中断聚合大量低速中断如果直接发给CPU会严重影响性能需要做聚合处理。调试子系统同样重要。JTAG、Trace、Performance Monitor这些模块平时不起眼但芯片回来后如果发现问题没有调试手段就是抓瞎。我建议在架构阶段就把调试方案定下来不要等到后端再补。4. 验证与物理实现流片前的最后关卡4.1 SoC验证的策略与开源方案验证占了SoC设计周期的一半以上时间。大型SoC的验证难点在于状态空间太大无法穷举。所以验证策略必须是基于覆盖率的、分层的。我通常把验证分成几层IP级验证供应商通常会提供IP的验证环境但你不能完全信任关键功能要自己再验一遍。子系统级验证把几个相关的IP集成在一起验证比如CPU子系统、显示子系统。SoC级验证全芯片验证重点验证互联、中断、启动流程、低功耗序列。这几年开源验证方案越来越成熟。比如基于UVM的验证框架还有RISC-V生态里的开源验证IP。对于预算有限的团队合理利用开源方案可以省下不少成本。但要注意开源方案的质量参差不齐用之前一定要做充分评估。提示验证环境本身也是代码也需要review和版本管理。我见过验证环境里的bug导致漏验最后流片失败的案例。4.2 形式验证与等价性检查形式验证Formal Verification在大型SoC里越来越重要。它不需要激励而是通过数学方法证明设计满足某些属性。常用的场景包括CDC检查证明跨时钟域处理是正确的。等价性检查证明RTL和网表的功能一致。协议一致性检查证明总线行为符合协议规范。形式验证的优点是完备性缺点是状态空间爆炸。对于大型设计通常需要做黑盒化处理把不相关的模块屏蔽掉只验证关键路径。4.3 物理实现从网表到GDSII的最后一公里物理实现Physical Implementation是把RTL变成可以流片的版图。这一步的难点在于同时满足时序、功耗、面积、可制造性四个维度的约束。大型SoC的物理实现通常分块进行每个模块单独做Place Route最后在顶层集成。这里最大的挑战是顶层布线拥塞。如果模块的引脚分配不合理顶层布线会非常困难甚至无法收敛。我的经验是早期做Floorplan时就要考虑顶层布线的需求给关键信号预留通道。Pin Assignment要用工具辅助不要手工摆。时序收敛要分阶段做先解决建立时间Setup再解决保持时间Hold。DRC/LVS检查必须干净任何一条违规都可能导致流片失败。4.4 低功耗序列验证容易被忽略的角落低功耗设计的功能验证往往被放在最后但它其实非常关键。电源开关序列、隔离使能、保持寄存器的保存与恢复这些如果出错芯片可能在某些场景下直接死机。我建议专门为低功耗序列写一套验证用例覆盖正常上电和下电流程。电源域的动态开关。低功耗模式之间的切换。异常情况下的电源管理比如突然断电。这些用例要跑在带电源信息的仿真环境里比如UPFUnified Power Format流程。普通的RTL仿真无法验证电源行为。5. 芯片启动与常见问题排查5.1 SoC启动流程从上电到操作系统SoC的启动流程是芯片设计里最复杂的序列之一。一个典型的启动流程包括上电复位所有寄存器恢复到复位值。Boot ROM执行芯片内部固化的启动代码开始运行。时钟初始化配置PLL把时钟切到目标频率。DDR初始化训练DDR控制器让内存可用。加载Bootloader从Flash或外部接口加载二级启动代码。加载操作系统把OS内核搬到内存跳转执行。这个流程里DDR初始化是最容易出问题的环节。DDR训练涉及大量的时序参数不同批次的DDR颗粒可能表现不一样。我见过项目因为DDR训练失败导致芯片无法启动最后只能改Boot ROM重新流片。5.2 常见问题速查表问题现象可能原因排查思路芯片上电无反应电源域未上电、复位信号异常检查Power Rail电压、复位时序启动卡在Boot ROM时钟未锁定、Boot ROM代码bug用JTAG读PC指针检查PLL锁定状态DDR训练失败时序参数不对、PCB走线问题调整训练参数检查PCB阻抗系统偶发死机CDC问题、亚稳态跑CDC检查加同步逻辑功耗超标电源域未关断、时钟未门控检查低功耗序列用功耗分析工具中断丢失中断控制器配置错误检查GIC配置确认优先级和路由5.3 调试手段与经验技巧芯片回来后调试手段非常有限。JTAG是最基本的调试接口但速度慢。Trace可以记录CPU的执行轨迹但需要额外的引脚和存储。Performance Monitor可以统计性能事件帮助定位瓶颈。我的经验是在芯片里多留调试寄存器哪怕流片时用不到后期调试时可能救命。Boot ROM里加自检代码上电时自动检查关键模块是否正常。保留一个Always-On的调试通道即使系统挂死也能访问。注意调试接口也可能成为安全漏洞量产芯片里一定要做访问控制。6. 一些个人体会与后续可扩展的方向做大型SoC设计这些年我最大的体会是买IP容易集成难画框图容易收敛难流片容易量产难。每一个环节都有无数的细节任何一个细节出错都可能导致项目延期甚至失败。如果让我给新入行的工程师一个建议那就是不要只盯着自己负责的模块要理解整个系统的运作。做集成的要懂验证做验证的要懂物理实现做后端的要懂架构。只有站在系统层面看问题才能做出真正可靠的芯片。后续如果大家感兴趣我可以再展开聊聊Chiplet技术对SoC设计的影响或者RISC-V生态下的SoC设计新范式。这两个方向都在快速演进值得持续关注。