4、AXI互连架构（一）：单点对点连接、共享总线架构、Crossbar（交叉开关）架构

大家好，我是老李。今天咱们聊聊AXI互连架构。说实话，这玩意儿是SoC设计里最绕不开的话题之一。我入行那会儿，第一个项目就是调一个多主多从的AXI总线，折腾得我够呛。后来慢慢摸透了，才发现其实核心就三种架构：点对点、共享总线、Crossbar。搞懂它们，你就能应付绝大多数场景了。

先说说最简单的。单点对点，就是一个主设备连一个从设备。没有仲裁，没有地址译码，信号直连。说白了，就是一根线拉过去完事。

适用场景：CPU直连私有SRAM、DMA直连某个专用外设。

我在一个低功耗IoT芯片项目里用过这种方案。当时CPU要频繁访问一个很小的配置寄存器组，我就没走系统总线，直接拉了一组AXI-Lite过去。省掉了总线矩阵的延迟和功耗，效果很好。

但要注意，这种架构扩展性很差。你想想看，每加一个主设备，就得给每个从设备多拉一组线。SoC里主设备一多，布线资源就炸了。所以它只适合固定、少量的连接。

接下来是共享总线。这是早期SoC最常用的方案。所有主设备挂在一条总线上，通过仲裁器决定谁用总线。从设备也挂在上面，通过地址译码器选择谁被访问。

嗯，这里要注意一个关键点：同一时刻，只能有一个主设备发起传输。其他主设备都得等着。

我曾经在一个多核处理器项目里吃过这个亏。三个CPU核共享一条AXI总线，结果高负载时总线利用率飙到90%以上，延迟大得离谱。后来一分析，发现是仲裁策略太简单，低优先级的主设备经常被饿死。

避坑指南：我曾经在共享总线上挂了一个高带宽的GPU和一个低延迟的CPU。结果GPU一发起长burst传输，CPU的请求就被堵在后面。后来我改用了基于优先级的仲裁，并给CPU开了个旁路通道，才算解决。

共享总线的优点是简单、面积小、功耗低。缺点也很明显：带宽受限、延迟不可控、扩展性差。适合主设备少、带宽要求不高的场景，比如一些MCU级别的芯片。

Crossbar，也叫交叉开关。它本质上是一个全连接的交换矩阵。每个主设备都有独立的路径到每个从设备。多个主设备可以同时访问不同的从设备，互不干扰。

说白了，共享总线是单车道，Crossbar是多车道立交桥。

我参与过一个AI加速器芯片的设计，里面用了4个CPU核、2个DMA、1个硬件加速器，总共7个主设备。从设备有DDR控制器、SRAM、PCIe控制器等。如果用共享总线，带宽根本不够。最后我们上了Crossbar，每个主设备都有独立的读写通道，带宽直接翻了7倍。

核心优势：并行传输、高带宽、低延迟、无阻塞（前提是访问不同的从设备）。

但Crossbar不是万能的。它的面积和功耗随端口数呈O(n²)增长。你想想看，4个主设备连4个从设备，需要16条独立的通道。如果是16个主设备连16个从设备，那就是256条通道。芯片面积和功耗会爆炸。

所以实际项目中，我们很少用全连接的Crossbar。更多是用部分连接的Crossbar，或者结合共享总线做分层设计。比如，把高带宽的主设备（如GPU）和从设备（如DDR）放在一个Crossbar里，低带宽的设备走共享总线。

特性	单点对点	共享总线	Crossbar
并行度	1对1	1对1（同一时刻）	多对多（同时）
带宽	固定	共享，易瓶颈	高，可扩展
面积	最小	中等	大（O(n²)）
延迟	最低	中等（有仲裁）	低（无阻塞时）
扩展性	差	一般	好（但代价高）
典型应用	CPU-私有SRAM	MCU、低端SoC	高性能SoC、AI芯片

下面这张图总结了三种架构的核心逻辑和适用场景。我建议你把它存下来，以后做架构选型时拿出来对照一下。

我个人习惯，拿到一个SoC架构需求后，会先做三件事：

数主设备数量：少于3个，考虑共享总线；3-8个，考虑Crossbar；超过8个，必须做分层。
看带宽需求：如果所有主设备的总带宽需求超过单条总线的带宽，直接上Crossbar。
分析访问模式：如果主设备经常访问不同的从设备，Crossbar优势巨大。如果都抢同一个从设备（比如DDR），那Crossbar也救不了你，得从存储系统层面优化。

重要提醒：不要盲目追求Crossbar。我见过一个项目，明明只有两个主设备，非要上Crossbar，结果面积大了30%，功耗高了20%，性能提升不到5%。纯属浪费。

好了，今天的内容就到这里。三种架构各有优劣，关键是根据实际需求做权衡。下一节我们会深入AXI的时序和协议细节，到时候再聊。

可可精品资料库