提示：文章写完后，目录可以自动生成，如何生成可参考右边的帮助文档

Aurora 协议学习理解与应用——Aurora 64B66B协议学习)

---

概述

Aurora 协议描述了通过 Aurora channel传输用户数据，该通道由一个或多个 Aurora lane组成。每个 Aurora lane都是串行数据连接，可以是全双工，也可以是单工。通过channel进行通信的设备称为channel partners。
Aurora 接口允许用户应用程序通过 Aurora 通道传输数据。每个 Aurora 接口上的用户接口未在本规范中定义。
Aurora通道包含下面这些属性：
1、数据通过 Aurora 通道以帧的形式传输。
2、帧与控制信息（例如流量控制消息、时钟补偿序列和空闲）共享通道。
3、帧可以是任意长度，并且可以具有任意格式。本规范仅定义了框架的轮廓。
4、Aurora 中的帧不必是连续的 — 它们可以随时被流量控制消息或空闲中断。
Aurora 中的帧之间不需要间隙。

下图显示了一对 Aurora 通道之间的单工连接，描述了包含 Aurora 连接的 PCS 和 PMA 层的功能块。这些块在本文档中有详细说明。

Aurora接口由一个或者多个Aurora lane构成，可以是单工或者双工。4种可能的Aurora接口配置如图：
（1）下图显示单lane，单工Aurora接口传输到另一个单lane单工接口，在这种配置下，每个接口使用单个lane从 Aurora 通道发送或接收。每个接口中的通道控制都会初始化通道，将控制权传递给用户应用程序。

图 1-4 显示了一个多lane、单工 Aurora 接口传输到另一个多lane、单工 Aurora 接口。在多lane配置中，作为通道初始化过程的一部分，通道控制会绑定lane以消除通道之间的偏差。在正常操作期间，通道控制逻辑在通道中的所有通道上分发数据和控制信息。

图 1-5 显示了一对单lane、全双工 Aurora 接口。全双工 Aurora 接口可以从 Aurora 通道发送和接收数据 - 它们的lane同时具有 TX 和 RX 功能块。通道控制逻辑执行与单工lane相同的初始化过程，但在两个方向上。此外，控制信息用于允许每个Aurora接口检测对方是否准备好接收数据。

图 1-6 显示了一对多lane、全双工 Aurora 接口。全双工 Aurora 通道还可以由任意数量的lane组成，在初始化期间进行绑定，以创建具有更高吞吐量的单个逻辑通道。

数据发送和接收

Aurora 64B/66B 中的所有传输均使用称为块的 64 bit码执行。可以通过 Aurora 通道传输的块有十种类型。在给定的周期内，一条通道只能传输一个块。因此，Aurora 中的块具有优先级 - 当需要在通道中同一通道上的同一周期发送两个或多个块时，始终选择最高优先级的块。表 2-1 总结了 Aurora 64B/66B 中可用的块。
（1）Clock Compensation：一种特殊的空闲块，可以由接收它的 Aurora 接口删除或复制。时钟补偿模块用于异步通道，具有共享时钟的通道不需要。
（2）Not Ready：全双工 Aurora 接口在尝试对齐通道中的数据并执行通道绑定时发送此特殊空闲块。
（3）Channel Bonding：用于通道绑定的特殊空闲块。 Aurora 接口同时在通道中的每个通道上传输通道绑定块。接收器上的通道需要调整其通道绑定 FIFO 以同时接收这些块，从而纠正通道之间的偏差。
（4）Native Flow Control：该块请求来自通道另一侧的 Aurora 接口的自然流量控制。当 Aurora 接口收到此消息时，它会开始自然流量控制倒计时，在此期间数据、分隔符和分隔符 7 块具有最低优先级。
（5）User Flow Control：该块用于启动用户流控制消息，并包含一个字段，指示后面有多少个字节是消息的一部分（最多 256 个）。当用户流控制消息正在处理时，数据、分隔符和分隔符 7 块下降到优先级 8（最低优先级），并且空闲上升到优先级 7。
（6）User K-Blocks：Aurora 64B/66B 包括几个未由 Aurora 接口解码的控制块，而是直接传递给用户。这些块可用于实现特定于应用程序的控制功能。有九个可用的用户 K 块。
（7）Data, Separator,Separator-7：这些块组合起来创建携带用户数据的帧。
• 数据块携带八个字节的数据。
• Separator 块指示当前帧的结束；下一帧从下一个块开始。分隔符块携带 0 到 6 个字节的数据：块中的一个字节用于指示块中有多少个字节是有效的。
• Separator-7 块与Separator 块相同，但始终携带正好七个有效字节的数据。
（8）Idle：每当更高优先级的块不可用于该通道时，就会传输空闲块。空闲块通常是优先级最低的块，但当 Aurora 接口响应自然流控制请求时，它们的优先级会升至 7，高于数据块、分隔符块和分隔符 7 块。
表 2-2 显示了传输块的相对优先级，该优先级始终有效，发送器正在处理流量控制请求时除外。

当发送器正在处理流量控制请求时，块的优先级发生变化。在自然流量控制倒计时或用户流量控制倒计时期间，空闲的优先级高于数据。由于当没有更高优先级的块可用时总是传输空闲，因此这种优先级的转变有效地阻止了帧传输，直到流量控制倒计时完成

帧传输过程

Aurora 接口执行以下过程，通过初始化的 Aurora 通道从用户应用程序传输帧：
• 使用 Separator 和 Separator-7 块描述帧
• 块采用 64B/66B 编码
• 数据流串行化，时钟嵌入
图 2-1 说明了如何通过此过程将帧映射到块代码。

链路层帧描绘

用户应该程序的每个帧的结尾都是用Separator 或 Separator-7 块来指示。这种划分允许channel partner区分来自不同帧的数据。帧本身被切成八个字节的块以适配数据块。帧末尾的任何剩余字节都在Separator 块的数据部分中传输。如果剩余字节的数量为六个或更少，则使用Separator 块。如果剩余七个字节，则使用 Separator-7 块。
注意：Aurora 接口可以在帧期间的任何时间选择发送更高优先级的块。空闲块也可以随时与数据和Separator块混合。

64B/66B 编码

帧经过链路层帧描述后，组成帧的Data块和 Separator块在传输之前由物理编码子层 (PCS) 进行 64B/66B 编码，将 64 位块转换为 66 位块代码。

多lane传输

多通道帧传输与单通道传输相同，不同之处在于，在链路层帧描述步骤期间从帧数据创建的块代码是使用第 6.4 节“帧数据条带化”中定义的条带化规则来调度传输的。这些规则将携带帧数据的块代码均匀地分布在构成通道的所有通道上。

帧接收过程

Aurora 接口执行以下过程以从初始化的 Aurora 通道接收帧并将其传递给用户应用程序：
• 数据解串
• 对所有块执行 64B/66B 解码
• 控制块从数据流中剥离

Control Block Stripping 控制块剥离

来自 Aurora 通道的Data和Separator块可以与控制块混合在一起，例如时钟补偿、通道绑定、流量控制、用户 K 块和空闲。所有这些控制块都与帧数据分离并单独处理。仅来自Data块和Separator块的数据字节作为帧传送到用户接口。
用户流控制消息也使用Data块来传输消息数据。当Data块的一部分用于用户流控制消息字节时，该块中的任何字节都不会用于携带数据字节。用户流量控制将在第 3 节“流量控制”中详细讨论。
Not Ready块重置帧。如果接收到“Not Ready”块，则认为帧丢失正在进行中。在“Not Ready”块之后接收到的块被视为新帧的一部分。

多lane接收

多通道帧接收与单通道接收相同，只是块码是从多个通道接收的。在控制块剥离步骤之前，块代码根据第 6.4 节“帧数据剥离”中定义的剥离规则进行排序。

Data 和Separator块格式

图 2-3 显示了用于承载帧数据的Data块的格式。Data块必须从最低有效字节开始填充，并且块中的数据必须是连续的。用于帧数据的Data块必须被完全填充。

图 2-4 显示了Separator块的格式。块的两个最重要的字节用于控制信息；其余块可用于帧数据。帧数据从最低有效字节开始添加到块中，并且块中的数据必须是连续的。Separator可以部分填充。未使用的字节被视为当前帧中的无关字节。 8 位有效字节计数字段指示Separator块中剩余的字节中有多少携带帧数据。该块可以携带 0 到 6 个字节的帧数据。

图 2-5 显示了 Separator-7 块的格式。块的最高有效字节用于控制信息；其余块用于帧数据。帧数据从最低有效字节开始添加到块中，并且块中的数据必须是连续的。 Separator-7 块的所有七个数据字节必须填充帧数据。

图2-6和图2-7分别显示了通过单通道和多通道Aurora通道传输帧数据的示例。传输的每个帧都携带一系列递增的字节。
注意：帧可以被空闲中断，并且可以是连续的。Separator块本身可用于结束可被八整除的帧，或携带七个字节或更小的帧的所有数据。

流控

本章介绍 Aurora 64B/66B 协议中的可选流量控制功能。
Aurora 支持以下流量控制机制：
• 自然流量控制：一种链路层流量控制机制，允许接收器请求其channel partner传输空闲数据而不是数据。这些请求由远程 Aurora 接口执行。
• 用户流量控制：一种允许通过Aurora 通道发送短的、高优先级的控制消息的机制。这些消息可用于实现更高级别的流量控制机制和特定于应用程序的控制方案。
Aurora 64B/66B 流量控制与 Aurora 8B/10B 流量控制非常相似，但有四个主要区别：
• 流量控制使用块码和64B/66B编码，而不是8B/10B符号和8B/10B编码
• 用户流量控制消息的长度可以是 1 到 256 个字节
• 用户流控制消息可以被块边界处的控制字符中断
• 自然流量控制PAUSE间隔未编码

自然流量控制操作

要启动自然流量控制 (NFC) 机制，Aurora 接口必须向其channel partner发送自然流量控制请求消息。该消息携带一个 PAUSE 值，告诉channel partner将空闲设置为比数据更高的优先级，直到 PAUSE 请求的非数据块数量（不包括时钟补偿和未就绪）在其每个通道上传输为止。发送器处理自然流量控制请求的时间称为自然流量控制倒计时（native flow control countdown）。
NFC 消息不是累积的：如果在 Aurora 接口仍在处理先前的 NFC 请求时有新的 NFC 消息到达，则新的 PAUSE 值会立即替换旧的。
自然流控制有两种操作模式：立即模式和完成模式。在立即模式下，Aurora 接口必须立即处理它们收到的任何 NFC 请求。在完成模式下，Aurora 接口必须等到它们处于新帧的开头（在尚未传输帧数据的帧中），然后才能处理 NFC 请求。（这点跟8B10B一样）
PAUSE 值是 8 bit值，用于携带指示 NFC 倒计时周期长度的二进制值。还有一个 XOFF 位用于请求 XOFF 模式。在 XOFF 模式下，空闲的优先级高于数据，直到 Aurora 接口收到非 XOFF PAUSE 的 NFC 请求，或者发送或接收Not Ready块。
当 PAUSE 和 XOFF 均设置为 0 时发送请求时，NFC 将设置为 XON 模式。收到 XON 后，任何正在进行的 NFC 倒计时都会停止，空闲状态立即成为最低优先级块。

自然流量控制延迟

在立即模式下，NFC 请求消息传输与由于该请求而发送的第一个Idle块之间的时间必须不超过请求发起者在单个通道上发送 256 个块所花费的时间。

自然流量控制块格式

使用自然流控制块传输的 NFC 请求（图 3-1 显示了 NFC 块的格式）。为了发送请求，Aurora 接口会传输带有根据需要设置的 XOFF 位和 PAUSE 字段的 NFC 块。

用户流量控制操作

用户流控制（UFC）消息由User Flow Control头块和一组Data块组成，只要通道初始化并且没有更高优先级块正在传输，就可以随时发送。
UFC 消息由header和message data.组成。 UFC header指示消息中有多少个字节的数据。该消息的长度可以是 1 到 256 个字节之间的任意长度。消息字节使用数据块传输。如果最后一个数据块未完全填充，则未使用的字节将被视为无关 — 它们不能用于携带常规帧数据。
当传输 UFC 消息时，Data, Separator, and Separator-7块会降至最低优先级（低于空闲）。这种优先级下降可以防止常规帧数据与 UFC 消息数据混合。 UFC消息传输的时间称为用户流控倒计时（user flow control countdown）。如果没有更多的 UFC 消息字节要发送，则认为给定通道的倒计时已完成。
如果通道重置或 Aurora 接口在 UFC 消息中间收到“Not Ready”块，则该消息将被视为已丢弃 — Aurora 接口无需等待剩余字节。

自然流量控制消息格式

图 3-2 显示了 UFC 块的格式。该块用于发送 UFC 消息的header。图3-3显示了承载UFC消息数据的Data块的格式。数据块中的字节必须是连续的，但构成 UFC 消息的块之间可以有任意数量的块代码，只要它们不是携带帧数据的块或Not-ready块。
UFC_COUNT 是 8 bit字段，指示 UFC 消息的总长度（以字节为单位）。消息的长度为 UFC_COUNT + 1 个字节。
UFC 消息数据使用数据块发送。必须从最低有效字节开始填充块，并且块内的所有数据字节都是连续的。任何未使用的消息数据字节都是无关紧要的，并且不能用于常规帧数据。

第 32 页的图 3-4 和图 3-5 显示了分别通过单通道和多通道 Aurora 通道传输的合法 UFC 消息的示例。 UFC hearder块标有其块类型及其消息长度字段的十进制值。这些消息携带递增的十六进制字节。

初始化和错误处理

本章介绍用于准备 Aurora 通道进行操作的过程。 Aurora 64B/66B 通道的初始化是一个两阶段过程，包括以下阶段：
• lane初始化：在此阶段，通道中的每个串行lane都会单独重置并与传入数据的块边界对齐。
• 通道绑定：在此阶段，Aurora 接口使用通道绑定来补偿每个lane之间的偏差。通道绑定成功后，通道将被视为单个通信通道。
全双工通道包括一个附加状态，以确保连接到通道的两个 Aurora 接口在帧传输开始之前准备好接收数据。
Aurora 64B/66B 初始化与 Aurora 8B/10B 初始化在几个关键方面有所不同：
• 初始化消息和握手的数量减少
• 没有通道验证阶段
• 定义于IEEE 803.3ae [参考资料 1] 中 10G以太网中的64b66B块锁定状态机用于块对齐和错误处理
• Aurora 协议推荐特定的 CRC 多项式以与 64B/66B 加扰多项式兼容
第 34 页的图 4-1 说明了 Aurora 64B/66B 的初始化过程，包括用于全双工初始化的附加状态。单工 通道不包括 Wait For Remote 状态（在图 4-1 中，该状态被视为边缘，允许 单工 Aurora 接口立即离开该状态）。

Aurora Channel Initialization

lane 初始化

Aurora 通道由一个或多个单独的串行链路（通道）组成。在通道初始化期间，每个通道准备好发送和接收数据，然后发送块，同时尝试找到传入数据的块边界并与其对齐。
为了与传入块对齐，Aurora 接口使用 IEEE 802.3ae [参考文献 2] 中定义的块同步状态机（请参阅 IEEE 802.3ae (2002)，图 49-12）。 Aurora 接口保持在通道初始化状态，直到块同步状态机达到 64_GOOD 状态并置位 block_lock（参见第 35 页的图 4-2）。

如果在任何时候 block_lock 被置为无效，则认为锁定已丢失，并且通道中的所有通道必须返回到通道初始化状态。
Aurora 通道可以是全双工或单工。同样，它们也可以是单lane或多lane。表 4-1 显示了每种可能配置的通道初始化期间每个lane应传输的内容。

仅当通道中所有通道的 block_lock 均有效后，Aurora 接口才应离开通道初始化状态。表 4-2 显示了通道初始化完成后每种类型的 Aurora 接口的下一个状态。

全双工差分接收器可以在通道初始化期间调整其极性。如果在实现块锁定后，传入的块代码是数据而不是控制块，则通道可能会反转其 RX 极性并重置块锁定。重置块锁定为远程 Aurora 接口提供了发送控制块的时间，确保不会因通道中的实际数据块而错误地定义极性。(如果硬件上P和N管脚接反了，header是01和10是检测不出来的，因此还需要通过块内的数据来判断极性是否正确)

通道绑定

在消除lane之间的偏差之前，多lane 通道无法开始发送数据。在 Aurora 64B/66B 协议中，相差校正是在通道绑定阶段完成的。
在进行通道绑定时，全双工通道中的所有通道必须混合传输“Not Ready”和“Channel Bonding”块（所有通道必须同时传输“Channel Bonding”块）。每个Channel Bonding块之间的Not Ready的最小数量为四个。单工通道必须传输常规Idle块来代替Not Ready块。
当 Aurora 接口中的lane接收Channel Bonding块时，它们必须分别调整其 PCS 延迟，以便Channel Bonding块在 PCS 层的 RX 数据接口上同时可用。当Aurora通道控制逻辑发现通道中的所有lane同时传送Channel Bonding块时，通道绑定完成。
对于单工 Aurora 接口，在常规操作期间，如果没有更高优先级的块等待传输，则应在所有通道上同时定期传输Channel Bonding块。
如果在任何时候接收到非同时的通道绑定块，则接收 Aurora 接口必须返回通道绑定状态。
通道绑定成功后，Aurora 接口应离开通道绑定状态。第 37 页的表 4-3 显示了每种类型的 Aurora 接口的下一个状态。

Wait For Remote 等待远端响应

当全双工 Aurora 接口的Channel Partner未准备好接收数据时，其会进入Wait For Remote状态。如果Channel Partner正在传输“Not Ready”块，则视为未准备好接收数据。
在Wait For Remote状态时，Aurora 接口必须传输空闲和通道绑定块的混合。通道绑定块必须至少由四个空闲块分隔开。
当 Aurora 接口收到任何不是Channel Bonding, Clock Compensation, 或者Not Ready的块时，它们可能会离开Wait For Remote状态。 Aurora 接口在处于“Wait For Remote”状态时必须准备好接收数据，但不能传输数据。

Channel Ready

在通道就绪状态下，全双工Aurora接口可以自由地发送和接收数据以及流量控制。单工接口​​可以自由地发送或接收数据，具体取决于其类型。
如果任何通道的 block_lock（来自 IEEE 802.3ae [参考资料 2] 块同步状态机）被置为无效，或者 Aurora 接口因任何原因重置，则全双工模块必须返回通道初始化状态。如果它们有多个lane，并且模块在一个lane（但不是所有其他通道）上接收到通道绑定块，则必须返回通道绑定状态。如果模块收到“Not Ready”块，则它们必须返回“Wait For Remote”状态。全双工模块应传输至少 64 个空闲字符并接收至少 16 个空闲字符以转换到通道就绪状态。
如果 单工 TX Aurora 接口因任何原因重置，则会返回通道初始化状态。如果 单工 RX Aurora 接口因任何原因被重置，或者任何通道的 block_lock 被置为无效，则它们将返回通道初始化状态。如果由多个lane组成，如果接口在一个lane（但不是所有其他通道）上收到通道绑定块，则必须返回通道绑定状态。 单工 TX Aurora 接口应至少传输 64 个空闲字符，而 单工 RX Aurora 接口应至少接收 16 个空闲字符才能转换到通道就绪状态。

Simplex Transmitters 单工发送

由于单工发射机不知道通道何时初始化，因此它们不使用第 34 页图 4-1 中所示的初始化状态。相反，单工发射机连续发射，并由用户应用程序使用外部信息来确定开始发送真实数据的最佳时间。多通道单工收发器应始终定期发送通道绑定块，以便在通道重置时随时执行通道绑定。

Error Handling

Aurora 64B/66B 协议定义了两种类型的错误：硬错误和软错误。硬错误是灾难性的或不可恢复的错误，例如通道断开、缓冲区溢出或硬件故障。软错误是正常操作过程中预期出现的暂时性统计错误。
Aurora 接口通过重置来响应硬错误。 Aurora 接口检测到的任何硬件故障情况均应视为硬错误。
软错误不会导致重置，但可以报告给用户应用程序。控制块中的非法同步标头值（11 或 00）或非法块类型字段 (BTF) 值应报告为软错误。

CRC

由于数据在传输前会被加扰，如果在通道中使用 CRC 进行错误检测，建议使用以下标准多项式（公式 4-1）来计算传出数据的 32 位 CRC：

Aurora Encoding

Aurora 64B/66B 中的所有数据和控制信息均以 64 位块进行编码。每个 64 位块都标有同步标头值，指示它是数据块还是控制块。同步头与块组合形成块代码。 Aurora 64B/66B 中有 15 种类型的控制块可用。在这 15 个中，5 个是 Aurora 64B/66B 协议中永久分配的特定功能，9 个可以由更高级别的应用程序（用户 K-Blocks）分配任何含义；剩下的一个控制块被保留。

Block Codes in 64B/66B

64B/66B 中的所有块代码都有 8 个字节的数据或控制信息，前面有 2 位同步标头。数据块代码具有 01 同步标头。控制块代码具有 10 个同步标头。同步头值 11 和 00 是非法的，只要它们出现就应被标记为软错误（请参见第 4.3 节“错误处理”）。
同步头位永远不会被扰乱。然而，其余八个字节组在传输前总是被加扰。

Aurora 64B/66B数据块可以携带帧数据或用户流控制消息数据。数据块始终从最低有效字节（最右边的字节，距同步头最远）开始填充。发送常规数据时，必须使用所有八个字节。当携带 UFC 消息数据时，如果 UFC 消息在块末尾之前完成，则数据块可能会部分填充（剩余的字节不关心）。
每个控制块的最高有效字节始终用于携带块类型字段（BTF），用于标识正在传输的控制块的类型。 Aurora 64B/66B 中有 14 个合法的 BTF 值和 1 个保留值（表 5-1）。与这些 BTF 相对应的控制块将在下面的部分中更详细地描述。

Clock Compensation Idles

Idle块代码的bit 10 是时钟补偿位 (CC)。当该位为高时，块代码是Clock Compensation Idle。当发送bit 10 设置为高的空闲块时，bit11、12 和 13 必须为低。在多lane通道中，Clock Compensation idles必须在所有通道上同时传输。

Channel Bonding Idles

Idle块代码的bit 11 是通道绑定位 (CB)。当该位为高时，块码是Channel Bonding Idles。当发送bit 11 设置为高的空闲块代码时，发送器必须将bit 10、12 和 13 设置为低。在多lane通道中，Channel Bonding idles必须在所有通道上同时传输

Not Ready Idles

Idle块代码的bit 12 是未就绪位 (NR)。当该位为高时，块代码为Not Ready idle。Not Ready idle用于全双工初始化，如第 4.2.3 节“等待远程”中所述。单工 Aurora 接口不使用“Not Ready idle” — 单工 Aurora 发送器必须始终将bit 12 设置为低，并且单工接收器应将所有传入空闲块代码视为bit 12 为低。
当发送bit 12设置为高的空闲块代码时，发送器必须将bit10 /11设置为低。在多lane通道中，如果在给定周期上传输的任何空闲的bit 12 为高，则在该周期上传输的所有空闲块代码必须将bit 12 设置为高。

Regular Idles

当空闲块码的bit 10、11 和 12 为低时，块码被认为是常规空闲，没有特殊属性。

The Strict Alignment Bit

空闲块代码的bit 13 是严格对齐 (SA) 位。具有遵守第 6.5 节“严格对齐帧数据条带化”和第 6.7 节“严格对齐用户流控制条带化”中所述的严格对齐规则的接收器的全双工模块，每当发送常规空闲或非空闲时，必须将bit13 设置为高电平。
如果接收到空闲块代码且bit 13 设置为高，则表示来自远程 Aurora 接口的接收器仅接受严格对齐的数据。

Native Flow Control Block Code

图 5-2 显示了自然流控制块代码的格式。该块代码用于发送 NFC 消息以执行第 3.2 节“本机流量控制操作”中描述的功能。
块代码的第二个字节（bit 10 至 17）用于携带 NFC 消息的 PAUSE 字段。 PAUSE 用于请求特定数量的空闲周期。bit 18 是 XOFF 位。该bit设置为高电平以发出 NFC XOFF 请求。当该bit为高时，PAUSE 字段可以被视为无关。

Data Block Code for Frame Data

Separator Block Code

有效字节计数是一个 8 bit字段，指示Separator块中帧数据字节的数量

Separator-7 Block Code

User Flow Control Block Code

UFC 计数是一个 8 位字段，可以设置为任何 8 位值。 UFC 消息中的字节总数 = UFC_Count +1。

Data Block Code for User Flow Control Message

图 5-7 显示了用于携带用户流量控制消息字节的数据块代码的格式。数据块可以被部分填充。所有有效的消息字节必须从最低有效字节位置开始连续放置在块中。
如果在用户流控制消息的末尾没有足够的字节来填充整个块，则块中的剩余空间被视为无关。剩余空间不能用于帧数据或来自不同消息的 UFC 消息数据

User K-Block Codes

Aurora 64B/66B 中有九个未分配的 BTF 值供用户应用程序使用。当 Aurora 接口接收到这些块之一时，它会将 BTF 和块中剩余的 7 个字节作为用户 K 块直接传递给用户应用程序。图 5-8 显示了用户 K 块的格式。表 5-3 显示了可用于用户 K 块的 BTF，以及与 Aurora 64B/66B 协议中每个 BTF 关联的名称。

64B/66B Scrambling

每当lane传输块代码时，必须使用具有多项式的自同步扰码器对 2 位同步标头后面的 8 个字节进行扰码：

公式 5-1 是 IEEE 802.3ae [参考资料 2] 中使用的加扰算法。 2 位同步头不能用于加扰。
当接收到块码时，必须使用自同步解扰器使用公式 5-1 中的相同多项式对 2 位同步头后面的 8 个字节进行解扰。这与 IEEE 802.3ae [参考资料 2] 中使用的解扰算法相同。 2 位同步头永远不会被解扰。

64B/66B Gearbox

当传输块代码时，64B/66B块同步状态机将同步头与来自扰码器的64位块组合，以向PMA层呈现66位块代码。这与 IEEE 802.3ae [参考资料 2] 中使用的算法相同。
当接收到块码时，64B/66B Gearbox 将 66 位块从 PMA 分离为 2 位同步头和用于解扰的 64 位块。这与 IEEE 802.3ae [参考资料 2] 中使用的算法相同。

Channel Bonding

通道绑定在第 4 节“初始化和错误处理”中详细描述。 Aurora 接口接收端的 PCS 层必须能够通过缓冲传入数据、识别Channel Bonding块以及与其他lane通信来调整每个通道中的传入数据流来执行通道绑定，以便呈现通道绑定块同时从所有lane的 PCS 输出。
PCS 层中使用的缓冲区深度决定了 Aurora 接口可以支持的最大倾斜。

Clock Compensation

Clock Compensation idle块可用于防止由于恢复时钟和本地参考时钟之间的微小差异而导致数据损坏。当使用独立的时钟源来驱动连接的 TX 和 RX 侧的时钟时，就会出现这些差异。如果使用共享时钟，则不需要时钟补偿模块。
如果通道不使用共享时钟，则必须在通道中的每个lane上连续三个周期传输时钟补偿块，至少每 10,000 个周期传输一次。
执行时钟补偿的通道必须使用弹性缓冲区将数据从恢复的时钟域移动到本地时钟域。**如果弹性缓冲区几乎已满，则不应将Clock Compensation idle块写入缓冲区以防止其填满。如果弹性缓冲区几乎为空，则应从缓冲区中读取时钟补偿空闲块而不删除，以防止缓冲区下溢。**该算法可防止缓冲区溢出或下溢并允许异步操作。Clock Compensation idle块在接收器的所有其他部分中被视为regular idles。

通道控制

Aurora 接口可以使用由一个或多个 Aurora lanes组成的通道进行通信。本节定义使用多通道通道的条带化规则。这些规则规定了每个周期如何在 Aurora 通道的通道绑定通道之间分配块代码。

Idle Block Striping

1、Not Ready Blocks
Not Ready idle块必须同时在所有通道上传输。
2、Idle Blocks
Regular idle块可以在任何通道上传输，仅受第 2.2 节“块代码”中定义的 Aurora 64B/66B 块代码优先级规则的限制。
3、Clock Compensation Blocks
Clock Compensation idle块必须同时在所有通道上传输。
4、Channel Bonding Blocks
Channel Bonding idle块必须同时在所有通道上传输。

Native Flow Control Striping

每个周期可以传输任意数量的自然流控制块。这些块必须遵守第 2.2 节“块代码”中定义的 Aurora 64B/66B 块代码优先级规则。在同一周期传输的所有自然流控制块必须携带相同的 PAUSE 代码和 XOFF 位设置。
当多个自然流控制块在同一时钟周期到达时，接收器必须仅处理一个块，并选择任何块进行处理。

Frame Data Striping

帧数据条带化如下：
• 通道中的每个通道都分配有一个索引号。
(1)最低有效通道被分配索引号 0。
(2)所有lane均按从最高位到最低位的顺序编号。
• 在每个时钟周期，帧数据被分成Data块和Separator符块。
每个 Aurora 接口必须双方的索引顺序应保持一致。

Strict-Alignment Frame Data Striping

严格对齐帧数据条带化与帧数据条带化相同，但有以下附加限制：
• 如果任何lane在一个周期内传输帧数据，则所有lane都必须传输数据
• 如果帧在给定周期结束，则除带有分隔符的通道以及索引高于分隔符的任何lane外，所有lane都必须填充数据。
注意：索引高于分隔符的通道不能包含流量控制或用户数据块。

User Flow Control Striping

用户流控制消息使用帧数据条带化规则——UFC 标头块必须位于 UFC 数据块之前。帧数据中不能散布有用户流量控制数据。

Strict-Alignment User Flow Control Striping

严格对齐用户流控制条带化与帧数据条带化相同，但具有以下附加限制：
• 用户流量控制标头只能在最低有效lane（最小索引）中传输
• 用户流量控制数据必须在用户流量控制标头发送后的周期内发送
• 用户流量控制数据只能从最小的lane（最小索引）传输
• 如果任何lane在一个周期内传输用户流量控制数据，则所有lane都必须传输用户流量控制数据，但以下情况除外：
• 如果用户流控制消息在给定周期结束，则所有lane必须填充用户流控制数据，直到消息结束。
注意：索引高于分隔符的通道不能包含帧或用户数据块。

User K-Block Striping

所有用户 K 块必须在同一周期内传输。在给定的周期中，用户 K 块不能散布任何帧数据或流控制。

Strict-Alignment User K-Block Striping

严格对齐用户 K 块的条带化如下：
• 如果任何lane在一个周期内传输用户 K 块，则所有lane都必须传输用户 K 块
• 传输的用户K 块必须包含九个有效用户K 块编号中的任何一个

PMA层

Bit and Byte Ordering Convention

Aurora 协议中的位和字节顺序表示法与 IEEE 802.3ae [参考资料 2] 中使用的位和字节顺序表示法相反。编码块代码的最左边的位是同步头位。这些是块代码的最高有效位。块的最左边字节是最高有效字节。最右边的字节是最低有效字节。

Serialization

每个通道必须首先传输每个块代码的最高有效位，然后按顺序传输剩余的同步位和块代码的位（图 7-1）。
注意：上面的顺序与 IEEE 802.3ae [参考资料 2] 中为块代码指定的顺序相同，但位位置的名称已颠倒。