作者：FPGA技术联盟
1、Aurora 8B/10B 协议
Aurora 协议是一个用于在点对点串行链路间移动数据的可扩展轻量级链路层协议（由Xilinx开发提供）。这为物理层提供透明接口，让专有协议或业界标准协议上层能方便地使用高速收发器。Aurora协议在Xilinx的FPGA上有两种实现方式：8B/10B 与 64B/10B。两个协议大部分相同，主要区别在编码方式上：
Aurora 8B/10B：将8bit数据编码成10bit数码进行传输，尽量平衡数据中“0”和“1”的个数以实现DC平衡，显然这个编码方式的开销是20%，也就是效率为80%
Aurora 64B/10B：将64bit数据编码成66bit块传输，66bit块的前两位表示同步头，主要由于接收端的数据对齐和接收数据位流的同步。同步头有“01”和“10”两种，“01“表示后面的64bit都是数据，“10”表示后面的64bit是数据信息。数据信息0和1不一定是平衡的，因此需要进行加
接收端（相对于用户来说）：
如果你熟悉AXI4-Stream协议的话，基本就能马上上手数据的接收发送部分了。
发送数据
从发送端的几个信号就可以判断，当s_axi_tx_tready与s_axi_tx_tvalid握手成功后，即可发送数据
使用s_axi_tx_tlast来表示当前发送最后一个数据
s_axi_tx_tkeep来表示最后一个数据的有效字节（应用场景在发送奇数个字节时，IP核会自动添加一个pad到数据中，所以存在一个无效字节需要指出），这一点倒是与AXI4-Stream协议不太一样
接收数据
接收数据不需要握手过程
当m_axi_rx_tvalid为高时，即说明此时的数据是有效数据，可以拿来用了
m_axi_rx_tkeep与m_axi_rx_tlast的用法与发送端对应的信号一致
帧结构
TX子模块将每个接收的用户帧通过TX接口转换为Aurora 8B / 10B帧。 帧开始（SOF）通过在帧开始处添加2字节的SCP代码组来指示。 帧结束（EOF）是通过在帧的末尾添加一个2字节的信道结束通道协议（ECP）码组来确定。 数据不可用时插入空闲代码组。 代码组是8B / 10B编码字节对，所有数据都作为代码对发送，因此具有奇数个字节的用户帧具有称为PAD的控制字符，附加到帧的末尾以填写最终的代码组。 下图显示了具有偶数数据字节的典型Aurora 8B / 10B帧。
4种发送案例
手册（PG046）里举了4种传输案例方便我们理解发送过程：
Example A: Simple Data Transfer（简单数据传输）
在valid信号与ready信号握手成功期间传输数据，传输到最后一个数据DATA2时，拉高tlast信号，表明此时传输的是最后一个数据。tkeep信号表示数据的那些字节是有效的。
Example B: Data Transfer with Pad（奇数字节数据传输）
在valid信号与ready信号握手成功期间传输数据，传输到最后一个数据DATA2时，拉高tlast信号，表明此时传输的是最后一个数据。tkeep信号表示数据的那些字节是有效的。由于此时传输的是奇数个字节，所以最数据中存在无效字节，故tkeep信号的值为N-1。
Example C: Data Transfer with Pause（带有暂停的数据传输）
在valid信号与ready信号握手成功期间传输数据，传输到最后一个数据DATA2时，拉高tlast信号，表明此时传输的是最后一个数据。tkeep信号表示数据的哪些字节是有效的。在握手期间，用户通过拉低valid信号中断了握手，实现了数据发送的暂停（流控）。
Example D: Data Transfer with Clock Compensation（带时钟补偿的数据传输）
当Aurora 8B / 10B IP核发送时钟补偿序列时，会自动中断数据传输。 时钟补偿序列每10,000字节加上每个通道的12字节开销。其他与上述情况一致。
接收数据案例
不同于发送数据的握手过程，接收数据过程简单的很，只需要数据有效信号m_axi_rx_tvalid为高时，则表示此时接收的数据有效，也用m_axi_rx_tkeep、m_axi_rx_tlast来修饰接收的数据。典型过程如下：
当m_axi_rx_tvalid为高时，接收到的数据有效，其他时候则无效。
Framing接口总结：
Framing接口类似被再封装的AXI4-Streaming接口，IP核自动加入帧头、帧尾，并在固定时间内完成时钟补偿
发送端用户只需要在发送、接收双方完成握手后，即可发送数据，通信双方均可通过握手信号来反压对方；接收端用户仅需要在valid信号有效时从总线上拿数据即可
由于是帧结构，所以需要有信号来约束帧长度--tlast；由于数据的发送是成对发送，所以最后数据可能存在无效字节的情况，故需要对数据的有效字节数进行约束--tkeep
2.5.3、Streaming接口
Streaming接口示意图如下：
看起来比 Framing接口清爽了很多，因为发送端和接收端都少了keep和last这两个信号（共4个）。之前说过，Framing接口的帧框架使得需要使用keep和last这两个信号来控制帧的长度，所以信号较多。而Streaming接口则没有帧框架，相当于一条不停流动的管道，不需要使用keep和last这两个信号来控制长度。
用起来也很简单，发送数据只要在tvalid信号和tready信号握手成功时就可以发送；接收数据就更简单了，只要tvalid为高则说明此时接收的数据是有效的。直接看图来加深理解：
Example A: TX Streaming Data Transfer（数据发送）
简单直白，只有当s_axi_tx_tready、s_axi_tx_tvalid均为高（成功握手）时，才可以发送数据。
Example B: RX Streaming Data Transfer（接收数据）
简单直白，只有当m_axi_rx_tvalid为高时才说明接收到的数据为有效数据。
Streaming接口总结：
Streaming接口就是经典的AXI4-Streaming接口，没有帧的概念，数据总线上数据长度是不受限制的
发送端用户只需要在发送、接收双方完成握手后，即可发送数据，通信双方均可通过握手信号来反压对方；接收端用户仅需要在valid信号有效时从总线上拿数据即可
文章来源：FPGA技术联盟
