一、AXI协议基础回顾：通道握手、地址通道与数据通道解耦、outstanding传输机制
各位同学，咱们今天聊聊AXI协议最核心的几个基础概念。说实话，很多做了两三年的工程师，对这些基础的理解还是模模糊糊的。我自己带项目时，发现大部分性能问题，根源都在这些基础没吃透。
1.1 通道握手——VALID和READY的博弈
AXI协议有五个独立通道：读地址、读数据、写地址、写数据、写响应。每个通道都用一套握手信号——VALID和READY。
说白了，VALID表示发送方说「我有数据给你了」，READY表示接收方说「我准备好收了」。两者同时拉高，一个传输就完成了。
这里有个关键点：VALID不能依赖READY。什么意思？发送方一旦把VALID拉高，就必须保持住，直到收到READY。不能因为对方没准备好就撤回去。我见过有新手写代码时，看到READY没拉高就把VALID拉低了，结果协议直接崩了。
握手规则总结：
- VALID可以等READY，但READY也可以等VALID
- 一旦VALID拉高，必须保持到握手完成
- 双方可以同时拉高，一拍完成传输
嗯，这里要注意：READY可以提前拉高，也可以等VALID来了再拉高。我个人习惯让从设备提前拉高READY，这样主设备发数据时一拍就能传过去，延迟最小。
1.2 地址通道与数据通道解耦
AXI最巧妙的设计之一，就是地址通道和数据通道是分开的。你想想看，发送地址和发送数据可以不在同一拍完成。
举个例子：主设备先发一个写地址，然后过几拍才发对应的写数据。这在其他总线协议里是做不到的。为什么AXI要这么设计？
因为实际系统中，地址的生成和数据的准备往往是不同步的。比如一个DMA控制器，它可能先算好要写到哪里，但数据还在从内存搬过来的路上。如果地址和数据必须同时发送，那整个流水线就得停下来等数据。
我的经验：在项目中我遇到过地址通道比数据通道快很多的情况。这时候如果从设备处理不过来，可以在地址通道上插入等待周期，或者用outstanding机制来缓冲。千万别让地址通道堵死，否则整个系统性能就完蛋了。
解耦带来的好处很明显：
- 地址和数据可以乱序发送
- 支持outstanding传输
- 流水线效率大幅提升
1.3 Outstanding传输机制
Outstanding，说白了就是「不等回应，继续发」。主设备可以连续发出多个传输请求，不用等前面的完成。
我记得刚接触AXI时，总觉得outstanding数量越大越好。后来踩了坑才发现，不是这么回事。outstanding太多，从设备可能撑不住，反而导致死锁。
为什么会这样？因为从设备内部通常有有限深度的buffer。如果outstanding请求超过了buffer深度，新请求就会被堵住。更严重的是，如果读和写共用buffer，还可能发生读写互相阻塞的情况。
| Outstanding数量 | 优点 | 缺点 |
|---|---|---|
| 1（无outstanding） | 控制简单，不会死锁 | 性能差，流水线停顿多 |
| 2~4 | 性能提升明显，风险可控 | 需要一定的buffer深度 |
| 8以上 | 极致性能 | 容易死锁，调试困难 |
避坑指南：我曾经在一个项目中把outstanding设成了16，结果从设备buffer只有8。跑仿真没问题，一上FPGA就死机。查了三天才发现是outstanding溢出导致地址丢失。后来我学乖了，outstanding数量一定要和从设备的buffer深度匹配。
1.4 核心知识结构图
下面这张图把AXI协议基础的核心逻辑串起来了。我建议你多看几遍，理解每个模块之间的关系。
这张图里，五个通道独立工作，每个通道都有自己的握手信号。地址和数据通道解耦后，outstanding传输才能实现。你仔细看看，主设备发完地址后，不用等数据回来，就可以发下一个地址。这就是AXI高性能的根源。
一个小技巧：调试AXI接口时，我习惯先看VALID和READY的波形。如果某个通道的VALID一直拉高但READY没反应，那八成是从设备卡住了。如果READY一直拉高但VALID没来，那就是主设备还没准备好。这两个信号一配合，问题就暴露了。
好了，这一章的基础就讲到这里。记住：握手是基础，解耦是关键，outstanding是性能利器。下一章咱们会深入讲流水线设计，这些基础概念会反复用到。