PHY Interface For The PCI Express Architecture
PHY Interface For The PCI Express Architecture
PHY Interface For The PCI Express Architecture
for the
PCI Express* Architecture
Notice: Implementations developed using the information provided in this specification may
infringe the patent rights of various parties including the parties involved in the development of
this specification. No license, express or implied, by estoppel or otherwise, to any intellectual
property rights (including without limitation rights under any party’s patents) are granted herein.
This document is an intermediate draft for comment only and is subject to change without notice.
Readers should not design products based on this document.
All product names are trademarks, registered trademarks, or service marks of their respective
owners
Table of Contents
1 Preface...................................................................................................................................... 7
1.1 Scope of this Revision ...................................................................................................... 7
1.2 Revision History ............................................................................................................... 7
2 Introduction .............................................................................................................................. 8
2.1 PCI Express PHY Layer ................................................................................................... 9
3 PHY/MAC Interface .............................................................................................................. 10
4 PCI Express PHY Functionality............................................................................................. 12
4.1 Transmitter Block Diagram (2.5 and 5.0 GT/s) .............................................................. 13
4.2 Transmitter Block Diagram (8.0 GT/s)........................................................................... 14
4.3 Receiver Block Diagram (2.5 and 5.0 GT/s) .................................................................. 15
4.4 Receiver Block Diagram (8.0 GT/s) ............................................................................... 16
4.5 Clocking.......................................................................................................................... 17
5 PIPE Interface Signal Descriptions ........................................................................................ 17
5.1 PHY/MAC Interface Signals .......................................................................................... 17
5.2 External Signals .............................................................................................................. 25
6 PIPE Operational Behavior .................................................................................................... 26
6.1 Clocking.......................................................................................................................... 26
6.2 Reset................................................................................................................................ 26
6.3 Power Management ........................................................................................................ 27
6.4 Changing Signaling Rate ................................................................................................ 28
6.4.1 Fixed data path implementations ............................................................................. 29
6.4.2 Fixed PCLK implementations ................................................................................. 29
6.5 Transmitter Margining .................................................................................................... 30
6.6 Selectable De-emphasis .................................................................................................. 31
6.7 Receiver Detection.......................................................................................................... 31
6.8 Transmitting a beacon..................................................................................................... 32
6.9 Detecting a beacon.......................................................................................................... 32
6.10 Clock Tolerance Compensation .................................................................................. 33
6.11 Error Detection............................................................................................................ 34
6.11.1 8B/10B Decode Errors............................................................................................. 34
6.11.2 Disparity Errors ....................................................................................................... 35
6.11.3 Elastic Buffer Errors ................................................................................................ 35
6.12 Loopback..................................................................................................................... 36
6.13 Polarity Inversion ........................................................................................................ 38
6.14 Setting negative disparity ............................................................................................ 39
6.15 Electrical Idle .............................................................................................................. 39
6.16 Implementation specific timing and selectable parameter support ............................. 40
6.17 Control Signal Decode table........................................................................................ 42
Table of Figures
Figure 1: Partitioning PHY Layer ........................................................................................................ 9
Figure 2: PHY/MAC Interface........................................................................................................... 10
Figure 3: PHY Functional Block Diagram .......................................................................................... 12
Figure 4: Transmitter Block Diagram ........................................................................................... 13
Figure 5: Receiver Block Diagram................................................................................................ 15
Figure 6: Clocking and Power Block Diagram ............................................................................. 17
Table of Tables
Table 5-1: Transmit Data Interface Signals................................................................................... 17
Table 5-2: Receive Data Interface Signals .................................................................................... 18
Table 5-3: Command Interface Signals ......................................................................................... 20
Table 5-4: Status Interface Signals................................................................................................ 21
Table 5-5: External Signals ........................................................................................................... 25
1 Preface
0.95 4/25/03 Updates to reflect 1.0a Base Spec. Added multilane suggestions.
1.86 2/27/2006 Fixed up more areas based on feedback. Added a section on how
to handle CLKREQ#.
1.87 9/28/2006 Removed references to Compliance Rate determination. Added
sections for TX Margining and Selectable De-emphasis. Fixed up
areas (6.4) based on feedback.
1.90 3/24/2007 Minor updates, mostly editorial.
3.0 Rev .5 8/11/2008 Initial draft with PCI Express 3.0 support.
2 Introduction
The PHY Interface for the PCI Express Architecture (PIPE) is intended to enable the
development of functionally equivalent PCI Express PHY's. Such PHY's can be delivered as
discrete IC's or as macrocells for inclusion in ASIC designs. The specification defines a set of
PHY functions which must be incorporated in a PIPE compliant PHY, and it defines a standard
interface between such a PHY and a Media Access Layer (MAC) & Link Layer ASIC. It is not
the intent of this specification to define the internal architecture or design of a compliant PHY
chip or macrocell. The PIPE specification is defined to allow various approaches to be used.
Where possible the PIPE specification references the PCI Express base specification specification
rather than repeating its content. In case of conflicts, the PCI-Express Base Specification shall
supersede the PIPE spec.
This spec provides some information about how the MAC could use the PIPE interface for
various LTSSM states and Link states. This information should be viewed as guidelines for or
‘one way to implement’ base specification requirements. MAC implementations are free to do
things in other ways as long as they meet the corresponding specification requirements.
One of the intents of the PIPE specification is to accelerate PCI Express endpoint device
development. This document defines an interface to which ASIC and endpoint device vendors
can develop. Peripheral and IP vendors will be able to develop and validate their designs,
insulated from the high-speed and analog circuitry issues associated with the PCI Express PHY
interface, thus minimizing the time and risk of their development cycles.
Figure 2-1 shows the partitioning described in this spec for the PCI Express Base Specification.
To higher link,
transaction layers
Logical
Sub-block PHY/MAC Interface
Physical Layer
Specification
(Chapter 4
of base spec) Physical Coding 8b/10b code/decode
Sublayer elastic buffer
(PCS) Rx detection
Rx Tx
Channel
3 PHY/MAC Interface
Figure 3-1 shows the data and logical command/status signals between the PHY and the MAC
layer. These signals are described in Section 5. Full support of PCI Express at all rates requires
15 control signals and 6 Status signals.
CLK
32, 16 or 8
TxData
TxDataK 4, 2 or 1
Command 16 Channel
32, 16 or 8 RxData PHY
MAC Layer
Layer Rx+,Rx-
4, 2 or 1
RxDataK
6 Status
PCLK
This specification allows several different PHY/MAC interface configurations to support various
signaling rates. For PIPE implementations that support only the 2.5 GT/s signaling rate
implementers can choose to have 16 bit data paths with PCLK running at 125 MHz, or 8 bit data
paths with PCLK running at 250 MHz.
PIPE implementations that support 5.0 GT/s signaling and 2.5 GT/s signaling in PCI Express
mode, and therefore are able to switch between 2.5 GT/s and 5.0 GT/s signaling rates, can be
implemented in several ways. An implementation may choose to have PCLK fixed at 250 MHz
and use 8-bit data paths when operating at 2.5 GT/s signaling rate, and 16-bit data paths when
operating at 5.0 GT/s signaling rate. Another implementation choice is to use a fixed data path
width and change PCLK frequency to adjust the signaling rate. In this case, an implementation
with 8-bit data paths could provide PCLK at 250 MHz for 2.5 GT/s signaling and provide PCLK
at 500 MHz for 5.0 GT/s signaling. Similarly, an implementation with 16-bit data paths would
provide PCLK at 125 MHz for 2.5 GT/s signaling and 250 MHz for 5.0 GT/s signaling. The full
set of possible widths and PCLK rates is shown in Table 3-1.
CLK
PCLK
PLL
32, 16 or 8
TxData
4, 2 or 1
TX BLOCK Tx+, Tx-
TxDataK
Command 15
6 Status
32, 16 or 8
RxData
4, 2 or 1
RX BLOCK Rx+, Rx-
RxDataK
Data
X32 or x16
or x8
x8
TxDataK
Scrambling (D Only)
x8
TxMargin
TxElecIdle Transmitter Differential
TxDeemph (PCI Express Only
TxDetectRx Driver TxSwing (PCI Express Only)
D+ D-
Data
X32 or x16
or x8
x8
TxDataK
Scrambling (D Only)
x8
TxMargin
TxElecIdle Transmitter Differential
TxDeemph (PCI Express Only
TxDetectRx Driver TxSwing (PCI Express Only)
D+ D-
D+ D-
Recovered
Bit Clock
Data Recovery
Circuit (DRC)
x 10 Recovered
Symbol Clock
Buffer Overflow/Underflow
Elastic Buffer
SKP added/removed Receiver RxStatus
Status
Loopback path
to transmitter x 10
Decode Error
Descrambler
x8
D+ D-
8.0 GHz
Clock Recovery
Circuit
Recovered
Bit Clock
Data Recovery
Circuit (DRC)
x 10 Recovered
Symbol Clock
Buffer Overflow/Underflow
Elastic Buffer
SKP added/removed Receiver RxStatus
Status
Loopback path
to transmitter x130
Decode Error
128b 130b Decode Disparity Error
400 MHz
RxDataK
x128
Descrambler
x8
4.5 Clocking
Bit Rate Clk
2.5, 5.0 or
8.0 GT/s
CLK
PLL
PCLK
TxStartBlock[ Input N/A Only used at the 8.0 GT/s signaling rate. These
3:0] for 32-bit signals allow the MAC to tell the PHY the
interface starting byte for a 130b block. For 32-bit
TxStartBlock[ interfaces, Bit 0 corresponds to the low-byte of
1:0] for 16-bit TxData, Bit3 corresponds to the upper byte. For
interface 16-bit interfaces, Bit 0 corresponds to the low-
TxStartBlock byte of TxData, Bit 1 to the upper byte. A value
for 8-bit of one indicates byte is the start of a 130b block,
interface a value of zero indicates the byte is not the start
of a 130b block.
RxData[31:0] Output N/A Parallel PCI Express data output bus. For 16-bit
for 32-bit interface, 16 bits represents 2 symbols of
interface receive data. Bits [7:0] are the first symbol
RxData[15:0] received, and bits [15:8] are the second symbol.
for 16-bit For the 32 bit interface, 32 bits represent the 4
interface or symbols of receive data. Bits [23:16] are the
RxData[7:0] third symbol received, and bits [31:24] are the
for 8-bit fourth symbol received.
interface
RxDataK[3:0] Output N/A Data/Control bit for the symbols of receive data.
for 32-bit For 32-bit interfaces, Bit 0 corresponds to the
interface low-byte of RxData, Bit3 coresponds to the
RxDataK[1:0] upper byte. For 16-bit interface, Bit 0
for 16-bit corresponds to the low-byte of RxData[15:0], Bit
interface 1 to the upper byte. A value of zero indicates a
RxDataK for data byte; a value of 1 indicates a control byte.
8-bit
interface
TxSyncHeader[1:0 Input N/A Provdes the sync header for the PHY to use in
] the next 130b block. The PHY reads this
value when the TXStartBlock signal is
asserted.
Active
Name Direction Description
Level
RxValid Output High Indicates symbol lock and valid data on
RxData and RxDataK.
PhyStatus Output High Used to communicate completion of several
PHY functions including power management
state transitions, rate change, and receiver
detection. When this signal transitions during
entry and exit from P2 and PCLK is not
running, then the signaling is asynchronous.
In error situations (where the PHY fails to
assert PhyStatus) the MAC can take MAC-
specific error recovery actions.
RxElecIdle Output High Indicates receiver detection of an electrical
idle. While deasserted with the PHY in P2,
indicates detection of a beacon.
This is an asynchronous signal.
RxStatus[2:0] Output N/A Encodes receiver status and error codes for
the received data stream when receiving data.
[2] [1] [0] Description
0 0 0 Received data OK
0 0 1 1 SKP added
0 1 0 1 SKP removed
0 1 1 Receiver detected
1 0 0 Both 128B/130B decode error
and (optionally) Receive
Disparity error
1 0 1 Elastic Buffer overflow
1 1 0 Elastic Buffer underflow.
This error code is not used if the
elasticity buffer is operating in the
nominal buffer empty mode.
1 1 1 Receive disparity error
(Reserved if Receive Disparity
error is reported with code
0b100)
6.1 Clocking
There are two clocks signals used by the PHY Interface component. The first (CLK) is a
reference clock that the PHY uses to generate internal bit rate clocks for transmitting and
receiving data. The specifications for this signal are implementation dependent and must be fully
specified by vendors. The specifications may vary for different operating modes of the PHY.
This clock may have spread spectrum modulation that matches a system reference clock (for
example, the spread spectrum modulation could come from REFCLK from the Card Electro-
Mechanical Specification).
The second clock (PCLK) is an output from the PHY and is the parallel interface clock used to
synchronize data transfers across the parallel interface. This clock runs at 125MHz, 250MHz, or
500 MHz depending on the Rate and PHY Mode control inputs and data interface width. The
rising edge of this clock is the reference point. This clock may also have spread spectrum
modulation.
6.2 Reset
When the MAC wants to reset the PHY (e.g.; initial power on), the MAC must hold the PHY in
reset until power and CLK to the PHY are stable. The PHY signals that PCLK is valid (ie. PCLK
has been running at its operational frequency for at least one clock) and the PHY is in the
specified power state by the de-assertion of PhyStatus. While Reset# is asserted the MAC should
have TxDetectRx/Loopback deasserted, TxElecIdle asserted, TxCompliance deasserted,
RxPolarity deasserted, PowerDown = P1, TxMargin = 000b, TxDeemp = 1, PHY Mode set to the
desired PHY operating mode, and Rate set to 2.5GT/s signaling rate. The state of TxSwing during
Reset# assertion is implementation specific.
Reset#
PhyStatus
Reset
Four power states are defined, P0, P0s, P1, and P2. P0 state is the normal operational state for the
PHY. When directed from P0 to a lower power state, the PHY can immediately take whatever
power saving measures are appropriate.
In states P0, P0s and P1, the PHY is required to keep PCLK operational. For all state transitions
between these three states, the PHY indicates successful transition into the designated power state
by a single cycle assertion of PhyStatus. Transitions into and out of P2 are described below. For
all power state transitions, the MAC must not begin any operational sequences or further power
state transitions until the PHY has indicated that the initial state transition is completed.
Mapping of PHY power states to states in the Link Training and Status State Machine (LTSSM)
found in the base specification are included below.
• P0 state: All internal clocks in the PHY are operational. P0 is the only state where the PHY
transmits and receives PCI Express signaling.
P0 is the appropriate PHY power management state for most states in the Link Training and
Status State Machine (LTSSM). Exceptions are listed below for each lower power PHY
state.
• P0s state: PCLK output must stay operational. The MAC may move the PHY to this state
only when the transmit channel is idle.
P0s state can be used when the transmitter is in state Tx_L0s.Idle.
While the PHY is in either P0 or P0s power states, if the receiver is detecting an electrical
idle, the receiver portion of the PHY can take appropriate power saving measures. Note that
the PHY must be capable of obtaining bit and symbol lock within the PHY-specified time
(N_FTS with/without common clock) upon resumption of signaling on the receive channel.
This requirement only applies if the receiver had previously been bit and symbol locked
while in P0 or P0s states.
• P1 state: Selected internal clocks in the PHY can be turned off. PCLK output must stay
operational. The MAC will move the PHY to this state only when both transmit and receive
channels are idle. The PHY must not indicate successful entry into P1 (by asserting
PhyStatus) until PCLK is stable and the operating DC common mode voltage is stable and
within specification (as per the base spec).
P1 can be used for the Disabled state, all Detect states, and L1.Idle state of the Link Training
and Status State Machine (LTSSM).
• P2 state: Selected internal clocks in the PHY can be turned off. The parallel interface is in
an asynchronous mode and PCLK output is turned off. The MAC must ensure that the PHY
is in 2.5 GT/s signaling mode prior to moving the PHY to P2 state or direct the signaling
mode change and PHY power state change at the same time.
When transitioning into P2, the PHY must assert PhyStatus before PCLK is turned off and then
deassert PhyStatus when PCLK is fully off and when the PHY is in the P2 state. When
transitioning out of P2, the PHY asserts PhyStatus as soon as possible and leaves it asserted until
after PCLK is stable. PHYs should be implemented to minimize power consumption during P2
as this is when the device will have to operate within Vaux power limits (as described in the PCI
Express Base Specification).
P2 state can be used in LTSSM states L2.Idle and L2.TransmitWake.
PCLK
PowerDown P0 P2
PhyStatus
P2 Entry
PCLK
PowerDown P2 P1
PhyStatus
P2 Exit
There is a limited set of legal power state transitions that a MAC can ask the PHY to make.
Referencing the main state diagram of the LTSSM in the base spec and the mapping of LTSSM
states to PHY power states described in the preceding paragraphs, those legal transitions are: P0
to P0s, P0 to P1, P0 to P2, P0s to P0, P1 to P0, and P2 to P0. The base spec also describes what
causes those state transitions.
The signaling rate of the link can be changed only when the PHY is in the P0 or P1 power state
and TxElecIdle is asserted. When the MAC changes the Rate signal, the PHY performs the rate
change and signals its completion with a single cycle assertion of PhyStatus. The MAC must not
perform any operational sequences, power state transitions, deassert TxElecIdle, or further
signaling rate changes until the PHY has indicated that the signaling rate change has completed.
There are instances where LTSSM state machine transitions indicate both a speed change and a
power state change for the PHY. One of these instances is when the LTSSM transitions to
Detect. In this case, the MAC must change (if necessary) the signaling rate to 2.5 GT/s before
changing the power state to P1. Another instance is when the LTSSM transitions to L2.Idle.
Again, the MAC must change (if necessary) the signaling rate to 2.5 GT/s before changing the
power state to P2.
Some PHY architectures may allow a speed change and a power state change to occur at the same
time. If a PHY supports this, the MAC must change the rate to 2.5 GT/s at the same PCLK edge
that it changes the PowerDown signals. This can happen when transitioning the PHY from P0 to
either P1 or P2 states. The completion mechanisms are the same as previously defined for the
power state changes and indicate not only that the power state change is complete, but also that
the rate change is complete.
stopped) is minimized to prevent any timers using PCLK from exceeding their specifications.
Also during the clock transition period, the frequency of PCLK must not exceed the PHY’s
defined 5.0 GT/s clock frequency. The amount of time between when Rate is changed and the
PHY completes the rate change is a PHY specific value.
PCLK
TxElecIdle
PhyStatus
Rate
PCLK
TxElecIdle
PhyStatus
Rate
TxData[7:0] Useable
TxData[15:8] Useable
RxData[7:0] Useable
RxData[15:8] Useable
There is a limited set of legal TxMargin[2:0] and Rate combinations that a MAC can select.
Refer to the PCIe Base Specification for a complete description of legal settings.
PCLK
PowerDown[1:0] P0 P0
< 128ns
New value at
Tx pins within 128ns
There is a limited set of legal TxDeemph and Rate combinations that a MAC can select. Refer to
the PCIe Base Specification for a complete description.
The MAC must ensure that TxDeemph is selecting -3.5db whenever Rate is selecting 2.5 GT/s.
PCLK
PowerDown[1:0] P0 P0
< 128ns
New value at
Tx pins within 128ns
PCLK
TxDetectRx/Loopback
PhyStatus
PowerDown[1:0] 10b
PowerDown[1:0] P2
TxElecIdle
Beacon Transmit
6.9 Detecting a beacon
The PHY receiver must monitor at all times (except during reset) for electrical idle. When the
PHY is in the P2 power state, and RxElecIdle is deasserted, then a beacon is being detected.
PowerDown[1:0] P2
RxElecIdle
Beacon Receive
The figure below shows a sequence where a SKP symbol is added in the data stream.
PCLK
RxValid
The figure below shows a sequence where a SKP symbol was removed from a SKP ordered-set
that only had one SKP symbol, resulting in a ‘bare’ COM transferring across the parallel
interface.
PCLK
RxValid
If an error occurs during a SKP ordered-set, such that the error signaling and SKP added/removed
signaling on RxStatus would occur on the same CLK, then the error signaling has precedence.
PCLK
RxValid
PCLK
RxValid
Disparity Error
6.11.3 Elastic Buffer Errors
For elastic buffer errors, an underflow should be signaled during the clock cycle or clock cycles
when a spurious symbol is moved across the parallel interface. The symbol moved across the
interface should be the EDB symbol. In the timing diagram below, the PHY is receiving a
repeating set of symbols Rx-a thru Rx-z. The elastic buffer underflows causing the EDB symbol
to be inserted between the Rx-g and Rx-h Symbols. The PHY drives RxStatus to indicate buffer
underflow during the clock cycle when the EDB is presented on the parallel interface.
Note that underflow is not signaled when the PHY is operating in Nominal Empty buffer mode.
In this mode SKP ordered sets are moved across the interface whenver data needs to be inserted.
PCLK
RxValid
PCLK
RxValid
6.12 Loopback
• The PHY must support an internal loopback as described in the corresponding base
specification.
The PHY begins to loopback data when the MAC asserts TxDetectRx/Loopback while doing
normal data transmission (ie. when TxElecIdle is deasserted). The PHY must, within the
specified receive and transmit latencies, stop transmitting data from the parallel interface, and
begin to loopback received symbols. While doing loopback, the PHY continues to present
received data on the parallel interface.
The PHY stops looping back received data when the MAC deasserts TxDetectRx/Loopback.
Transmission of data on the parallel interface must begin within the specified transmit latency.
The timing diagram below shows example timing for beginning loopback. In this example, the
receiver is receiving a repeating stream of bytes, Rx-a thru Rx-z. Similarly, the MAC is causing
the PHY to transmit a repeating stream of bytes Tx-a thru Tx-z. When the MAC asserts
TxDetectRx/Loopback to the PHY, the PHY begins to loopback the received data to the
differential Tx+/Tx- lines. Timing between assertion of TxDetectRx/Loopback and when Rx data
is transmitted on the Tx pins is implementation dependent.
PCLK
TxDetectRx/Loopback
TxElecIdle
Tx+/Tx- T x-g/T x-h T x-I/Tx-j T x-k/T x-l Tx-m/T x-n T x-o/T x-p Rx-g/Rx-h Rx-I/Rx
Loopback start
The next timing diagram shows an example of switching from loopback mode to normal mode.
When the MAC detects an electrical idle ordered-set, the MAC deasserts TxDetectRx/Loopback
and asserts TxElecIdle. The PHY must transmit at least three bytes of the electrical idle ordered-
set before going to electrical idle. (Note, transmission of the electrical idle ordered-set should be
part of the normal pipeline through the PHY and should not require the PHY to detect the
electrical idle ordered-set). The base spec requires that a Loopback Slave be able to detect and
react to an electrical idle ordered set within 1ms. The PHY’s contribution to this time consists of
the PHY’s Receive Latency plus the PHY’s Transmit Latency (see section 6.13).
PCLK
RxVali d
TxDetectRx/Loopback
TxElecIdle
Loopback end
PCLK
RxValid
RxCodeErr
RxDispErr
RxPolarity
Polarity inversion
PCLK
TxCompliance
Byte transmitted
with negative disparity
Loopback
Setting negativeend
disparity
TxDataK[0]
TxDataK[1]
TxElecIdle
Electrical Idle
Transmit Latency Time for data moving between the parallel interface and the PCI Express
serial lines. Timing is measured from when the data is transferred across
the parallel interface (ie. the rising edge of PCLK) and when the first bit
1 0 1 TxMargin value 5 =
1 1 0 TxMargin value 6 =
1 1 1 TxMargin value 7 =
When the MAC and higher levels have determined that the link should transition to L0s, the
MAC transmits an electrical idle ordered set and then has the PHY transmitter go idle and enter
P0s. Note that for a 16-bit interface, the MAC should always align the electrical idle on the
parallel interface so that the COM symbol is in the low-order position (TxDataK[7:0]).
.
PCLK
TxDataK[0]
TxDataK[1]
TxElecIdle
PhyStatus
L0 to L0s
To cause the link to exit the L0s state, the MAC transitions the PHY from the P0s state to the P0
state, waits for the PHY to indicate that it is read to transmit (by the assertion of PhyStatus), and
then begins transmitting Fast Training Sequences (FTS). Note, this is an example of L0s to L0
transition when the PHY is running at 2.5GT/s.
PCLK
PhyStatus
TxData[7:0] FTS
TxDataK[0]
TxData[15:8] FTS
TxDataK[1]
TxElecIdle
Tx+/Tx- Active
L0s to L0
After the MAC has had the PHY send PM_Active_State_Request_L1 messages, and has received
the PM_Request_ACK message from the upstream port, it then transmits an electrical idle
ordered set, and has the PHY transmitter go idle and enter P1.
PCLK
TxDataK[0]
TxDataK[1]
TxElecIdle
PhyStatus
L0 to L1
To cause the link to exit the 1 state, the MAC transitions the PHY from the P1 state to the P0
state, waits for the PHY to indicate that it is ready to transmit (by the assertion of PhyStatus), and
then begins transmitting training sequence ordered sets (TS1s). Note, this is an example when the
PHY is running at 2.5GT/s.
PCLK
PhyStatus
TxDataK[0]
TxDataK[1]
TxElecIdle
Tx+/Tx- Active
L1 to L0
7.3 Receivers and Electrical Idle
This section shows some examples of how PIPE interface signaling may happen as a receiver
transitions from active to electrical idle and back again. In these transitions there may be a
significant time difference between when RxElecIdle transitions and when RxValid transitions.
The first diagram shows how the interface responds when the receive channel has been active and
then goes to electrical idle. In this case, the delay between RxElecIdle being asserted and RxValid
being deasserted is directly related to the depth of the implementations elastic buffer and symbol
synchronization logic. Note that the transmitter that is going to electrical idle may transmit
garbage data and this data will show up on the RxData[] lines. The MAC should discard any
symbols received after the electrical idle ordered-set until RxValid is deasserted.
PCLK
RxValid
RxElecIdle
Rx+/Rx- Data
The second diagram shows how the interface responds when the receive channel has been idle
and then begins signaling again. In this case, there can be significant delay between the
deassertion of RxElecIdle (indicating that there is activity on the Rx+/Rx- lines) and RxValid
being asserted (indicating valid data on the RxData[] signals). This delay is composed of the
time required for the receiver to retrain as well as elastic buffer depth.
PCLK
RxValid
RxElecIdle
Rx+/Rx- Data
The general usage model is that to stop REFCLK the MAC puts the PHY into the P2 power state,
then deasserts CLKREQ#. To get the REFCLK going again, the MAC asserts CLKREQ#, and
then after some PHY and implementation specific time, the PHY is ready to use again.
CLKREQ# in L1
If the MAC is moving the link to the L1 state and intends to deassert CLKREQ# to stop
REFCLK, then the MAC follows the proper sequence to get the link to L1, but instead of
finishing by transitioning the PHY to P1, the MAC transition the PHY to P2. Then the MAC
deasserts CLKREQ#.
When the MAC wants to get the link alive again, it can:
• Assert CLKREQ#
• Wait for REFCLK to be stable (implementation specific)
• Wait for the PHY to be ready (PHY specific)
• Transition the PHY to P0 state and begin training.
CLKREQ# in L2
If the MAC is moving the link to the L1 state and intends to deassert CLKREQ# to stop
REFCLK, then the MAC follows the proper sequence to get the link to L2. Then the MAC
deasserts CLKREQ#.
When the MAC wants to get the link alive again, it can:
• Assert CLKREQ#
• Wait for REFCLK to be stable (implementation specific)
• Wait for the PHY to be ready (PHY specific)
• Transition the PHY to P0 state and begin training.
Delayed CLKREQ# in L1
The MAC may want to stop REFCLK after the link has been in L1 and idle for awhile. In this
case, the PHY is in the P1 state and the MAC must transition the PHY into the P0 state, and then
the P2 state before deasserting CLKREQ#. Getting the link operational again is the same as the
preceding cases.
8 Multi-lane PIPE
This section describes a suggested method for combining multiple PIPEs together to form a
multi-lane implementation. It describes which PIPE signals can be shared between each PIPE of
a multi-lane implementation, and which signals should be unique for each PIPE. This description
primarily applies to multi-lane links where lanes that become disassociated from an LTSSM
during training are unused, and they don’t associate with a new LTSSM. This is the common
case for most upstream facing ports, like those found in PCI Express endpoints.
The figure shows an example 4-lane implementation of a multilane PIPE solution. The signals
that can be shared are explicitly shown in the figure while signals that replicated for each lane are
shown as ‘Per-lane signals’.
CLK
PIPE
Rx+,Rx-
MAC Layer Tx+,Tx-
Per-lane Signals
PIPE
Rx+,Rx-
4-lane
implementation
In cases where a multi-lane has been ‘trained’ to a state where not all lanes are in use (like a x4
implementation operating in x1 mode), a special signaling combination is defined to ‘turn off’ the
unused lanes allowing them to conserve as much power as the implementation allows. This
special ‘turn off’ signaling is done using the TxElecIdle and TxCompliance signals. When both
are asserted, that PHY can immediately be considered ‘turned off’ and can take whatever power
saving measures are appropriate. The PHY ignores any other signaling from the MAC (with the
exception of Reset# assertion) while it is ‘turned off’. Similarly, the MAC should ignore any
signaling from the PHY when the PHY is ‘turned off’. There is no ‘handshake’ back to the MAC
to indicate that the PHY has reached a ‘turned off’ state.
There are two normal cases when a lane can get turned off:
1. During LTSSM Detect state, the MAC discovers that there is no receiver present and will
‘turn off’ the lane.
2. During LTSSM Configuration state (specifically Configuration.Complete), the MAC will
‘turn off’ any lanes that didn’t become part of the configured link.
As an example, both of these cases could occur when a x4 device is plugged into a x8 slot. The
upstream device (the one with the x8 port) will not discover receiver terminations on four of its
lanes so it will turn them off. Training will occur on the remaining 4 lanes, and let’s suppose that
the x8 device cannot operate in x4 mode, so the link configuration process will end up settling on
x1 operation for the link. Then both the upstream and downstream devices will ‘turn off’ all but
the one lane configured in the link.
When the MAC wants to get ‘turned off’ lanes back into an operational state, there are two cases
that need to be considered:
1. If the MAC wants to reset the multi-lane PIPE, it asserts Reset# and drives other interface
signals to their proper states for reset (see section 6.2). Note that this stops signaling
‘turned off’ to all lanes because TxCompliance is deasserted during reset. The multi-lane
PHY asserts PhyStatus in response to Reset# being asserted, and will deassert PhyStatus
when PCLK is stable.
2. When normal operation on the active lanes causes those lanes to transition to the LTSSM
Detect state, then the MAC sets the PowerDown[1:0] signals to the P1 PHY power state
at the same time that it deasserts ‘turned off’ signaling to the inactive lanes. Then as with
normal transitions to the P1 state, the multi-lane PHY will assert PhyStatus for one clock
when all internal PHYs are in the P1 state and PCLK is stable.