《PCI Express Technology 3.0 》Chapter 5 第3 节

5.2.5 具体的 TLP 格式：请求 TLP 和完成 TLP

在本节中，将会描述用来构成具体的一些事物类型的 TLP 3DW Header 和 4DW Header。许多通用的字段就如前文所述，因此我们把重点放在那些需要根据具体事务类型进行具体处理的字段上。接下来的几个小节是关于 TLP Header 的详细描述，相关的 TLP 类型为：1）IO Request，2）Memory Requests，3）Configuration Requests，4）Completions，以及 5）Message Request。

5.2.5.1 IO 请求（IO Request）

虽然协议中不鼓励使用 IO 事务，但是对于传统遗留设备还是允许的，并且对于软件来说需要通过 IO 事务来兼容那些存在系统 IO 映射而不是内存映射的设备。虽然 IO 事务从技术上讲是可以访问 32bit IO 范围的，但是实际上许多系统（和 CPU）都会将 IO 访问限制在低 16bit（64KB）范围内。图 5‑6 展示了系统 IO 映射以及 16bit 和 32bit 地址边界。自身不是传统遗留设备的设备是不允许访问 BAR 中的 IO 地址空间的。

图 5‑6 系统 IO 映射

l、 IO Request Header 的格式

如图 5‑7 所示是一个 3DW IO Request Header，其中的每个字段都会在接下来的内容中进行描述。

图 5‑7 3DW IO Request Header 格式

l、 IO Request Header 各字段

一个 IO Request Header 中的每个字段的位置和作用都在表 5‑4 中进行了描述。

表 5‑4 IO Request Header 各字段

5.2.5.2 Memory 请求（Memory Request）

PCIe 的 Memory 事务包含两种类型：第一种是读请求及其相对应的完成包，第二种是写请求。系统内存映射如所示，展示了 3DW 与 4DW 的 Memory 请求包。需要记住协议规范中多次重申的一点，Memory 传输绝对不允许跨 4KB 地址边界。

图 5‑8 3DW 和 4DW 的 Memory Request Header 格式

l、Memory Request Header 各字段

一个 4DW 的 Memory Request Header 中的每个字段的位置和作用都在表 5‑5 中进行了描述。注意，3DW 和 4DW Header 的区别仅仅是起始地址字段的位置和字段大小不同。

表 5‑5 4DW Memory Request Header 各字段

l、 Memory Request 注意事项

Memory 请求的特性包括：

1. Memory 数据传输不允许跨 4KB 边界。
2. 所有的内存映射写（Memory-Mapped Write）都是 Posted 的，以此来提升性能。
3. 使用 32bit 或者 64bit 地址方式。
4. 数据荷载大小在 0-1024DW 之间（0-4KB）。
5. QoS（Quality of Service）特性可以被使用，最多可以有 8 个流量类型。
6. No Snoop 属性可以在事务访问主存时，用来减轻系统对窥探处理器 Cache 的需求。
7. Relaxed Ordering 属性可以使得数据包传输路径上的设备对这个 TLP 使用宽松排序规则，以此来提升性能。

5.2.5.3 Configuration 请求（Configuration Request）

PCIe 像 PCI 一样使用 Type 0 和 Type 1 配置请求，以此来保持向后兼容性。一个 Type 1 配置请求会向下行传播，直到一个 Bridge 的次级总线（Secondary Bus）正好是这个 Type 1 配置请求的目标总线，在这时这个 Bridge 就会把这个配置事务从 Type 1 转换为 Type 0。Bridge 是通过此前编程写入的总线号寄存器来得知何时应该对配置事务进行 Type 转换以及继续转发，其中总线号寄存器包括主总线号（Primary Bus Number）、次级总线号（Secondary Bus Number）以及从属总线号（Subordinate Bus Number）。关于这里的更多内容，请参阅“传统 PCI 机制（Legacy PCI Mechanism）”一节。

如图 5‑9 中，一个 Type 1 配置请求正在按照规则向下行移动，它在 Switch 左侧的下行端口的 Bridge 被转换成 Type 0，这种转换是通过改变 TLP Header 中的 Type 字段 Bit 0 来完成的（Type 从 0 0101b 变为 0 0100b）。注意，不同于 PCI，PCIe 中下行的一条链路上只能由一个设备，因此链路上不需要有 IDSEL 或者其他指示信号来告诉设备需要声明自己占有 Type 0 配置请求，也就是说设备只要从上行收到了 Type 0 配置请求，就知道这个配置请求的目标设备就必然是自己。

图 5‑9 3DW 配置请求以及 Header 格式

l、 Configuration Request Header 各字段的定义

图 5‑9 中展示的 Configuration Request Header 中的每个字段的位置和作用都在表 5‑6 中进行了描述。

表 5‑6 配置请求 Header 各字段

l、 Configuration Request 注意事项

配置请求的 Header 总为 3DW 格式，路由信息为 Bus Number、Device Number 和 Function Number。所有的设备都会在接收到一个 Type 0 配置写请求时从请求包中捕获出它们自己的 Bus Number 和 Device Number。之所以这样，是因为这些设备之后会用自己捕获到的 Type 0 配置写中的 Bus Number 和 Device Number 来作为 Requester ID，用来在以后发起请求时使用。

5.2.5.4 完成包（Completion）

Completion（完成包）是用来响应 Non-Posted 请求的，除非有错误阻止了发送完成包。例如，Memory、IO、Configuration Read 请求通常就是由带有数据的完成包来响应。另一方面，IO 或者 Configuration 写请求通常也由无数据的完成包来响应，这种情况下的完成包仅仅是用来报告事务的状态。

在完成包中的许多字段的值，都与它相关的请求包中的字段相同，包括 TC（Traffic Class，流量类型）、Attr（Attribute，属性）以及 Requester ID（请求者 ID，用来将完成包路由回到请求者去）。图 5‑10 中展示了一个响应 Non-Posted 请求的完成包，并且还展示了这个完成包的 3DW Header。在正常操作中，Completer ID 并没有什么额外的用处，但若是在系统调试期间能够知道完成包从哪里来，那么这对错误的诊断就有较大的帮助。

图 5‑10 3DW 完成包 Header 格式

l、 Completion Header 各字段的定义

图 5‑10 中展示的 Completion Header 中的每个字段的位置和作用都在表 5‑7 中进行了描述。

表 5‑7 完成包 Header 格式

l、 完成包状态码总结（Summary of Completion Status Codes）

• 000b（SC）Successful Completion 成功完成：请求被正确服务。
• 001b（UR）Unsupported Request 不支持的请求：对于 Completer 来说，此请求是非法的或者是无法被识别的。这是一种出错的情况，至于 Completer 如何进行响应则要根据 Completer 对应的 PCIe 协议版本来。在 PCIe 1.1 之前，这种情况被视为一种不可纠正的错误，但是在 1.1 和之后的版本中，它被作为一种 Advisory Non-Fatal Error（报告的非致命错误）。更多详细内容请参阅“Unsupported Request（UR） Status”一节。
• 010b（CRS）Configuration Request Retry Status 配置请求重试状态：Completer 临时的无法服务一个配置请求，因此这个请求应该稍后再次尝试。
• 100b（CA）Completer Abort 完成者终止：Completer 应该已经对请求事务进行了服务，但是因为某些原因导致了服务失败。这是一种不可纠正的错误。

l、 计算低位地址字段（Calculating the Lower Address Field）

Completer 设置这个字段是用来反映返回给 Requester 的数据荷载中，第一个 enabled 的字节的字节对齐地址（byte-aligned address）。硬件会通过原始请求中的 DW 起始地址以及首 DW 字节使能字段（1st DW Byte Enable）中的字节使能情况，来计算出这个地址的值。

对于 MRd（Memory Read）请求，这个地址就是从 DW 起始地址开始的偏移量：

• 如果首 DW 字节使能字段为 1111b，也就是第一个 DW 中的所有字节都是有效的，那么偏移量就是 0。此时这个字段就与 DW 对齐的起始地址相同。
• 如果首 DW 字节使能字段为 1110b，也就是第一个 DW 中的高 3 个字节都是有效的，那么偏移量就是 1。此时这个字段就等于 DW 对齐的起始地址+1。
• 如果首 DW 字节使能字段为 1100b，也就是第一个 DW 中的高 2 个字节都是有效的，那么偏移量就是 2。此时这个字段就等于 DW 对齐的起始地址+2。
• 如果首 DW 字节使能字段为 1000b，也就是第一个 DW 中的仅有最高字节是有效的，那么偏移量就是 3。此时这个字段就等于 DW 对齐的起始地址+3。

一旦上述的计算完成，计算结果的低 7bit 就会被放入完成包 Header 的 Lower Address 字段，当读完成包小于整个数据荷载因而需要停止在第一个 RCB（Read Completion Boundary）时，这个字段可以有助于更好的处理这种情况。若想将一个事务拆分成多个部分，则必须要在 RCB 上进行拆分，而到达第一个 RCB 时所传输的字节数量是根据起始地址而定的。

对于 AtomicOp（原子操作）完成包，Lower Address 字段是保留位。对于所有其他完成包类型（非读请求、非原子操作），这个字段必须为 0。

l、 使用字节数修改位（Using The Byte Count Modified Bit）

这个 bit 仅由 PCI-X Completer 进行设置，但是如果使用了 PCIe 到 PCI-X 的 Bridge，那么这些 PCI-X Completer 们就也可以出现在 PCIe 拓扑结构中。使用这个 bit 的规则包括：

1. 当一个读请求要拆分成多个完成包来返回数据时，Byte Count Modified 这一位只能由 PCI-X Completer 进行置位。
2. 仅有一系列完成包中的第一个可以将这个 bit 置为 1，这表示第一个完成包内包含的 Byte Count 字段只反映这个完成包（第一个完成包）的数据荷载，而不是整个事务的数据荷载（通常情况下是表示整个事务的总数据荷载）。这样 Requester 就知道，即使 Byte Count 看起来似乎表示这是这个请求的最后一个完成包，但是实际上这个完成包之后还会有完成包，以此来满足原始请求对数据量的需求。
3. 对于随后的一系列完成包来说，BCM 位必须置为 0，且 Byte Count 字段要用来反映剩下的所有数据荷载额字节数，就像它通常的含义一样。
4. 当设备接收到 BCM 位为 1 的完成包时，它必须要正确的处理这种情况。
5. Completer 要在带有数据荷载的完成包中设置 Lower Address 字段，以此来反映返回的第一个有效字节的地址。

l、 读请求数据返回（Data Returned For Read Requests）:

1. 一个读请求可能需要多个完成包来返回数据，但是最终传输的数据总量必须等于原始请求中要求的大小，否则可能导致完成包超时错误（Completion Timeout error）。
2. 一个完成包只能用于服务一个请求。
3. IO 和 Configuration 读请求所请求的数据量永远是 1DW，并且只能由一个单独的完成包来返回数据。
4. 状态码不是 SC（Successful Completion）的完成包将会终止当前事务。
5. 在使用多个完成包来响应读请求时，必须注意读完成包边界（RCB，Read Completion Boundary）。对于 RC 来说，RCB 会是 64Bytes 或者 128Bytes，这是因为 RC 可以更改在其端口间移动的数据包的大小，具体的 RCB 的值可以在配置寄存器中看到。
6. Bridge 和 EP 可以用一个 bit 来实现软件对 RCB 大小的选择，64bytes 或者 128bytes。
7. 完全在一个对齐 RCB 边界内的完成包们必须一次完成传输，这是因为这些 RCB 边界内的完成包的传输是不会到达 RCB 的，而 RCB 才是允许提前停止传输的位置，这样就必须对一个 RCB 边界内的所有完成包一次完成传输而不能中途停止。
8. 对于一个单独的读请求来说，若使用多个完成包来返回数据，那么这些数据必须以地址递增的顺序来返回。

l、 接收者对完成包的处理规则（Receiver Completion Handling Rules）:

1. 如果一个已经被接收的完成包并没有匹配上任何一个待完成的请求，那么它就是一个 Unexpected Completion（意外完成包），将被当做是一种错误来处理。
2. 如果完成包状态不是 SC 或者 CRS，那么就将被当做是错误来处理，并且会清空与之相关联的 Buffer 空间。
3. 当 RC 在进行配置事务时接收到一个 CRS 状态的完成包，那么这个配置请求就被终止了。随后要进行的事情是根据具体实现而不同的，但是如果 RC 支持这种 CRS 状态的完成包处理，那么具体的操作将由 RC 控制寄存器中的 CRS Software Visibility 位来进行定义设置。

— 如果 CRS Software Visibility 没有启用，那么 RC 将会重新发出配置请求，直到重复了一定的次数（具体实现中指定）之后就会放弃重发的操作，并认为请求目标存在问题。

— 如果 CRS Software Visibility 是启用的，那么用来支持它的软件都会首先读取 Vendor ID 字段的两个字节，如果硬件接收到了这个读请求的 CRS 完成包，它将给返回的 Vendor ID 将会是 0001h。这个值是 PCI-SIG 规定的保留值，它并不对应任何有效的 Vendor，并会通知软件发生了这样的事件。这使得软件可以在等待目标 Function 准备就绪的这段时间里（通常在复位后需要 1s 时间），去执行其他的任务，而不是停滞不前。任何其他的配置读或者写（除了最开始的配置读 Vendor ID）都会被 RC 自动重试重发，直到达到设计的重复次数。

1. 如果一个请求并不是配置请求，但是它的完成包出现了 CRS 状态，那么这个完成包将被认为是一个畸形 TLP（Malformed TLP）。
2. 当完成包状态码为保留组合时，并不是定义出的那几种，就把它当做 UR（Unsupported Request）一样处理。
3. 如果接收到的一个读完成包或者一个原子操作完成包的状态码不是 SC，那么这个完成包就不会携带数据，并且 Requester 必须要考虑终止这个完成包对应的请求。至于 Requester 具体如何处理这种情况则根据具体实现而定。
4. 在使用多个完成包来响应一个读请求的情况下，任何一个完成包的状态只要不是 SC，那么就会终止这个事务。设备如何处理出错之前接收到的数据根据具体实现而定。
5. 为了保持对 PCI 的兼容性，RC 需要在一个配置事务被 UR 结束时，合成一个全 1 的读取值。这就类同于枚举软件尝试从不存在的设备中读取数据时的出现的 PCI Master Abort 一样。

5.2.5.5 消息请求（Message Requests）

Message 请求取代了 PCI/PCI-X 中使用的许多中断（interrupt）、错误（error）和电源管理（power management）的边带信号。所有的 Message 请求使用的都是 4DW Header 格式，但是并不是每种 Message 都使用了 Header 中的每一个字段。对于 Header 中的 Byte8-15 来说，在一些种类的 Message 中就没有其定义，在这种情况下它就是保留字段。Message 的处理方式更像是 Posted 的 MWr 事务，但是 Message 的路由方式可以是基于地址的、基于 ID 的，在一些情况下还可以是隐式路由。TLP Header 中的路由子域（routing subfield），也就是 Byte 0 bit 2:0，它用来表示使用的是哪种路由方法，并且相应的在 Header 中定义了哪些附加的字段，例如使用基于 ID 路由的 Header 中就会有用于路由的 BDF。通用的 Message 请求 Header 格式如图 5‑11 所示。

图 5‑11 4DW 的 Message 请求 Header 格式

l、 Message 请求 Header 各字段（Message Request Header Fields）

表 5‑8 Message 请求 Header 各字段

l、 Message 注意事项（Using The Byte Count Modified Bit）

接下来几个小节的列表会列出 9 种 Message 组（如表 5‑8 中给出的）的各自使用的更具体的 Message Code。这 9 种 Message 组为：

1. INTx 中断信号（INTx Interrupt Signaling）
2. 电源管理（Power Management）
3. 错误信号（Error Signaling）
4. 支持锁定事务（Locked Transaction Support）
5. 支持插槽功耗限制（Slot Power Limit Support）
6. 厂商定义的 Message（Vendor-Defined Message）
7. 忽略 Message（Ignored Message，与 PCIe 1.1 中的热插拔支持相关）
8. 延迟容忍报告（Latency Tolerance Reporting，LTR）
9. 优化的 Buffer 刷新和填满（Optimized Buffer Flush and Fill，OBFF）

l、 INTx 中断 Message（INTx Interrupt Messages）

许多设备都适用 PCI 2.3 的 MSI（Message Signaled Interrupt）方法来传输中断，但是对于老的设备来说可能会不支持 MSI。对于这些情况，PCIe 定义了一个“虚拟线 virtual wire”作为替代方案，设备通过发送 Message 来模拟 PCI 中断引脚（INTA-INTD）的拉起与释放。中断设备发出第一个 Message 来通知上行设备自己拉起了一个中断。一旦这个中断被响应处理（Serviced）了，那么中断设备就发出第二个 Message 来表示这个“虚拟中断线”已经释放。更多关于这种协议的内容，请参阅“Virtual INTx Signaling”一节。

表 5‑9 INTx 中断信号 Message 的代码

关于使用 INTx Message 的一些规则：

1. INTx Message 没有数据荷载，因此 Length 字段为保留字段。
2. 它们只会由上行端口（Upstream Port）发出。对接收到的数据包进行这方面的规则检查是可选项，但是如果进行了检查，那么发现违例的数据包就会被当做畸形 TLP（Malformed TLP）。
3. INTx Message 需要使用默认的流量类型 TC 0。接收方必须检查这一条规则，发现违例的数据包就会被当做畸形 TLP（Malformed TLP）。
4. 链路两端的组件必须跟踪四种虚拟中断（virtual interrupt）的状态。如果上行端口的一个中断的逻辑状态发生了改变，那么它必须发出相应的 INTx Message。
5. 当命令寄存器（Command Register）中的 Interrupt Disable 位被置为 1 时，INTx 信号是被禁用的（就像物理中断线的类似情况一样）。
6. 如果在 Interrupt Disable 位为 1 时，设备的任何一个虚拟 INTx 信号仍为激活状态，那么上行端口必须发出对应的释放 INTx Message（Deassert\_INTx Message）。
7. Switch 的各个下行端口必须独立的跟踪四种 INTx 信号状态，并组合成上行端口的状态。
8. RC 的各个下行端口必须独立的跟踪下行端口的 INTx 信号状态，并将它们转换成系统中断，具体的转换方式根据具体实现而定。
9. INTx Message 使用“Local-Terminate at Receiver 在接收者本地结束”的路由类型来使得一个 Switch 在必要时对指定的中断引脚进行重映射（参阅“Mapping and Collapsing INTx Messages”一节）。因此，INTx Message 中的 Requester ID 有可能是最后一个传送者所指定的。

l、 电源管理 Message（Power Management Messages）

PCIe 对 PCI 的电源管理是兼容的，并且还加入了基于硬件的链路电源管理。Message 是用来传达一些关于电源管理的信息，但是如果想了解完整的 PCIe 电源管理协议是如何工作的，那么请参阅 Chapter 16 “Power Management”一章。表 5‑10 总结了四种电源管理 Message 类型。

表 5‑10 电源管理 Message 标识码

关于使用电源管理 Message 的一些规则：

1. 电源管理 Message 没有数据荷载，因此 Length 字段为保留字段。
2. 电源管理 Message 需要使用默认的流量类型 TC 0。接收方必须检查这一条规则，发现违例的数据包就会被当做畸形 TLP（Malformed TLP）。
3. 当一个下行端口收到了一个链路对端电源管理请求，请求要将链路电源状态更改为 L1，但是下行端口拒绝这种更改，那么它就要发出 PM_Active_State_Nak 这种电源管理 Message。
4. 当一个组件请求电源管理事件（Power Management Event）时，它的上行端口需要发出 PM_PME，这个 Message 将被隐式路由至 RC。
5. PM_Turn_Off 会向下发送给所有的 EP（由 RC 发出，进行隐式路由的广播）。
6. PME_TO_Ack 是由 EP 的上行端口发出的。对于拥有多个下行端口的 Switch 来说，只有当所有的下行端口都收到了这个 Message，才会将其转发至上行（也就是汇聚收集，并路由转发给 RC）。

l、 错误 Message（Error Messages）

当启用了错误 Message 的组件检测到了错误，那么就会将错误 Message 向上发送（隐式路由至 RC）。为了协助软件，让软件知道应该如何处理这个错误，在 Error Message 中使用 Header 中的 Requester ID 字段来表示请求者。表 5‑11 总结了三种 Error Message 类型。

表 5‑11 错误 Message 标识码

关于使用 Error Message 的一些规则：

1. Error Message 没有数据荷载，因此 Length 字段为保留字段。
2. Error Message 需要使用默认的流量类型 TC 0。接收方必须检查这一条规则，发现违例的数据包就会被当做畸形 TLP（Malformed TLP）。
3. RC 会将 Error Message 转换成系统指定的事件。

l、 支持锁定事务（Locked Transaction Support）

解锁 Message（Unlock Message）被应用于 PCI 定义的锁定事务协议中（Locked Transaction Protocol），并且在 PCIe 中依然对传统 PCI 遗留设备可用。这种协议起始于一个 MRd Lock 请求。当这个请求在被送达到目标设备的过程中，沿途的端口们都会发现它，这些端口会实现一个原子“读-修改-写”协议（read-modify-write protocol），也就是说它们将会锁定 VC0（Virtual Channel 0）让其他的请求不能使用，直到收到 Unlock Message 才会对 VC0 解锁。这种 Unlock Message 会被发送至 Locked 事务的目标设备，以此来释放传输路径中的所有被锁定的端口，并用于最终完成锁定事务的一系列行为。表 5‑12 总结了 Unlock Message 的标识码。

表 5‑12 解锁 Message 标识码

关于使用 Unlock Message 的一些规则：

1. Unlock Message 没有数据荷载，因此 Length 字段为保留字段。
2. Unlock Message 需要使用默认的流量类型 TC 0。接收方必须检查这一条规则，发现违例的数据包就会被当做畸形 TLP（Malformed TLP）。

l、 设置插槽功率限制 Message（Set Slot Power Limit Message）

这种 Message 是由下行端口发送给插在插槽上的设备的。这里面的功率限制信息会储存在 EP 的设备能力寄存器中（Device Capabilities Register）。表 5‑12 总结了 Unlock Message 的标识码。

表 5‑13 插槽功率限制 Message 标识码

关于使用 Set Slot Power Limit Message 的一些规则：

1. Set Slot Power Limit Message 需要使用默认的流量类型 TC 0。接收方必须检查这一条规则，发现违例的数据包就会被当做畸形 TLP（Malformed TLP）。
2. Set Slot Power Limit Message 的数据荷载为 1DW，因此 Length 字段的值为 1。而在 32bit 数据荷载中仅有低 10bit 用于进行插槽功率放大或减小；剩下的高位必须都置为 0。
3. 当数据链路层转换为 DL-Up 状态时，该消息会自动发送。或者是放数据链路层已经报告了 DL-Up 状态，然后发生了一个配置写来写入 Slot Capabilities Register 时，该消息也会自动发送。
4. 如果插槽中的板卡消耗的功率已经低于了指定的功率限制，那么可以忽略这种 Message。

l、 厂商定义的 Message 0 和 1（Vendor-Defined Message 0 and 1）

Vendor-Defined Message 是用于进行 PCIe Message 能力的扩展，这种扩展既可以通过协议本身，也可以通过厂商来指定的扩展。这种 Message 的 Header 格式如图 5‑12 所示，Message 标识码如表 5‑12。

图 5‑12 厂商定义的 Message Header 格式

表 5‑14 厂商定义的 Message 标识码

关于使用Vendor-Defined Message 的一些规则：

1. Vendor-Defined Message 0 和1 可以有也可以没有数据荷载。
2. Message 用Vendor ID 来进行区分。
3. Attr[2]和Attr[1:0]并不是保留位。
4. 如果接收者无法认出这种Message：

• Type 1 Message 可以被安静的忽略丢弃掉。
• Type 0 Message 要被作为Unsupported Request（UR）这种错误情况来处理。

l、 被忽略的Message（Ignored Message）

如果直接列出一整个目录的需要被忽略的Message，而不去讲忽略的前因后果，那可能会听起来有一些奇怪。这些Message 其实是原来的热插拔信号Message（Hot Plug Signaling Message），它们用于支持设备，这些设备上具有热插拔指示器，并且只需要按下这个插卡设备上的按钮而不是系统板上的按钮。这种Message 类型是由PCIe 1.0a 版本所定义的，但是这个选项在PCIe 1.1 版本中就已经不再支持了，因此这里所讲的这些细节内容仅作为参考。正如名字要表达的那样，强烈建议发送方不要发送这些Message，并且也强烈建议接收方就算收到它们也要忽视掉。如果无论如何仍要使用这些Message，那么它们必须要符合PCIe 1.0a 的协议细节。

表 5‑15 热插拔Message 标识码

关于使用Hot Plug Message 的一些规则：

1. Hot Plug Message 由下行端口发送给插槽中的板卡。
2. Attention_Button Message 是由插槽中的设备向上行发送的。

l、 延迟容忍报告Message（Latency Tolerance Reporting Message）

LTR Message 是用来报告一个设备可接受的读写服务延迟，这是一个可选项。更多关于这种电源管理技术的内容，请参阅“LTR（Latency Tolerance Reporting）”一节。

图 5‑13 LTR Message Header 格式

表 5‑16 LTR Message 标识码

关于使用LTR Message 的一些规则：

1. LTR Message 没有数据荷载，因此Length 字段为保留字段。
2. LTR Message 需要使用默认的流量类型TC 0。接收方必须检查这一条规则，发现违例的数据包就会被当做畸形TLP（Malformed TLP）。

l、 优化的Buffer 刷新和填充Message（Optimized Buffer Flush and Fill）

OBFF Message 用来向EP 报告平台电源情况，以此来促进更高效的系统电源管理。更多关于这种技术的内容，请参阅“OBBF（Optimized Buffer Flush and Fill）”一节。

关于使用OBFF Message 的一些规则：

1. OBFF Message 没有数据荷载，因此Length 字段为保留字段。
2. OBFF Message 需要使用默认的流量类型TC 0。接收方必须检查这一条规则，发现违例的数据包就会被当做畸形TLP（Malformed TLP）。
3. Header 中的Requester ID 必须为传送中的端口的ID。

原文： Mindshare
译者： Michael ZZY
校对： LJGibbs
文章来源：https://zhuanlan.zhihu.com/p/508486198

《PCI Express Technology 3.0》翻译系列

• 《PCI Express Technology 3.0》Chapter 5
• PCI Express Technology 3.0:Chapter 1 Background/背景
• PCI Express Technology 3.0:PCIe体系结构概述 2.1 节
• PCI Express Technology 3.0:PCIe体系结构概述 2.2-2.3
• PCI Express Technology 3.0:PCIe体系结构概述 2.2-2.3 节（完）
• PCI Express Technology 3.0:PCIe配置概述 3.1-3.7 节
• PCI Express Technology 3.0:PCIe配置概述 3.8-3.14 节（完）
• PCI Express Technology 3.0:地址空间与事务路由4.1-4.2节
• PCI Express Technology 3.0:地址空间与事务路由 4.3-4.4节
• PCI Express Technology 3.0:地址空间与事务路由4.5-4.6小节（完）

更多IC设计技术干货请关注FPGA的逻辑技术专栏。欢迎添加极术小姐姐微信（id:aijishu20)加入技术交流群，请备注研究方向。