PCIe扫盲——TLP Header详解（一、二、三、四）

写在前面

笔者在工作中需要包个 PCIe wrapper，正在努力飞快学习 PCIe ing.
本文系转载，略做格式调整与增加解释（使用斜体表示），转自:
http://blog.chinaaet.com/justlxy/p/5100053481

转载正文

TLP Header详解（一）

事务层包（TLP）的一般格式如下图所示：

前面的文章介绍过，TLP Header为3DW或者4DW，Data Payload为1-1024DW，最后的TLP Digest（ECRC）是可选的，为1DW。

TLP Header在整个TLP的位置如下图所示，需要注意的是，TLP Header的格式和内容都会随着TLP的类型和路由方式的改变而改变。

TLP的类型和路由方式由Fmt和Type所决定，这在前面关于TLP路由的文章中已经详细的介绍过。上图显示的是各种不同格式的TLP Header的相同的部分。

每一个Field的作用与意义如下表所示：

下面分别详细地介绍一下Byte Enable，在PCIe中Data Payload的单位是DW，也就是说数据大小（地址）需要以DW作为对齐。但是很多情况下，数据的大小并不是DW的整数倍，因此PCIe引入了Byte Enable来解决这一问题。使用Byte Enable需要遵循一下原则：

· Byte Enable为高电平有效，低电平（0）表示Data Payload的对应Byte将被认为是无效的，即不被Completer使用。

· 如果有效数据小于1DW，则Last DW Byte Enable应全部为0。

· 如果Data Payload大于1DW，则First DW Byte Enable至少有一位是有效的。

· 如果Data Payload大于或等于3DW，则First DW Byte Enable和Last DW Byte Enable当中的有效位必须是连续的。即这种情况下，Byte Enable只能用于调整起始地址和结束地址。

· 如果Data Payload等于1DW，则First DW Byte Enable中的有效位可以是不连续的。

· 如果Data Payload等于2DW，则First DW Byte Enable和Last DW Byte Enable中的有效位都可以是不连续的。

· 写请求中的DW等于1，但是First DW Byte Enable中没有任何一位是有效的，也是允许的，但是这样的请求对于Completer没有任何作用。

· 如果读请求DW等于1，但是First DW Byte Enable中没有任何一位是有效的，此时Completer会返回1DW的Data Payload，只是其中的数据都是无效的。这一方式常备用于Flush Mechanism。

一个简单的Byte Enable使用的例子，如下图所示：

关于TLP的Data Payload有：

· Data Payload的大小由TLP Header中的Length决定。
· Data Payload的数据采用的是Little Endian，即低字节存放于低地址中。
· Data Payload的大小并不是有效的数据的大小，有效数据的大小是由Data Payload和Byte Enable共同决定的。

· 当TLP类型为Message时，Length一般是保留的（Reserved），除非该Message是带有数据的（MsgD）。

· TLP的Data Payload大小不得超过Max_Payload_Size的值，该值位于Device Control Register中。对于比较大的数据量，因此只能分多次进行发送。对于读请求来说，并没有Data Payload，也就是说该规则并不适用于读请求。

· 需要特别注意的是，起始地址和结束地址之间不能够跨越4KB的地址边界。

TLP Header详解（二）

下面用几个具体的例子来讲解TLP Header的格式与作用。因为内容较多，所以分为多篇文章分别进行介绍。

第一篇（即本文）介绍IO Request、Memory Request和Configuration Request。

第二篇文章（即TLP Header详解三）介绍Completion ，第三篇文章（即TLP Header详解四）介绍Message Request。

IO Request

IO Request的TLP Header的格式如下图所示：

Memory Request

Memory Request的TLP Header的格式如下图所示：

注：TLP Prefix、ID Based Ordering（IDO）和TLP Processing Hints（TH）均为PCIe Spec V2.1提出的。

Configuration Request

Configuration Request的TLP Header的格式如下图所示：

TLP Header详解（三）

Completions

Completions的TLP Header的格式如下图所示：

这里来解释一下Completion Status Codes

· 000b (SC) Successful Completion：表示请求（Request）被正确的处理；

· 001b (UR) Unsupported Request：表示请求是非法的或者不能被Completer所识别的。在PCIe V1.1以及之后的版本将这作为Advisory Non-Fatal Error；

· 010b (CRS) Configuration Request Retry Status：Completer暂时不能响应的配置请求，需要Requester稍后再次尝试；

· 100b (CA) Completer Abort：Completer可以响应该请求，但是却发生了其他的错误，该错误是Uncorrectable Error。

关于CplD，需要注意的是：

· 前面的文章中多次提到，一个读请求可能会对应多个CplD（因为4KB的地址边界问题，以及RCB的限制），但是返回的总的数据量应当与请求的数据量保持一致，否则可能会出现Completion Timeout的错误；

· 一个Completion只能对应于一个Request；

· IO和Configuration读请求由于一直都是1DW，因此其一直都只对应一个Completion；

· 当Completion中的状态码（Status Codes）为SC（Successful）之外的状态，则一次传输（事务，Transaction）被终止；

· 在处理一个请求多个CplD时，应当注意Read Completion Boundary（RCB），RCB的值可以是64Bytes或者128Bytes；

· Bridge和Endpoint应设计为RCB的大小是可以通过软件修改或控制的；

· 在处理一个请求多个CplD时，应注意先发送的是低地址的数据，后发送高地址数据。

Requester接受到Completion的处理规则：

· 如果Requester接收到的Completion与自己之前发送的Request不一致，则会报错；

· 当Completion中的状态码不是SC或者CRS的话，则会报错，并且相关的Buff都会被清空；

· 当任何非配置请求的Completion中的状态码为CRS时，都会被认为是非法的，并被认为是Malformed TLP；

TLP Header详解（四）

PCIe中的Message主要是为了替代PCI中采用边带信号，这些边带信号的主要功能是中断，错误报告和电源管理等。所有的Message请求采用的都是4DW的TLP Header，但是并不是所有的空间都被利用上了，例如有的Message就没有使用Byte8到Byte15的空间。

Message请求的TLP Header格式如下图所示：

上面的表格中提到了，Message主要有九个类型：

INTx Interrupt Signaling
Power Management
Error Signaling
Locked Transaction Support
Slot Power Limit Support
Vendor‐Defined Messages
Ignored Messages (related to Hot‐Plug support in spec revision 1.1)
Latency Tolerance Reporting (LTR)
Optimized Buffer Flush and Fill (OBFF)

下面将分别进行介绍一下，

INTx Interrupt Messages（中断消息）

PCI 2.3提出了MSI（Message Signaled Interrupt），但是早期的PCI并不支持这一功能，PCIe为此定义了一种Virtual Wire来模拟PCI的中断引脚（INTA-INTD）。如下图所示：

Power Management Messages（电源管理消息）

Error Messages（错误消息）

Locked Transaction Support

Set Slot Power Limit Message

Vendor‐Defined Message 0 and 1

Latency Tolerance Reporting Message

Optimized Buffer Flush and Fill Messages