2、Aurora协议基础：协议栈结构、物理层与链路层、数据帧格式解析
好，咱们正式开始啃Aurora协议的核心。这一章，我会把协议栈的骨架、物理层和链路层到底在干什么、以及数据帧长什么样，掰开了讲清楚。你想想看，搞通信协议，最怕的就是“知其然不知其所以然”。
我个人习惯，拿到一个新协议，先不看细节，先看它的分层结构。这就像盖房子，先看图纸，再看砖怎么砌。Aurora协议栈，说白了就三层：物理层、链路层、用户层。用户层是你自己写的逻辑，协议不管。我们重点啃下面两层。
核心观点：Aurora协议的精髓在于“轻量级、低延迟”。它没有复杂的路由和重传机制，专注于在高速串行链路上做最纯粹的透明数据传输。
2.1 协议栈结构：三层架构，各司其职
先看一张我画的协议栈结构图。这张图我建议你存下来，后面每讲一个知识点，都回来对照一下，思路会非常清晰。
这张图你看懂了吗？用户层在最上面，它只管把数据扔给链路层，或者从链路层拿数据。链路层是承上启下的关键，它负责把用户数据“打扮”成符合协议规范的帧。物理层呢？它就是个“搬运工”，负责把比特流从A点搬到B点。
我的经验：很多新手一上来就扎进物理层的GTX收发器配置里，结果调了几天眼图还是花的。我建议你先在链路层把帧结构搞明白，用仿真验证数据流对不对，再回头调物理层。这样效率高得多。
2.2 物理层：高速串行的基石
物理层，说白了就是Xilinx的GTP、GTX、GTH、GTY这些高速收发器。Aurora协议本身不定义物理层，它寄生在收发器之上。
物理层主要干三件事：
- 8B/10B编码：把8位数据变成10位，保证DC平衡，提供足够的跳变沿用于时钟恢复。嗯，这里要注意，Aurora 64B/66B模式用的是不同的编码方式，但入门阶段我们先啃8B/10B。
- 串并转换：FPGA内部是并行数据，线上是串行比特流。收发器负责这个转换。
- 时钟数据恢复(CDR)：接收端从串行数据流里提取出时钟，没有独立的时钟线。
我曾经在一个项目里，因为忽略了收发器参考时钟的抖动指标，导致链路在高温下频繁断开。查了三天，最后发现是时钟源选型出了问题。所以，物理层的时钟质量，直接决定链路的稳定性。
| 收发器系列 | 最大线速率 | 典型应用场景 |
|---|---|---|
| GTP | 6.6 Gbps | 低成本、中低速率 |
| GTX | 12.5 Gbps | 主流应用，性价比高 |
| GTH | 16.3 Gbps | 高性能、高带宽 |
| GTY | 32.75 Gbps | 超高速、高端芯片 |
避坑指南：我曾经在选型时，想当然地以为GTX和GTH的IP核配置完全一样。结果移植代码时发现，GTH的QPLL配置和GTX完全不同，导致工程编译不过。所以，不同系列的收发器，IP核配置一定要重新来过，别偷懒。
2.3 链路层：协议的核心战场
链路层才是我们FPGA工程师真正要花大力气的地方。它负责把物理层提供的原始比特流，组织成有意义的帧。
链路层主要处理这几类数据：
- 用户数据帧：你真正要传的数据。
- 控制帧：用于链路初始化、通道绑定、流量控制等。
- 空闲序列：没有数据传的时候，发特定的K码来维持链路同步。
你想想看，为什么要有空闲序列？因为物理层需要连续的比特流才能保持CDR锁定。如果数据停了，CDR就丢了。所以链路层会不停地填充“空闲”字符，保证线上永远有数据在跑。
2.4 数据帧格式解析：从比特到字节
好，到了最硬核的部分。Aurora的数据帧，说白了就是一组字节的序列，用特定的“逗号”字符来分隔。
我们先看一个标准的用户数据帧格式：
+--------+--------+--------+--------+--------+--------+--------+--------+
| SCP | Data | Data | ... | Data | ECP | CRC | CRC |
| (K28.5)| (Dxx.y) | (Dxx.y) | | (Dxx.y) | (K29.7)| (Dxx.y)| (Dxx.y)|
+--------+--------+--------+--------+--------+--------+--------+--------+
^ ^
| |
帧起始 帧结束解释一下：
- SCP (Start of Frame)：帧起始标志，用的是K28.5这个特殊字符。接收端一看到K28.5，就知道新的一帧来了。
- Data：你的用户数据，一个字节一个字节地排好。
- ECP (End of Frame)：帧结束标志，用的是K29.7。
- CRC：校验码，2个字节。接收端会重新计算CRC，和收到的比对，不一样就说明传错了。
为什么会用K码？因为K码是8B/10B编码里的“控制字符”，它和普通数据字符（D码）不一样。接收端可以轻松地把K码从数据流里识别出来，不需要额外的帧头帧尾信号。这就是Aurora协议“轻量级”的体现。
关键点：Aurora协议没有MAC地址，没有IP地址，没有复杂的路由表。它就是一个纯粹的“管道”，你从这头塞进去，它从那头吐出来。延迟极低，通常只有几十个时钟周期。
我再补充一个我实际项目中遇到的坑。有一次，我发现链路偶尔会丢帧，但CRC校验又是对的。查了很久，最后发现是用户逻辑在发送数据时，帧结束标志ECP的位置不对。我习惯在最后一个有效数据字节的同时拉高ECP，但协议要求ECP必须紧跟在最后一个数据字节之后。差一个时钟周期，接收端就会把ECP当成数据，导致帧结构错乱。
所以，帧格式的时序，必须严格对齐。一个时钟都不能差。
2.5 时钟补偿：一个容易被忽略的细节
最后聊一个细节：时钟补偿。为什么需要这个？因为发送端和接收端的时钟不可能完全一样，总有几十到几百ppm的偏差。时间长了，接收端的FIFO要么空要么满。
Aurora协议的处理方式很巧妙：它会在空闲序列里，定期插入或删除一个“时钟补偿序列”。这个序列由特定的K码组成，接收端看到后，知道这是补偿用的，不会把它当成数据。
我个人习惯，在调试链路时，先看时钟补偿序列有没有正常出现。如果这个序列乱了，说明链路层的状态机可能跑飞了，或者收发器的时钟有问题。
调试小技巧：用ChipScope或Vivado的逻辑分析仪，抓一下链路层的RX接口。重点看两个信号：frame_n（帧有效标志）和sof_n（帧起始标志）。如果这两个信号有毛刺或者时序不对，那帧格式肯定有问题。
好了，这一章的内容就到这里。Aurora协议栈的三层结构、物理层的收发器基础、链路层的帧格式，以及时钟补偿的细节，我都给你过了一遍。这些东西，是你后面写代码、调板子的基本功。