PCIE协议-2-事务层规范-Data Integrity

2.7 数据完整性

PCI Express中的基本数据可靠性机制包含在数据链路层中，该层使用32位循环冗余校验（LCRC）代码在链路对链路的基础上检测事务层包（TLP）中的错误，并应用链路对链路的重传机制进行错误恢复。TLP是由PCI Express域的“边缘”（例如端点或根复合体）处的数据源创建的数据和事务控制单元，可能通过中间组件（即交换机）路由，并由最终的PCI Express接收者消耗。当一个TLP通过一个交换机时，交换机可能需要更改一些控制字段，而不修改其他在数据包穿越路径时不应更改的字段。因此，交换机会重新生成LCRC。

数据可能会在交换机内部发生损坏，重新生成损坏数据的良好LCRC会掩盖错误的存在。为了确保在需要高数据可靠性的系统中进行端到端数据完整性检测，可以在TLP digest字段的末尾放置事务层端到端32位CRC（ECRC）。ECRC覆盖了TLP穿越路径时不发生变化的所有字段（不变字段）。ECRC由源组件中的事务层生成，并由最终的PCI Express接收者检查（如果支持），并可选择性地由中间接收者检查。支持ECRC检查的交换机必须检查针对交换机本身的TLP上的ECRC。这样的交换机可以可选择性地检查它转发的TLP上的ECRC，在交换机转发的TLP上，交换机必须保留ECRC（不作更改地转发）作为TLP不可分割的一部分，无论交换机是否检查ECRC或ECRC检查失败。

在某些情况下，当生成TLP时，TLP有效载荷中的数据已知是损坏的，或者在通过中间组件（如交换机）时可能会损坏。在这些情况下，可以使用错误转发（也称为数据中毒）来向消耗数据的设备指示损坏。

2.7.1 ECRC规则

生成和检查ECRC的能力向软件报告，并且通过软件启用此功能（见第7.8.4.7节）。

• 如果设备功能被启用生成ECRC，它必须为由该功能发起的所有TLP计算并应用ECRC。
• 交换机必须从入口端口到出口端口，不改变ECRC，将TLPs（事务层包）传递过去。

• 如果设备支持ECRC 生成/校验，至少其一个功能必须支持高级错误报告（AER）（见第6.2节）。

• 如果设备功能被启用来校验ECRC，它必须对所有带有ECRC的TLP（事务层包）进行校验，其中设备是最终的PCI Express接收器。

  • 请注意，功能仍然可能接收到不带ECRC的TLP，这些TLP将正常处理 - 这不是一个错误。

注意，交换机可以选择性地对通过交换机的TLP执行ECRC校验，交换机检测到的ECRC错误如表6-5所述进行报告，但不改变TLP通过交换机的传递。

使用以下算法为TLP（包括端到端TLP前缀、头标和数据有效载荷）计算一个32位的ECRC，并将其附加到TLP的末尾（见图2-3）：

• ECRC值是使用以下算法计算的（见图2-49）
• 使用的多项式具有系数表示为04C1 1DB7h。
• 种子值（ECRC存储寄存器的初始值）是FFFF FFFFh。
• 在ECRC计算中包括所有头标字段、所有端到端TLP前缀（如果存在）和整个数据有效载荷（如果存在），在变体字段中的所有位必须设置为进行ECRC计算。
  • TLP头中的Type字段的第0位是变体，端到端TLP前缀中的这个位是不变的。
  • EP位是变体
  • 所有其他字段是不变的
• ECRC计算从TLP的byte0的bit0 开始，并按顺序进行到每个byte的bit7。
• ECRC计算的结果被补码，并且补码结果位如表2-49所示映射到32位TLP digest字段中。

• 32位的ECRC值被放置在TLP末尾的TLPdiagest字段中（见图2-3）。 对于包含用于ECRC值的TLP  digest字段的TLP，支持端到端数据完整性校验的接收器通过以下方式检查TLP digest字段中的ECRC值：
  • 对接收到的TLP应用相同的ECRC计算算法（如上所述），但不包括接收到的TLP的32位TLP 的digest字段，然后
  • 将计算结果与接收到的TLP的TLP digest字段中的值进行比较。
• 支持端到端数据完整性检查的接收器将违规情况报告为ECRC错误。这个报告的错误与接收端口相关联（见第6.2节）。

除了本规范中其他地方包含的报告错误语义之外，最终的PCI Express接收器如何使用通过ECRC提供的端到端数据完整性检查不在本文档的范围之内。中间接收器仍然需要转发ECRC校验失败的TLP。PCI Express到PCI/PCI-X桥被认为是关于ECRC校验的最终PCI Express接收器。

2.7.2 错误转发

错误转发（也称为数据中毒）是通过设置EP位来指示的。执行此操作的规则在第2.7.2.2节中指定。以下是可能使用错误转发的一些示例：

• 示例 #1：从主内存中读取时遇到一个不可纠正的错误
• 示例 #2：向主内存写入时发生奇偶校验错误
• 示例 #3：内部数据缓冲区或缓存上的数据完整性错误

2.7.2.1 错误转发使用模型

• 错误转发仅用于读取完成数据、原子操作完成数据、原子操作请求数据或写入数据，从不用于错误在“头标”（请求阶段、地址/命令等）的情况下。 请求/完成头标错误通常不能被转发，因为真正的目的地不能被确切知道，因此，转发可能会导致直接或间接的影响，如数据损坏、系统故障等。
• 错误转发用于系统内错误控制传播、系统诊断等。
• 请注意，错误转发不会导致链路层重试 - 只有在数据链路层的TLP错误检测机制确定链路上存在传输错误时，中毒的TLP才会被重试。
  • 中毒的TLP最终可能导致请求的发起者（在事务层或更高层）在读取操作的情况下重新发出它，或采取其他一些行动。这种错误转发信息的使用不在本规范的范围之内。

2.7.2.2 数据中毒的使用规则

• 在发送器中支持TLP中毒是可选的。
• 数据中毒仅适用于写请求（转发或非转发）、带数据的消息、原子操作请求、读取完成或原子操作完成中的数据。
  • 通过设置EP位来指示TLP的中毒。
  • 发送器只允许为包含数据有效载荷的TLP设置EP位。如果为任何不包含数据有效载荷的TLP设置EP位，接收器的行为未被指定。
• 如果发送器支持数据中毒，发送器已知包含坏数据的TLP必须使用上述定义的中毒机制。
• 如果下游端口支持中毒TLP出站阻塞，中毒TLP出站阻塞使能位被设置，并且中毒TLP目标从出站端口发出，除非有更高优先级的错误，否则端口必须将TLP作为中毒TLP出站阻塞错误处理。见第6.2.3.2.3节、第6.2.5节和第7.9.15.2节。
  • 端口不得传输TLP。
  • 如果DPC（数据包校验）未触发，并且TLP是非转发的请求，端口必须返回一个带有不支持请求完成状态的完成。
  • 如果触发了DPC，端口必须按照第2.9.3节中描述的行为进行。
• 以下带有中毒数据的请求不得修改目标位置的值：
  • 配置写请求
  • 任何针对完成者中的控制寄存器或控制结构的以下请求：I/O写请求、内存写请求或非供应商定义的带数据消息
  • 原子操作请求
  • 除非有更高优先级的错误，否则完成者必须将这些请求作为接收到的中毒TLP错误处理，并且如果请求是非转发的（见第6.2.3.2.3节、第6.2.3.2.4节和第6.2.5节），完成者还必须返回一个带有完成状态为不支持请求(UR)的完成。 无论报告的错误严重性如何，报告的错误必须作为不可纠正的错误处理，而不是作为建议性的非致命错误。
  • 交换机必须按照它将如何路由相同请求（如果请求没有被中毒）的方式路由请求，除非请求针对交换机本身的位置，在这种情况下，交换机是请求的完成者，并且必须遵循上述规则。

对于某些应用，完成者可能希望在不针对控制寄存器或控制结构的写请求中使用中毒数据 - 这种使用是不被禁止的。同样，请求者可能希望在完成中使用标记为中毒的数据 - 这种使用也是不被禁止的。中毒信息的适当使用是特定于应用的，并且本文档不进行讨论。

本文档没有定义任何机制来确定中毒TLP的数据有效载荷的哪一部分或部分实际上是损坏的，以及哪些（如果有的话）是不损坏的。