S03-CH02-aurora_8b10b光通信

软件版本:VIVADO2017.4

操作系统:WIN10

硬件平台: K7/A7系列开发板

2.1概述

     本课内容讲解XILINX 官方的Aurora 8B/10B IP core的使用。以下内容大部分是基于官方datasheet的翻译。有不少不完善之处，建议读者和英文datsheet一起对比阅读。

     这个IP支持Kintex®-7, Virtex®-7 FPGA GTX 和GTH 收发器，Artix®-7 FPGA GTX 收发器, Zynq®-7000 GTX and GTX收发器。Aurora 8B/10B IP core可以工作于单工或者全双工模式。IP CODE 的使用也非常简单，支持AMBA®总线的AXI4-Stream协议。本课是用过外部的光纤线链接的，实际使用中也可以直接用在开发板之间链接,实现板子到板子的通信。本课程内容可以参考XILINX 官方文档PG046。

      图2-1-1是Aurora 8B/10B IP core简单的一个应用方式。对于用户来说，从应用角度，我们主要掌握IP CORE的使用以及正确编写用户逻辑代码。

图2-1-1 Aurora 8B/10B Channel Overview

      Aurora 8B/10B IP core具备很多优点，当一条通道联通的时候，它会自动初始化这条通路，并且以帧或者数据流的方式，发送一些测试数据。而且在正常通信的过程中，可以发送任意大小的帧，以及数据可以再任何时候中断。传输过程中有效数据字节之间的间隙会自动填充空闲，以保持锁定并防止过多的电磁干扰。流量控制可用于降低传入数据的速率或通过通道发送简短的高优先级消。Stream流传输是单一的，无限的帧。 在没有数据的情下，传送空闲以保持链接活着。 Aurora 8B/10B内核使用8B/10B编码规则检测单位和大多数多位错误。 过多的位错误，断开连接或设备故障导致内核复位并尝试重新初始化新通道。

Aurora 8B/10B IP的用途：

1)、芯片到芯片的链路：

      替换高速串行连接的芯片之间的并联连接可以显着减少PCB上所需的迹线和层数。 核心提供了使用GTX，GTX和GTH收发器所需的逻辑，FPGA资源成本最低。

2)、板对板和背板连接:

     IP CORE使用标准的8B / 10B编码，使其与现有的电缆和背板硬件标准兼容。 Aurora 8B / 10B内核可以在线速率和通道宽度上进行缩放，以便在新的高性能系统中使用便宜的传统硬件。

1. 、单向连接（单向）：

     Aurora协议提供了替代方法执行单向通道初始化，使GTX，GTX和GTH收发器在没有反向通道的情况下使用，并降低由于未使用的全双工资源而造成的成本。

2.2 Aurora 8B/10B IPCORE 描述

图2-1-2展示了Aurora 8B/10B内核的实现方框图

图2-2-1 Aurora 8B/10B Core Block Diagram

Lane Logic（通道逻辑）：

      每个GTX，GTX或GTH收发器（以下称为收发器）由通道逻辑模块的实例驱动，其初始化每个单独的收发器并处理控制字符的编码和解码以及错误检测。

Global Logic（全局逻辑）：

      全局逻辑模块执行通道初始化的绑定和验证阶段。 在运行期间，模块会生成Aurora协议所需的随机空闲字符，并监视所有通道逻辑模块的错误。

RX User Interface（RX接收端口）：

      AXI4-Stream RX接收端口将数据从通道移动到应用程序，并执行流量控制功能。

     TX User Interface（TX发送端口）：AXI4-Stream TX发送端口将数据从应用程序移动到通道，并执行流量控制TX功能。 标准时钟补偿模块嵌入在内核中。 该模块控制时钟补偿（CC）字符的周期性传输。

2.2.1性能表现(Performance)

最高频率：  参见XILINX Performance and Resource Utilization web

Latency(延迟)：

       通过Aurora 8B/10B内核的延迟是由通过协议引擎（PE）和收发器的流水线延迟引起的。 随着AXI4-Stream接口宽度的增加，PE流水线延迟增加。 收发器延迟取决于所选收发器的特性和属性。

      本节概述了Aurora 8B/10B核心AXI4-Stream用户端口对于2-byte-per-lane和4-byte-per-lane设计的user_clk周期的预期延迟。 为了说明延迟，Aurora 8B/10B模块被分为收发器逻辑和协议引擎（PE）逻辑，其在FPGA可编程逻辑中实现。

        注意：这些数字不包括由于Aurora 8B / 10B通道的每一侧之间的串行连接长度而引起的延迟。

        下图说明了默认配置的数据路径的延迟。 延迟可以根据设计中使用的收发器和IP配置而有所不同。

图2-2-1-1 Latency of the Data Path

         从s_axi_tx_tvalid到m_axi_rx_tvalid的两字节成帧设计的最小延迟在默认核心配置的功能仿真中大约为37个user_clk周期如下图所示

图2-2-1-2 Aurora 8B/10B 2-Byte Latency

       从s_axi_tx_tvalid到m_axi_rx_tvalid的默认四字节帧设计的最小延迟在功能仿真中大约为41个user_clk周期。

       流水线延迟被设计为保持时钟速度。如果没有依赖关系，请检查延迟是否可以通过其他可选功能添加。

Throughput（吞吐量）：

       Aurora 8B/10B核心吞吐量取决于收发器的数量和线速度。 单通道设计到16通道设计的吞吐量分别为0.4Gb/s到84.48Gb/s。 通过Aurora 8B/10B协议编码和0.5Gb/s至6.6 Gb/s线路速率范围的20％开销来计算吞吐量。

2.2.2 端口说明 （Port Descriptions）

       用于生成每个Aurora 8B/10B内核的参数决定了可用于该特定内核的接口。 接口在IP符号中可见，如图下图所示。 在IP符号中，如果左键单击界面旁边的+号，可以看到分组在其中的端口。 在本节中，也就是端口描述，一般来说，界面显示为单行条目，后面是分组在其中的端口。 例如，在表2-1（TX）中，USER_DATA_S_AXIS_TX是接口，s_axi_tx_ *端口分组到该接口中。 核心有四到六个接口。

图2-2-2-1`

注意:

1.选择小端点支持选项时，使用[n：0]总线格式。

2.选择大端支持选项时，使用[0：n]总线格式。

3.端口为高电平，除非另有说明。

用户接口(User Interface):

       Aurora 8B/10B内核可以通过成帧或流用户数据接口生成。 该接口包括流或帧数据传输所需的所有端口。帧用户接口符合AMBA®AXI4流协议规范，包括发送和接收成帧用户数据所需的信号。流接口允许数据要发送没有帧分隔符，这样操作更简单，并且使用比帧接口少的资源。 数据端口宽度取决于通道宽度和所选通道数。

Top-Level Architecture（顶级架构）

Aurora 8B / 10B核心顶层（块级）文件实例化了车道逻辑模块，TX和RX AXI4-Stream模块，全局逻辑模块和收发器的包装器。 在示例设计中也实例化了时钟，复位电路，帧生成器和检测器模块。

下图展示了双工配置的Aurora 8B/10B内核顶层。 顶级文件是用户设计的起点。

图2-2-2-2 Aurora 8B/10B Core Block Diagram

        本节提供了流和框架界面的详细信息。 用户接口逻辑应设计为符合相应接口的时序要求，如此处所述。

AXI4数据流位排序(AXI4-Stream Bit Ordering)：

       Aurora 8B / 10B内核采用升序排列。 它们首先发送和接收最高有效字节的最高有效位。 下图显示了Aurora 8B / 10B内核的AXI4-Stream数据接口的n字节示例。

图2-2-2-3 Top-Level Architecture

用户端口（User Interface Ports）：

下表列出了双工和单工核心模块AXI4-Stream TX和RX数据端口的描述。

表2-2-2-1 User I/O Ports (TX)

表2-2-2-2 User I/O Ports (RX)

注：1.如果选择了流式接口选项，此端口不可用。

2.2.3 框架界面(Framing Interface)

      下图显示了Aurora 8B/10B内核的成帧用户界面，AXI4-Stream兼容端口用于TX和RX数据。

2-2-3 Aurora 8B/10B Core Framing Interface (AXI4-Stream)

数据传输(Transmitting Data)

为了传输数据，用户应用程序操纵控制信号以使核心模块做到如下描述：

•从s_axi_tx_tdata总线上的用户端口获取数据

•s_axi_tx_tvalid和s_axi_tx_tready信号被断言。

•在Aurora 8B / 10B通道中划分数据。

•使用s_axi_tx_tvalid信号传输数据。 用户应用程序可以设置s_axi_tx_tvalid=0，以此插入空闲（引入停顿或暂停）。

•暂停数据（即插入空闲）（s_axi_tx_tvalid被取消置位）。

接收数据(Receiving Data)

当IPCORE接到数据时，它执行以下操作：

•检测和丢弃控制字节（空闲，时钟补偿，通道PDU（SCP），通道协议数据单元结（ECPDU）和PAD）。

•断开成帧信号（m_axi_rx_tlast）并指定有效字节数最后一个数据节拍（m_axi_rx_tkeep）。

•从车道恢复数据

•通过断言m_axi_rx_tvalid信号来组合数据以呈现给m_axi_rx_tdata总线上的用户接口。

        只有当s_axi_tx_tready和s_axi_tx_tvalid都被断言时，Aurora 8B / 10B内核才能采样（高）。

        AXI4-Stream数据仅在框架时有效。 帧外的数据将被忽略。 要启动一个帧，在s_axi_tx_tdata端口上的第一个数据字处于assert s_axi_tx_tvalid时。 要结束一个帧，在s_axi_tx_tdata端口上的数据的最后一个字（或部分字）上使用s_axi_tx_tlast，并使用s_axi_tx_tkeep来指定最后一个数据节拍中的有效字节数。

        在单个字长或更短的帧的情况下，s_axi_tx_tvalid和s_axi_tx_tlast同时被断言。

2.2.3 Aurora 8B/10B 帧（Frames）

       TX子模块将每个接收的用户帧通过TX接口转换为Aurora 8B / 10B帧。 帧开始（SOF）通过在帧开始处添加2字节的SCP代码组来指示。 帧结束（EOF）是通过在帧的末尾添加一个2字节的信道结束通道协议（ECP）码组来确定的。 数据不可用时插入空闲代码组。 代码组是8B / 10B编码字节对，所有数据都作为代码组发送，因此具有奇数个字节的用户帧具有称为PAD的控制字符，附加到帧的末尾以填写最终的代码组。 表2-3显示了具有偶数数据字节的典型Aurora 8B / 10B帧。

Length

用户应用程序通过操纵s_axi_tx_tvalid和s_axi_tx_tlast信号来控制通道帧长度。 Aurora 8B / 10B内核分别响应帧起始帧和帧结束顺序集，分别为/ SCP /和/ ECP，如表2-3所示。

表2-2-3-1:Typical Channel Frame

Example A: Simple Data Transfer(简单数据传输)

     图2-2-3-1显示了一个宽度为n字节的AXI4-Stream接口上的简单数据传输示例。 在这种情况下，发送的数据量为3n字节，因此需要三次数据节拍。 s_axi_tx_tready被断言，表示AXI4-Stream接口准备好传输数据。

      用户应用程序在前n个字节期间断言s_axi_tx_tvalid开始数据传输。 一个/ SCP /有序集放置在通道的前两个字节上，以指示帧的启动。 然后，第一个n-2个数据字节被放置在通道上。 由于/ SCP /所需的偏移量，每个数据节拍中的最后两个字节总是延迟一个周期，并在通道的下一个节拍的前两个字节上传输。

       要结束数据传输，用户应用程序将在s_axi_tx_tkeep总线上断言s_axi_tx_tlast，最后的数据字节以及适当的值。 在这个例子中，s_axi_tx_tkeep在演示的波形中设置为N，表示所有字节在最后一个数据节拍中有效。 当s_axi_tx_tlast被断言时，s_axi_tx_tready在下一个时钟周期中被断言，并且核心使用数据流中的间隙来发送最终偏移数据字节和/ ECP /有序集，指示帧的结束。 s_axi_tx_tready在下一个循环中被重新生成，以允许数据传输继续。

Example B: Data Transfer with Pad(使用Pad进行数据传输)

      图2-2-3-2显示了需要使用Pad的（3n-1）字节数据传输的示例。Aurora 8B / 10B内核根据协议要求为一个具有奇数个字节的帧附加一个Pad字符。 3n-1数据字节的传输需要两个完整的n字节数据字和一个部分数据字。 在此示例中，s_axi_tx_tkeep设置为N-1，以指示最后一个数据字中的n-1个有效字节。

图2-2-3-2 Data Transfer with Pad

Example C: Data Transfer with Pause（具有暂停的数据传输）

       图2-2-3-3显示了在帧传送过程中用户端口如何暂停数据传输。 在这个例子中，用户应用程序在前n个字节之后暂停数据流，取消s_axi_tx_tvalid，并发送空闲。 暂停继续，直到s_axi_tx_tvalid被取消置位。

图2-2-3-3 Data Transfer with Pause

Example D: Data Transfer with Clock Compensation（带时钟补偿的数据传输）

       当Aurora 8B / 10B内核发送时钟补偿序列时，会自动中断数据传输。 时钟补偿序列每10,000字节加上每个通道的12字节开销。

       图2-2-3-4显示了Aurora 8B / 10B内核在时钟补偿序列期间如何暂停数据传输。

2-2-3-4 Data Transfer Paused by Clock Compensation

      由于每通道需要每10,000字节的时钟补偿（每个通道设计的2个字节为5,000个时钟;每个通道设计为4个字节的2,500个时钟），因此您不能连续发送数据，也不能连续接收数据。 在时钟补偿期间，数据传输暂停六或三个时钟周期。

Receiving Data

       RX子模块没有用于用户数据的内置弹性缓冲区。 因此，RX AXI4-Stream接口上没有m_axi_rx_tready信号。 用户应用程序控制来自Aurora 8B / 10B通道的数据流的唯一方法是使用核心可选流量控制功能之一。

       m_axi_rx_tvalid信号与Aurora 8B / 10B内核的每帧的第一个字同时被断言。 m_axi_rx_tlast与每个帧的最后一个字或部分字同时断言。 m_axi_rx_tkeep端口指示每个帧的最终字中的有效字节数。m_axi_rx_tkeep信号仅在m_axi_rx_tlast被断言时有效。

       即使在帧内，Aurora 8B / 10B内核也可以随时取消放置m_axi_rx_tvalid。即使帧最初传输没有暂停，内核也可能会偶尔解除m_axi_rx_tvalid。 这些暂停是框架字符剥离和左对齐过程的结果。

        图2-2-3-5显示了由暂停中断的3n个字节的接收数据。 数据表示在m_axi_rx_tdata总线上。 当第一个n个字节被放置在总线上时，m_axi_rx_tvalid被断言，以指示数据为用户应用程序准备就绪。 内核在第一个数据节拍后的时钟周期内取消忽略m_axi_rx_tvalid，以指示数据流中的暂停。

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

图2-2-3-5 Data Reception with Pause

影响Aurora 8B / 10B内核框架效率的因素有两个：

•框架尺寸

•数据通路的宽度

      每个通道每隔10,000个字节使用12个字节的CC序列消耗总通道带宽的大约0.12％。Aurora 8B / 10B内核中的所有字节均以双字节代码组发送。 具有偶数字节的极光8B / 10B帧具有四个字节的开销，两个字节用于SCP（起始帧），两个字节用于ECP（帧结束）。具有奇数个字节的数据的8B / 10B帧有五个 字节的开销，四字节的成帧开销加上一个附加字节的pad字节。

      IP CORE仅在通道的特定通道中传输帧分隔符。 SCP仅在最左侧（MSB）的车道中传输，ECP仅在最右边（LSB）的车道中传输。 最后一个代码组与数据之间的通道中的任何空格与ECP代码组填充空闲。 结果是降低了设计的资源成本，牺牲了最小的附加吞吐量成本。 尽管SCP和ECP可以针对额外的吞吐量进行优化，但是在大多数情况下，由用户用户强加的每个周期限制的单个帧将使得此改进无法使用。

      下表它显示了8字节，4通道通道的效率，并说明了效率随着通道帧长度的增加而增加。

表2-2-3-1：Efficiency Example

      表2-2-3-1显示了在四个通道中传输256字节的帧数据时，8字节的4通道通道的开销。 由于起始和结束字符，结果数据单元长度为264字节，并且由于填充通道所需的空闲。 这相当于发射机的3.03％的开销。 另外，每隔10,000个字节，每个通道上会发生一个12字节的时钟补偿序列，这样就增加了一大部分的开销。 接收器可以处理稍微更有效的数据流，因为它不需要任何空闲模式。

表2-2-3-2：Typical Overhead for Transmitting 256 Data Bytes

表2-2-3-3：s_axi_tx_tkeep的值和开销的相应字节

      当在Vivado集成设计环境（IDE）中选择Little Endian选项时，s_axi_tx_tkeep位排序从MSB更改为LSB。

2.2.4数据流接口（Streaming Interface）

前面介绍的是Frame形式的传输，这里讲解Streaming 接口。

图2-2-4-1 Aurora 8B/10B Core Streaming User Interface

Transmitting and Receiving Data（发送和接收数据）

      流式接口允许将Aurora 8B/10B通道用作管道。 初始化后，通道始终可用于写入，除非发送时钟补偿序列。 核心数据传输符合AXI4-Stream协议。

      当s_axi_tx_tvalid被取消置位时，在字之间创建间隙，并且保留间隙，除非发送时钟补偿序列。

      当数据到达Aurora 8B/10B通道的RX侧时，它显示在m_axi_rx_tdata总线上，并且m_axi_rx_tvalid被断言。 数据必须立即读取或丢失。 如果这是不可接受的，缓冲区必须连接到RX接口来保存数据直到可以使用。

Example A: TX Streaming Data Transfer(TX流数据传输)

      图2-14显示了流数据的典型示例。 Aurora 8B / 10B内核表示可以通过断言s_axi_tx_tready传输数据。 一个周期之后，用户逻辑表示准备通过断言s_axi_tx_tdata总线和s_axi_tx_tvalid信号来传输数据。 因为两个就绪信号现在被断言，数据D0从用户逻辑传输到Aurora 8B / 10B内核。 数据D1在以下时钟周期进行传输。 在本例中，Aurora 8B / 10B内核取消了其准备就绪信号s_axi_tx_tready，并且在s_axi_tx_tready信号被断言的情况下，直到下一个时钟周期才会传输数据。 然后，用户逻辑在下一个时钟周期取消s_axi_tx_tvalid，并且在两个就绪信号被置位之前不传输任何数据。

图2-2-4-2 Typical Streaming Data Transfer

Example B: RX Streaming Data Transfer(RX流数据传输)

图2-2-4-3显示了数据传输的接收端。

图2-2-4-3 Typical Data Reception

2.2.5流量控制(Flow Control)

      本节介绍如何使用Aurora 8B/10B流量控制。 使用框架接口的内核上提供了两个可选的流控制接口。 本地流控制（NFC）调节全双工信道接收端的数据传输速率。 用户流控制（UFC）容纳用于控制操作的高优先级消息。

User Flow Control Interface（用户流控制接口）

     UFC接口是在启用UFC生成IPCORE时创建的（如图2-2-5-1 ）.UFC s_axi_ufc_tx_tvalid和TX侧的s_axi_ufc_tx_tready端口启动UFC消息，3位s_axi_ufc_tx_tdata端口指定消息的长度。 使用s_axi_ufc_tx_tready断言，UFC消息可以提供给数据端口。

图2-2-5-1 Aurora 8B/10B Core UFC Interface

        UFC接口的RX侧由一组AXI4-Stream端口组成，允许UFC消息被读取为一个帧。 Simplex模块仅保留在支持的方向发送数据所需的接口。

表2-2-5-1 UFC I/O Ports

Transmitting UFC Messages发送UFC消息

      UFC消息可以携带从2到16的偶数数据字节。用户应用程序通过在s_axi_ufc_tx_tdata端口上驱动SIZE代码来指定消息的长度。 UFC消息的合法SIZE代码值如表2-2-5-2所示。

表2-2-5-2

       要发送UFC消息，用户应用程序在使用所需的SIZE代码驱动s_axi_ufc_tx_tdata端口时会断言s_axi_ufc_tx_tvalid。必须保持s_axi_ufc_tx_tvalid信号，直到Aurora 8B / 10B IPCORE断言s_axi_ufc_tx_tready信号。UFC消息的数据必须放在s_axi_tx_tdata端口上，从s_axi_ufc_tx_tready被断言后的第一个周期开始。当s_axi_tx_tdata端口用于UFC数据时，核心模块将取消s_axi_tx_tready s_axi_tx_tready。

注意：只有在完成当前UFC请求后才应给予UFC请求; 背靠背UFC请求可能不会被IP所支持。

Number of Data Beats Required to Transmit UFC Messages(发送UFC消息所需的节拍数)

图2-2-5-2 Data Switching Circuit

       表2-2-5-3显示了根据AXI4-Stream数据接口的宽度传输不同大小的UFC消息所需的周数。在所有消息数据可用之前，不应启动UFC消息。 与常规数据不同，在s_axi_ufc_tx_tready已被确认直到当前UFC消息完成之前，UFC消息不能被中断。

表2-2-5-3 Number of Data Beats Required to Transmit UFC Messages

Example A: Transmitting a Single-Cycle UFC Message（发送单周期UFC消息）

      发送单周期UFC消息的过程如图2-2-5-3所示。 在这种情况下，4字节的消息正在4字节的接口上发送。

      注意：s_axi_ufc_tx_tready信号被断言两个周期。 Aurora 8B / 10B内核使用

      这个差距在数据流中传输UFC头和消息数据。

图2-2-5-3 Transmitting a Single-Cycle UFC Message

Example B: Transmitting a Multicycle UFC Message(发送多周期UFC消息)

       发送双周期UFC消息的过程如图2-2-5-4所示。 在这种情况下，用户应用程序使用2字节接口发送一个4字节的消息。 s_axi_tx_tready被断言三个周期：在s_axi_ufc_tx_tready周期期间发送的UFC头的一个周期，以及UFC数据的两个周期。

图2-2-5-4 Transmitting a Multicycle UFC Message

Receiving User Flow Control Messages(接收用户流控制消息)

      当Aurora 8B/10B内核接收到UFC消息时，它将通过专用UFC AXI4-Stream接口将数据传递给用户应用程序。数据显示在m_axi_ufc_rx_tdata端口上; m_axi_ufc_rx_tvalid表示消息数据的开始，m_axi_ufc_rx_tlast表示结束。m_axi_ufc_rx_tkeep用于在消息的最后一个周期中显示m_axi_ufc_rx_tdata上的有效字节数。

Example A: Receiving a Single-Cycle UFC Message(接收单周期UFC消息)

       图2-2-5-5显示了一个4位数据接口接收4字节UFC消息的Aurora 8B/10B内核。核心通过断言m_axi_ufc_rx_tvalid和m_axi_ufc_rx_tlast来指示单个周期框架将该数据提供给用户应用程序。 m_axi_ufc_rx_tkeep设置为4'hF，仅指示接口的四个最高有效字节有效。

图2-2-5-5 Receiving a Single-Cycle UFC Message

Example B: Receiving a Multicycle UFC Message(接收多个UFC消息)

上图显示了一个4字节接口接收8字节消息的Aurora 8B/10B内核模块。

注意：结果帧是两个周期长，第二个周期的m_axi_ufc_rx_tkeep设置为4'hF，表示数据的所有四个字节都有效。

2.2.6本地流量控制(Native Flow Control)

      Aurora 8B/10B协议包括本地流控制（NFC）接口（图2-2-6-1），其允许接收机通过指定必须放入数据流的空闲数据跳数来控制接收数据的速率。 甚至可以通过请求发送器临时发送空闲（XOFF）来完全关闭数据流.NFC通常用于防止FIFO溢出条件。有关NFC操作和代码的详细说明，请参阅Aurora 8B/10B协议规范（SP002）。

图2-2-6-1 Aurora 8B/10B Core NFC Interface

      当NFC选项启用时生成IPCORE时，就会创建NFC接口。该接口包括用于发送NFC消息的请求（s_axi_nfc_tx_tvalid）和确认（s_axi_nfc_tx_tready）端口以及4位s_axi_nfc_tx_tdata端口，以指定所请求的空闲周期数。 表2-2-6-1列出了NFC接口的端口，仅在全双工Aurora 8B/10B内核中可用。

表2-2-6-1：NFC I/O Ports

表2-2-6-2显示了本机流量控制（NFC）的代码。 这些值以大端格式的位[0：3]和小端格式的[3：0]驱动。

表2-2-6-2：NFC Codes

       用户应用程序断言s_axi_nfc_tx_tvalid并将NFC代码写入s_axi_nfc_tx_tdata。 NFC代码指示频道合作伙伴应在其TX数据流中插入的最小空闲周期数。 用户应用程序必须保存s_axi_nfc_tx_tvalid和s_axi_nfc_tx_tdata，直到s_axi_nfc_tx_tready被断言。 Aurora 8B / 10B内核在发送NFC消息时无法传输数据。 在s_axi_nfc_tx_tready断言之后的周期上，s_axi_tx_tready总是被取消置位。

示例A：发送NFC消息

       图2-2-6-2示出了当用户应用向通道伙伴发送NFC消息时的发送定时的示例。 s_axi_nfc_tx_tready信号被断言一个周期（假设n至少为2），以在NFC消息的数据流中创建间隙。

图2-2-6-2 Transmitting an NFC Message

Example B: Receiving a Message with NFC Idles Inserted(接收带有NFC空闲的消息插入)

图2-2-6-3显示了当接收到NFC消息时，TX用户界面上的信号示例。 在这种情况下，NFC消息具有0001的代码，请求两个空闲数据跳动。 内核在用户界面上取消s_axi_tx_tready，直到发送足够的空闲来满足请求。 在这个例子中，核心正在立即进入NFC模式，NFC空闲时间立即被插入。 Aurora 8B / 10B内核也可以在完成模式下工作，其中NFC空闲仅插入帧之间。 如果完成模式核心在发送帧时收到NFC消息，则在取消s_axi_tx_tready以插入空闲之前完成发送帧。

2-2-6-3 Receiving a Message with NFC Idles Inserted

2.2.7状态，控制和收发器接口

(Status, Control, and the Transceiver Interface)

       Aurora 8B/10B IPCORE的状态和控制端口允许应用程序监视通道并使用收发器的内置功能。 本节提供状态和控制界面，收发器串行I / O接口以及专用于单工模块的边带初始化端口的图表和端口说明。

状态和控制端口

       Aurora 8B/10B内核的状态和控制端口的功能如表表2-2-7-1所示。 收发器端口如表表2-2-7-3所示。

表2-2-7-1 Status and Control Ports

表2-2-7-1 接续

注：

1.m是收发器的数量。 有关详细信息，请参阅错误状态信号。

1. 仅在TX只有单工数据流模式和边带作为后通道核心配置。
2. 仅适用于仅限于RX的单工数据流模式和边带作为后通道核心配置。

Full-Duplex Cores全双工IP CORE

     Full-Duplex Status and Control Ports(全双工状态和控制端口)

全双工内核提供TX和RX Aurora 8B/10B通道连接。 全双工Aurora 8B/10B内核的状态和控制界面如图2-2-7-1所示。

图2-2-7-1 Status and Control Interface for Full-Duplex Cores

错误状态信号

       在Aurora 8B/10B通道操作中，设备问题和通道噪声可能会导致错误。8B/10B编码允许Aurora 8B/10B内核检测通道中出现的所有单位错误和大多数位错误，并在每个周期内断言soft_err。TX单工内核不包括一个soft_err端口。除非发生设备问题，否则所有传输数据都被认为是正确的。

       IPCORE还监控每个收发器的硬件错误，如缓冲区溢出/下溢和锁定失败，并断言hard_err信号。使用rx_hard_err信号报告单工内核的RX侧硬错误。灾难性的硬件错误也可以表现为一连串的软错误。核心使用Aurora 8B/10B协议规范（SP002）中描述的泄漏桶算法来检测在短时间内发生的大量软错误，并断言hard_err或rx_hard_err信号。

       每当检测到硬错误时，内核自动重置自身，并尝试重新初始化。一旦导致硬错误的硬件问题得到解决，这就允许频道重新初始化并重新建立。软错误不会导致复位，除非它们在短时间内发生。

       具有AXI4-Stream数据接口的Aurora 8B/10B IPCORE还可以检测Aurora 8B/10B帧中的错误并声明frame_err信号。帧错误可以是没有数据，连续起始帧符号和连续帧结束符号的帧。此信号不适用于单工TX内核。如果可用，该信号通常被认定为接近于soft_err断言，其中软错误是帧错误的主要原因。

       表2-2-7-2总结了Aurora 8B / 10B内核可以检测的错误情况以及用于提醒用户应用的错误信号。

表2-2-7-2Error Signals in Cores

Full-Duplex Initialization（全双工初始化）

      全双工IPCORE在上电，复位或硬错误后自动初始化，并执行Aurora 8B / 10B初始化过程，直到通道准备就绪。 lane_up总线指示通道中哪条通道已经完成了通道初始化过程。 该信号可用于帮助在多通道通道中调试设备问题。 只有在核心完成整个初始化过程之后，才会声明channel_up。

       Aurora 8B/10B IPCORE无法接收channel_up之前的数据。 应使用用户界面上的m_axi_rx_tvalid信号来限定传入数据。 channel_up可以被反转并用于重置驱动全双工通道TX侧的模块，因为在通道_up之前不会发生任何传输。 如果在数据接收之前需要复位用户应用模块，则可以将lane_up信号之一反转并使用。 在所有的lane_up信号被置位之后才能接收数据。

注：channel_init_sm模块中可以使用WATCHDOG_TIMEOUT参数来控制通道初始化过程中出现的看门狗定时器。

Simplex Cores(单工IPCORE)

单工TX状态和控制端口

        单工TX允许用户应用程序将数据传输到单工RX。他们没有RX连接。单片TX IPCORE的状态和控制界面如图2-2-7-2所示。

图2-2-7-2 Status and Control Interface for Simplex TX Core

单工接收状态和控制端口

       单工RX IPCORE允许用户应用从单工TXIPCORE接收数据。 单片RXIPCORE的状态和控制界面如图图2-2-7-3 所示。

图2-2-7-3 Status and Control Interface for Simplex RX Core

单工IPCORE的初始化

       单工IPCORE不依赖于Aurora 8B/10B通道的信号进行初始化。

       相反，单工通道的TX和RX侧通过一组边带初始化信号传送其初始化状态：对齐，绑定，验证和复位; 一个为TX侧设置TX_前缀，一个为RX侧设置一个RX_前缀。 绑定端口仅用于多通道内核。有两种方式可以使用边带初始化信号初始化单工模块：

•将RX边带初始化端口的信息发送到TX边带初始化端口

•使用定时初始化间隔，独立于RX边带初始化端口驱动TX边带初始化端口

以下部分将介绍两种初始化方法。

使用返回通道

      在RX和TX之间没有通道的情况下，返回通道是初始化和维