Aurora 8b/10b协议（高速收发器十五）

  点击进入高速收发器系列文章导航界面

  前面几篇文章通过自定义PHY协议去实现高速收发器收发数据，一帧数据包括帧头、数据、帧尾等信息，在空闲的时候发送FLSR伪随机序列降低电磁干扰，并且每隔固定空闲时间发送一次逗号，用于接收端字节对齐和时钟纠正。在接收端需要用户自己完成字对齐。

  xilinx官方其实提供了一个Aurora 8B/10B的IP，该IP本质就是对GTX进行封装，在其基础上完成组帧和拆包。并且该IP多了一个流控的处理方式，当接收端处理数据的速度低于发送端发送速度时，接收端可以通过一些指令让发送端暂停发送数据来防止接收端数据溢出。另一方面发送端可以把一些高优先级的数据立即发送给接收端。这两个功能是自定义PHY协议时所没有考虑的。

  Aurora 8B/10B IP开放给用户的功能极其简单，用户只需要以固定时序接收、发送数据即可，Aurora 8B/10B IP内部回自己组帧，会把数据进行字对齐之后再输出给用户。缺点是用户不能控制其组帧的格式之类的。

  本文讲解Aurora 8B/10B协议的一些规则，参考文档为Sp002，下一篇文章讲解xilinx的Aurora 8B/10B IP知识。

1、用户协议数据单元（user protocol data units）

  Aurora 8B/10B协议是一种可扩展的轻量级链路层协议，可用于在一条或多条高速串行通道上点对点传输数据。

  Aurora 8B/10B协议接口通过用户界面向用户应用程序传输数据和控制。该协议的数据传输方式如下图所示，左右两部分可以看成是两个高速收发器设备，该IP支持多通道的高速收发器。

  其中用户与IP之间可以传输两种数据，一种是用户的发送或者接收的数据，称为用户PDU。另一种是用于控制发送数据速率的指令（简称流控），称为用户流量控制（User Flow Control Messages）。

  Aurora 8B/10B协议发送数据的流程如下所示，需要经过Padding、组帧、8B/10B编码、串行化等几个过程。

  Padding：因为Aurora 8B/10B信道传输的最小信息单位是两个字节，因此首先需要检测用户待发送数据字节数为奇数还是偶数。如果是奇数，则在用户待发送数据后面补充一个值为0x9C（K28.4）的K码Pad数据。

  组帧：就是在开始发送数据前发送2字节的起始码SCP（值分别为K28.2、K27.7），在帧尾发送两字节停止位ECP（值分别为K29.7、K30.7）。

  8B/10B编码：在传输之前，通过高速收发器的PCS中的8B/10B进行编码，用于填充数据的Pad被编码为控制字符，其余被编码为数据字符。编码后的数据被串行化，以差分不归零（NRZ）格式传输。

  Aurora 8B/10B协议接收数据的流程如下所示，包含串并转换、8B/10B解码、去除帧头帧尾和空闲字符、去除Pad等几个阶段。

  串并转换：串行数据流以差分NRZ格式接收，将该数据反序列化为10位数据和控制符号。

  8B/10B解码：串并转换后，链路层有效负载被解码为八位字节流。在解码过程中，必须把停止位ECP之前的填充字符Pad标记，便于后续去除。

  去除链路层：把解码后用户数据流中的起始位SCP、停止位ECP、空闲字符去除，空闲字符可能是通过流控操作发送端插入的。空闲序列必须在偶数字节用户数据之后开始插入，并且插入偶数个空闲字符。

  去除Pad：最后去除填充的Pad字符0x9C（K28.4），之后把得到的数据传输给用户。

2、流控（Flow Control）

  Aurora 8B/10B协议除了常规的用户数据收发，主要特点是支持可选的流量控制机制和多通道绑定机制。可选的流量控制机制提供了低延迟流量控制，防止因为发送速率和接收速率不同导致的数据丢失。

  Aurora 8B/10B协议支持User Flow Control（UFC）和Native Flow Control（NFC）两种流量控制机制，相关的流量控制方案如下图所示，下文将对这两种机制进行详细讲解。

2.1、用户流量控制（UFC）

  这个接口主要用于传输一些高优先级的数据，将UFC数据插入到用户待发送数据（UPDU）中，优先传输，一般用来传输比较重要的控制信息。下图是UFC数据的流向图，均是单向传输。

  UFC开始传输后不能被时钟补偿序列、NFC或空闲序列中断。因为UFC会中断用户数据的发送，因此Aurora 8B/10B协议实现可能需要将用户待发送数据暂存，防止数据丢失。

  UFC的数据格式如下图所示，长度为4到18个字节，第一个字节是用户流控制开始字符（SUF），是一个K码，值为K28.4。

  第二个字节称为命令字节的数据字符，之后紧跟着发送用户需要传输的高优先级数据，数据长度为2到16个字节。

  注意K28.4可以用于SUF和填充，区别在于填充字符后面只能跟一个控制字符，不能跟一个数据字符。

  UFC消息的长度为SIZE取值乘2加2，即SIZE*2+2。因为SIZE长度只有三位，因此UFC消息大小可以是2到16之间的任意偶数字节。

2.2、本地流量控制（NFC）

  本地流量控制（Native Flow Control，简称NFC）是一种链路层流量控制机制，由Aurora 8B/10B接口生成并解释，而UFC是上层实现的机制。

  NFC的机制其实比较简单，如下图所示，高速收发器A通过蓝色走线向高速收发器B传输数据。由于双方的速率可能并不一致，导致高速收发器B的用户接收FIFO快溢出了，此时高速收发器B会生成NFC消息，然后通过发送端口传输给高速收发器A的接收端。

  高速收发器A解析NFC消息之后，可能会暂停发送用户数据（蓝线暂停），而是发送空闲数据（黄线发送），接收端接收空闲数据会直接丢弃，不会存入接收FIFO，通过上述机制来防止接收FIF溢出。

  注意NFC的优先级低于UFC，这是因为发送的UFC消息也不会存入接收端的FIFO中，即UFC的传输对接收端的FIFO溢出没有影响。

  高速收发器A的发送端通过在请求的时间间隔内暂停发送用户数据，来响应接收端的NFC控制。这段时间除了可以发送空闲序列之外，暂停还可以传输UFC和NFC数据，因为这些都没有存储在接收端的FIFO中。

  发送端暂停的时间与接收端通过NFC传输的数据有关，NFC的数据格式如下图所示，长度为两字节。第一个字节是本地流控制开始字符（SNF），第二个字节是数据字符，称为命令字节。

  命令字节包含暂停字段，该字段指定发送空闲字符的时钟周期数，下表显示了暂停字段的编码。

  当发送端口收到接收端的NFC数据时，如果Aurora 8B/10B接口正在发送用户数据，发送端可以通过完成模式或立即模式两种方式之一响应NFC。

  完成模式需要等待用户这一帧数据发送完成之后才执行暂停的时间，而立即模式可以直接中断用户当前数据的发送，直接暂停规定时间，一般会采用立即模式吧。

  通过上面分析可知，NFC与用户收发数据的关系不大，是在Aurora 8B/10B协议内部完成的。可能有点影响的是暂停时间设置多大合适，要考虑接收端与发送端传输的延迟，不能发送端接收到NFC时，接收端的FIFO就已经溢出了。

3、初始化和错误处理

  下文介绍准备Aurora 8B/10B通道以进行数据传输和接收所需的初始化程序，Aurora 8B/10B通道的初始化分为三个阶段，即通道初始化、通道绑定、通道验证。

  这部分内容大多直接翻译手册，用户只需要了解即可，知道有这些东西，对于具体实现方式不需要关注太多。

  通道初始化：在每个通道上单独执行，以激活数据传输的链路并将接收到的数据与正确的边界对齐（字节对齐）。

  通道绑定：将多个通道绑定为一个数据通道。如果仅使用单条链路，则不需要通道绑定，通道绑定将被绕过。通道绑定消除了各种来源引起的偏斜，包括PCB走线长度、连接器和IC变化。

  通道验证：将接收到的数据映射到用户界面所需的任何校准，并验证通道传输有效数据的能力。

  下图说明了这三个阶段是如何相互关联的，在通道验证期间，所有通道必须准备好接收数据。当Aurora 8B/10B接口完成通道验证时，可以立即开始传输数据。

  复位或通道故障时，独立通道初始化程序会使每个通道收发器与接收器同步。通道传输的数据错误过多或者违反协议都会造成通道故障。

  下图显示了通道初始化程序的状态图，其中/SP/表示同步和极性、/K/表示逗号，/SPA/表示同步和极性应答。

  下图是该协议中一些K码的含义。

  注意D21.5是D10.2的倒数，而D19.6是D12.1的倒数。

  通道绑定过程会对齐每个通道接收的所有数据，下图显示了通道绑定程序的状态图。

  通道绑定分两个阶段进行，第一阶段对应于上图中的状态CB0，由收发器特定数据对齐组成。第二阶段对应于状态CB1，验证收发器是否已正确对齐，并同时传送/I/有序集内的/A/有序集。

  通道验证用于在用户界面上对齐数据，并验证通道完整性，实质包括在每个方向的所有通道上发送通道验证序列。

  当所有通道接收器都接收到第三个/V/有序集时，接收器的通道接收器部分（如果尚未启用）必须启用以防止数据丢失。

  在正常的数据传输过程中，通道可能会出现故障。在串行收发器正确字节对齐数据之前，输出端会出现许多错误。因此，在通道稳定之前不激活任何错误检测电路。

  一旦K计数器达到3，所有错误检测电路都应被激活，一般有硬错误和软错误的两种类型错误。

  当发送或接收弹性buffer上溢或下溢、软错误太多，接收或者发送放复位、接收和发送端断开物理连接则被认为是硬错误，硬错误一般都需要进行复位处理。

  软错误通常是由通道上的瞬时位错误引起的，软错误不一定需要复位通道。Aurora 8B/10B协议不进行显式数据错误检查，应该通过用户的错误处理能力来检测和纠正由软错误引起的数据错误。

  在高速系统中，对于信道完整性较差的系统，误差可能在几分钟内发生，对于信道完整性较好的系统，可能在几天或几年内发生。

  因此，Aurora 8B/10B接口必须实施软错误监控逻辑来验证正在进行的通道完整性。该逻辑由软错误计数器和每个通道的相关控制逻辑组成。下图说明了软错误监控逻辑所需的行为。

4、PCS和PMA

  Aurora 8B/10B协议手册还讲解了PCS、PMA以及8B/10B编码解码，但是这些内容与GTX的功能是一致的，因此不再赘述。

  在初始化器件，空闲字节用于执行字节对齐和通道绑定。在发送数据期间，空闲用于指示没有数据，此时必须发送伪随机序列，用于降低EMI。

  Aurora 8B/10B协议为了补偿发送端与接收端的时钟速率差异，会定期将时钟补偿序列插入空闲模式或用户数据中，使得接收端对时钟进行纠正，与自定义PHY协议中每间隔固定时间发送一个用于时钟纠正的K码效果一致。

  这种时钟补偿机制，可以补偿发送端和接收端之间高达100ppm的时钟速率差异。由图11知，一般使用K23.7作为时钟补偿序列。

  发送端传输10000个字符后至少要传输一次时钟补偿序列，对于多通道，完整的时钟补偿序列在每个通道上同时传输。

  Aurora 8B/10B协议可以发送多种数据，发送各种数据优先级如下图所示，时钟纠正序列优先级最高，其实是初始化序列、NFC、UFC、用户数据、空闲数据。

  综上所述就是Aurora 8B/10B协议的相关内容了，本质就是规定了组帧格式、空闲是发送伪随机序列、通道初始化及通道绑定相关功能、时钟补偿序列等等。

  与自定PHY协议的主要区别在于流量控制，UFC和NFC，其中UFC给用户发送高优先级数据提供通道，而NFC用于仿真接收端FIFO溢出。

  本文讲解的是Aurora 8B/10B协议内容，而这个协议是开放协议，xilinx在此基础上提供了一个Aurora 8B/10B IP，下文将讲解xilinx的Aurora 8B/10B IP相关信息。

  本文的多数内容来自sp002手册，可以在xilinx官网获取该手册，也可以在公众号后台回复“xilinx手册”（不包括引号）获取相关的所有手册。