一、课程导学与背景：为什么需要AXI互连与SerDes？
各位同学好，我是老李。在芯片行业摸爬滚打了十几年，今天想跟你们聊聊一个很实在的话题——为什么我们的芯片里，需要AXI互连和SerDes这两种技术？
说白了，这俩东西解决的是同一个问题：数据怎么在芯片内部和芯片之间高效地跑起来。
我刚开始做设计那会儿，芯片里的总线结构还比较简单。一个CPU，挂个内存控制器，再连几个外设，用AMBA 2.0的AHB总线就能搞定。那时候数据速率也就几十兆赫兹，布线压力不大，时序收敛也容易。
但后来情况变了。多核处理器出现了，GPU、NPU、DSP这些高性能IP都往一个芯片里塞。你想想看，一个4K视频流，每秒要处理几十G比特的数据。如果还用老式的共享总线，所有IP都挤在同一条线上抢带宽——那画面太美我不敢看。
1.1 芯片内部总线架构的演进
先说说总线架构是怎么一步步走到今天的。
| 阶段 | 总线类型 | 典型速率 | 痛点 |
|---|---|---|---|
| 早期 | AHB/APB | 几十MHz | 共享总线，带宽瓶颈 |
| 中期 | AXI3 | 几百MHz | 多主多从，乱序处理复杂 |
| 现在 | AXI4/ACE/CHI | 1-2GHz+ | 一致性、延迟、功耗平衡 |
AXI总线最大的优势是什么？独立的地址/数据通道。读地址、读数据、写地址、写数据、写响应——五条通道各走各的。这意味着什么？意味着你可以同时发读请求和写请求，数据还能乱序返回。这在视频处理、网络加速这类场景下，性能提升非常明显。
核心要点：AXI互连不是简单的线连在一起，而是一个智能的交换网络。它负责仲裁、路由、数据缓冲、协议转换。我见过不少团队，以为把几个AXI slave挂到同一个interconnect上就完事了，结果跑起来发现带宽上不去——后来一查，是interconnect的配置没调好，仲裁策略不对。
1.2 为什么需要AXI互连？
我举个例子。假设你有一个SoC，里面有4个CPU核，一个GPU，一个视频编解码器，一个DDR控制器。如果没有AXI互连，你怎么让这些模块通信？
- CPU要读DDR里的数据
- GPU要写渲染结果到DDR
- 视频模块要从DDR取帧数据
- CPU还要配置GPU的寄存器
这些操作同时发生，而且优先级不同。AXI互连的作用就是：把多个master的请求，有序地分发到对应的slave，同时保证带宽和延迟满足要求。
我记得有一次做车载芯片的项目，客户要求视频延迟不能超过一帧。我们用的AXI interconnect支持QoS优先级设置，把视频流的数据通道设成高优先级，CPU的配置操作设成低优先级。这样即使CPU在疯狂刷数据，视频流也不会被卡住。嗯，这个坑踩过之后，我后来做任何互连设计，第一件事就是先理清楚各master的带宽和延迟需求。
1.3 高速串行接口的趋势
说完片内，再说片间。
芯片内部的数据速率越来越高，但芯片之间的通信呢？传统的并行接口，比如DDR、PCIe并行版本，速率做到一定程度就上不去了。为什么？信号偏移。你想想看，32根数据线同时从芯片A飞到芯片B，每根线的长度、阻抗、延迟都不一样。速率一高，数据到达的时间差就大到无法容忍。
SerDes（Serializer/Deserializer）就是来解决这个问题的。它把并行数据转成串行，用一对差分线传输，速率可以做到几十Gbps甚至更高。
个人经验：SerDes设计里最头疼的是时钟恢复。接收端没有独立的时钟线，必须从数据流里提取时钟。我曾经在一个25Gbps的项目里，因为CDR（时钟数据恢复）环路的带宽没调好，导致锁相环一直抖动，数据误码率居高不下。后来花了整整两周才找到问题——是参考时钟的噪声耦合进来了。
现在主流的SerDes标准包括：
- PCIe Gen4/5/6：每通道16/32/64Gbps，广泛用于服务器、AI加速卡
- Ethernet 25G/50G/100G/400G：数据中心互联
- JESD204B/C：ADC/DAC与FPGA之间的高速接口
- MIPI D-PHY/C-PHY：手机摄像头、显示屏
1.4 AXI互连 + SerDes = 什么？
好，现在把这两者结合起来。你有一个大芯片，内部用AXI互连把各个IP连起来。但芯片的规模不能无限大，有时候需要把系统拆成多个die，或者用多颗芯片拼成一个系统。这时候，芯片之间的通信就需要SerDes。
典型的场景是：
- Chiplet架构：多个小芯片通过Die-to-Die接口（如UCIe、BoW）互连，内部用AXI协议
- FPGA+SoC：FPGA通过高速SerDes连接到SoC的AXI端口
- 分布式存储：多个存储控制器通过SerDes组成网络，对外呈现统一的AXI接口
说白了，AXI互连管片内，SerDes管片间。两者配合，才能构建出真正高性能、可扩展的系统。
注意：AXI协议在片内跑的时候，延迟是纳秒级的。但一旦经过SerDes，延迟会变成微秒级。这个量级的差异，会导致你的互连协议需要做调整。比如，AXI的写响应通道，如果等待时间太长，可能会把interconnect的buffer撑爆。我见过有人直接把片内的AXI interconnect接到SerDes上，结果跑起来就死锁——因为协议的超时机制没处理好。
1.5 本章知识体系
下面这张图，是我自己总结的AXI互连与SerDes的知识框架。你可以把它当作整个课程的地图。
这张图把整个课程的核心脉络串起来了。从系统架构出发，分两大技术方向——AXI互连和SerDes接口，再往下深入到协议、拓扑、物理层、时钟恢复等关键技术，最后落到实战应用和验证调试。我们后面的每一章，都会围绕这张图展开。
1.6 避坑指南
最后，分享几个我这些年踩过的坑：
- 不要低估互连的延迟：AXI interconnect不是简单的导线，它内部有寄存器、buffer、仲裁逻辑。每经过一级，延迟就会增加几个时钟周期。如果你做的是对延迟敏感的设计（比如cache一致性），一定要仔细算好pipeline深度。
- SerDes的功耗比你想象的大：一个25Gbps的SerDes通道，功耗轻松超过100mW。如果你有几十个通道，那功耗就是几瓦。散热和供电设计一定要提前考虑。
- 协议转换不是小事：把AXI协议封装到SerDes上传输，需要做协议适配。我曾经见过一个团队，直接把AXI的valid/ready信号拉到SerDes上，结果因为跨时钟域处理不当，导致数据丢失。嗯，这个坑我帮他们填了整整一周。
好了，这一章就到这里。后面的内容会更深入，我们会一步步拆解AXI互连的细节，也会手把手带你做SerDes的验证。准备好了吗？
一句话总结：AXI互连解决片内多IP高效通信的问题，SerDes解决片间高速数据传输的问题。两者结合，是现代高性能芯片设计的基石。
可可精品资料库