PCIe Base Specification解析（二）

---

2 .Transaction Layer Specification

2.1 Transaction Layer Overview

Figure 2-1: Layering Diagram Highlighting the Transaction Layer

从上层逻辑看，事务层的关键点是：

• 流水线式的完整的split-transaction协议。
• 事务层数据包（TLP）的排序和处理。
• 基于信用的流控制机制。
• 可选支持的数据中毒功能和端到端数据完整性检测功能。

事务层包含以下内容：

• TLP构造和处理。
• 流控机制和虚通道管理。
• TLP排序和管理。
  • PCI/PCI-X兼容的排序。
  • TC处理。

2.1.1 Address Spaces, Transaction Types, and Usage

Table 2-1 Transaction Types for Different Address Spaces

Address Space	Transaction Types	Basic Usage
Memory	Read Write	Transfer data to/from a memory-mapped location
I/O	Read Write	Transfer data to/from an I/O-mapped location
Configuration	Read Write	Device Function configuration/setup
Message	Baseline (including Vendor-Defined)	From event signaling mechanism to general purpose messaging

2.1.1.1 Memory Transactions

包括：读请求／完成、写请求、原子操作请求／完成；分32bit地址格式和64bit地址格式。

某些内存事务可以带有Process Address Space ID (PASID）的PASID TLP Prefix。详细请参见Section 6.20。

2.1.1.2 I/O Transactions

PCI Express支持I/O空间，以与传统设备兼容。本规范的未来修订版可能会弃用I/0空间。I/0事务包括：读请求／完成、写请求／完成。I/O事务只有32bit地址格式。

2.1.1.3 Configuration Transactions

配置请求包括：读请求／完成、写请求／完成。

2.1.1.4 Message Transactions

消息事务或简称为消息，用于支持设备之间事件的带内通信。

除了指定的消息外，PCI Express还使用指定的消息代码为供应商定义的消息提供支持。特定的供应商定义的消息的定义不在本文档的范围之内。

该规范建立了一个标准框架，供应商可以在其中指定自己的供应商定义的消息，这些消息经定制以适应其平台的特定要求（请参阅 Section 2.2.8.5和Section 2.2.8.7）。

请注意，不能保证这些供应商定义的消息可与其他供应商的组件互操作。

2.1.2 Packet Format Overview

Figure 2-2: Serial View of a TLP

Figure 2-2表示了在链路上串行传输的TLP的顺序，最左边一个字节最先发送或接收。

Figure 2-3中表示的TLP Prefix,TLP Header 和 TLP Digest的位置，其中低编号的字节绘制在左侧，而PCI规范低编号的字节绘制在右侧。Header的布局针对串行互连上的性能进行了优化，这是因为首先传输时间最紧迫的信息所驱动的。例如，在TLP header 中，首先传输地址字段的最高有效字节，以便可以将其用于早期地址解码。

Figure 2-3: Generic TLP Format

TLP内的有效载荷数据以最低寻址字节（Figure 2-3所示）显示在左上方。描述数据结构组织的详细布局（例如Chapter 7中描述的配置空间）保留了传统的PCI字节布局，并在右侧显示了最低的寻址字节。无论如何描述，所有字节在概念上都以递增的字节数顺序在链路上传输。

根据数据包的类型，该Packet header 包含以下字段：

• Format of the packet
• Type of the packet
• Length for any associated data
• Transaction Descriptor, including:
  • Transaction ID
  • Attributes
  • Traffic Class
• Address/routing information
• Byte Enables
• Message encoding
• Completion status

2.2 Transaction Layer Protocol - Packet Definition

四种事务类型：Memory、I/O、Configuration和Messages。两种地址格式：32bit和64bit。

构成TLP时，所有标记为Reserved的字段（有时缩写为R）都必须全为0。接收者必须忽略此字段中的值，Switch必须对其进行原封不动的转发。请注意，对于某些字段，既有指定值又有Reserved值-在这些情况下，按Reserved值的方式处理。

2.2.1 Common Packet Header Fields

所有TLP的prefix和header都包含以下定义字段，如Figure 2-4所示：

• Fmt[2:0]-Format of TLP (see Table 2-2) - bits 7:5 of byte 0
• Type[4:0]-Type of TLP- bits 4:0 of byte 0

Figure 2-4 Fields Present in All TLPS

Fmt字段还指示是否存在一个或多个TLP Prefix,Type字段指示相关的TLP Prefix的类型。

TLP header的Fmt和Type字段确定了TLP header是3DW还是4DW，还确定了header之后是否包含数据有效载荷。

TLP header的Fmt,Type,TD和Length字段确定了非前缀TLP的大小所需的所有信息。Type字段除了定义TLP的类型外，还决定了Switch如何路由TLP。以下各节将详细讨论不同类型的TLP。

• Fmt[2:0］和Type[4:0］字段的值定义如 Table 2-3。
  • 所有其他编码都是保留的（see Section 2.3）。
• TC[2:0]-Traffic Class (see Section2.2.6.6)-bits [6:4] of byte 1。
• Lightweight Notification(LN)-此1bit表示内存请求是LN Read或LN Write，或者完成是LN
  Completion。
• TLP Hints(TH)-1bit值表示在TLP header中存在TPH(TLP Processing
  Hints）信息以及可选的TPH TLP Prefix,- bit 0 of byte 1 (see Section 2.2.7.1)。
• Attr[1:0]-Attributes (see Section 2.2.6.3)-bits [5:4] of byte 2。
• Attr[2]-Attribute (see Section 2.2.6.3)- bit 2 of byte 1。
• TD-1bit值表示在TLP末尾以单个DW的形式存在TLP摘要（see Section 2.2.3)- bit 7 of byte
  2。
• Error Poisoned(EP)-表示该TLP是中毒的TLP(see Section 2.7)-bit 6 of byte 2。
• Length[9:0]-表示以DW为单位的Data Payload的长度（see Table 2-4 ) - byte
  2[1:0]+byte 3[7:0］。
  • TLP数据必须自然对齐4字节，并以4字节双字（DW）为增量。
  • Cpl,CplLk和一些Message保留此字段值。

Figure 2-5 Fields Present in All TLP Headers

Table 2-2 Fmt[2:0] Field Values

Fmt[2:0]	Corresponding TLP Format
000b	3 DW header, no data
001b	4 DW header, no data
010b	3 DW header, with data
011b	4 DW header, with data
100b	TLP Prefix
	All encodings not shown above are Reserved (see Section 2.3).

Table 2-3 Fmt[2:0] and Type[4:0] Field Encodings

TLP Type	Fmt [2:0]3(b)	Type [4:0](b)	Description
MRd	000 001	0 0000	Memory Read Request
MRdLk	000 001	0 0001	Memory Read Request-Locked

TLP Type	Fmt [2:0](b)	Type [4:0](b)	Description
MWr	010 011	0 0000	Memory Write Request
IORd	000	0 0010	I/O Read Request
IOWr	010	0 0010	I/O Write Request
CfgRd0	000	00100	Configuration Read Type 0
CfgWro	010	0 0100	Configuration Write Type 0
CfgRd1	000	00101	Configuration Read Type 1
CfgWr1	010	00101	Configuration Write Type 1
TCfgRd	000	11011	Deprecated TLP Type4
TCfgWr	010	11011	Deprecated TLP Type5
Msg	001	10r2r1ro	Message Request-The sub-field r[2:0] specifies the Message routing mechanism (see Table 2-17).
MsgD	011	10r2r1ro	Message Request with data payload- The sub-field r[2:0] specifies the Message routing mechanism (see Table 2-17).
Cpl	000	01010	Completion without Data - Used for I/O and Configuration Write Completions with any Completion Status. Also used for AtomicOp Completions and Read Completions (1/0, Configuration, or Memory) with Completion Status other than Successful Completion.
CpID	010	01010	Completion with Data -Used for Memory, I/O, and Configuration Read Completions.Also used for AtomicOp Completions.
CplLk	000	01011	Completion for Locked Memory Read without Data-Used only in error case.
CplDLk	010	01011	Completion for Locked Memory Read-Otherwise like CplD.
FetchAdd	010 011	01100	Fetch and Add AtomicOp Request
Swap	010 011	01101	Unconditional Swap AtomicOp Request
CAS	010 011	01110	Compare and Swap AtomicOp Request
LPrfx	100	0 L3L2L1Lo	Local TLP Prefix-The sub-field L[3:0] specifies the Local TLP Prefix type (see Table 2-36).
EPrfx	100	1 E3E2E1Eo	End-End TLP Prefix- The sub-field E[3:0] specifies the End-End TLP Prefix type (see Table 2-37).
			All encodings not shown above are Reserved (see Section 2.3).

Table 2-4 Length[9:0] Field Encoding

Length[9:0]	Corresponding TLP Data Payload Size
00 0000 0001b	1 DW
00 0000 0010b	2 DW
...	...
11 1111 1111b	1023 DW
00 0000 0000b	1024 DW

注释3：两个Fmt值的意思是其中一个使用32bit地址格式，另一个使用64bit地址格式。

注释4,5：不推荐使用的TLP类型：以前用于受信任的配置空间（Trusted Configuration Space,TCS)，此规范不再支持。如果接收方未实现TCS，则接收方必须将此类请求视为格式错误的数据包。

2.2.2 TLPs with Data Payloads- Rules

• Length字段用于指定有多少个DW。

• 对于所有Message,Length[9:0］为Reserved值，除了那些显式引用数据长度的Message。

  • 参阅Section 2.2.8的消息编码表获取更多信息。

• 发送器不允许发送的TLP中的Length字段的值超过Device Control寄存器的Max_Payload_Size字段定义的值的TLP(see Section 7.5.3.4)。

  • 对于ARI设备，Max_Payload_Size仅由Function 0中设置的值确定。其他Function中的Max_Payload_Size将被忽略。
  • 对所有Function上的Max_Payload_Size设置值都相同的non-ARI Multi-Function Device(MFD）的Upstream Port，传输的TLP的数据有效载荷不得超过通用的Max_Payload_Size设置值。
  • 对所有Function上的Max_Payload_Size设置值不相同的non-ARI multi-Function设备的Upstream Port，传输的TLP的数据有效载荷不得超过Max_Payload_Size设置值，具体根据实现定义。
    • 建议发送器的实现使用生成事务的Function中的Max_Payload_Size设置值，或者使用所有Function中最小的Max_Payload_Size设置值。
    • 除非软件知道特定的实现，否则软件不应将不同Function中的Max_Payload_Size设置为不同的值。
  • Note:Max_Payload_Size 仅适用于具有数据有效负载的TLP。Memory Read Request的长度不受Max_Payload_Size的限制。Memory Read Request的大小由 Length字段控制。

• 接收器接收到的TLP中的Length字段的值不得超过Device Control寄存器的Max_Payload_Size字段定义的值（see Section 7.5.3.4)。

  • 接收器必须检查是否违反此规则。如果接收器确定TLP违反此规则，则该TLP是一个Malformed TLP。
    • 这是报告的与接收端口相关的错误（请参见Section 6.2）。
  • 对于ARI设备，Max_Payload_Size仅由Function0中设置的值确定。其他Function中的Max_Payload_Size将被忽略。
  • 对所有Function上的Max_Payload_Size设置值都相同的non-ARI multi-Function 设备的Upstream Port，接收器将按通用的Max_Payload_Size 设置检查TLP的数据有效载荷大小。
  • 对所有Function上的Max_Payload_Size设置值不相同的non-ARI multi-Function 设备的Upstream Port，接收器如何检查Max_Payload_Size 设置值是根据实现定义的。
    • 建议接收器实现使用事务目标的Function中的Max_Payload_Size设置，或者使用所有Function中最大的Max_Payload_Size设置。
    • 除非软件知道特定的实现，否则软件不应将不同Function中的Max_Payload_Size设置为不同的值。

• 对于包含数据的TLP,Length字段中的值和TLP中包含的实际数据量必须匹配。

  • 接收器必须检查是否违反此规则。如果接收器确定TLP违反此规则，则该TLP是一个Malformed TLP。
    • 这是报告的与接收端口相关的错误（请参见Section 6.2）。

• Length字段中的值仅适用于数据-Length字段中不包括TLP Digest。

• 当除AtomicOp Request 或AtomicOp Completion之外的其他TLP中包含数据有效载荷时，header后的数据的第一个字节对应于最接近零的字节地址，并且后续字节按递增的字节地址顺序排列。

  • 示例：向地址100h写入16字节，header后的第一个字节将是要写入地址为100h的字节，第二个字节将被写入地址101h，依此类推，最后一个字节被写入地址10Fh。

• 必须对AtomicOp Request和AtomicOp Completion 中的数据有效载荷进行格式化，以使TLP header之后的数据的第一个字节是第一个数据的最低有效字节，而随后的数据字节的重要性严格增加。对于CAS Request，第二个数据紧跟在第一个数据之后，并且必须采用相同的格式。

  • AtomicOp Completer读取和写入目标地址的数据的字节序格式是特定于实现的，并且允许为Completer指定适合目标内存的任何格式（例如，little endian或big endian）。AtomicOp Completer的字节序格式功能的报告和控制不在本规范的范围之内。

  • Little endian的例子：对于目标内存为Little endian的64bit的Swap Request的目标地址100h,header后的第一个字节写入地址100h，第二个字节写入地址101h，并且依此类推，最后一个字节写入位置107h。请注意，在执行写操作之前，Completer首先读取目标存储器地址，以便它可以在完成中返回原始值。Completion中与数据对应的字节地址与Request中的相同。

  • Big endian的例子：对于目标内存为Big endian的64bit的Swap Request的目标地址100h,header后的第一个字节写入地址107h，第二个字节写入地址106h，依此类推，将最后一个字节写入地址100h。请注意，在执行写操作之前，Completer首先读取目标存储器地址，以便它可以在完成中返回原始值。Completion与数据对应的字节地址与Request 中的相同。

  • Figure2-6显示了针对64bit的FetchAdd的Completer目标内存访问的小端和大端示例。操作数和结果中的字节编号为0-7，字节0为最低有效位，字节7为最高有效位。在每种情况下，Completer都使用适当的字节序格式获取目标内存操作数。接下来，Completer中的AtomicOp计算逻辑使用原始目标内存值和FetchAdd请求中的“add值执行FetchAdd 操作。最后，Completer使用与读取相同的字节序格式将FetchAdd结果存储回目标内存。

Figure 2-6 Examples of Completer Target Memory Access for FetchAdd

IMPLEMENTATION NOTE

Endian Format Support by RC AtomicOp Completers

允许AtomicOp Completer使用其选择的字节序格式访问目标内存的一个关键原因是，使以AtomicOps为目标内存的PCI Express 设备可以与使用原子操作指令（或指令序列）的主机软件进行互操作。某些主机环境对原子操作的字节序格式支持有限，并且通过支持“正确”字节序格式，RC AtomicOp Completer 可以显着提高互操作性。

对于在仅支持Little Endian字节序处理器的平台上具有AtomicOp Completer功能的RC,RC AtomicOp Completer支持除 Little Endian 以外的任何字节序格式几乎没有好处。对于在支持双字节序处理器的平台上具有AtomicOp Completer 功能的RC，在支持Little Endian字节序和Big Endian字节序格式以及可能为主机内存的不同区域配置字节序格式方面可能会有好处。

没有PCI Express 设备要求RC AtomicOp Completer 支持主机处理器的“本机”字节序格式（如果有的话），这样做也不会有任何好处。例如，某些处理器可以使用load-link/store-conditional或类似的指令序列以非本机字节序格式进行原子操作，因此不需要RC AtomicOp Completer 支持其他字节序格式。

IMPLEMENTATION NOTE

Maintaining Alignment in Data Payloads

Section 2.3.1.1讨论了有关形成某些自然地址边界的读取完成的规则。通过在Write Request添加遵守相似的地址边界的信息，可以显著提高内存写入性能。具体而言，形成Write Request以遵守64或128字节的自然地址边界将有助于提高系统性能。这是一个再常见不过的经验法则，这样做会降低硬件处理字节不对齐的复杂度，因而提高系统性能。

2.2.3 TLP Digest Rules

• 对于任何TLP,TD字段中的值为1b表示存在TLP Digest字段，该字段包括TLP末尾的ECRC值。
  • TD字段值与观察到的大小不对应（考虑到数据有效载荷，如果存在的话）的TLP是一个Malformed的TLP。
    • 这是报告的与接收端口相关的错误（请参见Section 6.2）。
• 如果中间设备或最终PCI Express接收器不支持ECRC检查，则接收器必须忽略TLP Digest。
  • 如果TLP的接收方支持ECRC检查，则接收方会根据Section 2.7.1中的规则将TLP Digest字段中的值解释为ECRC值。

2.2.4 Routing and Addressing Rules

TLP有三种路由机制：地址路由、ID路由和隐式路由。本节定义了地址路由和ID路由机制的规则。隐式路由仅与消息请求一起使用，并在Section 2.2.8中介绍。

2.2.4.1 Address Based Routing Rules

• 地址路由用于Memory请求和I/0请求。
• 有两种地址格式：32bit地址的3DW header(see Figure 2-8）和64bit地址的4DW header(see
  Figure 2-7）。

Figure 2-7 64-bit Address Routing

Figure 2-8 32-bit Address Routing

• 对于Memory Read、Memory Write 和 AtomicOp Request, Address Type
  (AT）字段的编码如Table 10-1所示。对于所有其他请求，除非另有明确说明，否则AT字段为保留字段。LN Read和LN Write
  对AT字段有特殊的要求，参见Section 6.21.5节。

Table 10-1 Address Type(AT) Field Encodings

AT[1:0]Coding	Mnemonic	Meaning
00b	Untranslated	A TA may treat the address as either virtual or physical.
01b	Translation Request	The TA will return the translation of the address contained in the address field of the request as a read completion. This value only has meaning for an explicit Translation Request (see Section 10.2.2). The TA will signal an Unsupported Request (UR) if it receives a TLP with the AT field set to 01b in a Memory Request other than Memory Read.
10b	Translated	The address in the transaction has been translated by an ATC. If the Function associated with the SourcelD is allowed to present physical addresses to the system memory, then the TA might not translate this address. If the Function is not allowed to present physical addresses, then the TA may treat this as an UR.
11b	Reserved	The TA will signal an Unsupported Request (UR) if it receives a Memory Request TLP with the AT field set to 11b.

• 如果TH字段设置为1，则PH字段编码如Table 2-15所示。如果TH字段清0，则PH字段为保留值。

Table 2-15 Processing Hint Encoding

PH[1:0](b)	Processing Hint	Description
00	Bi-directional data structure	Indicates frequent read and/or write access to data by Host and device
01	Requester	Indicates frequent read and/or write access to data by device
10	Target	Indicates frequent read and/or write access to data by Host

11

Target with Priority

Indicates frequent read and/or write access by Host and indicates high temporal locality for accessed data

• TLP header 中地址字段的分布如Table 2-5所示。

Table 2-5 Address Field Mapping

Address Bits	32-bit Addressing	64-bit Addressing
63:56	Not Applicable	Bits 7:0 of Byte 8
55:48	Not Applicable	Bits 7:0 of Byte 9
47:40	Not Applicable	Bits 7:0 of Byte 10
39:32	Not Applicable	Bits 7:0 of Byte11
31:24	Bits 7:0 of Byte 8	Bits 7:0 of Byte 12
23:16	Bits 7:0 of Byyte 9	Bits 7:0 of Byte 13
15:8	Bits 7:0 of Byte 10	Bits 7:0 of Byte 14
7:2	Bits 7:2 of Byte 11	Bits 7:2 of Byte 15

• Memory Read、Memory Write 和AtomicOp Request 可以使用3DW header，也可以使用4DW header。

  • 对于低于4GB的地址，请求者必须使用32位格式。如果接收到地址低于4GB的64位格式请求（即地址的高32位全为0)，则未指定接收器的行为。

• I/O Read Request 和I/O Write Request 只能用32bit地址格式。

• 所有设备都必须解码header中的所有地址字段-不允许使用别名。

IMPLEMENTATION NOTE

Prevention of Address Aliasing

为了软件能正确操作，即使系统硬件架构师或设计人员知道丢64位地址格式在系统中有实际意义，也需要进行全地址解码。

2.2.4.2 ID Based Routing Rules

• 配置请求、基于ID路由的消息以及Completion TLP会使用ID路由。该规范定义的使用ID路由的消息如Table F-1所示。允许其他规范定义其他ID路由消息（如ATS）。
• ID路由使用总线号，设备号和功能号来指定TLP的目的地：
  • 对于non-ARI Routing ID，总线号、设备号和3-Bit功能号到TLP header的映射如 Table 2-6,Figure
    2-9和 Figure 2-11所示。
  • 对于ARI Routing ID，总线号和8-Bit的功能号到TLP header的映射如 Table 2-7,Figure
    2-10和Figure 2-12所示。
• 规范指定了两种ID路由格式，一种用于4DW头（Figure 2-9和Figure 2-10)，一种用于3DW头（Figure 2-12和Figure 2-10）。
  • 参阅Figure 2-5获取TLP Header的各字段分布。

Table 2-6 Header Field Locations for non-ARI ID Routing

Field	Header Location
Bus Number[7:0]	Bits 7:0 of Byte 8
Device Number[4:0]	Bits 7:3 of Byte 9
Function Number[2:0]	Bits 2:0 of Byte 9

Table 2-7 Header Field Locations for ARI ID Routing

Field	Header Location
Bus Number[7:0]	Bits 7:0 of Byte 8
Function Number[7:0]	Bits 7:0 of Byte 9

Figure 2-9 Non-ARI ID Routing with 4 DW Header

Figure 2-10 ARI ID Routing with 4 DW Header

Figure 2-11 Non-ARI ID Routing with 3 DW Header

Figure 2-12 ARI ID Routing with 3 DW Header

2.2.5 First/Last DW Byte Enables Rules

Byte Enable 包含在Memory、I/O和 Configuration Request中。本节定义了相应的规则。Byte Enable 位于header的byte 7 (see Figure 2-13）。对于TH字段值为1的Memory Read Request, Byte Enable 字段被重新指定为携带ST[7:0］字段（有关详细信息，请参见Section 2.2.7.1)，并且如下隐含的定义了Byte Enable的值。Memory Read Request中的TH字段在这种情况下必须设置为1：当看起来像是可以完成这些请求（就好像所请求数据的所有字节都使能一样）。

Figure 2-13 Location of Byte Enables in TLP Header

• 对于TH字段置1的Memory Read Request,Byte Enable 隐含以下值。有关其他要求，请参见Section
  2.2.7。
  • 如果此请求的Length字段指示此请求的数据为1个DW的长度，则First DW Byte Enable的值隐含为1111b,Last
    DW Byte Enable的值隐含为0000b。
  • 如果此请求的Length字段指示此请求的数据大于1个DW的长度，First DW Byte Enable和 Last DW Byte
    Enable的值隐含为1111b。

IMPLEMENTATION NOTE

Read Request with TPH to Non-Prefetchable Space

仅在可以确保完成此类读取不会产生不良副作用的情况下，才应发出将TH位置1的Memory Read Request，并且用于访问Non-Prefetchable Memory Space。即使某些BAR映射了具有读取副作用的某些地址，也请考虑Section 7.5.2.1中某些BAR可能会考虑把Prefetchable字段设置为1。

• 1st DW BE[3:0］字段指明所请求的第一个（Length=1时为唯一一个）DW的Byte Enable。

  • 如果Request的Length字段指示的长度大于1DW，则此字段不得等于0000b。

• Last DW BE[3:0］字段指明请求的最后一个DW的Byte Enable。

  • 如果 Request的Length字段指示的长度等于1DW，则此字段必须等于0000b。

  • 如果Request的Length字段指示的长度大于1DW，则此字段不得等于0000b。

• 对于Byte Enable字段的每个比特：

  • 如果值为ob表示不得写入相应的数据字节，或者如果non-prefetchable，则不得读取。

  • 如果值为1b表示必须在写入或读取相应的数据字节。

• 对于长度为1DW的所有请求类型，1st DW BE[3:0］字段中允许使用非连续的Byte Enable。

  • 非连续的Byte Enable 指的是1010b,0101b,1001b,1011b,1101b这种形式。

• 对于长度为2DW的QW对齐的Memory Request, 1st DW BE [3:0］和 Last DW BE
  [3:0］中均允许非连续的ByteEnable。

• 长度为2DW的所有非QW对齐的Memory Request和长度为3DW或更大的Memory
  Request必须仅启用与请求的第一个DW和最后一个DW之间的数据连续的字节。

  • 连续的Byte Enable的例子：

    • 1st DW BE: 1100b, Last DW BE:0011b

    • 1st DW BE: 1000b, Last DW BE:0111b

• Table 2-8给出了Byte Enable字段的比特分布，它们在Request header中的位置以及所引用数据的相应字节之间的对应关系。

Table 2-8 Byte Enables Location and Correspondence

Byte Enables	Header Location	Affected Data Byte
First DW BE[0]	Bit 0 of Byte 7	Byte 0
First DW BE[1]	Bit 1 of Byte 7	Byte 1
First DW BE[2]	Bit 2 of Byte 7	Byte 2
First DW BE[3]	Bit 3 of Byte 7	Byte 3
Last DW BE[0]	Bit 4 of Byte 7	Byte N-4
Last DW BE[1]	Bit 5 of Byte 7	Byte N-3
Last DW BE[2]	Bit 6 of Byte 7	Byte N-2
Last DW BE[3]	Bit 7 of Byte 7	Byte N-1

• 允许长度为1DW且未启用任何字节的Write Request，除非特别说明，否者这对Completer没有影响。

IMPLEMENTATION NOTE

Zero-Length Write

在某些协议下，设备可能会使用1DW的未启用字节的Memory Write Request 或“zero-length Write”，以实现某种预期作用。LN 协议就是一个例子。参见Section 6.21。

• ·如果1DW的Read Request 指定未启用任何字节读取（1st DW BE[3:0]=0000b)，则相应的Completion必须指定1DW的长度，并包括1DW的数据有效载荷。
  • 未指定Completion packet 中数据有效载荷的内容，可以是任何值。
• 对于违反本节中指定的Byte Enable 规则的TLP，未定义接收方／完成方行为。
• ·接收器可以选择检查是否违反了本节中指定的Byte Enable 规则。如果执行此类检查的接收器确定TLP违反一个或多个Byte Enable规则，则该TLP是一个Malformed TLP。这些检查是独立可选实现的（请参见Section 6.2.3.4）。
  • 如果要检查 Byte Enable 规则，则报告与接收端口相关的错误（请参见Section 6.2）。

IMPLEMENTATION NOTE

Zero-Length Read

设备可以将no bytes enabled的1DW的Memory Read Request或“zero-length Read”用作刷新请求的一种。对于请求者，刷新语义允许设备确保先前发送的Posted Write 已在其PCI Express目标位置完成。为了在所有情况下均有效，zero-length Read的地址必须与要刷新的Posted Write针对同一设备。一种推荐的方法是使用与Posted Write相同的地址。

刷新语义具有广泛的应用，所有Completer必须实现与此语义相关联的功能。由于请求者可以在不理解Completer的特征的情况下使用刷新语义，因此Completer必须确保zero-length Read没有副作用。这实际上只是规则的一种特殊情况，即在non-prefetchable 空间中，一定不能在Completer 中读取未启用的字节。请注意，刷新仅适用于与zero-length Read 相同的Traffic Class的业务。

2.2.6 Transaction Descriptor

2.2.6.1 Overview

事务描述符（Transaction Descriptor）是一种在请求者和完成者之间传送Transaction的信息的机制。事务描述符由三个字段组成，see Figure 2-14:

• Transaction ID- 指明识别 Transaction。

• Attributes-指明Transaction的特征。

• Traffic Class (TC)-指明Transaction的业务类型。

Figure 2-14 Transaction Descriptor

2.2.6.2 Transaction Descriptor-Transaction ID Field

Transaction ID 包括两个子字段：Requester ID和Tag，如Figure 2-15所示。

Figure 2-15 Transaction ID

在PCle协议中，事务发起者（Requester）发送的TLP需要有身份ID，这个就叫做Transaction ID，而Transaction ID 由两部分构成，Requester ID和Tag。其中，Requester ID包含了Bus/Device/Function信息。而Tag则表示的是同一发起者（Requester）同时暂存TLP 的数量（Tag字段定义支持的outstanding Non-Posted Request的数量）。

注意：

1．对于Posted TLP来说，Transaction ID其实没有多大意义，因为Requester也不需要有反馈，但是设备还得要支持 Transaction ID的。

2．对于Non-Posted TLP来说，Transaction ID就是必须的。不然在有Cpl包返回时，也不知道是哪个Requester的。

关于Tag：

1. Requester 发送 Non-Posted TLP之后，在没有收到Cpl报文之前，对应的Transaction ID不能被释放。同一Requester发送的Non-Posted TLP的Header中，Requster ID肯定是一样的。当一个Requster要发起多个Non-Posted TLPs时，Tag字段就有了施展才华的时刻。

2. Tag字段的大小决定了发送端可以暂存同一类型TLP的数量。PCle 3.0 Spec中显示，默认是bit[4:0]，就是默认长度是5，当enable extend Tag bit后，Tag长度为8。也就是说在PCle 3.0中，每个PCle设备的发送端最多只能暂存256个TLPs，换句话说，对于同一发起者而言，此时PCle链路上有其256个TLPs在传输。

3. PCle设备的Function 设定中也可以扩展Tag字段。

4. Tag[9:8］的有效取值包括01b,10b,11b。00b表示Requester 不支持10-Bit Tag，如下所述。因而，10-bit Tag最大暂存TLP 数目由原来的256扩大到了768。

［PCle-4.0］中引入的10-Bit Tag Capability 将总的Tag字段从8-Bit 增加到10-Bit。其中Tag[8](T8）和Tag[9](T9）与TLP Header 中的其他Tag[7:0］位不相邻。在本规范的先前版本中，保留了另外两个比特。

• Tag[9:0］是每个请求者生成的10-Bit字段，并且对于该请求者的所有需要一个Completion的outstanding
  Request，它必须是唯一的。不支持10-Bit Tag Requester
  Capability的请求者必须将Tag[9:8］设置为00b。

  • 支持16.0 GT/s或更高数据速率的Function（包括Switch中的 Function）必须支持10-Bit Tag
    Completer Capability。如果某个Function 支持10-Bit Tag Completer
    Capability，则可以选择支持10-Bit Tag Requester Capability。请参阅Section
    7.5.3.15和本节后面的＂Considerations for Implementing 10-Bit Tag Capabilities”的实现说明。
  • 如果RC包含支持10-Bit Tag Completer
    Capability的元件，则RC必须正确处理所有作为PCle请求者目标的寄存器和内存区域的10-Bit Tag
    Request；例如，RCiEP中的DMA请求或MMIO区域作为目标的主机内存。
    • 每个支持10-Bit Tag Completer Capability的RP必须由其Ingress Port处理收到的此类请求。
    • 每个支持10-Bit Tag Completer Capability的RCiEP必须处理来自内部路径（包括来自RP的请求）的此类请求。

• 如果RC包含的RCiEP支持10-Bit Tag Requester Capability，则RC必须由作为这些RCiEP目标的所有寄存器和存储区正确处理来自这些RCiEP的10-Bit Tag Request。例如，RCiEP中的DMA请求或MMIO区域作为目标的主机内存。

• Receiver/Completer 必须正确处理8-bit Tag值，而不管其Extended Tag Field Enable字段的设置如何（Section 7.5.3.4）。关于桥处理扩展标签（extended tag）的详细信息，请参阅PCI Express to PCI/PCI-X Bridge Specification。

• 支持10-Bit Tag Completer Capability的Receiver/Completer必须正确处理10-Bit Tag值，而不管10-Bit Tag Requester Enable 字段如何设置。参见Section 7.5.3.16。

• 10-Bit Tag Capability 不是为 PCI Express to PCI/PCI-X Bridge 设计的，它们不得支持10-Bit Tag Requester Capability或10-Bit Tag Completer Capability。

• 如果10-Bit Tag RequesterEnable=0且 Extended Tag Field Enable=0，，则每个Function的最大outstanding Request的数目应限制为32，并且仅使用Tag字段的低5比特，其余高5比特必须为00000b。

• 如果10-Bit Tag Requester Enablele=且 Extended Tag Field Enable=1，，则最大值增加到256，并且仅使用Tag字段的低8比特，其余的高2比特为00b。

• 如果 10-Bit Tag
  RequesterEnable=1，则针对单个Completer的最大限制提高到768。在向其认为合适的Completer发送10-Bit
  Tag Request时，允许Requester使用整个10-Bit Tag字段，尽管仍然允许 Requester将较小
  Tag的请求发送给其他Completer。以下内容适用于10-Bit Tag Requester Enable
  字段被置1的具有10-Bit Tag capable的Requester。

  • 如果某个Endpoint支持将请求发送到其他Endpoint（而不是主机内存），则该Endpoint不得将10-Bit Tag
    Request 发送到另一个给定的Endpoint，除非有特定于实现的机制能确定该Endpoint支持10-Bit Tag
    Completer Capability。对于某些实现，完全不向其他Endpoint发送10-Bit Tag Request
    可能是可以接受的。更复杂的机制不在本规范的范围之内。

  • 如果PIO Requester 支持 10-Bit Tag Requester Capability，则该 Requester
    如何确定何时使用10-Bit Tag与较小 Tag 的机制超出了本规范的范围。

  • 对于10-Bit Tag，有效的Tag[9:8］值为01b,10b或11b。Tag[9:8］等于00b的10-Bit
    Tag值无效，并且请求者不能生成这样的请求。这使Requester 可以判断接收到的应该具有10-Bit
    Tag的Completion是否包含无效标记，这通常是由于Completer 不支持10-Bit Tag Completer
    Capability 引起的。

  • 如果Requester 向不支持10-Bit Completer Capability的 Completer 发送 10-Bit Tag
    Request，则返回的Completion 将携带Tag[9:8］等于00b的Tag。由于Requester被禁止为10-Bit
    Tag生成这些Tag值，因此此类完成将作为Unexpected Completion 处理，默认情况下是Advisory
    Non-FatalError。Requester 必须遵循标准的PCI Express错误处理要求。

  • 当Requester处理带有无效10-Bit Tag的Completion作为Unexpected Completion时，原始请求可能会导致完成超时。如果Requester以某种特定于设备的方式处理完成超时条件，以避免数据损坏，则允许Requester按标准要求通过标准PCI Express错误处理机制抑制对完成超时的处理。

  • 如果 Requester 支持将10-Bit Tag Request 同时发送给某些 Completer，将较小Tag的Request同时发送给其他Completer，则Requester 必须遵守发送较小 Tag Request的Extended Tag Field Enable字段的设置。也就是说，如果该位为0，则仅Tag字段的低5比特可以为非零；否则为0。如果该位置1，则仅Tag字段的低8比特可以为非零。

  • 如果 Requester 支持同时向某些Completer 发送10-Bit Tag Request，并向其他Completer发送较小Tag的 Request，则Requester 必须确保，如果任何10-Bit Tag Request 是由不支持10-Bit Tag Completer Capability的Completer 完成的，则任何 outstanding的10-Bit Tag都不能别名为outstanding的较小Tag。请参阅本节后面的“Using 10-Bit Tags and Smaller Tags Concurrently”的实现说明。

• Extended Tag Field Enable字段的默认值是特定于实现的。10-Bit Tag Requester Enable 字段的默认值为0b。

• 如果向多个未完成的请求发出了不唯一的Tag值，则Receiver/Completer的行为是不确定的。

• 如果使用 Phantom Function Number 扩展 outstanding request的数目，则对于所有需要该请求者完成的outstanding Request, Phantom Function Number和Tag字段的组合必须唯一。

• 对于Posted Request,Tag[9:8］为保留值。

• 对于TH字段置1的Posted Request，将Tag[7:0］字段改用于ST[7:0］字段（有关详细信息，请参见Section 2.2.7.1）。对于TH字段为0的Posted Request,Tag[7:0］字段未定义并且可以包含任何值。（某些Vendor_Defined Message是此规则的例外，请参阅Table F-1。）

  • 对于TH字段为0的Posted Request, Tag[7:0］字段中的值不得影响接收方对请求的处理。

  • 对于TH字段为1的Posted Request,ST[7:0］字段中的值可能会影响 Completer处理请求。

• Requester ID和Tag的组合形成一个全局标识符，即层次结构中每个事务的Transaction ID。

• 所有的Request和Completion TLP中都包含 Transaction ID。

• Requester ID是一个16比特值，对于层次结构中的每个PCI Express Function都是唯一的。

• Function 必须捕获 Function 完成的所有 Type 0 Configuration Write Request 携带的Bus Number和 Device Number，并在由Device/Function 发起的所有请求的Requester ID的Bus Number和Device Number字段中使用这些Number。建议仅为成功完成的请求捕获这些Number。

例外：可以通过特定于实现的方式将总线和设备号分配给RC中的设备，并将设备号分配给Switch中的下游端口。
请注意，总线号和设备号可能会在运行时更改，因此有必要在每个Configuration Write Request 中重新捕获此信息。
建议寻址未实现的Function的Configuration Write Request 不影响捕获的总线号和设备号。

注1：在ARI设备中，Function只需捕获 Bus Number。ARI设备可以按设备或按Function保留捕获的Bus Number。如果捕获的Bus Number是按设备保留的，则需要所有Function来更新和使用公共的Bus Number。

注2:ARI设备的Requester ID 不包含 Device Number字段。参见Sectin 2.2.4.2。

注3:ARI设备只有Bus Number 可以改变。

• 代表自己生成请求时（例如，用于错误报告）,Switch必须使用与逻辑上与端口相关联的桥的Primary Side（请参阅Section7.1）相关联的Requester ID发起请求。
• 在发起对Function的配置写之前，不允许该Function发送Non-Posted Request（需要有效的Requester ID 才能正确路由所产生的完成TLP）。
  • 例外：允许RC中的Function在对系统引导设备进行访问的软件启动配置之前发起请求。

请注意，此规则和例外与用于系统初始化和配置的现有PCI模型一致。

• 与设备关联的每个Function都必须设计唯-Function Number。注意：每个non-ARI Device最多可以包含八个Function。每个ARI设备最多可包含256个Function。
• Switch 不能改动经过的TLP的Transaction ID。
• 在某些情况下，需要PCI Express to PCI/PCI-X Bridge 才能为从PCI或PCI-X总线转发的请求生成Transaction ID。

IMPLEMENTATION NOTE

Increasing the Number of Outstanding Requests

为了将需要完成的outstanding Request的最大可能数目增加到超过256，如果Phantom Functions Enable字段置1（参见Section 7.8.4)，则设备可以使用未分配给已实现Function的Function Number 来逻辑扩展Tag标识符。对于single-Function 设备，这可以使 outstanding Request的最大数量最多增加8倍。

Unclaimed Function Number 就叫 Phantom Function Number(PFN）。

IMPLEMENTATION NOTE

Considerations for Implementing 10-Bit Tag Capabilities

10-Bit Tag的使用使请求者可以将outstanding Non-Posted Request(NPR）的数量从256增加到768，这对于非常高速率的NPR可以避免Tag的可用性成为瓶颈。以下公式给出了有效负载带宽、outstanding NPR数量和其他因素之间的基本关系：

BW=S*N/RTT,，其中

$$BW=payloadbandwidth$$

$$S=transactionpayloadsize$$

$$N=numberofoutstandingNPR$$

RTT = transaction round-trip time

通常，只有使用相对较小transaction的高速率链路上的高速率请求者才能从其outstanding NPR数量增加到超过256中受益，尽管这也可以帮助在事务往返时间较长的配置中保持性能。

在支持10-Bit Tag Requester Capability的请求者需要以多个完成者为目标的配置中，需要确保请求者仅向支持10-Bit Tag Completer Capability的完成者发送10-Bit Tag Request。如果所有完成者都支持此Capability，则将大大简化此过程。

为了使业界普遍使用10-Bit Tag，强烈建议所有Function都支持10-Bit Tag Completer Capability。通过新的实现，不需要本身同时使用大量NPR的完成者通常可以在内部跟踪10-Bit Tag，并以适度的增量在Completion中返回。

实际上同时处理大量NPR的完成者可能需要大量额外的硬件资源（存储空间），但是通常无法实现10-Bit Tag的全部性能优势，除非完成者实际同时处理更多的NPR。

对于RC支持10-Bit Tag Completer Capability的平台，强烈建议配置PCle层次结构的平台固件或操作软件在支持10-Bit Tag Requester Capability的Endpoint 中自动设置10-Bit Tag Requester Enable 字段。这将启用一类重要的支持10-Bit Tag的适配器，这些适配器只向主机内存发送内存读取请求。

对于RCiEP以外的Endpoint，可以通过检查其关联RP中的10-Bit Tag Completer Supported字段来确定RC是否为每个Port支持10-Bit Tag Completer Capability。RCiEP没有关联的RP，因此，由于这个原因，除非RC支持它们的10-Bit Tag Completer Capability，否则不允许它们设置其10-Bit Tag Completer Supported字段。因此，软件不需要对RCiEP执行单独的检查。

不支持10-Bit Tag Completer Capability的Switch 仍能够正确转发带有10-Bit Tag的NPR Completion，因为这两个新的Tag字段位于以前保留的TLP Header字段中，并且要求Switch无需修改的转发TLP Header中的这些字段。但是，如果这样的Switch检测到带有10-Bit Tag的NPR的错误，并且该Switch通过充当NPR的完成者来处理错误，则完成的结果将具有无效的10-Bit Tag。因此，强烈建议使用10-Bit Tag的所有组件之间的Switch支持10-Bit Tag Completer Capability。请注意，支持16.0 GT/s或更高数据速率的Switch必须支持10-Bit Tag Completer Capability。

支持10-Bit Tag Requester Capability的请求者发送的配置请求的目的地可能支持10-Bit Tag Completer Capability，也可能不支持。此请求者如何确定发送的NPR哪些包含10-Bit Tag的实现不在本规范范围之内。

IMPLEMENTATION NOTE

Using 10-Bit Tags and Smaller Tags Concurrently

如本节前面所述，如果请求者支持同时向某些完成者发送10-Bit Tag Request，并向其他完成者发送较小的Tag请求，则如果任何10-Bit Tag Request 是由不支持10-Bit Tag Completer Capability的完成者完成的，则请求者必须确保没有outstanding 10-Bit Tag可以别名到outstanding的较小Tag能力。

一种实现方法是让请求者将其8-bit Tag空间划分为两个区域：一个区域仅用于较小的标记（8位或5位Tag)，另一个区域仅用于10-Bit Tag中较低的8位。请注意，这将强制在10-Bit Tag 可用的标记空间和较小的标记之间进行权衡。

例如，如果请求者将其8-bit Tag空间划分为仅将最低的4位用于较小的标记，则这最多支持16个未完成的较小标记，并将10-Bit Tag空间减少3x16个值，支持768-48=720个未完成的10-Bit Tag。许多其他分区选项都是可能的，所有这些选项都减少了未完成请求的总数。一般来说，为较小的标记保留N个值会将10-Bit Tag空间减少3N个值，较小的标记加上10-Bit Tag的总数最终为768-2N。

2.2.6.3 Transaction Descriptor - Attributes Field

Attributes 字段用于提供额外的信息以允许修改Transaction的默认处理。这些修改适用于处理系统内Transaction的不同方面，例如：

• Ordering
• 硬件一致性管理（snoop）

请注意，Attributes是提示，可用于优化业务处理。支持级别取决于特定PCI Express外围设备和平台构件的应用需求。有关这些属性的更多详细信息，请参阅PCI-X2.0。请注意，Attributes字段的bit 2与bit 1和bit 0不相邻（见Flgure 2-17和 Figure 2-18）。

Figure 2-16 Attributes Field of Transaction Descriptor

2.2.6.4 Relaxed Ordering and ID-Based Ordering Attributes

Table 2-9定义了Relaxed Ordering和 ID-Based Ordering属性字段的状态。这些属性将在Section 2.4中讨论。请注意， Relaxed Ordering 和ID-Based Ordering 属性在位置上不相邻（请参见 Figure 2-5）。

Table 2-9 Ordering Attributes

Attribute Bit [2]	Attribute Bit [1]	Ordering Type	Ordering Model
0	0	Default Ordering	PCI Strongly Ordered Model
0	1	Relaxed Ordering	PCI-X Relaxed Ordering Model
1	0	ID-Based Ordering	Independent ordering based on Requester/CompleterID
1	1	Relaxed Ordering plus ID-Based Ordering	Logical "OR" ofRelaxed Ordering and IDO

对于Configuration Request, I/O Request，作为MSI的Memory Request和Message Request（除非特别允许）, Attribute bit[1］不使用且必须将其设置为0b。

Attribute bit [2]，即IDO，保留用于 Configuration Request 和I/O Request。IDO并非为所有Memory Request 保留，包括MSI。除非明确禁止，否则IDO不保留用于消息请求。仅当设置了Device Control 2 寄存器中的IDO Request Enable字段时，才允许请求者设置IDO。

在确定TLP是否为Malformed Packet时，接收方不得检查IDO字段的值。

仅当Device Control 2寄存器中的IDO Request Enable 字段设置为1时，允许完成者设置IDO。不需要将IDO的值从请求复制到该请求的完成中。如果完成者启用了IDO，则建议完成者为所有完成设置IDO，除非有特定原因不这样做（请参阅Appendix E）。不需要支持在根端口之间对等转发TLP的RC来保留从入口到出口的IDO位。

2.2.6.5 No Snoop Attribute

Table 2-10定义了No Snoop 属性字段的状态。请注意，No Snoop属性不会更改事务顺序。

Table 2-10 Cache Coherency Management Attribute

No Snoop Attribute(b)	Cache Coherency Management Type	Coherency Model
0	Default	Hardware enforced cache coherency expected
1	No Snoop	Hardware enforced cache coherency not expected

对于Configuration Request, I/O Request，作为MSI的Memory Request和 Message Request（除非特别允许），此属性不使用且必须将其设置为0b。

2.2.6.6 Transaction Descriptor - Traffic Class Field

业务类别（TC,Traffic Class）是一个3比特字段，可将Transaction区分为八个业务类别。

TC机制与PCI Express虚通道机制一起是实现差异化业务服务的基本要素。每个PCI Express事务层数据包都使用TC信息作为在PCI Express中首尾相连的不变标签。当数据包在整个拓扑中传输时，此信息将在每个链路上以及每个Switch内使用，以对业务服务做出正确决策。服务的关键方面是根据数据包的TC标签通过相应的虚通道对数据包进行路由。Section 2.5节详细介绍了VC 机制。

Table 2-11给出了TC字段的编码。

Table 2-11 Definition of TC Field Encodings

TC Field Value (b)	Definition
000	TCO:Best Effort service class (General Purpose I/O) (Default TC-must be supported by every PCI Express device)
001 to 111	TC1 toTC7: Differentiated service classes (Differentiation based on Weighted-Round-Robin (WRR) and/or priority)

系统软件决定TC标签和TC/VC映射，以便提供满足目标平台要求的差异化服务。

业务类别的概念仅适用于PCI Express互连结构。如何将PCI Express TC服务策略转换为非PCI Express互连上的策略的特定要求超出了本规范的范围。