PCIe学习笔记（20）
接收tlp处理（Handling of Received TLPs）
本节描述了当接收到的TLP从接收数据链路层传送到接收事务层，并且在数据链路层已经验证了接收到的TLP的完整性后，如何处理所有接收到的TLP
•保留字段中的值必须被接收方忽略。
•如果Fmt字段中的值表明至少存在一个TLP前缀:
◦通过检查后续DW的第一个字节的Fmt字段来检测头部中是否存在额外的TLP前缀，直到Fmt字段与TLP前缀不匹配。
◦按照TLP前缀处理规则(2.2.10)处理所有收到的TLP前缀。
•如果设置了“Extended Fmt Field Supported bit”，则接收到的使用Fmt和Type编码的TLPs为畸形 TLPs(参见表2-1和表2-3)。
•如果扩展Fmt字段支持位为Clear，则未定义接收到的具有Fmt[2] Set的tlp的处理。所有接收到的带有Fmt[2] Clear且使用undefined Type字段值的TLPs都是畸形 TLPs。
•所有收到的畸形tlp必须被丢弃。
◦接收到的畸形TLPs，对于要释放的缓冲区有歧义，或者映射到未初始化或禁用的虚拟通道，必须在不更新接收流量控制信息的情况下丢弃。
◦所有其他收到的畸形TLPs必须丢弃，可选不更新接收流量控制信息。
•否则，更新接收流控制跟踪信息(见2.6节)。
•如果Type字段的值表示该TLP是Request，则按照Request Handling Rules进行处理;否则，该TLP是Completion - handle，按照Completion Handling Rules进行处理。
SW既要处理Switch内部资源的tlp，也要处理Switch外部资源的tlp。Switch按照上述规则处理所有访问Switch内部资源的tlp。经过Switch的TLP，或者地址为Switch并经过Switch的TLP，按照以下规则处理(见图2-42):
•如果Type字段的值表明该TLP不是Msg或MsgD请求，则该TLP必须按照所使用的路由机制进行路由(参见2.2.4.1和2.2.4.2)。
•使用Completion的requester ID字段中的信息来路由Completions。
•如果Type字段的值表明该TLP是Msg或MsgD请求，则根据Type字段的r[2:0]子字段所指示的路由机制进行路由。
◦如果r[2:0]的值表示Msg/MsgD路由到Root Complex (000b)，则Switch必须将Msg/MsgD路由到Switch的Upstream Port。
在交换机的上游端口收到指定000b路由的Msg/MsgD请求是错误的。Switch可以检查是否违反此规则——违反规则的tlp是畸形的tlp。如果选中，这是一个与接收端口相关的报告错误(参见6.2节)。
◦如果r[2:0]中的值表明Msg/MsgD是通过地址(001b)路由的，交换机必须以与通过地址路由内存请求相同的方式路由Msg/MsgD。
◦如果r[2:0]中的值表明Msg/MsgD是通过ID (010b)路由的，Switch必须以与通过ID路由Completion相同的方式路由Msg/MsgD。
◦如果r[2:0]中的值表示Msg/MsgD是来自根Complex (011b)的广播，则交换机必须将Msg/MsgD路由到交换机的所有下行端口。
在交换机的下行端口收到指定011b路由的Msg/MsgD请求是错误的。交换机可以检查是否违反此规则——违反规则的tlp是畸形的tlp。如果选中，这是一个与接收端口相关的报告错误(参见6.2节)。
◦如果r[2:0]中的值表示Msg/MsgD终止于Receiver (100b或保留值)，或者如果Message Code字段值被定义并对应于必须由Switch理解的消息，则Switch必须根据消息处理规则处理消息。
◦如果r[2:0]的值为“collecting and routing to Root Complex (101b)”，请参见5.3.3.2.1中的“消息处理规则”。
◦接收指定101b路由的PME_TO_Ack以外的任何Msg/MsgD请求是错误的。
◦交换机上行端口收到PME_TO_Ack错误。处理步骤交换机可以选择检查是否违反这些规则。这些检查是独立可选的(参见6.2.3.4节)。如果检查，违规是畸形的tlp，并报告与接收端口相关的错误(见6.2节)。
请求处理规则
在对所有tlp进行初始处理之后，如何处理收到的请求。流程图如图2-43所示。
•如果设备不支持请求类型(通过设计或由于配置设置)，则请求是不支持的请求，并根据章节6.2报告
◦如果请求需要完成，则返回UR的完成状态
•如果请求是消息,且消息代码,路由领域,或Msg/ MsgD指示对应于一个未定义的组合,或者对应一个不被设备功能支持的消息,(除了Vendor_Defined Type1型,这不视为一个错误),请求是一个不受支持的请求（UR）
◦如果消息代码是支持的值,根据相应的消息处理规则处理;如果消息码是一个被忽略的消息，并且接收方正在忽略它，忽略该消息而不报告任何错误。
•如果请求消息路由为ID路由,如果请求被带有Type0型头的设备功能接收,强烈建议设备被视为消息的目标无论总线目的地ID字段中指定的数量和设备数量的请求
◦如果函数中指定目的地ID是未实现的,强烈建议请求处理作为一个不受支持的请求,并按照第6.2节的规定进行报告
如果请求不是消息，并且是受支持的类型，则可以根据已定义的编程模型优化特定的实现，以确保某些类型的(否则合法的)请求永远不会发生。这样的实现可以利用以下规则:
•如果请求违反了设备功能的编程模型，功能可以选择性地将请求视为Completer Abort，而不是正常处理请求
◦如果请求被视为Completer Abort，这是一个与功能相关的报告错误(参见6.2节)
◦如果请求需要完成，CA的完成状态返回(参见2.2.8.10节)
•否则(支持请求类型,而不是一个消息),处理请求
◦如果完成者由于设备特定的错误条件而永久无法处理请求，完成者必须（如果可能的话）将请求作为完成者中止（Completer Abort）来处理。
▪这是一个与接收函数相关的报告错误, 如果错误可以被隔离到组件中的特定函数, 或如果无法隔离错误，则发送到接收端口(见6.2节)
◦对于配置请求，仅在重置后，设备有可能终止请求，但表明它暂时无法处理请求，但将来可以处理请求-在这种情况下，使用配置请求重试状态(CRS)完成状态(见章节6.6)。设备允许返回CRS的有效复位条件是:
-Cold, Warm, and Hot Resets
- FLRs
-A reset initiated in response to a D3Hot to D0uninitialized device state transition 为响应D3Hot到D0未初始化设备状态转换而启动的复位
◦设备功能明确不允许在设备的软件初始化复位(除了FLR)之后返回CRS，例如，由设备的软件驱动程序写入设备特定的复位位。如果没有有效的复位(即FLR或常规复位)条件，或者如果在函数的状态寄存器中设置了立即就绪位，则不允许在设备函数指示配置就绪(见第6.23节)之后返回CRS。另外，在没有有效复位(即FLR或常规复位)条件的情况下，设备函数不允许在先前返回成功完成后返回CRS
◦在服务请求的过程中，Completer可以确定(否则可接受的)请求必须作为错误处理，在这种情况下，根据错误的类型处理请求
▪示例:PCI Express/PCI桥可能最初接受请求，因为它指定了映射到桥的辅助侧的内存空间范围，但请求可能在桥的PCI侧主中止或目标中止。从PCI Express的角度来看，在这种情况下请求的状态是UR(表示主中止)或CA(表示目标中止)。如果请求需要在PCI Express上完成，则返回相应的完成状态。
•如果请求是需要返回完成包的类型，根据完成结构规则生成完成包
◦完成状态是由处理请求的结果决定
◦如果请求有ECRC校验失败错误，那么是否返回完成以及如果返回，使用哪个架构定义的值作为其完成状态，这是硬件设计的
但是，强烈建议Completer返回带有UR Completion Status的Completion。
•在正常工作条件下，PCI Express endpoint和Legacy endpoint接受一个Posted Request的延迟不能超过10 μs，这个延迟被称为Posted Request Acceptance Limit。设备必须(a)设计为处理收到的发布请求并在必要的时间限制内返回相关的Flow Control credits，或者(b)依赖于受限的编程模型，以确保在设备无法在必要的时间限制内接受新的Posted Request时，软件或其他设备永远不会向设备发送转发请求。
◦不视为适用Posted Request接受限制的正常运行条件包括:
▪基本重置后的一段时间(见6.6节)
▪TLP重传或链路重训练
▪一个或多个丢弃的流量控制数据包(fcp)
▪设备处于诊断模式
▪设备处于不适合正常使用的设备特定模式。
◦以下被认为是正常的操作条件，但它们造成的任何延迟都不违反Posted Request接受限制:
▪上游TLP流量延迟上游fcp
▪链路从低功耗状态出来
▪与其他vc流量仲裁
◦虽然不是要求，但强烈建议rciep也遵守发布请求接受限制。
•如果设备支持作为I/O写请求的目标，即Non-Posted Requests，强烈建议每个相关的完成在与Posted Requests接受相同的时间限制内返回，尽管这不是必需的。
