PCIE-Malformed tlp，UR，UC，CA

Malformed TLP

(1)收到的cpl，actual payload 不等于length；

(2)收到的cpl，违背了RCB准则；

(3)Local tlp prefix不在end-end tlp prefix前；

(4)不支持local tlp prefix的设备，同时extended fmt field为1的设备收到了local tlp prefix（注意如果extended fmt field为0，收到了tlp prefix的话，由设备决定这个tlp的处理方式）；

(5)收到的end-end tlp prefix超过四个（协议最大允许4个）。对于RP来说，如果收到了大于Max End-End TLP Prefixes field的prefix的话，对于请求来说，建议将其认为是UR，对于cpl来说建议是UC（对于请求和建议来说，如果不遵循的话那么必须认为是Malformed TLP ）；对于其他function来说也是类似；

(6)收到了不支持的end-end tlp prefix类型；

(7)有tlp prefix但是没有tlp header；

(8)Extended fmt field为1 但是 fmt和type的组合是reserved的；fmt[2]为0的情况下type为reserved；

(9)收到的TLP的length超过Rx_MPS_Limit；

(10)收到的TLP所对应的TD域（表示是否有tlp digest）和实际的长度尺寸不符合；

(11)收到的TLP违背了byte enable准则；

(12)对于原子操作来说，接收者收到的TLP长度和规定的长度不同；另外原子操作的请求必须以规定的方式字节对齐，如果没有按照规定的方式字节对齐，接收者将认为这个tlp是Malformed；

(13)接收者接收到的TLP包的address和lengthe结合超过了4Kb边界；

(14)对于IO操作，要求tc，th，attr，at，last be均为0，length为1，违背这个的IO操作被认为是Malformed；

(15)只有up port能够发送Assert_INTx/Deassert_INTx Messages，如果收到了down port的Assert_INTx/Deassert_INTx Messages，那么认为是Malformed的tlp包，另外中断msg、power management msg、error msg要求使用default Traffic Class，违背的话也是被认为Malformed。

置为1的情况下，malformed tlp报告fatal error。 

UR（对应completion的status域为ur）

（1）completion status域为reserved，那么认为completion是ur属性的；

（2）由于design或者配置setting而导致的设备不支持的request；

（3）msg中各个域的组合是undefied的，或者说这个msg是这个设备不支持的msg（除了vender define的msg）；

（4）msg的dstid所对应的function没有实现；

（5）ecrc检查失败，可以回cpl，也可以不回，但是如果回的回的status必须为ur；

（6）FLR开始和结束直接收到了request，可以回ur也可以不做处理；

Unexpected Completion

 （1）larger-Tag的请求者发给了一个请求给缺少” larger-Tag”功能的completer，那么回应的completion的tag是无效的tag，这个completion是Unexpected Completion（注意实际上对于请求者来说，由于回应的tag是无效的，所以大概率是针对这个请求的处理是把他作为timeout来处理）；

（2）对于RP来说，如果收到了大于Max End-End TLP Prefixes field的prefix的话，对于请求来说，建议将其认为是UR，对于cpl来说建议是UC（对于请求和建议来说，如果不遵循的话那么必须认为是Malformed TLP ）

（3）如果一共function的upstream port的End-End TLP Prefix功能支持的话，如果收到了一个不支持的end-end tlp prefix type的completion的话，所有和这个upstream port相关的function都要把这个completion认为是UC

（4）设备收到了一个和之前发的请求的Transaction ID都不一样的cpl，那么设备会把这个cpl认为是UC（如果这个cpl的Transaction ID能对应上，但是其他域对不上，也是把他认为是UC）

（5）假如再FLR开启结束之间收到了cpl，这个cpl可以认为是UC，也可以不做任何处理，但是如果是FLR结束之后收到了FLR之前发起的请求对应的cpl，那么必须认为是UC

这里再以pcie5.0 data book中的具体例子阐述相关情况： 

SU: Successful Completion “CPL Status”

MLF: Malformed

UC: Unexpected CPL

MA: (Received) Master Abort set in “PCI-compatible Status Register”

TA: (Received) Target Abort set in “PCI-compatible Status Register”

		mem read/IO read	mem write/IO write	CFG	MSG	cpl(UR/CA/CRS)	cpl(su)
1	当前状态非D0	UR	UR	SU	SU	UC	UC
2	IO操作的情况下，访问地址不在配置memory bar、IO bar之内的	UR	UR
3	TLP中ep为1	UR	UR	UR	UR	SU	SU
4	EP收到了cfg type1的request			UR
5	cfg request的ID号和接收端的bdf不匹配			UR
6	收到了无效的message				UR/MLF
7	message的payload长度是非法的				UR
8	Vendor msg的处理
9	收到ECRC错误的TLP	CA	CA(io only)	CA
10	写操作payload超过Max_payload_size，读操作长度超过Max_Read_Request_Size	MLF	MLF
11	Request id不匹配，tag不匹配					MA/TA	MLF
12	针对tag，原本是reserved的域不是0					MA/TA	MLF
13	Byte Count Mismatch					MA/TA	UC/MLF
14	收到带有CRS状态的CPL，且CPL不是待处理的cfg req					MLF

 2：IO操作的情况下，访问地址不在配置的memory bar、IO bar之内：如何去申请一段IO访问空间或申请一段memory 访问空间？？

PCIe扫盲:Memory & IO 地址空间/基地址寄存器详解/Base & Limit寄存器详解 - 极术社区 - 连接开发者与智能计算生态 (aijishu.com)

5：The function number of a completer ID within a CFG request does not match an implemented function within the receiver device:cfg request的ID号和接收端的bdf不匹配??

8：不同厂商针对这一部分处理不同，协议上的要求是： 针对type0，如果completer没有支持的话，回UR处理；针对type1，如果completer没有支持的话，直接丢掉。

10：Max_payload_size/Max_Read_Request_Size：注意单位，前者是B，后者是DW；

PCIe学习笔记之Max payload size-CSDN博客

PCIe一些系统参数（MPS, MRRS, RCB）的深度解析_pcie mrrs-CSDN博客

PCIe Max_Payload_Size 和 Max_Read_Request_Size - Michael_Tong唐唐 - 博客园 (cnblogs.com)

关于上述参数的一些说明：

（1）除了显式引用数据长度的消息，其他消息中length[9:0]都是保留域；

（2）传输带有数据有效载荷的TLP的function不允许TLP的length字段所指示的数据有效载荷长度超过function的适用Max_Payload_Size（MPS）设置。如果函数的Mixed_MPS_Supported位为0或请求的目标为host memory，则适用的MPS设置必须是function的计算的Tx_MPS_Limit。

（3）如果Mixed_MPS_Supported位为1，function必须有一个特定的机制，能够为不同的目标支持不同的MPS设置，并且必须同时处理request和completion tlp。特定于目标的MPS设置允许高于或低于function的Tx_MPS_Limit，但绝不能超function数的Max_Payload_Size Supported字段值。

（4）function的Tx_MPS_Limit确定如下:

对于single-Function设备，Tx_MPS_Limit必须是它的Max_Payload_Size字段值；

对于ARI设备，Tx_MPS_Limit必须是function 0中的MPS值。MFD （Multi-Function Device ）中其他function中的MPS设置必须忽略；

对于Non-ARI的MFD（Multi-Function Device ）中所有function的MPS设置相同的function，Tx_MPS_Limit必须是一个公共MPS设置值；

对于Non-ARI的MFD中的function，其MPS设置在各个function中都不相同，Tx_MPS_Limit必须是某个function中的MPS设置值；（建议Transmitter实现使用生成事务的function中的MPS设置，或者使用所有function中最小的MPS设置；软件不应该将不同function中的MPS设置配置为不同的值）；

MPS设置仅适用于具有数据有效载荷的tlp;内存读请求的长度不受MPS设置的限制。内存读请求的大小由TLP的Length字段控制。

（5）接收的TLP中的数据有效载荷大小由TLP的Length字段指示，不能超过为接收函数计算的Rx_MPS_Limit，由mps相关参数确定，如下所示：

接收方必须检查是否违反此规则。如果接收方确定TLP违反了此规则，则该TLP必须作为畸形TLP处理，这是和Receiving Port相关的错误；

在接收function中，如果设置了Rx_MPS_Fixed位，则Rx_MPS_Limit必须是Max_Payload_Size Supported字段。否则，Rx_MPS_Limit必须由一个或多个function中的Max_Payload_Size字段(“MPS设置”)确定，如下所示:

**对于single-Function，Rx_MPS_Limit必须是其MPS设置值。

**对于ARI设备，Rx_MPS_Limit必须是function 0中的MPS设置值。其他function中的MPS设置必须忽略。

**对于与Non-AIR的MFD相关联的上游端口，其MPS设置在所有function中都是相同的，Rx_MPS_Limit必须是公共MPS设置值。

**对于和Non-AIR MFD相关联的上游端口，其MPS设置在所有function中都不相同，Rx_MPS_Limit必须是实现特定函数中的MPS设置值。

（建议接收方实现使用事务目标函数的MPS设置，或者使用所有函数中最大的MPS设置）

12：关于pcie中的tag处理：

PCIe 6.0为什么需要14-bit tag_pcie tag的作用 csdn-CSDN博客

13： Byte Count Mismatch：注意byte count中的值是以byte为单位，byte count表示的是剩下还有多少byte没有传输，这个剩下的内容是包含当前tlp中的内容的，比如需要128，第一次cpl里有64B，但是注意此时byte count还是128。如果byte count的值和cpl的内容不匹配就是Byte Count Mismatch。

补充说明：

RCB:

Read Completion Boundary (RCB)切分规则-CSDN博客

PCIe协议之RCB、MPS、MRRS详解 (ppmy.cn)

【PCIe】PCIe 读完成边界 (RCB) 介绍_pcie rcb-CSDN博客

byte conunt：

BCM和Split Transaction_pcie bcm-CSDN博客

lower address：

【PCIe】First/Last DW Byte Enables 介绍_zero read-CSDN博客

lower address为什么要 7bit？？为什么要7bit就够了？？

按理说，要么要两bit用来指示cpl的byte enable，要么给一个和地址长度一样的位数，但是现在是用了7bit这是为啥？？

For the first (or only) Completion, the Completer can generate this field from the least significant 5 bits of the address of the Request concatenated with 2 bits of byte-level address formed as shown in § Table 2-41.

网上说法：根据lengteh来的。

为什么pcie的完成包的Lower Address字段，只需要7个bit呢 - 数字IC设计讨论(IC前端|FPGA|ASIC) - EETOP 创芯网论坛 (原名：电子顶级开发网) -

14：Config Req Retry Status（CRS）配置请求重试状态， Completer 临时的无法服务一个配置请求，因此这个请求应该稍后再次尝试[Completion Status CRS (Configuration Request Retry Status) 改叫 RRS (Request Retry Status) ]；

这里有个问题，databook原有描述是：

“CPL received with CRS status and CPL is not a pending configuration request“

那么问题来了，收到一个带CRS的cpl的时候设备怎么判断他是否是一个”pending configuration request“？？还是说这里指的是设备没有发这个的cfg req，但是收到了相应tag的带CRS的cpl？？

一些待确定的点：

（1）Application requests the controller filter to return CRS by asserting signal app_req_retry_en/app_pf_req_retry_en:???

（2）Address within a BAR that is configured to TRGT0 and TLP DW length > 1:？？

 （3）MRd with lock and filter mask CX_FLT_MASK_LOCKED_RD_AS_UR bit is not set:？？