It is expected that graphics, Ethernet, InfiniBand, storage and PCIe switches will continue to drive the bandwidth evolution for the PCIe architecture and these applications are the current targets of the PCIe 3.0 technology. In the future, other applications may put additional bandwidth and performance demands on the PCIe architecture.

The PCIe Card Electromechanical (CEM) 3.0 specification consolidates all previous form factor power delivery specifications, including the 150W and the 300W specifications.

PCI-SIG attempts to define and evolve the PCIe architecture in a manner consistent with low-cost and high-volume manufacturability considerations. While PCI-SIG cannot comment on design choices and implementation costs, optimized silicon die size and power consumption continue to be overarching imperatives that inform PCIe specification development and architecture evolution.

For each revision of its specification, PCI-SIG develops compliance tests and related collateral consistent with the requirements of the new architecture. All of these compliance requirements are incremental in nature and build on the prior generation of the architecture. PCI-SIG anticipates releasing compliance specifications as they mature along with corresponding tests and measurement criteria. Each revision of the PCIe technology maintains its own criteria for product interoperability and admission into the PCI-SIG Integrators List.

The PCI-SIG will study the requirements of its members and of the industry for the next generation of the PCIe architecture following the successful release of the PCIe 3.0 specifications. Higher signaling rates depend on a number of factors. The PCI-SIG is committed to delivering the most robust and high-performance I/O interconnect specifications, while at the same time maintaining an uncompromised focus on low cost, low power, high volume manufacturability and compatibility, by taking advantage of breakthroughs in signaling technologies and silicon process capabilities.

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.

When polarity needs to be inverted, it must be done before exiting Poilling.Configuration, which permits it to be done in Polling.Active.

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.

The Receiver is not required to check the Link and Lane numbers while in Recovery.Equalization.

The Transmitter sends TS1 Ordered Sets using the Transmitter settings specified by the Transmitter Presets received in the EQ TS2 Ordered Sets during the most recent transition to 8.0 GT/s data rate from 2.5 GT/s or 5.0 GT/s data rate.

The unused transmitter Lane is put into Electrical Idle. It is recommended that the receiver terminations be left on.

The transmitter of the unused lanes remains in Electrical Idle during the speed change.

The transition requirements can be satisfied by receiving 8 TS1s, 8 TS2s, or a combination of TS1s and TS2s totaling 8.

At 8 GT/s, a SKP Ordered Set must be scheduled for transmission at an interval between 370 to 375 blocks. However, the Transmitter must not transmit the scheduled SKP Ordered Set until it completes transmission of any TLP or DLLP it is sending, and sends an EDS packet. Therefore, the interval between SKP OS transmissions may not always fall within a 370 to 375 block interval.

For example, if a SKP Ordered Set remains scheduled for 6 block times before framing rules allow it to be transmitted, the interval since the transmission of the previous SKP OS may be 6 blocks longer than normal, and the interval until the transmission of the next SKP OS may be 6 Blocks shorter than normal. But the Transmitter must schedule a new SKP Ordered Set every 370 to 375 blocks, so the long-term average SKP OS transmission rate will match the scheduling rate.

Receivers must size their elastic buffers to tolerate the worst-case transmission interval between any two SKP Ordered Sets (which will depend on the Max Payload Size and the Link width), but can rely on receiving SKP Ordered Sets at a long term average rate of one SKP Ordered Set for every 370 to 375 blocks. The SKP Ordered Set interval is not checked by the Receiver.

When an Ack or Nak is not received and the REPLAY_TIMER expires, the TLPs in the Transmit Retry Buffer are retransmitted. The Replay Timer Timeout error is also reported.

Each Port of a Switch contains registers that define Memory Space apertures. The Memory Base/Limit registers define an aperture for 32-bit non-prefetchable Memory Space. The Prefetchable Memory Base/Limit & their corresponding Upper registers define an aperture for 64-bit prefetchable Memory Space. Here is the basic behavior with a properly configured Switch. If the TLP address falls within the aperture of another Downstream Port, the TLP is routed to that Downstream Port and sent Downstream. If the TLP address falls within a Memory Space range mapped by any BAR within the Switch, the TLP is routed to the Function containing that BAR. Otherwise, if the TLP address falls within an aperture of the Upstream Port, the TLP is handled as an Unsupported Request. Otherwise, the TLP is routed to the Upstream Port where it is sent to the Upstream Link or another Function associated with the Upstream Port.

If a Switch implements and supports Access Control Services (ACS), ACS mechanisms provide additional controls governing whether each Memory Request TLP is routed normally to another Downstream Port, blocked as an error, or redirected Upstream even if its address falls within the aperture of another Downstream Port. See Section 6.12.

Yes, that is the expected sequence when the autonomous equalization mechanism is executed. Note that Section 4.2.3 also describes other equalization mechanisms.

If the receivers are in L0s, Receiver Errors should not be reported. It does not matter whether the transmitters are in L0 or L0s for reporting of Receiver Errors. Section 4.2.6.5 specifies the 3 conditions required for the LTSSM to transition from L0 to L1. Until all of these conditions are satisfied, the LTSSM is in L0 state, and should report Receiver Errors, even if its transmitters are in Electrical Idle.

No. Lanes being activated for upconfiguration are not required to align their exit of Electrical Idle with the transmission of any Symbol, Block, or Ordered Set type. Furthermore, the Lanes are not required to exit Electrical Idle before the LTSSM enters the Configuration.Linkwidth.Start state.

Only Host CPUs are permitted to generate locked transaction sequences, so Endpoints should never receive CplLk or CplDLk Completions that match their Transaction IDs. An Endpoint is permitted to handle the case in question either as a Malformed TLP or an Unexpected Completion, depending upon implementation specific factors, such as whether it decodes these types of Completions. For this case it is recommended that an Endpoint handle it as an Unexpected Completion since it may be the result of a misrouted TLP, and best handled as an Advisory Non-Fatal Error as described in Section 6.2.3.2.4.5.

Yes. The received Link Number (not in the range 0-31) does not match the transmitted Link Number (in the range 0-31).

The Port should transition to the LTSSM Recovery.RcvrCfg state.

Setting the Extended Synch bit in the Link Control register of the two devices on the link will increase the number of FTS Ordered Sets to 4096, but the Extended Synch bit is used only for testing purposes.

When setting the directed_speed_change variable (in response to receiving 8 consecutive TS1 or TS2 Ordered Sets with the speed_change bit set), it is recommended, but not required, to reset the counters/status of received TS1 or TS2 Ordered Sets. That is, it is recommended that a Device receive an additional 8 consecutive TS1 or TS2 Ordered Sets with the speed_change bit set after it has started transmitting TS1 Ordered Sets with the speed_change bit set before it transitions from Recovery.RcvrLock to Recovery.RcvrCfg.

If the Downstream Port receives no valid TS1 Ordered Sets but does receive valid TS2 Ordered Sets, should it timeout and transition to Detect?

No, the timer is to guarantee that the Transmitter will stay in Recovery.RcvrLock for a minimum time to establish common mode. The Port must wait to transition from Recovery.RcvrLock until this timer has expired, and the timer does not start counting until an exit from Electrical Idle has been detected. Errata A21 modified this section of the L1 PM Substates with CLKREQ ECN document.

When VC Enable for VC1 is set to 0b, the device must stop transmitting UpdateFC DLLPs for VC1.

The default value of the M-PCIe Target Link Speed Control field is 01b.

An Electrical Idle exit is required to be detected on at least one Lane.

The ASPM L1 Exit Latency in the Link Capabilities register indicates the L1/L1.0 to L0 latency, and does not include added latency due to Clock Power Management, L1.1 or L1.2.

While in the D3hot state, a Function must not initiate any Request TLPs on the Link with the exception of a PME Message.

Per Section 2.7.1, the device is required to check ECRC for all TLPs where it is the ultimate PCI Express Receiver. Note that per Section 6.2.4, an ECRC Error is not Function-specific, so it must be logged in all Functions of that device.

The Completion with UR status is required to be transmitted while the Port is in D3hot, assuming that the Port remains powered long enough to transmit the Completion.

The Link Speed following reset will be the result of Configuration process. During the M-PCIe discovery and Configuration process, RRAP is used to discover M-PHY capabilities, analyze and configure configuration attributes accordingly. Depending on the High speed supported by both components, the Link Speed and Rate Series may get configured for HS-G1, HS-G2 or HS-G3 and RATE A or B respectively. For this particular example Link Speed could be either HS-G1 or HS-G2 depending on the supported Link Speeds of the other Component on the LINK.

We suggest using the 2.5 GT/s values for Gear 1 and 2 at Rates A and B, and also suggest using the 5.0 GT/s values for Gear 3 at Rates A and B, until clarification is received from the workgroup. This clarification will be included in next errata release.

Section 6.20 – Lines 8-13 on page 628 of PCIe 3.1 states:
A PASID TLP Prefix is permitted on:

- Memory Requests (including AtomicOp Requests) with Untranslated Addresses (See Section 2.2.4.1).

- Translation Requests and Translation Message Requests as defined in the Address Translation Services Specification.

The PASID TLP Prefix is not permitted on any other TLP.

No, the text is correct as-is -- a PASID is not permitted on a Completion.  We will consider if an errata is needed to clarify this.”

Yes, when the LTSSM enters the Disabled state, the DLCMSM transitions to DL_Inactive, the Link transitions to DL_Down, and this causes the equivalent of a Hot Reset to the Endpoint. See Sections 2.2.9 & 3.2.1.

Based on PCI-SIG feasibility analysis, the bit rate for the PCIe 4.0 specification will be 16GT/s. This bit rate represents the optimum tradeoff between performance, manufacturability, cost, power and compatibility. PCI-SIG analysis covered multiple topologies. All of these studies confirmed the potential feasibility of 16GT/s signaling with low-cost enablers.

After technical analysis, the PCI-SIG has determined that 16 GT/s on copper, which will double the bandwidth over the PCIe 3.0 specification, is technically feasible at approximately PCIe 3.0 power levels. The preliminary data also confirms that a 16GT/s interconnect can be manufactured in mainstream silicon process technology and can be deployed with existing low-cost materials and infrastructure, while maintaining compatibility with previous generations of PCIe architecture. In addition, the PCI-SIG will investigate advancements in active and idle power optimizations as they become available.

In assessing potential improvements to the connector, materials, silicon and channel improvements, PCI-SIG required that compatibility, low-cost and high-volume manufacturing be maintained.

PCI-SIG is proud of its long heritage of developing compatible architectures and its members have consistently produced compatible and interoperable products. In keeping with this tradition, the PCIe 4.0 architecture is compatible with prior generations of this technology, from software to clocking architecture to mechanical interfaces. That is to say PCIe 1.x, 2.x and 3.x cards will seamlessly plug into PCIe 4.0-capable slots and operate at the highest performance levels possible. Similarly, all PCIe 4.0 cards will plug into PCIe 1.x-, PCIe 2.x- and PCIe 3.x-capable slots and operate at the highest performance levels supported by those configurations.

PCI-SIG responds to the needs of its members. As applications evolve to consume the I/O bandwidth provided by the current generation of the PCIe architecture, PCI-SIG begins to study the requirements for technology evolution to keep abreast of performance and feature requirements.

The PCIe 4.0 specification will address the many applications pushing for increased bandwidth at a low cost including server, workstation, desktop PC, notebook PC, tablets, embedded systems, peripheral devices, high-performance computing markets and more. The target implementations are entirely at the discretion of the designer.

PCI-SIG attempts to define and evolve the PCIe architecture in a manner consistent with low-cost and high-volume manufacturability considerations. While PCI-SIG cannot comment on design choices and implementation costs, optimized silicon die size and power consumption continue to be important considerations that inform PCIe specification development and architecture evolution.

A PCIe Link consists of 1, 2, 4, 8, 12, 16, or 32 Lanes, all operating at one of the supported signaling rates.

• PCIe 1.0 provided an effective 2.5 Gigabits/second/Lane/direction of raw bandwidth.
• PCIe 2.0 added support for 5.0 Gigabits/second/Lane/direction of raw bandwidth.
• PCIe 3.0 added support for 8.0 Gigabits/second/Lane/direction of raw bandwidth.
• PCIe 4.0 added support for 16.0 Gigabits/second/Lane/direction of raw bandwidth.
• PCIe 5.0 adds support for 32.0 Gigabits/second/Lane/direction of raw bandwidth.

A PCIe 5.0 Link consisting of 32 Lanes and operating at a bit rate of 32 GT/s provides an effective raw bandwidth of 128 Gigabytes/second in each direction simultaneously.