2. SoC架构基础：SoC的基本组成、总线与互连架构、存储层次结构

好，咱们开始聊SoC架构。说实话，很多人一上来就盯着CPU、GPU这些大块头，觉得它们才是主角。但我的经验告诉我，真正决定一个SoC能不能打、好不好用的，往往是那些“看不见”的部分——总线怎么连、数据怎么搬、存储怎么管。今天我就把这些基础掰开揉碎了讲给你听。

2.1 SoC的基本组成：不只是CPU的“全家桶”

一个典型的SoC，说白了就是把一台电脑的核心部件全塞进一颗芯片里。你想想看，它得有大脑（CPU）、有显卡（GPU）、有专门的AI加速器（NPU），还得有内存控制器、各种外设接口（USB、PCIe、I2C、SPI……），以及最重要的——把所有这些串起来的互连结构。

我个人习惯把SoC的组件分成三类：

• 计算单元：CPU、GPU、NPU、DSP，负责干活。
• 存储单元：Cache、SRAM、DRAM控制器，负责存东西。
• 互连与接口：总线、NoC（片上网络）、各种协议桥接，负责“修路”。

我在项目中遇到过一种情况：团队花了大半年调优NPU的算力，结果最后系统性能上不去。查来查去，发现是CPU和NPU之间共享的一条总线带宽不够，数据堵在半路上。嗯，这就是典型的“木桶效应”——短板往往不在计算，而在互连。

2.2 总线与互连架构：SoC的“高速公路网”

互连架构，就是SoC内部的数据通路。它决定了数据从A点到B点要花多长时间、能同时跑多少趟车。早期的SoC用简单的总线（比如AMBA AHB/APB），但现在的异构SoC，CPU、GPU、NPU各跑各的频率，各要各的带宽，传统总线根本扛不住。

2.2.1 传统总线 vs. 片上网络

传统总线（比如ARM的AMBA AXI）是共享式的。所有主设备（Master）挂在一条线上，谁用谁申请。好处是简单，坏处是——你想想看，一条路上车多了，肯定堵。我记得有一次做一款AI芯片，CPU和GPU同时访问DDR，结果总线仲裁器忙得冒烟，延迟直接翻倍。

后来大家开始用NoC（Network-on-Chip，片上网络）。NoC把互连从“一条马路”变成了“立交桥网络”。每个模块都有自己的路由器，数据包走最短路径。说白了，就是给数据开了个导航。

2.2.2 一致性互连：让CPU、GPU、NPU“说同一种语言”

这里有个坑，我踩过。CPU和GPU各自有独立的Cache。CPU改了数据，GPU不知道，还在用旧数据——这就叫“不一致”。解决这个问题，需要一致性互连协议，比如ARM的ACE或CHI。

一致性互连的核心，就是让所有计算单元看到同一份数据的最新版本。怎么做？靠“监听”或“目录”机制。CPU写数据时，互连会通知GPU：“嘿，你Cache里那份数据过期了，别用了。”

下面这张图，是我画的一个典型异构SoC互连架构。你可以看到CPU、GPU、NPU通过一致性互连连接到共享的LLC（最后一级缓存）和内存控制器。

2.3 存储层次结构：从纳秒到微秒的“数据仓库”

存储层次，是SoC里另一个容易翻车的地方。CPU希望数据“秒到”，但DRAM的延迟是几十纳秒，SSD是几十微秒——差了上千倍。怎么办？用Cache一层层兜底。

典型的存储层次是这样的：

这里有个关键点：LLC（最后一级缓存）是所有计算单元的“汇合点”。CPU、GPU、NPU的数据一致性，就是在LLC这一层维护的。我曾经参与过一个项目，LLC设计得偏小，结果GPU和NPU频繁争抢，命中率掉到60%以下，性能惨不忍睹。

2.3.1 一致性协议对存储层次的影响

你可能会问：一致性协议怎么影响存储？举个例子，ACE协议要求所有Cache行都处于“共享”、“独占”、“修改”、“无效”四种状态之一。每次数据修改，都要发“嗅探”（Snoop）请求给其他Cache。这意味着LLC不仅要存数据，还得维护一张“谁有这份数据”的目录表。

嗯，这里要注意：目录表的大小和LLC的容量是矛盾的。目录太大，LLC存数据的地方就少了。我见过一个设计，为了支持256核的一致性，目录占了LLC的30%空间——得不偿失。

所以，实际工程中，我们经常做“折中”。比如只对CPU和GPU之间的共享数据做一致性，NPU的私有数据走独立通道。这样既保证了关键路径的一致性，又避免了性能开销。

好了，这一章的内容就到这里。记住我说的：别光盯着算力，多看看数据怎么流、存在哪、怎么保证大家看到的是同一份数据。这些“基础”的东西，才是决定SoC成败的关键。

公众号:蓝海资料掘金营，微信deep3321