文章目录
- 一、什么是Aurora协议？
- 二、Aurora 8B/10B IP核的结构原理
- 三、Aurora 8B/10B IP核 延迟开销
- 四、用户数据接口格式
- 4.1 AXI4-Stream 位排序
- 4.2 帧传输用户端口说明
- 4.3 帧传输数据流程
- 4.4 Aurora 8B/10B 帧格式
- 4.5 帧格式数据传输时序
- 4.5.1 简单数据传输
- 4.5.2 奇数个字节数据传输
- 4.5.3 暂停数据传输
- 4.5.4 带时钟补偿的数据传输
- 4.6 流传输用户接口说明
- 4.6.1 简单数据传输
- 4.6.2 接受数据传输
- 五、状态指示端口
- 5.1 时钟端口
- 5.2 复位操作
- 六、配置Aurora 8B/10B IP核
- 七、仿真验证
- 八、下板验证
一、什么是Aurora协议？
Aurora协议是一种用于FPGA和其他硬件设备之间高速串行数据传输的协议，为物理层提供透明接口；用于在点对点串行链路间移动数据的可扩展轻量级链路层协议，由Xilinx公司开发。它主要用于在FPGA之间、FPGA与处理器之间、或FPGA与其他外部设备之间进行高效的数据通信。Aurora协议是轻量级的，具有高带宽和低延迟的特点，适合用于各种应用场景，如数据中心、通信、视频处理、存储和高性能计算等，Aurora协议通信示意图如下所示：
在两个Aurora核通信中，是通过Lane链接，建立链接后的两个核也叫Aurora Channel Partners；每一条Lane包括一个TX，一个RX，在物理层就是通过GT收发器来传输，具体的GT收发器的配置可以参考《详解Xilinx GTP结构原理以及gtwizard IP的使用并下板验证》这篇文章。多条Lane可以组成一个Channel，类似于Xilinx GT收发器里面四对GT收发器组成一个Quad。
由上图也可以看出用户通过用户接口与Aurora核进行数据交互，Aurora核将用户数据添加链路层协议后再进行8B/10B编码，最后经过GT收发器发送出去。在Xilinx GTP收发器里，单个收发器支持速率为0.5Gbps 至 6.6Gbps；Aurora支持最多16个收发器同时传输，因为8B10B编码有20%的开销，因此Aurora 8B/10B核支持的吞吐量为0.5 * 0.8 = 0.4Gbps 至 6.6* 16 *0.8 = 84.48Gps。
二、Aurora 8B/10B IP核的结构原理
Aurora 8B/10B IP 核心框图如下所示：
- Lane Logic ：每一个驱动一个GT（GTP，GTX，GTH）收发器，并且初始化对应的GT收发器和处理控制字符的编码和解码以及错误检测。
- Global Logic：执行通道初始化的绑定和验证阶段。在运行过程中，该模块生成 Aurora 协议所需的随机空闲字符，并监控所有通道逻辑模块是否存在错误。
- RX User Interface：AXI4-Stream RX 用户接口将数据从通道移动到应用程序并执行流控制功能。
- TX User Interface：AXI4-Stream TX 用户界面将数据从应用程序移动到通道并执行流控制 TX 功能。标准时钟补偿模块嵌入在内核中。该模块控制时钟补偿 (CC) 字符的定期传输
总结：Aurora 8B/10B是一个基于GT高速收发器（物理层）的全双工点到点协议，GT高速收发器的每个Channel就是Aurora协议的一条Lane，用户通过AXI4-Stream来向Aurora 8B/10B IP核读写数据。
三、Aurora 8B/10B IP核 延迟开销
Aurora 8B/10B IP的延迟是由协议引擎（编解码、流水线处理、）和GT收发器的管道延迟引起的。随着用户接口数据宽度的增加，协议引擎的延迟也会增加；GT收发器的延迟取决于所选收发器的功能和属性。下图是默认配置下的数据路径的延迟路径：
对于默认核心配置在功能仿真中，从 s_axi_tx_tvalid 到 m_axi_rx_tvalid 的2字节帧设计的最小延迟约为 37 个user_clk 周期，4字节帧设计的最小延迟约41各user_clk周期：
Aurora 8B/10B端口示意图如下所示：
在IP配置界面可以选择大小端模式，选择小端模式（ Little Endian Support ）后，数据总线上的数据高位在前面，低位在后面，数据格式为[n:0]。选择大端模式（ Big Endian Support）后，数据总线上的数据低位在前，高位在后，数据格式为[0:n]；在配置IP时，我们大多数选择小端模式，也是符合我们平时的设计习惯。
四、用户数据接口格式
Aurora 8B/10B IP配置可选择帧或流式用户数据接口。
- 帧式用户接口符合AXI4-Stream 协议规范，并包含传输和接收帧式用户数据所需的信号，简单理解就是在AXI4-Stream的基础上添加了帧头、帧尾等控制信号，使得传输更准确，但是会降低传输效率和使用较多资源。
- 流式接口允许发送没有帧分隔符的数据，操作更简单，并且比帧式接口占用更少的资源。数据端口宽度取决于通道宽度和所选通道数；基本上就是一个非常简化的AXI4-Stream接口，只有数据有效、握手和数据信号，此种方式传输效率高，但无法保证传输的准确性
Aurora 8B/10B IP顶层结构实例化了通道逻辑模块、TX 和 RX AXI4-Stream 模块、全局逻辑模块以及收发器的包装器，Example还实例化了时钟、复位电路、帧生成器和检查器模块，如下所示：
4.1 AXI4-Stream 位排序
Aurora 8B/10B IP采用升序排序。它们首先传输和接收最高有效字节的最高有效位，如下图所示：
4.2 帧传输用户端口说明
帧传输用户端口框图如下所示：
| 端口名称 | 方向 | 时钟域 | 端口说明 |
| s_axi_tx_tdata[0:(8n–1)] 或s_axi_tx_tdata[(8n–1):0] | 输入 | user_clk | 输出数据；n表示字节数，由lane数量组成 |
| s_axi_tx_tready | 输出 | user_clk | 拉高表示IP准备好接收数据 |
| s_axi_tx_tlast | 输入 | user_clk | 拉高表示当前传输的是最后一个数据 |
| s_axi_tx_tkeep[0:(n–1)] 或s_axi_tx_tkeep[(n–1):0] | 输入 | user_clk | 指定最后一个数据节拍中的有效字节数 |
| s_axi_tx_tvalid | 输入 | user_clk | 拉高表示当前输出的数据有效 |
| m_axi_rx_tdata[0:8(n–1)] 或 m_axi_rx_tdata[8(n–1):0] | 输出 | user_clk | 接收到来自GT收发器的数据 |
| m_axi_rx_tlast | 输出 | user_clk | 拉高表示当前输出的是最后一个数据 |
| m_axi_rx_tkeep[0:(n–1)] 或 m_axi_rx_tkeep[(n–1):0] | 输出 | user_clk | 指定最后一个数据节拍中的有效字节数 |
| m_axi_tx_tvalid | 输出 | user_clk | 拉高表示当前输出的数据有效 |
4.3 帧传输数据流程
IP核传输用户发送数据的流程如下：
- 当s_axi_tx_tvalid和s_axi_tx_tready信号同时断言时，IP核从s_axi_tx_tdata总线上的用户接口获取数据
- IP核将数据分到Channel里的lane上
- 用户可以取消s_axi_tx_tvalid来暂停数据传输以插入空闲字符
- 暂停数据（即插入空闲）（s_axi_tx_tvalid 无效）
IP核接收GT发送过来的数据流程如下：
- 检测并丢弃控制字节（空闲、时钟补偿、通道开始 PDU (SCP)、通道结束协议数据单元 (ECPDU) 和 PAD
- 断言帧信号 (m_axi_rx_tlast) 并指定最后一个数据节拍中的有效字节数 (m_axi_rx_tkeep)
- 从Lane上恢复数据
- 通过断言 m_axi_rx_tvalid 信号来组装数据以发送给 m_axi_rx_tdata 总线上的用户接口
4.4 Aurora 8B/10B 帧格式
TX 子模块将通过 TX 接口接收到的每个用户帧转换为 Aurora 8B/10B 帧。通过在帧开头添加 2 字节 SCP 代码组来表示帧开始 (SOF)。通过在帧末尾添加 2 字节通道结束协议 (ECP) 代码组来表示帧结束 (EOF)。只要没有数据，就会插入空闲代码组。代码组是 8B/10B 编码字节对，所有数据都作为代码组发送，因此具有奇数个字节的用户帧在帧末尾附加了一个称为 PAD 的控制字符，以填充最终的代码组，下图是偶数字节的帧格式
4.5 帧格式数据传输时序
4.5.1 简单数据传输
传输时序如下所示：
在valid信号与ready信号握手成功期间传输数据，传输到最后一个数据DATA2时，拉高tlast信号，表明此时传输的是最后一个数据。tkeep信号表示最后一个数据的那些字节是有效的。
4.5.2 奇数个字节数据传输
Aurora 8B/10B IP根据协议要求为具有奇数字节的帧附加 pad 字符。传输 3n–1 个数据字节需要两个完整的 n 字节数据字和一个部分数据字。在此示例中，s_axi_tx_tkeep 设置为 N–1，以指示最后一个数据字中有 n–1 个有效字节。
4.5.3 暂停数据传输
用户接口通过取消断言 s_axi_tx_tvalid 来暂停前 n 个字节后的数据流，并改为传输空闲数据。暂停持续到取消断言 s_axi_tx_tvalid。
4.5.4 带时钟补偿的数据传输
Aurora 8B/10B 核心在发送时钟补偿序列时会自动中断数据传输。时钟补偿序列每 10,000 字节对每个通道施加 12 字节的开销；由于每通道 10,000 字节需要进行一次时钟补偿（每通道 2 字节设计需要 5,000 个时钟；每通道 4 字节设计需要 2,500 个时钟），因此无法连续传输数据，也无法连续接收数据。在时钟补偿期间，数据传输会暂停六个或三个时钟周期
帧格式传输接口总结：帧格式接口类似被再封装的AXI4-Streaming接口，IP核自动加入帧头、帧尾，并在固定时间内完成时钟补偿；发送端用户只需要在发送、接收双方完成握手后，即可发送数据，通信双方均可通过握手信号来反压对方；接收端用户仅需要在valid信号有效时从总线上拿数据即可；由于是帧结构，所以需要有信号来约束帧长度（tlast）；由于数据的发送是成对发送，所以最后一个数据可能存在无效字节的情况，故需要对最后一个数据的有效字节数进行约束（tkeep）
4.6 流传输用户接口说明
如下所示，显示了流传输端口示意图：
4.6.1 简单数据传输
上图显示Aurora 8B/10B IP通过断言 s_axi_tx_tready 来指示它已准备好传输数据。用户逻辑通过断言 s_axi_tx_tdata 总线和 s_axi_tx_tvalid 信号来指示它已准备好传输数据。由于现在两个握手信号都已断言，因此数据 D0 从用户逻辑传输到 Aurora 8B/10B IP。数据 D1 在下一个时钟周期传输。在此示例中，Aurora 8B/10B 核心取消断言其就绪信号 s_axi_tx_tready，并且直到下一个时钟周期再次断言 s_axi_tx_tready 信号时才传输任何数据。然后，用户逻辑在下一个时钟周期取消断言 s_axi_tx_tvalid，并且直到两个就绪信号都断言后才会传输任何数据。
4.6.2 接受数据传输
接收数据没有ready信号，当m_axi_rx_tvalid有效时，表示当前数据总线上的数据有效。
五、状态指示端口
| 端口名称 | 方向 | 时钟域 | 端口说明 |
| channel_up | 输出 | user_clk | 通道初始化完成且通道已准备好进行数据传输时，该信号被置位 |
| lane_up[0:m–1] | 输出 | user_clk | 成功初始化通道后，每个通道均置位，每个位代表一个通道 |
| frame_err | 输出 | user_clk | 检测到通道帧/协议错误 |
| hard_err | 输出 | user_clk | 检测到硬件错误 |
| soft_err | 输出 | user_clk | 在传入串行流中检测到软件错误 |
| reset | 输入 | 异步 | 重置 Aurora 8B/10B IP（高电平有效）。此信号必须保持至少六个 user_clk 周期 |
| gt_reset | 输入 | 异步 | 这会系统地重置收发器的所有物理编码子层 (PCS) 和物理介质附件 (PMA) 子组件。 使用 init_clk_in 去抖动信号，并且必须断言六个 init_clk_in 周期 |
| link_reset_out | 输出 | init_clk | 如果热插拔计数到期，则驱动为高电平 |
| init_clk_in | 输入 | 需要 init_clk_in 端口，因为当 gt_reset 被置位时 user_clk 会停止。建议为 init_clk_in 选择的频率低于 GT 参考时钟输入频率 |
5.1 时钟端口
| 端口名称 | 方向 | 端口说明 |
| pll_not_locked | 输入 | 如果使用 PLL 为 Aurora 8B/10B 核心生成时钟，则应将 pll_not_locked 信号连接到 PLL 锁定信号的反相。如果不使用 PLL 为 Aurora 8B/10B 核心生成时钟信号，则将 pll_not_locked 接地 |
| user_clk | 输入 | Aurora 8B/10B 核心和用户应用程序共享的并行时钟。user_clk 和 sync_clk 是 tx_out_clk 驱动的 PLL 或 BUFG 的输出 |
| sync_clk | 输入 | 收发器内部同步逻辑使用的并行时钟。sync_clk 作为收发器的 txusrclk 输入 |
| gt_refclk | 输入 | gt_refclk（clkp/clkn）端口是通过 IBUFDS_GTE 供电的专用外部收发器参考时钟 |
| gt0_pll0outclk_in/gt1_pll0outclk_in | 输入 | 此端口应连接到 GTPE2_COMMON 生成的 PLL0OUTCLK/PLL1OUTCLK 时钟输出。此端口内部连接到 GTPE2_CHANNEL 原语上的 PLL0CLK/PLL1CLK 端口 |
| gt0_pll0outrefclk_in/gt0_pll1outrefclk_in | 输入 | 此端口应连接到 GTPE2_COMMON 生成的 PLL0OUTREFCLK/PLL1OUTREFCLK 时钟输出。此端口内部连接到 GTPE2_CHANNEL 原语上的 PLL0REFCLK/PLL1REFCLK 端口 |
| quad1_common_lock_in | 输入 | GTPE2_COMMON PLL锁定输入端口 |
- GT Refclk：在《详解Xilinx GTP结构原理以及gtwizard IP的使用并下板验证》这篇文章中，我们知道GT收发器需要外部差分晶振提供参考时钟。
- INIT CLK:初始化时钟，之所以要INIT CLK，是因为在GT复位时，user_clk是停止工作的；可以由PLL提供
- DRP CLK:动态重配置时钟，和INIT CLK一样即可。
整个时钟架构框图如下所示：
5.2 复位操作
复位有gt_reset和reset两种：
- reset：用于复位 Aurora 8B/10B IP 核的协议层逻辑（控制逻辑、数据路径等）。它的作用是确保协议层逻辑处于正确的初始状态，不会影响底层的 GT 模块
- gt_reset：用于复位底层的高速收发器（GT），包括 PLL、CDR、SerDes 等。它的作用是确保 GT 模块的正确初始化和数据同步，影响整个链路的物理层操作
上图显示为reset复位的时序，复位断言应至少为 6 个 user_clk 时间周期。因此，channel_up 在 3 个 user_clk 周期后被解除断言。
上图显示为gt_reset复位的时序，并且应至少为六个 init_clk_in 时间段。因此，user_clk 在几个时钟周期后停止，因为没有来自收发器的 txoutclk，并且 channel_up 随后被取消断言
在实际工程中，可以先进行gt_reset复位，等user_clk稳定后在进行reset复位：
六、配置Aurora 8B/10B IP核
上面我们了解到了Aurora 8B/10B IP核的内部结构以及各种信息，接下来我们调用一个，让它跑起来。调用步骤如下：
配置完成后我们打开实例工程：
七、仿真验证
我们先直接打开实例工程里的仿真，看一下整个IP是怎样控制的，然后我们再修改成自己可用的模块：
上电开始，就拉高gt_reset和reset，然后等待tx_reserdone_out和rx_resetdone_out拉高就能开始数据传输了，可以看到复位期间，user_clk和sync_clk都没有生成。
大概仿真到0.5ms，整个Aurora IP核已经复位完成，此时sys_reset_out拉低，可以传输数据了，我们放大来看数据传输模块：
用户在发送端发送完数据后，大约33个user_clk周期后，IP输出了接收数据，数据也都是正确的。
八、下板验证
我们修改数据发送模块：
整个IP的数据收发都是用AXI_stream传输，我们每次发送100个从0-99连续的数据，然后例化两个IP出来，在外部用光纤链接在一起，然后一个收一个发，约束好管脚后，我们直接下板：
可以看到数据收发正常，都是从0-99的连续数据。
