本页是介绍多吉比特收发器(MGT)的系列文章中的第二篇。
简介
多吉比特收发器(MGT)是许多常见协议的基础构建模块:PCIe、SATA、千兆以太网、SuperSpeed USB、Thunderbolt 和 DisplayPort。这些协议都有一个共同点:都涉及计算机。还有一些用于电信领域的协议,目的是通过光纤链路传输电话语音。
MGT 也可用于在两片 FPGA 之间交换数据。关于这种用途需要注意的几点已经列在上一页。显然,需要某种协议来确保数据在物理信道上以可接受的可靠性正确传输。实现这样的协议相当复杂,所以问题是:是否有现成的协议或其他构建模块可以帮忙。
本页试图概括主要可选方案。下面按应用逻辑的复杂程度从低到高列出。
除非另有说明,下面的所有协议既可以用于双向链路(全双工),也可以用于单向链路(半双工)。
Xillyp2p
Xillyp2p 是一种专有协议,可在两片 FPGA 之间可靠地传输多个数据流。该协议管理数据流的发送、调度、重传和流量控制(flow control),类似于 TCP/IP 协议通过网络传输数据的方式:所有数据都能保证正确到达对端。
应用逻辑通过标准 FIFO 与协议的实现进行交互。该协议在两片 FPGA 之间营造出一个贯穿两端的标准 FIFO 效果:这个虚拟 FIFO 的写入端位于一片 FPGA 上,读取端位于另一片 FPGA 上。
在这两片 FPGA 中,FIFO 的一侧连接到应用逻辑,另一侧与协议逻辑交互。因此,发送端的应用逻辑把数据写入一个 FIFO,接收端的应用逻辑则从另一个 FIFO 读取数据。协议负责把数据从发送端 FPGA 上的 FIFO 搬到接收端 FPGA 的 FIFO 中。协议通过流量控制确保目的端 FPGA 上的 FIFO 永远不会变成 full(满)。
该协议可在两个方向上同时服务多个 FIFO。公平的数据发送调度器可确保 MGT 的带宽得到有效利用。发送端 FIFO 中的数据会及时被取走,因此只要带宽允许,并且对端持续从 FIFO 中读取数据,这个 FIFO 就不会变成 full(满)。
该协议还提供了一种专门用于发送数据包的接口(借助 EOP 端口)。
该协议还支持半双工模式。在此模式下,协议保证到达的数据都是正确的。如果物理信道发生比特错误,数据流会在错误数据到达应用逻辑之前停下。
千兆以太网
尽管千兆以太网是面向计算机之间通信的,但这个简单协议也可以用于在两片 FPGA 之间发送数据包。FPGA 厂商通常会提供合适的 IP 核(IP core)。这样,应用逻辑就负责通过某种标准接口(GMII、RGMII、XGMII 等)来构造和接收以太网数据包。
与任何以太网链路一样,把数据组织成数据包以及处理链路错误(例如通过重传)也是应用逻辑的职责。
Interlaken
Interlaken 是一种开放协议,用于在芯片之间传输数据包。它基于64b/67b 编码:底层数据流由不断重复的 64 位数据段构成。在每段之前,会额外添加 3 个比特,用来区分应用数据和控制字。该协议定义的是单工链路(单向物理信道)。如果使用全双工链路(双向物理信道),其工作方式与单工相同,差别仅在于流量控制消息可以沿相反方向发送。
该协议的基本传输单元是长度可变的突发(burst)。在每个突发之前和之后各发送一个控制字(control word)。这两个控制字中包含的信息允许上层对数据包和信道进行抽象。这些信息包括:
- 信道编号:一个介于 0 和 255 之间的数字,用于把随后的突发关联到某个信道。信道的数量最多可以扩展到 65536。
- SOP:一个标志位,表示随后传输的数据是一个数据包的开头。
- EOP:一个标志位,表示该控制字之前的数据包,其最后一个数据已经由那个突发传输完毕。EOP 还指示突发最后一个字中有效字节的数量,以及该数据包是否包含错误。
每个突发的长度既不能超过 BurstMax,也不能小于 BurstShort。BurstMax 和 BurstShort 都是根据具体应用选择的参数。BurstShort 至少为 32 字节(并且必须是 8 的倍数),BurstMax 必须是 64 字节的倍数。
CRC24 会对控制字及其前面(可能存在的)数据突发的内容进行校验,以检测比特错误。
如果某个突发未通过 CRC24 校验(即检测到比特错误),可以按照Interlaken 重传扩展协议定义中的规定请求重传。根据其建议的机制,该请求通过从接收端到发送端的 3 根物理导线发送。这三根导线分别叫作 FC_CLK、FC_DATA 和 FC_SYNC,本来是为带外流量控制(OOBFC)设计的。协议定义了在这些导线上发送流量控制请求的简单串行数据传输协议。如果启用了重传,其中一个比特被称为“RT”,用于请求重传。换句话说,该协议并没有定义在 MGT 链路上发送重传请求的方式,而是使用 3 根独立的带外物理导线。
重传请求并不包含应从哪个突发开始重传的信息。相反,协议要求发送端在缓冲区中保存一定量的突发数据。当收到重传请求时,缓冲区中的所有突发都会被重新发送。因此,缓冲区的大小必须足以容纳可能因故丢失的那个突发。但如果缓冲区太大,重传就会比实际需要的更长。为了确定缓冲区大小,需要仔细计算从把突发交给实现 Interlaken 协议的逻辑开始,到收到重传请求为止的往返时间。
接收端借助一个计数器来识别重传的突发:每发送一个新突发,该计数器就加 1(也可以每发送 2、4、8 等个突发加 1)。计数器的值放在每个突发前后控制字的 Multiple-Use 字段中传输。接收端用这个计数器来区分一个新突发和一个重传的突发。
Interlaken 协议还有一个用于诊断目的的 CRC32 校验(每个 Meta Frame 做一次)。然而,如果通过这种校验发现错误,那么它对应的是一个较大的数据段,而不是某个特定的突发或数据包。换句话说,如果数据虽然包含比特错误却仍然通过了 CRC24 校验,那么错误只能更晚被发现,而且无法指出究竟是哪一个突发包含错误数据。
可以自行设计一种基于反向 MGT 数据流的重传机制。Interlaken 协议并没有给出这种重传机制的建议,但你仍然可以为请求重传的数据包分配一个专用信道。这种方案可能带来明显优势,因为它能更精确地要求重传哪些内容。也可以使用更好的 CRC,甚至可以针对数据包而不是突发做校验。不过,如果采用这种思路,整套机制都必须由应用逻辑来实现。
Interlaken 的流量控制机制将在另一页中讨论。
Aurora
Aurora 是 Xilinx(现为 AMD)为其自家 FPGA 开发的一种协议。该协议的基本传输单元是一个字(宽度固定,取决于所使用 MGT 的数量)。同时,它也支持以数据包为单位进行传输(这种数据包称为帧,frame)。应用逻辑借助一个“last”输入端口把数据流分割成数据包。
Aurora 有两种变体:一种是基于8b/10b 编码,另一种是基于64b/66b 编码。64b/66b 编码效率更高,因此在条件允许时应优先选择这一种。
Aurora 可以用于单工链路(单向物理信道),也可以用于全双工链路(双向物理信道)。从应用逻辑的角度看,这两种方式没有显著区别,只是流量控制在单工链路上没有意义。
请注意,与 Interlaken 不同,Aurora 协议并没有涉及“信道”的概念。也就是说,通过物理信道传输的所有数据都属于同一个数据流。协议里用到“信道”一词时,指的是物理信道本身,而不是把数据划分成多个独立的数据流。如果你希望做这种划分,就需要由应用逻辑来实现,比如给每个数据包增加一个头部。
协议不会纠正物理信道上的比特错误。不过,当使用该协议传输数据包时,发送端可以选择在每个数据包的末尾附加一个 CRC(这是 Xilinx 对协议的一种实现)。在接收端,协议的实现会检查这个 CRC,并通知应用逻辑该数据包是否检测到错误。如果 Aurora 不按数据包方式使用(没有“last”信号),则该协议不支持差错检测。
协议自身的控制信息在传输时没有任何差错保护,也没有针对这类信息的 CRC。如果物理链路上存在比特错误,协议可能会出现各种各样的故障。
任何重传机制、多信道复用以及发送调度,都必须由应用逻辑自己实现。另一页讨论了使用 Aurora 实现流量控制的可能性。
Serial Lite
Altera 有一系列共享 Serial Lite 名称的协议和 IP 核:
- SerialLite II:基于数据包或非数据包的收发数据接口(名为 Atlantic Interface)。支持针对比特错误的重传。仅适用于早期 FPGA(从 Arria II 到系列 V 的 FPGA)。
- Serial Lite III:支持连续模式(Continuous)和突发模式(Burst)。在连续模式下,数据流可以在发送端和接收端之间不间断、无间隙地流动。这要求双方使用同一个参考时钟。该协议在内部基于 Interlaken,但不支持信道,也不支持 SOP/EOP。因此,接口的数据位宽是 64 位乘以所用 MGT 的数量。物理链路上的比特错误会作为诊断事件上报,并与引发错误的 MGT 对应,而不是与某个特定数据段挂钩。适用于系列 V FPGA 和系列 10 FPGA。
- Serial Lite IV:基于 Avalon 流接口(Avalon streaming interface),并带有用于指示数据包开始和结束的信号(MAC)。发送端可以选择在数据包末尾插入 CRC,并由接收端进行检查。还有一种 Basic 模式,不划分数据包。适用于 Stratix 10 和 Agilex E-tile。
这一系列协议中的各个 IP 核并不互相兼容。只有 SerialLite II 能够发起重传。
RapidIO
RapidIO 是一种基于数据包的协议,它在某种意义上与 PCIe 相似:它所支持的数据包类型与 CPU 所需的操作相对应。这些操作包括:
- 写操作(Write):向某个地址写入数据。该操作有几种变体,其中一种要求对方返回一个“操作已经完成”的响应。
- 读操作(Read):请求从某个地址读取数据。目标端会向这个请求发送一个响应数据包。
- 原子读-改-写(Atomic read-modify-write):作为一种原子操作,先读取某个地址的旧值,再把新数据写入该地址。支持的操作包括:原子加一(atomic increment)和原子减一(atomic decrement)、原子交换(atomic swap)、比较并交换(compare and swap)等。
- 还有一些用于发现、控制和状态查询的维护请求。与 PCI 协议中的配置寄存器空间类似,这些维护请求会访问能力寄存器(Capability Register,CAR)以及命令和状态寄存器(Command and Status Register,CSR)。
RapidIO 与 PCIe 之间最主要的区别在于:PCIe 协议要求由一个中心单元(Root Complex,通常是一颗 CPU)来配置系统中的所有端点设备。而 RapidIO 系统则不需要这样的中心单元。
另一个与 PCIe 的不同之处是,数据包的重传是可选的。只有以“可靠流量”(Reliable Traffic,RT)方式发送的数据包才会被重传。数据包也可以以“连续流量”(Continuous Traffic,CT)方式发送,这类数据包既不会得到确认,也不会被重传。
RapidIO 协议完整定义了从电气规范到数据包格式、重传机制和流量控制在内的所有通信环节。
对于两片 FPGA 之间的简单点对点连接来说,RapidIO 可能不是一个有吸引力的选择,因为该协议比较复杂。RapidIO 更适合通过交换芯片(switch)在多个 FPGA 之间做互连,尤其是在 PCIe 因为系统中需要一颗 CPU 而不适用的情况下。
总结
前面介绍了几种用于传输应用数据的协议。每种协议都采用不同的方式来实现数据传输、控制数据流以及应对比特错误(如果有这一能力的话)。为某个应用选择哪种协议,其实是在协议自带的功能与在应用逻辑中实现缺失部分所需的努力之间做平衡。