PCI-SIG Technical Support Technical FAQ
The following list of technical FAQs have been generated as a result of answers provided to questions submitted to Technical Support by PCI-SIG members. Individual names, company names, and any content that might identify a person/company have been removed. Any additional FAQs identified as appropriate to add to this list, will be added on a quarterly basis. For the following content, an FAQ is defined as a compilation of two or more questions received during a previous QTR that appear to be basically the same or of very similar content. Over time, older FAQ entries may be deleted from the list as newer entries are added.
If you have questions relative to the PCI Express Specifications that you will be submitting to Technical Support, please reference your questions relative to the content contained in the appropriate PCI Express Specification. Please do not reference your questions relative FAQs posted below. Please submit your Tech Support questions through email via the PCI-SIG web-based submittal process available at www.pcisig.com/developers/technical_support.
PCIe 3.0
1. Section 2.3.1.1 – If an End Point returns a Completion (Cpl) with no data and Successful Completion status to a memory read request, should this be handled as a Malformed TLP or as an Unexpected Completion?
A compliant device would not return a Completion (Cpl) with no data and Successful Completion status to a memory read request, so normally this should not occur. If a properly formed Cpl is received that matches the Transaction ID, it is recommended that it be handled as an Unexpected Completion, but it is permitted to be handled as a Malformed TLP.
2. Section 7.5.3 – I have a question relating to BAR registers in Root Port, EP, PCIe-to-PCI Bridge, and a PCIe Switch. If a PCIe Memory Request is received which has a starting address that hits a BAR, but a length that exceeds the BAR range, how should such a Request to these devices be handled?
A Memory Request that exceeds the BAR range of an End Point, Bridge, Root Port, or Switch is handled as an Unsupported Request unless one of the following exceptions applies. An AtomicOp Request that crosses a 4KB boundary is unaligned, and thus must be handled as a Malformed TLP; otherwise, a Memory Request that crosses a 4KB boundary may optionally be handled as a Malformed TLP.
3. Section 4.2.6.2.3 – Can you please clarify the below statement quoted from section "4.2.6.2.3. Polling.Configuration" of PCI Express 3.0 specification: Receiver must invert polarity if necessary (see Section 4.2.4.4). Does this imply the polarity inversion can only be initiated by receiver in Polling.Configuration state or can the inversion happen in Polling.Active state as well?
When polarity needs to be inverted, it must be done before exiting Poilling.Configuration, which permits it to be done in Polling.Active.
4. Section 4.2.6.3.1.2 – The question is regarding Configuration.Linkwidth.Start state in the case of upconfiguration. It is written in the spec: "The Transmitter sends out TS1 Ordered Sets with Link numbers and Lane numbers set to PAD on all the active Upstream Lanes; the inactive Lanes it is initiating to upconfigure the Link width; and if upconfigure_capable is set to 1b, on each of the inactive Lanes where it detected an exit from Electrical Idle since entering Recovery and has subsequently received two consecutive TS1 Ordered Sets with Link and Lane numbers, each set to PAD, in this substate." It is not mentioned here if sending of these TS1s should be done ONLY on lanes that detected a receiver in the last time the LTSSM was at Detect state. Is it so?
The only lanes that can be part of an upconfigure sequence are lanes that were part of the configured link when configuration was performed with LinkUp = zero, and Lanes that failed to detect a Receiver can not be part of that initially configured Link. Therefore, a Port in the Configuration.Linkwidth.Start state must only transmit TS1s on a subset of the Lanes that detected a Receiver while last in the Detect state, regardless of if it is attempting to upconfigure the Link width, or not.
5. Section 4.2.6.4.2 – According to pg227 of spec, "When using 128b/130b encoding, TS1 or TS2 Ordered Sets are considered consecutive only if Symbols 6-9 match Symbols 6-9 of the previous TS1 or TS2 Ordered Set". When in Recovery.Equalization and if using 128b/130b encoding, is it required that lane/link numbers (symbol 2) match in TS1s to be considered as consecutive or is it need not match?
The Receiver is not required to check the Link and Lane numbers while in Recovery.Equalization.
PCIe 2.0
1. Section 4.2.4.1 – What does Link Upconfigure mean? What is it used for?
Link Upconfigure means the device is capable of increasing the link width. When Upconfigure is supported by both devices on a link, the link width may be reduced to conserve power. When link use is going to increase, the devices will increase the link width to support the needed high data rate preferred by the device.
2. Section 4.2.4.3 – What is the purpose of the "inferred" electrical idle?
The purpose of the "inferred" electrical idle is to permit a method of detecting an electrical idle that does not use an analog circuit. Using an analog circuit can be difficult at 5.0 GT/s and the inferred method is an alternate (permitted) method.
3. Section 4.2.6.10.1 – The Loopback slave should wait until Symbol lock is archived after link speed change during Loopback.Entry substate. However, the base spec does not appear to define whether symbol lock should be archieved on some Lanes or all Lanes.
The Loopback slave transitions to Loopback.Active immediately after exiting Electrical Idle following the link speed change. It attempts to acquire symbol lock on all of the lanes that were active when it entered Loopback.Entry.
4. Section 2.2.4.1 – In the PCIe spec 2.0 page 57, there is a sentence "For Memory Read Requests and Memory Write Requests, the Address Type field is encoded as shown in Table 2-5, with full descriptions contained in the Address Translation Services Specification, Revision 1.0." If the value of AT field is invalid, what will PCIe do? Will it report an error, and if so, what error will be reported?
Endpoints that do not support Address Translation Services set the AT field to 00b on transmitted TLPs and ignore the AT field on received TLPs.
5. Section 2.2.62. – How does a CPU know a device exists and where the position of the device is?
Configuration softrware reads configuration space address 00h (using different bus, device and function numbers). When it gets a response, it knows a device exists at that ID.
6. Section 4.2.6.4.3 – An Endpoint is in Recovery.RcvrCfg state and has received the 8 required consecutive TS2's. But before it is able to complete sending 16 TS2s, the downstream port sends EIEOS and then starts sending TS1s. At this point, should the Endpoint move to Recovery.Idle after sending 16 TS2s? Or is it required to reset its RX counter and start counting TS1s and try to go to Configuration?
Transition to Recovery.Idle after sending the 16 TS2s since the requirements for that transition are met.
7. Section 5.3.2.3 – Is the following error scenario valid?
- RC sends PME_Turn_off message to EP
- EP doesn't respond with ACK due to delay
- EP responds with PME_TO_Ack message
- EP sends PM_Enter_L23 and not sending ACK.
Can the EP do without ACK?
The Endpoint is required to send an Ack for the PME_Turn_Off message. There is no valid reason for an extended delay of the Ack.
8. Section 2.7.2.2 – In PCIe 2.0 Spec P.128,a Poisoned I/O or Memory Write Request, or a Message with data (except for vendor-defined 25 Messages), that addresses a control register or control structure in the Completer must be handled as an Unsupported Request (UR) by the Completer. The completer receiving this kind of TLP needs to report error as UR or Poison TLP Received?
The intent is for this error case to be handled as a Poisoned TLP Receieved error. Errata is being developed against the 2.1 Base spec to clarify this. Due to ambiguous language in earlier versions of the spec, a component will be permitted to handle this error as an Unsupported Request, but this will be strongly discouraged.
9. Section 2.9.1 – For a PCIe 2.0 Switch, when upstream port goes to DL_down, it is stated in pg. 131 line 11 that the config registers will be reset, also line 15 says propagate reset to all other ports (which I interpret as all downstream ports, am I right?)
Yes, when a link reports DL_Down the upsteam port on the switch (and all other downstream devices) are reset.
But on line 11 of pg. 130, it says downstream port registers are not affected except status update, do these contradict?
The section 2.9.1 text covers two contexts. The context of a Downstream Port in DL_Down and the context of an Upstream Port in DL_Down. Care must be taken to apply the requirements in this section to the correct context.
10. Section 4.2.6.10.1 – I have a question about LTSSM in Loopback state. When the LTSSM is in Loopeback.Entry(p.233L24), Loopback master will send TS1 with Compliance Receive bit (Symbol 5 bit 4)=0b and Loopback bit=1b and wait to receive identical TS1 with Loopback bit asserted less than 100 ms. In this time, both sides of link are probably in 5GT/s. Then if Loopback slave cannot do Symbol lock, how long does Loopback slave need to wait, and what is the next substate?
The slave stays in Loopback.Active indefinitely until it receives an EIOS (or detects or infers an Electrical Idle). There is not timeout.
11. Section 4.2.6.1.1 – According to Section 4.2.6.1.1 in PCIe Base Specification 2.0, "The next state is Detect.Active after a 12 ms timeout or if Electrical Idle is broken on any Lane". Does this mean next state is Detect.Active only when electrical idle is broken?
It means the next state is Detect.Active after a 12 ms timeout, or the next state is Detect.Active (prior to the end of the 12 ms timer) if Electrical Idle is broken on any Lane.
12. Section 6.18 – If a Switch supports the LTR feature, which of its ports must support LTR?
If a Switch supports the LTR feature, it must support the feature on its Upstream Port and all Downstream Ports.
13. SECTION 4.2.6.3.5.2 – Based on the PCIe 2.0 spec, Line 13 page 212: - The next state is Configuration.Idle immediately after all Lanes that are transmitting TS2 Ordered Sets receive eight consecutive TS2 Ordered Sets with matching Lane and Link numbers (non-PAD) and identical data rate identifiers (including identical Link Upconfigure Capability (Symbol 4 bit 6)), and 16 consecutive TS2 Ordered Sets are sent after receiving one TS2 Ordered Sets. Does the received eight consecutive TS2 Ordered Sets with identical data rate identifiers (including identical Link Upconfigure Capability (Symbol 4 bit 6)) need to match the transmitted TS2 Ordered Sets if the next state is Configuration.Idle?
The received Link number must match the transmitted Link number. The received Lane number must match the transmitted Lane number. The received data rate identifier must be the same on all received lanes (but is not required to be the same as the transmitted data rate identifier). The received Link Upconfigure Capability bit must be the same on all received lanes (but is not required to be the same as the transmitted Link Upconfigure Capability bit).
14. SECTION 7.5.3.6 – Can you please clarify the behavior of a Switch Downstream Port when the Secondary Bus Reset bit is Set in its Bridge Control register? It is our understanding that a Secondary Bus Reset will not affect anything in the Downstream Port where it is Set, only in components Downstream (i.e. components on or below the secondary bus of that virtual Bridge). Should the primary side of the virtual Bridge reset or preserve its Requester ID after the Secondary Bus Reset bit is Set?
When software sets the Secondary Bus Reset bit in a Switch Downstream Port, the Downstream Port must not reset any of its own configuration settings, and it must transition the Link below it to the Hot Reset state, assuming the Link is not down. The description of the Secondary Bus Reset bit in Section 7.5.3.6 states “Port configuration registers must not be changed, except as required to update Port status.”
15. SECTION 4.2.8 – In the PCIe Base Spec 2.0, Section 4.2.8, page 239, under Key below the table it states -
D Delay Symbol K28.5 (with appropriate disparity)
What exactly does the term 'appropriate disparity' mean in the above lines from Spec?
Appropriate disparity means that the D symbol must have the correct disparity for the specified sequence of symbols.
16. SECTION 6.1.4 – This question relates to MSI. More specifically this question also relates to the Conventional PCI 3.0 spec (on page 237) for MSI where it states that - The Multiple Message Enable field (bits 6-4 of the Message Control register) defines the number of low order message data bits the function is permitted to modify to generate its system software allocated vectors. Does this mean that the binary value of the LSBs of the message data specifies the vector number?
Yes (up to a total of 5 bits). Also to avoid confusion for the function, software sets each of the low order message data bits to 0, that correspond to the low order message data bits the function is permitted to modify to generate its system software allocated vectors.
17. SECTION 4.2.6.4.4 – Referring to section 4.2.6.4.4 (Recovery.Idle), our EP is implemented such that it will send Idle data once entry into recovery.idle. If Hot Reset bit is asserted in two consecutive received TS1 ordered set, then we will move to HotReset state. Will the RC respond to the idle data that the EP sends out and falsely trigger into L0 state even though RC is directed to enter into HotReset?
For this case, the LTSSM of the Downstream Port above the Endpoint is already in the Hot Reset state, since that is how it transmitted TS1 Ordered Sets with the Hot Reset bit asserted.
18. SECTION 4.2.6.5 – In Base Spec 2.1 on page 246 line 10, it states that - "If directed" is defined as both ends of the Link having agreed to enter L1 etc. and then refers to Section 4.3.2.1, but there is no such section in the spec. Is there a section in the spec that provides more detail on this?
The reference in the spec should be to Section 5.3.2.1, which provides more detail (note that this reference will be fixed through upcoming errata to the 2.1 spec).
19. SECTION 7.5.1.1 – We implement Memory Space Enable and IO Space Enable bit in our Endpoint. If the Endpoint receives a Memory Write TLP when Memory Space Enable bit is not set. How should the Endpoint handle this TLP? Also, if the Endpoint receives a Memory Write TLP and its data payload exceeds Max_Payload_Size when Memory Space Enable bit is not set. How should the Endpoint handle this TLP in each case?
For the first case, the Endpoint must handle the Request as an Unsupported Request. For the second case, it is recommended that the Endpoint handle the Request as a Malformed TLP, but the Endpoint is permitted to handle the Request as an Unsupported Request.
20. SECTION 2.3.1 – What is the correct behavior if a read or write exceeds a bar limit? For example, let's say a BAR is 128 bytes, and the Read or write request to the address space mapped by the BAR is for a size that is larger than 128 bytes. In this case what is the correct response from the device?
It should be handled as an unsupported request.
21. SECTION 4.2.6.4.4 – Is the following lane setting valid: executing a downconfiguration from x4 to x2, with lane0=ACTIVE, lane1=INACTIVE, lane2=ACTIVE, lane3=INACTIVE?
The active lanes must be consecutively numbered lanes starting with lane 0. Your example would configure as a x1 link.
22. SECTION 7.7 – Is a PCI Express Root Complex required to support MSI?
All PCI Express device Functions (including root ports) that are capable of generating interrupts must implement MSI or MSI-X or both.
