Xilinx Aurora 8B/10B IP介绍以及下板验证

id="article_content" class="article_content clearfix" style="height: 2000px; overflow: hidden;"> id="content_views" class="markdown_views prism-atom-one-dark">

class="toc">

文章目录

一、什么是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 帧传输用户端口说明

  帧传输用户端口框图如下所示：
在这里插入图片描述

class="table-box">
端口名称 方向时钟域 端口说明
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拉高表示当前输出的数据有效
class="table-box">

4.3 帧传输数据流程

  IP核传输用户发送数据的流程如下：

  1. 当s_axi_tx_tvalid和s_axi_tx_tready信号同时断言时，IP核从s_axi_tx_tdata总线上的用户接口获取数据
  2. IP核将数据分到Channel里的lane上
  3. 用户可以取消s_axi_tx_tvalid来暂停数据传输以插入空闲字符
  4. 暂停数据（即插入空闲）（s_axi_tx_tvalid 无效）

  IP核接收GT发送过来的数据流程如下：

  1. 检测并丢弃控制字节（空闲、时钟补偿、通道开始 PDU (SCP)、通道结束协议数据单元 (ECPDU) 和 PAD
  2. 断言帧信号 (m_axi_rx_tlast) 并指定最后一个数据节拍中的有效字节数 (m_axi_rx_tkeep)
  3. 从Lane上恢复数据
  4. 通过断言 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有效时，表示当前数据总线上的数据有效。

五、状态指示端口

class="table-box">
端口名称 方向时钟域 端口说明
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 参考时钟输入频率
class="table-box">

5.1 时钟端口

class="table-box">
端口名称 方向端口说明
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锁定输入端口
class="table-box">
  1. GT Refclk：在《详解Xilinx GTP结构原理以及gtwizard IP的使用并下板验证》这篇文章中，我们知道GT收发器需要外部差分晶振提供参考时钟。
  2. INIT CLK:初始化时钟，之所以要INIT CLK，是因为在GT复位时，user_clk是停止工作的；可以由PLL提供
  3. DRP CLK:动态重配置时钟，和INIT CLK一样即可。
      整个时钟架构框图如下所示：

在这里插入图片描述

5.2 复位操作

  复位有gt_reset和reset两种：

在这里插入图片描述
  上图显示为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的连续数据。

注：本文转载自blog.csdn.net的爱奔跑的虎子的文章"https://blog.csdn.net/qq_43156031/article/details/143688551"。版权归原作者所有，此博客不拥有其著作权，亦不承担相应法律责任。如有侵权，请联系我们删除。
复制链接
复制链接
相关推荐
发表评论

评论记录：

未查询到任何数据！