INTRODUCTION TO THE PACKET-BASED PROTOCOL

The PCI Express protocol improves upon methods used by earlier busses (e.g. PCI) to exchange
data and to signal system events. In addition to supporting basic memory, IO, and configuration
read/write transactions, the links eliminate many sideband signals and replaces them with in-
band messages.

With the exception of the logical idle indication and physical layer Ordered Sets, all information
moves across an active PCI Express link in fundamental chunks called packets which are
comprised of 10 bit control (K) and data (D) symbols.

two major classes of packets exchanged between two PCI Express devices are high
level Transaction Layer Packets (TLPs), and low-level link maintenance packets called Data
Link Layer Packets (DLLPs). Collectively, the various TLPs and DLLPs allow two devices to
perform memory, IO, and Configuration Space transactions reliably and use messages to initiate
power management events, generate interrupts, report errors, etc

Figure TLP And DLLP Packets

Why Use A Packet-Based Transaction Protocol

There are some distinct advantages in using a packet-based protocol, especially when it comes to
data integrity. Three important aspects of PCI Express packet protocol help promote data
integrity during link transmission:

Packet Formats Are Well Defined

Some early bus protocols (e.g. PCI) allow transfers of indeterminate (and unlimited) size,
making identification of payload boundaries impossible until the end of the transfer. In addition,
an early transaction end might be signaled by either agent (e.g. target disconnect on a write or
pre-emption of the initiator during a read), resulting in a partial transfer. In these cases, it is
difficult for the sender of data to calculate and send a checksum or CRC covering an entire
payload, when it may terminate unexpectedly. Instead, PCI uses a simple parity scheme which is
applied and checked for each bus phase completed.

In contrast, each PCI Express packet has a known size and format, and the packet header--
positioned at the beginning of each DLLP and TLP packet-- indicates the packet type and
presence of any optional fields. The size of each packet field is either fixed or defined by the
packet type. The size of any data payload is conveyed in the TLP header Length field. Once a
transfer commences, there are no early transaction terminations by the recipient. This structured
packet format makes it possible to insert additional information into the packet into prescribed
locations, including framing symbols, CRC, and a packet sequence number (TLPs only).

Framing Symbols Indicate Packet Boundaries

Each TLP and DLLP packet sent is framed with a Start and End control symbol, clearly defining
the packet boundaries to the receiver. Note that the Start and End control (K) symbols appended
to packets by the transmitting device are 10 bits each. This is a big improvement over PCI and
PCI-X which use the assertion and de-assertion of a single FRAME# signal to indicate the
beginning and end of a transaction. A glitch on the FRAME# signal (or any of the other
PCI/PCIX control signals) could cause a target to misconstrue bus events. In contrast, a PCI
Express receiver must properly decode a complete 10 bit symbol before concluding link activity
is beginning or ending. Unexpected or unrecognized control symbols are handled as errors.

CRC Protects Entire Packet

Unlike the side-band parity signals used by PCI devices during the address and each data phase
of a transaction, the in-band 16-bit or 32-bit PCI Express CRC value “protects” the entire packet
(other than framing symbols). In addition to CRC, TLP packets also have a packet sequence
number appended to them by the transmitter so that if an error is detected at the receiver, the
specific packet(s) which were received in error may be resent. The transmitter maintains a copy
of each TLP sent in a Retry Buffer until it is checked and acknowledged by the receiver. This
TLP acknowledgement mechanism (sometimes referred to as the Ack/Nak protocol) forms the
basis of link-level TLP error correction and is very important in deep topologies where devices
may be many links away from the host in the event an error occurs and CPU intervention would
otherwise be needed.

TRANSACTION LAYER PACKETS

In PCI Express terminology, high-level transactions originate at the device core of the
transmitting device and terminate at the core of the receiving device. The Transaction Layer is
the starting point in the assembly of outbound Transaction Layer Packets (TLPs), and the end
point for disassembly of inbound TLPs at the receiver. Along the way, the Data Link Layer and
Physical Layer of each device contribute to the packet assembly and disassembly as described
below.

TLPs Are Assembled And Disassemble

general flow of TLP assembly at the transmit side of a link and disassembly at the receiver. The
key stages in Transaction Layer Packet protocol are listed below. The numbers correspond to
those in Figure 4-2.

1
. Device B's core passes a request for service to the PCI Express hardware
interface. How this done is not covered by the PCI Express Specification,
and is device-specific. General information contained in the request would
include:

- The PCI Express command to be performed

- Start address or ID of target (if address routing or ID routing are used)
- Transaction type (memory read or write, configuration cycle, etc.)
- Data payload size (and the data to send, if any)
- Virtual Channel/Traffic class information
- Attributes of the transfer: No Snoop bit set?, Relaxed Ordering set?,
etc.
2 The Transaction Layer builds the TLP header, data payload, and digest based
. on the request from the core. Before sending a TLP to the Data Link Layer,
flow control credits and ordering rules must be applied.

3 When the TLP is received at the Data Link Layer, a Sequence Number is
. assigned and a Link CRC is calculated for the TLP (includes Sequence
Number). The TLP is then passed on to the Physical Layer.

4 At the Physical Layer, byte striping, scrambling, encoding, and serialization are
. performed. STP and END control (K) characters are appended to the packet.
 The packet is sent out on the transmit side of the link.

5 At the Physical Layer receiver of Device A, de-serialization, framing symbol

. check, decoding, and byte un-striping are performed. Note that at the Physical
Layer, the first level or error checking is performed (on the control codes).

6 The Data Link Layer of the receiver calculates CRC and checks it against the
. received value. It also checks the Sequence Number of the TLP for violations.
If there are no errors, it passes the TLP up to the Transaction Layer of the
receiver. The information is decoded and passed to the core of Device A. The
Data Link Layer of the receiver will also notify the transmitter of the success or
failure in processing the TLP by sending an Ack or Nak DLLP to the
transmitter. In the event of a Nak (No Acknowledge), the transmitter will re-
send all TLPs in its Retry Buffer.

Figure 4-2. PCI Express Layered Protocol And TLP Assembly/Disassembly

Device Core Requests Access to Four Spaces

Transactions are carried out between PCI Express requesters and completers, using four separate
address spaces: Memory, IO, Configuration, and Message. (See Table 4-1.)
Table 4-1. PCI Express Address Space And Transaction Types

Address Transaction Purpose

Space Types

Memory Read, Write Transfer data to or from a location in the system memory
map. The protocol also supports a locked memory read
transaction.

IO Read, Write Transfer data to or from a location in the system IO map. PCI
Express IO address assignment to legacy devices. IO
addressing is not permitted for Native PCI Express devices.

Configuration Read, Write Transfer data to or from a location in the configuration space
of a PCI Express device. As in PCI, configuration is used to
discover device capabilities, program plug-and-play features,
and check status using the 4KB PCI Express configuration
space.

Message Baseline, Provides in-band messaging and event reporting (without

Vendor- consuming memory or IO address resources). These are
specific handled the same as posted write transactions.

TLP Transaction Variants Defined

In accessing the four address spaces, PCI Express Transaction Layer Packets (TLPs) carry a
header field, called the Type field, which encodes the specific command variant to be
used. Table 4-2 on page 160 summarizes the allowed transactions:

Table 4-2. TLP Header Type Field Defines Transaction Variant

TLP Type Acronym

Memory Read Request (MRd)

Memory Read Lock Request (MRdLk)

Memory Write Request (MWr)

IO Read Request (IORd)

IO Write Request (IOWr)

Table 4-2. TLP Header Type Field Defines Transaction Variant

TLP Type Acronym

Config Type 0 Read Request (CfgRd0)

Config Type 0 Write Request (CfgWr0)

Config Type 1 Read Request (CfgRd1)

Config Type 1 Write Request (CfgWr1)

Message Request (Msg)

Message Request W/Data (MsgD)

Completion (Cpl)

Completion W/Data (CplD)

Completion-Locked (CplLk)

Completion W/Data (CplDLk)

TLP Structure

The basic usage of each component of a Transaction Layer Packet is defined in Table 4-3 on
page 161.

Table 4-3. TLP Header Type Field Defines Transaction Variant

TLP Componen Protocol
Component Use
t Layer

Header Transaction 3DW or 4DW (12 or 16 bytes) in size. Format varies with
Layer type, but Header defines transaction parameters:
 Transaction type
 Intended recipient address, ID, etc.
 Transfer size (if any), Byte Enables
 Ordering attribute
 Cache coherency attribute
 Traffic Class
 Table 4-3. TLP Header Type Field Defines Transaction Variant

TLP Componen Protocol
Component Use
t Layer

Data Transaction Optional field. 0-1024 DW Payload, which may be further

Layer qualified with Byte Enables to get byte address and byte
transfer size resolution.

Digest Transaction Optional field. If present, always 1 DW in size. Used for

Layer end-to-end CRC (ECRC) and data poisoning.

Generic TLP Header Format

Figure 4-3 on page 162 illustrates the format and contents of a generic TLP 3DW header. In this
section, fields common to nearly all transactions are summarized. In later sections, header format
differences associated with the specific transaction types are covered.

Figure 4-3. Generic TLP Header Fields

Generic Header Field Summary

Table 4-4 on page 163 summarizes the size and use of each of the generic TLP header fields.
Note that fields marked “R” in Figure 4-3 on page 162 are reserved and should be set = 0.

Table 4-4. Generic Header Field Summary

Header
Header Field Field Use
Location

Length [9:0] Byte 3 Bit TLP data payload transfer size, in DW. Maximum transfer size
7:0 Byte 2 is 10 bits, 210 = 1024 DW (4KB). Encoding:
Bit 1:0 00 0000 0001b = 1DW
00 0000 0010b = 2DW
.
.
11 1111 1111b = 1023 DW
00 0000 0000b = 1024 DW

Attr Byte 2 Bit Bit 5 = Relaxed ordering.

(Attributes) 5:4 When set = 1, PCI-X relaxed ordering is enabled for this TLP.
If set = 0, then strict PCI ordering is used.
Bit 4 = No Snoop.
When set = 1, requester is indicating that no host cache
coherency issues exist with respect to this TLP. System
hardware is not required to cause processor cache snoop for
coherency. When set = 0, PCI -type cache snoop protection is
required.

EP (Poisoned Byte 2 Bit 6 If set = 1, the data accompanying this data should be
Data) considered invalid although the transaction is being allowed to
complete normally.

TD (TLP Byte 2 Bit 7 If set = 1, the optional 1 DW TLP Digest field is included with
Digest Field this TLP that contains an ECRC value. Some rules: Presence
Present) of the Digest field must be checked by all receivers (using this
bit).
 A TLP with TD = 1, but no Digest field is handled as a
Malformed TLP.
 If a device supports checking ECRC and TD=1, it must
perform the ECRC check.
 If a device does not support checking ECRC (optional)
at the ultimate destination, the device must ignore the
digest.
Table 4-4. Generic Header Field Summary

Header
Header Field Field Use
Location

TC (Traffic Byte 1 Bit These three bits are used to encode the traffic class to be
Class) 6:4 applied to this TLP and to the completion associated with it (if
any).
000b = Traffic Class 0 (Default)
.
.
111b = Traffic Class 7
TC 0 is the default class, and TC 1-7 are used in providing
differentiated services. See “Traffic Classes and Virtual
Channels” on page 256 for additional information.

Type[4:0] Byte 0 Bit These 5 bits encode the transaction variant used with this TLP.
4:0 The Type field is used with Fmt [1:0] field to specify
transaction type, header size, and whether data payload is
present. See below for additional information of Type/Fmt
encoding for each transaction type.

Fmt[1:0] Byte 0 Bit These two bits encode information about header size and
Format 6:5 whether a data payload will be part of the TLP:
00b 3DW header, no data
01b 4DW header, no data
10b 3DW header, with data
11b 4DW header, with data
See below for additional information of Type/Fmt encoding for
each transaction type.

First DW Byte Byte 7 Bit These four high-true bits map one-to-one to the bytes within
Enables 3:0 the first double word of payload.
Bit 3 = 1: Byte 3 in first DW is valid; otherwise not
Bit 2 = 1: Byte 2 in first DW is valid; otherwise not
Bit 1 = 1: Byte 1 in first DW is valid; otherwise not
Bit 9 = 1: Byte 0 in first DW is valid; otherwise not
See below for details on Byte Enable use.

Last DW Byte Byte 7 Bit These four high-true bits map one-to-one to the bytes within
Enables 7:4 the first double word of payload.
Bit 3 = 1: Byte 3 in last DW is valid; otherwise not
Bit 2 = 1: Byte 2 in last DW is valid; otherwise not
Bit 1 = 1: Byte 1 in last DW is valid; otherwise not
Bit 9 = 1: Byte 0 in last DW is valid; otherwise not
Table 4-4. Generic Header Field Summary

Header
Header Field Field Use
Location

See below for details on Byte Enable use.

Header Type/Format Field Encodings

Table 4-5 on page 165 summarizes the encodings used in TLP header Type and Format (Fmt)
fields.

Table 4-5. TLP Header Type and Format Field Encodings

TLP FMT[1:0] TYPE [4:0]

Memory Read Request (MRd) 00 = 3DW, no data 01 = 0 0000

4DW, no data

Memory Read Lock Request 00 = 3DW, no data 01 = 0 0001

(MRdLk) 4DW, no data

Memory Write Request (MWr) 10 = 3DW, w/ data 11 = 0 0000

4DW, w/ data

IO Read Request (IORd) 00 = 3DW, no data 00010

IO Write Request (IOWr) 10 = 3DW, w/ data 0 0010

Config Type 0 Read Request 00 = 3DW, no data 0 0100

(CfgRd0)

Config Type 0 Write Request 10 = 3DW, w/ data 0 0100

(CfgWr0)

Config Type 1 Read Request 00 = 3DW, no data 0 0101

(CfgRd1)

Config Type 1 Write Request 10 = 3DW, w/ data 0 0101

(CfgWr1)

Message Request (Msg) 01 = 4DW, no data 1 0 rrr* (for rrr, see routing
subfield)
 Table 4-5. TLP Header Type and Format Field Encodings

TLP FMT[1:0] TYPE [4:0]

Message Request W/Data 11 = 4DW, w/ data 1 0rrr* (for rrr, see routing
(MsgD) subfield)

Completion (Cpl) 00 = 3DW, no data 0 1010

Completion W/Data (CplD) 10 = 3DW, w/ data 0 1010

Completion-Locked (CplLk) 00 = 3DW, no data 0 1011

Completion W/Data (CplDLk) 10 = 3DW, w/ data 0 1011

The Digest and ECRC Field

The digest field and End-to-End CRC (ECRC) is optional as is a device's ability to generate and
check ECRC. If supported and enabled by software, devices must calculate and apply ECRC for
all TLPs that the device originates. Also, devices that support ECRC checking must also support
Advanced Error Reporting.

ECRC Generation and Checking

This book does not detail the algorithm and process of calculating ECRC, but is defined within
the specification. ECRC covers all fields that do not change as the TLP is forwarded across the
fabric. The ECRC includes all invariant fields of the TLP header and the data payload, if present.
All variant fields are set to 1 for calculating the ECRC, include:

 Bit 0 of the Type field is variant — this bit changes when the transaction type is altered
for a packet. For example, a configuration transaction being forwarded to a remote link
(across one or more switches) begins as a type 1 configuration transaction. When the
transaction reaches the destination link, it is converted to a type 0 configuration
transaction by changing bit 0 of the type field.
 Error/Poisoned (EP) bit — this bit can be set as a TLP traverses the fabric in the event
that the data field associated with the packet has been corrupted. This is also referred to
as error forwarding.

Who Can Check ECRC?

The ECRC check is intended for the device that is the ultimate receipient of the TLP. Link CRC
checking verifies that a TLP traverses a given link before being forwarded to the next link, but
ECRC is intended to verify that the packet send has not been altered in its journey between the
Requester and Completer. Switches in the path must maintain the integrity of the TD bit because
corruption of TD will cause an error at the ultimate target device.

The specification makes two statements regarding a Switch's role in ECRC checking:

 A switch that supports ECRC checking performs this check on TLPs destined to a
location within the Switch itself. “On all other TLPs a Switch must preserve the ECRC
(forward it untouched) as an integral part of the TLP.”
 “Note that a Switch may perform ECRC checking on TLPs passing through the Switch.
ECRC Errors detected by the Switch are reported in the same way any other device
would report them, but do not alter the TLPs passage through the Switch.”

These statements may appear to contradict each other. However, the first statement does not
explicitly state that an ECRC check cannot be made in the process of forwarding the TLP
untouched. The second statement clarifies that it is possible for switches, as well as the ultimate
target device, to check and report ECRC.

Using Byte Enables

As in the PCI protocol, PCI Express requires a mechanism for reconciling its DW addressing and
data transfers with the need, at times, for byte resolution in transfer sizes and transaction
start/end addresses. To achieve byte resolution, PCI Express makes use of the two Byte Enable
fields introduced earlier in Figure 4-3 on page 162 and in Table 4-4 on page 163.

The First DW Byte Enable field and the Last DW Byte Enable fields allow the requester to
qualify the bytes of interest within the first and last double words transferred; this has the effect
of allowing smaller transfers than a full double word and offsetting the start and end addresses
from DW boundaries.

Byte Enable Rules

1. Byte enable bits are high true. A value of “0” indicates the corresponding byte in the data
payload should not be written by the completer. A value of “1”, indicates it should.
2. If the valid data transferred is all within a single aligned double word, the Last DW Byte
enable field must be = 0000b.
3. If the header Length field indicates a transfer is more than 1DW, the First DW Byte
Enable must have at least one bit enabled.
4. If the Length field indicates a transfer of 3DW or more, then neither the First DW Byte
Enable field or the Last DW Byte Enable field may have discontinuous byte enable bits
set. In these cases, the Byte Enable fields are only being used to offset the effective start
address of a burst transaction.
5. Discontinuous byte enable bit patterns in the First DW Byte enable field are allowed if
the transfer is 1DW.
6. Discontinuous byte enable bit patterns in both the First and Second DW Byte enable
fields are allowed only if the transfer is Quadword aligned (2DWs).
 7. A write request with a transfer length of 1DW and no byte enables set is legal, but has no
effect on the completer.
8. If a read request of 1 DW is done with no byte enable bits set, the completer returns a
1DW data payload of undefined data. This may be used as a Flush mechanism. Because
of ordering rules, a flush may be used to force all previously posted writes to memory
before the completion is returned.

An example of byte enable use in this case is illustrated in Figure 4-4 on page 168. Note that the
transfer length must extend from the first DW with any valid byte enabled to the last DW with
any valid bytes enabled. Because the transfer is more than 2DW, the byte enables may only be
used to specify the start address location (2d) and end address location (34d) of the transfer.

Figure 4-4. Using First DW and Last DW Byte Enable Fields

Transaction Descriptor Fields

As transactions move between requester and completer, it is important to uniquely identify a

transaction, since many split transactions may be pending at any instant. To this end, the
specification defines several important header fields that when used together form a unique
Transaction Descriptor as illustrated in Figure 4-5.
Figure 4-5. Transaction Descriptor Fields

While the Transaction Descriptor fields are not in adjacent header locations, collectively they
describe key transaction attributes, including:

Transaction ID

This is comprised of the Bus, Device, and Function Number of the TLP requester AND the Tag
field of the TLP.

Traffic Class

Traffic Class (TC 0 -7) is inserted in the TLP by the requester, and travels unmodified through
the topology to the completer. At every link, Traffic Class is mapped to one of the available
virtual channels.

Transaction Attributes

These consist of the Relaxed Ordering and No Snoop bits. These are also set by the requester and
travel with the packet to the completer.

Additional Rules For TLPs With Data Payloads

The following rules apply when a TLP includes a data payload.

1. The Length field refers to data payload only; the Digest field (if present) is not included
in the Length.
2. The first byte of data in the payload (immediately after the header) is always associated
with the lowest (start) address.
 3. The Length field always represents an integral number of doublewords (DW) transferred.
Partial doublewords are qualified using First and Last Byte Enable fields.
4. The PCI Express specification states that when multiple transactions are returned by a
completer in response to a single memory request, that each intermediate transaction
must end on naturally-aligned 64 and 128 byte address boundaries for a root complex
(this is termed the Read Completion Boundary, or RCB). All other devices must break
such transactions at naturally-aligned 128 byte boundaries. This behavior promotes
system performance related to cache lines.
5. The Length field is reserved when sending message TLPs using the transaction Msg. The
Length field is valid when sending the message with data variant MsgD.
6. PCI Express supports load tuning of links. This means that the data payload of a TLP
must not exceed the current value in the Max_Payload_Size field of the Device Control
Register. Only write transactions have data payloads, so this restriction does not apply to
reads. A receiver is required to check for violations of the Max_Payload_Size limit
during writes; violations are handled as Malformed TLPs.
7. Receivers also must check for discrepancies between the value in the Length field and the
actual amount of data transferred in a TLP with data. Violations are also handled as
Malformed TLPs.
8. Requests must not mix combinations of start address and transfer length which will cause
a memory space access to cross a 4KB boundary. While checking is optional in this case,
receivers checking for violations of this rule will report it as a Malformed TLP.

Building Transactions: TLP Requests & Completions

In this section, the format of 3DW and 4DW headers used to accomplish specific transaction
types are described. Many of the generic fields described previously apply, but an emphasis is
placed on the fields which are handled differently between transaction types.

IO Requests

While the PCI Express specification discourages the use of IO transactions, an allowance is
made for legacy devices and software which may rely on a compatible device residing in the
system IO map rather than the memory map. While the IO transactions can technically access a
32-bit IO range, in reality many systems (and CPUs) restrict IO access to the lower 16 bits
(64KB) of this range. Figure 4-6 on page 171 depicts the system IO map and the 16/32 bit
address boundaries. PCI Express non-legacy devices are memory-mapped, and not permitted to
make requests for IO address allocation in their configuration Base Address Registers.

Figure 4-6. System IO Map

IO Request Header Format

Figure 4-7 on page 172 depicts the format of the 3DW IO request header. Each field in the
header is described in the section that follows.
Figure 4-7. 3DW IO Request Header Format

Definitions Of IO Request Header Fields

Table 4-6 on page 173 describes the location and use of each field in an IO request header.
Table 4-6. IO Request Header Fields

Field Name Header Function

Byte/Bit

Length 9:0 Byte 3 Bit 7:0 Indicates data payload size in DW. For IO requests, this
Byte 2 Bit 1:0 field is always = 1. Byte Enables are used to qualify
bytes within DW.

Attr 1:0 Byte 2 Bit 5:4 Attribute 1: Relaxed Ordering Bit

(Attributes) Attribute 0: No Snoop Bit
Both of these bits are always = 0 in IO requests.

EP Byte 2 Bit 6 If = 1, indicates the data payload (if present) is poisoned.

TD Byte 2 Bit 7 If = 1, indicates the presence of a digest field (1 DW) at

the end of the TLP (preceding LCRC and END)

TC 2:0 (Transfer Byte 2 Bit 6:4 Indicates transfer class for the packet. TC is = 0 for all IO
Class) requests.

Type 4:0 Byte 0 Bit 4:0 TLP packet type field. Always set to 00010b for IO
requests

Fmt 1:0 (Format) Byte 0 Bit 6:5 Packet Format. IO requests are:
00b = IO Read (3DW without data)
10b = IO Write (3DW with data)

1st DW BE 3:0 Byte 7 Bit 3:0 These high true bits map one-to-one to qualify bytes
(First DW Byte within the DW payload. For IO requests, any bit
Enables) combination is valid (including none)

Last BE 3:0 (Last Byte 7 Bit 7:4 These high true bits map one-to-one to qualify bytes
DW Byte Enables) within the last DW transferred. For IO requests, these
bits must be 0000b. (Single DW)

Tag 7:0 Byte 6 Bit 7:0 These bits are used to identify each outstanding request
issued by the requester. As non-posted requests are sent,
the next sequential tag is assigned.
Default: only bits 4:0 are used (32 outstanding
transactions at a time)
If Extended Tag bit in PCI Express Control Register is
set = 1, then all 8 bits may be used (256 tags).

Requester ID 15:0 Byte 5 Bit 7:0 Identifies the requester so a completion may be returned,
Byte 4 Bit 7:0 etc.
Byte 4, 7:0 = Bus Number
Table 4-6. IO Request Header Fields

Field Name Header Function

Byte/Bit

Byte 5, 7:3 = Device Number

Byte 5, 2:0 = Function Number

Address 31:2 Byte 8 Bit 7:2 The upper 30 bits of the 32-bit start address for the IO
Byte 7 Bit 7:0 transfer. Note that the lower two bits of the 32 bit address
Byte 6 Bit 7:0 are reserved (00b), forcing the start address to be DW
Byte 5 Bit 7:0 aligned.

Memory Requests

PCI Express memory transactions include two classes: Read Request/Completion and Write
Request. Figure 4-8 on page 175 depicts the system memory map and the 3DW and 4DW
memory request packet formats. When request memory data transfer it is important to remember
that memory transactions are never permitted to cross 4KB boundaries.

Figure 4-8. 3DW And 4DW Memory Request Header Formats

Description of 3DW And 4DW Memory Request Header Fields

The location and use of each field in a 4DW memory request header is listed in Table 4-7 on
page 176.

Note: The difference between a 3DW header and a 4DW header is the location and size of the
starting Address field:

 For a 3DW header (32 bit addressing): Address bits 31:2 are in Bytes 8-11, and 12-15 are
not used.
 For a 4DW header (64 bit addressing): Address bits 31:2 are in Bytes 12-15, and address
bits 63:32 are in Bytes 8-11.

Otherwise the header fields are the same.

Table 4-7. 4DW Memory Request Header Fields

Field Name Header Function

Byte/Bit

Length [9:0] Byte 3 Bit TLP data payload transfer size, in DW. Maximum transfer
7:0 Byte 2 size is 10 bits, 210 = 1024 DW (4KB). Encoding:
Bit 1:0 00 0000 0001b = 1DW
00 0000 0010b = 2DW
.
.
11 1111 1111b = 1023 DW
00 0000 0000b = 1024 DW

Attr (Attributes) Byte 2 Bit Bit 5 = Relaxed ordering.

5:4 When set = 1, PCI-X relaxed ordering is enabled for this
TLP. If set = 0, then strict PCI ordering is used.
Bit 4 = No Snoop.
When set = 1, requester is indicating that no host cache
coherency issues exist with respect to this TLP. System
hardware is not required to cause processor cache snoop for
coherency. When set = 0, PCI -type cache snoop protection
is required.

EP (Poisoned Byte 2 Bit 6 If set = 1, the data accompanying this data should be
Data) considered invalid although the transaction is being allowed
to complete normally.

TD (TLP Digest Byte 2 Bit 7 If set = 1, the optional 1 DW TLP Digest field is included
Field Present) with this TLP. Some rules: Presence of the Digest field must
be checked by all receivers (using this bit)
 A TLP with TD = 1, but no Digest field is handled as
a Malformed TLP.
 If a device supports checking ECRC and TD=1, it
must perform the ECRC check.
 If a device does not support checking ECRC
(optional) at the ultimate destination, the device must
ignore the digest field.

TC (Traffic Byte 1 Bit These three bits are used to encode the traffic class to be
Class) 6:4 applied to this TLP and to the completion associated with it
(if any).
000b = Traffic Class 0 (Default)
.
.
Table 4-7. 4DW Memory Request Header Fields

Field Name Header Function

Byte/Bit

111b = Traffic Class 7

TC 0 is the default class, and TC 1-7 are used in providing
differentiated services. See“Traffic Classes and Virtual
Channels” on page 256 for additional information.

Type[4:0] Byte 0 Bit TLP packet Type field:

4:0 00000b = Memory Read or Write
00001b = Memory Read Locked
Type field is used with Fmt [1:0] field to specify transaction
type, header size, and whether data payload is present.

Fmt 1:0 Byte 0 Bit Packet Format:

(Format) 6:5 00b = Memory Read (3DW w/o data)
10b = Memory Write (3DW w/ data)
01b = Memory Read (4DW w/o data)
11b = Memory Write (4DW w/ data)

1st DW BE 3:0 Byte 7 Bit These high true bits map one-to-one to qualify bytes within
(First DW Byte 3:0 the DW payload.
Enables)

Last BE 3:0 Byte 7 Bit These high true bits map one-to-one to qualify bytes within
(Last DW Byte 7:4 the last DW transferred.
Enables)

Tag 7:0 Byte 6 Bit These bits are used to identify each outstanding request
7:0 issued by the requester. As non-posted requests are sent, the
next sequential tag is assigned.
Default: only bits 4:0 are used (32 outstanding transactions at
a time)
If Extended Tag bit in PCI Express Control Register is set =
1, then all 8 bits may be used (256 tags).

Requester ID Byte 5 Bit Identifies the requester so a completion may be returned, etc.
15:0 7:0 Byte 4 Byte 4, 7:0 = Bus Number
Bit 7:0 Byte 5, 7:3 = Device Number
Byte 5, 2:0 = Function Number

Address 31:2 Byte 15 Bit The lower 32 bits of the 64 bit start address for the memory
7:2 transfer. Note that the lower two bits of the 32 bit address are
Byte 14 Bit reserved (00b), forcing the start address to be DW aligned.
Table 4-7. 4DW Memory Request Header Fields

Field Name Header Function

Byte/Bit

7:0
Byte 13 Bit
7:0
Byte 12 Bit
7:0

Address 63:32 Byte 11 Bit The upper 32 bits of the 64-bit start address for the memory
7:2 transfer
Byte 10 Bit
7:0
Byte 9 Bit
7:0
Byte 8 Bit
7:0

Memory Request Notes

Features of memory requests include:

1. Memory transfers are never permitted to cross a 4KB boundary.

2. All memory mapped writes are posted, resulting in much higher performance.
3. Either 32 bit or 64 bit addressing may be used. The 3DW header format supports 32 bit
addresses and the 4DW header supports 64 bits.
4. The full capability of burst transfers is available with a transfer length of 0-1024 DW (0-
4KB).
5. Advanced PCI Express Quality of Service features, including up to 8 transfer classes and
virtual channels may be implemented.
6. The No Snoop attribute bit in the header may be set = 1, relieving the system hardware
from the burden of snooping processor caches when PCI Express transactions target main
memory. Optionally, the bit may be deasserted in the packet, providing PCI-like cache
coherency protection.
7. The Relaxed Ordering bit may also be set = 1, permitting devices in the path between the
packet and its destination to apply the relaxed ordering rules available in PCI-X. If
deasserted, strong PCI producer-consumer ordering is enforced.

Configuration Requests
To maintain compatibility with PCI, PCI Express supports both Type 0 and Type 1 configuration
cycles. A Type 1 cycle propagates downstream until it reaches the bridge interface hosting the
bus (link) that the target device resides on. The configuration transaction is converted on the
destination link from Type 1 to Type 0 by the bridge. The bridge forwards and converts
configuration cycles using previously programmed Bus Number registers that specify its
primary, secondary, and subordinate buses. Refer to the “PCI-Compatible Configuration
Mechanism” on page 723 for a discussion of routing these transactions.

Figure 4-9 on page 180 illustrates a Type 1 configuration cycle making its way downstream. At
the destination link, it is converted to Type 0 and claimed by the endpoint device. Note that
unlike PCI, only one device (other than the bridge) resides on a link. For this reason, no IDSEL
or other hardware indication is required to instruct the device to claim the Type 0 cycle; any
Type 0 configuration cycle a device sees on its primary link will be claimed.

Figure 4-9. 3DW Configuration Request And Header Format

Definitions Of Configuration Request Header Fields

Table 4-8 on page 181 describes the location and use of each field in the configuration request
header illustrated in Figure 4-9 on page 180.

Table 4-8. Configuration Request Header Fields

Field Name Header Function

Byte/Bit

Length 9:0 Byte 3 Bit Indicates data payload size in DW. For configuration
7:0 Byte 2 requests, this field is always = 1. Byte Enables are used to
Bit 1:0 qualify bytes within DW (any combination is legal)

Attr 1:0 Byte 2 Bit Attribute 1: Relaxed Ordering Bit

(Attributes) 5:4 Attribute 0: No Snoop Bit
Both of these bits are always = 0 in configuration requests.

EP Byte 2 Bit If = 1, indicates the data payload (if present) is poisoned.

6

TD Byte 2 Bit If = 1, indicates the presence of a digest field (1 DW) at the

7 end of the TLP (preceding LCRC and END)

TC 2:0 (Transfer Byte 2 Bit Indicates transfer class for the packet. TC is = 0 for all
Class) 6:4 Configuration requests.

Type 4:0 Byte 0 Bit TLP packet type field. Set to:
4:0 00100b = Type 0 config request
00101b = Type 1 config request

Fmt 1:0 (Format) Byte 0 Bit Packet Format. Always a 3DW header
6:5 00b = configuration read (no data)
10b = configuration write (with data)

1st DW BE 3:0 Byte 7 Bit These high true bits map one-to-one to qualify bytes within
(First DW Byte 3:0 the DW payload. For config requests, any bit combination is
Enables) valid (including none)

Last BE 3:0 Byte 7 Bit These high true bits map one-to-one to qualify bytes within
(Last DW Byte 7:4 the last DW transferred. For config requests, these bits must
Enables) be 0000b. (Single DW)
Table 4-8. Configuration Request Header Fields

Field Name Header Function

Byte/Bit

Tag 7:0 Byte 6 Bit These bits are used to identify each outstanding request issued
7:0 by the requester. As non-posted requests are sent, the next
sequential tag is assigned.
Default: only bits 4:0 are used (32 outstanding transactions at
a time)
If Extended Tag bit in PCI Express Control Register is set =
1, then all 8 bits may be used (256 tags).

Requester ID Byte 5 Bit Identifies the requester so a completion may be returned, etc.
15:0 7:0 Byte 4 Byte 4, 7:0 = Bus Number
Bit 7:0 Byte 5, 7:3 = Device Number
Byte 5, 2:0 = Function Number

Register Number Byte 11 Bit These bits provide the lower 6 bits of DW configuration space
7:2 offset. The Register Number is used in conjunction with Ext
Register Number to provide the full 10 bits of offset needed
for the 1024 DW (4096 byte) PCI Express configuration
space.

Ext Register Byte 10 Bit These bits provide the upper 4 bits of DW configuration space
Number 3:0 offset. The Ext Register Number is used in conjunction with
(Extended Register Number to provide the full 10 bits of offset needed
Register for the 1024 DW (4096 byte) PCI Express configuration
Number) space. For compatibility, this field can be set = 0, and only the
lower 64DW (256 bytes will be seen) when indexing the
Register Number.

Completer ID Byte 9 Bit Identifies the completer being accessed with this
15:0 7:0 Byte 8 configuration cycle. The Bus and Device numbers in this field
Bit 7:0 are “captured” by the device on each configuration Type 0
write.
Byte 8, 7:0 = Bus Number
Byte 9, 7:3 = Device Number
Byte 9, 2:0 = Function Number

Configuration Request Notes

Configuration requests always use the 3DW header format and are routed by the contents of the
ID field.

All devices “capture” the Bus Number and Device Number information provided by the
upstream device during each Type 0 configuration write cycle. Information is contained in Byte
8-9 (Completer ID) of configuration request.

Completions

Completions are returned following each non-posted request:

 Memory Read request may result in completion with data (CplD)

 IO Read request may result in a completion with or without data (CplD)
 IO Write request may result in a completion without data (Cpl)
 Configuration Read request may result in a completion with data (CplD)
 Configuration Write request may result in a completion without data (Cpl)

Many of the fields in the completion must have the same values as the associated request,
including Traffic Class, Attribute bits, and the original Requester ID which is used to route the
completion back to the original requester. Figure 4-10 on page 184 depicts a completion
returning after a non-posted request, as well as the 3DW completion header format.

Figure 4-10. 3DW Completion Header Format

Definitions Of Completion Header Fields

Table 4-9 on page 185 describes the location and use of each field in a completion header.

Table 4-9. Completion Header Fields

Header
Field Name Function
Byte/Bit

Length 9:0 Byte 3 Bit Indicates data payload size in DW. For completions, this field
7:0 Byte 2 reflects the size of the data payload associated with this
Bit 1:0 completion.

Attr 1:0 Byte 2 Bit Attribute 1: Relaxed Ordering Bit

(Attributes) 5:4 Attribute 0: No Snoop Bit
For a completion, both of these bits are set to same state as in
Table 4-9. Completion Header Fields

Header
Field Name Function
Byte/Bit

the request.

EP Byte 2 Bit 6 If = 1, indicates the data payload is poisoned.

TD Byte 2 Bit 7 If = 1, indicates the presence of a digest field (1 DW) at the

end of the TLP (preceding LCRC and END)

TC 2:0 Byte 2 Bit Indicates transfer class for the packet. For a completion, TC
(Transfer Class) 6:4 is set to same value as in the request.

Type 4:0 Byte 0 Bit TLP packet type field. Always set to 01010b for a
4:0 completion.

Fmt 1:0 Byte 0 Bit Packet Format. Always a 3DW header

(Format) 6:5 00b = Completion without data (Cpl)
10b = Completion with data (CplD)

Byte Count Byte 7 Bit This is the remaining byte count until a read request is
7:0 Byte 6 satisfied. Generally, it is derived from the original request
Bit 3:0 Length field. See “Data Returned For Read Requests:” on
page 188 for special cases caused by multiple completions.

BCM (Byte Byte 6 Bit 4 Set = 1 only by PCI-X completers. Indicates that the byte
Count count field (see previous field) reflects the first transfer
Modified) payload rather than total payload remaining. See “Using The
Byte Count Modified Bit” on page 188.

CS 2:0 Byte 6 Bit These bits encoded by the completer to indicate success in
(Completion 7:5 fulfilling the request.
Status Code) 000b = Successful Completion (SC)
001b = Unsupported Request (UR)
010b = Config Req Retry Status (CR S)
100b = Completer abort. (CA)
others: reserved. See “Summary of Completion Status
Codes:” on page 187.

Completer ID Byte 5 Bit Identifies the completer. While not needed for routing a
15:0 7:0 Byte 4 completion, this information may be useful if debugging bus
Bit 7:0 traffic.
Byte 4 7:0 = Completer Bus #
Byte 5 7:3 = Completer Dev #
 Table 4-9. Completion Header Fields

Header
Field Name Function
Byte/Bit

Byte 5 2:0 = Completer Function #

Lower Address Byte 11 Bit The lower 7 bits of address for the first enabled byte of data
6:0 6:0 returned with a read. Calculated from request Length and
Byte enables, it is used to determine next legal Read
Completion Boundary. See “Calculating Lower Address
Field” on page 187.

Tag 7:0 Byte 10 Bit These bits are set to reflect the Tag received with the request.
7:0 The requester uses them to associate inbound completion
with an outstanding request.

Requester ID Byte 9 Bit Copied from the request into this field to be used in routing
15:0 7:0 Byte 8 the completion back to the original requester.
Bit 7:0 Byte 4, 7:0 = Requester Bus #
Byte 5, 7:3 = Requester Device #
Byte 5, 2:0 = Requester Function #

Summary of Completion Status Codes

(Refer to Completion Status field in table Table 4-9 on page 185).

 000b (SC) Successful Completion code indicates the original request completed properly
at the target.
 001b (UR) Unsupported Request code indicates original request failed at the target
because it targeted an unsupported address, carried an unsupported address or request,
etc. This is handled as an uncorrectable error. See the “Unsupported Request” on page
365 for details.
 010b (CRS) Configuration Request Retry Status indicates target was temporarily off-line
and the attempt should be retried. (e.g. initialization delay after reset, etc.).
 100b (CA) Completer Abort code indicates that completer is off-line due to an error
(much like target abort in PCI). The error will be logged and handled as an uncorrectable
error.

Calculating The Lower Address Field (Byte 11, bits 7:0)

Refer to the Lower Address field in Table 4-9 on page 185. The Lower Address field is set up by
the completer during completions with data (CplD) to reflect the address of the first enabled byte
of data being returned in the completion payload. This must be calculated in hardware by
considering both the DW start address and the byte enable pattern in the First DW Byte Enable
field provided in the original request. Basically, the address is an offset from the DW start
address:

 If the First DW Byte Enable field is 1111b, all bytes are enabled in the first DW and the
offset is 0. The byte start address is = DW start address.
 If the First DW Byte Enable field is 1110b, the upper three bytes are enabled in the first
DW and the offset is 1. The byte start address is = DW start address + 1.
 If the First DW Byte Enable field is 1100b, the upper two bytes are enabled in the first
DW and the offset is 2. The byte start address is = DW start address + 2.
 If the First DW Byte Enable field is 1000b, only the upper byte is enabled in the first DW
and the offset is 3. The byte start address is = DW start address + 3.

Once calculated, the lower 7 bits are placed in the Lower Address field of the completion header
in the event the start address was not aligned on a Read Completion Boundary (RCB) and the
read completion must break off at the first RCB. Knowledge of the RCB is necessary because
breaking a transaction must be done on RCBs which are based on start address--not transfer size.

Using The Byte Count Modified Bit

Refer to the Byte Count Modified Bit in Table 4-9 on page 185. This bit is only set by a PCI-X
completer (e.g. a bridge from PCI Express to PCI-X) in a particular circumstance. Rules for its
assertion include:

1. It is only set = 1 by a PCI-X completer if a read request is going to be broken into

multiple completions
2. The BCM bit is only set for the first completion of the series. It is set to indicate that the
first completion contains a Byte Count field that reflects the first completion payload
rather than the total remaining (as it would in normal PCI Express protocol). The receiver
then recognizes that the completion will be followed by others to satisfy the original
request as required.
3. For the second and any other completions in the series, the BCM bit must be deasserted
and the Byte Count field will reflect the total remaining count--just as in normal PCI
Express protocol.
4. PCI Express devices receiving completions with the BCM bit set must interpret this case
properly.
5. The Lower Address field is set up by the completer during completions with data (CplD)
to reflect the address of the first enabled byte of data being returned

Data Returned For Read Requests:

1. Completions for read requests may be broken into multiple completions, but total data
transfer must equal size of original request
2. Completions for multiple requests may not be combined
 3. IO and Configuration reads are always 1 DW, so will always be satisfied with a single
completion
4. A completion with a Status Code other than SC (successful completion) terminates a
transaction.
5. The Read Completion Boundary (RCB) must be observed when handling a read request
with multiple completions. The RCB is 64 bytes or 128 bytes for the root complex; the
value used should be visible in a configuration register.
6. Bridges and endpoints may implement a bit for selecting the RCB size (64 or 128 bytes)
under software control.
7. Completions that do not cross an aligned RCB boundary must complete in one transfer.
8. Multiple completions for a single read request must return data in increasing address
order.

Receiver Completion Handling Rules:

1. A completion received without a match to an outstanding request is an Unexpected

Completion. It will be handled as an error.
2. Completions with a completion status other than Successful Completion (SC) or
Configuration Request Retry Status (CRS) will be handled as an error and buffer space
associated with them will be released.
3. When the Root Complex receivers a CRS status during a configuration cycle, its handling
of the event is not defined except after reset (when a period is defined when it must allow
it).
4. If CRS is received for a request other than configuration, it is handled as a Malformed
TLP.
5. Completions received with status = a reserved code alias to Unsupported Requests.
6. If a read completion is received with a status other than Successful Completion (SC), no
data is received with the completion and a CPl (or CplLk) is returned in place of a CplD
(or CplDLk).
7. In the event multiple completions are being returned for a read request, a completion
status other than Successful Completion (SC) immediately ends the transaction. Device
handling of data received prior to the error is implementation-specific.
8. In maintaining compatibility with PCI, a Root Complex may be required to synthesize a
read value of a “1's” when a configuration cycle ends with a completion indicating an
Unsupported Request. (This is analogous to master aborts which occur when PCI
enumeration probes devices which are not in the system).

Message Requests

Message requests replace many of the interrupt, error, and power management sideband signals
used on earlier bus protocols. All message requests use the 4DW header format, and are handled
much the same as posted memory write transactions. Messages may be routed using address, ID,
or implicit routing. The routing subfield in the packet header indicates the routing method to
apply, and which additional header registers are in use (address registers, etc.). Figure 4-11 on
page 190 depicts the message request header format.
Figure 4-11. 4DW Message Request Header Format

Definitions Of Message Request Header Fields

Table 4-10 on page 191 describes the location and use of each field in a message request header.

Table 4-10. Message Request Header Fields

Field Name Header Function

Byte/Bit

Length 9:0 Byte 3 Bit Indicates data payload size in DW. For message requests, this
7:0 Byte 2 field is always 0 (no data) or 1 (one DW of data)
Bit 1:0

Attr 1:0 Byte 2 Bit Attribute 1: Relaxed Ordering Bit

Table 4-10. Message Request Header Fields

Field Name Header Function

Byte/Bit

(Attributes) 5:4 Attribute 0: No Snoop Bit

Both of these bits are always = 0 in message requests.

EP Byte 2 Bit 6 If = 1, indicates the data payload (if present) is poisoned.

TD Byte 2 Bit 7 If = 1, indicates the presence of a digest field (1 DW) at the

end of the TLP (preceding LCRC and END)

TC 2:0 Byte 2 Bit Indicates transfer class for the packet. TC is = 0 for all
(Transfer 6:4 message requests.
Class)

Type 4:0 Byte 0 Bit TLP packet type field. Set to:
4:0 Bit 4:3:
10b = Msg
Bit 2:0 (Message Routing Subfield)
000b = Routed to Root Complex
001b = Routed by address
010b = Routed by ID
011b = Root Complex Broadcast Msg
100b = Local; terminate at receiver
101b = Gather/route to Root Complex
0thers = reserved

Fmt 1:0 Byte 0 Bit Packet Format. Always a 4DW header

(Format) 6:5 01b = message request without data
11b = message request with data

Message Code Byte 7 Bit This field contains the code indicating the type of message
7:0 7:0 being sent.
0000 0000b = Unlock Message
0001 xxxxb = Power Mgmt Message
0010 0xxxb = INTx Message
0011 00xxb = Error Message
0100 xxxxb = Hot Plug Message
0101 0000b = Slot Power Message
0111 111xb = Vendor Type 0 Message
0111 1111b = Vendor Type 1 Message

Tag 7:0 Byte 6 Bit As all message requests are posted, no tag is assigned to them.
7:0 These bits should be = 0.
Table 4-10. Message Request Header Fields

Field Name Header Function

Byte/Bit

Requester ID Byte 5 Bit Identifies the requester sending the message.

15:0 7:0 Byte 4 Byte 4, 7:0 = Requester Bus #
Bit 7:0 Byte 5, 7:3 = Requester Device #
Byte 5, 2:0 = Requester Function #

Address 31:2 Byte 11 Bit If address routing was selected for the message (see Type 4:0
7:2 field above), then this field contains the lower part of the 64-
Byte 10 Bit bit starting address. Otherwise, this field is not used.
7:0
Byte 9 Bit
7:0
Byte 8 Bit
7:0

Address 63:32 Byte 15 Bit If address routing was selected for the message (see Type 4:0
7:2 field above), then this field contains the upper 32 bits of the 64
Byte 14 Bit bit starting address. Otherwise, this field is not used.
7:0
Byte 13 Bit
7:0
Byte 12 Bit
7:0

Message Notes

The following tables specify the message coding used for each of the seven message groups, and
is based on the message code field listed in Table 4-10 on page 191. The defined groups include:

1. INTx Interrupt Signaling

2. Power Management
3. Error Signaling
4. Lock Transaction Support
5. Slot Power Limit Support
6. Vendor Defined Messages
7. Hot Plug Signaling

INTx Interrupt Signaling

While many devices are capable of using the PCI 2.3 Message Signaled Interrupt (MSI) method
of delivering interrupts, some devices may not support it. PCI Express defines a virtual wire
alternative in which devices simulate the assertion and deassertion of the INTx (INTA-INTD)
interrupt signals seen in PCI-based systems. Basically, a message is sent to inform the upstream
device an interrupt has been asserted. After servicing, the device which sent the interrupt sends a
second message indicating the virtual interrupt signal is being released. Refer to the “Message
Signaled Interrupts” on page 331 for details. Table 4-11 summarizes the INTx message coding at
the packet level.

Table 4-11. INTx Interrupt Signaling Message Coding

INTx Message Message Code 7:0 Routing 2:0

Assert_INTA 0010 0000b 100b

Assert_INTB 0010 0001b 100b

Assert_INTC 0010 0010b 100b

Assert_INTD 0010 0011b 100b

Deassert_INTA 0010 0100b 100b

Deassert_INTB 0010 0101b 100b

Deassert_INTC 0010 0110b 100b

Deassert_INTD 0010 0111b 100b

Other INTx Rules

1. The INTx Message type does not include a data payload. The Length field is reserved.
2. Assert_INTx and Deassert_INTx are only issued by upstream ports. Checking violations
of this rule is optional. If checked, a TLP violation is handled as a Malformed TLP.
3. These messages are required to use the default traffic class, TC0. Receivers must check
for violation of this rule (handled as Malformed TLPs).
4. Components at both ends of the link must track the current state of the four virtual
interrupts. If the logical state of one of the interrupts changes at the upstream port, the
port must send the appropriate INTx message to the downstream port on the same link.
5. INTx signaling is disabled when the Interrupt Disable bit of the Command Register is set
= 1 (just as it would be if physical interrupt lines are used).
6. If any virtual INTx signals are active when the Interrupt Disable bit is set in the device,
the device must transmit a corresponding Deassert_INTx message onto the link.
 7. Switches must track the state of the four INTx signals independently for each
downstream port and combine the states for the upstream link.
8. The Root Complex must track the state of the four INTx lines independently and convert
them into system interrupts in a system-specific way.
9. Because of switches in the path, the Requester ID in an INTx message may be the last
transmitter, not the original requester.

Power Management Messages

PCI Express is compatible with PCI power management, and adds the PCI Express active link
management mechanism. Refer to Chapter 16, entitled "Power Management," on page 567 for a
description of power management. Table 4-12 on page 194 summarizes the four power
management message types.

Table 4-12. Power Management Message Coding

Power Management Message Message Code 7:0 Routing 2:0

PM_Active_State_Nak 0001 0100b 100b

PM_PME 0001 1000b 000b

PM_Turn_Off 0001 1001b 011b

PME_TO_Ack 0001 1011b 101b

Other Power Management Message Rules

1. Power Management Message type does not include a data payload. The Length field is
reserved.
2. These messages are required to use the default traffic class, TC0. Receivers must check
for violation of this rule (handled as Malformed TLPs).
3. PM_PME is sent upstream by component requesting event.
4. PM_Turn_Off is broadcast downstream
5. PME_TO_Ack is sent upstream by endpoint. For switch with devices attached to multiple
downstream ports, this message won't be sent upstream until all it is first received from
all downstream ports.

Error Messages

Error messages are sent upstream by enabled devices that detect correctable, non-fatal
uncorrectable, and fatal non-correctable errors. The device detecting the error is defined by the
Requester ID field in the message header. Table 4-13 on page 195 describes the three error
message types.

Table 4-13. Error Message Coding

Error Message Message Code 7:0 Routing 2:0

ERR_COR 0011 0000b 000b

ERR_NONFATAL 0011 0001b 000b

ERR_FATAL 0011 0011b 000b

Other Error Signaling Message Rules

1. These messages are required to use the default traffic class, TC0. Receivers must check
for violation of this rule (handled as Malformed TLPs).
2. This message type does not include a data payload. The Length field is reserved.
3. The Root Complex converts error messages into system-specific events.

Unlock Message

The Unlock message is sent to a completer to release it from lock as part of the PCI Express
Locked Transaction sequence. Table 4-14 on page 196 summarizes the coding for this message.

Table 4-14. Unlock Message Coding

Unlock Message Message Code 7:0 Routing 2:0

Unlock 0000 0000b 011b

Other Unlock Message Rules

1. These messages are required to use the default traffic class, TC0. Receivers must check
for violation of this rule (handled as Malformed TLPs).
2. This message type does not include a data payload. The Length field is reserved.

Slot Power Limit Message

This message is sent from a downstream switch or Root Complex port to the upstream port of the
device attached to it. It conveys a slot power limit which the downstream device then copies into
the Device Capabilities Register for its upstream port. Table 4-15 summarizes the coding for this
message.

Table 4-15. Slot Power Limit Message Coding

Unlock Message Message Code 7:0 Routing 2:0

Set_Slot_Power_Limit 0101 0000b 100b

Other Set_Slot_Power_Limit Message Rules

1. These messages are required to use the default traffic class, TC0. Receivers must check
for violation of this rule (handled as Malformed TLPs).
2. This message type carries a data payload of 1 DW. The Length field is set = 1. Only the
lower 10 bits of the 32-bit data payload is used for slot power scaling; the upper bits in
the data payload must be set = 0.
3. This message is sent automatically anytime the link transitions to DL_Up status or if a
configuration write to the Slot Capabilities Register occurs when the Data Link Layer
reports DL_Up status.
4. If a card in a slot consumes less power than the power limit specified for the card/form
factor, it may ignore the message.

Hot Plug Signaling Message

These messages are passed between downstream ports of switches and Root Ports that support
Hot Plug Event signaling. Table 4-16 summarizes the Hot Plug message types.

Table 4-16. Hot Plug Message Coding

Error Message Message Code 7:0 Routing 2:0

Attention_Indicator_On 0100 0001b 100b

Attention_Indicator_Blink 0100 0011b 100b

Attention_Indicator_Off 0100 0000b 100b

Power_Indicator_On 0100 0101b 100b

Power_Indicator_Blink 0100 0111b 100b

Table 4-16. Hot Plug Message Coding

Error Message Message Code 7:0 Routing 2:0

Power_Indicator_Off 0100 0100b 100b

Attention_Button_Pressed 0100 1000b 100b

Other Hot Plug Message Rules

 The Attention and Power indicator messages are all driven by the switch/root complex
port to the card.
 The Attention Button message is driven upstream by a slot device that implements a
switch.

DATA LINK LAYER PACKETS

The primary responsibility of the PCI Express Data Link Layer is to assure that integrity is
maintained when TLPs move between two devices. It also has link initialization and power
management responsibilities, including tracking of the link state and passing messages and status
between the Transaction Layer above and the Physical Layer below.

In performing its role, the Data Link Layer exchanges traffic with its neighbor using Data Link
Layer Packets (DLLPs). DLLPs originate and terminate at the Data Link Layer of each device,
without involvement of the Transaction Layer. DLLPs and TLPs are interleaved on the
link. Figure 4-12 on page 198 depicts the transmission of a DLLP from one device to another.

Figure 4-12. Data Link Layer Sends A DLLP

Types Of DLLPs

There are three important groups of DLLPs used in managing a link:

1. TLP Acknowledgement Ack/Nak DLLPs

2. Power Management DLLPs
3. Flow Control Packet DLLPs

In addition, the specification defines a vendor-specific DLLP.

DLLPs Are Local Traffic

DLLPs have a simple packet format. Unlike TLPs, they carry no target information because they
are used for nearest-neighbor communications only.

Receiver handling of DLLPs

The following rules apply when a DLLP is sent from transmitter to receiver:

1. As DLLPs arrive at the receiver, they are immediately processed. They cannot be flow
controlled.
 2. All received DLLPs are checked for errors. This includes a control symbol check at the
Physical Layer after deserialization, followed by a CRC check at the receiver Data Link
Layer. A 16 bit CRC is calculated and sent with the packet by the transmitter; the
receiver calculates its own DLLP checksum and compares it to the received value.
3. Any DLLPs that fail the CRC check are discarded. There are several reportable errors
associated with DLLPs.
4. Unlike TLPs, the is no acknowledgement protocol for DLLPs. The PCI Express
specification has time-out mechanisms which are intended to allow recovery from lost or
discarded DLLPs.
5. Assuming no errors occur, the DLLP type is determined and it is passed to the
appropriate internal logic:

- Power Management DLLPs are passed to the device power management logic

- Flow Control DLLPs are passed to the Transaction Layer so credits may be updated.

- Ack/Nak DLLPs are routed to the Data Link Layer transmit interface so TLPs in the
retry buffer may be discarded or resent.

Sending A Data Link Layer Packet

DLLPs are assembled on the transmit side and disassembled on the receiver side of a link. These
packets originate at the Data Link Layer and are passed to the Physical Layer. There, framing
symbols are added before the packet is sent. Figure 4-13 on page 200 depicts a generic DLLP in
transit from Device B to Device A.

Figure 4-13. Generic Data Link Layer Packet Format

Fixed DLLP Packet Size: 8 Bytes

All Data Link Layer Packets consist of the following components:

1. A 1 DW core (4 bytes) consisting of the one byte Type field and three additional bytes of
attributes. The attributes vary with the DLLP type.
2. A 16 bit CRC value which is calculated based on the DW core contents, then appended to
it.
3. These 6 bytes are then passed to the Physical Layer where a Start Of DLLP (SDP) control
symbol and an End Of Packet (END) control symbol are added to it. Before transmission,
the Physical Layer encodes the 8 bytes of information into eight 10-bit symbols for
transmission to the receiver.

Note that there is never a data payload with a DLLP; all information of interest is carried in the
Type and Attribute fields.

DLLP Packet Types

The three groups of DLLPs are defined with a number of variants. Table 4-17 summarizes each
variant as well as their DLLP Type field coding.

Table 4-17. DLLP Packet Types

DLLP Type Type Field Encoding Purpose

Ack (TLP Acknowledge) 0000 0000b TLP transmission integrity

Nak (TLP No Acknowledge) 0001 0000b TLP transmission integrity

PM_Enter_L1 0010 0000b Power Management

PM_Enter_L23 0010 0001b Power Management

PM_Active_State_Request_L1 0010 0011b Power Management

PM_Request_Ack 0010 0100b Power Management

Vendor Specific 0011 0000b Vendor

InitFC1-P xxx=VC # 0100 0xxxb TLP Flow Control

InitFC1-NP xxx=VC # 0101 0xxxb TLP Flow Control

InitFC1-Cpl xxx=VC # 0110 0xxxb TLP Flow Control

InitFC2-P xxx=VC # 1100 0xxxb TLP Flow Control

InitFC2-NP xxx=VC # 1101 0xxxb TLP Flow Control

InitFC2-Cpl xxx=VC # 1110 0xxxb TLP Flow Control

UpdateFC-P xxx=VC # 1000 0xxxb TLP Flow Control

UpdateFC-NP xxx=VC # 1001 0xxxb TLP Flow Control

UpdateFC-Cpl xxx=VC # 1010 0xxxb TLP Flow Control

Reserved Others Reserved

Ack Or Nak DLLP Packet Format

The format of the DLLP used by a receiver to Ack or Nak the delivery of a TLP is illustrated
in Figure 4-14.
Figure 4-14. Ack Or Nak DLLP Packet Format

Definitions Of Ack Or Nak DLLP Fields

Table 4-18 describes the fields contained in an Ack or Nak DLLP.

Table 4-18. Ack or Nak DLLP Fields

Field Name Header DLLP Function

Byte/Bit

AckNak_Seq_Num Byte 3 Bit For an ACK DLLP:

[11:0] 7:0 Byte 2  For good TLPs received with Sequence Number =
Bit 3:0 NEXT_RCV_SEQ count (count before
incrementing), use NEXT_RCV_SEQ count - 1
(count after incrementing minus 1).
 For TLP received with Sequence Number earlier
than NEXT_RCV_SEQ count (duplicate TLP),
use NEXT_RCV_SEQ count - 1.
For a NAK DLLP:
 Associated with a TLP that failed the CRC check,
use NEXT_RCV_SEQ count - 1.
 For a TLP received with Sequence Number later
than NEXT_RCV_SEQ count, use
NEXT_RCV_SEQ count - 1.
Upon receipt, the transmitter will purge TLPs with equal
to and earlier Sequence Numbers and replay the
remainder TLPs.

Type 7:0 Byte 0 Bit Indicates the type of DLLP. For the Ack/Nak DLLPs:
Table 4-18. Ack or Nak DLLP Fields

Field Name Header DLLP Function

Byte/Bit

7:0  0000 0000b = ACK DLLP.

 0001 0000b = NAK DLLP.

16-bit CRC Byte 5 Bit 16-bit CRC used to protect the contents of this DLLP.
7:0 Byte 4 Calculation is made on Bytes 0-3 of the ACK/NAK.
Bit 7:0

Power Management DLLP Packet Format

PCI Express power management DLLPs and TLPs replace most signals associated with power
management state changes. The format of the DLLP used for power management is illustrated
in Figure 4-15.

Figure 4-15. Power Management DLLP Packet Format

Definitions Of Power Management DLLP Fields

Table 4-19 describes the fields contained in a Power Management DLLP.

Table 4-19. Power Management DLLP Fields

Field Header
DLLP Function
Name Byte/Bit

Type Byte 0 Bit 7:0 This field indicates type of DLLP. For the Power Management
7:0 DLLPs:
0010 0000b = PM_Enter_L1
0010 0001b = PM_Enter_L2
0010 0011b = PM_Active_State_Request
0010 0100b = PM_Request_Ack

Link Byte 5 Bit 7:0 16 Bit CRC sent to protect the contents of this DLLP. Calculation
CRC Byte 4 Bit 7:0 is made on Bytes 0-3, regardless of whether fields are used.

Flow Control Packet Format

PCI Express eliminates many of the inefficiencies of earlier bus protocols through the use of a
credit-based flow control scheme. This topic is covered in detail in Chapter 7, entitled "Flow
Control," on page 285. Three slightly different DLLPs are used to initialize the credits and to
update them as receiver buffer space becomes available. The two flow control initialization
packets are referred to as InitFC1 and InitFC2. The Update DLLP is referred to as UpdateFC.

The generic DLLP format for all three flow control DLLP variants is illustrated in Figure 4-
16 on page 205.

Figure 4-16. Flow Control DLLP Packet Format

Definitions Of Flow Control DLLP Fields

Table 4-20 on page 206 describes the fields contained in a flow control DLLP.

Table 4-20. Flow Control DLLP Fields

Field Header DLLP Function

Name Byte/Bit

DataFC Byte 3 Bit This field contains the credits associated with data storage. Data
11:0 7:0 Byte 2 credits are in units of 16 bytes per credit, and are applied to the flow
Bit 3:0 control counter for the virtual channel indicated in V[2:0], and for the
traffic type indicated by the code in Byte 0, Bits 7:4.

HdrFC Byte 2 Bit This field contains the credits associated with header storage. Data
11:0 7:6 Byte 1 credits are in units of 1 header (including digest) per credit, and are
Bit 5:0 applied to the flow control counter for the virtual channel indicated in
V[2:0], and for the traffic type indicated by the code in Byte 0, Bits
7:4.

VC Byte 0 Bit This field indicates the virtual channel (VC 0-7) receiving the credits.
[2:0] 2:0

Type Byte 0 Bit This field contains a code indicating the type of FC DLLP:
3:0 7:4 0100b = InitFC1-P (Posted Requests)
0101b = InitFC1-NP (Non-Posted Requests)
0110b = InitFC1-Cpl (Completions)
0101b = InitFC2-P (Posted Requests)
1101b = InitFC2-NP (Non-Posted Requests)
1110b = InitFC2-Cpl (Completions)
1000b = UpdateFC-P (Posted Requests)
1001b = UpdateFC-NP (Non-Posted Requests)
1010b = UpdateFC-Cpl (Completions)

Link Byte 5 Bit 16 Bit CRC sent to protect the contents of this DLLP. Calculation is
CRC 7:0 Byte 4 made on Bytes 0-3, regardless of whether fields are used.
Bit 7:0

Vendor Specific DLLP Format

PCI Express reserves a DLLP type for vendor specific use. Only the Type code is defined. The
Vendor DLLP is illustrated in Figure 4-17.
Figure 4-17. Vendor Specific DLLP Packet Format

Definitions Of Vendor Specific DLLP Fields

Table 4-21 on page 207 describes the fields contained in a Vendor-Specific DLLP

Table 4-21. Vendor-Specific DLLP Fields

Field Header Byte/Bit DLLP Function

Name

Type Byte 0 Bit 7:4 This field contains a code indicating the Vendor-specific DLLP:
3:0 0011 0000b = Vendor specific DLLP

Link Byte 5 Bit 7:0 16 Bit CRC sent to protect the contents of this DLLP.
CRC Byte 4 Bit 7:0 Calculation is made on Bytes 0-3, regardless of whether fields
are used.