TLP元素与PCIE数据流

不同于并行总线，PCIe 这样的串行总线不使用总线上的控制信号来表示某时刻链路上正在发生什么。相反地，PCIe 链路上的发送方发出的比特流必须要有一个预期的大小，还要有一个可供接收方辨认的格式，这样接收方才能理解比特流的内容。此外，PCIe 在传输数据包时并不使用任何直接握手机制（immediate handshake）。

除了逻辑空闲符号（Logical Idle symbol）和 Ordered Set 的物理层包外，在活跃的 PCIe 链路上传输的信息的基本组块被称为 Packet（包），包是由符号组成的。链路上交换的两类主要的数据包为高层的 TLP（Transaction Layer Packet，事务层包），和低层的用于链路维护的包称为 DLLP（Data Link Layer Packet，数据链路层包）。这些包和它们的传输流如图 5‑1 所示。物理层的 Ordered Set 也是一种包，但是它并不像 TLP 和 DLLP 一样会被封装上包起始符号和包结束符号（也就是前面章节所讲的组帧符号），并且 Ordered Set 也并没有像 TLP 和 DLLP 一样的字节条带化过程，相反地，Ordered Set 会在链路的每个通道（lane）上都复制一份，而不是像字节条带化一样把信息按字节分配到各个通道上。

图 5‑1 TLP 和 DLLP 包

5.1.2 使用基于数据包协议的动机

使用基于包的协议（Packet-Based Protocol）有三个明显的优点，特别是对于数据完整性（data integrity）来说：

5.1.2.1 精心定义的数据包格式

像 PCI 这种早期的总线，它们允许总线上不确定数据量大小的传输，这使得只要传输没有结束就无法识别出数据荷载（payload）的边界。此外，任何一个设备都可以在此次传输完成前终止这个传输，这使得发送方很难去计算并传输一个覆盖了整个数据荷载的校验和或者 CRC。相反地，PCI 使用了一种简单的奇偶校验的方案，并在每个数据阶段（data phase）进行奇偶校验。（这里如果没理解请参阅 Chapter 1 内的 PCI 相关内容）

相比之下，PCIe 包具有一个已知的大小和格式。位于包的开头的部分为 Header，它用来指示这个包的类型，并包含了必需字段（required field）和可选字段（optional field）。除了地址字段以外，Header 中的其他字段长度都是固定的，地址字段可以为 32bit 也可以为 64bit。一旦一次传输开始，接收方不能暂停或者提前终止它。这种结构化的格式使得我们可以在 TLP 中加入一些信息来更有利于进行可靠的传输，例如加入组帧符号（framing symbol）、CRC、以及一个包的序列号（Sequence Number）。

5.1.2.2 使用组帧符号定义包的边界

在 PCIe Gen1 和 Gen2 操作模式中使用的是 8b/10b 编码，因此在这 Gen1 和 Gen2 中每个 TLP 和 DLLP 在发送前都会使用起始符号（Start）和结束符号（End）这两种控制符号来进行组帧，这样就可以给接收方清晰地定义出包的边界。这是在 PCI 和 PCI-X 上的重大改进，在 PCI 和 PCI-X 中使用一个单独的 FRAME# 信号来指示一个事务的开始和结束，如果 FRAME# 出现了毛刺，或者其他的控制信号出现了毛刺，那么都有可能造成目标设备对总线行为的误解。一个 PCIe 接收方必须在最后的链路活动开始或结束之前，就正确完成一个完整 10bit 符号的译码，这样接收方能更容易识别不期望出现或者无法识别的符号，并且将其作为一个错误来处理。

对于 PCIe Gen3 使用的 128b/130b 编码来说，控制字符不再被使用，并且也没有组帧符号了。对于更多的关于 Gen3 编码与早期版本的差异的内容，请参阅 Chapter 12“Physical Layer-Logical（Gen3）”。

5.1.2.3 使用 CRC 保障整个数据包的正确传输

在 PCI 体系结构中，会在地址阶段（address phase）和数据阶段（data phase）中使用奇偶校验边带（side-band）信号，但是在 PCIe 中则不同。PCIe 中使用带内（in-band）的 CRC 值来验证整个数据包是否进行了无错误的传输。同时 TLP 还会被发送方的数据链路层添加上一个序列号（Sequence Number），这使得当这个序列号的数据包传输出错时可以很简单的定位到它，并进行自动的重传。发送方会在自己的 Retry Buffer 内保存每个 TLP 的一个副本，直到接收方确认了这个 TLP 成功无错传输后才会将副本清除。这种 TLP 的确认机制被称为 Ack/Nak 协议（更多内容请参阅 Chapter 10 “Ack/Nak Protocol” ），它用来形成基础的链路级 TLP 错误检测和纠正机制。这种 Ack/Nak 协议提供的错误恢复机制使得我们可以在问题发生的地方或者链路上及时的解决问题，但是这也要求有一个本地的硬件解决方案来支持这种协议。

5.2 TLP 细节（TLP Details）

在 PCIe 中，高层次事务起源于发送方的 Device Core，终止于接收方的 Device Core。事务层会处理这些请求，其中，发送端的事务层组装 TLP，接收端的事务层解析 TLP。在这个过程中，每个设备的数据链路层和物理层也会参与包的组装。

5.2.1 TLP 的组包和拆包

如图 5‑2 所示的是链路的发送端组装 TLP 和接收端拆解 TLP 的一般流程。现在让我们讲一讲从一个包的生成，到它被传送到接收端的 Device Core 的各个步骤。下面列出了 TLP 组包和拆包的关键阶段，列出的编号与图 5‑2 中的编号相对应。

图 5‑2 PCIe TLP 的组包与拆包

发送方

1. 设备 A 的 Device Core 向它的 PCIe 接口发送一个请求（具体 Device Core 是如何给 PCIe 接口发送请求的，这并不是 PCIe 协议或者本书的讨论范畴）。这个请求中包括：

• 目标地址或者 ID（也就是路由信息）

• 源端信息，例如 Requester ID 和 Tag

• 事务类型/数据包类型（需要执行的命令，例如一个内存读取 MRd）

• 数据荷载大小 payload size 和数据荷载内容（如果 TLP 需要带数据）

• 流量类型（Traffic Class，用于分配数据包的优先级）

• 请求的自身属性（No Snoop 无窥探、Relaxed Ordering 宽松排序，等等）

2. 基于这个请求，事务层将会组建 TLP Header，并在其后附上数据荷载（如果有），以及如果启用并支持可选项的话也可以再附上 ECRC（End-to-End CRC）。随后 TLP 就会被放入一个虚拟通道 Buffer。这个虚拟通道会根据事务排序规则来管理 TLP 的顺序，并在向下转发 TLP 到数据链路层之前，确认接收方有足够的 Buffer 来接收一个 TLP。

3. 当 TLP 到达数据链路层，它会被分配一个序列号（Sequence Number），并基于 TLP 的内容和序列号来计算出一个 LCRC（Link CRC）来附加在原 TLP 后。然后会将经过这些处理过程之后的 TLP 保存一个副本，这个副本会保存在数据链路层的重传 Buffer（Replay Buffer，也可称为 Retry Buffer）中，这是为了应对传输出错的情况。与此同时，这个 TLP 也会被向下转发至物理层。

4. 物理层将会进行一系列的操作来准备对这个数据包进行串行传输，包括字节条带化（Byte Striping）、扰码（Scrambling）、编码（Encoding）以及并串转换（Serializing）。对于 Gen1 和 Gen2 的设备，当进行 8b/10b 编码时，会将 STP 和 END 这两个控制字符分别加在 TLP 的首端和尾端。最后，这个数据包通过链路进行传输。在 Gen3 操作模式中，STP 令牌（STP token）会被添加在 TLP 的首端，但是并不会在尾端加上 END，而是在 STP 令牌中包含 TLP 大小的信息来判断 TLP 的尾部位置。

接收方

5. 在接收方（本例中是 Device B），为了发送包所做的一切准备现在都必须撤销。物理层将对比特流进行串并转换（deserialize）、对串并转换后的符号进行解码，然后再进行字节反条带化（un-stripes）。控制字符将被移除，因为它们仅在物理层有意义，然后这个数据包就会被向上转发至数据链路层。

6. 数据链路层将会计算 CRC（具体一点是 LCRC）并与 TLP 中的 CRC 进行比较。如果 CRC 比较结果相同，那么就再检查序列号（Sequence Number）。如果都没有出现错误，那就把 CRC 和序列号都从 TLP 剥除，并随后将 TLP 向上转发给接收方事务层，与此同时要通过返回给发送方一个 Ack DLLP 来通知发送方这个 TLP 被成功接收。相反地，如果前面的过程中检查出了错误，那么就要返回给发送方一个 Nak DLLP，这样发送方将会使用它的重传 Buffer 来对 TLP 进行重传。

7. 在事务层，TLP 被进行解码，并将 TLP 内的信息传递给 Device Core 来进行相应的操作。如果当前接收设备就是数据包的最终目的地，那么它可以检查 ECRC 错误，并在发现任何 ECRC 错误时报告给 Device Core。

5.2.2 TLP 结构

一个事务层包 TLP 中每个字段域的基本用法在表 5‑1 中进行了定义。

表 5‑1 TLP Header 的 Type 字段定义了事务不同种类

下面对表 5‑1 中的内容进行复述。

• Header

• 协议层次：事务层

• 该组件用法：大小为 3 或 4DW（12 或 16Bytes）。Header 的格式会随类型而变化，但是 Header 也定义了一些参数，包括：

  • 事务类型（Transaction Type）

  • 目标地址、ID 等

  • 传输数据量大小（如果有数据）、字节使能（Byte Enable）

  • 属性（Attribute）

  • 流量类型（Traffic Class）

• Data

• 协议层次：事务层

• 该组件用法：可选的 1-1024DW 大小的数据荷载，具体的大小由字节使能或者字节对齐的开始和结束地址来进行描述。需要注意指定的长度不能为 0，但是一个 0 长度的读取可以通过指定长度为 1DW 然后将字节使能全部置为 0 来进行近似处理（在某些情况下会使用）。来自 Completer 的结果数据虽然是未定义的种类，但是 Requester 并不使用它，因此就和指定 0 长度的目的等效了。

• Digest/ECRC

• 协议层次：事务层

• 该组件用法：可选的功能。当需要使用时，ECRC 的大小永远为 1DW。

5.2.3 通用 TLP Header 格式（Generic TLP Header Format）

5.2.3.1 概括（General）

如图 5‑3 中，展示了一个 4DW 的通用 TLP Header 的格式和内容。在本节内，会对几乎所有事务的 TLP Header 中的公共字段进行总结，并会在稍后讨论与特定事务类型相关 Header 格式差异。

图 5‑3 通用 TLP Header 的各字段域

5.2.3.2 通用 Header 各字段摘要

表 5‑2 中对通用 TLP Header 中的每个字段的大小和用途进行了总结。需要注意的是，在图 5‑3 中被标注为“R”的字段是保留字段（reserve），应该被置为 0。