此页是介绍 Multi-Gigabit Transceiver (MGT)的系列页面中的第二页。
介绍
Multi-Gigabit transceivers (MGTs)是许多著名协议的基本组成部分: PCIe、 SATA、 Gigabit Ethernet、 SuperSpeed USB、 Thunderbolt 和 Displayport。所有这些协议都有一个共同点: 其中涉及一台计算机。还有几台用于电信的协议,用于通过光纤链路传输电话呼叫。
MGTs 还可用于在两 FPGAs之间交换数据。上一页列出了使用 MGT 进行此目的时需要注意的一些事项。显然,需要某种协议来确保数据在物理通道上正确传输且具有可接受的可靠性。这种协议的实现相当复杂,因此问题是是否有现成的协议或其他可以提供帮助的构建块。
本页试图总结主要的替代方案。它们按照应用逻辑的复杂程度列在下面,最不复杂的列在最前面。
除非另有说明,以下所有协议均可作为双向链路(全双工)以及单向链路(半双工)工作。
Xillyp2p
Xillyp2p是专有的协议,可在两 FPGAs之间可靠地传输多个数据流。协议管理应用程序数据的传输、调度、重传以及硬件流控制（flow control）,其方式与 TCP/IP 协议通过网络传输数据的方式类似: 保证所有数据正确到达对方。
应用逻辑通过标准 FIFOs与协议的实现进行交互。协议营造出标准 FIFO 的假象,并跨越两 FPGAs: 这个虚拟的 FIFO的写入端在一 FPGA上,读取端在另一 FPGA上。
在两 FPGAs中, FIFO 的一侧连接到应用逻辑,而另一侧与协议的逻辑交互。因此,发送方的应用逻辑将数据写入 FIFO ,而接收方的应用逻辑从另一 FIFO读取数据。协议负责将数据从发送方 FPGA 上的 FIFO 移动到接收方 FPGA上的 FIFO 。协议的流量控制可确保目标 FPGA 上的 FIFO 永远不会满。
协议可以双向为多 FIFOs 提供服务。公平的数据传输调度程序可确保高效利用 MGT的带宽。发送方 FIFO 中的数据很快就会被消耗掉,因此这 FIFO 不会变满(只要带宽允许并且数据是从另一侧的 FIFO 消耗的)。
协议还具有不同的传输数据包的接口(在 EOP 端口的帮助下)。
还支持半双工选项。在这种情况下,协议确保所有到达的数据都是正确的。如果物理通道上发生位错误,则在错误数据到达应用逻辑之前数据流会停止。
Gigabit Ethernet
尽管 Gigabit Ethernet 旨在用于计算机之间的通信,但可以使用这个简单的协议在两 FPGAs之间发送数据包。 FPGA 制造商通常会提供合适的 IP 。因此,应用逻辑负责通过标准接口之一(GMII、 RGMII、 XGMII 等)创建和接收 Ethernet 数据包。
与任何 Ethernet 链路一样,应用逻辑的作用是将数据组织成数据包,以及处理链路上的错误(例如重传)。
Interlaken
Interlaken 是协议的一个开放版本,用于芯片之间的数据包通信。它基于64b/67b 编码: 底层数据流由重复发送的 64 比特数据段组成。在每个数据段之前,都会添加 3 比特以区分应用数据和控制字。协议是为 simplex link (单向物理通道)定义的。如果使用 full duplex link (双向物理通道),其工作方式与 simplex link相同,只是硬件流控制消息可以沿相反方向发送。
协议的基本传输单元是长度可变的突发。在每个这样的突发之前和之后立即传输一个控制字。这两个控制字包含允许抽象数据包和通道的信息。其中包括:
- 频道编号: 一个介于 0 和 255 之间的数字,用于将后续的数据突发与某个通道关联起来。通道数量最多可扩展至 65536 个。
- SOP： 表示接下来的数据是数据包（packet）的开始的标志。
- EOP： 数据包标志位指示控制字之前的字节是否为数据包的最后一个数据。 EOP 标志位还指示突发传输最后一个字中的有效字节数,以及数据包是否包含错误。
每个脉冲串的长度不得超过 BurstMax ,也不得短于 BurstShort。 BurstMax 和 BurstShort 均为根据特定应用选择的参数。 BurstShort 至少为 32 字节(且必须是 8 的倍数), BurstMax 必须是 64 字节的倍数。
使用 CRC24检查控制字的内容和(可能)之前出现的数据突发是否存在位错误。
如果突发数据未能通过 CRC24 测试(即检测到比特错误),则可以按照 Interlaken Retransmit Extension Protocol Definition的定义请求重传。根据建议的机制,此请求通过接收器到发射器的三条物理线路发送。这些线路分别命名为 FC_CLK、 FC_DATA 和 FC_SYNC,最初是为 out-of-band flow control (OOBFC)设计的。硬件流控制请求的发送定义了一个简单的串行数据传输协议。如果启用了重传,则其中一个比特被称为“RT”,用于请求重传。换句话说,协议并没有定义在 MGT 链路本身上发送重传请求的方法,而是通过三条独立的带外物理线路发送。
重传请求不包含从哪个突发数据开始重传的信息。相反,发送方需要在缓冲区中保存一定量的突发数据。当收到重传请求时,缓冲区中的所有突发数据都会被重传。因此,缓冲区的大小需要足够大,以容纳丢失的突发数据。但是,如果缓冲区过大,重传时间将会过长。为了确定缓冲区的大小,需要仔细计算从发送突发数据到实现 Interlaken 协议的逻辑电路,再到收到重传请求之间的往返时间。
接收器利用一个计数器来检测重传的突发脉冲,该计数器在每次首次发送突发脉冲时递增(也可以每发送 2、4、8 等突发脉冲递增一次)。该计数器的值包含在每次突发脉冲前后发送的控制字的 Multiple-Use 部分中。接收器利用该计数器来区分新发送的突发脉冲和重传的突发脉冲。
Interlaken 协议还包含一个用于诊断目的的 CRC32 检查(每 Meta Frame检查对应一次)。但是,如果通过此测试检测到错误,则该错误与大段数据相关,而不是与特定的突发传输或数据包检查相关。换句话说,如果数据在比特错误（bit error）检查中通过了 CRC24 检查,则只能在稍后才能检测到该错误,并且无法指出包含错误数据的突发传输。
可以设计并实现一种基于 MGT反向数据流的重传机制。 Interlaken 协议没有提供此类重传机制的方法,但仍然可以为其分配一个专用通道,供数据包请求重传。这种方案具有显著优势,因为它允许更具体地指定要重传的内容。也可以应用更完善的 CRC机制,或许可以在数据包上实现,而不是采用突发传输。但是,如果采用这种方法,则整个机制必须在应用逻辑中实现。
Interlaken的硬件流控制机制在单独的页面上讨论。
Aurora
Aurora 是 Xilinx (现为 AMD)为其自身的 FPGAs开发的协议版本。协议的基本传输单元是一个字(字长固定,取决于参与传输的 MGTs 的数量)。然而,协议也支持传输数据包(称为 frames)。应用逻辑借助 "last" input 端口将数据流分割成数据包段。
Aurora有两种变体: 使用8b/10b 编码和64b/66b 编码。 64b/66b 编码效率更高,因此在可能的情况下应优先考虑此变体。
Aurora 既适用于 simplex link (单向物理信道),也适用于 full duplex link (双向物理信道)。从应用逻辑的角度来看,这两种选项之间没有显著区别,只是硬件流控制在 simplex link上没有意义。
请注意,与 Interlaken不同, Aurora 协议没有提及任何 channels。换句话说,通过物理信道传输的所有数据都属于同一个数据流。当协议中使用“channel”时,指的是物理信道,而不是将数据划分为独立的数据流。如果需要进行数据划分,则由应用逻辑来实现,可以通过在每个数据包（packet）中添加一 header 来实现。
物理信道上的比特错误错误不会被协议纠正。但是,当使用协议发送数据包时,发送方可以选择在每个数据包的末尾附加一 CRC (在 Xilinx对协议的实现中)。接收方的协议实现会检查这 CRC ,如果检测到数据包错误,则会通知应用逻辑。如果使用 Aurora 而没有数据包(即没有 "last" 信号),则协议不支持错误检测。
协议自身的控制信息在传输过程中未采取任何针对比特错误的保护措施。此类流量中不存在 CRC 。如果物理链路上存在比特错误,则协议可能会出现各种故障。
任何重传机制、多信道复用和传输调度都必须由应用逻辑实现。另有一页讨论了使用 Aurora实现硬件流控制的可能性。
Serial Lite
Altera 有一系列协议和 IP cores ,它们共享名称 Serial Lite:
- SerialLite II： 用于接收和发送数据的基于数据包或非数据包的接口(称为“Atlantic Interface”)。支持位错误重传。仅适用于早期的 FPGAs (范围从 Arria II 到 series-V FPGAs)。
- Serial Lite III： 支持连续和突发模式。在连续模式下,数据流可以不间断地流动,发送器和接收器之间没有间隙。这要求双方都依赖相同的参考时钟（reference clock）。此协议在内部基于 Interlaken,但不支持通道或 SOP/EOP。因此,接口的数据宽度是 64 比特乘以所用 MGTs 的数量。物理链路上的位错误被报告为与导致它们的 MGT 相关的诊断事件,但不与特定数据段相关。适用于 series-V FPGAs 和 series-10 FPGAs。
- Serial Lite IV： 基于 Avalon streaming 接口,带有数据包开始和结束信号 (MAC)。发送器可选择在数据包末尾插入 CRC ,并由接收器检查。还有基本模式,无需划分数据包。适用于 Stratix 10 和 Agilex E-tile。
IP cores 与协议系列的不同成员不兼容。只有 SerialLite II 可以发起重传。
RapidIO
RapidIO是一种基于数据包的协议,它与PCIe类似,因为它支持的数据包类型与 CPU所需的操作相对应,其中包括:
- 写: 将数据写入地址（address）。此操作有几种变体,其中一种需要响应指示操作已完成。
- 读: 从地址读取数据的请求。目标会针对此请求发送响应数据包。
- 原子读取-修改-写入: 请求在读取前一个值后将数据写入地址,这是一项原子操作。支持的操作包括: Atomic increment 和 atomic decrement, atomic swap, compare and swap 等。
- 几个用于发现、控制和状态的维护请求。与 PCI 协议的 configuration register space类似,这些维护请求访问 registers capability registers (CAR) 和 command and status registers (CSR)。
RapidIO 和 PCIe 之间的主要功能差异在于, PCIe 协议需要中央单元( Root Complex,通常是 CPU)配置系统中的所有端点。 RapioIO 系统不需要这种中央单元。
与 PCIe 的另一个区别是数据包的重传是可选的。仅当数据包以“reliable traffic”(RT)的形式发送时才会重传。数据包也可以以“continuous traffic”(CT)的形式发送。此类数据包既不被确认也不被重传。
RapidIO 协议定义了通信的所有方面,从电气规范到数据包格式、重传和流量控制。
由于协议的复杂性,RapidIO 可能不是两 FPGAs之间简单的点对点连接的理想选择。 RapidIO 可能更适合通过 switch连接多 FPGAs ,特别是如果 PCIe 不适合,因为系统中需要 CPU 。
概括
介绍了几种用于传输应用数据的协议。每种协议都提供了不同的数据传输、控制流量和响应位错误(如果有的话)的方法。适合应用的正确协议是在协议提供的功能与实现应用逻辑中缺失部分所需的努力之间取得平衡。