PCI Express® Architecture

Endpoint Compliance Checklist

for the PCI Express Base 1.1
Specification

Revision 1.1
10/19/2006
 ENDPOINT COMPLIANCE CHECKLIST FOR THE PCI EXPRESS BASE 1.1 SPECIFICATION,
REVISION 1.1

REVISION REVISION HISTORY DATE

1.0 Initial release 8/18/03
1.0a Update release 9/14/04
1.1 Update release 10/19/06

The PCI Special Interest Group disclaims all warranties and liability for the use of this document and the
information contained herein and assumes no responsibility for any errors that may appear in this document, nor
does the PCI Special Interest Group make a commitment to update the information contained herein.

Questions regarding the this document or membership in the PCI Special Interest Group may be forwarded to:

PCI Special Interest Group

5440 SW Westgate Drive #217
Portland, OR 97221
Phone: 503-291-2569
Fax: 503-297-1090
e-mail [email protected]
http://www.pcisig.com

DISCLAIMER
This document is provided "as is" with no warranties whatsoever, including any warranty of
merchantability, noninfringement, fitness for any particular purpose, or any warranty otherwise arising
out of any proposal, specification, or sample. The PCI SIG disclaims all liability for infringement of
proprietary rights, relating to use of information in this specification. No license, express or implied, by
estoppel or otherwise, to any intellectual property rights is granted herein.

All product names are trademarks, registered trademarks, or servicemarks of their respective owners.

2
 ENDPOINT COMPLIANCE CHECKLIST FOR THE PCI EXPRESS BASE 1.1 SPECIFICATION,
REVISION 1.1

Table of Contents
INTRODUCTION..................................................................................................................................4
PRODUCT INFORMATION....................................................................................................................5
TOPOLOGY CHECKLIST......................................................................................................................6
TRANSACTION LAYER CHECKLIST....................................................................................................7
LINK LAYER CHECKLIST.................................................................................................................31
ELECTRICAL CHECKLIST.................................................................................................................39
POWER MANAGEMENT CHECKLIST.................................................................................................61
SYSTEM ARCHITECTURE CHECKLIST..............................................................................................69
Configuration Checklist................................................................................................................76

3
 ENDPOINT COMPLIANCE CHECKLIST FOR THE PCI EXPRESS BASE 1.1 SPECIFICATION,
REVISION 1.1

Introduction

This document provides checklists for PCI Express Root Endpoints.

The requirements listed in this document are provided as an aid in designing and validating PCI Express
devices. While reasonably complete, the checklist is not necessarily comprehensive. This document is
only a summary of most of the requirements of the PCI Express Base Specification, Revision 1.1 (PCI
Express 1.1) In case of discrepancy between this document and PCI Express 1.1, PCI Express 1.1
governs. PCI Express devices must meet all of the requirements of PCI Express 1.1 whether or not
those requirements are repeated in this document.

This checklist is also used as one of the requirements to qualify a PCI product for the Integrator’s List
by creating a paper trail of testing for PCI compliance. Vendors that want their products on the
Integrator’s List must complete this checklist and submit it to the SIG or its agent. Note that to be
included on the Integrator’s List, products must also successfully complete PCI SIG compliance and
interoperability testing done at a Compliance Workshop.

There is PCI Express functionality that is optional to implement. Assertions for these optional features
are included in this checklist. If a product does not implement an optional feature, please write in an
‘NA’ response in either the ‘Y’ or ‘N’ area.

CHECKLIST STRUCTURE:
Indicate whether
Unique Base Specification Assertion device satisfies
Assertion Section/Paragraph Text assertion
Identifier Reference

ID Ref Assertion Y N
TPL.03.01#02 1.3.1 A Root Complex must support generation of configuration requests as a
requester.

4
 ENDPOINT COMPLIANCE CHECKLIST FOR THE PCI EXPRESS BASE 1.1 SPECIFICATION,
REVISION 1.1

Product Information

Date
Vendor Name
Vendor Street Address
Vendor City, State, Zip
Vendor Phone Number
Vendor Contact, Title
Vendor Email address
Product Name
Product Model Number
Product Revision Level
Product Description (brief description of product
function)

Compliance Workshop Product was Tested at: Workshop #_____ Date ____________

Preferred listing on Integrators List

If this product (or products) qualifies for inclusion on the PCI Express Integrators List, please
indicate in the area below how you would like the product(s) listed. If this product qualifies for
inclusion on the PCIe Integrator’s List as a PCIe 1.0a product (but not as a PCIe 1.1 product),
please list it as a PCIe 1.0a product.

Company Product Identifier Max Function

Supported
Lane Width

5
 ENDPOINT COMPLIANCE CHECKLIST FOR THE PCI EXPRESS BASE 1.1 SPECIFICATION,
REVISION 1.1

Topology Checklist

ID Ref Assertion Y N
TPL.03.01#04 1.3.1 Devices that generate peer-to-peer transactions through the Root Complex
must be able to handle having the Root Complex split the packet into smaller
packets.
TPL.03.02#02 1.3.2.1 A Legacy Endpoint must support Configuration Requests as a completer.
TPL.03.02#03 1.3.2.1 A Legacy Endpoint must not issue a Locked Request.
TPL.03.02#04 1.3.2.1 An Endpoint device must report its self as one of the following: Legacy
Endpoint; PCI Express Endpoint; or Root Complex Integrated Endpoint.
TPL.03.02#05 1.3.2.1 A Legacy Endpoint must have a Type 00h configuration space header.
TPL.03.02#06 1.3.2.1 A Legacy Endpoint that needs to support legacy software must support Lock
memory semantics as a completer.
TPL.03.02#07 1.3.2.1 A Legacy Endpoint that requests an interrupt must support MSI, or MSI-X, or
both.
TPL.03.03#02 1.3.2.2 A PCI Express Endpoint (ie. non-legacy) must support Configuration Requests
as a completer.
TPL.03.03#04 1.3.2.2 A PCI Express Endpoint (ie. non-legacy) must not generate I/O Requests.
TPL.03.03#05 1.3.2.2 A PCI Express Endpoint (ie. non-legacy) must not support Locked Requests as
a completer or generate them as a requester.
TPL.03.03#06 1.3.2.2 A PCI Express Endpoint (ie. non-legacy) must have a Type 00h configuration
space header.
TPL.03.03#07 1.3.2.2 A PCI Express Endpoint (ie. non-legacy) must operate normally, even if the
operating system does not allocate any I/O type resources requested by the
devices Base Address registers.
TPL.03.03#09 1.3.2.2 A PCI Express Endpoint (ie. non-legacy) must be able to generate 64 bit
Memory Requests.
TPL.03.03#10 1.3.2.2 A PCI Express Endpoint (ie. non-legacy) that requests an interrupt must
support MSI, or MSI-X, or both. If MSI is implemented, it must use only the
64 bit Address version of the MSI Capability structure.
TPL.03.03#11 1.3.2.2 A PCI Express Endpoint (ie. non-legacy) that requests an memory resource for
an address range that can tolerate read-aheads without suffering side-effects, or
that can tolerate write merging, must set the Prefetchable bit to 1 in the
associated Base Address register.
TPL.03.03#12 1.3.2.2 A PCI Express Endpoint (ie. non-legacy) must use a 64 bit address for any
Base Address register, requesting a memory resource, that sets the
Prefetchable bit to 1.

6
 ENDPOINT COMPLIANCE CHECKLIST FOR THE PCI EXPRESS BASE 1.1 SPECIFICATION,
REVISION 1.1

Transaction Layer Checklist

ID Ref Assertion Y N
TXN.02.00#03 2.2 ALL TLP fields marked Reserved in the PCI Express Base Specification
1.1, must be ignored by receivers, but are included in all LCRC and ECRC
calculations.
TXN.02.00#02 2.2 All TLP fields marked Reserved in the PCI Express Base Specification 1.1,
must be filled with all 0 when a TLP is formed for transmission (this does
not include TLPs that are being forwarded by a Switch).
TXN.02.01#01 2.2.1 All TLP headers must follow the field format specified in the Fields Present
in All TLPs Figure 2-4 of the PCI Express Base Specification 1.1.
TXN.02.01#02 2.2.1 All TLPs must only use permitted Fmt[1:0] and Type[4:0] field values are
shown in Fmt[1:0] and Type[4:0] Field Encodings Table 2-3 of the PCI
Express Base Specification 1.1 (all other encodings are reserved).
TXN.02.01#03 2.2.1 A TLP with the TD Field set to 1 indicates the presence of a TLP digest in
the form of a single DW at the end of the TLP giving an ECRC value.
TXN.02.01#04 2.2.1 All TLP data must be four-byte naturally aligned and in increments of four-
byte Double Words (DW).
TXN.02.01#06 2.2.1 A TLP with the EP Field set to 1 indicates that the TLP is poisoned.
TXN.02.02#03 2.2.2 The Transmitter of a TLP with a data payload as given by the TLP’s length
field must not allow the data payload length to exceed the length specified
by the value in the Max_Payload_Size field of the Transmitter's Device
Control register taken as an integral number of DW.
TXN.02.02#08 2.2.2 When a data payload is included in a TLP, the first byte of data following
the header corresponds to the byte address closest to zero and the
succeeding bytes are in increasing byte address sequence.
TXN.02.02#07 2.2.2 The value in the TLP Length field applies only to data, any TLP Digest (if
present) is not included in the Length.
TXN.02.02#16 2.2.2 For an Upstream Port associated with a multifunction device whose
Max_Payload_Size settings are not identical across all functions, the
Receiver is required to check the TLP’s data payload against a
Max_Payload_Size setting whose determination is implementation specific.
TXN.02.02#15 2.2.2 For an Upstream Port associated with a multifunction device whose
Max_Payload_Size settings are identical across all functions, the Receiver is
required to check the TLP’s data payload size against the common
Max_Payload_Size setting.
TXN.02.02#14 2.2.2 The receiving device must check that the size of the data payload of a
Received TLP and the value given by the TLP's Length field, must match.
If this rule is violated, than the TLP is a Malformed TLP and is reported (if
enabled) as an error associated with the receiving port.
TXN.02.02#05 2.2.2 For TLPs that include data, the value in the Length field and the actual
amount of data included in the TLP must match.
TXN.02.02#04 2.2.2 The receiving device must check that the size of the data payload of a
Received TLP, as given by the TLP's Length field, must not exceed the
length specified by the value in the Max_Payload_Size field of the receiver's
Device Control register, taken as an integral number of DW. If this rule is
violated, than the TLP is a Malformed TLP and is reported (if enabled) as an
error associated with the receiving port.
TXN.02.02#11 2.2.2 For an Upstream Port associated with a multifunction device whose
Max_Payload_Size settings are identical across all functions, a transmitted
TLP’s data payload must not exceed the common Max_Payload_Size
setting.

7
 ENDPOINT COMPLIANCE CHECKLIST FOR THE PCI EXPRESS BASE 1.1 SPECIFICATION,
REVISION 1.1

ID Ref Assertion Y N
TXN.02.02#02 2.2.2 A TLP's Length field must give the length as an integral number of DW.
TXN.02.02#12 2.2.2 For an Upstream Port associated with a multifunction device whose
Max_Payload_Size settings are not identical across all functions, a
transmitted TLP’s data payload must not exceed a Max_Payload_Size
setting whose determination is implementation specific.
TXN.02.03#06 2.2.3 The receiving device must check that the observed size of the Received TLP
(including any data payload), must match the indicated presence/absence of
a TLP Digest (if TD=1 than observed TLP size must includes a Digest, if
TD=0, than observed TLP size must not include a Digest). If this rule is
violated, than the TLP is a Malformed TLP and is reported (if enabled) as an
error associated with the receiving port.
TXN.02.03#05 2.2.3 If the device at the ultimate destination of the TLP supports ECRC
checking, the device interprets the value in the TLP Digest field as an ECRC
value, according to the rules in Section 2.7.1 of the PCI Express Base
Specification 1.1. (Note: the device must be enabled for ECRC checking
before it can report an ECRC error.)
TXN.02.03#03 2.2.3 If the device at the ultimate destination of the TLP does not support ECRC
checking, the device must ignore the TLP Digest.
TXN.02.04#04 2.2.4.1 For Memory or I/O requests, TLP address fields must follow the order
specified in Address Field Mapping Table 2-5 in the PCI Express Base
Specification 1.1.
TXN.02.04#01 2.2.4.1 For Memory Read or Memory Write requests, requesters must use the 32 bit
address format for addresses below 4 GB.
TXN.02.04#05 2.2.4.1 For Memory Read or Memory Write requests, requesters must use the 64 bit
address format for addresses above (or equal to) 4 GB.
TXN.02.04#02 2.2.4.1 For I/O Read or I/O Write requests, requesters must use the 32 bit address
format.
TXN.02.04#03 2.2.4.1 All PCI Express Agents must decode all address bits in the header.
TXN.02.05#03 2.2.4.2 TLPs that use ID routing use the Bus, Device and Function numbers to
specify the destination device for the TLP.
TXN.02.05#04 2.2.4.2 TLP ID routing header field locations must comply with Header Field
Locations for ID Routing Table 2-6 in the PCI Express Base Specification
1.1.
TXN.02.05#01 2.2.4.2 Configuration Request and Completion TLPs must use ID routing.
Vendor_Defined messages may optionally use ID routing.
TXN.02.06#05 2.2.5 For each bit of the Byte Enables fields, a value of 1b indicates that the
corresponding byte of data must be written or read at the Completer.
TXN.02.06#10 2.2.5 A Flush request (a way to ensure that previous posted Write requests have
completed at their destination) applies only to traffic in the same Traffic
Class as the zero length Read.
TXN.02.06#09 2.2.5 A Memory Read request of 1 DW with no bytes enabled must have no side-
effect at the Completer.
TXN.02.06#08 2.2.5 A Write request with a length of 1 DW with no bytes enabled must have no
effect at the Completer.
TXN.02.05#21 2.2.5 The receiving device may optionally check if all non-QW (Quad Word)
aligned Memory requests with length of 2 DW and Memory Requests with
length of 3 DW or more, have enabled only bytes that are contiguous with
the data between the first and last DW of the request. If this optional check
is implemented and fails, than the TLP is a Malformed TLP and is reported
as an error (if enabled) associated with the receiving port.
TXN.02.06#11 2.2.5 All non-QW (Quad Word) aligned Memory requests with length of 2 DW
and Memory Requests with length of 3 DW or more, must enable only bytes
that are contiguous with the data between the first and last DW of the
request.

8
 ENDPOINT COMPLIANCE CHECKLIST FOR THE PCI EXPRESS BASE 1.1 SPECIFICATION,
REVISION 1.1

ID Ref Assertion Y N
TXN.02.05#20 2.2.5 The receiving device may optionally check if Non-contiguous Byte Enables
(two or more enabled bytes separated by non-enabled bytes) are used for
Memory requests of 3 DW or greater, or for Memory requests of 2 DW that
are not QW (Quad Word) aligned. If this optional check is implemented
and fails, than the TLP is a Malformed TLP and is reported as an error (if
enabled) associated with the receiving port.
TXN.02.05#19 2.2.5 Non-contiguous Byte Enables (two or more enabled bytes separated by non-
enabled bytes) must not be used for Memory requests of 3 DW or greater, or
for Memory requests of 2 DW that are not QW (Quad Word) aligned.
TXN.02.06#07 2.2.5 Byte enables must comply with the Request Header mapping to referenced
data as specified in Byte Enables Location and Correspondence Table 2-7 of
the PCI Express Base Specification 1.1.
TXN.02.05#18 2.2.5 The receiving device may optionally check that if the Length field for a
request indicates a length of greater than 1 DW, then the Last DW BE[3:0]
field must not be 0000b. If this optional check is implemented and fails,
than the TLP is a Malformed TLP and is reported as an error (if enabled)
associated with the receiving port.
TXN.02.06#03 2.2.5 If the Length field for a request indicates a length of greater than 1 DW,
then the Last DW BE[3:0] field must not be 0000b.
TXN.02.05#17 2.2.5 The receiving device may optionally check that if the Length field for a
request indicates a length of 1 DW then the byte enables for the Last DW
BE[3:0] field must be 0000b. If this optional check is implemented and
fails, than the TLP is a Malformed TLP and is reported as an error (if
enabled) associated with the receiving port.
TXN.02.06#02 2.2.5 If the Length field for a request indicates a length of 1 DW then the byte
enables for the Last DW BE[3:0] field must be 0000b.
TXN.02.05#16 2.2.5 If the Length field for a request indicates a length of greater than 1DW then
the byte enables for the last DW must be accurately given by the Last DW
BE[3:0] field.
TXN.02.05#13 2.2.5 Memory, I/O, and Configuration Request TLPs must include Byte Enables
to designate valid bytes in the data.
TXN.02.05#15 2.2.5 The receiving device may optionally check that if the Length field for a
request indicates a length of greater than 1 DW then the byte enables for the
first DW given by the 1st DW BE[3:0] field must not be 0000b. If this
optional check is implemented and fails, than the TLP is a Malformed TLP
and is reported as an error (if enabled) associated with the receiving port.
TXN.02.06#12 2.2.5 A Read request of 1 DW with no bytes enabled must cause the Completer to
send a corresponding Completion with a Length of 1 DW and a data
payload of 1 DW (the contents of the data payload within the Completion
packet is unspecified and may be any value).
TXN.02.06#01 2.2.5 If the Length field for a request indicates a length of greater than 1 DW then
the byte enables for the first DW given by the 1st DW BE[3:0] field must
not be 0000b.
TXN.02.05#14 2.2.5 If the Length field for a request indicates a length of 1 DW (or greater than
1DW) then the byte enables for the only DW (or the first DW) must be
accurately given by the 1st DW BE[3:0] field.
TXN.02.06#04 2.2.5 For each bit of the Byte Enables fields, a value of 0b indicates that the
corresponding byte of data must not be written or, if non-prefetchable, must
not be read at the Completer.

9
 ENDPOINT COMPLIANCE CHECKLIST FOR THE PCI EXPRESS BASE 1.1 SPECIFICATION,
REVISION 1.1

ID Ref Assertion Y N
TXN.02.07#09 2.2.6.2 Functions (other than Root Complex logical devices and Switch
downstream ports) must capture the Bus and Device Numbers supplied with
all Configuration Write requests (Type 0) completed by the function and
supply the most recently captured numbers in the Bus and Device Number
fields of the Requester ID for all requests initiated by the device/function
and the Completer ID for all completions generated by the device/function.
TXN.02.07#11 2.2.6.2 Prior to the initial Configuration Write (Type 0) completed by a device, that
device (except for logical devices within a Root Complex) is not permitted
to initiate Non-posted requests.
TXN.02.07#07 2.2.6.2 Requesters must ensure that a Transaction ID (Requester ID + Tag) is
included with all Requests. Completers must ensure that a Transaction ID
(Requester ID + Tag) is included with all Completions.
TXN.02.07#05 2.2.6.2 The receiver of any Posted request (except for certain types of Vendor
defined messages) must not be affected by the value in the Tag field for that
request.
TXN.02.07#03 2.2.6.2 If the Extended Tag Field Enable bit is set (and Phantom Functions Enable
bit is clear), the requester can allow a maximum number of outstanding
requests (that require a Completion for that requester) per device/function of
256, and all 8 bits of the Tag field are used.
TXN.02.07#13 2.2.6.2 Each function associated with a logical device must only respond to a
unique Function Number for Configuration Requests addressing that logical
device.
TXN.02.07#02 2.2.6.2 By default a requester can only allow a maximum number of outstanding
requests (that require a Completion for that requester) per device/function of
32, and only the lower 5 bits of the Tag field are used with the remaining
upper 3 bits required to be all 0.
TXN.02.07#04 2.2.6.2 If the Phantom Functions Enable bit is set, the requester can use some or all
of the Function Number field of the Transaction ID to extend the number of
outstanding requests (that require a Completion for that requester). The
number of outstanding requests can be increased by two times, four times or
eight times, depending on the value returned in the Phantom Functions
Supported field. The combination of the Function Number field and the Tag
field must be unique for all outstanding requests that require a Completion
for that requester.
TXN.02.07#01 2.2.6.2 The requester must generate Tag[7:0] which is a 8-bit field in the TLP
which must be unique for all outstanding requests that require a Completion
for that requester.
TXN.02.08#03 2.2.6.4 The Relaxed Ordering Attribute bit in a request must be set to 0 when
requiring a PCI Strongly Ordered Model. It must be set to 1 when allowing
a PCI-X Relaxed Ordering Model.
TXN.02.08#01 2.2.6.4 The Relaxed Ordering Attribute bit must be set to 0 for Configuration
requests, I/O requests, memory requests that are Message Signaled
Interrupts, and message requests (except where specifically permitted in the
PCI Express Base Specification 1.1).
TXN.02.09#02 2.2.6.5 The No Snoop Attribute bit in a request must be set to 0 when specifying
that hardware enforced cache coherency is expected to be maintained. It
must be set to 1 when specifying that hardware enforced cache coherency is
not expected to be maintained.
TXN.02.09#01 2.2.6.5 The No Snoop Attribute must be set to 0 for Configuration requests, I/O
requests, memory requests that are Message Signaled Interrupts, and
message requests (except where specifically permitted in the PCI Express
Base Specification 1.1).
TXN.02.10#01 2.2.6.6 TC0 is the default TC and must be supported by every PCI Express device.

10
 ENDPOINT COMPLIANCE CHECKLIST FOR THE PCI EXPRESS BASE 1.1 SPECIFICATION,
REVISION 1.1

ID Ref Assertion Y N
TXN.02.10#02 2.2.6.6 The TC field must pass unchanged when a TLP traverses from end to end
within the PCI Express fabric.
TXN.02.11#21 2.2.7 The receiving device may optionally check if Configuration requests have
the Attr[1:0] field equal to 00b. If this optional check is implemented and
fails, than the TLP is a Malformed TLP and is reported as an error (if
enabled) associated with the receiving port.
TXN.02.11#06 2.2.7 All Configuration requests, in addition to the header fields included in all
Memory, I/O and Configuration requests and the ID routing fields, contain
the following additional fields:- Register Number[5:0], and Extended
Register Number[3:0].
TXN.02.11#07 2.2.7 Requesters must ensure that Configuration requests must have the TC0[2:0]
field equal to 000b.
TXN.02.11#19 2.2.7 The receiving device may optionally check if Configuration requests have
the TC0[2:0] field equal to 000b. If this optional check is implemented and
fails, than the TLP is a Malformed TLP and is reported as an error (if
enabled) associated with the receiving port.
TXN.02.11#20 2.2.7 Requesters must ensure that Configuration requests have the Attr[1:0] field
equal to 00b.
TXN.02.11#22 2.2.7 Requesters must ensure that Configuration requests have the Length[9:0]
field equal to 00 0000 0001b (1 DW).
TXN.02.11#23 2.2.7 The receiving device may optionally check if Configuration requests have
the Length[9:0] field equal to 00 0000 0001b (1 DW). If this optional check
is implemented and fails, than the TLP is a Malformed TLP and is reported
as an error (if enabled) associated with the receiving port.
TXN.02.11#24 2.2.7 Requesters must ensure that Configuration requests have the Last DW
BE[3:0] field equal to 0000b.
TXN.02.11#25 2.2.7 The receiving device may optionally check if Configuration requests have
the Last DW BE[3:0] field equal to 0000b. If this optional check is
implemented and fails, than the TLP is a Malformed TLP and is reported as
an error (if enabled) associated with the receiving port.
TXN.02.11#18 2.2.7 The receiving device may optionally check if I/O requests have the Last DW
BE[3:0] field equal to 0000b. If this optional check is implemented and
fails, than the TLP is a Malformed TLP and is reported as an error (if
enabled) associated with the receiving port.
TXN.02.11#08 2.2.7 The request format used for MSI/MSI-X transactions is identical to the
Memory Write request format. MSI/MSI-X requests are indistinguishable
from Memory Writes with regard to ordering, Flow Control, and data
integrity.
TXN.02.11#17 2.2.7 Requesters must ensure that I/O requests have the Last DW BE[3:0] field
equal to 0000b.
TXN.02.11#16 2.2.7 The receiving device may optionally check if I/O requests have the
Length[9:0] field equal to 00 0000 0001b (1 DW). If this optional check is
implemented and fails, than the TLP is a Malformed TLP and is reported as
an error (if enabled) associated with the receiving port.
TXN.02.11#15 2.2.7 Requesters must ensure that I/O requests have the Length[9:0] field equal to
00 0000 0001b (1 DW).
TXN.02.11#14 2.2.7 The receiving device may optionally check if I/O requests have the Attr[1:0]
field equal to 00b. If this optional check is implemented and fails, than the
TLP is a Malformed TLP and is reported as an error (if enabled) associated
with the receiving port.
TXN.02.11#13 2.2.7 Requesters must ensure that I/O requests have the Attr[1:0] field equal to
00b.

11
 ENDPOINT COMPLIANCE CHECKLIST FOR THE PCI EXPRESS BASE 1.1 SPECIFICATION,
REVISION 1.1

ID Ref Assertion Y N
TXN.02.11#12 2.2.7 The receiving device may optionally check if I/O requests have the
TC0[2:0] field equal to 000b. If this optional check is implemented and
fails, than the TLP is a Malformed TLP and is reported as an error (if
enabled) associated with the receiving port.
TXN.02.11#04 2.2.7 Requesters must ensure that I/O requests must have the TC0[2:0] field equal
to 000b.
TXN.02.11#11 2.2.7 The receiving device may optionally check if Memory requests specify an
Address/Length combination which causes a memory space access to cross
a 4KB boundary. If this optional check is implemented and fails, than the
TLP is a Malformed TLP and is reported as an error (if enabled) associated
with the receiving port.
TXN.02.11#09 2.2.7 Requesters must ensure that Memory requests must not specify an
Address/Length combination which causes a memory space access to cross
a 4KB boundary.
TXN.02.11#01 2.2.7 All Memory, I/O and Configuration requests include the following fields in
addition to the common header fields: Requester ID[15:0], Tag[7:0], Last
DW BE[3:0], and 1st DW BE[3:0].
TXN.02.11#10 2.2.7 Requesters must ensure that for Memory Read requests, the request Length
must not exceed the value specified by Max_Read_Request_Size field.
TXN.02.12#05 2.2.8 Message requests are posted and do not require Completion.
TXN.02.12#07 2.2.8 Message routing is by address routing, ID routing, or implicit routing. The
r[2:0] sub-field value of the Type field determines the routing mechanism.
TXN.02.12#08 2.2.8 Message requests must use r[2:0] sub-field values given in the Message
Routing Table 2-11 in the PCI Express Base Specification 1.1.
TXN.02.12#06 2.2.8 Message requests follow the same ordering rules as Memory Write
Requests.
TXN.02.12#03 2.2.8 Receivers must fully decode the Message Code[7:0] field.
TXN.02.12#01 2.2.8 All Message requests include the following fields in addition to the common
header fields: Requester ID[15:0], Tag[7:0], and Message Code[7:0].
TXN.02.12#02 2.2.8 All Message requests use the Msg Type field encoding, except for the
Vendor_Defined messages, which can use either Msg or MsgD, and the Set
Slot Power Limit message which uses MsgD.
TXN.02.12#04 2.2.8 For Message requests, the Attr[1:0] field is reserved (except as noted in the
PCI Express Base Specification 1.1).
TXN.02.12#09 2.2.8 Message requests must use Byte 8 to Byte 15 values given in the Message
Routing Table 2-11 in the PCI Express Base Specification 1.1.
TXN.02.13#06 2.2.8.1.1 The receiving device may optionally check if the Assert_INTx and
Deassert_INTx Message was issued by an Upstream port. If this optional
check is implemented and fails, than the TLP is a Malformed TLP and is
reported as an error (if enabled) associated with the receiving port.
TXN.02.13#21 2.2.8.1.1 The Requester ID of an Assert INTx or Deassert INTx Message will
correspond to the transmitter of the message on that link (not necessarily to
the original source of the interrupt).
TXN.02.13#14 2.2.8.1.1 A Deassert_INTx Message must be sent for each INTx virtual wire that is in
the active state when the Interrupt Disable bit in the Command register is set
to 1.
TXN.02.13#13 2.2.8.1.1 Sending Assert_INTx Messages is disabled when the Interrupt Disable bit of
the Command register is set to 1.
TXN.02.13#12 2.2.8.1.1 When the local logical state of an INTx virtual wire changes at an Upstream
port, the port must communicate this change in state to the Downstream port
on the other side of the same link using the appropriate Assert_INTx or
Deassert_INTx Message.
TXN.02.13#11 2.2.8.1.1 A Deassert_INTx Message represents the inactive going transition of the
INTx (x = A, B, C, or D) virtual wire.

12
 ENDPOINT COMPLIANCE CHECKLIST FOR THE PCI EXPRESS BASE 1.1 SPECIFICATION,
REVISION 1.1

ID Ref Assertion Y N
TXN.02.13#10 2.2.8.1.1 An Assert_INTx Message represents the active going transition of the INTx
(x = A, B, C, or D) virtual wire.
TXN.02.13#09 2.2.8.1.1 Devices at both ends of the link must track the logical state of the four
virtual interrupt wires using the Assert/Deassert Messages to represent the
active and inactive transitions (respectively) of each corresponding virtual
wire.
TXN.02.13#07 2.2.8.1.1 Requesters must ensure that Assert_INTx and Deassert INTx Messages use
only TC0.
TXN.02.13#05 2.2.8.1.1 Requesters must ensure that Assert_INTx and Deassert_INTx Messages are
only issued by Upstream ports.
TXN.02.13#04 2.2.8.1.1 For INTx Messages, the TLP Length[9:0] field is reserved.
TXN.02.13#03 2.2.8.1.1 Assert_INTx/Deassert_INTx Messages must use Msg Type and do not have
a data payload.
TXN.02.13#27 2.2.8.1.1 INTx Messages must use the Requester ID field values defined in the INTx
Mechanism Messages Table 2-12 of the PCI Express Base Specification 1.1.
TXN.02.13#26 2.2.8.1.1 INTx Messages can be supported as a transmitter, or receiver, or both based
on the values defined in the INTx Mechanism Messages Table 2-12 of the
PCI Express Base Specification 1.1.
TXN.02.13#01 2.2.8.1.1 INTx Messages must use the Code[7:0] and r[2:0] sub-field values defined
in the INTx Mechanism Messages Table 2-12 of the PCI Express Base
Specification 1.1.
TXN.02.13#08 2.2.8.1.1 The receiving device must check if the Assert_INTx and Deassert INTx
Messages use only TC0. If this check fails, than the TLP is a Malformed
TLP and is reported as an error (if enabled) associated with the receiving
port.
TXN.02.14#03 2.2.8.1.2 For Power Management Messages, the TLP Length[9:0] field is reserved.
TXN.02.14#06 2.2.8.1.2 Power Management Messages can be supported as a transmitter, or receiver,
or both based on the values defined in the Power Management Messages
Table 2-14 of the PCI Express Base Specification 1.1.
TXN.02.14#05 2.2.8.1.2 The receiving device must check if the Power Management Messages use
only TC0. If this check fails, than the TLP is a Malformed TLP and is
reported as an error (if enabled) associated with the receiving port.
TXN.02.14#04 2.2.8.1.2 Requesters must ensure that Power Management Messages use only TC0.
TXN.02.14#07 2.2.8.1.2 Power Management Messages must use the Requester ID field values
defined in the Power Management Messages Table 2-14 of the PCI Express
Base Specification 1.1.
TXN.02.14#01 2.2.8.1.2 Power Management Messages must use the Code[7:0] and r[2:0] sub-field
values defined in the Power Management Messages Table 2-14 of the PCI
Express Base Specification 1.1.
TXN.02.14#02 2.2.8.1.2 Power Management Messages must use Msg Type and do not have a data
payload.
TXN.02.15#04 2.2.8.1.3 Requesters must ensure that Error Signaling Messages use only TC0.
TXN.02.15#09 2.2.8.1.3 The receiving device must check if the Error Signaling Messages use only
TC0. If this check fails, than the TLP is a Malformed TLP and is reported
as an error (if enabled) associated with the receiving port.
TXN.02.15#03 2.2.8.1.3 For Error Signaling Messages, the TLP Length[9:0] field is reserved.
TXN.02.15#02 2.2.8.1.3 Error Signaling Messages must use Msg Type and do not have a data
payload.
TXN.02.15#08 2.2.8.1.3 Error Signaling Messages must use the Requester ID field values defined in
the Error Signaling Messages Table 2-15 of the PCI Express Base
Specification 1.1.
TXN.02.15#07 2.2.8.1.3 Error Signaling Messages can be supported as a transmitter, or receiver, or
both based on the values defined in the Error Signaling Messages Table 2-
15 of the PCI Express Base Specification 1.1.

13
 ENDPOINT COMPLIANCE CHECKLIST FOR THE PCI EXPRESS BASE 1.1 SPECIFICATION,
REVISION 1.1

ID Ref Assertion Y N
TXN.02.15#01 2.2.8.1.3 Error Signaling Messages must use the Code[7:0] and r[2:0] sub-field values
defined in the Error Signaling Messages Table 2-15 of the PCI Express Base
Specification 1.1.
TXN.02.15#06 2.2.8.1.3 Error Signaling Messages are only initiated by the agent that detected the
error.
TXN.02.16#06 2.2.8.1.4 Unlock Messages can be supported as a transmitter, or receiver, or both
based on the values defined in the Unlock Message Table 2-16 of the PCI
Express Base Specification 1.1.
TXN.02.16#07 2.2.8.1.4 Unlock Messages must use the Requester ID field values defined in the
Unlock Message Table 2-16 of the PCI Express Base Specification 1.1.
TXN.02.16#02 2.2.8.1.4 Unlock Messages must use Msg Type and do not have a data payload.
TXN.02.16#03 2.2.8.1.4 For Unlock Messages, the TLP Length[9:0] field is reserved.
TXN.02.16#05 2.2.8.1.4 The receiving device must check if the Unlock Messages use only TC0. If
this check fails, than the TLP is a Malformed TLP and is reported as an
error (if enabled) associated with the receiving port.
TXN.02.16#01 2.2.8.1.4 Unlock Messages must use the Code[7:0] and r[2:0] sub-field values defined
in the Unlock Message Table 2-16 of the PCI Express Base Specification
1.1.
TXN.02.17#12 2.2.8.1.5 The receiving device must check if the Set_Slot_Power_Limit Messages use
only TC0. If this check fails, than the TLP is a Malformed TLP and is
reported as an error (if enabled) associated with the receiving port.
TXN.02.17#04 2.2.8.1.5 The received Set_Slot_Power_Limit message data payload value must be
written into the Device Capabilities register of the Upstream port on the
other side of the link from the initiator of the message, except in the case
where the receiving device never consumes more than the minimum power
allowance for its form factor or the receiving device is integrated on the
system planar.
TXN.02.17#05 2.2.8.1.5 The Set_Slot_Power_Limit Message data payload byte 1 (bits 1:0) map to
the Slot Power Limit Scale field.
TXN.02.17#08 2.2.8.1.5 The Set_Slot_Power_Limit Message data payload byte 3 (bits 7:0), byte 2
(bits 7:0), and byte 1 (bits 7:2) must be ignored by the receiver.
TXN.02.17#14 2.2.8.1.5 Set_Slot_Power_Limit Messages must use the Requester ID field values
defined in the Set_Slot_Power_Limit Message Table 2-17 of the PCI
Express Base Specification 1.1.
TXN.02.17#13 2.2.8.1.5 Set_Slot_Power_Limit Messages can be supported as a transmitter, or
receiver, or both based on the values defined in the Set_Slot_Power_Limit
Message Table 2-17 of the PCI Express Base Specification 1.1.
TXN.02.17#01 2.2.8.1.5 Set_Slot_Power_Limit Messages must use the Code[7:0] and r[2:0] sub-
field values defined in the Set_Slot_Power_Limit Message Table 2-17 of the
PCI Express Base Specification 1.1.
TXN.02.17#06 2.2.8.1.5 The Set_Slot_Power_Limit Message data payload byte 0 (bits 7:0) map to
the Slot Power Limit Value field.
TXN.02.17#02 2.2.8.1.5 Set_Slot_Power_Limit Messages must use MsgD Type and have a data
payload of 1 DW.
TXN.02.18#11 2.2.8.1.6 Vendor_Defined Messages (if implemented) must use the Code[7:0] and
r[2:0] sub-field values defined in the Vendor_Defined Messages Table 2-18
of the PCI Express Base Specification 1.1.
TXN.02.18#17 2.2.8.1.6 Vendor_Defined Messages (if implemented), that are designed to be
interoperable with PCI-X Device ID Messages must meet the requirements
of PCI Express to PCI/PCI-X Bridge Specification 1.0. (This defines
restrictions on the contents of the Tag[7:0] field and the Length[9:0] field as
well as specific use of bytes 12 through 15 of the message header.)

14
 ENDPOINT COMPLIANCE CHECKLIST FOR THE PCI EXPRESS BASE 1.1 SPECIFICATION,
REVISION 1.1

ID Ref Assertion Y N
TXN.02.18#09 2.2.8.1.6 Receivers handle the receipt of an unsupported Vendor_Defined Type 0
Message as an Unsupported Request, and a UR error is reported (if
enabled).
TXN.02.18#08 2.2.8.1.6 Receivers silently discard Vendor_Defined Type 1 Messages which they are
not designed to receive.
TXN.02.18#16 2.2.8.1.6 Support for specific Vendor_Defined Messages is vendor specific and is not
guaranteed.
TXN.02.18#07 2.2.8.1.6 For Vendor_Defined Messages (if implemented), messages defined by
different vendors or by PCI SIG are distinguished by the value in the
Vendor ID field.
TXN.02.18#15 2.2.8.1.6 For both types of Vendor_Defined Messages (if implemented), the Attr[1:0]
field is not reserved.
TXN.02.18#06 2.2.8.1.6 Vendor_Defined Messages (if implemented) must use Msg type if a data
payload is NOT included.
TXN.02.18#05 2.2.8.1.6 Vendor_Defined Messages (if implemented) must use MsgD type if a data
payload is included.
TXN.02.18#12 2.2.8.1.6 Vendor_Defined Messages (if implemented) can be supported as a
transmitter, or receiver, or both based on the values defined in the
Vendor_Defined Messages Table 2-18 of the PCI Express Base
Specification 1.1.
TXN.02.18#10 2.2.8.1.6 For Vendor_Defined Messages (if implemented), bytes 12 to 15 are defined
by the vendor.
TXN.02.18#04 2.2.8.1.6 For Vendor_Defined Messages (if implemented), bytes 10 and 11 form a 16
bit field for the Vendor ID (defined by PCI-SIG) of the vendor defining the
message.
TXN.02.18#03 2.2.8.1.6 For Vendor_Defined Messages (if implemented), if ID routing is not used,
bytes 8 and 9 are Reserved.
TXN.02.18#02 2.2.8.1.6 For Vendor_Defined Messages (if implemented), if ID routing is used, than
bytes 8 and 9 of the TLP Header form a 16 bit field for the Destination ID.
TXN.02.18#01 2.2.8.1.6 Vendor_Defined Messages (if implemented) must use the TLP Header
format shown in Table 2-18 in the PCI Express Base Specification 1.1.
TXN.02.18#13 2.2.8.1.6 Vendor_Defined Messages (if implemented) must use the Requester ID
field values defined in the Vendor_Defined Messages Table 2-18 of the PCI
Express Base Specification 1.1.
TXN.02.19#07 2.2.8.1.7 The Physical and Data Link Layers must handle received Ignored Messages
identically to handling any other TLP.
TXN.02.19#08 2.2.8.1.7 The Transaction layer must account for flow control credit for received
Ignored Messages.
TXN.02.19#05 2.2.8.1.7 If a transmitter sends any of the Ignored Messages listed in the Ignored
Messages Table 2-19 of the PCI Express Base Specification 1.1, than it must
fully comply with the specific requirements for that message type as defined
in PCI Express Base Specification 1.0a.
TXN.02.19#04 2.2.8.1.7 Ignored Messages must follow the encoding in the Ignored Messages Table
2-19 of the PCI Express Base Specification 1.1
TXN.02.19#06 2.2.8.1.7 If a receiver processes any of the Ignored Messages listed in the Ignored
Messages Table 2-19 of the PCI Express Base Specification 1.1, than it must
fully comply with the specific requirements for that message type as defined
in PCI Express Base Specification 1.0a.
TXN.02.19#09 2.2.8.1.7 If the receiver does not process the received Ignored Message it must
discard it and take no other action.
TXN.02.21#10 2.2.9 The Byte Count[11:0] field value for Memory Read Completions must
accurately give the remaining bytes for the request, specified as a binary
number, with 0000 0000 0001b indicating 1 byte, 1111 1111 1111b
indicating 4095 bytes, and 0000 0000 0000b indicating 4096 bytes.

15
 ENDPOINT COMPLIANCE CHECKLIST FOR THE PCI EXPRESS BASE 1.1 SPECIFICATION,
REVISION 1.1

ID Ref Assertion Y N
TXN.02.21#25 2.2.9 The receiving device must check that the Completion data payload size
matches the size specified in the Length[9:0] field. If this check fails, than
the TLP is a Malformed TLP and is reported as an error (if enabled)
associated with the receiving port.
TXN.02.21#24 2.2.9 A Completion with a data payload must specify the actual amount of data
returned in that Completion, and must include the amount of data specified.
TXN.02.21#20 2.2.9 The requester must ignore the value returned in the Completer ID field until
the completing device has finished software initialization and configuration
using at least one Type 0 Configuration Write request.
TXN.02.21#19 2.2.9 Completion headers must supply exactly the same values for the Requester
ID[15:0], Tag[7:0], Attribute[1:0], and Traffic Class [2:0] fields as were
supplied in the header of the corresponding request.
TXN.02.21#18 2.2.9 If a Completion with the Unsupported Request status is generated by a
multi-function device without associating the Completion with a specific
function within the device, the Function Number field is Reserved.
TXN.02.21#16 2.2.9 If a function (other than a Root Complex logical device) must generate a
Completion prior to the initial device Type 0 Configuration Write Request is
completed, the Bus Number and Device Number fields of the Completer ID
must contain all 0.
TXN.02.21#15 2.2.9 Functions must capture the Bus and Device Numbers supplied with all Type
0 Configuration Write Requests completed by the function, and supply these
numbers in the Bus and Device Number fields of the Completer ID for all
Completions generated by the device/function. The Bus Number and
Device number must be updated with every Type 0 Configuration Write
Request that is completed by the function.
TXN.02.21#13 2.2.9 The Lower Address[6:0] field for non-Memory Read Completions must be
set to all 0.
TXN.02.21#12 2.2.9 The Lower Address[6:0] field for Memory Read Completions must
accurately give the byte address for the first enabled byte of data returned
with the Completion.
TXN.02.21#22 2.2.9 The Byte Count[11:0] field value for non-Memory Read Completions must
be 4.
TXN.02.21#08 2.2.9 BCM (Byte Count Modified) bit must not be set by PCI Express Completers
(only PCI-X completers can set the BCM bit).
TXN.02.21#06 2.2.9 Completion Status[2:0] field must be used to accurately indicate the status
for a Completion using the values in the Completion Status Field Values
Table 2-20) of the PCI Express Base Specification 1.1.
TXN.02.21#05 2.2.9 Completer ID[15:0] field must be encoded to identify the Completer.
TXN.02.21#04 2.2.9 Completions must adhere to the header format specified in Figure 2-19 of
the PCI Express Base Specification 1.1.
TXN.02.21#23 2.2.9 All Completion TLPs include the following fields in addition to the header
fields included in all TLPs and ID routing fields: Completer ID[15:0],
Completion Status[2:0], BCM, Byte Count[11:0], Tag[7:0], Lower
Address[6:0].
TXN.02.21#03 2.2.9 The routing ID fields correspond directly to the Requester ID supplied with
the corresponding request.
TXN.02.21#02 2.2.9 Completions route by ID, and use a 3 DW Header.
TXN.02.21#01 2.2.9 Completions must be sent in response to all Read requests and all Non-
Posted Write requests.
TXN.02.21#11 2.2.9 For a Completion, the Tag[7:0] field in combination with the Requester ID
field, must correspond to the Transaction ID.
TXN.03.00#03 2.3 All Received TLPs which fail the required Malformed TLP checks (and
which fail any implemented optional checks for Malformed TLP) must be
discarded.

16
 ENDPOINT COMPLIANCE CHECKLIST FOR THE PCI EXPRESS BASE 1.1 SPECIFICATION,
REVISION 1.1

ID Ref Assertion Y N
TXN.03.00#01 2.3 Values in Reserved fields must be ignored by the Receiver.
TXN.03.03#08 2.3 All Received TLPs which fail the required Malformed TLP checks (and
which fail any implemented optional checks for Malformed TLP), and are
ambiguous with respect to which buffer to release or are mapped to an
uninitialized VC, must not update the receiver's Flow Control information.
TXN.03.00#10 2.3 The receiving device must check that the TLP uses a defined Type field
value. If this check fails, than the TLP is a Malformed TLP and is reported
as an error (if enabled) associated with the receiving port.
TXN.03.00#02 2.3 Receiver Flow Control tracking information must be updated for all valid
TLPs (not Malformed) that are received.
TXN.03.00#11 2.3 The receiving device must process all Request TLPs (based on TLP Type
field) in accordance to the Flowchart for Handling of Received TLPs Figure
2-21 in the PCI Express Base Specification 1.1.
TXN.03.01#22 2.3.1 A receiving device must not generate a Completion with Completion Status
of Configuration Request Retry Status in response to a Configuration
Request received after is has already generated a Completion with
Completion Status of Successful Completion in response to a previous
Configuration Request, and there has been no intervening reset of any of:
cold reset; warm reset; Hot Link reset; D3-hot to D0-unitialized transition
reset.
TXN.03.01#11 2.3.1 A receiving device must only generate a Completion with Completion
Status of Configuration Request Retry Status in response to a Configuration
Request received while the device is temporarily unable to process the
Request following the device being reset by any of: cold reset; warm reset;
Hot Link reset; D3-hot to D0-unitialized transition reset.
TXN.03.01#08 2.3.1 A Completer of a normally supported request, which is permanently unable
to process that Request due to a device-specific error condition, must handle
the Request as a Completer Abort if functionally able to do so.
TXN.03.01#21 2.3.1 A receiving device that is designed to support Legacy software must support
all types of Requests which are possible in the existing usage model for the
device.
TXN.03.01#06 2.3.1 A receiving device must return a Completion TLP with a Completion Status
of Completer Abort for all Request TLPs treated as Completer Abort
(targeting the device) that require a Completion.
TXN.03.01#05 2.3.1 A receiver that determines a Request TLP is treated as a Completer Abort
must report this as an error (if enabled to report these errors) associated with
the receiving device/function (if it can isolate the error to a device/function),
or associated with the receiving port (if it cannot isolate the error to a
device/function).
TXN.03.01#20 2.3.1 A receiving device must treat a Message Request TLP which specifies a
value that corresponds to a Message supported by the device (excluding
Vendor_Defined Type 1 Messages) normally and process it. A valid
Message Code that is an ignored Message, must be ignored without
generating any error.
TXN.03.01#03 2.3.1 A receiving device must treat a Message Request TLP which specifies a
value that is undefined, or that corresponds to a Message not supported by
the device (excluding Vendor_Defined Type 1 Messages), as an
Unsupported Request.
TXN.03.01#01 2.3.1 If a receiver determines a Request TLP is not supported (either it not
supported at any time by design, or it is currently not supported due to
configuration settings) it must treat the request as an Unsupported Request.
TXN.03.01#02 2.3.1 A receiving device must return a Completion TLP with a Completion Status
of Unsupported Request for all Unsupported Request TLPs (targeting the
device) that require a Completion.

17
 ENDPOINT COMPLIANCE CHECKLIST FOR THE PCI EXPRESS BASE 1.1 SPECIFICATION,
REVISION 1.1

ID Ref Assertion Y N
TXN.03.01#19 2.3.1 A receiver that determines a Request TLP is an Unsupported Request must
report this as an error associated with the receiving port (depending on the
settings of the device in handling unsupported requests).
TXN.03.01#18 2.3.1 The receiving device must process all Request TLPs (following the initial
processing done with all TLPs) in accordance to the Flowchart for Handling
of Received Request Figure 2-23 in the PCI Express Base Specification 1.1.
TXN.03.01#04 2.3.1 If a receiving device may only treat a Request as a Completer Abort (instead
of handling the Request normally) if it determines that the Request violates
the programming model of the device.
TXN.03.01#25 2.3.1 PCI Express Endpoints and Legacy Endpoints must never delay the
acceptance of a Posted Request for more than 10 usec (the Posted Request
Acceptance Limit), except under the following abnormal operating
conditions: the device is in the period following Fundamental reset; TLPs
are being re-transmitted; the device's link is retraining; one or more dropped
Flow Control DLLPs; the device is in a diagnostic mode of operation; the
device is in a mode of operation not intended for normal use. The following
delays are not counted against the Posted Request Acceptance Limit:
Upstream TLP traffic delaying upstream Flow Control DLLPs; the link
returning from a low power link state; arbitration with traffic on other VCs.
If the device cannot meet this, then it must implement a restricted
programming model that ensures such a situation cannot arise.
TXN.03.02#35 2.3.1.1 When a Read Completion is generated with a Completion Status other than
Successful Completion, the Lower Address field must indicate the lower
bits of the byte address for the first enabled byte of data that would have
been returned with the Completion (as if the Completion Status were
Successful Completion).
TXN.03.02#18 2.3.1.1 Multiple Memory Read Completions for a single Read request must return
data in increasing address order.
TXN.03.02#19 2.3.1.1 For each Memory Read Completion, the Byte Count field must indicate the
remaining number of bytes required to complete the Request including the
number of bytes returned with the Completion, except when the BCM field
is 1b.
TXN.03.02#21 2.3.1.1 The total byte count required to complete a Memory Read Request must be
calculated as shown in the Calculating Byte Count from Length and Byte
Enables Table 2-21 in the PCI Express Base Specification 1.1.
TXN.03.02#23 2.3.1.1 If a Memory Read Request is completed using multiple Completions, the
Byte Count value for each successive Completion is the value indicated by
the preceding Completion minus the number of bytes returned with the
preceding Completion.
TXN.03.02#25 2.3.1.1 A PCI Express Memory Read requester must recognize that if the BCM bit
is set to 1 in the first Read Completion it means that a PCI-X Bridge/PCI-X
Completer is indicating that the Byte Count field reports the size of just that
first transaction and the requester must not conclude that packets of a Read
Completion are missing. (Subsequent Read completions will have BCM
clear and contain the correct Byte Count.)
TXN.03.02#27 2.3.1.1 For all Memory Read Completions, the Lower Address field must indicate
the lower bits of the byte address for the first enabled byte of data returned
with the Completion.
TXN.03.02#42 2.3.1.1 For the first (or only) Completion, the Lower Address field is generated
from the least significant five bits of the address of the Request,
concatenated with the two bits of byte-level address taken from the
Calculating Lower Address from 1st_DW_BE Table 2-22 in the PCI
Express Base Specification 1.1.

18
 ENDPOINT COMPLIANCE CHECKLIST FOR THE PCI EXPRESS BASE 1.1 SPECIFICATION,
REVISION 1.1

ID Ref Assertion Y N
TXN.03.02#28 2.3.1.1 For any Completions after the first, the Lower Address field must be zero
(except for Completions generated by the Root Complex with an RCB value
of 64 bytes).
TXN.03.02#32 2.3.1.1 When a Read Completion is generated with a Completion Status other than
Successful Completion no data is included with the Completion and the Cpl
(or CplLk if the request is MemRdLk) encoding must be used.
TXN.03.02#34 2.3.1.1 When a Read Completion is generated with a Completion Status other than
Successful Completion, the Byte Count field must indicate the remaining
number of bytes that would be required to complete the Request (as if the
Completion Status were Successful Completion).
TXN.03.02#36 2.3.1.1 The boundaries specified by RCB must be respected for all reads which the
device will Complete with Successful Completion status.
TXN.03.02#17 2.3.1.1 The receiving device may optionally check if, for Read requests crossing
address boundaries at integer multiples of RCB bytes, all Completions
between, but not including, the first and final Completions are an integer
multiple of RCB bytes in length. If this optional check is implemented and
fails, than the TLP is a Malformed TLP and is reported as an error (if
enabled) associated with the receiving port.
TXN.03.02#11 2.3.1.1 For all devices (except for Root Complexes), Read Completion Boundary is
128 bytes.
TXN.03.02#33 2.3.1.1 When a Read Completion is generated with a Completion Status other than
Successful Completion, the Completer must not transmit any additional
Completions for this Request.
TXN.03.02#07 2.3.1.1 Completions must not include more data than permitted by the
Max_Payload_Size parameter.
TXN.03.02#01 2.3.1.1 All Completions for a given Read Request, when combined, must return
exactly the amount of data Requested in the Read Request.
TXN.03.02#02 2.3.1.1 Completions for different Requests cannot be combined.
TXN.03.02#03 2.3.1.1 I/O Reads and Configuration Reads must be completed with exactly one
Completion.
TXN.03.02#04 2.3.1.1 The Completion Status for a Completion corresponds only to the status
associated with the data returned with that Completion.
TXN.03.02#38 2.3.1.1 The receiving device may optionally check if Completions for Read
Requests which do not cross the naturally aligned address boundaries at
integer multiples of RCB Bytes includes all data specified in the Request. If
this optional check is implemented and fails, than the TLP is a Malformed
TLP and is reported as an error (if enabled) associated with the receiving
port.
TXN.03.02#06 2.3.1.1 For a Completion with status other than Successful Completion, the value in
the Length field is undefined, and must be ignored by the Receiver.
TXN.03.02#16 2.3.1.1 For Read requests crossing address boundaries at integer multiples of RCB
bytes, all Completions between, but not including, the first and final
Completions must be an integer multiple of RCB bytes in length.
TXN.03.02#37 2.3.1.1 Receivers must check that Completions must not include more data than
permitted by the Max_Payload_Size parameter. If this check fails, than the
TLP is a Malformed TLP and is reported as an error (if enabled) associated
with the receiving port.
TXN.03.02#12 2.3.1.1 Completions for Read Requests which do not cross the naturally aligned
address boundaries at integer multiples of RCB Bytes must include all data
specified in the Request.

19
 ENDPOINT COMPLIANCE CHECKLIST FOR THE PCI EXPRESS BASE 1.1 SPECIFICATION,
REVISION 1.1

ID Ref Assertion Y N
TXN.03.02#14 2.3.1.1 For Read requests crossing address boundaries at integer multiples of RCB
bytes, the first Completion must start with the address specified in the
Request, and must end at one of the following: the address specified in the
Request plus the length specified by the Request; an address between the
start and end of the Request at an integer multiple of RCB bytes.
TXN.03.02#39 2.3.1.1 The receiving device may optionally check if, for Read requests crossing
address boundaries at integer multiples of RCB bytes, the first Completion
starts with the address specified in the Request, and ends at one of the
following: the address specified in the Request plus the length specified by
the Request; an address between the start and end of the Request at an
integer multiple of RCB bytes. If this optional check is implemented and
fails, than the TLP is a Malformed TLP and is reported as an error (if
enabled) associated with the receiving port.
TXN.03.02#15 2.3.1.1 For Read requests crossing address boundaries at integer multiples of RCB
bytes, the final Completion must end with the address specified in the
Request plus the length specified by the Request.
TXN.03.02#40 2.3.1.1 The receiving device may optionally check if, for Read requests crossing
address boundaries at integer multiples of RCB bytes, the final Completion
ends with the address specified in the Request plus the length specified by
the Request. If this optional check is implemented and fails, than the TLP is
a Malformed TLP and is reported as an error (if enabled) associated with the
receiving port.
TXN.03.02#05 2.3.1.1 A Completion with status other than Successful Completion terminates the
Completions for a single Read Request.
TXN.03.03#12 2.3.2 Completions with a Completion Status other than Successful Completion, or
Configuration Request Retry Status (in response to Configuration Request
only) must cause the requester to handle the error via a Requester-specific
mechanism (it must not use PCI Express specific error logging or
messages).
TXN.03.03#10 2.3.2 Completions with a Completions Status of Unsupported Request or
Completer Abort are reported using the conventional PCI reporting
mechanisms via the Status register.
TXN.03.03#19 2.3.2 When a Read Completion is received with a Completion Status other than
Successful Completion, the receiver must free all internal resources which
had been allocated for that specific Read request.
TXN.03.03#18 2.3.2 When a Read Completion is received with a Completion Status other than
Successful Completion, the receiver must consider the request terminated
and must not expect additional Completions for the request.
TXN.03.03#17 2.3.2 When a Read Completion is received with a Completion Status other than
Successful Completion, the receiver must not expect any data to be included
with the Completion which will be Cpl (or CplLk if the request was
MemRdLk).
TXN.03.03#05 2.3.2 The receiving device may optionally check if, Completions with a
Configuration Request Retry Status are only received in response to a
Configuration Request. If this optional check is implemented and fails, than
the TLP is a Malformed TLP and is reported as an error (if enabled)
associated with the receiving port.
TXN.03.03#01 2.3.2 An Agent receiving a Completion that does not correspond to any of the
outstanding Requests issued by the device must discard the Unexpected
Completion.
TXN.03.03#03 2.3.2 Completions with a Completion Status other than Successful Completion, or
Configuration Request Retry Status (in response to Configuration Request
only) must cause the requester to free Completion buffer space and other
resources associated with the Request.

20
 ENDPOINT COMPLIANCE CHECKLIST FOR THE PCI EXPRESS BASE 1.1 SPECIFICATION,
REVISION 1.1

ID Ref Assertion Y N
TXN.03.03#02 2.3.2 Receivers must check that Completions correspond to an outstanding
Request issued by the device. If this check fails, than the Completion is an
Unexpected Completion and is reported as an error (if enabled) associated
with the receiving port.
TXN.03.03#06 2.3.2 Completions with a Reserved Completion Status value are treated as if the
Completion Status was Unsupported Request (UR).
TXN.04.00#12 2.4.1 Read Completions for one Request (with the same Transaction ID) must
return in address order.
TXN.04.00#34 2.4.1 Acceptance of a Completion must not depend upon the transmission of a
posted or non-posted Request or a Completion in the same Traffic Class.
TXN.04.00#33 2.4.1 Completions issued for non-posted Requests must be returned in the same
Traffic Class as the corresponding non-posted Request.
TXN.04.00#32 2.4.1 Acceptance of a posted Request must not depend upon the transmission of a
Completion in the same Traffic Class.
TXN.04.00#31 2.4.1 For Endpoints and Bridges, acceptance of a posted or non-posted Request
must not depend upon the transmission of a posted or non-posted Request in
the same Traffic Class.
TXN.04.00#22 2.4.1 Combining of Memory Read Requests, and/or Completions for different
Requests must not be done.
TXN.04.00#10 2.4.1 Completions must be allowed to pass any Read Requests, I/O Write
Requests, or Configuration Write Requests to avoid deadlocks if the first
request is blocked.
TXN.04.00#07 2.4.1 Any Read Completion with the Relaxed Ordering attribute is set to 0 must
not pass a previously enqueued Memory Write or Message Request.
TXN.04.00#06 2.4.1 Any Read Requests, I/O Write Requests, and Configuration Write Requests
must not pass a previously enqueued Memory Write or Message Request.
TXN.04.00#03 2.4.1 A Memory Write or Message Request must be allowed to pass any Read
Requests, I/O Write Requests, or Configuration Write Requests to avoid
deadlocks when the first request is blocked.
TXN.04.00#02 2.4.1 A Memory Write or Message Request, with the Relaxed Ordering Attribute
bit is set to 0, must not pass an already enqueued Memory Write or Message
Request.
TXN.04.00#24 2.4.1 All Transactions types within a single Traffic Class, must follow the
Ordering Rules Summary Table 2-23 of the PCI Express Base Specification
Table.
TXN.04.00#23 2.4.1 The No Snoop bit must not affect the required transaction ordering behavior.
TXN.04.02#01 2.4.3 If a single write transaction containing multiple DWORDs and the Relaxed
Ordering bit is 0, is accepted by a Completer, the observed ordering of the
updates to locations within the Completer's data buffer must be in increasing
address order.
TXN.05.00#02 2.5 Requesters that do not implement the optional PCI Express Virtual Channel
Capability Structure must only generate requests with TC0 label.
TXN.05.00#08 2.5 The receiving device may optionally check if requests have the TC0[2:0]
field equal to 000b. If this optional check is implemented and fails, than the
TLP is a Malformed TLP and is reported as an error (if enabled) associated
with the receiving port.
TXN.05.00#03 2.5 Completers that do not implement the optional PCI Express Virtual Channel
Capability Structure must accept requests with a TC label other than TC0.
TXN.05.00#04 2.5 Completers, (including those that do not implement the optional PCI
Express Virtual Channel Capability Structure), must generate Completions
with the same TC label as the label of the corresponding Request.
TXN.05.00#07 2.5 For a requester to be permitted to issue requests with a TC label other than
TC0, the requester must implement the PCI Express Virtual Channel
Capability structure.

21
 ENDPOINT COMPLIANCE CHECKLIST FOR THE PCI EXPRESS BASE 1.1 SPECIFICATION,
REVISION 1.1

ID Ref Assertion Y N
TXN.05.01#01 2.5.1 All PCI Express Ports that support more than VC0 must provide at least one
VC Capability Structure.
TXN.05.01#04 2.5.1 VC ID 0 is assigned and fixed to the default VC.
TXN.05.01#07 2.5.1 If a multi-function device implements a MFVC Capability structure, its
MFVC associated VC hardware resources must be distinct from the VC
hardware resources associated with any VC Capability structures of its
functions.
TXN.05.02#01 2.5.2 Every Traffic Class that is supported must be mapped to one of the Virtual
Channels.
TXN.05.03#01 2.5.3 All PCI Express devices must support TC0 and must implement the default
VC0.
TXN.05.03#11 2.5.3 Each implemented VC must have independent Flow Control.
TXN.05.03#14 2.5.3 A multi-function device’s peer-to-peer capability between different
functions applies to all Virtual Channels supported by the multi-function
device.
TXN.05.03#06 2.5.3 Transactions with a TC that is not mapped to any enabled VC in a PCI
Express Ingress Port are treated as malformed transactions by the receiving
device.
TXN.05.03#15 2.5.3 For multi-function devices with a MFVC Capability structure, transactions
with a TC that is not mapped to an enabled VC in the MFVC Capability
structure are treated as malformed TLPs.
TXN.06.00#01 2.6 Each Virtual Channel maintains an independent Flow Control credit pool.
TXN.06.00#04 2.6 The VC ID field of the DLLP is used to carry the Virtual Channel
Identification required for proper flow-control credit accounting.
TXN.06.00#03 2.6 LCRC, Packet Framing Symbols, other Special Symbols, and Data Link
Layer to Data Link Layer inter-communication packets are not associated
with Flow Control Credits and so must be processed by the receiver at the
rate they arrive (except as explicitly noted in the PCI Express Base
Specification 1.1).
TXN.06.01#33 2.6.1 The device receiving Flow Control packets may optionally check if, an
Infinite Credit advertisement (value of 00h or 000h) has been made during
initialization, and Flow Control updates are transmitted for that type, the
credit values must be set to 0. If this optional check is implemented and
fails, than the violation is a Flow Control Protocol Error and is reported as
an error (if enabled) associated with the receiving port.
TXN.06.01#34 2.6.1 Transmitters must not send TLPs using any VC 0-7 until initialization for
that VC has completed by exiting FC_INIT2 state.
TXN.06.01#30 2.6.1 The device receiving Flow Control packets may optionally check if, a
Receiver has ever cumulatively issued more than 2047 outstanding unused
credits to the Transmitter for data payload or 127 outstanding unused credits
for header. If this optional check is implemented and fails, than the
violation is a Flow Control Protocol Error and is reported as an error (if
enabled) associated with the receiving port.
TXN.06.01#29 2.6.1 A Receiver must never cumulatively issue more than 2047 outstanding
unused credits to the Transmitter for Data payload or 127 outstanding
unused credits for Header.
TXN.06.01#18 2.6.1 If an Infinite Credit advertisement (value of 00h or 000h) has been made
during initialization, no Flow Control updates for that type are required
following initialization.
TXN.06.01#31 2.6.1 If an Infinite Credit advertisement (value of 00h or 000h) has been made
during initialization, and Flow Control updates are transmitted for that type,
the credit values must be set to 0.

22
 ENDPOINT COMPLIANCE CHECKLIST FOR THE PCI EXPRESS BASE 1.1 SPECIFICATION,
REVISION 1.1

ID Ref Assertion Y N
TXN.06.01#32 2.6.1 If an Infinite Credit advertisement (value of 00h or 000h) has been made
during initialization, any Flow Control updates transmitted for that type with
credit values of 0 must be ignored by the Receiver.
TXN.06.01#05 2.6.1 There are six types of information which must be tracked by Flow Control
for each Virtual Channel, as shown Flow Control Credit Types, Table 2-25
in the PCI Express Base Specification 1.1.
TXN.06.01#19 2.6.1 If only the Data or Header advertisement (but not both) for a given type (N,
NP, or CPL) has been made with infinite credits during initialization, then
UpdateFC DLLPs for that type must be transmitted.
TXN.06.01#20 2.6.1 If only the Data or Header advertisement (but not both) for a given type (N,
NP, or CPL) has been made with infinite credits during initialization, then
the credit field corresponding to the Data or Header (which ever was
advertised as infinite) must be set to zero in the UpdateFC DLLPs for that
type.
TXN.06.01#22 2.6.1 If only the Data or Header advertisement (but not both) for a given type (N,
NP, or CPL) has been made with infinite credits during initialization, then
any credit field corresponding to the Data or Header (which ever was
advertised as infinite) that are zero must be ignored by the Receiver in the
UpdateFC DLLPs for that type.
TXN.06.01#24 2.6.1 Receivers must check that all received TLPs use only VCs that are enabled.
If this check fails, than the TLP is Malformed and is reported as an error (if
enabled) associated with the receiving port. (VC0 is always enabled. VCs
1-7 are considered enabled when the corresponding VC Enable bit in the VC
Resource Control Register has been set to 1, and once FC negotiation for
that VC has exited the FC_INIT1 state and progressed to the FC_INIT2
state.)
TXN.06.01#17 2.6.1 The device receiving InitFC Flow Control packets may optionally check if,
during FC initialization for any Virtual Channel, including the default VC
initialized as a part of Link initialization, Receivers must initially advertise
VC credit values equal to or greater than those shown in the Minimum
Initial Flow Control Advertisements Table 2-27, in the PCI Express Base
Specification 1.1. If this optional check is implemented and fails, than the
violation is a Flow Control Protocol Error and is reported as an error (if
enabled) associated with the receiving port.
TXN.06.01#23 2.6.1 The device receiving Flow Control packets may optionally check if, when
only the Data or Header advertisement (but not both) for a given type (N,
NP, or CPL) has been made with infinite credits during initialization, then
the credit field corresponding to the Data or Header (which ever was
advertised as infinite) must be set to zero in the UpdateFC DLLPs for that
type. If this optional check is implemented and fails, than the violation is a
Flow Control Protocol Error and is reported as an error (if enabled)
associated with the receiving port.
TXN.06.01#04 2.6.1 Each Virtual Channel has independent Flow Control.
TXN.06.01#07 2.6.1 Components must implement independent Flow Control for all Virtual
Channels that are supported by that component.
TXN.06.01#01 2.6.1 Flow Control information is transferred using Flow Control Packets (FCPs)
which are a type of DLLP.
TXN.06.01#03 2.6.1 For headers, the unit of Flow Control credit is one maximum-size header
plus TLP digest.
TXN.06.01#16 2.6.1 During FC initialization for any Virtual Channel, including the default VC
initialized as a part of Link initialization, Receivers must initially advertise
VC credit values equal to or greater than those shown in the Minimum
Initial Flow Control Advertisements Table 2-27, in the PCI Express Base
Specification 1.1.

23
 ENDPOINT COMPLIANCE CHECKLIST FOR THE PCI EXPRESS BASE 1.1 SPECIFICATION,
REVISION 1.1

ID Ref Assertion Y N
TXN.06.01#06 2.6.1 TLPs consume Flow Control credits as shown in TLP Flow Control Credit
Consumption Table 2-26 in the PCI Express Base Specification 1.1.
TXN.06.01#08 2.6.1 Flow Control is initialized autonomously by hardware only for the default
Virtual Channel (VC0).
TXN.06.01#09 2.6.1 VC0 is initialized when the Data Link Layer is in the DL_Init state
following reset.
TXN.06.01#10 2.6.1 When other Virtual Channels are enabled by software, each newly enabled
VC will follow the Flow Control initialization protocol.
TXN.06.01#13 2.6.1 Disabling a Virtual Channel for a component resets the Flow Control
tracking mechanisms for that Virtual Channel in that component.
TXN.06.01#14 2.6.1 InitFC1 and InitFC2 Flow Control packets are used only for Flow Control
initialization.
TXN.06.01#15 2.6.1 An InitFC1, InitFC2, or UpdateFC Flow Control packet that specifies a
Virtual Channel that is disabled is discarded without effect.
TXN.06.01#02 2.6.1 For data the unit of Flow Control credit is 4 DW.
TXN.06.02#04 2.6.1.1 Transmitters must treat CREDIT_LIMIT as undefined at interface
initialization.
TXN.06.02#08 2.6.1.1 If the Transmitter does not have enough credits to transmit a TLP, it must
block the transmission of that TLP.
TXN.06.02#14 2.6.1.1 When a Transmitter sends a nullified TLP (with inverted LCRC and using
EDB as the end Symbol), the Transmitter does not modify
CREDITS_CONSUMED for that TLP.
TXN.06.02#13 2.6.1.1 Flow Control credit return is used for receive buffer management only, and
Agents must not make any judgment about the Completion status or system
visibility of a Transaction based on the return or lack of return of Flow
Control information.
TXN.06.02#11 2.6.1.1 Transmitters, when accounting for credit use and return, must ensure that
information from different TLPs is never mixed within one credit.
TXN.06.02#10 2.6.1.1 The Transmitter must block TLP transmission (for each credit type) if the
following calculation (using unsigned arithmetic) is false: (CREDIT_LIMIT
- ( (CREDITS_CONSUMED+
credit_units_required_for_pending_TLP)mod 2**Field_Size )mod
2**Field_Size <= (2**Field_Size) / 2 (where Field_Size is 8 for header and
12 for data).
TXN.06.02#17 2.6.1.1 The Transmitter must not gate TLP transmission (for a credit type) if
CREDIT_LIMIT (for that type) was specified as infinite during Flow
Control initialization..
TXN.06.02#12 2.6.1.1 The Transmitter, while blocking one TLP transmission type due to lack of
FC credits, must not block other TLP transmission types, if that other TLP
type has sufficient FC credits and if ordering and deadlock avoidance rules
specified in PCI Express Base Specification 1.1 are met.
TXN.06.02#05 2.6.1.1 Transmitters must set CREDIT_LIMIT to the value indicated by the
Receiver at Flow Control Initialization.
TXN.06.02#06 2.6.1.1 Transmitters must count CREDITS_LIMIT which is the most recent number
of FC units legally advertised by the Receiver. This value is the total
number of FC credits made available by the Receiver since Flow Control
initialization modulo 2**8 (for headers) and modulo 2**12 (for data).
TXN.06.02#02 2.6.1.1 Transmitters must update CREDITS_CONSUMED for each TLP the
Transaction Layer allows to pass the Flow Control gate for transmission.
The update follows the equation:
CREDITS_CONSUMED:=(CREDITS_CONSUMED + increment) mod
2**Field_Size (where increment is the size of the FC credit and Field_Size
is 8 for header and 12 for data).

24
 ENDPOINT COMPLIANCE CHECKLIST FOR THE PCI EXPRESS BASE 1.1 SPECIFICATION,
REVISION 1.1

ID Ref Assertion Y N
TXN.06.02#01 2.6.1.1 Transmitters must set CREDITS_CONSUMED to 0 when the interface is
initialized.
TXN.06.02#16 2.6.1.1 Transmitters must count CREDITS_CONSUMED which is the total number
of FC units consumed by TLP Transmissions made since Flow Control
initialization modulo 2**8 (for headers) and modulo 2**12 (for data).
TXN.06.02#07 2.6.1.1 For each FC update received, if CREDIT_LIMIT is not equal to the update
value, set CREDIT_LIMIT to update value.
TXN.06.02#15 2.6.1.1 Transmitters must track the following quantities for Flow Control TLP
Transmission gating (for each type of credit information):
CREDITS_CONSUMED; CREDIT_LIMIT.
TXN.06.03#20 2.6.1.2 A Receiver that implements the optional UpdateFC received timer, must
initiate a Physical Layer link recovery when the timer expires.
TXN.06.03#08 2.6.1.2 If a Receiver implements the optional receiver overflow error check and
detects an overflow condition, the Receiver must de-allocate any resources
which it had allocated for the TLP(s).
TXN.06.03#10 2.6.1.2 For non-infinite NPH, NPD, PH, and CPLH types, an UpdateFC Flow
Control packet must be scheduled for transmission each time the following
sequence of events occurs: all advertised FC units for a particular type of
credit are consumed by TLPs received, than one or more units of that credit
type are made available by processing TLPs.
TXN.06.03#21 2.6.1.2 A Receiver that implements the optional UpdateFC received timer, must
disable the timeout mechanism if an infinite credit advertisement has been
made during initialization for all three flow control classes.
TXN.06.03#12 2.6.1.2 If the Extended Sync bit of the Link Control register is 0, than when the
Link is in the L0 or L0s Link state, UpdateFC Flow Control packets for each
enabled type of non-infinite FC credit must be scheduled for transmission at
least once every 30 usec (-0%/+50%).
TXN.06.03#17 2.6.1.2 A Receiver that implements the optional UpdateFC received timer, must
only activate the timer when the link is in the L0 or L0s link state.
TXN.06.03#19 2.6.1.2 A Receiver that implements the optional UpdateFC received timer, must
reset the time upon the receipt of any InitFC or UpdateFC Flow Control
packet, or by the receipt of any DLLP.
TXN.06.03#07 2.6.1.2 If a Receiver implements the optional Receiver Overflow error check and
detects an overflow condition, the Receiver must discard the TLP(s) without
modifying the CREDITS_RECEIVED.
TXN.06.03#11 2.6.1.2 For non-infinite PD and CPLD types, when the number of available credits
is less than Max_Payload_Size, an UpdateFC Flow Control packet must be
scheduled for Transmission each time one or more units of that type are
made available by processing TLPs. (For a multi-function device whose
Max_Payload_Size settings are identical across all functions, the common
Max_Payload_Size setting or larger must be used. For a multi-function
device whose Max_Payload_Size settings are not identical across all
functions, the selected Max_Payload_Size setting is implementation
specific.)
TXN.06.03#18 2.6.1.2 A Receiver that implements the optional UpdateFC received timer, must set
the time limit to 200 usec (-0%/+50%).
TXN.06.03#01 2.6.1.2 Receivers must ensure that CREDITS_ALLOCATED is initially set
according to the buffer size and allocation policies of the Receiver. This
value is included in the InitFC and UpdateFC DLLPs.
TXN.06.03#16 2.6.1.2 If the Extended Sync bit of the Link Control register is 1, than when the
Link is in the L0 or L0s Link state, UpdateFC Flow Control packets for each
enabled type of non-infinite FC credit must be scheduled for transmission at
least once every 120 usec (-0%/+50%).

25
 ENDPOINT COMPLIANCE CHECKLIST FOR THE PCI EXPRESS BASE 1.1 SPECIFICATION,
REVISION 1.1

ID Ref Assertion Y N
TXN.06.03#09 2.6.1.2 Receivers may optionally check if, a received valid TLP does not satisfy the
equation: (CREDITS_ALLOCATED-CREDITS_RECEIVED)mod
2**Field_Size >= (2**Field_Size) / 2 (where Field_Size is 8 for header and
12 for data). If this optional check is implemented and fails, than a Receiver
Overflow is reported as an error (if enabled) associated with the receiving
port.
TXN.06.03#14 2.6.1.2 Receivers must count CREDITS_ALLOCATED which is the total number
of credits granted to the Transmitter since Flow Control initialization
modulo 2**8 (for headers) and modulo 2**12 (for data).
TXN.06.03#02 2.6.1.2 Receivers must ensure that CREDITS_ALLOCATED is incremented as the
Receiver Transaction Layer makes additional receive buffer space available
as follows: CREDITS_ALLOCATED := (CREDITS_ALLOCATED +
increment) mod 2**Field_Size (where increment is the credits made
available and Field_Size is 8 for header and 12 for data).
TXN.06.03#15 2.6.1.2 Receivers wishing to check for the optional Receiver Overflow error, must
also track the following quantities for Flow Control TLP Receiver
accounting (for each type of credit information): CREDITS_RECEIVED.
TXN.06.03#04 2.6.1.2 Receivers (that implement the optional Receiver Overflow check) must
count CREDITS_RECEIVED which is the total number of FC units
consumed by valid TLPs received since Flow Control initialization modulo
2**8 (for headers) and modulo 2**12 (for data).
TXN.06.03#03 2.6.1.2 Receivers (that implement the optional Receiver Overflow check) must set
CREDITS_RECEIVED to 0 at interface initialization.
TXN.06.03#05 2.6.1.2 Receivers (that implement the optional Receiver Overflow check) must
update CREDITS_RECEIVED, for each received TLP that passes DLLP
integrity check, is not malformed, and does not consume more credits than
have been allocated. The update is as follows: CREDITS_RECEIVED :=
(CREDITS_ RECEIVED + increment)mod 2**Field_Size (where
increment corresponds to the credits made available and Field_Size is 8 for
header and 12 for data).
TXN.06.03#06 2.6.1.2 If a Receiver implements the CREDITS_RECEIVED counter, then when a
nullified TLP (with inverted LCRC and using EDB as the end Symbol) is
received, the Receiver does not modify CREDITS_RECEIVED for that
TLP.
TXN.06.03#13 2.6.1.2 Receivers must track the following quantities for Flow Control TLP
Receiver accounting (for each type of credit information):
CREDITS_ALLOCATED.
TXN.07.01#01 2.7.1 If a device is enabled to generate ECRC, it must calculate and apply ECRC
for all TLPs originated by the device.
TXN.07.01#07 2.7.1 The ECRC seed value (initial value for ECRC storage registers) is FFFF
FFFFh.
TXN.07.01#15 2.7.1 For TLPs including a TLP Digest field used for an ECRC value, Receivers
which support end-to-end data integrity checking, check the ECRC value in
the TLP Digest field by applying the same algorithm used for ECRC
calculation (Section 2.7.1 of the PCI Express Base Specification 1.1) to the
received TLP, not including the 32-bit TLP Digest field of the received TLP
and compares the calculated result with the value in the TLP Digest field of
the received TLP.
TXN.07.01#10 2.7.1 The result of the ECRC calculation is complemented, and the complemented
result bits are mapped into the 32 bit TLP Digest field as shown in Mapping
of Bits into ECRC Field Table 2-29 of the PCI Express Base Specification
1.1.
TXN.07.01#09 2.7.1 ECRC calculation starts with bit 0 of byte 0 and proceeds from bit 0 to bit 7
of each byte of the TLP.

26
 ENDPOINT COMPLIANCE CHECKLIST FOR THE PCI EXPRESS BASE 1.1 SPECIFICATION,
REVISION 1.1

ID Ref Assertion Y N
TXN.07.01#08 2.7.1 All invariant fields of the TLP header and the entire data payload (if
present) are included in the ECRC calculation, all bits in variant fields (Bit 0
of the Type field and also the EP field) must be assumed to be 1 for ECRC
calculations.
TXN.07.01#14 2.7.1 The ECRC polynomial used has coefficients expressed as 04C1 1DB7h.
TXN.07.01#06 2.7.1 A 32 bit ECRC is calculated for the entire TLP (header and data payload)
using the algorithm specified in Section 2.7.1 of the PCI Express Base
Specification 1.1 and the ECRC is appended to the end of the TLP.
TXN.07.01#13 2.7.1 If a device is enabled to check ECRC, it must process normally all TLPs
received by the device which do not include the ECRC.
TXN.07.01#03 2.7.1 If a device reports the capability to check ECRC, it must support Advanced
Error Reporting.
TXN.07.01#16 2.7.1 Receivers which support end-to-end data integrity checks report violations
as an ECRC Error. This reported error is associated with the receiving port.
TXN.07.01#04 2.7.1 If a device is enabled to check ECRC, it must check the ECRC all TLPs
received by the device which include the ECRC.
TXN.07.02#04 2.7.2.1 Poisoned TLPs will be retried only if there are transmission errors on PCI
Express as determined by the TLP error detection mechanisms in the Data
Link Layer.
TXN.07.02#03 2.7.2.1 Error Forwarding must not cause Link Layer Retry.
TXN.07.02#01 2.7.2.1 Error Forwarding is only used for Read Completion Data or Write Data.
TXN.07.02#02 2.7.2.1 Error Forwarding should never be used in cases where there are errors in the
header (request phase, address/command, etc.).
TXN.07.02#10 2.7.2.2 Receivers must be able to handle poisoned Completions.
TXN.07.03#01 2.7.2.2 Data Poisoning applies only to the data within a Write Request (Posted or
Non-Posted) or a Read Completion.
TXN.07.03#02 2.7.2.2 Poisoning of a TLP is indicated by a 1b value in the EP field.
TXN.07.03#03 2.7.2.2 If a Transmitter supports data poisoning, TLPs that are known to the
Transmitter to include bad data must use the poisoning mechanism.
TXN.07.03#04 2.7.2.2 Receipt of a poisoned TLP is a reported error associated with the Receiving
device/function.
TXN.07.02#05 2.7.2.2 A poisoned Configuration Write request must be discarded by the
Completer and a Completion with Completion Status of Unsupported
Request returned.
TXN.07.02#07 2.7.2.2 A poisoned I/O Write Request, a poisoned Memory Write Request, or a
poisoned Message with data (except for Vendor_Defined messages), all of
which address a control register or control structure in the Completer must
be handled as an Unsupported Request by the Completer.
TXN.07.02#09 2.7.2.2 Receivers must be able to handle poisoned Write Requests that do not target
control registers or control structures.
TXN.08.00#06 2.8 A Memory Read Request for which there are multiple Completions must be
considered completed only when all Completions have been received by the
requester
TXN.08.00#05 2.8 A Completion Timeout is a reported error associated with the Requester
device/function.
TXN.08.00#04 2.8 The Completion Timeout timer must expire or cause a timeout event if a
Request is not completed in 50 msec.
TXN.08.00#03 2.8 The Completion Timeout timer must not expire or cause a timeout event in
less than 50 usec.
TXN.08.00#08 2.8 The Completion Timeout mechanism must be activated, for each Request
(except for Configuration Requests) that require one or more Completions,
when the Request is transmitted.

27
 ENDPOINT COMPLIANCE CHECKLIST FOR THE PCI EXPRESS BASE 1.1 SPECIFICATION,
REVISION 1.1

ID Ref Assertion Y N
TXN.08.00#07 2.8 The Completion Timeout mechanism must only be activated when there is
not reasonable expectation that the Completion will be returned and should
never occur under normal operating conditions.
TXN.08.00#02 2.8 Any device that issues Requests requiring Completions (except for
Configuration Requests) must implement the Completion Timeout
mechanism.
TXN.09.01#10 2.9.1 For a Port with DL_Down status, the Transaction Layer is not required to
accept received TLPs from the Data Link Layer, provided that these TLPs
have not been acknowledged by the Data Link Layer. Such TLPs do not
modify receive Flow Control credits.
TXN.09.01#07 2.9.1 For a port on an Endpoint, and the port on a Switch or Bridge that is closest
to the Root Complex, DL_Down status is handled as a reset by returning all
PCI Express-specific registers, state machines and externally observable
state to the specified default or initial conditions (except for registers
defined as sticky).
TXN.09.01#08 2.9.1 For a port on an Endpoint, and the port on a Switch or Bridge that is closest
to the Root Complex, DL_Down status is handled by discarding all TLPs
being processed.
TXN.09.02#02 2.9.2 The Transaction layer of a port with DL_UP status must accept received
TLPs that conform to normal TLP rules.

Explanations:
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
__________________________________________________________
__________________________________________________________
__________________________________________________________
__________________________________________________________
__________________________________________________________
This section should be used to clarify any answers on checklist items above. Please key explanation to item number.

28
 ENDPOINT COMPLIANCE CHECKLIST FOR THE PCI EXPRESS BASE 1.1 SPECIFICATION,
REVISION 1.1

Link Layer Checklist

ID Ref Assertion Y N
DLL.02.00#01 3.2 All device's Data Link Layer Control and Management state machine must
comply to the Data Link control and Management State Machine Figure 3-2 in
the PCI Express Base Specification 1.1.
DLL.02.01#01 3.2.1 A device's Data Link Layer Control and Management state machine must enter
the DL_Inactive state following any PCI Express hot, warm or cold reset that it
sees.
DLL.02.01#22 3.2.1 Upon entry into DL_Inactive state, all Data Link Layer state information must
be reset to their default values.
DLL.02.01#11 3.2.1 Upon entry into DL_Inactive state, the contents of the Data Link Layer Retry
Buffer must be discarded.
DLL.02.01#12 3.2.1 While in DL_Inactive state, report DL_Down status to the Transaction Layer
as well as to the rest of the Data Link Layer.
DLL.02.01#13 3.2.1 While in DL_Inactive state, discard TLP information from the Transaction and
Physical Layers.
DLL.02.01#14 3.2.1 While in DL_Inactive state, do not generate or accept DLLPs.
DLL.02.01#15 3.2.1 Exit to DL_Init state only when the Transaction Layer indicates that the link is
not disabled by software and the Physical Layer reports Physical LinkUp = 1.
DLL.02.01#23 3.2.1 While in DL_Init state, attempt to initialize Flow Control for default VC0.
DLL.02.01#16 3.2.1 While in DL_Init state and sub-state FC_INIT1, report DL_Down status.
DLL.02.01#17 3.2.1 While in DL_Init state and sub-state FC_INIT2, report DL_Up status.
DLL.02.01#24 3.2.1 A device detecting DL_Down status must fully process any previously
received TLPs that it has already sent ACK for.
DLL.02.01#18 3.2.1 While in DL_Init state, exit to DL_Active state if Flow Control initialization
completes successfully and the Physical Layer continues to report Physical
LinkUp = 1.
DLL.02.01#19 3.2.1 While in DL_Init state, terminate attempt to initialize Flow Control for VC0
and exit to DL_Inactive state if Physical Layer reports Physical LinkUp = 0.
DLL.02.01#25 3.2.1 While in DL_Active state, accept and transfer TLPs with the Transaction and
Physical Layers.
DLL.02.01#26 3.2.1 While in DL_Active state, generate and accept DLLPs.
DLL.02.01#20 3.2.1 While in DL_Active state, report DL_Up status to the Transaction and Data
Link Layers.
DLL.02.01#21 3.2.1 While in DL_Active state, exit to DL_Inactive state if the Physical Layer
reports Physical LinkUp = 0.
DLL.02.01#29 3.2.1 The Data Link Layer must be able to temporarily block TLPs and DLLPs from
being sent to the Physical Layer, should the Physical Layer be temporarily
unable to accept them.
DLL.03.00#01 3.3 TLP traffic on already initialized VCs should not have any effect on the
initialization process for additional VCs.
DLL.03.01#01 3.3.1 Disabling of VC1-VC7 at any time during initialization of the VC terminates
the initialization process for the disabled VC.
DLL.03.01#11 3.3.1 FC_INIT1 state is entered for VC0 upon entering DL_Init state.
DLL.03.01#12 3.3.1 FC_INIT1 state is entered for VC1-7 (if supported) when the specific VC is
enabled by software.
DLL.03.01#02 3.3.1 While in FC_INIT1 state, the transaction layer must block transmission of all
TLPs using that VC.
DLL.03.01#03 3.3.1 While in FC_INIT1 state, three InitFC1 DLLPs for the VC must be sent in the
following relative order: InitFC1-P (1st), InitFC1-NP (2nd), InitFC1-Cpl (3rd).

29
 ENDPOINT COMPLIANCE CHECKLIST FOR THE PCI EXPRESS BASE 1.1 SPECIFICATION,
REVISION 1.1

ID Ref Assertion Y N
DLL.03.01#04 3.3.1 While in FC_INIT1 state, the three InitFC1 DLLPs must be re-transmitted at
least once every 34 usec (excluding any time spent in Recovery LTSSM state).
DLL.03.01#13 3.3.1 While in FC_INIT1 state, the Data Link Layer must not block any other
transmissions, except as needed to ensure the required frequency of InitFC1
DLLP transmission.
DLL.03.01#14 3.3.1 While in FC_INIT1 state, any received InitFC1 and InitFC2 DLLPs must be
processed and have their FC unit values recorded.
DLL.03.01#05 3.3.1 While in FC_INIT1 state, exit to FC_INIT2 state only after the FC Unit values
have been recorded for each of P, NP, and Cpl for that VC.
DLL.03.01#15 3.3.1 While in FC_INIT2 state, the transaction layer must block transmission of all
TLPs using that VC.
DLL.03.01#06 3.3.1 While in FC_INIT2 state, three InitFC2 DLLPs for the VC must be sent in the
following relative order: InitFC2-P (1st), InitFC2-NP (2nd), InitFC2-Cpl (3rd).
DLL.03.01#07 3.3.1 While in FC_INIT2 state, the three InitFC2 DLLPs must be re-transmitted at
least once every 34 usec (excluding any time spent in Recovery LTSSM state).
DLL.03.01#16 3.3.1 While in FC_INIT2 state, the Data Link Layer must not block any other
transmissions, except as needed to ensure the required frequency of InitFC2
DLLP transmission.
DLL.03.01#17 3.3.1 While in FC_INIT2 state, any received InitFC1 and InitFC2 DLLPs must be
processed, but their FC unit values are ignored.
DLL.03.01#08 3.3.1 While in FC_INIT2 state, exit the state after receiving any InitFC2 DLLP for
that VC.
DLL.03.01#09 3.3.1 While in FC_INIT2 state, exit the state after receiving any TLP for that VC.
DLL.03.01#10 3.3.1 While in FC_INIT2 state, exit the state after receiving any UpdateFC DLLP
for that VC.
DLL.04.01#01 3.4.1 All transmitted DLLPs must have Reserved fields set to 0.
DLL.04.01#02 3.4.1 Upon receiving a DLLP, the Data Link Layer receiver must ignore values in
all Reserved fields.
DLL.04.01#35 3.4.1 Byte 0 of any transmitted DLLP must contain a valid DLLP Type Encoding as
given in DLLP Type Encodings Table 3-1 of the PCI Express Base
Specification 1.1.
DLL.04.01#03 3.4.1 Byte 4 and byte 5 of any DLLP must contain the 16bit CRC value for that
DLLP.
DLL.04.01#04 3.4.1 InitFC1 and InitFC2 DLLPs must only be used for VC initialization.
DLL.04.01#05 3.4.1 DLLP Type field (bits 7-0) must be 0000 0000b for an ACK DLLP.
DLL.04.01#06 3.4.1 DLLP Type field (bits 7-0) must be 0001 0000b for a NAK DLLP.
DLL.04.01#07 3.4.1 Byte 1 (bits 7-0) and Byte 2 (bits 7-4) of a ACK DLLP or NAK DLLP are
reserved.
DLL.04.01#36 3.4.1 Byte 2 (bits 3-0) and Byte 3 (bits 7-0) of a ACK DLLP or NAK DLLP contain
the AckNak_Seq_Num and must indicate the TLPs effected by the DLLP.
DLL.04.01#08 3.4.1 DLLP Type field (bits 7-4) must be 0100b for InitFC1-P (Posted) DLLPs.
DLL.04.01#09 3.4.1 DLLP Type field (bits 7-4) must be 0101b for InitFC1-NP (NonPosted)
DLLPs.
DLL.04.01#10 3.4.1 DLLP Type field (bits 7-4) must be 0110b for InitFC1-Cpl (Completion)
DLLPs.
DLL.04.01#11 3.4.1 DLLP Type field (bit 3) must be zero for all InitFC1 DLLPs.
DLL.04.01#12 3.4.1 DLLP Type field (bits 2-0) must specify the Virtual Channel ID for which this
InitFC1 DLLP applies.
DLL.04.01#37 3.4.1 Byte 1 (bits 7-6) and Byte 2 (bits 5-4) of any InitFC1 DLLP are reserved.
DLL.04.01#13 3.4.1 Byte 1 (bits 5-0) and byte 2 (bits 7-6) of any InitFC1 DLLP must specify the
credit value for headers for the indicated type (P, NP, or Cpl).
DLL.04.01#14 3.4.1 Byte 2 (bits 3-0) and Byte 3 (bits 7-0) of any InitFC1 DLLP must specify the
credit value for data for the indicated type (P, NP, or Cpl).

30
 ENDPOINT COMPLIANCE CHECKLIST FOR THE PCI EXPRESS BASE 1.1 SPECIFICATION,
REVISION 1.1

ID Ref Assertion Y N
DLL.04.01#15 3.4.1 DLLP Type field (bits 7-4) must be 1100b for InitFC2-P (Posted) DLLPs.
DLL.04.01#16 3.4.1 DLLP Type field (bits 7-4) must be 1101b for InitFC2-NP (NonPosted)
DLLPs.
DLL.04.01#17 3.4.1 DLLP Type field (bits 7-4) must be 1110b for InitFC2-Cpl (Completion)
DLLPs.
DLL.04.01#18 3.4.1 DLLP Type field (bit 3) must be zero for all InitFC2 DLLPs.
DLL.04.01#19 3.4.1 DLLP Type field (bits 2-0) must specify the Virtual Channel ID for which this
InitFC2 DLLP applies.
DLL.04.01#38 3.4.1 Byte 1 (bits 7-6) and Byte 2 (bits 5-4) of any InitFC2 DLLP are reserved.
DLL.04.01#20 3.4.1 Byte 1 (bits 5-0) and byte 2 (bits 7-6) of any InitFC2 DLLP must specify the
credit value for headers for the indicated type (P, NP, or Cpl).
DLL.04.01#21 3.4.1 Byte 2 (bits 3-0) and Byte 3 (bits 7-0) of any InitFC2 DLLP must specify the
credit value for data for the indicated type (P, NP, or Cpl).
DLL.04.01#22 3.4.1 DLLP Type field (bits 7-4) must be 1000b for UpdateFC-P (Posted) DLLPs.
DLL.04.01#23 3.4.1 DLLP Type field (bits 7-4) must be 1001b for UpdateFC-NP (NonPosted)
DLLPs.
DLL.04.01#24 3.4.1 DLLP Type field (bits 7-4) must be 1010b for UpdateFC-Cpl (Completion)
DLLPs.
DLL.04.01#25 3.4.1 DLLP Type field (bit 3) must be zero for all UpdateFC DLLPs.
DLL.04.01#26 3.4.1 DLLP Type field (bits 2-0) must specify the Virtual Channel ID for which this
UpdateFC DLLP applies.
DLL.04.01#39 3.4.1 Byte 1 (bits 7-6) and Byte 2 (bits 5-4) of any UpdateFC DLLP are reserved.
DLL.04.01#27 3.4.1 Byte 1 (bits 5-0) and byte 2 (bits 7-6) of any UpdateFC DLLP must specify the
credit value for headers for the indicated type (P, NP, or Cpl).
DLL.04.01#28 3.4.1 Byte 2 (bits 3-0) and Byte 3 (bits 7-0) of any UpdateFC DLLP must specify
the credit value for data for the indicated type (P, NP, or Cpl).
DLL.04.01#29 3.4.1 DLLP Type field (bits 7-0) must be 0010 0000b for PM_Enter_L1 DLLPs.
DLL.04.01#30 3.4.1 DLLP Type field (bits 7-0) must be 0010 0001b for PM_Enter_L23 DLLPs.
DLL.04.01#31 3.4.1 DLLP Type field (bits 7-0) must be 0010 0011b for
PM_Active_State_Request_L1 DLLPs.
DLL.04.01#32 3.4.1 DLLP Type field (bits 7-0) must be 0010 0100b for PM _Request_Ack
DLLPs.
DLL.04.01#40 3.4.1 Byte 1, Byte 2, and Byte 3 of any PM DLLP are reserved.
DLL.04.01#33 3.4.1 DLLP Type field (bits 7-0) must be 0011 0000b for Vendor Specific DLLPs.
DLL.04.01#41 3.4.1 Byte 1, Byte 2, and Byte 3 of any Vendor Specific DLLP must follow the
individual vendor's specification.
DLL.04.01#42 3.4.1 DLLPs are differentiated from TLPs when they are presented to, or received
from, the Physical Layer.
DLL.04.01#34 3.4.1 All DLLPs must be covered by a 16-bit CRC using a polynomial have a
coefficient expressed as 100Bh.
DLL.04.01#43 3.4.1 All DLLPs must be covered by a 16-bit CRC using a seed value of FFFFh.
DLL.04.01#44 3.4.1 All DLLPs must be covered by a 16-bit CRC calculation starting with bit 0 of
byte 0 and proceeding from bit 0 to bit 7 of each byte.
DLL.04.01#45 3.4.1 All DLLPs must be covered by a 16-bit CRC calculation covering all bits in
the DLLP (including reserved fields).
DLL.04.01#46 3.4.1 All DLLPs must be covered by a 16-bit CRC calculation that is complemented
before placing it in the CRC field.
DLL.04.01#47 3.4.1 All DLLPs must be covered by a 16-bit CRC mapping that corresponds to
Mappings of Bits into CRC Field Table 3-2 of the PCI Express Base
Specification 1.1.
DLL.05.02#03 3.5.2.1 The first TLP transmitted after coming out of DL_Inactive state must have a
TLP sequence number equal to zero.

31
 ENDPOINT COMPLIANCE CHECKLIST FOR THE PCI EXPRESS BASE 1.1 SPECIFICATION,
REVISION 1.1

ID Ref Assertion Y N
DLL.05.02#21 3.5.2.1 The DLLP state machine after entering DL_Inactive state must set its internal
counter of the last acknowledged TLP sequence number equal to the maximum
sequence number (all 1's).
DLL.05.02#04 3.5.2.1 The DLLP state machine after entering DL_Inactive state must set its internal
counter of the number of times the Retry Buffer has been re-transmitted to
zero.
DLL.05.02#22 3.5.2.1 The DLLP state machine must start its internal Replay Timer, if not already
started, when the last symbol of any TLP transmission or re-transmission.
DLL.05.02#23 3.5.2.1 The DLLP state machine must reset and restart its internal Replay Timer when
the last symbol of the first TLP to be re-transmitted for each replay.
DLL.05.02#24 3.5.2.1 The DLLP state machine must restart its internal Replay Timer when it
receives an ACK DLLP and there are outstanding TLPs, only if the ACK
DLLP was for some TLP in the retry buffer.
DLL.05.02#25 3.5.2.1 The DLLP state machine must reset and stop (awaiting a restart condition) its
internal Replay Timer when it receives a NAK DLLP (except during replay),
or when the Reply Timer expires.
DLL.05.02#26 3.5.2.1 The DLLP state machine must hold its internal Replay Timer when Recovery
LTSSM occurs. During Link retraining the Replay Timer must not advance.
DLL.05.02#27 3.5.2.1 The DLLP state machine must reset and hold its internal Replay Timer as soon
as all outstanding TLPs are acknowledged. It must remain in this state as long
as no outstanding TLPs exist.
DLL.05.02#28 3.5.2.1 The DLLP Link Layer must not modify the contents of a TLP received from
the Transaction Layer, except to pre-pend a 16 bit value (leading 4 bits are
reserved and remaining 12 bits are the sequence number), that corresponds to
the next available sequence number (NEXT_TRANSMIT_SEQ).
DLL.05.02#05 3.5.2.1 The transmitter must cease accepting TLPs from the Transaction Layer if the
equation: (NEXT_TRANSMIT_SEQ - ACKD_SEQ) mod 4096 >= 2048 is
true. It can only accept TLPs when the equation becomes false.
DLL.05.02#29 3.5.2.1 All TLPs must be covered by a 32-bit LCRC using a polynomial have a
coefficient expressed as 04C1 1DB7h.
DLL.05.02#30 3.5.2.1 All TLPs must be covered by a 32-bit LCRC using a seed value of FFFF
FFFFh.
DLL.05.02#31 3.5.2.1 All TLPs must be covered by a 32-bit LCRC calculation starting with bit 0 of
byte 0 and proceeding from bit 0 to bit 7 of each byte.
DLL.05.02#32 3.5.2.1 All TLPs must be covered by a 32-bit LCRC calculation covering all bits in
the TLP (including reserved fields).
DLL.05.02#33 3.5.2.1 All TLPs must be covered by a 32-bit LCRC calculation that is complemented
before placing it in the LCRC field.
DLL.05.02#34 3.5.2.1 All TLPs must be covered by a 32-bit LCRC mapping the corresponds to
Mappings of Bits into LCRC Field Table 3-3 of the PCI Express Base
Specification 1.1.
DLL.05.02#35 3.5.2.1 All TLPs must be covered by a 32-bit LCRC appended to the TLP following
the bytes received from the Transaction Layer.
DLL.05.02#36 3.5.2.1 A transmitter wanting to NULLIFY a TLP must logically invert the normal
LCRC value and use the final framing symbol of EDB.
DLL.05.02#06 3.5.2.1 When a transmitter sends a nullified TLP (the final framing symbol = EDB
and LCRC is inverted), the next new TLP transmitted must have the same
sequence number as the previous nullified TLP.
DLL.05.02#37 3.5.2.1 Nullified TLPs are not stored in the Retry Buffer and must not be replayed if
not acknowledged.
DLL.05.02#38 3.5.2.1 All transmitted TLPs (except for Nullified TLPs) are stored in the Retry Buffer
as soon as they are transmitted.
DLL.05.02#39 3.5.2.1 A received NAK or REPLAY TIMER expiration should be ignored if the
Retry Buffer is empty (all TLPs were acknowledged).

32
 ENDPOINT COMPLIANCE CHECKLIST FOR THE PCI EXPRESS BASE 1.1 SPECIFICATION,
REVISION 1.1

ID Ref Assertion Y N
DLL.05.02#40 3.5.2.1 When a replay occurs, the DLLP state machine must increment its internal
counter of the number of times the TLP in the Retry Buffer has been re-
transmitted.
DLL.05.02#02 3.5.2.1 When a replay occurs and the DLLP state machine's internal counter of the
number of times the TLP in the Retry Buffer has been re-transmitted rolls over
from 11b to 00b, the transmitter must ask the Physical Layer to retrain the link
and wait for the retrain to complete before preceding. This must be a reported
error condition unless masked.
DLL.05.02#07 3.5.2.1 The Data Link Layer state, including the contents of Retry Buffer, must not
change in link retraining as long as the Physical Layer reports Physical
LinkUp=1.
DLL.05.02#08 3.5.2.1 The link transmitter must not accept any new TLPs from the Transaction Layer
when a replay occurs.
DLL.05.02#09 3.5.2.1 Before starting the replay, any TLP currently in transmission must be
completed.
DLL.05.02#10 3.5.2.1 Once replay is initiated and if during the reply no ACK or NAK is received
effecting any of the TLPs in the Reply Buffer, the oldest unacknowledged TLP
must be sent first in replay, followed by the rest of the unacknowledged TLPs
in the original transmission order (excluding nullified TLPs). If during replay
an ACK is received effecting one of the TLPs in the Replay Buffer, the
transmitter may skip re-transmission of any newly acknowledged TLPs. If
during replay a NAK is received effecting one of the TLPs in the Replay
buffer, the transmitter may complete the replay.
DLL.05.02#18 3.5.2.1 During replay, any TLP currently in re-transmission must be completed.
DLL.05.02#11 3.5.2.1 During replay, once all TLPs in the Replay Buffer have been re-transmitted,
return to normal operation (including accepting new TLPs from the
Transaction Layer).
DLL.05.02#12 3.5.2.1 During replay, all ACK/NAK DLLPs must be processed. If multiple ACKs
and NAKs are received, then the received ACK or NAK with the highest
sequence number takes precedence, and lower sequence number ACKs or
NAKs are ignored.
DLL.05.02#41 3.5.2.1 During replay, re-transmission of all TLPs in the Replay Buffer should
proceed regardless of current flow control credit levels.
DLL.05.02#13 3.5.2.1 Any unacknowledged TLPs in the Retry Buffer can only be re-transmitted
after the Replay Timer value (as specified by Unadjusted REPLAY_TIMER
Limits by Link Width and Max_Payload_Size Table 3-4 in the PCI Express
Base Specification 1.1) plus Receiver L0s adjustment offset, is exceeded and if
no ACK or NAK DLLP has been received by the transmitter within that same
time. This must be a reported error condition unless masked.
DLL.05.02#42 3.5.2.1 Replay Timer timeout values given in Unadjusted REPLAY_TIMER Limits
by Link Width and Max_Payload_Size Table 3-4 in the PCI Express Base
Specification 1.1 are measured at the TLP transmitter port from the last
symbol of the TLP to the first symbol of the TLP re-transmission.
DLL.05.02#43 3.5.2.1 All received DLLPs must be processed in accordance with Ack/Nak DLLP
Processing Flowchart Figure 3-16 of the PCI Express Base Specification 1.1.
DLL.05.02#14 3.5.2.1 If the Physical Layer indicates a Receiver Error, discard any DLLP currently
being received and free any storage for that DLLP.
DLL.05.02#15 3.5.2.1 All received DLLPs must compare the CRC field with the calculated CRC of
the DLLP and if not equal, the DLLP is corrupt. All corrupt DLLPs must be
discarded and be reported as an error associated with the port unless masked.
DLL.05.02#16 3.5.2.1 A non-corrupt received DLLP with undefined encodings shall be dropped
silently by the receiver with no error associated.
DLL.05.02#44 3.5.2.1 Receivers must process all DLLPs received at the rate they are received.

33
 ENDPOINT COMPLIANCE CHECKLIST FOR THE PCI EXPRESS BASE 1.1 SPECIFICATION,
REVISION 1.1

ID Ref Assertion Y N
DLL.05.02#17 3.5.2.1 If a received ACK or NAK DLLP doesn't have a sequence number of an
unacknowledged TLP, or of the most recently acknowledged TLP, the DLLP
is discarded. This is reported as a Data Link Layer Protocol Error (if enabled)
associated with the port.
DLL.05.02#45 3.5.2.1 If a received ACK DLLP has a sequence number of an unacknowledged TLP
in the Replay Buffer, purge from the Replay Buffer all TLPs from the oldest to
the one matching the ACK sequence number.
DLL.05.02#46 3.5.2.1 If a received ACK DLLP has a sequence number of an unacknowledged TLP
in the Replay Buffer, reset the DLLP state machine's internal counter of the
number of times the TLP in the Retry Buffer has been re-transmitted.
DLL.05.02#47 3.5.2.1 By itself, receiving a NAK DLLP is never reported as an error.
DLL.05.02#48 3.5.2.1 All received DLLPs must be processed in accordance with Received DLLP
Error Check Flowchart Figure 3-15 of the PCI Express Base Specification 1.1.
DLL.05.03#07 3.5.3.1 The DLLP receiver, after coming out of DL_Inactive state must set the first
expected received TLP sequence number equal to zero.
DLL.05.03#08 3.5.3.1 The DLLP receiver must clear any scheduled NAKs when in DL_Inactive
state.
DLL.05.03#09 3.5.3.1 The DLLP receiver must clear its counter of the time since the last ACK or
NAK DLLP was scheduled when in the DL_Inactive state.
DLL.05.03#10 3.5.3.1 The DLLP receiver must restart from 0 its counter of the time since the last
ACK or NAK DLLP was scheduled when an ACK or NAK is scheduled.
DLL.05.03#11 3.5.3.1 The DLLP receiver must reset to 0 its counter of the time since the last ACK
or NAK DLLP was scheduled when all received TLPs have been
acknowledged.
DLL.05.03#12 3.5.3.1 The DLLP receiver must start its counter of the time since the last ACK or
NAK DLLP was scheduled when there are initially no unacknowledged
received TLPs and a new TLP is forwarded to the Receive Transaction Layer.
DLL.05.03#13 3.5.3.1 If the Physical Layer indicates a Receiver Error, discard any TLP currently
being received and free any storage for that TLP.
DLL.05.03#14 3.5.3.1 If the Physical Layer indicates a Receiver Error and a TLP is currently being
received than immediately schedule a NAK DLLP for transmission, but only if
there is no NAK already scheduled.
DLL.05.03#01 3.5.3.1 If a TLP is received with EDB end framing symbol, and the LCRC is the
logical NOT of the calculated value, discard the TLP and free any storage
associated with it. Do not report this as an error.
DLL.05.03#15 3.5.3.1 If a TLP with EDB end framing symbol, and the LCRC does not match the
logical NOT of the calculated value, discard the TLP and free any storage for
the TLP, than immediately schedule a NAK DLLP for transmission, but only if
there is no NAK already scheduled. This is reported as an error (if enabled)
associated with the port.
DLL.05.03#06 3.5.3.1 All received TLPs must compare the LCRC field with the calculated LCRC of
the TLP and if not equal, the TLP is corrupt. All corrupt TLPs must be
discarded and be reported as an error associated with the port unless masked.
DLL.05.03#02 3.5.3.1 If a normal TLP (one with END end framing symbol) is received and its
LCRC doesn't match the calculated LCRC, discard the TLP and free any
storage associated with it, than immediately schedule a NAK DLLP for
transmission, but only if there is no NAK already scheduled. This is reported
as an error (if enabled) associated with the port.
DLL.05.03#03 3.5.3.1 If the received TLP sequence number isn't equal to the next expected sequence
number value, discard the TLP and free any storage associated with it.
DLL.05.03#16 3.5.3.1 If the received TLP sequence number satisfies the equation: (next expected
sequence number - received sequence number ) mod 4096 <= 2048, schedule
an ACK DLLP (this is a duplicate TLP).

34
 ENDPOINT COMPLIANCE CHECKLIST FOR THE PCI EXPRESS BASE 1.1 SPECIFICATION,
REVISION 1.1

ID Ref Assertion Y N
DLL.05.03#17 3.5.3.1 If the received TLP sequence number does not satisfy the equation: (next
expected sequence number - received sequence number ) mod 4096 <= 2048,
than immediately schedule a NAK DLLP for transmission, but only if there is
no NAK already scheduled. This is reported as an error (if enabled) associated
with the port.
DLL.05.03#18 3.5.3.1 If the received TLP sequence number is equal to the next expected sequence
number value and the LCRC was good, the TLP is forwarded to the
Transaction Layer for processing. The next expected sequence number is
incremented, and any scheduled NAK is cleared.
DLL.05.03#19 3.5.3.1 The DLLP Link Layer must not modify the contents of a TLP transmitted to
the Transaction Layer, except to remove the Sequence Number, reserved bits,
and LCRC.
DLL.05.03#20 3.5.3.1 The DLLP Link Layer Receiver flow control mechanisms do not account for
received TLPs until the TLP is forwarded to the Transaction Layer.
DLL.05.03#21 3.5.3.1 All received TLPs must be processed in accordance with Receive Data Link
Layer Handling of TLPs Flowchart Figure 3-17 of the PCI Express Base
Specification 1.1.
DLL.05.03#04 3.5.3.1 An ACK DLLP must be transmitted when all of: Data Link Control and
Management State Machine is in the DL_Active state; TLPs have been
forwarded to the Transaction Layer but not yet acknowledged; the
AckNak_LATENCY_TIMER reaches or exceeds the time limit set in
Unadjusted Ack Transmission Latency Limit and AckFactor by Link Width
and Max Payload Table 3-5 in the PCI Express Base Specification 1.1, plus
Tx_L0s_adjustment (if L0s is enabled otherwise the adjustment value is 0) for
a given Max_Payload_Size and link width; a NAK is not scheduled. Note:
ACK DLLPs may be scheduled more frequently than required by Table 3-5.
DLL.05.03#05 3.5.3.1 The AckNak LATENCY_TIMER must start from zero every time an ACK or
NAK DLLP has been scheduled for transmission.
DLL.05.03#22 3.5.3.1 The transmitted ACK or NAK DLLP uses the value of the last TLP sequence
number successfully forwarded to the Transaction Layer in its
AckNak_Seq_Num field.
DLL.05.03#23 3.5.3.1 AckNak Latency values given in Unadjusted Ack Transmission Latency Limit
and AckFactor by Link Width and Max Payload Table 3-5 in the PCI Express
Base Specification 1.1 are measured at the TLP receiver port from the last
symbol of the received TLP to the first symbol of the ACK or NAK DLLP
being transmitted.
DLL.05.03#24 3.5.3.1 The Retry Buffer must be large enough to ensure that under normal conditions,
transmission is never throttled by waiting for space in the Retry Buffer.

35
 ENDPOINT COMPLIANCE CHECKLIST FOR THE PCI EXPRESS BASE 1.1 SPECIFICATION,
REVISION 1.1

Explanations:
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
__________________________________________________________
__________________________________________________________
__________________________________________________________
__________________________________________________________
__________________________________________________________
This section should be used to clarify any answers on checklist items above. Please key explanation to item number.

36
 ENDPOINT COMPLIANCE CHECKLIST FOR THE PCI EXPRESS BASE 1.1 SPECIFICATION,
REVISION 1.1

Electrical Checklist

ID Ref Assertion Y N
PHY.02.01#03 4.2.1 Transmitters/Receivers must encode/decode 8 bit data into/from 10 bit
Symbols in accordance with Character to Symbol Mapping Figure 4-2 of
the PCI Express Base Specification 1.1.
PHY.02.01#04 4.2.1.1 Transmitters/Receivers must place/take 10 bit Symbols on a lane starting
with the least significant bit of the symbol.
PHY.02.01#05 4.2.1.2 Transmitters/Receivers must send/decode only Valid Special Symbols listed
in Special Symbols Table 4-1 of the PCI Express Base Specification 1.1.
The Special Symbols can only be used for the purposes listed in the table.
PHY.02.01#01 4.2.1.3 Transmitters/Receivers must follow Valid Symbol encoding/decoding
specified in the 8b/10b Data Symbol Codes Table B-1 in the PCI Express
Base Specification.
PHY.02.01#06 4.2.1.3 Transmitters/Receivers must follow Valid Special Symbol
encoding/decoding specified in the 8b/10b Special Character Symbol Codes
Table B-2 in the PCI Express Base Specification.
PHY.02.01#07 4.2.1.3 Once the Transmitter picks the disparity for the first transmitted symbol,
after returning from Electrical Idle state, it must follow the correct 8b/10b
encoding (disparity) rules until it again enters Electrical Idle state. The
Transmitter may only pick a different disparity after first going to Electrical
Idle state.
PHY.02.01#08 4.2.1.3 The Receiver must set the initial disparity to the disparity of the first
received character that obtains symbol lock, after detecting an exit from
Electrical Idle state. It must than follow the correct 8b/10b decoding
(disparity) rules until it either loses Symbol lock, or it again enters the
Electrical Idle state. The Receiver may only set a different initial disparity
after losing and than re-establishing Symbol lock.
PHY.02.01#02 4.2.1.3 A Receiver that detects a received symbol that does not correspond to a
valid symbol, or that corresponds to the incorrect running disparity must
have the Physical Layer notify the Data Link Layer that the received symbol
is invalid.
PHY.02.01#09 4.2.1.3 The receiving device must check that all received symbols correspond to a
valid symbol with the correct running disparity. If this rule is violated, than
a Receiver Error is reported (if enabled) as an error associated with the
receiving port.
PHY.02.02#01 4.2.2 Transmitters must ensure that ordered sets are always transmitted serially on
each lane such that a full ordered set appears simultaneously on all lanes of
a multi-lane link.
PHY.02.03#09 4.2.2.1 Receivers must handle the condition that TLP and DLLP Transmissions are
permitted to follow each other successively as long as the STP and SDP
Symbols aren't placed on the Link more frequently than once per Symbol
Time.
PHY.02.03#06 4.2.2.1 Transmitters must ensure that for Links wider than x1, the SDP Symbol
(representing the start of a DLLP) must be placed in Lane 0 when starting
Transmission of a DLLP from a Logical Idle link condition.
PHY.02.03#10 4.2.2.1 Transmitters must ensure that for xN Links (where N is 8 or more), if an
END or EDB Symbol is placed in a Lane K, where K does not equal N-1,
and is not followed by a STP or SDP Symbol in Lane K+1 (i.e., there is no
TLP or DLLP immediately following on an allowed lane boundary), then
PAD Symbols (Special Symbol K23.7) must be placed in Lanes K+1 to
Lane N-1.

37
 ENDPOINT COMPLIANCE CHECKLIST FOR THE PCI EXPRESS BASE 1.1 SPECIFICATION,
REVISION 1.1

ID Ref Assertion Y N
PHY.02.03#20 4.2.2.1 Transmitters must ensure that if one STP Symbol and one SDP Symbol is
placed on the link in the same symbol time than the STP or SDP is placed
on a lane that is a multiple of 4 (ie. Lanes 0, 4, 8, 12, etc.).
PHY.02.03#19 4.2.2.1 Receivers may optionally check that the SDP symbol was not seen on the
Link more frequently than once per Symbol Time. If this optional check is
implemented and fails, than a Receiver Error is reported as an error (if
enabled) associated with the receiving port.
PHY.02.03#08 4.2.2.1 Transmitters/Receivers must ensure that the SDP symbol must not be placed
on the Link more frequently than once per Symbol Time.
PHY.02.03#18 4.2.2.1 Receivers may optionally check that the STP symbol was not seen on the
Link more frequently than once per Symbol Time. If this optional check is
implemented and fails, than a Receiver Error is reported as an error (if
enabled) associated with the receiving port.
PHY.02.03#07 4.2.2.1 Transmitters must ensure that the STP symbol must not be placed on the
Link more frequently than once per Symbol Time.
PHY.02.03#17 4.2.2.1 Receivers may optionally check that for Links wider than x1, the SDP
Symbol (representing the start of a DLLP) was seen in Lane 0 when
receiving a DLLP from a Logical Idle link condition. If this optional check
is implemented and fails, than a Receiver Error is reported as an error (if
enabled) associated with the receiving port.
PHY.02.03#22 4.2.2.1 Receivers may optionally check that for xN Links (where N is 8 or more), if
an END or EDB Symbol is seen in a Lane K, where K does not equal N-1,
and is not followed by a STP or SDP Symbol in Lane K+1 (i.e., there is no
TLP or DLLP immediately following on an allowed lane boundary), then
PAD Symbols (Special Symbol K23.7) are seen in Lanes K+1 to Lane N-1.
If this optional check is implemented and fails, than a Receiver Error is
reported as an error (if enabled) associated with the receiving port.
PHY.02.03#02 4.2.2.1 Transmitters must ensure that DLLPs must be framed by placing a SDP
Symbol (Special Symbol K28.2) at the start of the DLLP and an END
Symbol (Special Symbol K29.7) at the end of the DLLP.
PHY.02.03#16 4.2.2.1 Receivers may optionally check that for Links wider than x1, the STP
Symbol (representing the start of a TLP) was seen in Lane 0 when receiving
a TLP from a Logical Idle link condition. If this optional check is
implemented and fails, than a Receiver Error is reported as an error (if
enabled) associated with the receiving port.
PHY.02.03#21 4.2.2.1 Receivers may optionally check that if one STP Symbol and one SDP
Symbol is seen on the link in the same symbol time than the STP or SDP
was seen on a lane that is a multiple of 4 (ie. Lanes 0, 4, 8, 12, etc.). If this
optional check is implemented and fails, than a Receiver Error is reported as
an error (if enabled) associated with the receiving port.
PHY.02.03#12 4.2.2.1 Receivers may optionally check that TLPs must be framed by seeing a STP
Symbol (Special Symbol K27.7) at the start of the TLP and an END Symbol
(Special Symbol K29.7) in the case of a good TLP, or EDB Symbol
(Special Symbol K30.7) in the case of a nullified TLP, at the end of the
TLP. If this optional check is implemented and fails, than a Receiver Error
is reported as an error (if enabled) associated with the receiving port.
PHY.02.03#13 4.2.2.1 Receivers may optionally check that DLLPs must be framed by seeing a
SDP Symbol (Special Symbol K28.2) at the start of the DLLP and an END
Symbol (Special Symbol K29.7) at the end of the DLLP. If this optional
check is implemented and fails, than a Receiver Error is reported as an error
(if enabled) associated with the receiving port.

38
 ENDPOINT COMPLIANCE CHECKLIST FOR THE PCI EXPRESS BASE 1.1 SPECIFICATION,
REVISION 1.1

ID Ref Assertion Y N
PHY.02.03#01 4.2.2.1 Transmitters must ensure that TLPs must be framed by placing a STP
Symbol (Special Symbol K27.7) at the start of the TLP and an END Symbol
(Special Symbol K29.7) in the case of a good TLP, or EDB Symbol
(Special Symbol K30.7) in the case of a nullified TLP, at the end of the
TLP.
PHY.02.03#03 4.2.2.1 Transmitters (in the L0 state) that have no packet information or special
ordered sets to send (the Logical Idle state) must send, the logical idle data
character (00h) on all active lanes (scrambled and encoded accordingly).
PHY.02.03#14 4.2.2.1 Receivers (in the L0 state) that detect the logical idle data character (00h) on
all active lanes (scrambled and encoded accordingly) go to the Logical Idle
state.
PHY.02.03#04 4.2.2.1 Receivers must ignore incoming Logical Idle data, and must not have any
dependency other than scramble sequencing on any specific data patterns.
PHY.02.03#15 4.2.2.1 Receivers may optionally check that the logical idle data character (00h), if
received, is received on all active lanes (scrambled and encoded
accordingly). If this optional check is implemented and fails, than a
Receiver Error is reported as an error (if enabled) associated with the
receiving port.
PHY.02.03#05 4.2.2.1 Transmitters must ensure that for Links wider than x1, the STP Symbol
(representing the start of a TLP) must be placed in Lane 0 when starting
transmission of a TLP from a Logical Idle link condition.
PHY.02.04#15 4.2.3 Transmitters/Receivers must perform scrambling/de-scrambling (if not
disabled) by serially XORing the 8 bit (D0-D7) character with the 16 bit
(D0-D15) of the LFSR. An output of the LFSR, D15, is XORed with D0 of
the data to be processed. The LFSR and data register are then serially
advanced and the output processing is repeated for D1 through D7. The
LFSR is advanced after the data is XORed. The LFSR polynomial is:
G(X)=X**16 + X**5 + X**4 +X**3 + 1.
PHY.02.04#10 4.2.3 Scrambling does not apply to a Loopback Slave
PHY.02.04#09 4.2.3 Transmitter/Receivers can only disable Scrambling at the end of the LTSSM
Configuration state.
PHY.02.04#16 4.2.3 For Receivers, every time a COM enters the Receive LFSR on any lane of
that link, the LFSR on the receive side is initialized.
PHY.02.04#08 4.2.3 For Transmitters, immediately after a COM exits the Transmit LFSR, the
LFSR on the transmit side is initialized.
PHY.02.04#07 4.2.3 The initialized value of an LFSR seed (D0-D15) is FFFFh.
PHY.02.04#06 4.2.3 All special characters (K codes) are not scrambled.
PHY.02.04#11 4.2.3 Transmitters/Receivers must enable Scrambling by default in the LTSSM
Detect state.
PHY.02.04#05 4.2.3 All data characters (D codes) except those within a Training Sequence
ordered sets (TS1, TS2) and the Compliance Pattern are scrambled (unless
disabled).
PHY.02.04#03 4.2.3 The COM Symbol (Special Symbol K28.5) initializes the LFSR.
PHY.02.04#14 4.2.3 Receivers must apply de-scrambling (if not disabled) to characters after
8b/10b decoding.
PHY.02.04#13 4.2.3 Transmitters must apply scrambling (if not disabled) to characters before
8b/10b encoding.
PHY.02.04#12 4.2.3 Transmitter's/Receiver's LFSRs must operate on data on a Lane-by-Lane
basis as if there was a separate LFSR for each lane within the link,
regardless of the actual number of implemented LFSRs.
PHY.02.04#02 4.2.3 Receivers must ensure that when there is more than one Receive LFSR per
Link, these must operate in concert, maintaining the same simultaneous (see
Differential Receiver (RX) Input Specifications Table 4-6, LRX-SKEW
Total Skew) value in each LFSR.

39
 ENDPOINT COMPLIANCE CHECKLIST FOR THE PCI EXPRESS BASE 1.1 SPECIFICATION,
REVISION 1.1

ID Ref Assertion Y N
PHY.02.04#01 4.2.3 Transmitters must ensure that when there is more than one transmit Linear
Feedback Shift Register (LFSR) per Link, these must operate in concert,
maintaining the same simultaneous (see Differential Transmitter (TX)
Output Specifications Table 4-5, LTX-SKEW Lane-to-Lane Output Skew)
value in each LFSR.
PHY.02.04#04 4.2.3 The LFSR value is advanced eight serial shifts for each character except the
SKP.
PHY.02.06#01 4.2.4.1 Transmitters/Receivers must ensure that Training sequence ordered sets are
never scrambled but are always 8b/10b encoded.
PHY.02.06#02 4.2.4.1 Transmitters/Receivers must ensure that Training sequences (TS1 or TS2)
are transmitted consecutively and can only be interrupted by SKP ordered
sets.
PHY.02.06#03 4.2.4.1 The Training control bits for Hot Reset, Disable Link, and Enable Loopback
are mutually exclusive, only one of these bits may be set at a time as well as
transmitted on all Lanes in a configured (all Lanes in L0) or possible (all
Lanes in Configuration) link.
PHY.02.06#05 4.2.4.1 Transmitters/Receivers must ensure that TS1 training sets follow the format
shown in TS1 Ordered Set Table 4-2, in the PCI Express Base Specification
1.1.
PHY.02.06#06 4.2.4.1 Transmitters/Receivers must ensure that TS2 training sets follow the format
shown in TS2 Ordered Set Table 4-3, in the PCI Express Base Specification
1.1.
PHY.02.07#04 4.2.4.2 Transmitters must never invert the transmitted data.
PHY.02.07#03 4.2.4.2 Receivers must support Lane Polarity Inversion across all lanes
independently.
PHY.02.07#01 4.2.4.2 Receivers must check Symbols 6 to15 of TS1 and TS2 to determine if Lane
Polarity Inversion has occurred. If the received TS1 Symbols 6-15 are
D21.5 (instead of D10.2) than Lane Polarity Inversion is detected. If the
received TS2 Symbols 6-15 are D26.5 (instead of D5.2) than Lane Polarity
Inversion is detected.
PHY.02.07#02 4.2.4.2 Receivers must invert received data when Lane Polarity Inversion is
detected.
PHY.02.08#06 4.2.4.3 A single Fast Training Sequence (FTS) must consist of one COM Symbol
(Special Symbol K28.5) and three FTS Symbols (Special Symbol K28.1).
PHY.02.08#01 4.2.4.3 The maximum number of FTS ordered sets (N_FTS) that a component can
request is 255 (providing a bit lock time of 4 * 255 * 10 * UI), so Receivers
must be able to establish bit lock within this time.
PHY.02.08#02 4.2.4.3 Transmitters must send 4096 FTS ordered sets when the Extended Synch bit
is set.
PHY.02.08#03 4.2.4.3 Transmitters must schedule and transmit SKP ordered sets between FTS
ordered sets as necessary to meet the SKP requirements, with the exception
that SKP ordered sets cannot be transmitted during the first N_FTS FTS
ordered sets.
PHY.02.08#04 4.2.4.3 Transmitters must send one single SKP ordered set after the last FTS is
transmitted. A second SKP ordered set may be sent back to back if needed
by the SKP requirements.
PHY.02.08#05 4.2.4.3 Upon exit from L0s, if the N_FTS period of time expires before the
Receiver obtains bit, Symbol, and Lane-to-Lane de-skew on all lanes of the
configured link, the Receiver must transition to LTSSM Recovery state.
PHY.02.09#05 4.2.4.4 Receivers may optionally check that Loss of Symbol Lock, Lane Deskew
Error, or Elasticity Buffer Overflow/Underflow didn't occur. If this optional
check is implemented and fails, than a Receiver Error is reported as an error
(if enabled) associated with the receiving port.

40
 ENDPOINT COMPLIANCE CHECKLIST FOR THE PCI EXPRESS BASE 1.1 SPECIFICATION,
REVISION 1.1

ID Ref Assertion Y N
PHY.02.09#04 4.2.4.4 If a Receiver Lane detects an implementation specific number of 8b/10b
decode errors, Symbol lock must be verified or re-established as soon as
possible.
PHY.02.09#06 4.2.4.4 Link Errors that occur, while in any LTSSM states other than L0 state, must
not result in the Physical Layer initiating a LTSSM state transition.
PHY.02.09#02 4.2.4.4 For Receivers on a configured link in L0 state, error recovery must at a
minimum be managed in a layer above the Physical Layer by directing the
link to transition to Recovery state. Link Errors may also result in the
Physical Layer initiating a LTSSM state transition from L0 to Recovery.
PHY.02.09#03 4.2.4.4 All LTSSM states other than L0 state make progress (ie. don't stay in one
state indefinitely except for the Detect state) when Link Errors occur.
PHY.02.10#06 4.2.4.5.1 When Fundamental Reset is asserted the Transmitter is required to hold a
constant DC common mode voltage.
PHY.02.10#04 4.2.4.5.1 When Fundamental Reset is de-asserted the port LTSSM must be
initialized.
PHY.02.10#01 4.2.4.5.1 Fundamental Reset only applies when Main power is present. It is not valid
if there is only Aux power present.
PHY.02.10#03 4.2.4.5.1 When Fundamental Reset is asserted, Receiver terminations are required to
only meet ZRX-HIGH-IMP-DC >= 200K (per Differential Receiver (RX)
Input Specifications Table 4-6).
PHY.02.10#05 4.2.4.5.1 When Fundamental Reset is asserted the Transmitter is required only to
meet ITX-SHORT <= 90 mA (per Differential Transmitter (TX) Output
Specifications Table 4-5).
PHY.02.11#02 4.2.4.6 Transmitters must specify all supported data rates in the Data Rate Identifier
field in the training sequence ordered set.
PHY.02.11#01 4.2.4.6 All Transmitters are required to start Link initialization using a generation 1
data rate on each Lane.
PHY.02.11#03 4.2.4.6 Transmitters may only switch to any higher speed supported by both sides
of the Link during LTSSM Polling.Speed.
PHY.02.12#03 4.2.4.7 The negotiation establishes values for Link Number and Lane Number for
each Lane that is part of a valid Link. Each Lane that is not part of a valid
Link exits the negotiation to become a separate Link or remain in Electrical
Idle.
PHY.02.12#04 4.2.4.7 During Link width and Lane number negotiation, the two communicating
ports must accommodate the maximum allowed Lane-Lane skew (as
specified by LRX-SKEW in Differential Receiver (RX) Input Specifications
Table 4-6).
PHY.02.12#02 4.2.4.7 All Lanes within a link shall simultaneously (as defined by LTX-SKEW in
Differential Transmitter (TX) Output Specifications Table 4-5) transmit data
based on the exact same frequency.
PHY.02.12#01 4.2.4.7 PCI Express Links must only consist of 1, 2, 4, 8, 12, 16, or 32 lanes in
parallel.
PHY.02.13#01 4.2.4.7.1 The ability for a xN port to form a xN Link as well as a x1 Link (where N
can be 32, 16, 12, 8, 4, 2, and 1) is required.
PHY.02.13#05 4.2.4.7.1 Devices must meet the requirements of electromechanical and/or form
factor specifications with regard to the implementation of: supporting links
of width greater than 1 lane, but less than N lanes (where N is the maximum
lane width and can be 32, 16, 12, 8, 4, 2); supporting the ability to split a
port into two or more links; supporting Lane Reversal; supporting the
formation of crosslinks.
PHY.02.13#04 4.2.4.7.1 If optional support for Lane reversal is implemented, than both the
Transmitter and the Receiver of a given port for a multi-lane link must
perform Lane Reversal.

41
 ENDPOINT COMPLIANCE CHECKLIST FOR THE PCI EXPRESS BASE 1.1 SPECIFICATION,
REVISION 1.1

ID Ref Assertion Y N
PHY.02.14#03 4.2.4.8 Lane-to-Lane de-skew must be performed during Configuration, Recovery,
and L0s in the LTSSM.
PHY.02.14#02 4.2.4.8 Lane-to-Lane de-skew shall be done across all Lanes within multi-Lane
links.
PHY.02.14#01 4.2.4.8 The Receiver must compensate for the allowable skew between Lanes
within a multi-Lane link (per in Differential Transmitter (TX) Output
Specifications Table 4-5 and Differential Receiver (RX) Input
Specifications Table 4-6) before delivering the data and control to the Data
Link Layer.
PHY.02.15#03 4.2.4.9 If the optional behavior of a port being able to configure multiple links is
employed, a separate LTSSM is needed for the maximum number of links
that are desired to be configured by any given Port.
PHY.02.15#02 4.2.4.9 Links are formed at the conclusion of LTSSM Configuration state.
PHY.02.15#01 4.2.4.9 Transmitters/Receivers must send/receive, for Lanes to configure properly
into a desired link, the TS1 and TS2 ordered sets with the N_FTS, Data Rate
Identifier, and Training Control fields (symbol 3, 4, and 5) set to the same
value on all Lanes included in the link.
PHY.02.16#02 4.2.5 All counter values in the LTSSM states must be set to the specified values
after power-on/reset.
PHY.02.16#01 4.2.5 All timeout values in the LTSSM states must be set to the specified values
after power-on/reset.
PHY.02.16#03 4.2.5 All timeout values in the LTSSM states must be -0/+50% (unless explicitly
stated otherwise).
PHY.02.16#04 4.2.5.2 Transmitters cannot disable entry into Polling.Compliance (when the proper
conditions for entry are met). Under normal operating conditions,
Transmitters should not enter Polling.Compliance.
PHY.02.17#09 4.2.6 Receivers can only check for 8b/10b Errors while in the Configuration, L0,
Disabled, or Hot Reset LTSSM states.
PHY.02.17#10 4.2.6 Receivers that optionally check for Framing Violations, Loss of Symbol
Lock, Lane Deskew Error, or Elasticity Buffer Overflow/Underflow can
only do so while in the L0 state.
PHY.02.17#11 4.2.6 Device's LTSSMs must follow the Main State Diagram for Link Training
and Status State Machine Figure 4-11, in the PCI Express Base
Specification 1.1.
PHY.02.17#03 4.2.6.1 In Detect.Active sub-state, the Transmitter performs a Receiver Detection
sequence on all un-configured Lanes that can form one or more links.
PHY.02.17#08 4.2.6.1 From Detect.Active sub-state, if exactly the same lanes don't detect a
receiver as in the first Receiver Detection sequence, the LTSSM exits back
to Detect.Quiet sub-state.
PHY.02.17#12 4.2.6.1 In Detect.Active sub-state, lanes that did not detect a receiver must either be
associated (immediately after the LTSSM in progress transitions back to
Detect) with a new LTSSM (if this optional feature is supported) or must
transition to Electrical Idle.
PHY.02.17#07 4.2.6.1 From Detect.Active sub-state, if exactly the same lanes detect a Receiver as
the first Receiver Detection sequence, the LTSSM enters Polling state.
PHY.02.17#06 4.2.6.1 In Detect.Active sub-state, if at least one but not all un-configured Lanes
detect a Receiver then, wait for 12 msec and than the Transmitter performs a
Receiver Detection sequence on all un-configured lanes that can form one
or more Links.
PHY.02.17#04 4.2.6.1 From Detect.Active sub-state, the LTSSM enter Polling state only if a
receiver is detected on all unconfigured lanes.
PHY.02.17#02 4.2.6.1 From Detect.Quiet sub-state, the LTSSM enters Detect.Active sub-state
after a 12 msec timeout or if Electrical Idle is exited on any Lane.

42
 ENDPOINT COMPLIANCE CHECKLIST FOR THE PCI EXPRESS BASE 1.1 SPECIFICATION,
REVISION 1.1

ID Ref Assertion Y N
PHY.02.17#01 4.2.6.1 In Detect.Quiet sub-state, the Transmitter must be in Electrical Idle state,
Generation 1 data rate is selected, and LinkUp=0.
PHY.02.17#05 4.2.6.1 From Detect.Active sub-state, the LTSSM exits back to Detect.Quiet sub-
state only if a Receiver is not detected on any lanes.
PHY.02.26#12 4.2.6.10 In Loopback.Active sub-state, a Loopback Slave must add or delete SKPs
on a per lane basis as required by the specification, with the exception that
SKPs do not have to be simultaneously added or removed across all lanes of
the link. If a SKP ordered set retransmission requires adding a SKP symbol
to accommodate timing tolerance correction, the SKP symbol is inserted in
the retransmitted symbol stream anywhere adjacent to a SKP symbol in a
SKP ordered set following the COM symbol. The inserted SKP symbol
must be of the same disparity as the received SKPs symbols in the SKP
ordered set. If a SKP ordered set retransmission requires dropping a SKP
symbol to accommodate timing tolerance correction, the SKP symbol is not
retransmitted.
PHY.02.26#16 4.2.6.10 In Loopback.Exit sub-state, the Loopback Slave must first transmit
Loopback of all Symbols (including the Electrical Idle ordered set) that
were received prior to detecting Electrical Idle.
PHY.02.26#07 4.2.6.10 From Loopback.Active sub-state, the Loopback Master LTSSM exits to
Loopback.Exit sub-state if directed.
PHY.02.26#01 4.2.6.10 In Loopback.Entry sub-state, set LinkUp = 0.
PHY.02.26#17 4.2.6.10 From Loopback.Exit sub-state, the Loopback Master LTSSM and Loopback
Slave LTSSM exit to Detect state.
PHY.02.26#15 4.2.6.10 In Loopback.Exit sub-state, the Loopback Slave must enter Electrical Idle
on all lanes for 2 msec.
PHY.02.26#14 4.2.6.10 In Loopback.Exit sub-state, the Loopback Master ignores any data received
after the Electrical Idle ordered set is received.
PHY.02.26#08 4.2.6.10 In Loopback.Exit sub-state, the Loopback Master sends an Electrical Idle
ordered set and enters Electrical Idle on all Lanes for 2 msec. The
Loopback Master must transition to Electrical Idle on all lanes within TTX-
IDLE-SET-TO-IDLE (see Differential Transmitter (TX) Output
Specifications Table 4-5) after sending the Electrical Idle ordered set.
PHY.02.26#13 4.2.6.10 In Loopback.Active sub-state, the Loopback Slave must be able to detect an
Electrical Idle condition on any lane within 1 msec of the Electrical Idle
ordered set being received.
PHY.02.26#06 4.2.6.10 From Loopback.Active sub-state, the Loopback Slave LTSSM exits to
Loopback.Exit sub-state when an Electrical Idle ordered set is received, or
Electrical Idle is detected on any lane.
PHY.02.26#05 4.2.6.10 In Loopback.Active sub-state, a Loopback Slave is required to retransmit
the received 10b information as received (even if the 10b code is invalid),
with the polarity inversion determined in Polling state applied, while
continuing to perform clock tolerance compensation.
PHY.02.26#02 4.2.6.10 In Loopback Entry sub-state, the Loopback Master device transmits TS1
ordered sets with the Loopback bit asserted.
PHY.02.26#04 4.2.6.10 In Loopback.Active sub-state, the Loopback Master must send valid 8b/10b
data.
PHY.02.26#11 4.2.6.10 When going from Loopback.Entry sub-state to Loopback.Active sub-state,
the Loopback Slave Transmitter must transition on a transmit symbol
boundary.
PHY.02.26#03 4.2.6.10 From Loopback.Entry sub-state, the Loopback Slave LTSSM exits to
Loopback.Active sub-state.

43
 ENDPOINT COMPLIANCE CHECKLIST FOR THE PCI EXPRESS BASE 1.1 SPECIFICATION,
REVISION 1.1

ID Ref Assertion Y N
PHY.02.26#09 4.2.6.10 From Loopback Entry sub-state, the Loopback Master LTSSM exits to
Loopback.Active sub-state when the Loopback Master receives identical (to
the TS1 ordered sets it is sending) TS1 ordered sets with the Loopback bit
asserted on an implementation specific number of lanes.
PHY.02.26#10 4.2.6.10 From Loopback Entry sub-state, the Loopback Master LTSSM exits to
Loopback.Exit sub-state after a timeout of less than 100 msec, if the
Loopback Master does not receive identical (to the TS1 ordered sets it is
sending) TS1 ordered sets with the Loopback bit asserted on an
implementation specific number of lanes.
PHY.02.27#03 4.2.6.11 From Hot Reset state (as directed by a higher layer), the LTSSM exits to
Detect state, if it receives two consecutive TS1 ordered sets with Hot Reset
bit asserted and configured Link number and Lane number, on any lane,
except if it is directed by a higher layer to remain in Hot Reset state.
PHY.02.27#08 4.2.6.11 From Hot Reset state (not directed by a higher layer), the LTSSM stays in
Hot Reset state, if it receives two consecutive TS1 ordered sets with Hot
Reset bit asserted and configured Link number and Lane number, on any
lane.
PHY.02.27#07 4.2.6.11 In Hot Reset state (not directed by a higher layer), the Transmitter sends
TS1 ordered sets with the Hot Reset bit asserted and the configured Link
number and Lane numbers, on all lanes in the link.
PHY.02.27#01 4.2.6.11 In Hot Reset state (as directed by a higher layer), the Transmitter sends TS1
ordered sets with the Hot Reset bit asserted and the configured Link number
and Lane numbers, on all lanes in the link.
PHY.02.27#04 4.2.6.11 From Hot Reset state (as directed by a higher layer), the LTSSM exits to
Detect state, after a 2 msec timeout, if it does not receive two consecutive
TS1 ordered sets with Hot Reset bit asserted and configured Link number
and Lane number, on any lane.
PHY.02.27#02 4.2.6.11 In Hot Reset state (as directed by a higher layer), if 2 consecutive TS1
ordered sets with the Hot Reset bit asserted and configured Link number
and Lane numbers, are received on any lane, then set LinkUp = 0.
PHY.02.27#09 4.2.6.11 From Hot Reset state (not directed by a higher layer), the LTSSM exits to
Detect state, after a 2 msec timeout, if it does not receive two consecutive
TS1 ordered sets with Hot Reset bit asserted and configured Link number
and Lane number, on any lane.
PHY.02.27#05 4.2.6.11 In Hot Reset state (not directed by a higher layer), if 2 consecutive TS1
ordered sets with the Hot Reset bit asserted and configured Link number
and Lane numbers, are received on any lane, then set LinkUp = 0.
PHY.02.18#16 4.2.6.2 In Polling.Speed sub-state, the Transmitter (if optional support for multiple
LTSSMs with different data rates is implemented) changes the data rate on a
valid group of lanes to the highest common data rate supported on both
sides of the link for that group (as indicated by the Data Rate Identifier field
in the training sequence) and initiates a separate LTSSM for each additional
valid group of lanes running at a different data rate.
PHY.02.18#10 4.2.6.2 From Polling.Configuration sub-state, the LTSSM exits to Configuration
state after 8 consecutive TS2 ordered sets, with Link and Lane numbers set
to PAD, are received on any lanes that detected a Receiver during Detect,
16 TS2 ordered sets are transmitted after receiving one TS2 ordered set, and
none of those same lanes is transmitting and receiving a higher Data Rate
Identifier field value.
PHY.02.18#15 4.2.6.2 From Polling.Speed sub-state, the LTSSM exits back to Polling.Active sub-
state after a minimum of TTX-IDLE-MIN (in Differential Transmitter (TX)
Output Specifications Table 4-5) and no longer than 2 msec.

44
 ENDPOINT COMPLIANCE CHECKLIST FOR THE PCI EXPRESS BASE 1.1 SPECIFICATION,
REVISION 1.1

ID Ref Assertion Y N
PHY.02.18#14 4.2.6.2 In Polling.Speed sub-state, the Transmitter changes the data rate on all lanes
to the highest common data rate supported on both sides of the link as
indicated by the Data Rate Identifier field in the training sequence.
PHY.02.18#12 4.2.6.2 In Polling.Speed sub-state, the Transmitter enters Electrical Idle (after first
sending Electrical Idle ordered set) for a minimum of TTX-IDLE-MIN (in
Differential Transmitter (TX) Output Specifications Table 4-5) and no
longer than 2 msec.
PHY.02.18#04 4.2.6.2 From Polling.Active sub-state, if eight consecutive TS1 or TS2 ordered sets
(or their complement) are not received with Lane and Link numbers set to
PAD on all lanes that detected a receiver, than after a 24 ms timeout, the
LTSSM enters Polling.Compliance sub-state if at least one Lane's Receiver,
which detected a Receiver during Detect, has never detected an exit from
Electrical Idle since entering Polling.Active sub-state.
PHY.02.18#13 4.2.6.2 From Polling.Configuration sub-state, after a 48 msec timeout the LTSSM
enters Detect state, if 8 consecutive TS2 ordered sets, with Link and Lane
numbers set to PAD, are not received on any lanes that detected a Receiver
during Detect or 16 TS2 ordered sets were not transmitted after receiving
one TS2 ordered set.
PHY.02.18#11 4.2.6.2 From Polling.Configuration sub-state, the LTSSM enters Polling.Speed sub-
state after 8 consecutive TS2 ordered sets, with Link and Lane numbers set
to PAD, are received on any lanes that detected a Receiver during Detect,
16 TS2 ordered sets are transmitted after receiving one TS2 ordered set, and
at least one of those same lanes is transmitting and receiving a higher Data
Rate Identifier field value.
PHY.02.18#08 4.2.6.2 In Polling.Configuration sub-state, the Receiver must invert polarity if
necessary.
PHY.02.18#07 4.2.6.2 From Polling.Compliance sub-state, the LTSSM exits back to
Polling.Active sub-state if Electrical Idle exit has been detected at the
Receiver of all lanes that detected a Receiver during Detect.
PHY.02.18#05 4.2.6.2 From Polling.Active sub-state, if eight consecutive TS1 or TS2 ordered sets
(or their complement) are not received with Lane and Link numbers set to
PAD on all lanes that detected a receiver, than after a 24 ms timeout, the
LTSSM enters Detect state if no TS1 or TS2 ordered set is received with
Link and Lane number set to PAD on any lane. The highest advertised
speed in TS1 and TS2 is lowered (unless generation 1 is the highest
advertised speed).
PHY.02.18#03 4.2.6.2 From Polling.Active sub-state, if eight consecutive TS1 or TS2 ordered sets
(or their complement) are not received with Lane and Link numbers set to
PAD on all lanes that detected a receiver, than after a 24 msec timeout, the
LTSSM enters Polling.Configuration sub-state if any lane, which detected a
Receiver during Detect, received 8 consecutive TS1 or TS2 ordered sets (or
their complement) with the Lane and Link numbers set to PAD, and a
minimum of 1024 TS1s are transmitted after receiving one TS1 and all lanes
that detected a Receiver during Detect have detected an exit from Electrical
Idle at least once since entering Polling.Active sub-state.
PHY.02.18#02 4.2.6.2 From Polling.Active sub-state, the LTSSM enters Polling.Configuration
sub-state after 8 consecutive TS1 or TS2 ordered sets (or their complement)
are received with the Lane and Link numbers set to PAD Symbol (Special
Symbol K23.7) on all Lanes that detected a Receiver during Detect and at
least 1024 TS1 ordered sets were transmitted.
PHY.02.18#01 4.2.6.2 In Polling.Active sub-state, the Transmitter sends TS1 ordered sets with
Lane and Link numbers set to PAD Symbol (Special Symbol K23.7) on all
Lanes that detected a Receiver during Detect.

45
 ENDPOINT COMPLIANCE CHECKLIST FOR THE PCI EXPRESS BASE 1.1 SPECIFICATION,
REVISION 1.1

ID Ref Assertion Y N
PHY.02.18#06 4.2.6.2 In Polling.Compliance sub-state, the transmitter sends out the Compliance
Pattern on all lanes that detected a Receiver during Detect at the data rate
which was employed upon entry to Polling.Compliance.
PHY.02.18#09 4.2.6.2 In Polling.Configuration sub-state, the Transmitter sends TS2 ordered sets
with link and lane numbers set to PAD on all Lanes that detected a Receiver
during Detect.
PHY.02.19#29 4.2.6.3 From Configuration.Lanenum.Accept sub-state, for Upstream lanes the
LTSSM exits to Detect state if no Link can be configured or if all Lanes
receive 2 consecutive TS1 ordered sets with PAD Link number and PAD
Lane number.
PHY.02.19#15 4.2.6.3 From Configuration.Linkwidth.Start sub-state, for Upstream lanes the
LTSSM exits to Detect state after a 24 msec timeout if it hasn't: been
directed to Disable state; been directed to Loopback state; received 2
consecutive TS1s with Disable Link bit set; received 2 consecutive TS1s
with Loopback bit set; received 2 consecutive TS1s with non-PAD Link
number and PAD Lane number; if crosslinks (optional) are supported and a
Tcrosslink timeout occurred.
PHY.02.19#18 4.2.6.3 In Configuration.Linkwidth.Accept sub-state, for Upstream lanes that a
configured link can be formed using lanes that transmitted a non-PAD Link
number which are receiving 2 consecutive TS1 ordered sets with the same
non-PAD Link number and any non-PAD Lane number, then TS1 ordered
sets are transmitted with the non-PAD Link number and Lane numbers that
match the received Lane numbers if possible, or Lane numbers that are
backward if necessary to force the other end of the link to implement Lane
Reversal (optional) (the newly assigned transmitted lane numbers must
range from 0 to m-1, be assigned sequentially only to some continuous
grouping of lanes that are receiving non-PAD Lane numbers, must include
either Lane 0 or n-1 (where n is the largest received Lane number), and m-1
must be equal to or smaller than the largest received Lane number (n-1) ).
The remaining unassigned lanes must transmit TS1 with PAD Link number
and PAD Lane number. The LTSSM then exits to
Configuration.Lanenum.Wait sub-state.
PHY.02.19#19 4.2.6.3 From Configuration.Linkwidth.Accept, for Upstream lanes the LTSSM
exits to Detect state after a 2 msec timeout, or if no link can be configured
from the lanes that received 2 consecutive TS1s with the same received non-
PAD and matching one that was transmitted by the Upstream lanes Link
number and any non-PAD Lane number, or if it hasn't received 2
consecutive TS1s with the same received non-PAD and matching one that
was transmitted by the Upstream lanes Link number and any non-PAD Lane
number, or if all Lanes receive 2 consecutive TS1 ordered sets with PAD
Link number and PAD Lane number.
PHY.02.19#42 4.2.6.3 In Configuration.Linkwidth.Start sub-state, if crosslinks (optional) are
supported, if any Upstream lanes don't receive, 2 consecutive TS1 ordered
set with PAD Link number and PAD Lane number followed by 2
consecutive TS1 ordered sets with non-PAD Link number and PAD Lane
number, than after a Tcrosslink timeout (see Differential Transmitter (TX)
Output Specifications Table 4-5) the Transmitters sends 16-32 TS2 ordered
sets with PAD Link number and PAD Lane number, and the Upstream lanes
become Downstream lanes. The LTSSM than exits to
Configuration.Linkwidth.Start sub-state as Downstream lanes.

46
 ENDPOINT COMPLIANCE CHECKLIST FOR THE PCI EXPRESS BASE 1.1 SPECIFICATION,
REVISION 1.1

ID Ref Assertion Y N
PHY.02.19#28 4.2.6.3 In Configuration.Lanenum.Accept sub-state, for Upstream lanes that can
form a link with any subset of lanes that receive 2 consecutive TS1 ordered
sets with the same transmitted non-PAD Link number and any non-PAD
Lane number, the Transmitter sends TS1 ordered sets with non-PAD Link
number and newly assigned non-PAD Lane numbers (the newly assigned
transmitted Lane numbers must range from 0 to m-1, be assigned
sequentially only to some continuous grouping of lanes that are receiving
non-PAD Lane numbers, must include either Lane 0 or n-1 (where n is the
largest received Lane number), and m-1 must be equal to or smaller than the
largest received Lane number (n-1) ). The remaining unassigned lanes must
transmit TS1 with PAD Link number and PAD Lane number. The LTSSM
than exits to Configuration.Lanenum sub-state.
PHY.02.19#40 4.2.6.3 From Configuration.Linkwidth.Start sub-state, for Upstream lanes that
support crosslink (optional), the LTSSM exits to Disable state after all lanes
that detected a Receiver during Detect and are receiving TS1 ordered sets
with the Disable Link bit asserted in 2 consecutive TS1 ordered sets.
PHY.02.19#27 4.2.6.3 From Configuration.Lanenum.Accept sub-state, for Upstream lanes the
LTSSM exits to Configuration.Complete sub-state if 2 consecutive TS2
ordered sets are received with non-PAD Link number and non-PAD Lane
numbers that match all non-PAD Link number and non-PAD Lane numbers
that are being transmitted in Upstream lane TS1 ordered sets.
PHY.02.19#41 4.2.6.3 In Configuration.Linkwidth.Start sub-state, if crosslinks (optional) are
supported, than all Upstream lanes that detected a Receiver during Detect
must first transmit 16-32 TS1s with PAD Link number and PAD Lane
number, than if any Upstream lanes first receive 2 consecutive TS1 ordered
set with PAD Link number and PAD Lane number then the Transmitter
continues to send out TS1 ordered sets with PAD Link number and PAD
Lane number. Next, if any lanes receive 2 consecutive TS1 ordered sets
with non-PAD Link number and PAD Lane number, a single Link number
is selected and transmitted on all lanes that both detected a Receiver during
Detect and also received 2 consecutive TS1 ordered sets with non-PAD
Link number and PAD Lane number. Any left over lanes that detected a
Receiver during Detect must transmit TS1 ordered sets with the PAD Link
number and PAD Lane number. The LTSSM than exits to
Configuration.Linkwidth.Accept sub-state.
PHY.02.19#14 4.2.6.3 In Configuration.Linkwidth.Start sub-state, for Upstream lanes that don't
support crosslinks, if any lanes receive 2 consecutive TS1 ordered sets with
non-PAD Link numbers, a single Link number is selected and transmitted
on all lanes that both detected a Receiver and also received 2 consecutive
TS1 ordered sets with non-PAD Link numbers and Lane number is set to
PAD. Any leftover lanes that detected a Receiver during Detect must
transmit TS1 ordered sets with the Link number set to PAD and Lane
number set to PAD. The LTSSM than exits to
Configuration.Linkwidth.Accept sub-state.
PHY.02.19#13 4.2.6.3 In Configuration.Linkwidth.Start sub-state, for Upstream lanes the
Transmitter sends out TS1 ordered sets with valid Link numbers and Lane
numbers set to PAD on Upstream lanes that detected a Receiver during
Detect.
PHY.02.19#12 4.2.6.3 From Configuration.Linkwidth.Start sub-state, for Upstream lanes the
LTSSM exits to Loopback state if all lanes that detected a Receiver during
Detect, that are also receiving TS1 ordered sets, receive the Loopback bit
asserted in 2 consecutive TS1 ordered sets.

47
 ENDPOINT COMPLIANCE CHECKLIST FOR THE PCI EXPRESS BASE 1.1 SPECIFICATION,
REVISION 1.1

ID Ref Assertion Y N
PHY.02.19#11 4.2.6.3 From Configuration.Linkwidth.Start sub-state, for Upstream lanes that don't
support crosslink, the LTSSM exits to Disable state after any lanes that
detected a Receiver during Detect and are receiving TS1 ordered sets with
the Disable Link bit asserted in 2 consecutive TS1 ordered sets.
PHY.02.19#10 4.2.6.3 From Configuration.Linkwidth.Start sub-state, for Upstream lanes the
LTSSM exits to Loopback state if directed by a higher layer and the
Transmitter is capable of being a Loopback Master.
PHY.02.19#09 4.2.6.3 From Configuration.Linkwidth.Start sub-state, for Upstream lanes where a
crosslink (optional) is supported, the LTSSM exits to Disable state if
directed by a higher layer.
PHY.02.19#37 4.2.6.3 From Configuration.Idle sub-state, the LTSSM exits to L0 state if 8
consecutive Symbol Times of Idle data are received on all configured lanes
and 16 Idle data Symbols are sent after receiving one Idle data Symbol.
PHY.02.19#22 4.2.6.3 From Configuration.Lanenum.Wait sub-state, for Upstream lanes the
LTSSM exits to Configuration.Lanenum.Accept sub-state if any of the lanes
receive 2 consecutive TS1 ordered sets which have a Lane number different
from the value first seen when it most recently entered
Configuration.Lanenum.Wait sub-state and not all the lanes' Link numbers
are set to PAD.
PHY.02.19#36 4.2.6.3 In Configuration.Idle sub-state, the Transmitter sends Idle data symbols on
all configured Lanes.
PHY.02.19#35 4.2.6.3 From Configuration.Complete sub-state, for Upstream lanes the LTSSM
exits to Detect state after a 2 msec timeout, during which all lanes that are
transmitting TS2 ordered sets did not receive 8 consecutive TS2 ordered
sets with matching (non-PAD) Lane number and (non-PAD) Link numbers
PHY.02.19#38 4.2.6.3 From Configuration.Idle sub-state, the LTSSM exits to Detect state after a
minimum 2 msec timeout, if it does not receive 8 consecutive Symbol
Times of Idle data received on all configured lanes.
PHY.02.19#43 4.2.6.3 From Configuration.Lanenum.Wait sub-state, for Upstream lanes the
LTSSM exits to Configuration.Lanenum.Accept sub-state if any lane
receives 2 consecutive TS2 ordered sets.
PHY.02.19#56 4.2.6.3 Any unassigned Upstream lanes that were not part of the configured link, or
that are not associated with an optionally supported new crosslink LTSSM,
must be re-associated with the LTSSM immediately after the LTSSM in
progress transitions to the Detect state.
PHY.02.19#55 4.2.6.3 In Configuration.Complete sub-state, for Upstream lanes, any remaining
unassigned lanes that are not part of the configured link, or that are not
associated with an optionally supported new crosslink LTSSM, must ensure
that the Receiver terminations meet the ZRX-HIGH-IMP-DC (per
Differential Receiver (RX) Input Specifications Table 4-6).
PHY.02.19#54 4.2.6.3 In Configuration.Complete sub-state, for Upstream lanes, any remaining
unassigned lanes that are not part of the configured link, or that are not
associated with an optionally supported new crosslink LTSSM, must
transition to Electrical Idle.
PHY.02.19#23 4.2.6.3 From Configuration.Lanenum.Wait sub-state, for Upstream lanes the
LTSSM exits to Detect state after a 2 msec timeout (where it didn't receive 2
consecutive TS1 ordered sets which have a Lane number different from the
value first seen when it most recently entered Configuration.Lanenum.Wait
sub-state and not all the lanes' Link numbers are set to PAD or it didn't
receive 2 consecutive TS2 ordered sets), or if all lanes receive 2 consecutive
TS1 ordered sets with PAD Link number and PAD Lane number.

48
 ENDPOINT COMPLIANCE CHECKLIST FOR THE PCI EXPRESS BASE 1.1 SPECIFICATION,
REVISION 1.1

ID Ref Assertion Y N
PHY.02.19#34 4.2.6.3 From Configuration.Complete sub-state, for Upstream lanes the LTSSM
exits to Configuration.Idle sub-state immediately after all lanes that are
transmitting TS2 ordered sets receive 8 consecutive TS2 ordered sets with
matching (non-PAD) Lane number and (non-PAD) Link numbers, and 16
consecutive TS2 ordered sets are sent (using Link number and Lane
numbers that match the received TS2 ordered set Link number and Lane
numbers) after receiving one TS2 ordered set.
PHY.02.19#52 4.2.6.3 When leaving the Configuration.Complete sub-state, for Upstream lanes:
Scrambling is disabled if all configured lanes have the Disable Scrambling
bit set in 2 consecutive received TS2 ordered sets.
PHY.02.19#51 4.2.6.3 When leaving the Configuration.Complete sub-state, for Upstream lanes:
the N_FTS value must be noted for use in L0s; lane-to-lane de-skew must
be completed.
PHY.02.19#33 4.2.6.3 In Configuration.Complete sub-state, for Upstream lanes the Transmitter
sends TS2 ordered sets using Link number and Lane numbers that match the
received TS2 ordered set Link number and Lane numbers.
PHY.02.19#46 4.2.6.3 If a port is sending TS2 ordered sets with the Disable Scrambling bit set,
than the sending device must disable Scrambling once it leaves the
Configuration.Complete sub-state.
PHY.02.19#53 4.2.6.3 In Configuration.Complete sub-state, for Upstream lanes, any remaining
unassigned lanes that are not part of the configured link are no longer
associated with the current LTSSM in progress. If optionally supported,
these unassigned lanes must be associated with a new crosslink LTSSM.
PHY.02.19#57 4.2.6.3 The transition from Configuration.Idle sub-state to L0 state sets LinkUp = 1.
PHY.02.20#09 4.2.6.4 From Recovery.Idle sub-state, for Downstream lanes or crosslink (optional)
port, the LTSSM exits to Hot Reset state if directed by a higher layer.
PHY.02.20#10 4.2.6.4 From Recovery.Idle sub-state, the LTSSM exits to Configuration state if
directed by a higher layer.
PHY.02.20#11 4.2.6.4 From Recovery.Idle sub-state, the LTSSM exits to Loopback state if
directed by a higher layer and the Transmitter is capable of being a
Loopback Master.
PHY.02.20#12 4.2.6.4 From Recovery.Idle sub-state, for Upstream lanes and crosslink (optional)
ports), the LTSSM exits to Disabled state immediately after any configured
lane has the Disable Link bit asserted in 2 consecutive received TS1 ordered
sets.
PHY.02.20#13 4.2.6.4 From Recovery.Idle sub-state, for Upstream lanes and crosslink (optional)
ports, the LTSSM exits to Hot Reset state immediately after any configured
lane has the Hot Reset bit asserted in 2 consecutive received TS1 ordered
sets.
PHY.02.20#14 4.2.6.4 From Recovery.Idle sub-state, the LTSSM exits to Configuration state if 2
consecutive TS1 ordered sets are received on any configured lane with a
Lane number set to PAD.
PHY.02.20#18 4.2.6.4 From Recovery.Idle sub-state, the LTSSM exits to Detect state after a 2
msec timeout, if not directed to Disable, Hot Reset, Configuration, or
Loopback states, or if it did not receive 8 consecutive symbol times of Idle
data on all configured lanes.
PHY.02.20#08 4.2.6.4 From Recovery.Idle sub-state, for Downstream lanes or crosslink (optional)
port, the LTSSM exits to Disabled state if directed by a higher layer.
PHY.02.20#15 4.2.6.4 From Recovery.Idle sub-state, the LTSSM exits to Loopback state if any
configured lane has the Loopback bit asserted in 2 consecutive received TS1
ordered sets.

49
 ENDPOINT COMPLIANCE CHECKLIST FOR THE PCI EXPRESS BASE 1.1 SPECIFICATION,
REVISION 1.1

ID Ref Assertion Y N
PHY.02.20#16 4.2.6.4 In Recovery.Idle sub-state, the transmitter sends Idle data on all configured
lanes, except if directed to Disable, Hot Reset, Configuration, or Loopback
states, the Transmitter does not need to send Idle Characters before
performing the state transition.
PHY.02.20#01 4.2.6.4 In Recovery.RcvrLock sub-state, the Transmitter sends TS1 ordered sets on
all configured Lanes using the same Link number and Lane numbers that
were set after leaving Configuration state.
PHY.02.20#22 4.2.6.4 When leaving the Recovery.RcvrCfg sub-state to go to Configuration state:
the most recent N_FTS value must be noted for use in L0s.
PHY.02.20#06 4.2.6.4 From Recovery.RcvrCfg sub-state, the LTSSM exits to Configuration state
if 8 consecutive TS1 ordered sets are received on any configured lanes with
Link number or Lane numbers that don't match what is being transmitted on
those same lanes and 16 TS2 ordered sets were sent after receiving one TS1
ordered set.
PHY.02.20#21 4.2.6.4 When leaving the Recovery.RcvrCfg sub-state to go to Recovery.Idle sub-
state: the most recent N_FTS value must be noted for use in L0s; lane-to-
lane de-skew must be completed.
PHY.02.20#05 4.2.6.4 From Recovery.RcvrCfg sub-state, the LTSSM exits to Recovery.Idle sub-
state if 8 consecutive TS2 ordered sets are received on all configured lanes
with the same Link number and Lane numbers that match what is being
transmitted on those same lanes and 16 TS2 ordered sets were sent after
receiving one TS2 ordered set.
PHY.02.20#04 4.2.6.4 In Recovery.RcvrCfg sub-state, the Transmitter sends TS2 ordered sets on
all configured lanes using the same Link number and Lane numbers that
were set after leaving Configuration state.
PHY.02.20#20 4.2.6.4 From Recovery.RcvrLock sub-state, after a 24 msec timeout the LTSSM
exits to Detect state if all the configured lanes that are receiving a TS1 or
TS2 ordered set have not received at least one TS1 or TS2 ordered set with
Link number and Lane numbers that match what is being transmitted on
those same lanes.
PHY.02.20#03 4.2.6.4 From Recovery.RcvrLock sub-state, after a 24 msec timeout the LTSSM
exits to Configuration state if all the configured lanes that are receiving a
TS1 or TS2 ordered set have received at least one (but did not receive 8
consecutive) TS1 or TS2 ordered set with Link number and Lane numbers
that match what is being transmitted on those same lanes. Otherwise, the
LTSSM reverts to Detect.
PHY.02.20#17 4.2.6.4 From Recovery.Idle sub-state, the LTSSM exits to L0 state if 8 consecutive
symbol times of Idle data are received on all configured lanes and 16 Idle
data symbols were sent after receiving one Idle data symbol.
PHY.02.20#19 4.2.6.4 From Recovery.RcvrLock sub-state (with Extended Synch bit = 1), the
LTSSM exits to Recovery.RcvrCfg sub-state if 8 consecutive TS1 or TS2
ordered sets are received on all configured lanes with the same Link number
and Lane numbers that match what is being transmitted on those same lanes
and the Transmitter has sent a minimum of 1024 consecutive TS1 ordered
sets.
PHY.02.20#02 4.2.6.4 From Recovery.RcvrLock sub-state (with Extended Synch bit = 0), the
LTSSM exits to Recovery.RcvrCfg sub-state if 8 consecutive TS1 or TS2
ordered sets are received on all configured lanes with the same Link number
and Lane numbers that match what is being transmitted on those same lanes.

50
 ENDPOINT COMPLIANCE CHECKLIST FOR THE PCI EXPRESS BASE 1.1 SPECIFICATION,
REVISION 1.1

ID Ref Assertion Y N
PHY.02.20#07 4.2.6.4 From Recovery.RcvrCfg sub-state, the LTSSM exits to Detect state after a
48 msec timeout, if 8 consecutive TS2 ordered sets are not received on all
configured lanes with the same Link number and Lane numbers that match
what is being transmitted on those same lanes, or if 8 consecutive TS1
ordered sets are not received on any configured lanes with Link number or
Lane numbers that don't match what is being transmitted on those same
lanes.
PHY.02.21#07 4.2.6.5 From L0 state, the LTSSM exits to L2 state if directed (and both ends of the
link have agreed to enter L2), and an Electrical Idle ordered set is received
on any lane, and an Electrical Idle ordered set was transmitted on all lanes.
PHY.02.21#06 4.2.6.5 From L0 state, the LTSSM exits to L1 state if directed (and both ends of the
link have agreed to enter L1), and an Electrical Idle ordered set is received
on any lane, and an Electrical Idle ordered set was transmitted on all lanes.
PHY.02.21#05 4.2.6.5 From L0 state, only the LTSSM Receiver exits to L0s state if an Electrical
Idle ordered set is received on any lane, and the port is not directed to the
L1 or L2 states by a higher layer.
PHY.02.21#04 4.2.6.5 From L0 state, only the LTSSM Transmitter exits to L0s state if directed by
a higher layer.
PHY.02.21#03 4.2.6.5 From L0 state, the LTSSM exits to Recovery state if directed by a higher
layer.
PHY.02.21#01 4.2.6.5 In L0 state, set LinkUp = 1.
PHY.02.21#02 4.2.6.5 From L0 state, the LTSSM exits to Recovery state if a TS1 or TS2 ordered
set is received on any configured lane.
PHY.02.22#06 4.2.6.6 From Tx_L0s.Entry sub-state, only the LTSSM Transmitter exits to
Tx_L0s.Idle sub-state after a TTX-IDLE-MIN (see Differential Transmitter
(TX) Output Specifications Table 4-5) timeout.
PHY.02.22#11 4.2.6.6 In Tx_L0s.FTS sub-state (when Extended Synch bit = 1), the Transmitter
sends 4096 number of Fast Training Sequences on all configured lanes
without any SKP inserted between the FTS. After sending the required FTS
a single SKP ordered set is sent on all configured lanes.
PHY.02.22#08 4.2.6.6 In Tx_L0s.FTS sub-state (when Extended Synch bit = 0), the Transmitter
sends N_FTS number of Fast Training Sequences on all configured lanes
without any SKP inserted between the FTS. After sending the required FTS
a single SKP ordered set is sent on all configured lanes.
PHY.02.22#03 4.2.6.6 From Rx_L0s.FTS sub-state, only the LTSSM Receiver exits to L0 state if a
SKP ordered set is received on all configured lanes of the link
PHY.02.22#07 4.2.6.6 From Tx_L0s.Idle sub-state, only the LTSSM Transmitter exits to
Tx_L0s.FTS sub-state if directed.
PHY.02.22#12 4.2.6.6 From Tx_L0s.FTS sub-state, only the LTSSM Transmitter exits to L0 state
after sending the required number of Fast Training Sequences and the single
SKP ordered set on all configured lanes.
PHY.02.22#10 4.2.6.6 From Rx_L0s.FTS sub-state (with Extended Synch bit = 1), only the
LTSSM Receiver enters Recovery state after the N_FTS timeout, if it didn't
see a SKP ordered set on all configuration lanes of the link. The N_FTS
timeout value must be greater than or equal to 40*[2048]*UI and must be
less or equal to 40*[4096]*UI.
PHY.02.22#09 4.2.6.6 When leaving the Rx_L0s.FTS sub-state to go to L0 state: the Receiver
must be able to accept valid data immediately after the SKP ordered set;
lane-to-lane de-skew must be completed.
PHY.02.22#02 4.2.6.6 From Rx_L0s.Idle sub-state, only the LTSSM Receiver exits to
Rx_L0s.FTS sub-state if the Receiver detects an exit from Electrical Idle on
any lane of the configured link.

51
 ENDPOINT COMPLIANCE CHECKLIST FOR THE PCI EXPRESS BASE 1.1 SPECIFICATION,
REVISION 1.1

ID Ref Assertion Y N
PHY.02.22#01 4.2.6.6 From Rx_L0s.Entry sub-state, only the LTSSM Receiver exits to
Rx_L0s.Idle after a TTX-IDLE-MIN (see Differential Transmitter (TX)
Output Specifications Table 4-5) timeout.
PHY.02.22#04 4.2.6.6 From Rx_L0s.FTS sub-state (with Extended Synch bit = 0), only the
LTSSM Receiver enters Recovery state after the N_FTS timeout, if it didn't
see a SKP ordered set on all configuration lanes of the link. The N_FTS
timeout value must be greater than or equal to 40*[N_FTS+3]*UI and must
be less or equal to 2*(40*[N_FTS+3]*UI).
PHY.02.22#05 4.2.6.6 In Tx_L0s.Entry sub-state, the Transmitter sends the Electrical Idle ordered
set and enters Electrical Idle. In Electrical Idle the DC common mode
voltage must be within TTX-IDLE-SET-TO-IDLE and must meet VTX-
CM-DC-ACTIVE-IDLE-DELTA (see Differential Transmitter (TX) Output
Specifications Table 4-5).
PHY.02.23#03 4.2.6.7 In L1.Idle sub-state, the Transmitter remains in Electrical Idle. In Electrical
Idle the DC common mode voltage must be within TTX-IDLE-SET-TO-
IDLE and must meet VTX-CM-DC-ACTIVE-IDLE-DELTA (see
Differential Transmitter (TX) Output Specifications Table 4-5).
PHY.02.23#04 4.2.6.7 From L1.Idle sub-state, the LTSSM exits to Recovery state if the Receiver
detects exit from Electrical Idle on any lane, or if directed by a higher layer.
PHY.02.23#02 4.2.6.7 From L1.Entry sub-state, the LTSSM exits to L1.Idle sub-state after a TTX-
IDLE-MIN and must meet VTX-CM-DC-ACTIVE-IDLE-DELTA (see
Differential Transmitter (TX) Output Specifications Table 4-5) timeout.
PHY.02.23#01 4.2.6.7 In L1.Entry sub-state, all configured Transmitters must be in Electrical Idle.
In Electrical Idle the DC common mode voltage must be within TTX-IDLE-
SET-TO-IDLE and must meet VTX-CM-DC-ACTIVE-IDLE-DELTA (see
Differential Transmitter (TX) Output Specifications Table 4-5).
PHY.02.24#02 4.2.6.8 In L2.Idle sub-state, all configured Transmitters must remain in Electrical
Idle for a minimum time of TTX-IDLE-MIN (see Differential Transmitter
(TX) Output Specifications Table 4-5).
PHY.02.24#09 4.2.6.8 In L2.Idle sub-state, Receivers must delay a minimum time of TTX-IDLE-
MIN (see Differential Transmitter (TX) Output Specifications Table 4-5)
before looking for Electrical Idle exit.
PHY.02.24#05 4.2.6.8 From L2.Idle sub-state, for Upstream lanes the LTSSM exits to Detect state
if Electrical Idle Exit is detected on any lane. (NOTE: A Switch must
transition any Downstream Lanes to Detect)
PHY.02.24#06 4.2.6.8 In L2.Idle sub-state, for Upstream lanes of an Upstream port, the LTSSM
exits to L2.TransmitWake sub-state if directed to transmit a Beacon.
PHY.02.24#07 4.2.6.8 In L2.TransmitWake sub-state, Upstream Ports shall transmit the Beacon on
at least lane 0. (Support for Beacon may be optional depending on form
factor and the use of WAKE#.)
PHY.02.24#08 4.2.6.8 In L2.TransmitWake sub-state, Upstream ports LTSSM exits to the Detect
state if Electrical Idle exit is detected on any Upstream port's Receiver that
is in the direction of the Root Complex.
PHY.02.24#01 4.2.6.8 In L2.Idle sub-state, all Receiver terminations must remain in low
impedance.
PHY.02.25#01 4.2.6.9 In Disabled state, the Transmitter sends 16 to 32 TS1 ordered sets with the
Disable Link bit asserted on all lanes, and than all lanes send an Electrical
Idle ordered set and go to Electrical Idle.
PHY.02.25#03 4.2.6.9 From Disabled state, the LTSSM exits to Detect if no Electrical Idle ordered
set is received after a 2 msec timeout.
PHY.02.25#04 4.2.6.9 From Disabled state, the LTSSM exits to Detect state (after an Electrical
Idle ordered set was transmitted and received even while transmitting TS1
with the Disable Link bit asserted) if directed to, or if Electrical Idle is
exited.

52
 ENDPOINT COMPLIANCE CHECKLIST FOR THE PCI EXPRESS BASE 1.1 SPECIFICATION,
REVISION 1.1

ID Ref Assertion Y N
PHY.02.25#02 4.2.6.9 In Disabled state, if an Electrical Idle ordered set was transmitted and
received (even while transmitting TS1 with the Disable Link bit asserted)
then set LinkUp = 0.
PHY.02.28#01 4.2.7 The Receiver Physical Layer logical sub-block must include elastic
buffering to compensate for differences in frequencies between bit rates at
the two ends of a link.
PHY.02.28#07 4.2.7.1 Transmitters must ensure that SKP ordered sets do not count as an
interruption when monitoring for consecutive characters or consecutive
ordered sets.
PHY.02.28#13 4.2.7.1 Transmitters must ensure that during all lower power link states (L0s, L1,
L2) any counter(s) or other mechanisms used to schedule the SKP ordered
sets must be reset.
PHY.02.28#11 4.2.7.1 Transmitters must not send SKP ordered sets while the Compliance Pattern
is in progress during Polling.Compliance sub-state.
PHY.02.28#06 4.2.7.1 Transmitters send scheduled SKP ordered sets if a packet or ordered set is
not already in progress, otherwise the scheduled SKP ordered sets are
accumulated and then inserted consecutively at the next packet or ordered
set boundary.
PHY.02.28#05 4.2.7.1 Transmitters must ensure that the SKP ordered sets is scheduled for
insertion at an interval between 1180 and 1538 Symbol Times.
PHY.02.28#04 4.2.7.1 Transmitters sending the SKP ordered set as consisting of one COM
Symbol (Special Symbol K28.5) followed by three consecutive SKP
Symbols (Special Symbol K28.0).
PHY.02.28#03 4.2.7.1 A Transmitter sending SKP ordered set, shall transmit SKP ordered sets
simultaneously on all lanes of a multi-Lane Link (except in the case of
being in LoopBack Slave mode).
PHY.02.28#02 4.2.7.1 All Transmitter lanes must transmit Symbols at the same frequency with 0
ppm difference between bit rates within all multi-lane links.
PHY.02.28#12 4.2.7.1 Transmitters must ensure that any and all time spent in any lower power
link state (L0s, L1, L2) does not count in the 1180 to 1538 Symbol Time
interval used to schedule the transmission of SKP ordered sets.
PHY.02.28#08 4.2.7.2 Receivers shall recognize received SKP ordered sets consisting of one COM
Symbol followed consecutively by one to five SKP Symbols.
PHY.02.28#09 4.2.7.2 Receivers shall be tolerant to receive and process SKP ordered sets at an
average interval between 1180 to 1538 Symbol Times.
PHY.02.28#10 4.2.7.2 Receivers shall be tolerant to receive and process consecutive SKP ordered
sets. Receivers shall be tolerant to receive and process SKP ordered sets
that have a maximum separation dependent on the Max_Payload_Size a
component supports (the formula for the maximum number of Symbols (N)
between SKP ordered sets is: N = 1538 + (Max_payload_size_byte + 26) ).
PHY.02.29#05 4.2.8 Transmitting Compliance Pattern can only be exited when an Electrical Idle
exit is detected on all lanes that detected a Receiver during Detect.
PHY.02.29#01 4.2.8 During Polling state, the Polling.Compliance sub-state must be entered if
passive test equipment is attached to one lane of a possible link and being
detected during Detect state.
PHY.02.29#02 4.2.8 The Compliance Pattern consists of the sequence of 8b/10b symbols: K28.5
(disparity 0), D21.5 (disparity 1), K28.5 (disparity 1), and D10.2 (disparity
0), repeating.
PHY.02.29#04 4.2.8 For any given device that has multiple lanes sending Compliance Pattern,
every eighth lane is delayed by a total of four Symbols. A two Symbol
(K28.5) delay occurs at both the beginning and end of the four Symbol
sequence. After the eight Symbols are sent, the delay Symbols are advanced
to the next lane and the process is repeated.

53
 ENDPOINT COMPLIANCE CHECKLIST FOR THE PCI EXPRESS BASE 1.1 SPECIFICATION,
REVISION 1.1

ID Ref Assertion Y N
PHY.03.01#34 4.3.1 The ports on the two ends of a link must transmit data at a rate that is within
600 ppm of each other at all times.
PHY.03.01#04 4.3.1.1 If Spread Spectrum Clocking is used, both ports must use the same bit rate
clock source.
PHY.03.01#07 4.3.1.4 The Transmitter must meet RLTX-DIFF = 10 dB min, RLTX-CM = 6 dB
min, and ZTX-DIFF-DC = 80R to 120R, 100R nominal (per Differential
Transmitter (TX) Output Specifications Table 4-5) any time functional
differential signals are being transmitted.
PHY.03.01#08 4.3.1.4 The Transmitter must meet only ITX-SHORT = 90 mA max (per
Differential Transmitter (TX) Output Specifications Table 4-5) any time
functional differential signals are not being transmitted.
PHY.03.01#10 4.3.1.4 The Receiver must meet RLRX-DIFF = 10 dB min, RLRX-CM = 6 dB min,
ZRX-DIFF-DC = 80R to 120R, 100R nominal, and ZRX-DC = 40R to 60R,
50R nominal (per Differential Receiver (RX) Input Specifications Table 4-
6) during all LTSSM states except for times when the device is powered
down, Fundamental Reset to the device is asserted, or when otherwise
explicitly specified.
PHY.03.01#09 4.3.1.4 The Receiver must meet ZRX-HIGH-IMP-DC = 200K min (per Differential
Receiver (RX) Input Specifications Table 4-6) any time the device does not
received adequate power, or when otherwise explicitly specified.
PHY.03.01#11 4.3.1.5 The Receiver DC common mode voltage must be nominally 0 V during all
states.
PHY.03.01#12 4.3.1.5 The Transmitter DC common mode voltage (VTX-DC-CM) must be held at
the same value during all states (unless otherwise specified). The allowable
range for VTX-DC-CM = 0 to 3.6 V (per Differential Transmitter (TX)
Output Specifications Table 4-5).
PHY.03.01#13 4.3.1.6 All signal and power pins must withstand 2000 V of ESD using the human
body model and 500 V using the charged device model without damage
(Class 2 per JEDEC JESE22-A114-A).
PHY.03.01#15 4.3.1.7 All Transmitters and Receivers must support surprise hot insertion/removal
without damage to the component.
PHY.03.01#16 4.3.1.7 The Transmitter and Receiver D+ and D- lines must be able to withstand a
sustained short circuit to ground without damage to the component.
PHY.03.01#34 4.3.1.7 The Transmitter short circuit current limit must comply with ITX-SHORT
<= 90mA max (per Differential Transmitter (TX) Output Specifications
Table 4-5).
PHY.03.01#35 4.3.1.8 The Receiver Detection circuit for each lane of a Transmitter must detect
whether a load impedance ZRX-DC = 60R or lower (per Differential
Receiver (RX) Input Specifications Table 4-6), is present on at least one of
the D+ or D- conductors of a differential pair.
PHY.03.01#29 4.3.1.9 After receiving the Electrical Idle ordered set, a Receiver must enable its
Electrical Idle Exit detector within TTX-IDLE-MIN = 50 UI (per
Differential Transmitter (TX) Output Specifications Table 4-5.
PHY.03.01#36 4.3.1.9 The Transmitter must hold its D+ and D- voltages at the same constant
value during Electrical idle.
PHY.03.03#07 4.3.1.9 A Receiver will not detect Electrical Idle exit if a signal smaller than VRX-
IDLE-DET-DIFFp-p = 65 mV (per Differential Receiver (RX) Input
Specifications Table 4-6) is detected at the package pins of the Receiver.
PHY.03.04#08 4.3.1.9 A Receiver will detect Electrical Idle exit if a signal larger than VRX-IDLE-
DET-DIFFp-p = 175 mV (per Differential Receiver (RX) Input
Specifications Table 4-6) is detected at the package pins of the Receiver.
PHY.03.01#37 4.3.1.9 A Receiver must not detect an Electrical Idle if a signal larger than VRX-
IDLE-DET-DIFFp-p = 175 mV (per Differential Receiver (RX) Input
Specifications Table 4-6) is detected at the package pins of the Receiver.

54
 ENDPOINT COMPLIANCE CHECKLIST FOR THE PCI EXPRESS BASE 1.1 SPECIFICATION,
REVISION 1.1

ID Ref Assertion Y N
PHY.03.04#07 4.3.1.9 A Receiver must detect an Electrical Idle if a signal smaller than VRX-
IDLE-DET-DIFFp-p = 65 mV (per Differential Receiver (RX) Input
Specifications Table 4-6) is detected at the package pins of the Receiver.
PHY.03.01#19 4.3.1.9 When transitioning from Electrical Idle to sending differential data, the
Transmitter must meet the output return loss specification (per Differential
Transmitter (TX) Output Specifications Table 4-5) and transition from zero
differential to full differential voltage consistent with the Transmitter
Compliance Eye (per Differential Transmitter (TX) Output Specifications
Table 4-5 or Mobile Graphics Low-Power Addendum to the PCI Express
Base Specification 1.0) within TTX-IDLE-TO-DIFF-DATA = 20 UI (per
Differential Transmitter (TX) Output Specifications Table 4-5) after leaving
Electrical Idle.
PHY.03.01#21 4.3.1.9 The Transmitter can be in either a low or high impedance mode during
Electrical Idle.
PHY.03.01#28 4.3.1.9 After receiving the Electrical Idle ordered set, a Receiver must enter
Electrical Idle.
PHY.03.01#25 4.3.1.9 The low impedance common mode and differential Receiver termination
values must be met in Electrical Idle.
PHY.03.01#22 4.3.1.9 The Receiver detects the successful reception of an Electrical Idle ordered
set upon the receipt of two out of the three IDL Symbols in the transmitted
Electrical Idle ordered set.
PHY.03.01#23 4.3.1.9 Before entering Electrical Idle, a Transmitter must send the Electrical Idle
ordered set, a COM Symbol (Special Symbol K28.5) followed by three IDL
Symbols (Special Symbol K28.3), unless otherwise specified.
PHY.03.01#27 4.3.1.9 Any time a Transmitter enters Electrical Idle it must remain in Electrical
Idle for a minimum of TTX-IDLE-MIN = 50 UI (per Differential
Transmitter (TX) Output Specifications Table 4-5).
PHY.03.01#24 4.3.1.9 After sending the last symbol of the Electrical Idle ordered set the
Transmitter must be in a valid Electrical Idle state within TTX-IDLE-SET-
TO-IDLE = 20 UI (per Differential Transmitter (TX) Output Specifications
Table 4-5).
PHY.03.02#16 4.3.2.2 The allowable Total jitter at the target must meet a maximum BER of 10 **
-12.
PHY.03.02#01 4.3.2.3 De-emphasis must be implemented (except for devices designed only to
Mobile Graphics Low-Power Addendum to the PCI Express Base
Specification 1.0) when multiple bits of the same polarity are output in
succession. Subsequent bits are driven at a differential voltage level 3.5 dB
(+/- 0.5 dB) below the first bit.
PHY.03.02#02 4.3.2.3 The first bit following a polarity transition (with the exception of a Beacon
signal), must be driven between the VTX-DIFFp-p minimum and maximum
(0.8 V and 1.2 V per Differential Transmitter (TX) Output Specifications
Table 4-5, or 0.4V and 1.2V per Mobile Graphics Low-Power Addendum to
the PCI Express Base Specification 1.0).
PHY.03.02#05 4.3.2.4 The Beacon is a DC balanced signal of periodic arbitrary data, which is
required to contain some pulse widths >= 2 nsec but no larger than 16 usec.
PHY.03.02#08 4.3.2.4 The output Beacon voltage level can range between the transition VTX-
DIFFp-p (per Differential Transmitter (TX) Output Specifications Table 4-
5, or per Mobile Graphics Low-Power Addendum to the PCI Express Base
Specification 1.0) and a corresponding -3.5 dB voltage levels for Beacon
pulses smaller than 500 nsec.
PHY.03.02#07 4.3.2.4 The output Beacon voltage level must be at -6 dB de-emphasis level for
Beacon pulses with a width greater than 500 nsec.

55
 ENDPOINT COMPLIANCE CHECKLIST FOR THE PCI EXPRESS BASE 1.1 SPECIFICATION,
REVISION 1.1

ID Ref Assertion Y N
PHY.03.02#04 4.3.2.4 All Beacons must be transmitted and received on at least lane 0 of multi-
lane links (as defined after Link Width and Lane Reversal negotiations are
complete).
PHY.03.02#10 4.3.2.4 Lane-to-Lane Output Skew and SKP ordered set output requirements do not
apply to Beacon signals.
PHY.03.02#12 4.3.2.4 The Beacon signal is transmitted in a low impedance mode.
PHY.03.02#11 4.3.2.4 The Beacon signal must have a maximum time between valid pulses of less
than or equal to 16 usec..
PHY.03.02#18 4.3.2.4 Unless otherwise explicitly specified, all Transmitter electrical
specifications (per Differential Transmitter (TX) Output Specifications
Table 4-5) must be met while sending Beacon.
PHY.03.02#17 4.3.2.4 Downstream components send Beacon signal Upstream towards the Root
Complex, to start the exit from L2 state.
PHY.03.02#03 4.3.2.4 Support for Beacon is required for all ""universal"" PCI Express
components that support a wakeup mechanism in order to function in form
factors that require the use of Beacon (otherwise Beacon is optional).
PHY.03.02#06 4.3.2.4 The Beacon signal's DC balance must be restored within a maximum time
of 32 usec.
PHY.03.03#11 4.3.3 Transmitters must comply with Differential Transmitter (TX) Output
Specifications Table 4-5, of the PCI Express Base Specification 1.1 (or
Mobile Graphics Low-Power Addendum to the PCI Express Base
Specification 1.0).
PHY.03.03#02 4.3.3 Each UI must be 400 psec +/-300ppm (not accounting for SSC dictated
variations).
PHY.03.03#01 4.3.3 Transmitters must meet the Transmitter eye diagram as shown in Minimum
Transmitter Timing and Voltage Output Compliance Specifications Figure
4-24, in the PCI Express Base Specification 1.1 (or Mobile Graphics Low-
Power Addendum to the PCI Express Base Specification 1.0), as measured
at the package pins into the Passive Compliance Test and Measurement
Load.
PHY.03.03#12 4.3.3.3 The PLL used to generate Transmitter output must have a half power corner
frequency response at -3 dB between 1.5MHz and 22MHz, and a maximum
peaking of +3 dB or less across the frequency band from DC to 22 MHz.
PHY.03.04#01 4.3.4.4 Receivers must reliably receive all data that meets the differential receiver
input specifications as shown in Minimum Receiver Eye Timing and
Voltage Compliance Specification Figure 4-26, in the PCI Express Base
Specification 1.1 (or Mobile Graphics Low-Power Addendum to the PCI
Express Base Specification 1.0).
PHY.03.04#14 4.3.4.4 Receivers must comply with Differential Transmitter (RX) Input
Specifications Table 4-6, of the PCI Express Base Specification 1.1 (or
Mobile Graphics Low-Power Addendum to the PCI Express Base
Specification 1.0).
PHY.03.04#15 4.3.4.4 The Receiver must meet ZRX-DIFF-DC and ZRX_DC (per Differential
Transmitter (RX) Input Specifications Table 4-6) on all lanes within 5 msec
of transitioning from Fundamental Reset to LTSSM Detect state.

56
 ENDPOINT COMPLIANCE CHECKLIST FOR THE PCI EXPRESS BASE 1.1 SPECIFICATION,
REVISION 1.1

Explanations:
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
__________________________________________________________
__________________________________________________________
__________________________________________________________
__________________________________________________________
__________________________________________________________
This section should be used to clarify any answers on checklist items above. Please key explanation to item number.

57
 ENDPOINT COMPLIANCE CHECKLIST FOR THE PCI EXPRESS BASE 1.1 SPECIFICATION,
REVISION 1.1

Power Management Checklist

ID Ref Assertion Y N
PMG.01.00#01 5.1 All PCI Express components, except Root Complexes, must meet the
minimum requirements defined by PCI Bus Power Management Interface
Specification Revision 1.2, and the Advanced Configuration and Power
Interface Specification Revision 2.0.
PMG.01.00#02 5.1 Power savings must increase as the Link state transitions from L0 (most
power) through to L3 (least power) including any interim link states that are
supported.
PMG.01.01#02 5.1.1 Active State Link Power Management must be supported by all PCI
Express components (L0s entry is the minimum requirement). Root
Complex Integrated Endpoints do not implement ASPM since they have no
actual link.
PMG.02.00#24 5.2 L2/L3 Ready transition is initiated when the downstream component is put
into a D3 state, before starting to remove power and clocks.
PMG.02.00#31 5.2 All devices must comply to the Summary of PCI Express Link Power
Management States Table 5-1 in the PCI Express Base Specification 1.1.
PMG.02.00#30 5.2 All supported ASPM Lx state transitions must comply to the Link Power
Management State Flow Diagram Figure 5-1 in the PCI Express Base
Specification 1.1.
PMG.02.00#15 5.2 No TLP or DLLP communication is allowed over a link in the L2 state.
PMG.02.00#29 5.2 If in L2 state, all wakeup logic (Beacon or WAKE#) and PME context logic
must use Vaux supply.
PMG.02.00#28 5.2 Optional L2 state requires Vaux supply be provided while main power
supply and reference clocks are off.
PMG.02.00#09 5.2 No TLP or DLLP communication is allowed over a link in the L2/L3
Ready state.
PMG.02.00#27 5.2 The L2/L3 Ready state entry must begin as soon as possible after sending
PME_TO_ACK TLP in response to a received PME_Turn_Off message.
PMG.02.00#26 5.2 A component's link that is in the L2/L3 Ready state must only transition to
L3 state after main power is removed and Vaux supply is not present.
PMG.02.00#25 5.2 A component in the L2/L3 Ready state must be ready to allow the removal
of power and reference clock.
PMG.02.00#08 5.2 The L2/L3 Ready transition protocol must be supported.
PMG.02.00#05 5.2 All components supporting PCI-PM compatible power management must
support the L1 state.
PMG.02.00#01 5.2 All PCI Express components must support the L0 active state.
PMG.02.00#02 5.2 All main power supplies, component reference clocks, and components'
internal PLLs must be active at all times during L0s.
PMG.02.00#10 5.2 A component's link that is in the L2/L3 Ready state must only transition to
L2 state after main power is removed and Vaux supply is present.
PMG.02.00#20 5.2 A port's transmitter goes to the L0s state, even if the same port's receiver is
in the L0 state.
PMG.02.00#04 5.2 No TLP or DLLP communication is allowed over a link in the L1 state.
PMG.02.00#21 5.2 If required by a particular form factor, ASPM L1 must be supported.
Otherwise ASPM L1 support is optional.
PMG.02.00#06 5.2 All platform provided main power supplies and component reference
clocks must remain active at all times during L1.

58
 ENDPOINT COMPLIANCE CHECKLIST FOR THE PCI EXPRESS BASE 1.1 SPECIFICATION,
REVISION 1.1

ID Ref Assertion Y N
PMG.02.00#07 5.2 If supported, both sides of the link must enter the L1 state when all
functions of a downstream component on the link are programmed to a Dx
state other than D0.
PMG.02.00#22 5.2 Both sides of the link must enter the L1 state when the downstream
component on the link requests ASPM L1 entry and receives a positive PM
acknowledgement.
PMG.02.00#23 5.2 Either side of the link can initiate an exit from L1 state.
PMG.02.00#03 5.2 No TLP or DLLP communication is allowed through a transmitter in the
L0s state.
PMG.03.01#01 5.3.1 PCI Express functions must support D0, D3-hot, and D3-cold states.
PMG.03.02#01 5.3.1.1 When a PCI Express function is initially powered on it must default to the
D0-unitialized state.
PMG.03.02#05 5.3.1.1 A function in the D0-active state must be in its fully operational PCI
Express state.
PMG.03.02#02 5.3.1.1 A function must enter the D0-active state whenever any of the Memory
Space Enable bit, I/O Space Enable bit, or Bus Master Enable bit in the
Command register has been set.
PMG.03.03#03 5.3.1.2 A function's software driver must ensure that any outstanding TLPs (still
awaiting completion) issued by the function must be terminated before it
can pass control to system software that will complete the transition to D1.
PMG.03.03#01 5.3.1.2 While in the D1 state all received configuration and message requests must
be processed normally. All other received requests must be handled as
unsupported requests by a function in the D1 state. (Received completions
may optionally be handled as unexpe
PMG.03.03#02 5.3.1.2 A function must not initiate any request TLPs while in the D1 state except
the PME message.
PMG.03.03#05 5.3.1.2 If an error caused by an event other than a received TLP is detected while
in the D1 state and error reporting is enabled, the device must send an error
message when it is programmed back to the D0 state.
PMG.03.03#04 5.3.1.2 If an error caused by a received TLP is detected while in the D1 state and
error reporting is enabled, then the link must be returned to the L0 state (if
not already there) and an error message sent.
PMG.03.04#01 5.3.1.3 A function must not initiate any request TLPs while in the D2 state except
the PME message.
PMG.03.04#02 5.3.1.3 While in the D2 state all received configuration and message requests must
be processed normally. All other received requests must be handled as
unsupported requests by a function in the D2 state. (Received completions
may optionally be handled as unexpe
PMG.03.04#04 5.3.1.3 If an error caused by a received TLP is detected while in the D2 state and
error reporting is enabled, then the link must be returned to the L0 state (if
not already there) and an error message sent.
PMG.03.04#05 5.3.1.3 If an error caused by an event other than a received TLP is detected while
in the D2 state and error reporting is enabled, the device must send an error
message when it is programmed back to the D0 state.
PMG.03.04#03 5.3.1.3 A function's software driver must ensure that any outstanding TLPs (still
awaiting completion) issued by the function must be terminated before it
can pass control to system software that will complete the transition to D2.
PMG.03.05#01 5.3.1.4 If a function supports PME generation from D3 state it must support it for
both D3-cold and D3-hot states.
PMG.03.05#04 5.3.1.4 If a function's No Soft Reset bit in the Power Management Control/Status
register returns 1, than the function must maintain functional context while
in D3-hot state.

59
 ENDPOINT COMPLIANCE CHECKLIST FOR THE PCI EXPRESS BASE 1.1 SPECIFICATION,
REVISION 1.1

ID Ref Assertion Y N
PMG.03.05#05 5.3.1.4 If a function's No Soft Reset bit in the Power Management Control/Status
register returns 1, than the function must transition from D3-hot to D0-
initialized state when directed to. It must not rely on any software re-
initialization being performed upon r
PMG.03.05#02 5.3.1.4 A function must be able to accept accesses from software within 10 msec of
a D3-hot to D0 transition for that function.
PMG.03.06#02 5.3.1.4.1 A function's software driver must ensure that any outstanding TLPs (still
awaiting completion) issued by the function must be terminated before it
can pass control to system software that will complete the transition to D3-
hot.
PMG.03.06#07 5.3.1.4.1 A function in D3-cold state returns to D0-uninitialized after return of main
power and associated cold reset.
PMG.03.06#03 5.3.1.4.1 Functions in the D3-hot state must transition to the D0 state when software
writes to the function's PMCSR register Power State field to D0. The
function will transition to D0-uninitialized (if No Soft Reset bit returns 0),
or D0-initialized (if No Soft
PMG.03.06#04 5.3.1.4.1 If an error caused by a received TLP is detected while in the D3-hot state
and error reporting is enabled, then the link must be returned to the L0 state
(if not already there) and an error message sent.
PMG.03.06#01 5.3.1.4.1 While in the D3-hot state all received configuration and message requests
must be processed normally. All other received requests must be handled
as unsupported requests by a function in the D3-hot state. (Received
completions may optionally be handled a
PMG.03.06#05 5.3.1.4.1 If an error caused by an event other than a received TLP is detected while
in the D3-hot state and error reporting is enabled, the device must not send
any error message (sending the message is optional) until it is programmed
back to the D0 state.
PMG.03.06#06 5.3.1.4.1 A function must transition to D3-cold when its main power is removed.
PMG.03.07#01 5.3.1.4.2 A function that supports wakeup from D3-cold must maintain the full PME
context (including the Power Management Status/Control register).
PMG.03.07#02 5.3.1.4.2 A function must use only Vaux power source to support PME event
detection, link reactivation, and preservation of PME context from D3-cold
state. It must only use Vaux power source when enabled to do so.
PMG.03.07#03 5.3.1.4.2 A function asserting a wake up event through PME must send a PME
message to the Root, once the link is up. Devices on the hierarchy path
between the asserting function and the Root, must propagate the PME
message towards the root, once their links are up.
PMG.03.08#15 5.3.2 The power management state of a link is determined by the Dx state of its
Downstream component.
PMG.03.08#12 5.3.2 If a Switch or single function Endpoint device has its Upstream port
transitioned to D1, D2, or D3-hot it must initiate a Link state transition of
its Upstream port to L1.
PMG.03.08#11 5.3.2 In any Dx state, when a Downstream component has completed the
PM_Turn_Off/PME_TO_ACK handshake it must request a link transition
to L2/L3 Ready using the PM_ENTER_L23 DLLP.
PMG.03.08#17 5.3.2 Devices in D0, D1, D2, or D3-hot state must respond to receipt of
PME_Turn_Off message by sending PME_TO_Ack message.
PMG.03.08#09 5.3.2 If a Downstream component is in the D3-cold state and its Upstream
component is in D0, D1, D2, D3-hot, or D3-cold state, the link state must
only be in L2 or L3.
PMG.03.08#08 5.3.2 If a Downstream component is in the D3-hot state and its Upstream
component is in D0, D1, D2, or D3-hot state, the link state must only be L1
or L2/L3 Ready.

60
 ENDPOINT COMPLIANCE CHECKLIST FOR THE PCI EXPRESS BASE 1.1 SPECIFICATION,
REVISION 1.1

ID Ref Assertion Y N
PMG.03.08#06 5.3.2 If a Downstream component is in the D2 state and its Upstream component
is in D0, D1, or D2 state, the link state must only be L1 or L2/L3 Ready.
PMG.03.08#02 5.3.2 If both a Downstream component and its Upstream component are in D0
state, the link state must only be L0, L0s, L1 or L2/L3 Ready.
PMG.03.08#13 5.3.2 A multi-function Endpoint must not initiate a Link state transaction to L1
until all of its functions have been programmed to a non-D0 state.
PMG.03.08#04 5.3.2 If a Downstream component is in the D0 state and its Upstream component
is in D0 or D1 state, the link state must only be L1 or L2/L3 Ready.
PMG.03.09#02 5.3.2.1 Once an acknowledgement for the PMCSR write completion and all other
outstanding TLPs are completed, then the Downstream component must
transmit a PM_Enter_L1_DLLP onto its Upstream directed port. The
Downstream component must first ensure that it has re
PMG.03.09#03 5.3.2.1 Once a Downstream component sends a PM_Enter_L1_DLLP it must
continue to send it repeatedly until a response from the Upstream
component is received. The DLLPs are transmitted with no more than 4
symbol times of idle between subsequent transmissions of PM
PMG.03.09#08 5.3.2.1 Even while transmitting PM_Enter_L1 DLLPs, the Downstream
component must continue to accept TLPs and DLLPs from the Upstream
component. The Downstream component must continue to respond with all
DLLPs required by the received traffic.
PMG.03.09#10 5.3.2.1 The Downstream component must store any blocked TLPs for later
transmission. Any stored TLPs must cause the Downstream component to
initiate an Exit from L1 as soon as possible following L1 entry.
PMG.03.09#06 5.3.2.1 When a Downstream component receives a PM_Request_Ack DLLP on its
receive lanes it must stop sending all DLLPs and disable its Link layer by
sending one electrical idle ordered set and bringing its transmit lanes to
electrical idle state.
PMG.03.09#09 5.3.2.1 Once both ends of a link are in the L1 state (as the result of the
Downstream component being program to a non-D0 state), both
components must suspend the operation of counters for: Flow Control
Updates, TLP Completion Timeout, and Update FCP Timer (if im
PMG.03.09#01 5.3.2.1 A Downstream component must suspend all new TLP scheduling and
schedule a completion response corresponding to a configuration write to
the PMCSR field when it receives a TLP request that transitions the device
to D1, D2, or D3-hot. The downstream compon
PMG.03.10#03 5.3.2.2 Either side of a link can initiate exit from L1. A component must initiate
exit from L1 if it needs to transmit a TLP.
PMG.03.11#01 5.3.2.3 A Downstream component must not send PM_Enter_L23 DLLP until it has
completed all actions required to prepare it to lose power.
PMG.03.11#03 5.3.2.3 Once a Downstream component sends a PM_Enter_L23 DLLP it must
continue to send it repeatedly until a response from the Upstream
component is received or until power is removed. The DLLPs are
transmitted with no more than 4 symbol times of idle between sub
PMG.03.11#06 5.3.2.3 When a Downstream component receives a PM_Request_Ack DLLP on its
receive lanes it must stop sending all DLLPs and disable its Link layer by
sending one electrical idle ordered set and bringing its transmit lanes to
electrical idle state.
PMG.03.12#07 5.3.3.2 A component that asserts WAKE# must continue to assert it until main
power has been restored as indicated by Fundamental Reset going inactive.
PMG.03.12#10 5.3.3.2 An Endpoint must not use WAKE# as an input signal.
PMG.03.12#04 5.3.3.2 If required by the relevant form factor specifications, WAKE# must be
implemented. For these form factors, a device generating Beacon must be
tolerated, though it is not required to observe the Beacon.

61
 ENDPOINT COMPLIANCE CHECKLIST FOR THE PCI EXPRESS BASE 1.1 SPECIFICATION,
REVISION 1.1

ID Ref Assertion Y N
PMG.03.12#06 5.3.3.2 Components that support wakeup functionality must support Beacon,
unless they are designed exclusively for the following form factors: PCI
Express Card Electromechanical Specification, or PCI Express Mini Card
Electromechanical Specification.
PMG.03.13#02 5.3.3.2.1 When a PME_Turn_Off message is received, a Downstream component
must respond with a PME_TO_Ack message, regardless of what Dx state
the device or any of its functions are in.
PMG.03.13#04 5.3.3.2.1 After an Endpoint sends a PME_TO_Ack message, in response to a
PME_Turn_Off message, it must begin to initiate the transition to L2/L3
Ready state.
PMG.03.13#08 5.3.3.2.1 The device that requests wakeup must send PM_PME message to the Root
Complex one the link has been re-activated and trained.
PMG.03.14#03 5.3.3.3.1 If an agent sends a PM_PME message and its PME_Status bit has not been
cleared after 100 ms (+50% / -5%), it must re-send the PM_PME message
(waking up its link if necessary).
PMG.03.15#04 5.3.3.4 When a function initiates Link wakeup or issues a PM_PME message it
must set the PME_Status bit.
PMG.03.15#05 5.3.3.4 After receiving a PME_Turn_Off message, the device must block
transmission of any of it's PM_PME messages and transmit a
PME_TO_Ack message upstream. The component is permitted to transmit
a PM_PME message after the link has returned to the L0 state thr
PMG.03.15#02 5.3.3.4 PME capable functions must implement the PME_Status bit and related
behavior in their PMCSR configuration register.
PMG.03.15#06 5.3.3.4 Before a link or portion of hierarchy is blocked from sending PM_PME
messages, a PME_Turn_Off message must be broadcast to all Downstream
devices.
PMG.03.17#01 5.3.3.5 A device capable of generating PME must follow the Control State
Machine shown in a conceptual PME Control State Machine Figure 5-5 of
the PCI Express Base Specification 1.1.
PMG.04.01#10 5.4.1 For a multi-function Endpoint, if a least one function that is in the D0 state
has its ASPM Control field set to enable L0s only, and at least one other
function that is in the D0 state has its ASPM Control field set to enable L1
only, than ASPM is disabl
PMG.04.01#12 5.4.1 Multi-function Endpoints must be able to dynamically change their ASPM
policy at runtime, based on each function's current Dx-state and each
functions' current setting for ASPM Control field.
PMG.04.01#05 5.4.1 For a multi-function Endpoint, if all functions that are in the D0 state have
their ASPM Control field set to enable both L0s and L1, than ASPM is
enabled for both L0s and L1 for the entire device.
PMG.04.01#03 5.4.1 For a multi-function Endpoint, if any functions that are in the D0 state has
its ASPM Control field set to disabled, than ASPM is disabled for the entire
device.
PMG.04.01#04 5.4.1 For a multi-function Endpoint, if at least one function that is in the D0 state
has its ASPM Control field set to enable L0s only, and none of the other
functions that are in the D0 state have their ASPM Control field set to
disable L0s, than ASPM is enab
PMG.04.01#08 5.4.1 All Endpoints must report the worst-case L0s and L1 latency they can
tolerate in the Endpoint L0s Acceptable Latency and Endpoint L1
Acceptable Latency fields of the Device Capabilities register.
PMG.04.01#09 5.4.1 For a multi-function Endpoint, any function in a non-D0 state is ignored
when determining the device's ASPM state.
PMG.04.01#07 5.4.1 All PCI Express components must report their L0s and L1 exit latency in
the L0s Exit Latency and L1 Exit Latency fields of the Link Capabilities
register.

62
 ENDPOINT COMPLIANCE CHECKLIST FOR THE PCI EXPRESS BASE 1.1 SPECIFICATION,
REVISION 1.1

ID Ref Assertion Y N
PMG.04.01#06 5.4.1 All PCI Express components must report their level of ASPM Support in
the ASPM Support field of the Link Capabilities register.
PMG.04.01#02 5.4.1 All PCI Express components must support the L0s state from within the D0
state.
PMG.04.01#01 5.4.1 If the L0s state is enabled in a device it must bring any transmit link into
the L0s state whenever that Link is not in use.
PMG.04.01#11 5.4.1 For a multi-function Endpoint, if at least one function that is in the D0 state
has its ASPM Control field set to enable L1 only, and none of the other
functions that are in the D0 state have their ASPM Control field set to
disable L1, than ASPM is enable
PMG.04.02#02 5.4.1.1 Transaction Layer and Link Layer timers must not be affected by the
transition to the L0s state.
PMG.04.03#01 5.4.1.1.1 A device port not enabled for L0s must be able to tolerate having its
receiver lanes enter the L0s state and return to the L0 state.
PMG.04.03#02 5.4.1.1.1 A port enabled for L0s must transition its transmit lanes to the L0s state, if
all the following idle conditions are met for a period of time not exceeding
7 usec: No TLP (that has available FC credit) is waiting to be transmitted;
No DLLPs are waiting to
PMG.04.04#01 5.4.1.1.2 A lack of FC credits must not prevent a link from transitioning from L0s
state to L0 state.
PMG.04.04#04 5.4.1.1.2 A device port's transmitter lanes must initiate L0s exit when it has a TLP or
DLLP to send.
PMG.04.05#08 5.4.1.2.1 A Downstream component, while repeatedly sending
PM_Active_State_Request_L1 DLLPs must not initiate any TLP transfers.
PMG.04.05#16 5.4.1.2.1 The Transaction Layer completion timeout mechanism must not be affected
by going to the ASPM L1 state. It must still continue counting while in L1
and a Completion is outstanding.
PMG.04.05#13 5.4.1.2.1 When the Downstream component receives a PM_Request_Ack DLLP (in
response to its PM_Active_State_Request_L1 DLLP) it must cease sending
all DLLPs, disable DLLP and TLP transmission, send an electrical idle
ordered set, and then bring its transmit lanes in
PMG.04.05#21 5.4.1.2.1 A Downstream component that receives a PM_Active_State_Nak message
in response to a PM_Active_State_Request_L1 DLLP that it transmitted,
must stop sending PM_Active_State_Request_L1 DLLP for at least 10
usec, except in the case where it successfully trans
PMG.04.05#01 5.4.1.2.1 A Downstream component that receives a PM_Active_State_Nak message
in response to a PM_Active_State_Request_L1 DLLP that it transmitted,
must stop sending PM_Active_State_Request_L1 DLLP and immediately
attempt to transition its transmit lanes to L0s stat
PMG.04.05#17 5.4.1.2.1 Flow Control update timers must be frozen while in L1 state. Periodically
scheduled UpdateFCs will not occur while in L1 state.
PMG.04.05#07 5.4.1.2.1 A Downstream component that sent a PM_Active_State_Request_L1
DLLP on its transmit lines must send it repeatedly until a response is
received. These DLLPs must have no more than 4 symbol times of idle
between transmissions, not counting other DLLPs and S
PMG.04.05#05 5.4.1.2.1 A Downstream component must block movement of TLPs from the
Transaction Layer to the Data Layer (it must not transmit any new TLPs)
and it must wait until an acknowledgement is sent for the last TLP already
sent (its Retry Buffer must be empty) before sen
PMG.04.05#04 5.4.1.2.1 A Downstream component must not initiate ASPM L1 entry until it
accumulates at least the minimum number of credits required to send the
largest possible packet for any FC type.
PMG.04.05#18 5.4.1.2.1 If L1 is supported, L1 must be disabled by default in the ASPM Control
field of the Link Control register.

63
 ENDPOINT COMPLIANCE CHECKLIST FOR THE PCI EXPRESS BASE 1.1 SPECIFICATION,
REVISION 1.1

ID Ref Assertion Y N
PMG.04.05#09 5.4.1.2.1 A Downstream component while repeatedly sending
PM_Active_State_Request_L1 DLLPs must accept TLPs (storing for later
transmission any TLP responses required) and DLLPs from an Upstream
component, and must respond with DLLPs (including UpdateFC DLLPs) as
r
PMG.04.05#20 5.4.1.2.1 A Downstream component that needs to send a TLP while repeatedly
sending PM_Active_State_Request_L1 DLLPs must complete the L1
negotiation first, than transition to a lower power link state (if allowed to).
Once in the lower power link state (if allowed
PMG.04.07#02 5.4.1.3 A component must only issue PM_Active_State_Request_L1 DLLPs when
ASPM Control field has L1 Entry enabled.
PMG.04.07#03 5.4.1.3 A port's transmitter must only bring the port to L0s state if all L0s entry
conditions are met and ASPM Control field has L0s Entry enabled.
PMG.05.01#05 5.5.1 PCI Express functions that require Vaux power while running Legacy PCI-
PM software, must set PME Support field to non-zero, and have PME
Enable bit in the Power Management Status and Control register as R/W.
PMG.05.01#03 5.5.1 PCI Express functions that require Vaux power, but don't support PME,
must implement the Aux Power PM Enable bit in the Device Control
register as R/W.
PMG.05.01#04 5.5.1 PCI Express functions that require Vaux power, must set the Aux Current
field in the Power Management Status and Control register to a non-zero
value.
PMG.06.00#05 5.6 The traffic class field for all Power Management System messages must
use the default class (TC0).
PMG.06.00#01 5.6 The length field must be reserved in all Power Management System
messages.
PMG.06.00#02 5.6 The attribute field must be all zeroes in all Power Management System
messages.
PMG.06.00#06 5.6 The address field must be reserved in all Power Management System
messages.
PMG.06.00#04 5.6 For PM_PME messages, Endpoints must report in the Requester ID field
their Upstream link bus number and the device and function number where
the PME originated.
PMG.06.00#03 5.6 For all Power Management system messages except PM_PME, all devices
must report in the requestor ID field their actual Upstream link bus number
and device number, while the function number must be zero.

64
 ENDPOINT COMPLIANCE CHECKLIST FOR THE PCI EXPRESS BASE 1.1 SPECIFICATION,
REVISION 1.1

Explanations:
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
__________________________________________________________
__________________________________________________________
__________________________________________________________
__________________________________________________________
__________________________________________________________
This section should be used to clarify any answers on checklist items above. Please key explanation to item number.

65
 ENDPOINT COMPLIANCE CHECKLIST FOR THE PCI EXPRESS BASE 1.1 SPECIFICATION,
REVISION 1.1

System Architecture Checklist

ID Ref Assertion Y N
SYS.01.02#01 6.1 PCI Express devices that generate interrupts must also support either MSI
or MSI-X interrupts.
SYS.01.01#06 6.1 PCI Express devices that generate MSI or MSI-X interrupts must comply
to the PCI Local Bus Specification 3.0.
SYS.01.01#04 6.1 PCI Express devices that generate interrupts must support INTx emulation
for legacy compatibility.
SYS.01.05#01 6.1.1 PCI Express devices that generate interrupts must be able to differentiate
between INTx and MSI/MSI-X modes of operation.
SYS.01.01#02 6.1.2 PCI Express devices must use assert/de-assert INTx messages in pairs to
emulate PCI interrupt level-triggered signaling. Multiple asserts (without
an intervening deassert) and multiple deasserts (without an intervening
assert) are allowed but have no affect after the first message.
SYS.01.01#07 6.1.2 Legacy INTx interrupts only support level-triggered interrupts.
SYS.01.01#05 6.1.2 INTx emulation messages must use TC0.
SYS.01.02#05 6.1.4 MSI/MSI-X interrupts only support edge-triggered interrupts.
SYS.01.02#04 6.1.4 All non-legacy PCI Express Endpoint devices that produce interrupts must
support the 64 bit version of the MSI or MSI-X capability structure.
SYS.01.02#03 6.1.4 MSI/MSI-X transactions must have the No Snoop and Relaxed Ordering
attributes of the Transaction Descriptor set to 0.
SYS.01.02#06 6.1.4 Devices that generate MSI/MSI-X with more than one TCx must ensure
proper synchronization between data traffic and interrupt traffic using a
different TCx.
SYS.02.01#01 6.2.1 All PCI Express devices must support baseline (everything besides
advanced error reporting capability) PCI Express error reporting
mechanisms.
SYS.02.01#05 6.2.3.2 At least one error message must be sent for each severity level of error
detected (unless additional severity levels are precluded by the given error
type).
SYS.02.02#05 6.2.3.2.2 Error status bits are updated regardless of the setting of Device Control
Error Reporting Enable, SERR# Enable, or the Advanced Error Reporting
mask bits.
SYS.02.02#04 6.2.3.2.2 If Advanced Error Reporting is supported, then Advanced Error Reporting
mask bits must prevent the update of Header Log and First Error Pointer
registers for an error of the masked type. If Device Control register
enables the error group, or SERR# Enable bit is 1 for the error type, than
the mask bit being set must also block the error message from being sent
for the masked error.
SYS.02.02#03 6.2.3.2.2 If the Device Control register Fatal Error Reporting Enable bit is zero and
SERR# Enable bit is 0 the device must not send in band ERR_FATAL
messages regardless of advanced error reporting settings.
SYS.02.02#01 6.2.3.2.2 If the Device Control register Correctable Error Reporting Enable bit is
zero the device must not send in band ERR_COR messages regardless of
advanced error reporting settings.
SYS.02.02#02 6.2.3.2.2 If the Device Control register Non-Fatal Error Reporting Enable bit is
zero and SERR# Enable bit is 0 the device must not send in band
ERR_NONFATAL messages regardless of advanced error reporting
settings.
SYS.02.03#01 6.2.3.2.3 Once a particular packet has an error associated additional errors on the
same packet must not be reported by higher layers.

66
 ENDPOINT COMPLIANCE CHECKLIST FOR THE PCI EXPRESS BASE 1.1 SPECIFICATION,
REVISION 1.1

ID Ref Assertion Y N
SYS.02.03#02 6.2.3.2.3 For transaction layer errors, it is permitted to only report a single error as
long as the following precedence (highest to lowest) is used: 1) Receiver
Overflow; 2) Flow Control Protocol Error; 3) ECRC Check Failed; 4)
Malformed TLP; 5) Unsupported Request, Completer Abort, or
Unexpected Completion; 6) Poisoned TLP Received.
SYS.02.10#01 6.2.3.2.4.1 A device that implements AER, must send an ERR_COR message when it
detects an Advisory Non-Fatal Error case.
SYS.02.10#02 6.2.3.2.4.1 A device that does not implement AER, must not send error messages for
Advisory Non-Fatal Error cases.
SYS.02.12#01 6.2.3.2.4.4 If a requester of a non-posted request times out (completion timeout), it
must treat the error as Non-Fatal Advisory type, only if it is making an
attempt to retry the request. This applies even if the retry of the request is
not successful.
SYS.02.12#02 6.2.3.2.4.4 If a requester of a non-posted request times out (completion timeout), it
must signal the error (if enabled) as uncorrectable if it is not making any
further attempt to retry the request.
SYS.02.13#01 6.2.3.2.4.5 The Receiver of an unexpected Completion (if non-fatal), must handle this
as an Advisory Non-Fatal Error.
SYS.02.14#01 6.2.3.2.5 A Requester that receives completion with UR/CA status, must not report
this error using PCI Express error logging or error messages. It if must
report the error, is can only use a requester-specific mechanism.
SYS.02.04#01 6.2.4 In a multi-function device, all errors that are not specific to a single
function on the device must be logged to the corresponding status and
logging registers for all functions on the device. Non function-specific
errors are: all physical layer errors; all data link layer errors; ECRC Fail,
Unsupported Request caused by no function claiming a TLP, Receiver
Overflow, Flow Control Protocol Error, Malformed TLP.
SYS.02.04#03 6.2.4 A multi-function device must only send one error message for the same
non function specific error if the error is mapped to the same severity
levels for each function that is enabled to report that error. If functions
enabled to report the error do not have the same severity level, than one
error message per severity level must be sent.
SYS.02.04#02 6.2.4 If a non function specific error occurs within a multi-function device, the
device must send an error message for the error if any of its functions are
enabled to report the specific error. The Requester ID field in the error
message must indicate one of the functions within the device that is
enabled to report the specific error.
SYS.02.06#04 6.2.4.2 If AER is implemented, bits in the Uncorrectable Error Status register and
Correctable Error Status register must remain set until explicitly cleared
by software. When AUX power is used, the bits must not be cleared by
reset being applied.
SYS.02.06#01 6.2.4.2 If AER is implemented, the First Error Pointer register must record an
unmasked uncorrectable error when it occurs if the First Error Pointer
register is currently invalid.
SYS.02.06#02 6.2.4.2 If AER is implemented, the First Error Pointer register is valid when the
corresponding bit of the Uncorrectable Error Status register is set. The
First Error Pointer value is not meaningful when the corresponding bit of
the Uncorrectable Error Status register is not set, or is an unimplemented
or undefined bit.
SYS.02.06#05 6.2.4.2 If AER is implemented, the Header Log register must record the header of
the TLP that caused the First Error Pointer register to be set (if the error
type requires header logging).
SYS.02.06#03 6.2.4.2 If AER is implemented, the Header Log register must be valid when the
First Error Pointer is valid (if the error type requires header logging).

67
 ENDPOINT COMPLIANCE CHECKLIST FOR THE PCI EXPRESS BASE 1.1 SPECIFICATION,
REVISION 1.1

ID Ref Assertion Y N
SYS.02.16#02 6.2.4.3 The Advisory Non-Fatal Error Status bit must be set when an advisory
error occurs.
SYS.02.16#03 6.2.4.3 The Uncorrectable Error Status register bit is set only if the Advisory
Non-Fatal Error Mask bit is clear when an advisory error occurs. This
will update the First Error Pointer and the Header Log if required.
SYS.02.16#01 6.2.4.3 If the Uncorrectable Error Severity register indicates an error type to be
fatal, than the error type cannot be treated as Advisory Non-Fatal error
type.
SYS.02.16#04 6.2.4.3 If the Correctable Error Reporting Enable bit is set in Device Control
Register, an ERR_COR message will be sent when an advisory error
occurs.
SYS.02.17#01 6.2.5 Error signaling and logging must follow the flowchart shown in Flowchart
Showing Sequence of Device Error Signaling and Logging Operations
Figure 6-3 of the PCI Express Base Specification 1.1.
SYS.02.07#01 6.2.7 If a physical layer Receiver Error occurs the receiver must send
ERR_COR to the root complex if enabled.
SYS.02.07#09 6.2.7 If a transaction layer ECRC Check Failed error occurs, the receiver (if
checking) must send an ERR_NONFATAL/ERR_FATAL (depending on
severity setting) or ERR_COR (if this is treated as Advisory Non-Fatal
error type) to the root complex if enabled. The header of the TLP with the
bad ECRC is logged.
SYS.02.07#13 6.2.7 If a transaction layer Unexpected Completion error occurs, the receiver
must send an ERR_COR (this is treated as Advisory Non-Fatal error type)
to the root complex if enabled. The header of the unexpected completion
TLP is logged.
SYS.02.07#14 6.2.7 If a transaction layer Receiver Overflow error occurs, the receiver (if
checking) must send an ERR_FATAL/ERR_NONFATAL (depending on
severity setting) to the root complex if enabled.
SYS.02.07#26 6.2.7 If a transaction layer Completer Abort error occurs, the completer that
sent the CA must send an ERR_NONFATAL/ERR_FATAL (depending
on severity setting) or ERR_COR (if this is treated as Advisory Non-Fatal
error type) to the root complex if enabled. The header of the TLP request
that generated the CA error is logged.
SYS.02.07#11 6.2.7 If a transaction layer Completion Timeout error occurs, the requester that
times out must send an ERR_NONFATAL/ERR_FATAL (depending on
severity setting) or ERR_COR (if this is treated as Advisory Non-Fatal
error type) to the root complex if enabled.
SYS.02.07#10 6.2.7 If a transaction layer Unsupported Request error occurs, the Requester
that receives the UR must send an ERR_NONFATAL/ERR_FATAL
(depending on severity setting) or ERR_COR (if this is treated as
Advisory Non-Fatal error type) to the root complex if enabled. The
header of the TLP request that generated the UR error is logged. NOTE:
enabling unsupported request error messages is controlled by the Device
Control register Unsupported Request Reporting Enable bit. No error
messages for unsupported request errors may be sent if this bit is not set.
SYS.02.07#08 6.2.7 If a transaction layer Poisoned TLP Received error occurs, the receiver
must send ERR_NONFATAL/ERR_FATAL (depending on severity
setting) or ERR_COR (if this is treated as Advisory Non-Fatal error type)
to the root complex if enabled. The header of the poisoned TLP is logged.
SYS.02.07#25 6.2.7 If a data link layer Surprise Down error occurs, the component (if
checking) must send ERR_FATAL/ERR_NONFATAL (depending on
severity setting) to the root complex if enabled.

68
 ENDPOINT COMPLIANCE CHECKLIST FOR THE PCI EXPRESS BASE 1.1 SPECIFICATION,
REVISION 1.1

ID Ref Assertion Y N
SYS.02.07#17 6.2.7 If a Data Link Layer Protocol Error occurs, the component (if checking)
must send ERR_FATAL/ERR_NONFATAL (depending on severity
setting) to the root complex if enabled.
SYS.02.07#07 6.2.7 If a data link layer REPLY NUM Rollover error occurs, the transmitter
must send ERR_COR to the root complex if enabled.
SYS.02.07#06 6.2.7 If a data link layer Replay Timeout error occurs, the transmitter must send
ERR_COR to the root complex if enabled.
SYS.02.07#04 6.2.7 If a data link layer Bad TLP error occurs, the receiver must send
ERR_COR to the root complex if enabled.
SYS.02.07#24 6.2.7 If a received non-posted request is an unsupported request, a completion
with unsupported request status must be returned regardless of the
unsupported request error reporting settings. Devices will not send an
error message if both Unsupported Request Reporting Enable and
Correctable Error Reporting enable bits are clear (regardless of the setting
of SERR# Enable).
SYS.02.07#05 6.2.7 If a data link layer Bad DLLP error occurs, the receiver must send
ERR_COR to the root complex if enabled.
SYS.02.07#15 6.2.7 If a transaction layer Flow Control Protocol Error occurs, the receiver (if
checking) must send an ERR_FATAL/ERR_NONFATAL (depending on
severity setting) to the root complex if enabled.
SYS.02.07#27 6.2.7 If a received posted request is an unsupported request the device will send
an ERR_NONFATAL message if SERR# Enable is set, even when both
Unsupported Request Reporting Enable and Correctable Error Reporting
enable bits are clear.
SYS.02.07#16 6.2.7 If a transaction layer Malformed TLP error occurs, the receiver must send
an ERR_FATAL/ERR_NONFATAL (depending on severity setting) to
the root complex if enabled. The header of the malformed TLP is logged.
SYS.02.08#01 6.2.7.1 PCI Express errors must trigger the corresponding PCI Status register bits
to be set.
SYS.02.08#02 6.2.7.1 Clearing bits in the PCI Status registers must not affect PCI Express AER
registers.
SYS.02.08#03 6.2.7.1 Clearing bits in the PCI Express AER registers must not affect PCI Status
registers.
SYS.02.08#04 6.2.7.1 Some PCI Command register bits control PCI error reporting.
SYS.02.08#05 6.2.7.1 PCI Command register bits does not affect the setting of PCI Express
AER register bits.
SYS.03.01#02 6.3.2 Every port must support the TC0/VC0 pair.
SYS.03.01#03 6.3.2 The receiving port must treat any TLP that does not contain a TC label
that is mapped to an enabled VC resource as a Malformed TLP.
SYS.03.02#04 6.3.3.1 The device must arbitrate transactions arriving at different Ingress ports,
that target the same VC in the Egress port before they can be forwarded to
the resource. This uses Port Arbitration scheme.
SYS.03.04#02 6.3.4.2 If isochronous traffic targets the Root complex and the RCRB indicates it
requires the No Snoop attribute bit to be set in order to meet isochronous
bandwidth and latency requirements (ie. Root sets the Reject Snoop
Transactions field), then the No Snoop bit must be set in all TLP headers
for isochronous traffic.
SYS.03.04#01 6.3.4.2 A requester of isochronous services must never issue a request with a
value in Length field that exceeds Max_Payload_Size.
SYS.03.05#03 6.3.4.3 A completer must meet the maximum isochronous transaction latency.
SYS.03.05#01 6.3.4.3 Under normal operating conditions (when delays are not induced by other
parts of the system), a completer must not apply backpressure due to flow
control to isochronous requests injected to the PCI Express link.

69
 ENDPOINT COMPLIANCE CHECKLIST FOR THE PCI EXPRESS BASE 1.1 SPECIFICATION,
REVISION 1.1

ID Ref Assertion Y N
SYS.03.05#04 6.3.4.3 A completer must accurately report its isochronous bandwidth capability
in the Maximum Time Slots field in the VC Resource Capability register.
SYS.03.07#01 6.3.4.5 Under normal operating conditions (when delays are not induced by other
parts of the system), a multi-function device that contains a MFVC
Capability structure must not allow its MFVC isochronous logic to apply
backpressure due to flow control to isochronous requests injected to its
functions.
SYS.03.07#02 6.3.4.5 A multi-function device that contains a MFVC Capability structure must
support time-based Function Arbitration for each isochronous supporting
VC. This only applies to upstream traffic.
SYS.05.01#01 6.5.1 PCI Express endpoints must not support locked accesses. The only
endpoint type that has the option of supporting locked accesses is a legacy
PCI Express endpoint and only where necessary for legacy software
compatibility.
SYS.05.01#03 6.5.1 Only the Root Complex may initiate a Locked request. Endpoints and
Bridges cannot initiate Locked requests.
SYS.05.02#02 6.5.2 Locked requests which are completed with a status other than Successful
Completion must not establish lock.
SYS.05.02#01 6.5.2 MRdLk, CplDLk and Unlock requests may only be used with TC0 (the
default traffic class).
SYS.05.02#03 6.5.2 Any device not involved in a locked sequence must ignore the Unlock
Message. A switch is permitted to broadcast the unlock message
downstream.
SYS.05.02#04 6.5.2 When an Unlock message is received a locked Legacy Endpoint or Bridge
must unlock itself, if it is in a locked state.
SYS.05.02#11 6.5.2 A received Unlock message should be ignored and discarded by a PCI
Express Endpoint, or a Legacy Endpoint that doesn't support locking, or a
Bridge that doesn't support locking, or an unlocked Legacy Endpoint that
supports locking, or an unlocked Bridge that support locking.
SYS.05.02#06 6.5.2 The completions for any MRdLk request must use the CplDLk (for
successful completions). or CplLk (for unsuccessful completions).
SYS.05.06#01 6.5.6 A legacy endpoint must become locked only when it transmits a
Successful Completion for the first MRdLk request of the locked access.
SYS.05.06#02 6.5.6 Once an endpoint is locked it must remain locked until it receives the
Unlock message.
SYS.05.06#03 6.5.6 While it is locked a legacy endpoint must not issue any requests using
traffic classes which map only to VC0.
SYS.05.07#01 6.5.7 A PCI Express Endpoint (not legacy) must treat an MRdLk request as an
Unsupported Request.
SYS.06.00#17 6.6 When PERST# signal is present and active, it must trigger a Fundamental
Reset in the component.
SYS.06.00#18 6.6 When PERST# signal is not present, a Fundamental Reset must be
generated autonomously by the component.
SYS.06.00#19 6.6 If a component generates a Fundamental Reset autonomously, it must do
so every time supplied power goes outside the limits set for the form
factor or system.
SYS.06.00#01 6.6 On exit from any type of reset (cold, warm, hot) all port registers and state
machines must be set to the initialization values specified by the PCI
Express Specification 1.1 (except for sticky registers).
SYS.06.00#02 6.6 A component must enter the LTSSM Detect state within 20 ms of the end
of Fundamental Reset.
SYS.06.00#03 6.6 At the end of Link Training a component must be able to receive and
process TLPs and DLLPs.
SYS.07.03#01 6.7.1.1.1 Attention indicators must be yellow or amber in color.

70
 ENDPOINT COMPLIANCE CHECKLIST FOR THE PCI EXPRESS BASE 1.1 SPECIFICATION,
REVISION 1.1

ID Ref Assertion Y N
SYS.07.03#03 6.7.1.1.1 Attention indicators must be set to OFF when neither the adapter (if
present) nor the hot-plug slot requires attention.
SYS.07.03#04 6.7.1.1.1 Attention indicators must be set to ON if and only if there is an
operational problem with the adapter (if present) or hot-plug slot, that
prevents continued operation of the adapter.
SYS.07.03#02 6.7.1.1.1 Attention indicators must only be set to BLINKING when the hot-plug
slot is being identified by software, so that a user can locate the slot.
SYS.07.04#01 6.7.1.1.2 Power indicators must be green in color.
SYS.07.04#04 6.7.1.1.2 Power indicators must be set to BLINKING when a slot is powering up or
powering down and that insertion or removal of the adapter is not
permitted. It should also be BLINKING when the Attention Button is
pressed or when software initiates a hot-plug operation.
SYS.07.04#02 6.7.1.1.2 Power indicators must be set to OFF when power has been removed from
the slot or when insertion or removal of the adapter is permitted.
SYS.07.04#03 6.7.1.1.2 Power indicators must be set to ON when main power to the slot is on and
insertion or removal of the adapter is not permitted. This also means that
the hot-plug operation is complete.
SYS.07.06#04 6.7.1.5 The Attention Button status is indicated to software by the hot-plug
hardware in the downstream port associated with the slot.
SYS.07.06#01 6.7.1.5 If the Power Indicator begins blinking in response to the Attention Button
it must continue blinking for at least 5 seconds unless it is cancelled
within the first 5 seconds by another press of the Attention Button.
SYS.07.06#02 6.7.1.5 If the Attention Button is pressed during the first 5 seconds that the Power
Indicator is blinking the hot-plug operation must be cancelled.
SYS.07.09#01 6.7.2.1 The Attention Button Present bit in the Slot Capabilities and Device
Capabilities registers must accurately indicate whether an Attention
Button is electrically controlled by the chassis (Slot Capabilities register)
or by the adapter (Device Capabilities register).
SYS.07.09#02 6.7.2.2 The Attention Indicator Present bit in the Slot Capabilities and Device
Capabilities registers must accurately indicate whether an Attention
Button is electrically controlled by the chassis (Slot Capabilities) or by the
adapter (Device Capabilities).
SYS.07.09#03 6.7.2.3 The Power Indicator Present bit in the Slot Capabilities and Device
Capabilities registers must accurately indicate whether a Power Indicator
is electrically controlled by the chassis (Slot Capability) or by the adapter
(Device Capability).
SYS.07.11#01 6.7.2.3 The Power Indicator Control bit in the Slot Control register when written
sets a Power Indicator to the written state.
SYS.09.00#02 6.8 A card must never consume more power than the minimum guaranteed for
its form factor unless it receives a Set_Slot_Power_Limit message
indicating it can consume more.
SYS.09.00#10 6.9 An adapter that does not scale within the power limits for a given form
factor must support being disabled when it cannot be allocated enough
power.
SYS.09.00#06 6.9 A device must ensure that its device driver does not configure the device
to use more power than is allocated in the Slot Power Limit Value and
Scale field of the Device Capability.
SYS.09.00#05 6.9 Components that ignore Set_Slot_Power_Limit messages must accept
them without error and discard the message value.

71
 ENDPOINT COMPLIANCE CHECKLIST FOR THE PCI EXPRESS BASE 1.1 SPECIFICATION,
REVISION 1.1

Explanations:
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
__________________________________________________________
__________________________________________________________
__________________________________________________________
__________________________________________________________
__________________________________________________________
This section should be used to clarify any answers on checklist items above. Please key explanation to item number.

72
 ENDPOINT COMPLIANCE CHECKLIST FOR THE PCI EXPRESS BASE 1.1 SPECIFICATION,
REVISION 1.1

Configuration Checklist

ID Ref Assertion Y N
CFG.01.00#01 7 All PCI Express elements must have a PCI 3.0 compatible configuration
mechanism.
CFG.01.00#06 7.1 A PCI Express endpoint must be mapped to configuration space as a single
logical device with one or more logical functions. Function 0 must be
present.
CFG.01.00#09 7.1 Both PCI Express Endpoint and Legacy Endpoint must appear in
configuration space as a Hierarchy Domain originated by a Root Complex.
They cannot appear as a peer of the Root Ports.
CFG.01.00#10 7.1 Unless otherwise stated, configuration space requirements apply to all
functions in a multi-function device.
CFG.02.04#01 7.2.2.2 PCI Express devices must decode the Extended Register Address field of the
Configuration Request header.
CFG.03.01#01 7.3.1 Devices must not implement more than one device number in their upstream
port.
CFG.03.01#02 7.3.1 Devices must respond to all Type 0 Configuration Read Requests regardless
of the Device Number specified in the Request.
CFG.03.01#03 7.3.1 A PCI Express device must not assume it (or its upstream port) is
automatically associated with device number zero.
CFG.03.01#04 7.3.1 Devices wishing to implement more than 8 functions at their upstream port
must implement an internal Switch structure using Type 1 (PCI to PCI
Bridge) configuration space headers with the functions logically mapped as
devices connected downstream from the Switch.
CFG.03.03#01 7.3.3 A PCI Express Endpoint device must treat a type 1 configuration request as
an unsupported request.
CFG.03.03#02 7.3.3 A PCI Express Endpoint device must treat a type 0 configuration request for
an invalid local configuration space as an unsupported request.
CFG.03.03#03 7.3.3 All configuration requests can only be initiated by the Host Bridge.
CFG.04.00#01 7.4 Any read only register fields (RO) may not be changeable by software.
CFG.04.00#02 7.4 Any read-write register fields (RW) must be settable and clearable by
software.
CFG.04.00#03 7.4 Read only status - Write 1 to clear (RW1C) fields must be cleared when
written with a one. Otherwise they must be read only.
CFG.04.00#04 7.4 Sticky bit - read only fields (ROS) must be read only and can not be reset by
a hot reset. If AUX power consumption is enabled (by either Aux Power or
PME Enable) hot, warm, or cold resets must not change the fields.
CFG.04.00#05 7.4 Sticky bit - read-write fields (RWS) must be settable and clearable by
software. They must not be reset with a hot reset. If AUX power
consumption is enabled (by either Aux Power or PME Enable) hot, warm, or
cold resets must not change the fields.
CFG.04.00#06 7.4 Sticky bit - read only status - Write 1 to clear - fields (RW1CS) must be
cleared when written with a one. Otherwise they must be read only. They
must not be reset with a hot reset. If AUX power consumption is enabled (by
either Aux Power or PME Enable) hot, warm, or cold resets must not reset
the fields.
CFG.04.00#07 7.4 Hardware initialized (HWInit) fields can only be set by hardware or firmware
mechanisms. After initialization they are read only but must be reset with
Fundamental reset. NOTE: HWINIT fields may also be implemented as read
only. NOTE: Firmware initialization is only allowed for system integrated
devices.

73
 ENDPOINT COMPLIANCE CHECKLIST FOR THE PCI EXPRESS BASE 1.1 SPECIFICATION,
REVISION 1.1

ID Ref Assertion Y N
CFG.04.00#08 7.4 All fields must default to any default values specified in the PCI Express
specification except for Root Complexes and System Integrated devices.
CFG.04.00#09 7.4 All Reserved (RsvdP, RsvdZ) fields must return 0 when read.
CFG.05.00#03 7.5 All PCI compatible register fields that are not explicitly defined in the PCI
Express specification must comply to the requirements of the PCI 3.0
Specification.
CFG.05.01#01 7.5.1.1 Clearing the Bus Master Enable bit must prevent a PCI Express device from
initiating all memory (including MSI/MSI-X interrupt messages) and I/O
requests.
CFG.05.01#02 7.5.1.1 When the Interrupt Disable bit is set a device must not generate any INTx
messages.
CFG.05.01#03 7.5.1.1 When the Interrupt Disable bit is set, any already asserted INTx interrupts
must be deasserted.
CFG.05.01#04 7.5.1.1 The SERR# Enable bit controls reporting of non-fatal and fatal errors to the
root complex. If either SERR# Enable or PCI Express specific enable bits
are set then PCI Express in-band error messages must be sent to the root
complex.
CFG.05.01#08 7.5.1.1 Requests other than Memory or I/O are not controlled by the Bus Master
Enable bit.
CFG.05.01#09 7.5.1.1 If the device supports generation (Endpoint) or forwarding (Root or Bridge)
of memory or I/O requests, the Bus Master Enable bit must be R/W and must
default to 0.
CFG.05.01#10 7.5.1.1 If the device does not generate memory and I/O requests, the Bus Master
Enable bit must be RO and must be hard-wired to 0.
CFG.05.01#11 7.5.1.1 Special Cycle Enable bit must be RO and must be hard-wired to 0.
CFG.05.01#12 7.5.1.1 Memory Write and Invalidate bit must be RO and must be hard-wired to 0.
CFG.05.01#13 7.5.1.1 VGA Palette Snoop bit must be RO and must be hard-wired to 0.
CFG.05.01#14 7.5.1.1 Parity Error Response bit must be RW and must default to 0. (A Root
Complex Integrated Endpoint not associated with a Root Complex Event
Collector can hardwire this bit 0 and make it RO.)
CFG.05.01#15 7.5.1.1 IDSEL Stepping/Wait Cycle Control bit must be RO and must be hard-wired
to 0.
CFG.05.01#16 7.5.1.1 SERR# Enable bit must be RW and must default to 0. (A Root Complex
Integrated Endpoint not associated with a Root Complex Event Collector can
hardwire this bit 0 and make it RO.)
CFG.05.01#18 7.5.1.1 Fast Back to Back Transmission Enable bit must be RO and must be hard-
wired to 0.
CFG.05.01#19 7.5.1.1 Interrupt Disable bit must be RW and must default to 0.
CFG.05.02#01 7.5.1.2 The Interrupt Status bit must be set by H/W only if an INTx interrupt (Not
MSI) is pending internally to the device. NOTE: a Switch or Bridge does not
set this bit for interrupts forwarded from downstream devices.
CFG.05.02#02 7.5.1.2 The Capabilities List bit must be RO and must return 1.
CFG.05.02#03 7.5.1.2 For a Type 0 configuration header or for a Type 1 configuration header for
other than for Roots and Switches, the Master Data Parity Error bit must be
set by the requestor (Primary Side for Type 1) if the Parity Error Response bit
in the Command register is set and the requestor receives a completion
marked poisoned.
CFG.05.02#04 7.5.1.2 For a Type 0 configuration header or for a Type 1 configuration header for
other than for Roots and Switches, the Master Data Parity Error bit must be
set by the requestor (Primary Side for Type 1) if the Parity Error Response bit
in the Command register is set and the requestor poisons a write request.

74
 ENDPOINT COMPLIANCE CHECKLIST FOR THE PCI EXPRESS BASE 1.1 SPECIFICATION,
REVISION 1.1

ID Ref Assertion Y N
CFG.05.02#06 7.5.1.2 For a Type 0 configuration header or for a Type 1 configuration header for
other than for Roots and Switches, Signaled Target Abort bit must be set
when a device (Primary Side for Type 1 devices for requests completed by
the Type 1 header device) completes a request using the Completer Abort
completion status.
CFG.05.02#07 7.5.1.2 For a Type 0 configuration header or for a Type 1 configuration header for
other than for Roots and Switches, Received Target Abort bit must be set
when a requestor (Primary Side for Type 1 device initiated requests) receives
a completion with Completer Abort completion status.
CFG.05.02#08 7.5.1.2 For a Type 0 configuration header or for a Type 1 configuration header for
other than for Roots and Switches, Received Master Abort bit must be set
when a requestor (Primary Side for Type 1 device initiated requests) receives
a completion with Unsupported Request completion status.
CFG.05.02#09 7.5.1.2 For a Type 0 configuration header or for a Type 1 configuration header for
other than for Roots and Switches, Signaled System Error bit must be set
when a device sends an ERR_FATAL or ERR_NONFATAL message and
the SERR# Enable bit in the Command register is set.
CFG.05.02#10 7.5.1.2 For a Type 0 configuration header or for a Type 1 configuration header for
other than for Roots and Switches, Detected Parity Error bit must be set when
a device (Primary Side for Type 1) receives a poisoned TLP, regardless of the
state of the Parity Error Response bit in the Command register.
CFG.05.02#13 7.5.1.2 Interrupt Status bit must be RO and must default to 0.
CFG.05.02#15 7.5.1.2 66Mhz Capable bit must be RO and must be hard-wired to 0.
CFG.05.02#16 7.5.1.2 Fast Back to Back Transmission Capable bit must be RO and must be hard-
wired to 0.
CFG.05.02#17 7.5.1.2 Master Data Parity Error bit must be RW1C and must default to 0.
CFG.05.02#18 7.5.1.2 DEVSEL Timing field must be RO and must be hard-wired to 0.
CFG.05.02#19 7.5.1.2 Signaled Target Abort bit must be RW1C and must default to 0.
CFG.05.02#20 7.5.1.2 Received Target Abort bit must be RW1C and must default to 0.
CFG.05.02#21 7.5.1.2 Received Master Abort bit must be RW1C and must default to 0.
CFG.05.02#22 7.5.1.2 For a Type 0 configuration header or for a Type 1 configuration header for
other than for Roots and Switches, Signaled System Error bit must be RW1C
and must default to 0.
CFG.05.02#23 7.5.1.2 Detected Parity Error bit must be RW1C and must default to 0.
CFG.05.03#01 7.5.1.3 The Cache Line Size register must be implemented as a RW register.
CFG.05.03#02 7.5.1.3 The Cache Line Size register value must be ignored.
CFG.05.04#01 7.5.1.5 The Interrupt Line register must be implemented as RW by all devices that
use an interrupt pin (have a non-zero Interrupt Pin register value).
CFG.05.05#01 7.5.1.6 If a device does not use an interrupt pin, the Interrupt Pin register must be RO
and be hard-wired to zero.
CFG.05.05#03 7.5.1.6 If a function uses an interrupt pin, it must indicate in the Interrupt Pin register
the single interrupt pin it will use for originating an INTx interrupt. The only
acceptable values are 1 (INTA), 2 (INTB), 3 (INTC), or 4 (INTD). The
Interrupt Pin register is RO.
CFG.05.06#07 7.5.1.7 The PCI compatible error control and status register fields do NOT have any
effect on PCI Express error reporting enabled through the PCI Express
capability structure.
CFG.05.07#10 7.5.2.1 A device using a Base Address register to request a memory address range
must request a minimum of 128 bytes.
CFG.05.07#12 7.5.2.1 All PCI Express devices, except legacy endpoints, must support 64 bit
addressing for any base address register that requests prefetchable memory
resources.

75
 ENDPOINT COMPLIANCE CHECKLIST FOR THE PCI EXPRESS BASE 1.1 SPECIFICATION,
REVISION 1.1

ID Ref Assertion Y N
CFG.05.07#13 7.5.2.1 A device making a memory request through a BAR must set the BAR's
prefetchable bit unless the range contains locations with read side-effects or
locations that do not tolerate write merging.
CFG.05.07#15 7.5.2.2 Min_Gnt register must be RO and must be hard-wired to 0.
CFG.05.07#16 7.5.2.2 Max_Lat register must be RO and must be hard-wired to 0.
CFG.05.09#01 7.5.1.4 Master Latency Timer register must be RO and must be hard-wired to 0.
CFG.06.00#01 7.6 Devices that consume AUX power must preserve the value of PME Enable
when AUX power is available. In such devices this register value is not
modified by hot, warm or cold reset.
CFG.06.00#02 7.6 Devices that consume AUX power must preserve the value of PME Status
when AUX power is available. In such devices this register value is not
modified by hot, warm or cold reset.
CFG.06.00#06 7.6 PCI Power Management Capability must comply to PCI Bus Power
Management Interface Specification 1.2 (except as noted). This capability
must be present for all devices.
CFG.06.00#07 7.6 All devices must support at least the D0 and D3 devices states.
CFG.06.00#10 7.6 PME Clock bit must be RO and must be hard-wired to 0.
CFG.07.00#01 7.7 All PCI Express devices that are capable of generating interrupts must
implement MSI capability, or MSI-X capability, or both. MSI Capability and
MSI-X capability must comply to PCI Specification 3.0.
CFG.08.00#01 7.8 All PCI Express devices must implement the PCI Express capabilities,
Device Capabilities, Device Status/Control registers. All PCI Express
Endpoint devices and Root Ports, except for Root Complex Integrated
Endpoints must implement the Link Capabilities, and Link Status/Control
registers.
CFG.08.01#01 7.8.1 The PCI Express Capability ID must be RO and must be hard-wired to 10h.
CFG.08.01#02 7.8.1 The PCI Express capability list must be linked to the PCI capability list
following the rules in the PCI Specification.
CFG.08.01#03 7.8.1 Next Capability Pointers must be RO.
CFG.08.02#01 7.8.2 For the PCI Express capability, the Capability Version must be RO and must
be 01h for devices implemented to the PCI Express Specification, Revision
1.1.
CFG.08.02#02 7.8.2 Device/Port Type field must be 0000b for a PCI Express Endpoint device.
CFG.08.02#03 7.8.2 Device/Port Type field must be 0001b for a Legacy PCI Express Endpoint
device.
CFG.08.02#08 7.8.2 A PCI Express endpoint that requires I/O resources claimed through BARs
for run-time operation must indicate itself as a Legacy PCI Express Endpoint
device. (A PCI Express Endpoint device may claim I/O resources through
BARs, that are only needed for initialization and report itself as non-Legacy
device.)
CFG.08.02#11 7.8.2 If more than one MSI interrupt message is allocated to a function the
Interrupt Message Number must contain the MSI/MSI-X vector that is
generated when any of the status bits in either the Slot Status or Root Port
Status registers are set. It must return either the MSI or the MSI-X value
depending on with type is enabled.
CFG.08.02#13 7.8.2 Device/Port Type field must be RO.
CFG.08.02#17 7.8.2 Interrupt Message Number field is RO. Hardware must update this field
when software programs the Multiple Message Enable field changing the
number of MSI messages.
CFG.08.02#18 7.8.2 For MSI-X, the Interrupt Message Number field must return one of the first
32 table entries.
CFG.08.02#20 7.8.2 PCI Express Capabilities register bits 14-15 must be implemented as RsvdP.

76
 ENDPOINT COMPLIANCE CHECKLIST FOR THE PCI EXPRESS BASE 1.1 SPECIFICATION,
REVISION 1.1

ID Ref Assertion Y N
CFG.08.03#01 7.8.3 The Max_Payload_Size_Supported field must be RO and must correctly
indicate the maximum payload size that the device/function can support for
TLPs.
CFG.08.03#02 7.8.3 The Phantom Functions Supported field must be RO and must correctly
indicate which (if any) unclaimed function numbers may be used to extend
the number of outstanding transactions.
CFG.08.03#03 7.8.3 The Extended Tag Field Supported field must be RO and must correctly
indicate whether the device supports 5 bit or 8 bit Tag fields as a requestor.
CFG.08.03#04 7.8.3 For Endpoints only, The Endpoint L0s Acceptable Latency field must be RO
and must correctly indicate the worst case latency the endpoint can withstand
due to an L0s to L0 transition.
CFG.08.03#05 7.8.3 For Endpoints only, the Endpoint L1 Acceptable Latency field must correctly
indicate the worst case latency the endpoint can withstand due to an L1 to L0
transition.
CFG.08.03#06 7.8.3 Bits 12-14 of Device Capabilities register must be RO. Its return value is
undefined.
CFG.08.03#10 7.8.3 The Captured Slot Power Limit Value field must be RO and must show the
value received from the last Set_Slot_Power_Limit message. (if the device is
required to monitor these messages) and must only be implemented in
upstream ports. Any device consuming more than the form factor minimum
power is required to monitor Set_Slot_Power_Limit messages.
CFG.08.03#11 7.8.3 The Captured Slot Power Limit Scale field must be RO and must show the
value received from the last Set_Slot_Power_Limit message (if the device is
required to monitor these messages) ) and must only be implemented in
upstream ports. Any device consuming more than the form factor minimum
power is required to monitor Set_Slot_Power_Limit messages.
CFG.08.03#17 7.8.3 Role-Based Error Reporting bit must be RO and must be set to 1 for devices
complying to PCI Express 1.1 or later.
CFG.08.03#18 7.8.3 Device Capabilities register bits 28-31 must be implemented as RsvdP.
CFG.08.04#01 7.8.4 The Correctable Error Reporting Enable bit must be RW, defaulting to 0, and
must control (with other bits) whether a device sends ERR_COR messages.
(For a root port the reporting of correctable errors is internal to the root.) A
Root Complex Integrated Endpoint that is not associated with a Root
Complex Event Collector may hard-wire this bit to 0.
CFG.08.04#03 7.8.4 The Non-Fatal Error Reporting Enable bit must be RW, defaulting to 0, and
must control (with other bits) whether a device sends ERR_NONFATAL
messages. (For a root port the reporting of correctable errors is internal to the
root.) A Root Complex Integrated Endpoint that is not associated with a
Root Complex Event Collector may hard-wire this bit to 0.
CFG.08.04#05 7.8.4 The Fatal Error Reporting Enable bit must be RW, defaulting to 0, and must
control (with other bits) whether a device sends ERR_FATAL messages.
(For a root port the reporting of fatal errors is internal to the root.) A Root
Complex Integrated Endpoint that is not associated with a Root Complex
Event Collector may hard-wire this bit to 0.
CFG.08.04#07 7.8.4 The Unsupported Request Reporting Enable must be R/W, defaulting to 0,
and must control (with other bits) whether a device signals unsupported
requests by sending error messages. A device is not allowed to report them
through error messages unless the appropriate error message enable is also
set. (For a root port the reporting of unsupported request errors is internal to
the root.) A Root Complex Integrated Endpoint that is not associated with a
Root Complex Event Collector may hard-wire this bit to 0.
CFG.08.04#08 7.8.4 If the device can set the Relaxed Ordering attribute in transactions it initiates,
than the Enable Relaxed Ordering bit must be R/W, defaulting to 1.
Otherwise, it can be RO and hard-wired to 0.

77
 ENDPOINT COMPLIANCE CHECKLIST FOR THE PCI EXPRESS BASE 1.1 SPECIFICATION,
REVISION 1.1

ID Ref Assertion Y N
CFG.08.04#09 7.8.4 A device can only set the Relaxed Ordering attribute in transactions it
initiates, if the Enable Relaxed Ordering bit is set to one.
CFG.08.04#10 7.8.4 Max_Payload_Size field must be R/W and must default to a value of 000
(128 bytes).
CFG.08.04#11 7.8.4 Devices must handle receiving TLPs as large as the Max_Payload_Size
value.
CFG.08.04#12 7.8.4 Devices must not generate TLPs exceeding the Max_Payload_Size value.
CFG.08.04#13 7.8.4 Devices must only generate an 8 bit tag field as a requestor if the Extended
Tag Field Enable bit is set.
CFG.08.04#14 7.8.4 Devices that supports generation of 8 bit tags as a requester, must implement
the Extended Tag Field Enable bit as R/W defaulting to 0. A device that only
supports generation of 5 bit tags as a requester, must implement it as RO
hard-wired to 0.
CFG.08.04#15 7.8.4 Devices must only use unclaimed functions as phantom functions to extend
the number of outstanding transaction identifiers if the Phantom Functions
Enable bit is set.
CFG.08.04#16 7.8.4 Devices that supports use of phantom functions to extend the number of
outstanding transactions, must implement the Phantom Functions Enable bit
as R/W, defaulting to 0. A device that does not use phantom functions must
implement this bit as RO, hard-wired to 0.
CFG.08.04#17 7.8.4 Only if the Auxiliary (AUX) Power PM Enable bit is set can a device draw
AUX power (independent of PME_AUX) as requested in the AUX_Current
field of the Power Management Capabilities Register (PMC) independent of
the PME_En bit in PMC.
CFG.08.04#18 7.8.4 Devices that require Aux power (independent of PME_AUX) must
implement this bit as RWS. Devices that do not draw Aux power
(independent of PME_AUX) must implement the bit as RO, hard-wired to 0.
CFG.08.04#19 7.8.4 Devices that support setting the No Snoop attribute as a requester, must
implement the Enable No Snoop bit as R/W defaulting to 1. Devices that
cannot set the No Snoop attribute must implement the bit as RO hard-wired
to 0.
CFG.08.04#20 7.8.4 A device must only set the No Snoop attribute as a requester, if the Enable
No Snoop bit is one and the device can guarantee the address of the
transaction is not stored in any cache in the system.
CFG.08.04#21 7.8.4 Devices that can generate read requests larger than 128 bytes, must
implement the Max_Read_Request_Size field as R/W, defaulting to 010 (512
bytes). Devices do not generate read requests larger than 128 bytes can
implement this bit as RO, hard-wired to 0.
CFG.08.04#22 7.8.4 A device must not generate a read request with a size exceeding that set in
the Max_Read_Request_Size field.
CFG.08.04#23 7.8.4 Devices that consume AUX power must preserve the value of the Auxiliary
(AUX) Power PM Enable bit when AUX power is available. In such devices
this register value is not modified by hot, warm or cold reset.
CFG.08.04#24 7.8.4 Devices that require Aux power for Legacy operating systems should still
implement PME_AUX requirements.
CFG.08.04#26 7.8.4 Non-bridge devices must implement the Bridge Configuration Retry Enable
bit as RsvdP, hard-wired to 0.
CFG.08.05#01 7.8.5 A correctable error must cause the Correctable Error Detected field to be set
regardless of whether reporting of correctable errors is enabled in the Device
Control register.
CFG.08.05#02 7.8.5 A non-fatal error must cause the Non-Fatal Error Detected bit to be set
regardless of whether reporting of non-fatal errors is enabled in the Device
Control register.

78
 ENDPOINT COMPLIANCE CHECKLIST FOR THE PCI EXPRESS BASE 1.1 SPECIFICATION,
REVISION 1.1

ID Ref Assertion Y N
CFG.08.05#03 7.8.5 A fatal error must cause the Fatal Error Detected bit to be set regardless of
whether reporting of fatal errors is enabled in the Device Control register.
CFG.08.05#04 7.8.5 An unsupported request must cause the Unsupported Request Detected bit to
be set regardless of whether reporting of unsupported requests is enabled in
the Device Control register.
CFG.08.05#05 7.8.5 Only device that requires AUX power must report the Aux Power Detected
bit set if Aux Power is detected by the device. The bit is RO.
CFG.08.05#06 7.8.5 A device must set the Transactions Pending bit whenever it has any non
posted requests which have not been completed. This only applies to
transactions issued on the device's own behalf.
CFG.08.05#07 7.8.5 A device must clear the Transactions Pending bit only when all outstanding
non-posted requests have completed or been terminated with completion
timeout. This only applies to transactions issued on the device's own behalf.
CFG.08.05#09 7.8.5 The Correctable Error Detected bit must be RW1C and default to 0.
CFG.08.05#10 7.8.5 A correctable error must cause the Correctable Error Detected field to be set
regardless of the settings in the Correctable Error Mask register (if
implemented for a device supporting Advanced Error Handling).
CFG.08.05#11 7.8.5 The Non-Fatal Error Detected bit must be RW1C and default to 0.
CFG.08.05#12 7.8.5 A non-fatal error must cause the Non-Fatal Error Detected field to be set
regardless of the settings in the Correctable Error Mask register (if
implemented for a device supporting Advanced Error Handling).
CFG.08.05#13 7.8.5 The Fatal Error Detected bit must be RW1C and default to 0.
CFG.08.05#14 7.8.5 A fatal error must cause the Fatal Error Detected field to be set regardless of
the settings in the Correctable Error Mask register (if implemented for a
device supporting Advanced Error Handling).
CFG.08.05#15 7.8.5 The Unsupported Request Detected bit must be RW1C and default to 0.
CFG.08.05#16 7.8.5 The Transactions Pending bit is RO.
CFG.08.05#17 7.8.5 Device Status register bits 6-15 must be implemented as RsvdP.
CFG.08.06#01 7.8.6 The Maximum Link Speed field must be RO and must read 0001 (2.5 Gb/s
Link) for a device implemented to the PCI Express specification, revision
1.1.
CFG.08.06#02 7.8.6 The Maximum Link Width field must be RO and must accurately indicate the
maximum link width supported by the device.
CFG.08.06#03 7.8.6 The Active State Link Power Management Support field must be RO and
must correctly indicate the active power management states supported on the
link.
CFG.08.06#04 7.8.6 The L0s Exit Latency field must be RO and must accurately indicate the
length of time the ports takes to transition from L0s to L0 with the current
reference clock configuration.
CFG.08.06#05 7.8.6 The L1 Exit Latency field must be RO and must accurately indicate the
length of time the ports takes to transition from L1 to L0 with the current
reference clock configuration.
CFG.08.06#08 7.8.6 The Clock Power Management bit must be RO and only return 1 if the device
tolerates the removal of any reference clock via CLKREQ# mechanism.
CFG.08.06#09 7.8.6 Each function in a multi-function device implements a Clock Power
Management bit to indicate its individual capability.
CFG.08.06#11 7.8.6 Downstream ports must only set Surprise Down Error Reporting Capable bit
if the port is capable of detecting a Surprise Down error. Upstream ports
must hardwire this bit to 0. This bit is RO.
CFG.08.06#12 7.8.6 Downstream ports supporting Hot-Plug Capable field must set the Data Link
Layer Link Active Reporting Capable bit to 1. Other Downstream ports must
only set the Data Link Layer Link Active Reporting Capable bit to 1 if the
port is capable of reporting the DL_Active state. Upstream ports must
hardwire this bit to 0. This bit is RO.

79
 ENDPOINT COMPLIANCE CHECKLIST FOR THE PCI EXPRESS BASE 1.1 SPECIFICATION,
REVISION 1.1

ID Ref Assertion Y N
CFG.08.06#13 7.8.6 Link Capabilities register bits 21-23 must be implemented as RsvdP.
CFG.08.06#14 7.8.6 The Port Number field is Hwinit.
CFG.08.07#02 7.8.7 A receiver must be capable of entering L0s even when ASPM control is
disabled.
CFG.08.07#04 7.8.7 For Endpoints, PCI Express to PCI/PCI-X Bridges, and Switch upstream
ports, the Link Disable bit must be a reserved field.
CFG.08.07#05 7.8.7 The Retrain Link bit must always return zero when read.
CFG.08.07#07 7.8.7 For Endpoints, PCI Express to PCI/PCI-X Bridges, and Switch upstream
ports, the Link Retrain bit must be a reserved field.
CFG.08.07#08 7.8.7 Devices must use the Common Clock Configuration bit in reporting correct
L0s and L1 exit latencies.
CFG.08.07#09 7.8.7 If the Extended Synch bit is set the link must transmit 4096 FTS ordered sets
followed by a single SKP ordered set in transitioning from L0s to L0.
CFG.08.07#10 7.8.7 If the Extended Synch bit is set the link must transmit 1024 TS1 ordered-sets
when in the recovery state.
CFG.08.07#13 7.8.7 For Endpoints (if implemented) the Read Completion Boundary field must be
RW. If not implemented than it must be hard-wired to 0.
CFG.08.07#15 7.8.7 The Active State Power Management Control field must be RW.
CFG.08.07#18 7.8.7 For Endpoints, PCI Express to PCI/PCI-X Bridges, and Switch upstream
ports, writing the Link Disable bit must not have any effect on the link.
CFG.08.07#21 7.8.7 For Endpoints, PCI Express to PCI/PCI-X Bridges, and Switch upstream
ports, writing the Link Retrain bit must not have any effect on the link.
CFG.08.07#22 7.8.7 The Common Clock Configuration bit must be RW, defaulting to 0.
CFG.08.07#23 7.8.7 If implemented (that is that the Clock Power Management bit returns 1), the
Enable Clock Power Management bit is R/W, defaulting to 0. Otherwise the
bit is hard-wired to 0.
CFG.08.07#24 7.8.7 If implemented, the device can only use CLKREQ# to manage clocks when
the Enable Clock Power Management bit is 1. Otherwise CLKREQ# must be
held low.
CFG.08.07#25 7.8.7 Link Control register bits 9-15 must be implemented as RsvdP.
CFG.08.08#01 7.8.8 The Link Speed field must be RO and must return 0001 (2.5 Gb/s PCI
Express Link) for the devices implemented to PCI Express Specification,
Revision 1.1. This field is undefined when the link is not up.
CFG.08.08#02 7.8.8 The Negotiated Link Width field must be RO and must correctly indicate the
negotiated width of the PCI Express link. This field is undefined when the
link is not up.
CFG.08.08#05 7.8.8 Link Status register bit 10 must be R0.
CFG.08.08#08 7.8.8 The Slot Clock Configuration bit must be HwInit. It must only return 1 if the
component uses the same physical reference clock that the platform provides
on the connector. It must return 0 if the component uses an independent
clock.
CFG.08.08#11 7.8.8 For Endpoints and Switch upstream ports, the Link Training bit must be RO
and hard-wired to 0.
CFG.08.08#12 7.8.8 The Data Link Layer Link Active bit must be RO and returns a 1 to indicate
the DL_Active state. It must be implemented if the corresponding Data Link
Layer Active Capability bit reports a 1, otherwise it is hard-wired to 0.
CFG.08.08#13 7.8.8 Link Status register bits 14-15 must be implemented as RsvdZ.
CFG.08.13#03 7.8.14 PMEs must be kept pending until software writes a one to the PME Status bit
to clear the last PME.
CFG.09.00#01 7.9 Extended capabilities in a device configuration space must begin at offset
100h with a PCI Express Enhanced Capability Header.

80
 ENDPOINT COMPLIANCE CHECKLIST FOR THE PCI EXPRESS BASE 1.1 SPECIFICATION,
REVISION 1.1

ID Ref Assertion Y N
CFG.09.01#01 7.9.1 Absence of any extended capabilities must be indicated by and Enhanced
Capability Header with a Capability ID of 0000h, Capability Version of 0h,
and Next Capability Offset of 0h.
CFG.09.03#01 7.9.3 The PCI Express Extended Capability ID field of a PCI Express Enhanced
Capability Header must be RO and must return a valid PCI-SIG defined ID
number.
CFG.09.03#02 7.9.3 The Capability Version field of a PCI Express Enhanced Capability Header
must be RO and must correctly indicate the version of the capability structure
present.
CFG.09.03#03 7.9.3 The Next Capability Offset field must be RO and must return the offset to the
next capability structure or 000h (last capability in list). For capabilities in
configuration space, the field must be greater than 0FFh if not the last
capability in the list. The bottom two bits must be implemented as 00b.
CFG.10.00#01 7.10 Bits corresponding to fields that are not implemented in the AER must be
hard-wired to 0.
CFG.10.00#02 7.10 Optional error reporting bit fields in AER must consistently be implemented
as a group across the Status, Mask, and Severity registers.
CFG.10.01#01 7.10.1 The PCI Express Extended Capability ID field must be RO and must return
0001h for an Advanced Error Reporting Capability.
CFG.10.01#02 7.10.1 For Advanced Error Reporting capability, the Capability Version field must
be RO and return 1h for devices implemented to the PCI Express
Specification, Revision 1.1.
CFG.10.02#01 7.10.2 If AER is implemented, the following uncorrectable error bits are required
and must be implemented as RW1CS in the Uncorrectable Error Status
register and as RWS in the corresponding Uncorrectable Error Mask and
Uncorrectable Error Severity registers: Data Link Protocol Error, Poisoned
TLP, Completion Timeout, Unexpected Completion, Malformed TLP,
Unsupported Request Error. (For Switch ports that do not issue requests on
their own behalf, Completion Timeout fields must be hard-wired to 0.)
CFG.10.02#02 7.10.2 If AER is implemented, the following uncorrectable error bits are optional:
Surprise Down Error, Flow Control Protocol Error, Completer Abort,
Receiver Overflow, ECRC Error. If an optional bit is implemented in the
Uncorrectable Error Status register, it must be RW1CS and the corresponding
Uncorrectable Error Mask and Uncorrectable Error Severity bit must also be
implemented as RWS. If an optional bit is not implemented it must be hard-
wired to 0.
CFG.10.02#03 7.10.2 An Uncorrectable Error event must cause the corresponding Uncorrectable
Error Status bit to be set if implemented, regardless of the setting of the
Uncorrectable Error Mask bit.
CFG.10.02#04 7.10.2 Uncorrectable Error Status fields must only be cleared when software writes
a one to the respective bit.
CFG.10.02#05 7.10.2 All Uncorrectable Error Status fields must default to zero.
CFG.10.02#07 7.10.2 Uncorrectable Error Status register bits 1-3, 6-11,21-31 must be implemented
as RsvdZ. The same bits in Uncorrectable Error Mask/Severity register must
be implemented as RsvdP.
CFG.10.03#01 7.10.3 All Uncorrectable Error Mask fields must default to zero.
CFG.10.03#02 7.10.3 If a Uncorrectable Error Status field is set and the corresponding mask field
is clear the device must report the error as a non_fatal (Severity=0) or fatal
(Severity=1) error depending on the value of the corresponding severity field
with in band mechanisms.

81
 ENDPOINT COMPLIANCE CHECKLIST FOR THE PCI EXPRESS BASE 1.1 SPECIFICATION,
REVISION 1.1

ID Ref Assertion Y N
CFG.10.04#01 7.10.4 The Data Link Protocol Error Severity and Malformed TLP Severity fields of
the Uncorrectable Error Severity Register must default to one. If
implemented the optional fields: Surprise Down Error Severity, Flow Control
Protocol Error Severity, and Receiver Overflow Error Severity must default
to one.
CFG.10.04#02 7.10.4 The Poisoned TLP Severity, Completion Timeout Error Severity, Completer
Abort Error Severity, Unexpected Completion Error Severity, ECRC Error
Severity, and Unsupported Request Error Severity fields of the Uncorrectable
Error Severity Register must default to zero.
CFG.10.05#01 7.10.5 The following correctable error fields are required and must be implemented
as RW1CS in the Correctable Error Status and RWS in the Correctable Error
Mask registers: Bad TLP, Bad DLLP, REPLAY_NUM Rollover, Replay
Timer Timeout, and Advisory Non-Fatal Error.
CFG.10.05#02 7.10.5 The following Correctable error fields are optional. If they are implemented,
the Correctable Error Status field must be RW1CS and the Correctable Error
Mask field must be RWS: Receiver Error.
CFG.10.05#03 7.10.5 A Correctable Error event must cause the corresponding Error Status bit field
to be set if implemented, regardless of the setting of the Correctable Error
Mask bit.
CFG.10.05#04 7.10.5 Correctable Error Status fields must only be cleared when software writes a
one to the respective bit.
CFG.10.05#05 7.10.5 All the Correctable Error Status fields must default to zero.
CFG.10.05#06 7.10.5 Correctable Error Status register bits 1-5, 9-11,14-31 must be implemented as
RsvdZ. The same bits in Correctable Error Mask register must be
implemented as RsvdP.
CFG.10.06#01 7.10.6 The following Correctable Error Mask fields must default to zero: Bad TLP
Status, Bad DLLP Status, REPLAY_NUM Rollover Status, and Replay
Timer Timeout Status.
CFG.10.06#02 7.10.6 If a Correctable Error Status field is set and the corresponding mask field is
clear the device must report the error in band as a correctable error.
CFG.10.06#03 7.10.6 The following Correctable Error Mask fields must default to one: Advisory
Non-Fatal Error Status.
CFG.10.07#01 7.10.7 The First Error Pointer field must be ROS and indicate the bit position of the
first error reported in the uncorrectable error status register since the error
pointer was cleared.
CFG.10.07#03 7.10.7 The ECRC Generation Capable bit must be RO and must accurately indicate
if the device is capable of generating ECRC.
CFG.10.07#04 7.10.7 A capable device must only generate ECRCs if the ECRC Generation Enable
bit is set.
CFG.10.07#05 7.10.7 The ECRC Check Capable bit must be RO and must accurately indicate if the
device is capable of checking ECRC.
CFG.10.07#06 7.10.7 A capable device must only check ECRCs if the ECRC Check Enable bit is
set.
CFG.10.07#08 7.10.7 The ECRC Generation Enable bit must be RWS, defaulting to 0.
CFG.10.07#09 7.10.7 The ECRC Check Enable bit must be RWS, defaulting to 0.
CFG.10.07#10 7.10.7 Advanced Error Capabilities and Control register bits 9-31 must be
implemented as RsvdP.
CFG.10.08#01 7.10.8 The Header Log register must be updated with the TLP header of the
offending TLP whenever the First Error Pointer field is updated due to an
error associated with a TLP.
CFG.10.08#02 7.10.8 The bytes in each DW of the Header Log register are stored such that byte
zero of the header DW is stored in byte 3 of the corresponding Header Log
register, byte 1 of the header DW is stored in byte 2 of the corresponding
Header Log register, etc.

82
 ENDPOINT COMPLIANCE CHECKLIST FOR THE PCI EXPRESS BASE 1.1 SPECIFICATION,
REVISION 1.1

ID Ref Assertion Y N
CFG.10.08#03 7.10.8 The Header Log register must be ROS, defaulting to 0.
CFG.11.00#01 7.11 The PCI Express Virtual Channel capability must be implemented by any
device that generates/routes/filters traffic using anything except the default
TC0/VC0 traffic class and virtual channel.
CFG.11.00#02 7.11 Only multi-function devices that contain a Multi-Function Virtual Channel
capability structure can contain a Virtual Channel capability in Functions 1 to
7. Otherwise only Function 0 is permitted to contain a Virtual Channel
capability.
CFG.11.00#03 7.11 Virtual Channel Capability Structure bytes 18h-19h (and subsequent 18h+n -
19h+n, for VCn) must be RsvdP.
CFG.11.01#01 7.11.1 In a device that does not contain a Multi-Function Virtual Channel capability,
the PCI Express Extended Capability ID field must be RO and must return
0002h for the Virtual Channel Capability.
CFG.11.01#02 7.11.1 For the Virtual Channel capability, the Capability Version must be RO and
must return 1h for devices implemented to the PCI Express Specification,
revision 1.1.
CFG.11.01#03 7.11.1 In a device that does contain a Multi-Function Virtual Channel capability, the
PCI Express Extended Capability ID field must be RO and must return 0009h
for the Virtual Channel Capability.
CFG.11.02#01 7.11.2 The Extended VC Count field must be RO and must accurately indicate the
number of virtual channels supported by the device. (0 = VC0 only, 1 = VC0-
VC1, .., 7=VC0-VC7).
CFG.11.02#02 7.11.2 The Low Priority Extended VC Count field must be RO and must indicate
the number of VCs besides VC0 that belong to the lowest priority group if
strict priority VC arbitration is being used. Value can be between 0 and the
value given in Extended VC Count.
CFG.11.02#03 7.11.2 For Root Ports, Endpoints, and Switches or Root Complexes not
implementing WRR Port Arbitration, the Reference Clock field must be RO,
hard-wired to 0.
CFG.11.02#06 7.11.2 For Endpoints, the Port Arbitration Table Entry Size must be RO, hard-wired
to 0.
CFG.11.02#07 7.11.2 Port VC Capability Register 1 bits 12-31 must be implemented as RsvdP.
CFG.11.03#01 7.11.3 For devices that report a Low Priority Extended VC Count greater than zero,
the VC Arbitration Capability field must be RO and must correctly indicate
the possible types of VC Arbitration supported for the LPVC group. For
other devices it must return 0.
CFG.11.03#02 7.11.3 If no arbitration table is present, the VC Arbitration Table Offset field must
be RO and return 0.
CFG.11.03#03 7.11.3 The VC Arbitration Table Offset field must be RO and must accurately
indicate the offset of the table (if it exists) in DQWORDS from the base
address of the VC capability.
CFG.11.03#04 7.11.3 Port VC Capability Register 2 bits 8-23 must be implemented as RsvdP.
CFG.11.04#01 7.11.4 For all devices when the selected VC Arbitration uses the VC Arbitration
Table, setting the Load VC Arbitration Table bit must cause hardware to load
new settings from the VC Arbitration table.
CFG.11.04#02 7.11.4 Hardware must use the mode written to the VC Arbitration Select field for
VC arbitration of the LPVC group.
CFG.11.04#03 7.11.4 For all devices when the selected VC Arbitration uses the VC Arbitration
Table, the Load VC Arbitration Table bit must be RW and always returns 0.
CFG.11.04#05 7.11.4 The VC Arbitration Select field must be RW. Only values corresponding to
one of the asserted bits in the VC Arbitration Capability field are valid.
CFG.11.04#06 7.11.4 The VC Arbitration Select field must not change when more than one VC in
the LPFC group is enabled.
CFG.11.04#07 7.11.4 Port VC Control register bits 4-15 must be implemented as RsvdP.

83
 ENDPOINT COMPLIANCE CHECKLIST FOR THE PCI EXPRESS BASE 1.1 SPECIFICATION,
REVISION 1.1

ID Ref Assertion Y N
CFG.11.05#01 7.11.5 For all devices when the selected VC Arbitration uses the VC Arbitration
Table, hardware must set the VC Arbitration Table Status bit whenever
software modifies any entry of the VC Arbitration Table.
CFG.11.05#02 7.11.5 For all devices when the selected VC Arbitration uses the VC Arbitration
Table, hardware must clear the VC Arbitration Table Status bit whenever it is
finished downloading new values to the VC Arbitration Table, after software
sets the Load VC Arbitration Table field.
CFG.11.05#03 7.11.5 The VC Arbitration Table Status bit must be RO, defaulting to 0.
CFG.11.05#04 7.11.5 Port VC Status register bits 1-15 must be implemented as RsvdZ.
CFG.11.06#07 7.11.6 VC Resource Capability register bits 8-13, 23 must be implemented as
RsvdP.
CFG.11.07#01 7.11.7 The default value of the TC/VC Map field for the first VC resource must be
FFh.
CFG.11.07#02 7.11.7 The default value of all TC/VC Map fields for all VC resources except the
first VC resource must be 00h.
CFG.11.07#03 7.11.7 Hardware must accurately use the TC/VC Map field value to determine
which TCs are mapped to this VC (Bit 7 corresponds to TC7, Bit 0
corresponds to TC0).
CFG.11.07#06 7.11.7 The VC ID field for the first VC resource must be RO, hard-wired to 0.
CFG.11.07#07 7.11.7 The VC ID field for other than the first VC resource, must be R/W.
Hardware must use the VC ID value for the VC when it is enabled if it is not
the first VC resource.
CFG.11.07#08 7.11.7 The VC Enable bit must be hard-wired to 1, for the first VC resource.
CFG.11.07#09 7.11.7 The VC Enable bit must accurately indicate if the VC is enabled (Flow
Control initialization is completed) when read. (1 = enabled).
CFG.11.07#10 7.11.7 Writing a one to the VC Enable bit must enable a disabled VC (both sides of
the link must be updated).
CFG.11.07#11 7.11.7 Writing a zero to the VC Enable bit must disable an enabled VC (both sides
of the link must be updated).
CFG.11.07#12 7.11.7 Bit 0 of the TC/VC Map field must be RO. It must be set to 1 for the default
VC0 and set to 0 for all other enabled VCs.
CFG.11.07#13 7.11.7 Bits 1-7 of the TC/VC Map field must be RW.
CFG.11.07#15 7.11.7 VC Resource Control register bits 8-15, 20-23, 27-30 must be implemented
as RsvdP.
CFG.11.07#18 7.11.7 The VC ID field must not change when the VC is already enabled.
CFG.11.07#19 7.11.7 The VC Enable bit must be RW and default to 0 for all except the first VC
resource.
CFG.11.08#03 7.11.8 The VC Negotiation Pending bit must be RO and must be set by hardware
whenever the VC resource has not completed the process of negotiation.
CFG.11.08#04 7.11.8 The VC Negotiation Pending bit must be cleared by hardware after the VC
resource has completed the process of negotiation.
CFG.11.08#06 7.11.8 VC Resource Status register bits 2-15 must be implemented as RsvdZ.
CFG.12.00#01 7.12 A multi-function device that implements the Device Serial Number capability
must implement it in Function 0. If other functions implement the Device
Serial Number capability, they must return the exact same Device Serial
Number value as reported by Function 0.
CFG.12.01#01 7.12.1 The PCI Express Extended Capability ID field for the Device Serial Number
Capability is 0003h and must be RO.
CFG.12.01#02 7.12.1 For the Device Serial Number capability, the Capability Version must be RO
and return 1h for devices implemented to the PCI Express Specification,
Revision 1.1.

84
 ENDPOINT COMPLIANCE CHECKLIST FOR THE PCI EXPRESS BASE 1.1 SPECIFICATION,
REVISION 1.1

ID Ref Assertion Y N
CFG.12.02#01 7.12.2 The PCI Express Device Serial Number field must be RO and must contain a
64 bit identifier unique for a given device. The identifier contains a 24 bit
Company ID (assigned by IEEE) and a 40 bit identifier (assigned by the
company).
CFG.13.01#01 7.15.1 The PCI Express Extended Capability ID field for the Power Budgeting
Capability is 0004h and must be RO.
CFG.13.01#02 7.15.1 For the Power Budgeting capability, the Capability Version must be RO and
return 1h for devices implemented to the PCI Express Specification, Revision
1.1.
CFG.13.01#03 7.15 The Power Budgeting Capability must be implemented on devices that are
implemented on form factors that support Hot-Plug.
CFG.13.01#04 7.15 Power Budgeting Capability structure bytes 05h-07h, 0Dh-0Fh must be
implemented as RsvdP.
CFG.13.02#01 7.15.2 The Data Select register must be RW. A zero value in this register selects the
first DWORD of Power Budgeting data that is returned in the Data Register.
Subsequent DWORDs of Power Budgeting Data is returned by increasing the
Data Select Register value.
CFG.13.03#01 7.15.3 The Data register must be RO and returns the DWORD indicated by the Data
Select register index, or all zeros if the Data Select register index equal or
exceeds the number of operating conditions for which the device provides
power information.
CFG.13.03#02 7.15.3 The Base Power field and the Data Scale field must both be RO. The Base
Power field value multiplied by the Data Scale field value must correctly
indicate the power consumption of the current operating mode in watts.
CFG.13.03#03 7.15.3 The PM State field must be RO and must accurately indicate which device
Dx state the current power data describes.
CFG.13.03#04 7.15.3 The Type field must be RO and must accurately indicate the type of the
operating condition the current power data describes.
CFG.13.03#05 7.15.3 The Power Rail field must be RO and accurately indicate the power rail the
current power data describes.
CFG.13.03#06 7.15.3 Devices that implement the Power Budgeting Capability must provide data
values for the D0 Max and D0 Sustained power consumption for every power
rail they consume power from.
CFG.13.03#07 7.15.3 D0 Max Thermal and D0 Sustained Thermal power data must be provided if
these values differ from the D0 Max and D0 Sustained values for the power
rails.
CFG.13.03#08 7.15.3 Devices that support auxiliary power or PME from auxiliary power must
provide accurate power consumption data from Aux or PME Aux.
CFG.13.03#09 7.15.3 The PM Sub State field must be RO and must accurately specify the power
management sub state of the operating condition being described.
CFG.13.03#10 7.15.3 Power Budgeting Data register bits 21-31 must be implemented as RsvdP.
CFG.13.04#01 7.15.4 The System Allocated bit must be HwInit and must be set if the device power
budget is included in the system power budget.
CFG.13.04#03 7.15.4 Power Budget Capability register bits 1-7 must be implemented as RsvdP.
CFG.17.00#01 7.17 Multi Function Virtual Channel Capability Structure bytes 18h-19h (and
subsequent 18h+n - 19h+n, for VCn) must be RsvdP.
CFG.17.01#01 7.17.1 The PCI Express Extended Capability ID field for the Multi Function VC
Capability is 0008h and must be RO.
CFG.17.01#02 7.17.1 For the Multi Function VC capability, the Capability Version must be RO
and must return 1h for devices implemented to the PCI Express Specification,
Revision 1.1.
CFG.17.02#01 7.17.2 The Extended VC Count field must be RO and must accurately indicate the
number of virtual channels supported by the device. (0 = VC0 only, 1 = VC0-
VC1, .., 7=VC0-VC7).

85
 ENDPOINT COMPLIANCE CHECKLIST FOR THE PCI EXPRESS BASE 1.1 SPECIFICATION,
REVISION 1.1

ID Ref Assertion Y N
CFG.17.02#02 7.17.2 The Low Priority Extended VC Count field be RO and must indicate the
number of VCs besides VC zero that belong to the lowest priority group if
strict priority VC arbitration is being used. Value can be between 0 and the
value given in Extended VC Count.
CFG.17.02#03 7.17.2 The Reference Clock field must be RO and must accurately indicate the
reference clock to be used by for VCs that are using WRR Function
Arbitration.
CFG.17.02#04 7.17.2 The Function Arbitration Table Entry Size field must be RO and must
accurately indicate the size (in bits) of the function arbitration table entry.
CFG.17.02#05 7.17.2 Port VC Capability Register 1 bits 12-31 must be implemented as RsvdP.
CFG.17.03#01 7.17.3 The VC Arbitration Capability field must be RO and must accurately indicate
the possible types of VC Arbitration supported for the LPVC group if this
device reports a Low Priority Extended VC Count greater than zero.
Otherwise it must be 0.
CFG.17.03#02 7.17.3 Port VC Capability Register 2 bits 8-23 must be implemented as RsvdP.
CFG.17.03#03 7.17.3 The VC Arbitration Table Offset field must be RO and must accurately
indicate the offset of the table (if it exists) in DQWORDS from the base
address of the MFVC capability.
CFG.17.03#04 7.17.3 If no arbitration table is present, the VC Arbitration Table Offset field must
be RO and return 0.
CFG.17.04#01 7.17.4 For all devices when the selected VC Arbitration uses the VC Arbitration
Table, the Load VC Arbitration Table bit must be RW and always returns 0.
CFG.17.04#02 7.17.4 For all devices that the selected VC Arbitration uses the VC Arbitration
Table, setting the Load VC Arbitration Table bit must cause hardware to load
new settings from the VC Arbitration table.
CFG.17.04#04 7.17.4 The VC Arbitration Select field must be RW. Only values corresponding to
one of the asserted bits in the VC Arbitration Capability field are valid.
CFG.17.04#05 7.17.4 Hardware must use the mode written to the VC Arbitration Select field for
VC arbitration of the LPVC group.
CFG.17.04#06 7.17.4 The VC Arbitration Select field must not change when more than one VC in
the LPFC group is enabled.
CFG.17.04#07 7.17.4 Port VC Control register bits 4-15 must be implemented as RsvdP.
CFG.17.05#01 7.17.5 The VC Arbitration Table Status bit must be RO, defaulting to 0.
CFG.17.05#02 7.17.5 For all devices when the selected VC Arbitration uses the VC Arbitration
Table, hardware must set the VC Arbitration Table Status bit whenever
software modifies any entry of the VC Arbitration Table.
CFG.17.05#03 7.17.5 For all devices when the selected VC Arbitration uses the VC Arbitration
Table, hardware must clear the VC Arbitration Table Status bit whenever it is
finished downloading new values to the VC Arbitration Table, after software
sets the Load VC Arbitration.
CFG.17.05#04 7.17.5 Port VC Status register bits 1-15 must be implemented as RsvdZ.
CFG.17.06#01 7.17.6 For VCs, the Function Arbitration Capability field must be RO accurately
indicate the types of function arbitration supported by the VC resource.
CFG.17.06#02 7.17.6 VC Resource Capability register bits 8-15, 23 must be implemented as
RsvdP.
CFG.17.06#03 7.17.6 If the Function Arbitration Capability indicates the VC resource supports
WRR Function Arbitration, than the Maximum Time Slots field must be
HwInit and must accurately indicate the maximum number of time slots
(minus one) that the VC resource is capable of supporting when configured
for WRR Function Arbitration.
CFG.17.06#04 7.17.6 The Function Arbitration Table Offset field must be RO and must accurately
indicate the offset of the table (if one exists) in DQWORDS from the base
address of the MFVC capability.

86
 ENDPOINT COMPLIANCE CHECKLIST FOR THE PCI EXPRESS BASE 1.1 SPECIFICATION,
REVISION 1.1

ID Ref Assertion Y N
CFG.17.06#05 7.17.6 The Function Arbitration Table Offset field must be set to zero if no
arbitration table is present.
CFG.17.07#01 7.17.7 Bit 0 of the TC/VC Map field must be RO. It must be set to 1 for the default
VC0 and set to 0 for all other enabled VCs.
CFG.17.07#02 7.17.7 Bits 1-7 of the TC/VC Map field must be RW.
CFG.17.07#03 7.17.7 The default value of the TC/VC Map field for the first VC resource must be
FFh.
CFG.17.07#04 7.17.7 The default value of all TC/VC Map fields for all VC resources except the
first VC resource must be zero.
CFG.17.07#05 7.17.7 Hardware must accurately use the TC/VC Map field value to determine
which TCs are mapped to this VC (Bit 7 corresponds to TC7, Bit 0
corresponds to TC0).
CFG.17.07#06 7.17.7 Software must ensure that no new or outstanding transactions with the TC
labels are targeted at the given link, before it can remove TCs from the
TC/VC Map of an enabled VC.
CFG.17.07#07 7.17.7 VC Resource Control register bits 8-15, 20-23, 27-30 must be implemented
as RsvdP.
CFG.17.07#08 7.17.7 Setting the Load Function Arbitration field must cause hardware to update
the function arbitration logic from the Function Arbitration Table for the VC
resource, if the table is used by the current arbitration scheme. Reads of this
bit always return 0.
CFG.17.07#09 7.17.7 Software must check the Function Arbitration Table Status bit to confirm that
new values written to the Function Arbitration Table have been latched into
the hardware.
CFG.17.07#10 7.17.7 The Function Arbitration Select field must be RW. Only values
corresponding to one of the asserted bits in the Function Arbitration
Capability field are valid.
CFG.17.07#11 7.17.7 The hardware must latch and use the function arbitration scheme written to
the Function Arbitration Select field.
CFG.17.07#12 7.17.7 The VC ID for the first VC resource must be RO, hard-wired to 0.
CFG.17.07#13 7.17.7 The VC ID field for other than the first VC resource, must be R/W.
Hardware must use the VC ID value for the VC when it is enabled if it is not
the first VC resource.
CFG.17.07#14 7.17.7 The VC ID field must not change when the VC is already enabled.
CFG.17.07#15 7.17.7 The VC Enable field must be hard-wired to 1, for the first VC resource.
CFG.17.07#16 7.17.7 The VC Enable field must be RW and must default to 0 for all except the first
VC resource.
CFG.17.07#17 7.17.7 Software must check the VC Negotiation Pending bit is clear, before reading
the VC Enable bit to determine if the VC is initialized.
CFG.17.07#18 7.17.7 The VC Enable bit must accurately indicate if the VC is enabled (Flow
Control initialization is completed) when read. (1 = enabled).
CFG.17.07#19 7.17.7 Writing a one to the VC Enable field must enabled a disabled VC (both sides
of the link must be updated).
CFG.17.07#20 7.17.7 Writing a zero to the VC Enable field must disable an enabled VC (both sides
of the link must be updated).
CFG.17.07#21 7.17.7 Software must program VC Enable bit on both sides of the link when
enabling or disabling the VC.
CFG.17.07#22 7.17.7 Software must ensure that no traffic is using a VC at the time it is disabled.
CFG.17.07#23 7.17.7 Software must fully disable a VC (on both components) before re-enabling it.
CFG.17.08#01 7.17.8 If the Function Arbitration Table is used by the selected Function Arbitration
for the VC, the Function Arbitration Table Status field must be RO and must
be set by hardware whenever any entry in the Function Arbitration table is
written by software.

87
 ENDPOINT COMPLIANCE CHECKLIST FOR THE PCI EXPRESS BASE 1.1 SPECIFICATION,
REVISION 1.1

ID Ref Assertion Y N
CFG.17.08#02 7.17.8 If the Function Arbitration Table is used by the selected Function Arbitration
for the VC, hardware must clear the Function Arbitration Table Status after it
finishes loading values stored in the Function Arbitration Table, after
software sets the Load Function Arbitration Table field.
CFG.17.08#03 7.17.8 The VC Negotiation Pending field must be RO and must be set by hardware
whenever the VC resource has not completed the process of negotiation.
CFG.17.08#04 7.17.8 The VC Negotiation Pending field must be cleared by hardware after the VC
resource has completed the process of negotiation.
CFG.17.08#05 7.17.8 Software must check that the VC Negotiation Pending field is clear on both
sides of the link before using the VC.
CFG.17.08#06 7.17.8 VC Resource Status register bits 2-15 must be implemented as RsvdZ.
CFG.17.09#01 7.17.9 For devices that select VC Arbitration using WRR table, the VC Arbitration
Table is RW made up of 4 bit fixed size entries.
CFG.17.09#02 7.17.9 For devices that select VC Arbitration using WRR table, each 4 bit entry
corresponds to one phase of the WRR arbitration period. The lower 3 bits of
each entry is a valid VC ID (the VC must be enabled) that would be used
during that WRR arbitration period. The upper bit of each entry is reserved.
CFG.17.09#03 7.17.9 The length of the VC Arbitration Table is determined by the value in the VC
Arbitration Select field.
CFG.17.09#04 7.17.9 If the default VC resource uses a default VC Arbitration method that uses the
VC Arbitration Table the table must contain all zeros by default.
CFG.17.10#01 7.17.10 If the Function Arbitration Table is used by the selected Function Arbitration
for the port, the Function Arbitration Table is RW.
CFG.17.10#02 7.17.10 The length of the Function Arbitration Table is determined by the value in
the Function Arbitration Select field.
CFG.17.10#03 7.17.10 If the default VC resource uses a default Function Arbitration method that
uses the Function Arbitration Table the table must contain at least one entry
for each active function in a multi-function device.
CFG.18.00#02 7.18 Vendor Specific registers must start at byte offset 08h in the PCI Express
VSEC Structure.
CFG.18.01#01 7.18.1 The PCI Express Extended Capability ID field for the Vendor-Specific
Capability is 000Bh and must be RO.
CFG.18.01#02 7.18.1 For the Vendor-Specific capability, the Capability Version must be RO and
must return 1h for devices implemented to the PCI Express Specification,
Revision 1.1.
CFG.18.02#02 7.18.2 The VSEC ID field must be RO and must be a vendor-defined ID number
that indicates the format of the VSEC structure.
CFG.18.02#03 7.18.2 The VSEC Rev field must be RO and must be a vendor-defined version
number that indicates the revision of the VSEC structure.
CFG.18.02#04 7.18.2 The VSEC Length field must be RO and must indicate all the bytes in the
PCI Express Enhanced capability Header + Vendor-Specific Header +
Vendor-Specific registers.

88
 ENDPOINT COMPLIANCE CHECKLIST FOR THE PCI EXPRESS BASE 1.1 SPECIFICATION,
REVISION 1.1

Explanations:
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
__________________________________________________________
__________________________________________________________
__________________________________________________________
__________________________________________________________
__________________________________________________________
This section should be used to clarify any answers on checklist items above. Please key explanation to item number.

89