TLP基本格式
TLP
事务(Transactions)由请求(Requests)和完成(Completions)组成， 它们使用传输层包(Transaction Layer Packets，简称TLP)通信。PCIe 支持几种基本的事务类型:内存(Memory)，I/O，配置(Configuration) 和信息(Message)。他们的作用如下：
| 地址空间 | 事务类型 | 描述 |
|---|---|---|
| Memory | Read/write | 将数据传输到内存映射的位置 |
| I/O | Read/write | 将数据传输到I/O映射位置 |
| Configuration | Read/write | 设备功能配置/设置 |
| Message | Baseline | 从事件信号机制到通用消息 |
TLP由TLP Prefixes + TLP Header + Data Payload + TLP Digest构成 ，如下图所示:
当 TLP 形成时， 所有为保留(Reserved，R)的字段必须用 0 填充， 接收机在接受 TLP 时必须忽略这些保留的字段， 并且 Switches 在转发时也不能修改。
PCIe采用小端模式，传输时先传输 TLP Prefixes， 最后传输 TLP Digest， TLP Prefixes为TLP的前缀，可以没有，也可以有多个，TLP Header针对串行互连的性能进行了优化，最重要的信息首先传递. 在 TLP 标头， 地址会先传输，对端可以先对地址进行解析。Data Payload为数据载荷，根据TLP类型的不同，可以没有，也可以有，长度不定，TLP Digest为TLP后缀，可以没有，也可以有一个。
TLP Prefixes
Non Flit模式下所有的TLP prefixes 和Header都包含Fmt和Type字段。
在Non Flit模式下，对任意 TLP， 如果 TLP 的byte 0的Fmt字段为100b， 那么该 TLP 中存在 TLP Prefixes， 并且 TLP Header 中的 Type[4] 用于确定该 TLP Prefixes 的类型。
- Type[4] : 0， 表明是一个 Local TLP Prefixes
- Type[4] : 1， 表明是一个 End-End TLP Prefixes
Flit Mode下所有的TLP Prefix第一个DW都具有如下字段
不仅是TLP Prefix,Flit模式下的所有TLP的第一个DW都具有上述的所有字段。在Flit模式下,Type[7:0]如果为为下列值时，表明存在Prefix
- 1000_xxxx 1000_10xx 1000_1100 1000_1101 1000_1110 1000_1111
TLP Prefixes的大小是一个DW(4 Byes)，但是一个TLP中可以有多个TLP Prefixes。
TLP Prefixes 规则
TLP Prefixes Byte 1到3的具体内容取决于Fmt和type字段。如果TLP中有Prefixes，则该TLP中必须有Header，不能只传输Prefixes。如果接收只有Prefixes的TLP，则该TLP是一个Malformed TLP(无效的TLP),Malformed TLP必须上报错误，并且跟端口关联上。
TLP Prefixes可以有一个或者多个，并且类型也可以不一样，即一个TLP中可以同时包含Local TLP Prefixes和End-End TLP Prefixes，但是所有的Local TLP Prefixes必须要在End-End TLP Prefixes之前，如果收到的TLP中，End-End TLP Prefixes在Local TLP Prefixes之前，则是一个无效的TLP
Local Prefixes和End-End TLP Prefixes有不同的处理规则。
Local Prefixes处理规则
Prefixes有不同的类型，同样Local Prefixes也有不同的类型，其类型取决于Type字段的[3:0]，根据Type[3:0]的不同可分为下面几种类型
| Local TLP Prefix类型 | Type[3:0] | 描述 |
|---|---|---|
| MR-IOV | 0000 | MR-IOV TLP Prefix |
| FlitModePrefix | 1101 | Flit Mode Local TLP Prefx |
| VendPrefixL0 | 1110 | Vendor Defined Local TLP Prefix |
| VendPrefixL1 | 1111 | Vendor Defined Local TLP Prefix |
| xxx | xxx | 其它编码保留 |
VendPrefixL0和VendPrefixL1都属于Vendor Defined Local TLP Prefix。
不同类型的Local TLP Prefix具有不同的大小，路由规则和流控规则。
如果接收机收到不支持某种类型的Local TLP Prefix，对接收机而言是一种错误。如果此时Extended Fmt Field Supported域为1，收到不支持类型的Local TLP Prefix为无效的TLP，除非在其它协议中明确声称这种TLP不是无效的TLP。如果此时Extended Fmt Field Supported域为0，收到不支持的Local TLP Prefix时，其行为却决于设备自己实现。
Local TLP Prefix不受ECRC保护
Vendor Defined Local TLP Prefix
为了操作性和灵活性最大化，Vendor Defined Local TLP Prefix的规则也有一定的变化。
如果没有使用vendor-specific机制，component之间是不允许发送包含Vendor Defined Local TLP Prefix的TLP。使用vendor-specific机制机制后，只要同时满足Extended Fmt Field Supported域为1和支持Fmt中的所有定义时，才可以使用Vendor Defined Local TLP Prefix。
为了所有的vendor defined prefixes都可以使用Vendor Defined Local TLP Prefix编码中的任意一种，协议推荐Components可以通过vendor-specific去配置。
FLit Mode Local TLP Prefix
这种Prefix只允许出现在Flit模式中。其格式如下所示:
Flit Mode Local TLP Prefix包括TLP Uses Dedicated Credits，当改比特为1时，表明TLP必须使用dedicated flow control credits(专用流控信用)来处理相关联的TLP。当此比特为0时，或者是不存在Flit Mode Local TLP Prefix时，相关联的TLP必须使用shared flow control credits(共享流控信用)来处理
如果Flit Mode Local TLP Prefix(Byte 1的bit[7])用在了Non Flit Mode TLP中，这在Flit模式下是一个错误，并且必须视为无效的TLP。允许将Flit Mode Local TLP Prefix用在任何Flit模式下的TLp中，但是强烈推荐只有需要Prefix存在时，才使用Flit Mode Local TLP Prefix.
End-End TLP Prefix处理
注意: 该部分只适用于Non-Flit Mode
如果该Prefix是End-End TLP Prefix，则Type[4]必须为1b,Type[3:0]决定了End-End TLP Prefix的类型。
| End-End TLP Prefix类型 | E[3;0] | 描述 |
|---|---|---|
| TPH | 0000 | TPH |
| PASID | 0001 | PASID |
| IDE | 0010 | 定义一个IDE TLP |
| VendPrefixE0 | 1110 | Vendor Defined End-End TLP Prefix |
| VendPrefixE1 | 1111 | Vendor Defined End-End TLP Prefix |
| x | x | 其它编码保留 |
Device Capabilities 2寄存器的Max End-End TLP Prefixes字段表明了function支持End-End TLP Prefixes数量。TLP中End-End TLP Prefixes的最大数量为4，如果接收机接收到的TLP中，End-End Prefixes大于4，那么该TLP是一个Malformed TLP。
Max End-End TLP Prefix在不同的设备需求不同：
- 在RC中，Max End-End TLP Prefixes的值允许小于硬件实际支持的。
- 除RC外，其它设备收到的TLP中，End-End TLP Prefixes如果超出了设备支持的上限，则该TLP必须视为一个Malformed TLP。如果支持AER(Advanced Error Reporting),发生该错误后，必须记录在AER中。
如果RC中Max End-End TLP Prefixes字段小于硬件实际支持的，错误处理必须基于Max End-End TLP Prefixes域中的值。如果RC收到的TLP中End-End TLP Prefixes超过所支持的，必须做如下的处理：
- 推荐把Requests(如EP发的MWR)处理为UR(Unsupported Requests，不支持的请求)，如果不处理为UR,则必须处理为Malformed TLPS。
- 推荐把Completions处理为UR，如果不处理为UR，则必须处理Malformed TLP。
- 如果在Ingress Port收到了带End-End的TLP,这是一个跟Ingress Port相关联的错误。
- 如果从Egress Port发出了带End-End的TLP,这个跟Egress Port相关联的错误
如果End-End TLP Prefix Supported比特为1，Switch必须要能够转发包含4个End-End TLP Prefixes的TLP，如果TLP是受到ECRC保护的，那么End-End TLP Prefixes也是受到ECRC保护的。
如果接收机不支持End-End TLP Prefixes，收到带有End-End TLP Prefix的TLP是一个错误，接受需要把这个TLP处理为Malformed TLP,并且需要跟接受端口绑定。
对于软件的要求：如果component不支持End-End TLP Prefixes，软件必须确保不能发送带End-End TLP Prefixes的TLP。如果组件的Extend Fmt Field Supported比特被清了，可能会导致误认为TLPs中包含TLP Prefixes。
如果Upstream Port的其中一个function的End-End TLP Prefix Supported比特设置了，Upstream Port的所有function都必须能处理带不支持的End-End TLP Prefix类型的TLP，处理结果为UR，并且需要个端口绑定。如果收到的是Completion，且该Completion中带有不支持的End-End TLP Prefix类型，Upstream Port的所有function都需要有能力把该笔Completion处理为UC(Unexpected Completion,不支持的回复),并且需要跟端口绑定。
对于路由的元素，在每个Egress Port(出口)的End-End TLP Prefix Blocking比特决定了改TLP通过Egress Port发出去时是否包含了End-End TLP Prefixes。如果转发被阻断，整个TLP都将会被丢弃，并且需要报告未TLP Prefix Blocked Error。如果被阻挡得TLP是一个Non-Posted请求(如MRd)，Egress Port需要返回一个Completion且Completion中得Status未Unsupported Request(UR)。TLP Prefix Blocked Error上报时需要跟Egress Port绑定
对于启用多播的路由元素，End-End TLP Prefixes在所有多播的TLP中都需要加上，在每一个Egress Port上，多播包中的TLP Prefix Egress Blocking是相互独立的。
PASID Prefix
在非Flit模式下，PASID TLP Prefix是一个End-End TLP Prefix。在Flit模式下，当存在PASID时，它被包含在OHC-A1和OHC-A4中，非Flit模式下PASID Prefix如下图所示
| bits | 描述 |
|---|---|
| Byte 0 bit[7:5] | 100b – 表明是一个TLP Prefix |
| Byte 0 bit[4] | 1b – 表明是一个End-End TLP Prefix |
| Byte 0 bit[3:0] | 0001b – 表明是一个PASID TLP Prefix |
| Byte 1 bit[7] | Privileged Mode Request – 如果Set表示端点中的特权模式实体正在发出请求，如果Clear表示端点中的非特权模式实体正在发出请求。 |
| Byte 1 bit[6] | 如果设置表示端点正在请求执行权限。如果清除，表示端点没有请求执行权限。 |
| Byte 1 bit[3:0] – Byte 3 bit[0] | Process Address Space ID(PASID) – 表明改TLP中相关联得PASID的值 |
Execute Requested
如果Execute Requested比特设置了，EP正在请求允许EP执行与此请求相关联的内存范围内的指令, 具体执行权限协议没有说明。只要Execute Permission Supported比特和Execute Permission Enable都设置后，EP才允许发送带Execute Requested比特为1的TLP
对于RC而言，是否支持Execute Requested是可选的，RC是否支持Execute Requested取决于具体实现，协议强制建议RC不支持Execute Requested。默认RC不支持该机制，如果RC支持，则根据具体实现使能Execute Requested比特。
Privileged Mode Requested
当PASID存在时，PASID的值跟Requester ID的值一起定义了该笔请求需要处理的地址空间ID。PASID只能存在于几种特定类型的TLP中：
- 该表请求包含Address Type(AT)字段,类型为Untranslated(编码为00b)或者Translated(编码为10b)
- Flit模式下的地址翻译请求(Address Translation Requests,比如MRd中AT为10b)，ATS无效请求消息，页请求消息(Page Request Messages)，地址路由消息(Address routed mesages)
- PRT响应消息(PRG Response Messages)
除上述类型的TLP外，其它所有的类型的TLP都不能携带PASID
Vendor Defined End-End TLP Prefix
Vendor Defiend End-End TLP Prefix包括VendPrefixE0和VendPrefixE1,为了最大限度地提高互操作性和灵活性，Vendor Defiend End-End TLP Prefix有以下规则：
- 组件不允许发送包含Vendor Defiend End-End TLP Prefix的TLP，除非是明确指示可用(通过vendor-specific机制)
- 使用vendor-specific机制时，对于两种编码的Vendor Defined End-End TLP Prefix，可用使用那些建议是可配置。这样做允许在单个PCI Express拓扑中同时使用两个不同的Vendor Defined End-End TLP Prefixes，而不要求每个源都了解其发送的每个TLP的最终目的地。
Root Ports with End-End TLP Prefix Supported
在Root Ports之间，能否点对点的传输包含End-End TLP Prefixes的TLPs，这一特征是可选的，并且是实现是相互独立的。如果在两个或者更多RC之间，RC支持End-End TLP Prefix路由能力，则必须在每个RC的Device Capabilities 2寄存器中的End-End TLP Prefix Supported中体现出来.
在所有设置了End-End TLP Prefix Supported的RC对，RC也不要求支持必须支持End-End TLP Prefix路由，如果在不支持的RC对，路由了带有End-End TLP Prefixes的TLP Request,RC必须把它UR; 如果是路由了带End-End TLP Prefixes的Completion，RC必须把它处理Unexpected Completion(UC)。在这两种情况下，错误都是由发送端口报告
对于支持转发由主机软件或RCiEPs（Root Complex Integrated Endpoints）发起的带有End-End TLP Prefix的TLP，必须设置End-End TLP TLP Prefix Supported比特位1。对于支持将Ingress Port(端接收到的带有End-End TLP前缀的TLP转发到RCiEPs的RC，必须设置End-End TLP Prefix SUpported比特。
如果RC都支持带End-End TLP Prefix的TLP,不同的RC允许Max End-End TLP Prefixes有不同的值。
当RC在根端口之间进行对等路由时，如果将一个TLP拆分为多个小TLP，则必须在每个小TLP中复制原TLP的End-End TLP前缀
TLP Header
Non Flit TLP Header
在non-flit模式下，所有的TLP的header都具有如下字段，根据TLP类型的不同，TLP Header可能还会包含其它额外的内容。byte 1的bit[1]为LN,但是已经弃用，所以为R
TLP Header根据包的类型，可能会含下面这些字段的一些:
| 字段 | 比特 | 含义 |
|---|---|---|
| Fmt[2:0] | byte 0 bit[7:5] | TLP格式，是否有 TLP Prefixes 这些 |
| Type[4:0] | byte 0 bit[4:0] | 与Fmt[2:0]共同决定TLP类型 |
| TC | byte 1 bit[6:4] | traffic class,用于流量控制 |
| R | byte 1 bit[1] | 保留位，以前用作轻量化通知(Lightweight Notification，简称LN) |
| TLP Hints | byte 1 bit[0] | 简称TH， 为1表示TLP Header中存在TLP Processing Hints和可选的TPH Prefix |
| TD | byte 2 bit[7] | 为1表示在TLP末尾存在TLP Digest(ECRC)，大小为1个DW， 32比特 |
| EP | byte 2 bit[6] | 为1表示TLP是poisoned的 |
| Attr[1:0] | byte 2 bit[5:4] | |
| Attr[2] | byte 1 bit[2] | |
| AT | byte 2 bit[3:2] | Address Translation，地址转换相关 |
| Length[9:0] | byte 2 bit[1:0] + byte 3 bit[7:0] | TLP中data payload的长度 |
Fmt字段
TLP的格式， byte 0 的 bit[7:5]，pcie中1个DW为4 bytes，也就是32比特。
| Fmt[2:0] | 描述 |
|---|---|
| 000b | 3 DW header， 没有数据 (无 Data Payload 字段) |
| 001b | 4 DW header， 没有数据 |
| 010b | 3 DW header， 有数据 (有 Data Payload 字段) |
| 011b | 4 DW header， 有数据 |
| 100b | TLP 前缀 |
| others | 其余剩下的编码保留 |
Type[4:0]字段
TLP的类型， byte 0 的bit[4:0]， 与 Fmt[2:0] 一起决定 TLP 的类型. Fmt 字段表示存在一个或多个TLP前缀，Type字段表示关联的 TLP 前缀类型， TLP报头的Fmt和Type字段提供了确定TLP报头剩余部分的大小所需的信息，以及包是否在报头后面包含数据负载。
| TLP 类型 | Fmt[2:0] | Type[4:0] | 描述 |
|---|---|---|---|
| MRd | 000/001 | 00000 | 内存读请求 |
| MRdLK | 000/001 | 00001 | 内存读请求锁住 |
| MWr | 010/011 | 00000 | 内存写请求 |
| IORd | 000 | 00010 | I/O 读请求 |
| IOWr | 010 | 00010 | I/O 写请求 |
| CfgRd0 | 000 | 00100 | 配置读类型 0 |
| CfgWr0 | 010 | 00100 | 配置写类型 0 |
| CfgRd1 | 000 | 00101 | 配置读类型 1 |
| CfgWr1 | 010 | 00101 | 配置写类型 1 |
| TCfgRd | 000 | 11011 | 弃用的 TLP 类型 |
| TCfgWr | 010 | 11011 | 弃用的 TLP 类型 |
| Msg | 001 | 10r2r1r0 | 消息请求， r[2:0] 指定消息路由机制 |
| MsgD | 011 | 10r2r1r0 | 有数据载荷的消息请求， r[2:0] 指定消息路由机制 |
| Cpl | 000 | 01010 | 没有数据的完成报文， 用于具有完成状态的 I/0 和 配置写. 除了成功完成以外，还用于原子操作完成和读取完成状态（I/O，配置或内存）. |
| CplD | 010 | 01010 | 有数据的完成报文， 用于内存， I/O 和 配置读完成， 也可用于原子操作完成 |
| CplLk | 000 | 01011 | 没有数据的锁定内存读完成， 只在错误情况下使用 |
| CplDlk | 010 | 01011 | 锁定内存读完成， 否则像 CplD 一样 |
| FetchAdd | 010/011 | 01100 | 提取并添加Atomicop请求 |
| Swap | 010/011 | 01101 | Unconditional Swap AtomicOp 请求 |
| CAS | 010/011 | 01110 | 比较和交换原子操作 |
| LPrfx | 100 | 0L3L2L1L0 | 本地 TLP 前缀， L[3:0] 指定本地TLP前缀类型 |
| EPrfx | 100 | 1E3E2E1E0 | 末端 TLP 前缀， E[3:0] 指定末端 TLP 前缀类型 |
| 其它编码保留 |
T9字段
TC[2:0]字段
| TC 域的值(b) | 描述 |
|---|---|
| 000 | TC0:通用IO，GPIO， 默认 TC， 每个 PCIe 设备都必须支持 |
| 001 到 111 | TC1 到 TC7， 差异化服务类， 基于加权轮询(WRR : Weighted-Round-Robin)和/或优先级的区分 |
T8字段
LN字段
byte 1 的 bit[1]， Lightweight Notification， 轻量级通知，1 表示内存请求是一个 LN 读或者写， 或者完成是 LN 完成。但是已经弃用了LN协议，所以改比特在非Flit模式为保留位。在Flit Mode下不支持改LN。
TH字段
byte 1 的 bit[0]， TLP Hints， 1 表示在 TLP header 中存在 TLP 处理提示(TPH : TLP Processing Hints) 和 TPH TLP Prefix (如果存在)
Attr字段
Attr[1:0]为byte 2的bit[5:4]，Attr[2]为byte 1的bit[2]
TD 字段
- byte 2 的 bit[7]， 1 表示 TLP Digest(后缀) 以单个双字(DW)的形式出现在 TLP 的末尾
EP 字段
- byte 2 的 bit[6]， Error Poisoned， 1 表示 TLP 无效
AT 字段
TA : Translaion Agent，转换代理。AT编码如下
| AT[1:0] | 助记符 | 含义 |
|---|---|---|
| 00b | Untranslated(未翻译) | TA会把地址当成虚拟地址或者物理地址 |
| 01b | Translation Request(翻译请求) | TA会返回一笔read completion,其地址域中的地址为转换后的地址,TA在收到一笔非memory read的memory请求时，如果AT字段为01b,TA会把该笔请求当作UR |
| 10b | 翻译(Transalted) | 在事务中的地址，已经经过ATC翻译。 |
| 11b | 保留(Reserved) | 如果收到内存请求TLP,并且AT域为11b,TA会把该TLP标记成UR(Unsupported Request) |
AT字段只在下列请求中定义：
- Non Flit模式下的内存请求
- Flit模式下基于地址路由的消息请求
在其它所有TLP中都是保留的。
Length[9:0] 字段
表明TLP中data payload的长度，TLP 的数据必须是 4-byte(1DW) 对齐， 并且只能以 DW的整数为增量
| length[9:0] | 对应的 TLP 数组载荷大小 |
|---|---|
| 00 0000 0001b | 1 DW |
| 00 0000 0010b | 2 DW |
| … | … |
| 11 1111 1111b | 1023 DW |
| 00 0000 0000b | 1024 DW |
First/Last DW Byte
Byte 使能会出现在 Memory, I/O 和 Configuration 请求. 当 Byte Enable 出现在请求的 header 中时，它位于 TLP Header 中的 Byte 7
Flit模式下的TLP Header
Flit Mode下所有TLP Header都具有如下内容
根据OHC[4:0]的值，在第一个DW后面可以跟0到7个OHC
Type字段
Type[7:0]总共256中编码，详情可参考协议。此字段是用来决定TLP的类型，FC类型，是否具有Data Payload，Header Base大小以及转换规则。
即使接收机不支持支持Type[7:0]的所有编码，但是也必须能够解码出来。如果Type[7:0]表明改TLP跟Flow Control相关，接收机必须要能够处理。
OHC字段
OHC[4:0]用于表明OHC(Orthogonal Header Content)是否存在，编码如下：
| OHC[4:0] | 含义 |
|---|---|
| 0 0000b | 不存在OHC |
| x xxx1b | 存在OHC-A |
| x xx1xb | 存在OHC-B |
| x x1xxb | 存在OHC-C |
| 0 0xxxb | 不存在OHC-E |
| 0 1xxxb | 存在OHC-E1 |
| 1 0xxxb | 存在OHC-E2 |
| 1 1xxxb | 存在OHC-E4 |
当OHC存在时，OHC必须跟在Header Base的后面(TLP中Data Payload前)，并且允许有多个OHC的组合。但是，当多个不同的OHC时，跟在Header Base后时，必须采用A-B-C-E的顺序，即OHC-A必须在OHC-B前面。
比如存在OHC-A5时，OHC-A5具有如下的格式
OHC-A5在Header Base的后面，具有下列的形式
OHC其它部分图片较多，见另外一篇文章。
TS字段
TS[2:0]字段用于表明Trailer的大小。
| 编码 | Trailer 大小 |
|---|---|
| 000b | 没有 Trailer |
| 001b | 1DW Trailer,包含ECRC |
| 010b | 1DW Trailer,内容保留 |
| 011b | 2DW Trailer,内容保留 |
| 100b | 2DW Trailer,内容保留 |
| 101b | 3DW Trailer,只有OHC-C存在时才包含IDE MAC,表明是一个IDE TLP，其它情况内容保留 |
| 110b | 4DW Trailer,只有OHC-C存在时才包含IDE MAC,表示时一个IDE TLP，其它情况保留 |
| 111b | 5DW Trailer，内容保留 |
其它字段
TC,Attr和Length字段跟non flit模式一样。
TLP Data Payload
- TLP 的长度必须是双字(DW : Double Word, 32 bit)的整数倍
- Length[9:0] 对所有消息类型(Message)的 TLP 来说是保留的, 除非是显式引用数据长度的消息类型
- 发射机的 Device Control 寄存器的 Max_Payload_Size (最大数据载荷)字段必须要为双字(DW)的整数倍, 发射机一侧，如果发送带有数据载荷的 TLP, 其 TLP 中的 Length 字段不允许超过 Max_Payload_Size 的值。
- Max_Payload_Size 只应用在带有数组载荷的 TLP, Memory Read 请求不是严格受到 Max_Payload_Size 值的约束，Memory Read 请求是由 Length 控制
- 对于 ARI 设备来说, Max_Payload_Size 只由 Function 0 设置，其它 Function 设置的 Max_Payload_Size 将被忽略
- 对于 Upstream Port来说, 如果是一个多功能设备(Multi-Function Device,MFD)并且不支持 ARI, 如果 Max_Payload_Size 在所有 Function 中都是一样设置, 发射机传输 TLP 的数组载荷不允许超过设置的 Max_Payload_Size
- 对于 Upstream Port来说, 如果是一个多功能设备且不支持 ARI, 如果 Max_Payload_Size 在所有 Function 中设置的不完全一样, 传输的TLP的数据有效载荷不能超过Max_Payload_Size设置，该设置的确定取决于具体的实现。
- 鼓励发射机实现使用生成事务的 Function 的Max_Payload_Size设置，或者在所有 Function 中使用最小的Max_Payload_Size设置。
- 软件不应该在不同的 Function 中设置不同的 Max_Payload_Size 值，除非软件意识到这样特殊实现的目的
- 接收机的 Device Control 寄存器中的 Max_Payload_Size 字段必须设置为双字的整数倍, 接受到 TLP 的数据载荷长度由 TLP 的 length 字段给出，其不能超过接收机设置的 Max_Payload_Size 大小
- 接收机必须检查是否违反这条规则，如果违反该条规则，则 TLP 是畸形(Malformed)的 TLP。这是一个与接收端口相关的报告错误。
- 对于 ARI 设备, Max_Payload_Size 只有 Function 0 决定, 其它 Function 设置的 Max_Payload_Size 将被忽略
- 对于 Upstream Port来说, 如果是一个多功能设备(Multi-Function Device,MFD)并且不支持 ARI, 如果 Max_Payload_Size 在所有 Function 中都是一样设置,接收机需要检查 TLP 的数据载荷大小不超过设置的 Max_Payload_Size 值
- 对于 Upstream Port来说, 如果是一个多功能设备且不支持 ARI, 如果 Max_Payload_Size 在所有 Function 中设置的不完全一样, 接受机需要检查 TLP 的数据载荷长度不超过 Max_Payload_Size 的设置，该设置的确定取决于具体的实现。
- 鼓励接收机实现使用事务所针对的 Function 的Max_Payload_Size设置，或者使用所有 Function 中最大的Max_Payload_Size设置。
- 软件不应该在不同的 Function 中设置不同的 Max_Payload_Size 值，除非软件意识到这样特殊实现的目的
- 对于包含数据的 TLP, 在 TLP Header 中的 length 字段必须与实际 TLP 的数据长度相匹配
- 接收机必须检查该项规则，如果违反该条规则，该 TLP 是一个畸形的 TLP. 这是一个与接收端口相关的报告错误。
- TLP Header 的 Length 字段只应用数据, TLP digest 不包含在 Length 字段所规定的长度之内
- 还剩两大条
TLP Digest 规则 – 只适用于Non Flit模式
对于任何 TLP 而言， TD 字段为 1 表明 TLP Digest 存在， 也包括TLP 末尾端到端的 CRC (end-to-end CRC， ECRC)。如果收到的 TLP 中， TD 字段与观察到的TLP长度不一致(如果TD存在)， 则该 TLP 是一个 Malformed TLP. 且需要上报错误，该错误需要跟port绑定。比如 TLP 中的 TD 字段为 1， 但是 TLP 中并没有 ECRC
如果中间一级或者最终的 PCIe 接收机不支持 ECRC 检查， 接收机必须忽略 TLP Digest。如果接收机支持 TLP 的 ECRC 检查， 接受机会把 TLP Digest 的值当作 ECRC 的值
感谢您的支持，请扫码打赏
