硬件流控制(Flow control): 方法和协议(protocols)与 MGTs配合使用

本页是介绍 Multi-Gigabit Transceiver (MGT)的一系列页面中的第八页,也是最后一页。

介绍

硬件流控制是一种常用于各种数据链路的机制。该机制的目的是防止传输的数据量超过接收端的处理能力。

与 MGTs 相关的协议对此功能提供不同级别的支持。例如,如果接收方的缓冲区已满,则实现了PCIe 协议的逻辑将不会接受数据包（packet）请求进行传输。使用 PCIe 协议的应用逻辑无需实现任何相关功能。相反,应用逻辑和 PCIe protocol 逻辑之间的接口允许协议暂时拒绝接收新数据(例如,借助 VALID 和 READY等 AXI-S 端口)。同样,应用逻辑也被允许暂时拒绝接收来自另一端的数据。通过这种方式,应用逻辑可以保护自身免受溢出（overflow）的攻击。

需要注意的是,不要将硬件流控制与 MGT自身 elastic buffer中用于防止溢出的机制混淆。硬件流控制与 MGT自身缓冲区页面中提到的 skip symbols 无关。硬件流控制用于保护应用逻辑的缓冲区。由于通常有多个数据通道将 MGT 用作共享资源,因此硬件流控制会针对每个此类通道单独且独立地强制执行。

一般来说,定义与计算机通信的协议负责处理硬件流控制机制。应用逻辑只需借助简单的 handshake 端口与协议逻辑（protocol logic）接口,就像许多其他类型的逻辑 blocks（logic blocks）一样。此外, PCIe 、 SuperSpeed USB和SATA自行处理硬件流控制。

遗憾的是,用于 FPGAs 之间通信的协议通常不支持当前级别的硬件流控制。唯一能完全支持硬件流控制的协议是Xillyp2p 。其他用于 FPGAs 的协议仅具备一些在应用逻辑中实现硬件流控制时可能有所帮助的功能。

本页将介绍几种实现硬件流控制的方法。稍后会简要概述 Aurora 和 Interlaken 如何辅助硬件流控制。但需要注意的是,除了使用 Xillyp2p的情况外,应用逻辑才是防止出现溢出的关键所在。

硬件流控制技术

硬件流控制的最终目标是防止接收方接收到的数据超过其处理能力。通常,接收方会将接收到的数据存储在缓冲区(或 FIFO)中,因此关键在于确保缓冲区中有足够的空间来存储所有接收到的数据。

硬件流控制与 MGTs配合使用时实现起来更加困难,主要原因是物理信道存在显著延迟。因此,停止发送数据的请求需要时间才能到达发送端。此外,从发送端停止发送数据到接收端停止接收数据之间也存在一定的延迟。

MGTs 的另一个困难是,物理通道上的比特错误（bit errors）可能会导致停止发送数据的请求丢失。

除了这两个困难之外, MGTs 的数据速率很高,通常人们都希望能够有效地利用这个物理数据通道。

与更简单的通信信道(例如 serial 端口(RS-232))相比, MGT 的硬件流控制需要更复杂,以确保不会发生溢出事件。以下将解释以下三种技术:

• XON / XOFF
• 限时 XOFF (“Pause”)
• Credits

在考虑将协议用于项目时,务必问以下两个问题:

• 应用逻辑相对于硬件流控制需要实现什么?答案可能是不需要实现任何东西,就像 PCIe、 SuperSpeed USB 和 Xillyp2p一样。
• 如果应用数据（application data）属于不同的通道: 硬件流控制机制是否允许分别暂停每个通道上的通信,还是会影响通过物理通道的所有流量?

In-band 和 out-of-band

在分别讨论这三种技术之前,有必要区分 in-band 硬件流控制和 out-of-band 硬件流控制。

在任何硬件流控制机制中,接收端需要向发送端发送请求或信息,以调节数据流。在许多实际应用场景中,双向都存在物理数据通道。换句话说,接收端也拥有一个等效的、反向的物理通道用于发送数据。

如果存在反向的物理信道,那么问题在于该信道是否用于发送硬件流控制请求。如果用于发送,则该机制称为 in-band 硬件流控制;否则,采用 out-of-band 硬件流控制。

一般来说, out-of-band 硬件流控制并非最佳解决方案,尤其因为它需要单独的物理线缆。但是,如果 MGT的声道是单向的,那么这是唯一的选择。

下面将结合 Interlaken 如何实现硬件流控制来进一步讨论这个主题。

现在,我们来了解一下硬件流控制的三种技术。

XON / XOFF

XON / XOFF 是 transmit on / off的缩写。这是最简单的硬件流控制机制,但它有一些明显的缺陷。

这种方法可以用多种方式实现,但其基本思想始终不变: 当接收器无法接收更多数据时,它会向发送器发送一条表示“立即停止传输”的消息。这就是 XOFF 的含义。之后,当接收器可以接收数据时,会发送 XON 消息以请求恢复数据流。由于这些请求比较简单,因此也适用于 in-band 和 out-of-band的传输。

上述所有关于硬件流控制与 MGT 结合使用的困难,都可以用 XON / XOFF 方法来演示。第一个困难是 XOFF 请求到达发送器需要一些时间: 发送器会持续发送数据,直到收到此请求为止。此外,请求到达时物理信道上已有的数据也将继续到达接收器。

因此,接收方必须尽早发送 XOFF 消息,以便后续到达的数据能够被处理。但究竟多早才算足够早呢?这取决于物理信道的往返时间。在某些情况下,这个参数是已知的,或者至少已知往返时间很短。

例如, SATA 协议使用 XON / XOFF。这很合理,因为协议是用于与硬盘通信的,而硬盘在物理上靠近 SATA controller。如果两个链路伙伴之间的距离未知且可能很大,则很难确定何时请求 XOFF的最佳时机。

另一个因素是发送器在收到 XOFF时能否立即停止。例如,当发送的内容包含数据包时,协议可能不允许在发送数据包的过程中停止传输。在定义发送 XOFF 或 XON的条件时,必须考虑所有情况。

另一个问题是,如果由于比特错误或其他物理信道故障导致 XOFF 消息丢失,会发生什么情况。如果发生这种情况,发送方可能会继续数据传输,从而导致溢出故障。因此,协议必须确保在可能丢失 XOFF 请求时停止传输。下文将介绍 Interlaken 如何解决这个问题。

总结这一机制: XON / XOFF 方法基于一个简单的概念,但遗憾的是,要用这种方法确保溢出永远不会发生却很困难,需要仔细考虑各种意外情况。下文将讨论的 credits 方法与之正好相反: 虽然难以理解,但却能轻松达到目的。

限时 XOFF (“Pause”)

限时 XOFF 是 XON / XOFF 方法的一种变体: 硬件流控制请求附带一个编号。该编号指示发送方从收到此请求之时起应暂停数据传输多长时间。更准确地说,这是发送方不应发送数据的时钟周期（clock cycles）编号。此方法类似于 Ethernet Pause 帧。

这种方法的优点在于之后无需使用 XON 。虽然在某些特定情况下这个功能可能有用,但即使如此,优势也微乎其微。

这里之所以提到有时限的 XOFF ,是因为该方法是 Aurora 协议的一部分。

Credits

Credits 限制了自通信信道初始化以来允许传输的数据元素数量。该数量由接收器通过某种控制信道(由协议定义)发送给发送器。通过这种方式,接收器可以控制发送到自身的数据量。

用一个简单的例子来解释最为清楚: 假设接收器的缓冲区初始容量为 1000 个数据元素。因此,它会向发送器发送一条消息,告知其 credits 容量为 1000 个数据元素。发送器可以立即发送这 1000 个数据元素,也可以稍后发送。但是,只要 credits 没有更新,发送器发送的数据元素总数就不会超过 1000 个。

一段时间后,接收器接收到了 500 个数据元素。在此期间,应用逻辑消耗了 100 个数据元素。此时,缓冲区有 400 个数据字,因此缓冲区还可以容纳额外的 600 个数据元素。

此时,接收器发送另一条消息,将 credits 更新为 1100。这表示已有 500 个数据元素到达,并且允许再接收 600 个数据元素,即使应用逻辑没有从缓冲区中接收数据。因此,如果自开始以来发送器总共发送了 1100 个数据元素,则缓冲区将被填满。另一种理解方式是: 接收器总是将 credits 的值增加缓冲区消耗的数据元素的数量。

这种机制确保不会发生溢出错误,因为发送器永远不会发送超过接收器允许的数据量。然而,这种方法存在两个细微的缺陷。

第一个问题是接收器和发送器必须就一个起始点达成一致,即发送的数据元素数量为零。这需要某种初始化程序,双方都需要重置各自的计数器。所有使用 credits 的协议都有某种初始启动程序。这使得协议的情况更加复杂,因为双方都需要能够同时从一个状态切换到另一个。

第二个问题是数据流需要能够无限持续下去。 credits 的值一直在增加。如何才能用有限位数的数字来发送 credits 呢?答案是,只需发送 credits 二进制表示的低位部分(即 LSbs)即可。发送方使用相同位数的比特（bits）来表示已发送的数据元素数量。

这已经足够了,因为发送方仅使用 credits 来计算允许传输的数据元素数量。该数量通过 credits 减去已传输的数据元素数量来计算。计算结果不能大于接收方缓冲区的大小。如果该数量小于 2ⁿ,则 n LSbs 以上的所有比特都为零。因此,计算它们毫无意义。只需使用 n 比特进行减法运算即可。因此,在硬件流控制请求中,只需要 credits 二进制表示的较低值 n 比特即可。

例如, PCIe的硬件流控制是基于将 credits 作为二进制字传输的,该二进制字由 8 比特或 12 比特组成,具体取决于硬件流控制保护的是哪种类型的缓冲区。

使用 credits 有很多优点:

• 如果硬件流控制请求丢失,溢出不会受到影响: 与请求停止传输的 XON / XOFF不同, credits 允许发送更多数据。因此,如果丢失了 credits 更新,发送器将发送少于允许的数据量。这不会导致溢出的发生。
• 即使物理通道的延迟未知且可能很大, credits 机制依然高效。无需提前暂停数据流来补偿硬件流控制请求的延迟。
• 发射器预先知道它能否在不因硬件流控制而中断的情况下连续发送数据包。因此,可以确保数据包的连续发送。

硬件流控制与 Interlaken

Interlaken 协议在另一页中有简要介绍。

为了便于讨论硬件流控制,需要注意的是,协议会为每个数据突发分配一个通道号(通常介于 0 和 255 之间)。换句话说,协议基于多些应用数据（application data）数据流共享物理通道的概念。因此,硬件流控制机制可以独立控制每些应用数据数据流。

这款协议提供两种类型的硬件流控制机芯: In-band 硬件流控制和 out-of-band 硬件流控制(OOBFC)均为 XON/XOFF 机制。状态由每 channel对应的单个比特（bit）传递。当此通道准备好接收数据(XON)时,此比特为“1”;否则为“0”(XOFF)。

这两种机制的区别在于比特信号的传输方式: in-band 硬件流控制机制依赖于在每个突发传输前后发送一 control word 信号这一事实。该 control word 信号由 64 比特信号组成,其中 16 比特信号被分配给硬件流控制信号。这使得每 control word信号最多可以发出 16 XON / XOFF 请求。然而,这不足以支持多达 256 个信道: 每个通道都有自己的 XON / XOFF 比特。为了解决这个问题,硬件流控制信息被拆分成多 control words。这种方法称为calendar。 control word 中的 Bit 56 被称为“Reset Calendar”。当比特为“1”时, control word 包含与通道 0 到 15 相关的 XON / XOFF 请求。接下来的 control word 包含通道 16 到 31 的请求,依此类推。当所有通道都被覆盖后(可能只需要一 control word),序列将借助“Reset Calendar”重新开始。

当通过突发信号的 CRC24检测到比特错误时,所有信道都进入 XOFF 状态。原因是 CRC24 也涵盖了 control word,因此如果检测到错误,硬件流控制部分将被忽略。所以,发生此类事件后,在任何信道上进行传输都是不安全的。后续 control words 中的硬件流控制请求将逐步恢复正常运行。

in-band 硬件流控制的主要缺点是 XON / XOFF 请求的交付依赖于同方向传输的数据突发。如果这些突发持续时间较长,或者一段时间内完全没有突发传输,则 XON / XOFF 的交付时间可能会延长。这在一定程度上是可以理解的,因为在同一物理信道上发送的数据传输和硬件流控制消息不可避免地会相互竞争带宽。然而,其他协议通常会优先处理硬件流控制消息,以确保最大延迟保持一致。

out-of-band 硬件流控制(OOBFC)方案避免了与数据突发的竞争。采用此方法, XON / XOFF 请求通过三条额外的物理线路(FC_CLK、 FC_DATA 和 FC_SYNC)传输。所有通道的 XON / XOFF 比特请求则通过一条较长的 frame线路传输。

FC_SYNC 信号是高（high）,与 frame的第一个比特一起。 FC_CLK 的频率位于 0 和 100 MHz 之间,并且允许 DDR 时钟。由 4 比特(CRC-4)组成的 CRC 在 64 XON / XOFF 请求之后或最后一个请求之后插入。如果通过 CRC检测到错误,则所有通道进入 XOFF 状态。

当然, in-band 硬件流控制和 out-of-band 硬件流控制之间的选择取决于项目的具体要求。

Interlaken 不包含任何用于复用通道数据的机制。因此,应用逻辑负责仲裁各个通道的数据传输请求,并选择哪个通道可以传输突发数据(或整个数据包（packet）数据)。因此,当 XOFF需要暂停某个通道的传输时,应用逻辑也负责暂停该通道的传输。实现 Interlaken 协议的逻辑仅负责发送和接收 XON / XOFF 请求。

协议提及 credits 是实现硬件流控制的一种可能性,但仅表示可以通过专用通道来实现此方法。协议中没有提供任何关于如何实现此方法的详细信息。

硬件流控制与 Aurora

Aurora 协议在另一页中有简要介绍。协议提出了两种促进硬件流控制实现的机制: NFC 和 UFC。接下来将分别介绍这两种型号。

首先是 Native Flow Control (NFC) : 通过这种机制,接收端的应用逻辑具有向发送端发送硬件流控制请求的接口。这些请求包含两个独立的部分: XOFF 比特和限时 XOFF (“pause”)部件(这两个概念已在上文解释)。协议的发射端逻辑负责执行这些请求: 如果 XOFF 比特为“0”,则发送器会在时钟周期期间暂停数据传输,该时钟周期对应于硬件流控制请求中包含的 8 位数字。如果该数字为零,则数据传输立即恢复。请求中的数字不会累加。相反,每 NFC 请求都会使用新值更新暂停倒计时。

如果 XOFF 比特为“1”,则发送器无限期暂停数据传输。发送器仅在收到硬件流控制请求且请求值为 XOFF = '0' 时才会恢复数据传输。此类请求的处理方式如上所述。

请注意,硬件流控制机制控制所有通过物理数据通道的数据流量。因此,如果实现了对多个通道的单独控制,则 NFC 不适用于此类控制。

第二种机制是 User Flow Control (UFC) : 实际上,这是一个独立的通道,用于向另一端传输最大 256 字节的消息。 UFC 消息的优先级高于数据传输,因此它们能够以较低的延迟到达另一端。

由于该协议并未定义这些消息的格式,因此它们可用于实现任何类型的硬件流控制功能。这种实现完全在应用逻辑中完成。 UFC 消息也可用于传输任何其他类型的状态信息。

请注意,这两种硬件流控制机制中使用的消息均未针对物理链路上的比特错误进行保护。因此,硬件流控制请求可能到达错误或根本无法到达,从而可能导致接收方出现溢出错误。

由于这两种流量控制机制都基于相反方向的数据链路,因此它们仅在 full duplex 模式下可用。

概括

本页主要介绍了两种硬件流控制技术: XON / XOFF 和 credits。对于与计算机相关的协议(例如 PCIe、 SuperSpeed USB 和 SATA),硬件流控制由协议逻辑实现。另一方面,对于用于 FPGAs之间通信的协议,应用逻辑负责全部或大部分的实现。唯一的例外是 Xillyp2p,它负责数据通信的所有方面,包括硬件流控制、错误检测和重传。

本文介绍了与硬件流控制相关的两款协议(适用于 FPGAs )的功能: Interlaken 和 Aurora。如所示,这些协议将实现硬件流控制的更大负担留给了应用逻辑,尽管协议自身的功能在某些使用场景中可以完成一些工作。

这就是有关 MGTs的系列文章的最后一页。