【PG074】1 简略学习Aurora 64B/66B IP核

1 概览

Aurora 64B66B是一个轻量化的，多吉比特（multi-gigabit ）链路串行通信协议。用于一个或多个GTX，GTH或GTY收发器之间的数据传输。连接可以是全双工（full-duplex）的或单工（simplex）的。

Aurora 64B66B IP核支持高级微控制器总线结构（Advanced Microcontroller Bus Architecture，AMBA）协议的AXI4-Stream用户接口。一个Aurora 64B/66B核实例可以在GTX、GTH或GTY收发器上使用多达16个有效的连续通路（lane），以任何支持的线速率运行，提供低成本、通用的数据通道，吞吐量从500 Mb/s到超过400 Gb/s。

使用一系列自动化仿真测试来验证Aurora 64B/66B核是否符合协议。

Aurora 64B/66B核心自动初始化一个channel，当他们连接到Aurora 64B/66B channel partner。初始化后，应用程序可以通过channel以数据帧(frame)或数据流(stream)的形式传递数据。Aurora 64B/66B帧可以是任意大小的，并且可以在任何时候被高优先级请求中断。有效数据字节之间的间隙自动填充 idle，以保持锁定和防止过度的电磁干扰。在Aurora 64B/66B中，流控制(Flow control )是可选的，可以用于限制链路伙伴传输数据速率，或通过channel发送简短的、高优先级的消息。

流(stream)在Aurora 64B/66B中通过一个单个无休止的帧来实现。每当数据没有被传输时，就会传输idle以保持链路有效。过多的误bit、断开连接或设备故障将导致IP核复位并尝试初始化一个新的channel。Aurora 64B/66B可以在接收多通路(lane)的通道(channel)时最多支持两个符号偏斜。Aurora 64B/66B协议采用64B/66B编码。64B/66B编码相对8B/10B编码提供了理论上的性能提升，因为它的传输开销非常低(3%)，而8B/10B编码的传输开销为25%。

1.1 应用

由于其低资源成本、可扩展的吞吐量和灵活的数据接口，Aurora 64B/66B核可用于各种应用程序。Aurora 64B/66B核心应用的例子包括:

• 芯片间的连接（Chip-to-chip links）：用高速串行连接代替芯片之间的并行连接可以显著减少PCB上所需的线和层数。
• 电路板间（Board-to-board and backplane）的连接：Aurora 64B/66B使用标准的64B/66B编码，这是10Gb以太网的首选编码方案，使其与许多现有的电缆和背板硬件标准兼容。Aurora 64B/66B可以在线路速率和信道宽度方面进行扩展，以允许廉价的传统硬件用于新的高性能系统。
• 单工连接：Aurora 64B/66B单工协议提供单向通道初始化，使得当回发通道不可用时可以使用GTX、GTH和GTY收发器，并减少由于未使用全双工资源而导致的成本。

1.2 不支持的功能

• 在Aurora 64B/66B核不支持AXI4-Stream非严格对齐模式。
• 在Aurora 64B/66B核不支持7系列设备的GTP和GTZ类型收发器。
• Aurora 64B/66B仅支持GTYE3/GTYE4 16.375G设备的UFC功能。
• 在GTHE4/GTYE4和使用DRP的CPLL配置的情况下，动态切换线速率可能不会像预期的那样工作，因为gtwizard_ultrascale IP中的GTHE4/GTYE4 CPLL校准模块进行了更新。

2 产品规格

Aurora 64B/66B IP核结构：

主要功能模块：

• Lane logic：每个GT收发器由一个lane逻辑模块实例驱动，该实例初始化每个单独的收发器，处理控制字符的编码和解码，并执行错误检测。
• Global logic: 核心中的全局逻辑模块执行通道绑定以进行通道初始化。在运行过程中，该通道跟踪Aurora 64B/66B协议定义的Not Ready空闲字符，并监控所有通道逻辑模块的错误。
• RX user interface: AXI4-Stream接收(RX)用户界面将数据从通道移动到应用程序，并执行流控制功能。
• TX user interface: AXI4-Stream发送(TX)用户界面将数据从应用程序移动到通道，并执行TX的流量控制功能。标准时钟补偿模块嵌入在内核中。这个模块控制时钟补偿(CC)字符的周期性传输。

2.1 性能

2.1.1 最大频率

核心操作的最大频率取决于支持的线路速率和器件的速度等级。

2.1.2 延时

对于默认的单lane配置，通过Aurora 64B/66B核心的延迟是由通过协议引擎(PE)和通过GTX和GTH收发器的流水线延迟（ pipeline delay）造成的。PE流水线延迟随着AXI4-Stream接口宽度的增加而增加。收发器延迟是由收发器特性决定的。

数据路径延迟：

7系列GTX, GTH和的默认核心配置的流水线组件的最大延迟和单个延迟值UltraScale, UltraScale+ GTH收发器设备。延迟可能随添加的流控制而变化。

流水线延迟是为了保持时钟速度而设计的。

2.1.3 吞吐量

Aurora 64B/66B核心吞吐量取决于收发器数量、收发器类型和所选收发器的目标线速率。对于GTH收发器，单lane设计和16 lane设计的吞吐量分别为0.48 Gb/s到254.06 Gb/s。对于GTY收发器，吞吐量在0.455 Gb/s ~ 400 Gb/s之间
支持的线速率范围为0.5 Gb/s ~ 25.7813 Gb/s。当线路速率大于16.375 Gb/s时，GTY的最大吞吐量可能不准确，考虑到设计中的lane striping差异。

2.3 端口描述

用于生成每个Aurora 64B/66B核心的参数决定了该特定核心可用的接口。USER_DATA_S_AXIS_TX是一个接口，s_axi_tx_*端口分组到该接口中。在符号中，接口以分组的形式显示，点击+可以显示其中的端口。

2.3.1 用户接口

1. 顶层接口

Aurora 64B/66B顶层(块级)文件包含顶层接口定义，是用户设计的起点。顶级文件实例化了Aurora 64B/66B lane模块、TX和RX AXI4-Stream模块、全局逻辑模块和GTX，GTH或GTY收发器封装器。这个顶级封装文件与时钟、复位电路、帧生成器和检查模块一起在示例设计文件中实例化。

Aurora 64B/66B AXI4-Stream数据接口bit顺序的 n字节示例。高位在前。

2. 帧接口

遵循AXI4-Stream Protocol Specification。主演端口：

发送数据：

当s_axi_tx_tready和s_axi_tx_tvalid都断言（指示有效）时才会对数据进行采集。用户可以在任意时钟周期取消断言s_axi_tx_tvalid，如果在一帧之间取消断言了，channel会发送idle符号。

**AXI4-Stream数据只有在被帧化时才有效。**帧外的数据被忽略。要结束帧，当数据的最后一个字(或部分字)在s_ax_tx_tdata端口上时，断言s_ax_tx_tlast，并使用s_ax_tx_tkeep指定最后一个数据节拍中的有效字节数。

对于任何类型的转移，这些请求都具有高优先级:

• TXDATAVALID从收发器TX接口取消断言(1周期)。
• CC传输(8个周期)

Aurora 64B/66B 帧

块Block是8个字节的扰乱的数据或控制信息与一个2位的控制头(共66位)。

所有Aurora 64B/66B数据都作为数据块（data block）或分隔块（separator block）的一部分发送。分隔块(SEP)由一个计数字段组成，该字段指示在该特定块中有多少字节是有效的。在帧形成中，每个帧以数据块开始，以包含帧最后一个字节的分隔块结束。当数据不可用时插入空闲块（Idle block）。

一个典型的具有偶数数据字节的Aurora 64B/66B帧。

为了发送数据，用户应用程序配置控制信号，使核心执行以下步骤:

• 在s_axi_tx_tdata总线上接受来自用户应用程序的数据。
• 当s_ax_tx_tlast 、 s_ax_tx_tkeep 一起断言，指示帧结束。
• 当用户应用程序取消断言s_axi_tx_tvalid时，在串行数据上插入空闲或暂停周期。

当接收数据时，执行以下步骤：

• 检测和丢弃控制字节(idle，时钟补偿)。
• 恢复来自lane的数据。
• 在m_axi_rx_tdata总线上组装数据给用户应用程序，包括在m_axi_rx_tkeep上提供有效字节数，并在m_axi_rx_tlast周期中断言m_axi_rx_tvalid。

当线速率高于16.375Gb/s，数据处理方式不同。

3. 发送数据

示例A：简单的数据发送
一个简单的n字节宽的数据传输的例子。发送3n字节的数据需要3个数据拍。断言s_axi_tx_tready表示AXI4-Stream接口已准备好传输数据。

为了开始数据传输，用户应用程序断言s_axi_tx_tvalid并提供用户帧的前n个字节。因为已经断言了s_axi_tx_tready，数据传输从下一个时钟边缘开始。数据字节被放置在数据块中，并通过Aurora 64B/66B通道传输。

为了结束数据传输，用户应用程序 最后的数据字节 和 s_ax_tx_tkeep总线上适当的TKEEP值(0xFF) 到来时，断言s_ax_tx_tlast、s_ax_tx_tvalid。核心以块的形式发送最后的数据字，并且必须在下一个循环中发送一个空的分隔块来表示帧的结束。
在下一个循环中重新声明S_axi_tx_tready，以便继续更多的数据传输。如果没有新的数据，Aurora 64B/66B核心发送空闲数据。

示例B：带暂停的数据发送

在帧传输期间，用户应用程序暂停数据传输。应用程序发送3n字节的数据，并在前n字节后暂停数据流。在第一个数据字之后，应用程序取消对s_axi_tx_tvalid的断言，导致TX忽略总线上的所有数据并传输空闲块。暂停一直持续直到断言s_axi_tx_tvalid。

示例C：带暂停的数据发送

当发送时钟补偿序列时，核心自动中断数据传输。

4. 接收数据

因为IP核没有用于用户数据的内置缓冲区，所以在RX AXI4-Stream接口上没有m_axi_rx_tready信号。用户应用程序控制从一个Aurora 64B/66B通道来的数据流，是IP核可选的流控制功能之一。

m_axi_rx_tvalid信号与IP核中每一帧的第一个word同时断言。m_axi_rx_tlast信号与每一帧的最后一个word或部分word同时断言。m_axi_rx_tkeep端口使用与s_axi_tx_tkeep相同的字节指示过程表示每个帧的最后一个字中的有效字节数。当m_axi_rx_tlast未断言时，指定所有有效字节数(所有1)，当m_axi_rx_tlast断言时指定准确的有效字节数。

如果选择CRC选项，接收的数据流将计算期望的CRC值。CRC块重新计算m_axi_rx_tkeep值，并相应地断言m_axi_rx_tlast。

IP核可以在任何时候取消断言m_axi_rx_tvalid，甚至在帧期间。

示例A：带暂停的数据接收

数据在m_axi_rx_tdata总线上。当前n个字节放在总线上时，断言m_axi_rx_tvalid输出，以表明数据已经为用户应用程序准备好了。

暂停结束之后，IP核断言m_axi_rx_tvalid并继续在m_axi_rx_tdata总线上组装剩余的数据。在帧的末尾，IP核断言m_axi_rx_tlast。IP核还会计算m_axi_rx_tkeep总线的值，并根据帧的最后一个字中的有效字节总数将其呈现给用户应用程序。

5. 帧效率

有两个因素会影响Aurora 64B/66B核心的帧效率:

• 帧的大小
• 每32个user_clk周期后，从gearbox发出的数据无效请求。

GTX和GTH收发器中的gearbox需要一个周期性的暂停来满足时钟分频比和64B/66B编码。在AXI4-Stream接口中，用户数据需要在每32个循环之后停止一个循环。用户接口中来自Aurora 64B/66B核心的s_ax_tx_tready信号被取消一个周期，每32个周期后取消一次。暂停周期用于补偿变速箱的64B/66B编码。

关于这一部分，可以看看另一篇关于GTX收发器的知识10G光通信 64B66B编解码 配置方法及其工作原理-两种序列计数器工作原理章节，Aurora 64B/66B就是在简单的64B/66B编码收发器的基础上增加了帧结构，简化了用户的使用和控制。

Aurora 64B/66B核心实现了Aurora 64B/66B协议的严格对齐选项。在给定的周期内，没有数据块被放置在空闲块或SEP块之后。下表是一个包含时钟补偿开销(每4992 user_clk周期发送一次最多8个CC字符的CC序列)后计算的示例，显示了单lane的效率，同时说明了效率随帧长增加而增加。

当传输256字节的帧数据时，单lane通道中的开销如下表。由于帧尾SEP块使得数据单元长度为264字节。这将导致3.03%的发送器开销。此外，时钟补偿块必须每10,000个周期至少传输3个周期，从而在发送器中增加0.03%的额外开销。

2.3.3 Streaming接口

流接口允许在没有帧分隔符的情况下进行数据传输，从而使其操作简单，同时使用的资源比帧接口少。

1. 发送与接收数据

在Streaming中，Aurora 64B/66B通道以流水线处理。streaming Aurora 64B/66B接口需要数据被填充到整个s_ax_tx_tdata端口宽度(8字节的整数倍)。当s_ax_tx_tvalid被取消断言时，除了传输时钟补偿序列外，保留的word之间会产生间隙。

当数据到达Aurora 64B/66B通道的RX端时，必须立即读取，否则就会丢失。如果这是不可接受的，RX接口必须连接缓冲区来保存数据，直到数据可以被使用。

示例A：TX Streaming 数据传输

下图显示了一个典型的流数据传输。第一个时钟周期，两个ready信号都没有断言，表明用户逻辑和IP核都没有准备好传输数据。
下一个时钟周期，IP核通过断言s_axi_tx_tready表示它已准备好传输数据。
下一个时钟周期，用户逻辑断言s_ax_tx_tvalid信号，并将数据放在s_ax_tx_tdata总线上，表明它已经准备好传输数据了。因为两个信号现在都断言，数据拍0 从用户逻辑转移到IP核。
下一个时钟周期，数据拍1 传输。
下一个时钟周期，IP核取消它的就绪信号s_axi_tx_tready，数据无效。
下一个时钟周期，s_axi_tx_tready信号被断言时，传输数据。
下一个时钟周期，用户应用程序取消断言s_axi_tx_tvalid，数据无效，在断言两个ready信号之前不传输任何数据。

这里值得注意的是，实际应用中我们用户的ready是可控的，所以根据IP核的readys_axi_tx_tready给数据。收发器IP核是在ready有效信号的后一周期对应数据有效，而Aurora 64B/66B IP核ready信号s_axi_tx_tready与当前周期的数据对应。也就是说，当s_axi_tx_tready取消断言时，当前数据需要保持到下一个断言的周期才能保证当前数据被发送出去了。这个区别导致我在实际工程中测试了很久才发现:)。

示例A：RX Streaming 数据传输

流模式的接收非常简单，根据有效位接收数据就行。

2.3.2 时钟接口

Aurora 64B/66B IP核时钟端口：

2.3.4 流控制接口

2.3.5 状态、控制、传输接口

2.3.6 CRC接口