Transaction Layer Test Considerations Revision 1djm202/pdf/specifications/pcie/...TRANSACTION LAYER...

PCI ExpressTM Architecture

Transaction Layer Test Considerations

Revision 1.0

April 26, 2004

TRANSACTION LAYER TEST CONSIDERATIONS, REVISION 1.0

2

Revision History

Revision Issue Date Comments

1.0 4/26/2004 Initial release.

PCI-SIG 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 PCI-SIG make a commitment to update the information contained herein.

Contact the PCI-SIG office to obtain the latest revision of this document.

Questions regarding this document or membership in PCI-SIG may be forwarded to:

Membership Services www.pcisig.com E-mail: [email protected] Phone: 503-291-2569 Fax: 503-297-1090 Technical Support [email protected]

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. 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.

PCI Express is a trademark of PCI-SIG.

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

Copyright © 2004 PCI-SIG


3

Contents 1. INTRODUCTION ...............................................................................................................................................5

2. TEST ASSERTIONS...........................................................................................................................................7 2.1 TABLE OF ASSERTIONS...................................................................................................................................7

3. GENERAL TEST OVERVIEW AND TOPOLOGY .....................................................................................11

4. MACROS ...........................................................................................................................................................13 4.1 OVERVIEW....................................................................................................................................................13

4.1.1 Integer MACRO_GetDUT_VCCapsStructure ....................................................................................13 4.1.2 Integer Macro Poll_HotPlugCmdComplete (Integer Slot_Num).........................................................13 4.1.3 Integer MACRO Check_NativeHotPlug_Capable (Integer Slot_Num) ...............................................14

5. TEST DESCRIPTIONS ....................................................................................................................................15 5.1 TRANSACTION BASIC FUNCTIONAL TEST .....................................................................................................15

5.1.1 Test 1 .1 TXN_BFT_RequestCompletion ..........................................................................................15 5.1.2 Test 1.2 TXN_BFT_CompletionTimeout ..........................................................................................16

5.2 BASELINE MESSAGE BASIC FUNCTIONAL TEST............................................................................................17 5.2.1 Test 2.1 TXN_BFT_LegacyInt ..........................................................................................................17 5.2.2 Test 2.3 TXN_BFT_NativeHotPlug ..................................................................................................18 5.2.3 Test 2.4 TXN_BFT_ErrorSignaling .................................................................................................20

5.3 LINK INITIALIZATION BASIC FUNCTIONAL TEST..........................................................................................21 5.3.1 Test 3.1 TXN_BFT_FlowControlInit ................................................................................................21 5.3.2 Test 3.4 TXN_BFT_NegotiatedLinkWidth ...........................................................................................22

5.4 VIRTUAL CHANNEL BASIC FUNCTIONAL TEST .............................................................................................23 5.4.1 Test 5.1 TXN_BFT_VC0TCSupport .................................................................................................23


4


5

1. Introduction This document contains a list of Test Assertions and a set of Test Definitions pertaining to the Transaction Layer. Assertions are statements of spec requirements which are measured by the algorithm details as specified in the Test Definitions. “Basic Functional Tests” are Test Algorithms which perform basic tests for key elements of Transaction Layer device functionality. This document does not describe a full set of PCI Express tests and assertions and is in no way intended to measure products for full design validation. Tests described here should be viewed as tools to checkpoint the result of product validation – not as a replacement for that effort.

Devices must also meet the applicable requirements and tests described in the following documents as well as any tests provided by the PCI-SIG:

Electrical Test Considerations for PCI Express Architecture

Config Space Test Considerations for PCI Express Architecture

Platform Bios Test Considerations for PCI Express Architecture

Link Test Considerations for PCI Express Architecture


6


7

2. Test Assertions Note: N/A in the “Test ID” column simply means that a Test Description which measures that Assertion is not included with this Revision of this Test Document. A future revision of this (or another) Test Document may include Test Definitions to cover these Assertions. Regardless of whether or not a Test Description is provided, these Assertions still represent required criteria.

2.1 Table of Assertions

Assertion ID Assertion Description Test ID

Transaction Layer Protocol/Packet Definition

TXN.2.0#2 All TLP fields marked Reserved “R” in the Base Spec. must be filled with all 0’s when a TLP is formed. N/A

Transaction Descriptor – Transaction ID Field

TXN.2.7#9

Functions must capture the Bus and Device Numbers supplied with all Configuration Write Requests (Type 0) completed by the function and supply these numbers in the Bus and Device Number fields of the Requester ID for all Requests initiated by the device/function Test 1.1

INTx Interrupt Signaling

TXN.2.13#1 The INTx messages must adhere to the encoding defined in Table 2-12 of the Base Spec. N/A

TXN.2.13#3 Assert_INTx/Deassert_INTx Messages do not include a data payload (TLP Type is Msg) Test 2.1

TXN.2.13#4 The TLP Header Length field is reserved for INTx Signaling messages Test 2.1

TXN.2.13#7 Assert_INTx and Deassert INTx interrupt Messages must use the default Traffic Class designator (TC0). Test 2.1

TXN.2.13#10 An Assert_INTx represents the active going transition of the INTx (x = A, B, C, or D) virtual wire Test 2.1

TXN.2.13#11 A Deassert_INTx represents the inactive going transition of the INTx (x = A, B, C, or D) virtual wire Test 2.1

TXN.2.13#13 INTx Interrupt Signaling is disabled with the Interrupt Disable bit of the Command Register Test 2.1

TXN.2.13#14

Any INTx virtual wires that are active when the Interrupt Disable bit is set must be deasserted by transmitting the appropriate Deassert_INTx Message(s) Test 2.1

TXN.2.13#21

The Requester ID of an Assert INTx/Deassert INTx Message will correspond to the Transmitter of the message on that Link (not necessarily to the original source of the interrupt) Test 2.1

Error Signaling Messages

TXN.2.15#1 Error Signaling Messages must comply with the encoding in Base Specification Table 2-15. N/A

TXN.2.15#2 Error Signaling Messages do not include a data payload (TLP Type is Msg). Test 2.4


8


TXN.2.15#3 Within Error Signaling Messages the TLP Header Length field is Reserved.

Test 2.4_Test_2.4_TXN_BFT_ErrorSignaling

TXN.2.15#4 Error Signaling Messages must use the default Traffic Class designator (TC0) Test 2.4

Native Hot Plug Signaling

TXN.2.19#4 Hot Plug Signaling Messages must comply with the encoding in Base Specification Table 2-19 N/A

TXN.2.19#1

Components must accept received hot plug signaling messages as defined in the Support column of Base Specification, Table 2-19 without indicating an error. Test 2.3

Completions

TXN.2.21#15

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. Test 1.1

TXN.2.21#19

Completion headers must supply the same values for the Requester ID, Tag, Attribute and Traffic Class as were supplied in the header of the corresponding Request Test 1.1

Request Handling

TXN.3.1#1 A Request Type which is not supported by the device is an Unsupported Request and is reported according to Base Specification Section 6.2 Test 1.1

TXN.3.1#2

For Unsupported Requests requiring Completion, a Completion Status of UR is returned Test 1.1

Virtual Channel (VC) Mechanism

TXN.5.0#3

PCI Express Completers that do not implement the optional PCI Express Virtual Channel Capability Structure must accept requests with TC label other than TC0 Test 5.1

TXN.5.0#4

PCI Express Completers 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 Request Test 5.1

TXN.5.0#5 Switches that do not implement the optional PCI Express Virtual Channel Capability Structure must map all TCs to VC0 N/A

TXN.5.0#6

Switches that do not implement the optional PCI Express Virtual Channel Capability Structure must forward all transactions regardless of the TC Label N/A

Virtual Channel Identification (VC ID)

TXN.5.1#1

All PCI Express Ports that support more than VC0 must provide the VC Capability Structure according to the definition in Base Specification Section 7.11 Test 3.1

TXN.5.1#4 VC ID 0 is assigned and fixed to the default VC N/A


9


Flow Control Rules

TXN.6.1#1 Flow Control information is transferred using Flow Control Packets (FCPs)(see Base Specification Section 3.4) Test 3.1

TXN.6.1#14 InitFC1 and InitFC2 FCPs are used for Flow Control initialization (see Base Specification, Section 3.3) Test 3.1

TXN.6.1#16

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 Base Specification, Table 2-27. Test 3.1

Completion Timeout Mechanism

TXN.8.0#1.1 Completion Timeout support is required of Endpoint devices Test 1.2

TXN.8.0#2

The PCI Express elements that are capable of initiating Requests that invoke Completions must implement Completion Timeout mechanism. An exception is made for Configuration Requests Test 1.2

TXN.8.0#3

The Completion Timeout timer must not expire (i.e., cause a timeout event) in less than 50 µs. It is strongly recommend that unless an application requires this level of timer granularity the minimum time should not expire in less than 10 ms Test 1.2

TXN.8.0#4 The Completion Timeout timer must expire if a Request is not completed in 50 ms Test 1.2

TXN.8.0#5 A Completion Timeout is a reported error associated with the Requestor device/function Test 1.2

Link Width Negotiation

EM.6#4

A x8 add-in card (and endpoint) must operate as a x4 card (and endpoint) when plugged into a x8 connector that has only the first four lanes routed. Test 3.4

EM.6#3

All PCI Express cards and slots must meet the interoperability requirements as defined in Section 6.3 of the PCI Express Card Electromechanical Specification Test 3.4


10


11

3. General Test Overview and Topology

FPGA RAM

PGM

Mid-bus Probe

USBMid-bus Probe

Figure 1.0 - Transaction Layer Basic Test Topology

Protocol Test Card

Transaction Layer

Link Layer

Physical Layer

DUT

Test Control Initiates Test Traffic.Traffic is Monitored and Injected Through the USB Port. Mid Bus Probe Points Allow Any Protocol

Analyzer to be Connected for Broader Test Analysis.

Protocol Analyzer

USB

PCI Express

Test Control

Figure 1


12


13

4. MACROS

4.1 Overview

4.1.1 Integer MACRO_GetDUT_VCCapsStructure Description: Read the VC Capabilities Structure from the DUT and return a count of VCs supported by the DUT beyond the required/default VC0.

Algorithm :

• Attempt to locate the Virtual Channel Capability Structure in DUT configuration space

• If found {

o Read the Extended VC Count from the Port VC Capability Register 1 o Return (VC Count +1)

• } Else Return (0)

4.1.2 Integer Macro Poll_HotPlugCmdComplete (Integer Slot_Num) Description: This macro polls the Slot Status Register of the Slot number Slot_Num for Native Hot Plug command complete status (bit offset 4).

Input Arguments: Integer Slot_Num – the physical number of the slot to check

Return Values: Integer

1 = slot at Slot_Num has posted command complete

0 = slot at Slot_Num has not posted command complete

-1 = Slot_Num exceeds highest numbered slot within chassis

Algorithm:

• Scan the PCI Express Capabilities lists to locate each of the slots in the system {

o Read the Slot Capabilities Register to determine if it’s a match for Slot_Num { If it is a match for Slot_Num {

• Poll the Slot Status Register for command complete (bit 4) for 1 second

• If command complete not set within 1 second

o return (0) • Else {

o Write 0 to the Slot Status Register bit offset 4 to clear command complete

o return (1) }

} else continue slot scan

} continue scan

} Scan complete, unable to locate Slot_Num – return (-1)


14

4.1.3 Integer MACRO Check_NativeHotPlug_Capable (Integer Slot_Num) Description: This macro expects that physical slots are sequentially numbered from 1 to the highest numbered slot within the chassis (physical slots are prevented by the Base Spec. from being assigned a value of 0). The macro checks the physical slot number Slot_Num to see if it supports Native Hot Plug.

Input Arguments: Integer Slot_Num – the physical number of the slot to check

Return Values: Integer

1 = slot at Slot_Num supports Native Hot Plug

0 = slot at Slot_Num does not support Native Hot Plug

-1 = Slot_Num exceeds highest numbered slot within chassis

Algorithm:

• Initialization: scan the PCI Express Capabilities lists to locate all of the slots in the system

• Initialization: read the Slot Capabilities Registers of all slots and build a static NativeHotSlot_Num table of all Native Hot Plug capable slots in the system – put the slot numbers of those slots in this table

• When called: search the NativeHotSlot_Num table for Slot_Num and return the appropriate value from above Return Values list


15

5. Test Descriptions

5.1 Transaction Basic Functional Test This test measures basic Transaction Layer functionality requirements of slotted Endpoint devices.

5.1.1 Test 1 .1 TXN_BFT_RequestCompletion Abstract: Verify Basic Request and Completion handling of slotted Endpoint devices.

Assertion Coverage: TXN.2.7#9, TXN.2.21#15, TXN.2.21#19, TXN.3.1#1, TXN.3.1#2

Topology Configuration: Transaction Layer Basic Test Topology.

Notes: This test requires a device specific application to issue requests from the DUT.

Test Algorithm:

1. Test Control: Initialize the Protocol Test Card buffers (clear them) and program the Test Card to capture TLP Headers for Completions arriving at downstream ports (arriving from the DUT).

2. Test Control: Issue a Type 0 Configuration Write Request to the DUT.

a) Store the Bus and Device numbers supplied in the request for checking against subsequent Requests from the DUT, as well as Completions from the DUT (Request/Completion ID).

b) Receive a successful Completion for the Configuration Write request from the DUT and verify that the Completer ID field contains the Bus and Device numbers supplied with the Configuration Write Request in Step 1 (TXN.2.21#15).

c) Verify the Completion Header for the Configuration Write Request (TXN.2.21#19):

• Using a protocol analyzer in-line, manually/visually verify Requester ID, Tag, Attribute and Traffic Class are equal to what was issued with the Configuration Write Request Header.

3. Test Control: program the PTC to capture TLP Headers for Requests arriving at downstream ports (initiated by the DUT)

4. DUT: Initiate a series of request TLPs to the Test Control.

5. Test Control: handle the requests.

6. Test Control: read the captured TLP Headers from the Test Card and verify that the Bus and Device Numbers supplied with the Configuration Write Request to the DUT (step 2) are now present in Requester ID of the Requests from the DUT (TXN.2.7#9).

7. Test Control: program the PTC to capture TLP Headers for Completions arriving at downstream ports (arriving from the DUT)

8. Test Control: Issue a series of Vendor_Defined type 0 Request TLPs to the DUT (Base Spec. reference Table 2-18). Note: a range of Req IDs should be chosen for this series of TLPs such that at least one in the range would trigger a UR status at the DUT: {0h, 07fh, 0ffh}

9. Test Control: read the captured TLP Completions from the Test Card

a) Verify that the DUT returns UR status completion for the request issued in step 8 (TXN3.1#1, TXN3.1#2).

b) Verify that the Completer ID field of (unsuccessful) Completion contains the Bus and Device numbers supplied with the Configuration Write Request in Step 2 (TXN.2.21#15).


16

c) Verify that the Requester ID, Tag, Attribute and Traffic Class in the Completion are the same as what was supplied in the Request (TXN.2.21#19).

5.1.2 Test 1.2 TXN_BFT_CompletionTimeout Abstract: Verify Basic Completion Timer requirements of a slotted Endpoint device. The Completion Timeout timer must not expire in less than 50 µs, however, the Completion Timeout timer must expire if a Request is not completed in 50 ms.

Assertion Coverage: TXN.8.0#1.1, TXN.8.0#2, TXN.8.0#3, TXN.8.0#4, TXN.8.0#5

Topology Configuration: Transaction Layer Basic Test Topology. Test Control is located at an upstream port of the Test Card, the DUT is at a downstream port of the Test Card.

Notes: This test requires a device specific application to issue requests from the DUT. This test delays Non-posted requests from the DUT in order to force completion time-outs. In order to detect the type of Non-posted requests a DUT may issue (so that the PTC may be programmed to delay them), the following algorithm for PTC setup can be used:

a) Program PTC to capture TLPs arriving at downstream ports and clear the Trace Buffer

b) Program the PTC to generate an ACK_NAK_DELAY_LEGAL for CONFIG_RED_REQ

c) Issue a CONFIG_RD Req to the DUT after capturing traffic for 1 ms

d) Examine the PTC TB for Non-posted requests issued by the DUT

Test Algorithm:

1. Test Setup: program the PTC to capture TLPs arriving at upstream ports and clear the trace buffer on the PTC.

2. DUT: Issue two non-posted requests, back-to-back (no delay between them) to the Test Control.

• Test Control: return completion immediately for each request.

3. Test Control: Read the PTC trace buffer for the two TLPs (completions for requests in step 2); calculate Req_Resp_Delay as the delta between the two TLP trace buffer timestamps and convert to microseconds.

4. Test Control: Clear the error reporting register on the DUT (Device Status Register – Correctable Error Detected bit)

5. Test Control: Program the Test Card to delay Completion responses (PTC Command: delay TLP) arriving at upstream ports for (49 – Req_Resp_Delay) µs before forwarding them to downstream ports.

6. Test Control: Verify that the DUT Device Status Register Correctable Error Detected bit is clear (no error reported)

7. DUT: Issue a non-posted request to the Test Control

8. Test Control: receive the Request from the DUT and immediately send the Completion to the DUT.

9. Test Control: Wait 11 milliseconds, then verify that the DUT Device Status Register Correctable Error Detected bit is clear (no error reported). (TXN.8.0#3)

• Note: if an error is reported here, then steps 4-9 should be repeated, adding an incremental delta to Req_Resp_Delay (Delay TLP) to identify the window of variance for the DUT req/resp. times.


17

10. Test Control: program the Test Card to delay Completion responses arriving at upstream ports for ((50 – Req_Resp_Delay)milliseconds +1µs) before forwarding them to downstream ports.

11. DUT: Issue a non-posted request to the Test Control

12. Test Control: receive the request and immediately send a completion to the DUT.

13. Test Control: verify that the DUT Device Status Register Correctable Error Detected bit is set (error reported). (TXN.8.0#2, TXN.8.0#4, TXN.8.0#5)

5.2 Baseline Message Basic Functional Test

5.2.1 Test 2.1 TXN_BFT_LegacyInt Abstract: Verify Basic INTx message support requirements of slotted Endpoint devices.

Assertion Coverage: TXN.2.13#3, TXN.2.13#4, TXN.2.13#7, TXN.2.13#10, TXN.2.13#11, TXN.2.13#13, TXN.2.13#14, TXN.2.13#21

Topology Configuration: Transaction Layer Basic Test Topology

Notes: This test requires a device specific application to assert INTx from the DUT.

Test Algorithm:

1. Test Control: verify that the DUT is INTx interrupt capable (note: an abort at any of the steps 1a through 1c does not represent a failure since INTx support is not required – if implemented however, the DUT must comply with the remainder of the Assertions covered by this test):

a) If the DUT Interrupt Pin Register value is not between 1 and 4 (inclusive) then DUT is not INTx enabled, report and abort test.

b) If the DUT Interrupt Disable Bit is set (01b) then DUT is not INTx enabled, report and abort test.

c) If the DUT Message Control Register MSI Enable Bit is set (01b) then DUT is not INTx enabled, report and abort test.

d) Otherwise store DUT INTx usage (1=IntA, 2=IntB etc.) read from the Interrupt Pin Register and continue.

2. Test Control: Initialize the Protocol Test Card buffers (clear them) and program the Test Card to capture and filter INTx messages.

3. DUT: using a device specific mechanism, force the DUT to send an Assert_INTx message for one of the Interrupts it supports

4. Protocol Test Card: Capture, buffer and filter the DUT Assert_INTx message, preventing the message from being transmitted through the Test Card on an upstream port.

5. Test Control: while DUT is still asserting INTx, set the DUT Interrupt Disable Bit, disabling future Interrupt generation from the DUT. Note: at this point the DUT should send a Deassert_INTx message (TXN.2.13#14)

6. Protocol Test Card: Capture, buffer and filter the DUT Deassert_INTx message, preventing the message from being transmitted on an upstream port.

7. DUT: using a device specific mechanism, force the DUT to attempt to raise the same interrupt which resulted in Assert_INTx being sent previously (step 3)


18

8. Test Control: read the buffered TLP Headers from the Test Card and verify that the DUT has sent a single and appropriately mapped Assert_INTx message (TXN.2.13#10) with correct message format (TXN.2.13#7, TXN.2.13#3, TXN.2.13#4, TXN2.13#21) and that the DUT has sent a single and appropriately mapped Deassert_INTx Message (TXN.2.13#14)

5.2.2 Test 2.3 TXN_BFT_NativeHotPlug Abstract: Verify basic Native Hot Plug message support requirements and related functionality of slots and slotted endpoint adapters.

Assertion Coverage: TXN.2.19#1

Topology Configuration: This test does not require the PTC card. A slotted adapter must be plugged directly into a Native Hot Plug capable slot on the system baseboard. Test Control software modifies/monitors configuration space registers (below 0ffh legacy boundary) on the RC and slotted endpoint in order to drive and verify test results, respectively.

Notes: The system is powered up prior to this test and the Adapter is inserted into an empty Native Hot Plug slot during this test. An abort of the test at step 1a does not indicate a test failure as Native Hot Plug functional support is slot optional. If an adapter supports Native Hot Plug LEDs and/or Attention Button, these should function even if primary power is disabled to the slot. The adapter device control register can only be read when power is applied to the slot (step 7d) – even if an adapter does not support LED functionality, it must discard related commands without reporting an error (ignore them). This test requires interaction with a Test Operator in order to verify the command related actions of the LEDs. The algorithm below allows a test operator to verify the functional correctness of the adapter (DUT) as well as any or all of the Native Hot Plug slots in the system.

Test Algorithm:

1. Test Control: Use MACRO Check_NativeHotPlug_Capable() to build a table of Slot_Num values representing the Native Hot Plug capable slots in this system

a. If the Slot_Num value table is empty – this test does not apply to this system, report no native hot plug slots and abort the test

2. Test Control: Prompt the test operator to either choose an empty Native Hot Plug capable slot from the table of slots in step 1 or to exit this test; wait for user input Slot_Num

a. If user chooses to exit the test: cleanup, restore control register states and exit; else continue

b. Check Slot_Num Slot Status Register bit 6, Presence Detect State Bit – if the slot is not empty, notify the test operator and go back to top of step 2

3. Test Control: Initialize slot control

a. Disable Command Complete Interrupts by writing 0 to the Slot Control Register bit offset 4

b. Clear the Slot_Num command complete bit: MACRO Poll_HotPlugCmdComplete( Slot_Num )

c. Disable power to the Slot_Num by writing 1 to the Slot Control Register bit offset 10;

d. Disable attention button events (to system software) by writing 0 to the Slot Control Register bit 0 Attention Button Pressed Enable

e. If ( MACRO Poll_HotPlugCmdComplete( Slot_Num ) != 1) then report command complete test failure and go to step 2


19

4. Test Control: prompt test operator to insert the DUT into the Slot_Num slot; Poll the Slot_Num Slot Status Register bit 6, Presence Detect State Bit for up to 1 minute

a. If the polling loop exits and Presence Detect State Bit is not 1 (indicating presence of a card in the slot) then report presence detect test failure and go to step 2

5. Test Control: Enable power to the Slot_Num slot (write 0 to the Slot Control Register bit offset 10)

a. If ( MACRO Poll_HotPlugCmdComplete( Slot_Num ) != 1) then report command complete test failure and go to step 2

6. Test Control: read the DUT Device Status Register

a. If the DUT is reporting any errors (bits 0 – 3 inclusive), report the errors and go to step 2

7. Test Control: For each of the Native Hot Plug Commands {

i. Attention_Indicator _On

ii. Attention_Indicator_Blink

iii. Attention_Indicator_Off

iv. Power Indicator_On

v. Power_Indicator_Blink

vi. Power Indicator_Off

} Do steps a through d below:

a. notify the test operator of the Hot Plug Command from the above list which is about to be performed

b. Write to the Slot_Num Slot Control Register to perform the related command and issue the related Hot Plug Message to the DUT

i. If ( MACRO Poll_HotPlugCmdComplete( Slot_Num ) != 1) then report command complete test failure and go to step 2

c. Prompt test operator for visual confirmation that LED has been altered correctly; wait for operator confirmation

i. If LED has not been altered correctly – Report Test Failure; and cleanup/abort test

d. If Slot_Num slot power is enabled (Slot Control Register Bit offset 10) then

i. Read the DUT Device Status Register

ii. If the DUT is reporting any errors (bits 0 – 3 inclusive) - Report Test Failure and goto step 2 (TXN.2.19#1)

8. Test Control: Clear the Slot Status RegisterAttention Button Pressed Bit 0 for Slot_Num (button state)

9. Test Control: Prompt the Test Operator to depress the attention button at slot Slot_Num

a. Poll the Slot_Num Slot_Status Register for up to 1 minute, waiting for the Attention Button Pressed Bit to be set to 1

b. If the polling loop exits and the Attention Button Pressed bit is not set to 1, report attention button test failure and goto step 2


20

10. Test Control: If Slot_Num slot power is enabled (Slot Control Register Bit offset 10)

a. Disable power to the Slot_Num slot by writing 1 to the Slot Control Register bit offset 10;

b. If ( MACRO Poll_HotPlugCmdComplete( Slot_Num ) != 1) then report command complete test failure and go to step 2

c. Else notify test operator that testing is now with slot power disabled - goto step 7.

(Note: this 2nd loop checks to see that the power/attention LEDs and attention button on the adapter still function correctly when slot power is off.)

11. Test Control: Else go to step 2

5.2.3 Test 2.4 TXN_BFT_ErrorSignaling Abstract: Verify Basic Signaling functionality and message generation of a slotted Endpoint device.

Assertion Coverage: TXN.2.15#2, TXN.2.15#3, TXN.2.15#4

Topology Configuration: Transaction Layer Basic Test Topology. Test Control is located at an upstream port of the Test Card, the DUT is at a downstream port of the Test Card.

Notes: This test corrupts the TLP as it passes through the PTC by applying the edit mask – effectively injecting signaling errors: ERR_COR, ERR_NONFATAL, ERR_FATAL.

Test Algorithm:

1. Test Control: Hot Reset the DUT Link

2. Test Control: Program the DUT through config. Space (Device Capabilities Register) to report correctable, non-correctable fatal and non-fatal errors.

3. Test Control: Clear the Error Reporting Status bits in the Device Status Register (bits 0-3 inclusive)

4. Test Control: Initialize the Protocol Test Card buffers (clear them) and program the Test Card to capture and filter error signaling TLPs (see Base Spec. table 2-15) at downstream ports.

5. Test Control: Program the Test Card (edit mask) to issue a Bad TLP (bad Seq. number) to the DUT (ERR_COR)

6. Test Card: Arm/Execute/Disarm

7. Test Control: Program the Test Card (edit mask) to issue a Poisoned TLP to the DUT (ERR_NONFATAL) - clear the previous Test Card command


9. Test Control: Program the Test Card (edit mask) to issue a Malformed TLP (data/length field mismatch) to the DUT (ERR_FATAL) – clear the previous Test Card command


11. Test Control: read the Test Card trace-buffer and verify that there are 3 TLPs of proper format, received in the proper order (reception should match order of test steps 5-10 above) – one for each ERR_COR, ERR_NONFATAL and ERR_FATAL in proper sequence (TXN.2.15#2, TXN.2.15#3, TXN.2.15#4)

a. Read and verify the setting of the Error Reporting Status bits in the DUT Device Status Register (ERR_COR, ERR_NONFATAL and ERR_FATAL recorded in these status bits)


21

5.3 Link Initialization Basic Functional Test

5.3.1 Test 3.1 TXN_BFT_FlowControlInit Abstract: Verify that a slotted Endpoint device Receiver complies with basic flow control credit advertisement requirements.

Assertion Coverage: TXN.6.1#14, TXN.6.1#16, TXN.5.1#1


Notes: Although this is not the primary intent of this test, on completion of this test the DUT has successfully completed VC Link Training. This test can be used as a Basic functional test for VC link-up verification. Before a VC can be used for Transaction Layer (and above) testing, it must pass a basic link-up test such as this.

During Link Training, the DUT transmits a repeated series of 3 uninterrupted DLLPs advertising units of flow control credit (per. supported VC) as follows (see section 3.3.1 of Base Spec):

• 1st DLLP advertises credits for Posted request (PH, PD)

• 2nd DLLP advertises credits for Non-Posted requests (NPH, NPD)

• 3rd DLLP advertises credits for Completions (CplH, CplD)

Test Algorithm:

1. Test Control: Initialize the Protocol Test Card buffers (clear them) and program the Test Card to capture and filter InitFC1 and InitFC2 DLLPs at downstream ports.

2. Test Control: Force a cold reset of the DUT Link

3. Protocol Test Card: record (for each VC) the flow control credit values transmitted by the DUT (InitFC1x DLLPs) (TXN.6.1#14).

4. Test Control: Read and store the value of Max_Payload_Size from the DUT Device Control Register.

5. Test Control: read the FC Credit values advertised by the DUT from the Test Card and using the value of the DUT Max_Payload_Size register (PD = Max_Payload_Size/16). (note: Base spec. table 2-27 re: FC Unit = 16)

• verify that the DUT advertises compliant flow control credits values for each supported VC (TXN.6.1#16)

6. Test Control: If the DUT advertises flow control credit values for VCs besides VC0:

a) VC_Count = MACRO_GetDUT_VCCapsStructure

b) Verify that the VC_Count matches the number of VCs reported by the DUT (InitFC1x DLLPs)

c) Traverse the DUT Virtual Channel Capability Structure (using VC Count to compute offsets) reading the VC Negotiation Pending bit for each of the VC Status Registers. Verify that the VC Negotiation Pending bit is clear (VC negotiation complete) for each of the VCs advertised by the DUT (TXN.5.1#1)


22

5.3.2 Test 3.4 TXN_BFT_NegotiatedLinkWidth Abstract: This test is used as a functional pre-requisite for measuring device readiness for Transaction Layer testing - it verifies that a card-edge slotted endpoint completes Link width negotiation successfully. Additionally, this test verifies that a x8 card-edge slotted endpoint completes Link width negotiation at x4 when plugged into a slot which is wired (to a root port) in support of a maximum of 4 lanes (x4).

Assertion Coverage: EM.6#4, EM.6#3

Topology Configuration: This test does not require the PTC card – the slotted adapter (DUT) must be plugged directly into a slot on the system baseboard.

Notes: The EM.6#4 assertion test is performed to verify that a x8 adapter downshifts to x4 when plugged into a baseboard connector of x8 width, which is only routed to x4 lanes. If a baseboard does not have this type of slot configuration, then that portion of this test does not apply (it is not a baseboard or Root Complex failure since the requirement is on the x8 adapter side to downshift to x4 in this configuration).

Test Algorithm:

1. Test Control: in order to identify maximum link width support (per. slot) to the test operator - using a configuration space read utility, read/report the port Link Capabilities Register: Maximum Link Width, on a per. slot basis. Store number of slots supported by the baseboard in NUM_Slots (loop control for step 2)

2. For DUTs of xN connector width, perform each of the following steps for each baseboard slot connector width >= xN, where xN is a member of the set {1, 4, 8, 16}

a. Test Control: Prompt test operator to insert the DUT into a (untested) slot.

1) Manual Procedure: Insert the DUT into the slot

b. Test Control: Force a Reset of the DUT Link

c. Test Control: Poll the baseboard slot Link Status Register:Link Training bit until it becomes 0 (link training complete).

1) Exit polling loop after no more than 5 seconds.

d. Test Control: read the DUT Link Capabilities Register: Maximum Link Width (DUT_Link_Max)

1) IF the configuration read fails, the test operator should assure that the DUT has successfully completed Link Initialization (by running TXN_BFT_FlowControlInit). Report and abort test.

e. Test Control: read the DUT Link Status Register: Negotiated Link Width (DUT_Link_Negotiated)

f. Test Control: read the baseboard slot Link Capabilities Register: Maximum Link Width (Slot_Link_Max)

g. Test Control: read the baseboard slot Link Status Register: Negotiated Link Width (Slot_Link_Negotiated)

1) IF DUT_Link_Negotiated is not equal to Slot_Link_Negotiated, then report error (EM.6#3) and abort test

h. Test Control: IF DUT_Link_Max is equal to Slot_Link_Max :

1) IF DUT_Link_Negotiated is not equal to Slot_Link_Max, then report error (EM6#3) and abort test


23

i. Test Control: ELSE IF DUT_Link_Max is equal to x8 (01000b) AND Slot_Link_Max is equal to x4 (0100b) :

1) IF DUT_Link_Negotiated is not equal to x4 (0100b) then report error (EM.6#4) and abort test

j. Test Control: ELSE:

1) IF DUT_Link_Negotiated is not equal to x1 (01b) then report error (EM.6#3) and abort test

k. Test Control: report test pass status for this slot. IF all slots have been tested (NUM_Slots), then exit test – otherwise continue at top of loop (2.a).

5.4 Virtual Channel Basic Functional Test

5.4.1 Test 5.1 TXN_BFT_VC0TCSupport Abstract: Verify that slotted Endpoint devices which do not support VCs beyond the default, still handle requests with non-zero TC correctly

Assertion Coverage: TXN.5.0#3, TXN.5.0#4


Notes:

Test Algorithm:

1. Test Control: If (VC_Count = MACRO_GetDUT_VCCapsStructure) does not equal zero then this Test does not apply to this DUT – report and abort.

2. Test Control: Initialize the Protocol Test Card buffers (clear them) and program the Test Card to capture TLP Headers arriving from downstream ports.

3. Test Control: send a valid non-posted request to the DUT, with a non-zero Traffic Class ID value in the TLP header.

4. Test Control: read the TLP Headers from the Test Card - verify that the Traffic Class ID in the Completion(s) from the DUT is the same Traffic Class ID used in the initial Request from the Test Control (TXN.5.0#3, TXN.5.0#4)


24

Transaction Layer Test Considerations Revision 1djm202/pdf/specifications/pcie/...TRANSACTION LAYER...

Documents

Transcript of Transaction Layer Test Considerations Revision 1djm202/pdf/specifications/pcie/...TRANSACTION LAYER...