logical phy interface (lpif)

Logical PHY Interface (LPIF)Specification

Rev 1.1

November 14, 2020

Rev 1.1 © Intel Corporation 2November 14, 2020


You may not use or facilitate the use of this document in connection with any infringement or other legal analysis concerning Intel products described herein. You agree to grant Intel a non-exclusive, royalty-free license to any patent claim thereafter drafted, which includes subject matter disclosed herein.

Intel technologies' features and benefits depend on system configuration and may require enabled hardware, software, or service activation. Performance varies depending on system configuration. No product or component can be absolutely secure. Check with your system manufacturer or retailer or learn more at www.intel.com.

Your costs and results may vary.

No license (express or implied, by estoppel or otherwise) to any intellectual property rights is granted by this document.

The products described may contain design defects or errors known as errata which may cause the product to deviate from published specifications. Current characterized errata are available on request.

Tests document performance of components on a particular test, in specific systems. Differences in hardware, software, or configuration will affect actual performance. Consult other sources of information to evaluate performance as you consider your purchase. For more complete information about performance and benchmark results, visit www.intel.com/performance.

Intel Corporation and its subsidiaries (collectively, "Intel") would like to receive input, comments, suggestions, and other feedback (collectively, "Feedback") on this specification. To be considered for incorporation into the specification, Feedback must be submitted by e-mail to: [email protected]. To the extent that You provide Intel with Feedback, You grant to Intel a worldwide, non-exclusive, perpetual, irrevocable, royalty-free, fully paid, transferable license, with the right to sublicense, under Your Intellectual Property Rights, to make, use, sell, offer for sale, import, disclose, reproduce, make derivative works, distribute, or otherwise exploit Your Feedback without any accounting. As used in this paragraph, "Intellectual Property Rights" means, all worldwide copyrights, patents, trade secrets, and any other intellectual or industrial property rights, but excluding any trademarks or similar rights. By submitting Feedback, you represent that you are authorized to submit Feedback on behalf of your employer, if any, and that the Feedback is not confidential.Intel does not control or audit third-party data. You should review this content, consult other sources, and confirm whether referenced data are accurate.

Copies of documents which have an order number and are referenced in this document may be obtained by calling 1-800-548-4725 or by visiting www.intel.com/design/literature.htm.

© 2020 Intel Corporation. Intel, the Intel logo, and other Intel marks are trademarks of Intel Corporation or its subsidiaries. Other names and brands may be claimed as the property of others.

http://www.intel.com

http://www.intel.com/performance

http://www.intel.com/design/literature.htm

[email protected]

mailto:[email protected]



Contents

1.0 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81.2 Reference Documents. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91.3 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91.4 Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

1.4.1 About the Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101.4.2 The Logical PHY Interface (LPIF) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.0 LPIF Signal List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.1 Interface Reset Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222.2 Exit Clock Gating Req/Ack Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

2.2.1 Implementation Rules for Clock Gating . . . . . . . . . . . . . . . . . . . . . . . . . . . 242.2.2 Rules for Hot Plug Support with Multiple Protocols. . . . . . . . . . . . . . . . . . . . 26

2.3 Data Transfer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272.4 Stall Req/Ack Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

2.4.1 Full Handshake with lp_nbstallack. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282.4.2 De-assertion of lp_irdy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

2.5 StreamID Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312.6 LPIF Request and Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

3.0 LPIF State Status Machine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343.1 Reset State Rules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343.2 Active State Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363.3 PM Entry Rules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

3.3.1 DAPM and L1.x Resolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383.4 PM Exit Rules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383.5 Retrain State Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393.6 LinkReset State Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403.7 Disabled State Rules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413.8 LinkError State Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423.9 Common State Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

4.0 Precise Time Measurement (PTM) Support. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

5.0 LPIF Bandwidth Scaling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

6.0 Configuration Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

7.0 Support for Pipelining . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 527.1 LogPHY Implementation Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

8.0 Support for PCIe. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 558.1 Encoding for 2.5 GT/s and 5.0 GT/s Data Rates . . . . . . . . . . . . . . . . . . . . . . . . . . . 558.2 L0s Support. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 558.3 Implementation Notes for Certain LPIF Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . 558.4 Data Path Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

8.4.1 Framing-Related Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 598.5 LTSSM to LPIF State Mappings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 618.6 LinkError State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 628.7 Flow Diagram Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

8.7.1 Initial Bringup to L0 (PCIe) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63



8.7.2 Recovery Flow Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 668.7.3 Entry into L1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 678.7.4 L1 Abort Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

9.0 Support for CXL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 709.1 Special Notes for LPIF Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 709.2 CXL over Flexbus LogPHY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

9.2.1 Data Path Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 709.2.2 LTSSM-to-LPIF State Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 739.2.3 LinkError State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 739.2.4 Avoiding Explicit Physical Layer Packet (PLP) Exchange for PM . . . . . . . . . . . 739.2.5 Flow Diagram Examples. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

10.0 Bifurcation Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

11.0 Implementation Notes for Certain Global Flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8111.1 DPC for PCIe/CXL Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8111.2 DPC for CXL Mode (if error isolation is not supported) . . . . . . . . . . . . . . . . . . . . . . 8211.3 Warm Reset Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8211.4 Sx Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

AppendicesA Protocol Link Layer Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

A.1 Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

B Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91



Figures

1 Partitioning for Interaction with Flexbus LogPHY ........................................................... 102 Protocol Stack Diagram Showing LPIF ......................................................................... 113 Multiple Protocol Link Stack Diagram with LPIF............................................................. 114 Bifurcated Protocol Link Stack Diagram with LPIF ......................................................... 125 Clock Gating Interface Handshake .............................................................................. 246 Example Waveform Showing Handling of Level Transition .............................................. 257 Example Waveform Showing Handling of Edge Transition .............................................. 258 Data Transfer from Link Layer to Physical Layer ........................................................... 279 Waveform Showing an Example NBStallReq/Ack Handshake .......................................... 2810 Waveform Showing the Stall/Req Mechanism............................................................... 2911 Stream Signal Connections........................................................................................ 3212 pl_state_sts Signal Transitions................................................................................... 3413 Transitions from Reset State...................................................................................... 3514 Transitions from Active State..................................................................................... 3615 Example of Successful Entry into PM State .................................................................. 3716 Example of Entry into PM State Rejected ..................................................................... 3717 Exit from PM State (Example is for Exit from L1 State).................................................. 3818 Transition from Retrain State..................................................................................... 4019 Transitions from LinkReset State ................................................................................ 4120 Transitions from Disabled State ................................................................................. 4221 Transition from LinkError State .................................................................................. 4322 Common State Handling ........................................................................................... 4423 Packet Format for a 32-bit Interface ........................................................................... 5024 Example Waveform for Transactions on Configuration Interface...................................... 5125 Block Diagram for Pipelined Implementation ................................................................ 5226 Stallreq StallAck Protocol, Pipelined Implementation ................................................. 5327 Example of pipelined data transfer ............................................................................. 5428 Tx Data Path, Example 1........................................................................................... 5629 Tx Data Path, Example 2........................................................................................... 5730 Tx Data Path, Example 3........................................................................................... 5731 Tx Data Path, Example 4........................................................................................... 5832 Rx Data Path, Example 1 .......................................................................................... 5833 Rx Data Path, Example 2 .......................................................................................... 5934 Mappings for Different Configuration and Training ........................................................ 6035 Mapping for 8-Port Configuration................................................................................ 6136 Initial Link Bringup for PCIe....................................................................................... 6337 Example Waveform of Signal Transitions ..................................................................... 6438 Example Waveform Showing LTSSM Substate Transitions .............................................. 6539 Recovery Flow Example ............................................................................................ 6640 L1 Entry Example..................................................................................................... 6741 L1 Abort Scenario 1.................................................................................................. 6842 L1 Abort Scenario 2.................................................................................................. 6943 Tx Data Transfer Example—No Link Subdivision ........................................................... 7044 Rx Data Transfer Example—No Link Subdivision ........................................................... 7145 Tx Data Transfer Example—Two Ports in x8 Configuration ............................................. 7246 Rx Data Transfer Example—Two Ports in x8 Configuration ............................................. 7347 CXL over Flexbus LogPHY—Initial Entry to L0 ............................................................... 7548 Example Waveform for CXL over Flexbus Bringup ......................................................... 7649 Recovery Flow for CXL over Flexbus............................................................................ 7750 L1 Entry Example..................................................................................................... 7851 L1 Abort Scenario .................................................................................................... 79



52 DPC for PCIe/CXL Mode ............................................................................................ 8153 Containment flow if eDPC is not supported .................................................................. 8254 Hot Reset flow ......................................................................................................... 8355 Packet Formats for the 16-bit Configuration Interface ................................................... 8956 Packet Formats for the 8-bit Configuration Interface ..................................................... 90



Tables

1 Definition of Terms.....................................................................................................82 Reference Documents and Locations.............................................................................93 List of Contributors.....................................................................................................94 Revision History....................................................................................................... 105 LPIF Signal List ........................................................................................................ 136 List of Signals for PCIe Support.................................................................................. 207 Clock Gating Interface .............................................................................................. 228 Configuration Interface ............................................................................................. 229 Requests Considered in Each LPIF State by Physical Layer ............................................. 3310 Field Descriptions for a Request ................................................................................. 4811 Mapping of Address Field for Different Requests ........................................................... 4812 Field Descriptions for a Completion............................................................................. 4913 LTSSM State Mapping to LPIF States........................................................................... 6114 Applicability of signals to different protocols................................................................. 86



1.0 Introduction

1.1 TerminologyTable 1 lists terms used in this specification.

Table 1. Definition of TermsTerm Definition

Ack Acknowledge

AER Advanced error reporting (register)

BFM Bus Functional Model. This is a software model used to test an RTL module.

CA Completer abort

CFG Configuration

CRC Cyclic Redundancy Check

CRS Configuration request retry status

CXL Compute Express Link

DAPM Deepest Allowable Power Management

DLLP Data link layer packet

DPC Downstream Port Containment

DW D-word

DP Downstream Port

eDPC enhanced Downstream Port Containment

EDS End of Data Stream

EIOS Electrical Idle Ordered Set

FLITFLow Control UnIT. This term describes messages sent across the interface that generally express the amount of data passed on contiguously.

GT/s Giga Transfers per second

LL Link layer

logPHY logical physical layer, or Logical PHY

LPIF Logical PHY Interface

LSM LPIF state machine

LTSSM Link Training and Status State Machine

PLP Physical layer packet

PMA Power Management Adapter - SoC module that manages global reset and power management flows.

PM Power Management

PTM Precise time measurement

QW Quad word

SC Successful completion



1.2 Reference DocumentsTable 2 lists documents cited in this specification.

1.3 ContributorsTable 3 lists contributors to this specification.

SoC System on Chip

SOS Skip Ordered Set

STP Start of Packet

TLP Transaction layer packet

UR Unsupported request

UP Upstream Port

RAS Reliability, Availability, and Serviceability

Table 1. Definition of TermsTerm Definition

Table 2. Reference Documents and LocationsSpecification Location

CXL Specification www.computeexpresslink.org

PCI Express Base Specification www.pcisig.com

Table 3. List of ContributorsMahesh Wagh Swadesh Choudhary Su Wei Lim

Poh Thiam Teoh Jayaprakash Prahladachar Bruce Tennant

Joon Teik Hor Das Sharma Debendra New Lei Thi

Ishwar Agarwal Charan Sundararaman Michelle Jen

Ganesh Valliappan Aaron Bowles Mike Greger

Abhinav Rajasekar Peeyush Purohit Ting Lok Song

Say Cheong Gan Shreesha Sathyanarayan Loo Hooi Kar

Kersinan Shashitheren Manojna Vungarala Sandeep Kanodia

Mark Wolski Susann Flowers Deborah Wible

Nitish Paliwal Rahul Boyapati Nitin Jain

Manjula Peddireddy Maheswaran Subramanian Vijay Pothi Raj

https://www.computeexpresslink.org

http://goto/pcie



1.4 Overview

1.4.1 About the InterfaceThe Logical PHY Interface (LPIF) specification defines a common interface between the link layer and a logical physical layer (logPHY) to facilitate interoperability, design, and validation reuse between link layers and a physical layer. When running multiple protocols, there may be an additional arbitration and multiplexer layer in between the link layer and the physical layer. Each instance in the multiple protocol implementation must have its independent LPIF interface. In cases where bifurcation is supported, each bifurcated port must have its own independent LPIF interface (see Figure 3).

Note: Data buses between LPIF ports can be shared, and this is strongly recommended. See Section 8.0, Support for PCIe on page 55.

This specification provides some information about how the logical physical layer and the link layers could operate in the various modes (CXL over Flexbus logPHY, or PCIe over Flexbus logPHY). This information should be viewed as guidelines or as one way to implement base specification requirements. Implementations can be done in other ways as long as they can meet the corresponding interoperability requirements when using this interface. All waveforms and flow diagrams in this specification should be considered as examples. Implementations should follow rules written out in the respective sections.

1.4.2 The Logical PHY Interface (LPIF)Figure 1 shows the partitioning assumed in this specification for operation with the Flexbus logPHY.

Figure 1. Partitioning for Interaction with Flexbus LogPHY

CXL.cachemem Transaction and Link Layer

Common PCIe/CXL.io Transaction

and Link Layer

Arbiter and Mux

Flexbus LogPHY

HS-PHY

Flex

bus P

HY

LPIF LPIF

Protocol transaction and data link layersPacket/FLIT Packing/

UnpackingAnd CXL Deframing

State machines for Link Training and Status State Machine (LTSSM), lane-lane deskew, Idles/EDS/SOS

insertion, lane reversal, link degradation, PCIe deframing, scrambling/descrambling, 8b/10b or 128b/130b encode/decode (SerDes PIPE), elastic

buffer (SerDes PIPE)PIPE (SERDES)

Analog buffersRx detectionPower sequencing

SERDES

LPIF



Figure 2. Protocol Stack Diagram Showing LPIF

Figure 3. Multiple Protocol Link Stack Diagram with LPIF

Transaction Layer

LPIF

Link Layer

PHY

Logical PHY

PCS/AFE

LPIF(0) LPIF(1)

Arbiter and Mux

Transaction Layer (0)

Link Layer (0)


Link Layer (1)

PHY

Logical PHY

PCS/AFE

LPIF



Figure 4. Bifurcated Protocol Link Stack Diagram with LPIF

LPIF(0) LPIF(1)

Transaction Layer (Port 0)

Link Layer (0)

Transaction Layer (Port 1)

Link Layer (1)

PHY

Logical PHY

PCS/AFE



2.0 LPIF Signal List

Table 5 lists the baseline LPIF signals and their descriptions. It also indicates whether a signal is Per LPIF Port (or instance). Per Lane refers to the notion of a lane as defined in the PCI Express Base Specification. All signals are synchronous with lclk, unless explicitly mentioned to be asynchronous.

In Table 5:

• pl_* indicates that the signal is driven away from the physical layer to the link layer.

• lp_* indicates that the signal is driven away from the link layer to the physical layer.

Table 5. LPIF Signal List

Signal Name Per Port/Per Lane Description

lclk Per Port

Link Clock: The clock frequency at which the LPIF interface operates.The Link Clock is an input to signal to both the link layer as well as the logPHY.The SoC is responsible for providing the Link Clock.

pl_trdy Per PortThe physical layer is ready to accept data. Data is accepted by the physical layer when pl_trdy, lp_valid, and lp_irdy are asserted.

pl_data[NBYTES-1:0][7:0] Shared1 Physical layer to link layer data, where NBYTES equals the number of bytes determined by the supported data bus for the LPIF interface.

pl_valid[PL_NVLD-1:0] Shared

Physical layer to link layer indicates data valid on pl_data. PL_NVLD equals the number of valid bits. The bytes of pl_data associated with a specific bit of pl_valid is implementation-specific.

pl_crc[NCRC-1:0][7:0] Per Port

Physical layer to link layer CRC bytes for CXL FLITs. NCRC is the number of CRC bytes in the CXL FLIT. It is only valid when the corresponding pl_crc_valid bit is asserted. This signal is not applicable if in PCIe mode (Rx must ignore it).

pl_crc_valid Per PortPhysical layer to link layer indication if the corresponding CRC bytes are valid. This signal is not applicable if in PCIe mode (Rx must ignore it).

pl_stream[7:0] Per Port

Physical layer to link layer indicating the stream ID associated with the received data.See Section 2.5, StreamID Rules on page 31.The logPHY forwards the stream ID received from the remote agent.



pl_error Per Port

Indicates that the physical layer detected an encoding or framing-related error. This signal shall be asserted by the logPHY when non-training related errors are detected. Note that non-training errors are logPHY-specific. The logging of errors must be determined by the upper level protocols.See protocol-specific notes in Section 8.0, Support for PCIe on page 55 and Section 9.0, Support for CXL on page 70.

pl_trainerror Per Port

Indicates that physical layer training failed.This signal shall be asserted by the logPHY when training-related errors are detected.The logging of errors must be determined by the upper level protocols. The logPHY may use this signal to indicate other uncorrectable errors as well (such as internal parity errors) and transition to LinkError state as a result.

pl_cerror Per Port

Indicates that the physical layer received an error that was corrected by the physical layer.The logging of errors must be determined by upper layer protocols.

pl_stallreq Per PortPhysical layer request to link layer to flush all packets for state transitionSee Section 2.4, Stall Req/Ack Mechanism on page 27 for details.

pl_tmstmp Per PortTime stamp signal returned by the physical layer to link layer.See Section 4.0, Precise Time Measurement (PTM) Support on page 45 for more details.

pl_tmstmp_stream[7:0] Per Port

Physical layer to link layer signal indicating the StreamID associated with timestamp signal pl_tmstmp.See Section 4.0, Precise Time Measurement (PTM) Support on page 45 for more details.

pl_phyinl1 Per Port

Physical layer to link layer indication that the physical layer is in L1 state. Note that pl_state_sts indicates the status of the interface whereas this signal is asserted after the physical layer completes entry into L1 state.

pl_phyinl2 Per Port

Physical layer to link layer indication that the physical layer is in L2 state. Note that pl_state_sts indicates the status of the interface whereas this signal is asserted after the physical layer completes entry into L2 state.

lp_irdy Per PortLink layer to physical layer indicating link layer is ready to transfer data. lp_irdy must not be presented by the upper layers when pl_state_sts is RESET.

Table 5. LPIF Signal List (Continued)




lp_pri[1:0] Per Port

Link layer to physical layer indicating priority level of irdy. This is useful when running in a multi-protocol case where the link layer can indicate the priority of the request.Encoding for lp_pri[0] is as follows:0b—High1b—Lowlp_pri[1] is used to give additional priority encodings.The specific priority schemes used is implementation-specific.Link layer implementations only using a single bit of priority must drive lp_pri[1] to '0'.

lp_data[NBYTES-1:0][7:0] Shared1 Link layer to physical layer Data, where 'NBYTES' equals number of bytes determined by the data width for the LPIF instance.

lp_stream[7:0] Per Port

Link layer to physical layer indicates the stream ID to use with data.See Section 2.5, StreamID Rules on page 31 for details.

lp_valid[LP_NVLD-1:0] Shared

Link layer to physical layer indicates data valid on the corresponding lp_data bytes.'LP_NVLD' equals the number of valid bits. The bytes of lp_data associated with a specific bit of lp_valid is implementation-specific. When lp_irdy is asserted, at least one of the bits of lp_valid must be asserted.

lp_crc[NCRC-1:0][7:0] Per Port

Link layer to physical layer CRC bytes. NCRC is the number of CRC bytes in the CXL FLIT. This signal is not applicable if in PCIe mode (Rx must ignore). It is only valid when the corresponding lp_crc_valid bits are asserted.

lp_crc_valid Per PortLink layer to physical layer indication that corresponding CRC bytes are valid. This signal is not applicable if in PCIe mode (Rx must ignore).

lp_stallack Per Port Link layer to physical layer indicates that the packets are aligned LPIF width boundary (if pl_stallreq was asserted)





lp_state_req[3:0] Per Port

Link layer request to logical physical layer to request state change.Encodings as follows:0000: NOP0001: Active0010: Active.L0s0011: Deepest Allowable PM State [L1 Substates only]0100: L1.10101: L1.20110: L1.30111: L1.41000: L21001: LinkReset1010: Reserved1011: Retrain1100: DisableAll other encodings are reserved. Table 9 describes the Requests considered by the physical layer in each of the LPIF interface state. The link layer must consider the interface state status and make the necessary request modifications.

pl_state_sts[3:0] Per Port

Physical layer to link layer Status indication of the Interface.Encodings as follows:0000: Reset0001: Active0010: Active.L0s0011: Reserved0100: L1.10101: L1.20110: L1.30111: L1.41000: L21001: LinkReset1010: LinkError1011: Retrain1100: DisableAll other encodings are reserved.The status signal is also an asynchronous logPHY State transition indication. For example the logPHY asserts the Retrain signal when it decides to enter retraining either autonomously or when requested by remote agent.

lp_tmstmp Per PortLink layer to physical layer Timestamp signal.See Section 4.0, Precise Time Measurement (PTM) Support on page 45 for more details.





lp_linkerror Per Port

Link layer to physical layer indication that a fatal error has occurred, and physical layer must move to LinkError state when it samples this signal. It is also used for Downstream Port Containment flows. See Chapter 11.0

pl_quiesce Per PortLogPHY is requesting Quiescence from upper layers. Typical usage is for quiescence guarantee mechanism as specified in the PCI Express Base Specification.

lp_flushed_all Per Port

Indication from link layer that upper layers are empty [in response to pl_quiesce]. It is only asserted when pl_quiesce is asserted, and the upper layers have taken all the necessary actions to have quiescence guarantee. LogPHY may implement a 1 ms timeout for this and escalate to software appropriately on a timeout.

lp_rcvd_crc_err Per PortPulse indication that link layer saw a CRC error. Used for RAS by logPHY to monitor frequency of CRC errors. Multiple CRC errors in the same clock cycle show up as a single pulse only.

pl_lnk_cfg[2:0] Per Port

Width of the port: This bit field indicates the width of the port as determined by the Link initialization000 - x1001 - x2010 - x4011 - x8100 - x12101 - x16110 - x32Others - ReservedLink layer should only consider this to be relevant when pl_state_sts = RETRAIN or ACTIVE.

pl_lnk_up Per PortIndication from logPHY indicating Link Up state (as specified in the corresponding link specification. For an example, refer to the PCI Express Base Specification).

pl_rxframe_errmask Per Port

Rx Framing Error Reporting Mask: When asserted, receiver framing error should be masked off in the link layer.logPHY asserts this based on link state and data path alignment to make sure false errors are not logged by the link layer. This mask does not apply to pl_error, pl_trainerror, pl_cerror. It does apply to pl_byte_error (whenever pl_byte_err is applicable). This signal should be pipeline matched to pl_data.





pl_portmode[PW-1:0] n/a

Port mode settings indication from logPHY indication how the interface is subdivided. This is an asynchronous signal [not tied to lclk being available]It is a bit vector of PW bits (where PW is the width of portmode—it can be different than the number of ports associated with a specific LPIF instance to allow multiple controllers muxing to the same logPHY). As an example, if we support a maximum of 4 ports on LPIF in PCIe context, then the encodings correspond to link subdivision as follows:No Enabled Port 4'b0000x16 4'b0001x8/x8 4'b0101x8/x4x4 4'b0111x4x4/x8 4'b1101x4x4x4x4 4'b1111The encoding of this vector is determined by the link subdivision configuration (not the negotiated link width by logPHY), with the active port getting its index bit set. For asymmetric configurations also, the same convention is followed, with potentially one of the bits always set to 0 (to make a symmetric encoding).

pl_portmode_val n/a

pl_portmode setting from logPHY is valid. This is an asynchronous signal [not tied to lclk being available]When exiting RESET during initial bringup or otherwise, upper layers should not transition lp_state_req or other LPIF interface signals unless pl_portmode_val has been asserted by logPHY. This ensures that linkphy signals don't leave default state for inactive ports. pl_portmode_val is expected to be asserted before pl_protocol_vld.

pl_speedmode[2:0] Per Port

Current Link Speed as negotiated by the logPHY(3'b000 = Gen1,3'b001 = Gen2,3'b010 = Gen3, 3'b011 = Gen4, 3'b100 = Gen5, rest = Rsvd)Link layer should only consider this to be relevant when pl_state_sts = RETRAIN or ACTIVE.

pl_clr_lnkeqreq[2:0] Per PortLogPHY indication to clear Link Equalization Request bit in Link Status 2 register (3'b001 = Gen3, 3'b010 = Gen4, 3'b100 = Gen5, rest = Rsvd).

pl_set_lnkeqreq[2:0] Per PortLogPHY indication to set Link Equalization Request bit in Link Status 2 register(3'b001 = Gen3, 3'b010 = Gen4, 3'b100 = Gen5, rest = Rsvd).

pl_inband_pres Per PortIn-band presence detect indication from logPHY. It is asserted according to the rules outlined in the PCI Express Base Specification, when the logPHY enters Polling.Configuration.

lp_device_present Per Port

Based on a mode configured in the logPHY, this signal is asserted by the link layer to allow logPHY to perform periodic Receiver Detection. This mode is used for aggressive power savings, if it is known that no device is present in a particular slot. This is an asynchronous signal [not tied to lclk being available]





pl_ptm_rx_delay[7:0] Per Port

Current latency in nanoseconds (ns) through Rx path (part of PTM). Intermediate nodes (for e.g., Arb/Mux) must take the value from the previous node, add their own latency in ns and then forward to the next node.

lp_force_detect Per Port This is a level signal. It forces logPHY to shut down the receiver, drive and keep the physical LTSSM in Detect.

pl_setlabs Per Port LogPHY's pulsed indication to set Link Auto Bandwidth Change status in Link Status register

pl_setlbms Per Port LogPHY's pulsed indication to set Link Bandwidth Management status in Link Status register

pl_surprise_lnk_down Per Port Reporting surprise link down as seen by physical layer2

pl_protocol[2:0] Per Port

LogPHY indication to upper layers about which protocol was detected during training. It has the following encodings:000b - PCIe or DMI001b - RSVD010b - RSVD

011b - CXL.1 [1.1—Single protocol]3 100b - CXL.2 [1.1—Multi-protocol, Type 1, Type 2, or Type 3 devices]4 101b - CXL.3 [2.0—Multi-protocol, only Type 1 or Type 2 devices]110b - CXL.4 [2.0—Multi-protocol, only Type 3 devices]111b - CXL.5 [2.0—Single protocol]

pl_protocol_vld Per Port

Indication that pl_protocol has valid information. This is a level signal, asserted when the logPHY has discovered the appropriate protocol, but can de-assert again after subsequent transitions to RESET state depending on the link state machine transitions.

pl_err_pipestg Per Lane LogPHY to LL error due to 128b/130b error OR elastic buffer pointer collision. This signal is pipeline matched with data.

lp_wake_req Per Port

Request from the link layer to remove clock gating from the internal logic of the logPHY. This is an asynchronous signal [not tied to lclk being available]. See Section 2.2, Exit Clock Gating Req/Ack Mechanism on page 22 for more details on the rules for this signal.

pl_wake_ack Per Port

Acknowledge from the logPHY that it has ungated clocks in response to lp_wake_req. Only asserted when lp_wake_req is asserted, and de-asserted after lp_wake_req has de-asserted. This is synchronous with lclk. See Section 2.2, Exit Clock Gating Req/Ack Mechanism on page 22 for more details on the behavior of this signal.

pl_clk_req Per Port

Request from the logPHY to remove clock gating from the internal logic of the link layer. This is an asynchronous signal [not tied to lclk being available]. See Section 2.2, Exit Clock Gating Req/Ack Mechanism on page 22 for more details on the rules for this signal.





Table 6 lists signals that have been added to LPIF for PCIe support.

lp_clk_ack Per Port

Acknowledge from the link layer that it has ungated clocks in response to pl_clk_req. Only asserted when pl_clk_req is asserted, and de-asserted after pl_clk_req has de-asserted. This is synchronous with lclk. See Section 2.2, Exit Clock Gating Req/Ack Mechanism on page 22 for more details on the behavior of this signal.

pl_phyinrecenter Per Port

Physical layer to link layer indication that the physical layer is in Recovery (or Recenter) state.PCIe: Asserted when Rx enters Recovery (TS OS received), pl_state_sts indicates when Tx enters recovery. This can be used by link layer to ignore logging of receiver errors. CXL with Flexbus: Transitions along with pl_state_sts only. Because FLITs are blocked by logPHY, link layer does not need a separate indication.

1. It is strongly recommended to share the data bus between bifurcated ports. 2. Link layer directed link down will also be observed on this signal. Hence, this must be properly qualified by the

upper layers before logging into software visible registers.3. Currently, CXL.io is the only protocol supporting single protocol mode.4. Currently, CXL.io and CXL.cacheMem are supported in multi-protocol mode. Type 1/Type 2 and Type 3 device

definitions are part of the CXL Specification.



Table 6. List of Signals for PCIe Support


pl_nbstallreq Per PortPhysical layer request to link layer to align packets at LPIF width boundarySee Section 2.4, Stall Req/Ack Mechanism on page 27 for details.

lp_nbstallack Per PortLink layer acknowledge to pl_nbstallreq. See Section 2.4, Stall Req/Ack Mechanism on page 27 for details.

lp_kchar[n-1:0] Shared

Link layer to physical layer k-character indication, where 'n' equals number of bytes.For PCIe 2.5GT/s and 5GT/s speeds, it indicates if the byte on the corresponding lp_data is a k-character ('1') or not ('0'). For all other protocols and PCIe speeds, this should be driven to 0 by link layer and not sampled by physical layer.

pl_block_dl_init Per Port Indication from the logPHY to the LL to block initialization of DLLPs.

lp_dl_active Per Port

Indication from the LL that Data Link Control and Management State Machine is in DL_Active state (as defined in the PCI Express Base Specification).Link Layer must eventually de-assert this signal if the state moves to LinkError. logPHY is permitted to wait for this before reporting surprise link down.

lp_good_dllp Per Port Indication from link layer that a data link layer packet (DLLP) was received without errors.



pl_in_rxl0s Per Port Indication from logPHY that Rx is in L0s

pl_byte_err[(n-1):0] SharedCorresponding byte of data has an error. This is applicable in all speed modes. In Gen1/2 framing, it denotes k-char error detected by logPHY.

pl_kchar[(n-1):0] Shared k-char indication from logPHY. When asserted, the corresponding data byte must be interpreted at the LL as a k-char.

pl_tx_nfts[7:0] Per Port LogPHY reports the value of NFTS captured from the link.

pl_rx_nfts[7:0] Per Port LogPHY reports the value of NFTS requested for RXL0s exit.

pl_sris_en Per Port LogPHY indication if the link is operating in SRIS mode

pl_dlpstart[w-1] Shared

LogPHY indicates the start of a data link layer packet for Gen3 and above speeds. Each bit corresponds to a specific data byte depending on the configuration of the port. The value of 'w' is implementation-specific—chosen to allow supported configurations. See Section 8.4.1, Framing-Related Signals on page 59 for rules regarding the association of the bits of this signal with data bytes.

pl_dlpend[w-1] Shared

LogPHY indicating the end of a data link layer packet for Gen3 and above speeds. Each bit corresponds to a specific data byte depending on the configuration of the port. The value of 'w' is implementation-specific—chosen to allow supported configurations. See Section 8.4.1, Framing-Related Signals on page 59 for rules regarding the association of the bits of this signal with data bytes.

pl_tlpstart[w-1] Shared

LogPHY indicating the start of a Transaction Layer packet for Gen3 and above speeds (STP). Each bit corresponds to a specific data byte depending on the configuration of the port. The value of 'w' is implementation-specific—chosen to allow supported configurations. See Section 8.4.1, Framing-Related Signals on page 59 for rules regarding the association of the bits of this signal with data bytes.

pl_tlpend[w-1] Shared

LogPHY indicating the end of a Transaction Layer packet for Gen3 and above speeds (END). Each bit corresponds to a specific data byte depending on the configuration of the port. The value of 'w' is implementation-specific—chosen to allow supported configurations. See Section 8.4.1, Framing-Related Signals on page 59 for rules regarding the association of the bits of this signal with data bytes.

pl_tlpedb[w-1] Shared

LogPHY indicating EDB received for Gen3 and above speeds. Each bit corresponds to a specific data byte depending on the configuration of the port. The value of 'w' is implementation-specific—chosen to allow supported configurations. See Section 8.4.1, Framing-Related Signals on page 59 for rules regarding the association of the bits of this signal with data bytes.

pl_rx_flush Per Port Request from logPHY to link layer to flush its receiver pipeline. This typically occurs for framing errors in Gen3.

Table 6. List of Signals for PCIe Support (Continued)




2.1 Interface Reset RequirementsThe LPIF specification does not define a separate interface signal for reset; however, it is required that the logic entities on both sides of LPIF are in the same reset domain and the reset for each IP is derived from the same source.

2.2 Exit Clock Gating Req/Ack MechanismTable 7 describes the control signals required for Exit Clock Gating Req/Ack mechanism. The Exit Clock Gating Req/Ack mechanism is a full handshake, as described by the rules below:

1. LogPHY asserts the pl_exit_cg_req signal to request ungating of clocks by the upper layers. A rising edge on pl_exit_cg_req can only occur when lp_exit_cg_ack is de-asserted.

2. The upper layers assert the lp_exit_cg_ack to indicate that Upper Level stacks are not in clock gated state and are ready to receive packets from the physical layer. Once physical layer samples the lp_exit_cg_ack, it is also free to send packets on the Rx path.1 The lp_exit_cg_ack signal must assert within a specific time window (see Section 8.7.1, Initial Bringup to L0 (PCIe) on page 63) of the pl_exit_cg_req asserting—this is to avoid LTSSM timeouts for Flexbus usages.

Table 7. Clock Gating Interface


pl_exit_cg_req Per Port When asserted, requests upper level protocol stacks to exit clock gated state.

lp_exit_cg_ack Per PortWhen asserted, indicates that upper level protocol stacks are not in clock gated state and are ready to receive packets from the physical layer.

Table 8. Configuration Interface

Signal Name Per Port/ Per Lane Description

pl_cfg[NC-1:0] Per Port

This is the configuration interface from logPHY to the link layer. See Section 6.0, Configuration Interface on page 47 for details. NC is the width of the interface. Supported values are 8, 16, and 32.

pl_cfg_vld Per Port When asserted, indicates that pl_cfg has valid information that should be consumed by the link layer.

lp_cfg[NC-1:0] Per PortThis is the configuration interface from link layer to logPHY. See Section 6.0, Configuration Interface on page 47 for details. NC is the width of the interface. Supported values are 8, 16, and 32.

lp_cfg_vld Per Port When asserted, indicates that lp_cfg has valid information that should be consumed by the logPHY.

1. This is needed especially in the cases of PCIe logPHY, where the link layer must be ready to receive IDLE tokens while the LTSSM is still in Recovery.IDLE (pl_state_sts is RETRAIN).



3. The pl_exit_cg_req signal and lp_exit_cg_ack signal must be sampled as asserted by the physical layer before entering the Active state, if the physical layer is performing this handshake for that transition (see Implementation Note).

4. The pl_exit_cg_req signal must de-assert before lp_exit_cg_ack signal. It is the responsibility of the logPHY to control the specific scenario of de-assertion.

5. When exiting reset or low power state (L1, L2, Reset, or Disable), logPHY must ensure the state change is sampled by the upper layer. It is permitted to assert pl_exit_cg_req before the state change, in which case it must stay asserted until the state status transitions. Alternatively, if transitioning to a non-Active state, it is permitted to assert pl_exit_cg_req after the state status transition, but in this case it must wait for lp_exit_cg_ack before performing another state transition.

It is required for the upper layers to remove clock gating before the first entry into Active state, every entry into LinkError, and on every entry into Active state from other states where clock gating of link layer is permitted. Clock gating is permitted for Reset,L1, L2, and Disable states.

Implementation Note

Physical layer is allowed to initiate exit_cg_req/ack handshake at any time and the link layer must respond. It is used during initial boot to ensure link layer is ready to receive packets, for PM exit, or any other conditions deemed necessary by the physical layer. It is also permitted in certain protocols to omit this handshake for transitioning between two states that do not implement clock gating (RetrainActive transition for example).

During Initialization, the logPHY initiates this protocol to ensure that the upper layers exit clock gating and are ready to receive packets before first entry into the Active state. It is mandatory to participate in this protocol handshake when initiated on LPIF, even if the upper layers have exited clock gating and for those implementations that do not support upper layer clock gating.

When the upper layer is initiating PM exit, then it must ensure its PM and clock gating are removed first. A request to exit from L1 is initiated by the upper layer by changing the current lp_state_req encoding to a new requested state (other than the currently requested state), the change in the lp_state_req can be used by the logPHY to exit Trunk and local clock gating. In this case, individual bits of lp_state_req signal must be guaranteed to be glitch free to avoid multiple clock ungating requests. Upper layer can request removal of trunk and local clock gating by asserting lp_wake_req (asynchronous to lclk availability). All logPHY implementations must respond with a pl_wake_ack (synchronous to lclk). The extent of internal clock ungating when pl_wake_ack is asserted is implementation-specific, but lclk must be available by this time to enable LPIF interface transitions from the upper layers. The Wake Req/Ack is a full handshake (see additional notes in Section 2.2.1, Implementation Rules for Clock Gating on page 24):

1. Upper layer asserts lp_wake_req to request ungating of clocks by the logPHY. This can be done in parallel to lp_state_req change.

2. The logPHY asserts pl_wake_ack to indicate that clock gating has been removed. There must be at least one clock cycle bubble between lp_wake_req assertion and pl_wake_ack assertion.

3. lp_wake_req must de-assert before pl_wake_ack de-asserts. It is the responsibility of the upper layer to control the specific scenario of de-assertion. As an example, when performing the handshake for a state request, it can keep lp_wake_req asserted until it observes the desired state status.

4. lp_wake_req should not be the only consideration for logPHY to perform clock gating, it must take into account pl_state_sts and other protocol-specific requirements before performing trunk and/or local clock gating.



If the physical layer is initiating an exit from PM state, then it must ensure that upper layer clock gating is removed. When the physical layer initiates exit from PM, the physical layer must initiate the exit clock Req/Ack mechanism by asserting the pl_exit_cg_req signal. The pl_exit_cg_req signal must be guaranteed to be glitch free to avoid multiple clock ungating requests.

If the physical layer initiates an entry into LinkError state, then it must ensure that upper layer clock gating is removed so that the hardware failure is notified to the upper layer.

LPIF provides an optional mechanism in the form of pl_clk_req and lp_clk_ack handshake to allow the logPHY to request removal of clock gating from upper layers. This mechanism is especially useful in situations where multiple protocol layers mux over a common logPHY, but certain link functionality (e.g., Interrupt generation for link events) is handled by only one of the protocols. In this case, logical PHY can use the pl_clk_req and lp_clk_ack handshake to make sure the corresponding protocol layer has its clock gating removed (regardless of LPIF state). The rules for this handshake are:

1. LogPHY asserts pl_clk_req to request removal of clock gating by the link layer. This can be done asynchronously, and independent of current LPIF state.

2. The link layer asserts lp_clk_ack to indicate that clock gating has been removed. There must be at least one clock cycle bubble between pl_clk_req assertion and lp_clk_ack assertion.

3. pl_clk_req must de-assert before lp_clk_ack. It is the responsibility of the logPHY to control the specific scenario of de-assertion, after the required actions for this handshake are completed.

4. pl_clk_req should not be the only consideration for link layer to perform clock gating, it must take into account pl_state_sts and other protocol-specific requirements before performing trunk and/or local clock gating.

See additional notes in Section 2.2.1, Implementation Rules for Clock Gating on page 24.

Figure 5 describes the clock gating interface protocol for pl_exit_cg_req and lp_exit_cg_ack.

Figure 5. Clock Gating Interface Handshake

2.2.1 Implementation Rules for Clock GatingGiven below are certain rules and waveforms to illustrate clock gating scenarios between upper layers and logPHY.

Rules for pl_clk_req/lp_clk_ack handshake (for both Downstream and Upstream ports):

pl_exit_cg_req

lp_exit_cg_ack

Link Layer ensures PM is exited and clock

running beforeAck

Check Ack before deassertion

(Full Handshake)

Check Ack before assertion

(Full Handshake)



1. LogPHY must use this handshake to ensure transitions from the following signals have been observed by the upper layers:a. pl_phyinl1 (level)b. pl_phyinl2 (level)c. pl_inband_pres (level)d. pl_setlabs (edge)e. pl_setlbms (edge)f. pl_clr_lnkeqreq (edge)g. pl_set_lnkeqreq (edge)

In the above bullets, "level" implies the expected sampling is level transitions, so logPHY can let the signal transition without waiting for lp_clk_ack. And "edge" implies that the expected sampling is edge/pulse, hence logPHY must wait for lp_clk_ack before letting the corresponding signal transition. Some example waveforms follow.

Figure 6. Example Waveform Showing Handling of Level Transition

Figure 7. Example Waveform Showing Handling of Edge Transition

Rules for upper layers (for both Downstream and Upstream ports):

1. When performing lp_wake_req/pl_wake_ack handshake for lp_state_req transitions, the upper layers are permitted to not wait for pl_wake_ack before changing lp_state_req.

2. When performing lp_wake_req/pl_wake_ack handshake for lp_cfg transitions, upper layers must wait for pl_wake_ack before changing lp_cfg or lp_cfg_vld. Because lp_cfg can have multiple transitions for a single packet transfer, it is necessary to make sure logPHY clocks are up before transfer begins.1

1. Certain implementations have the configuration access logic on a different reset domain compared to the main data path logic. In these scenarios, the lp_wake_req/pl_wake_ack logic and the configuration interface must be on the reset domain relevant for configuration access enabling. It is assumed in LPIF that if configuration access logic is put on a different reset domain, it must be out of reset before the main data path logic in the system reset flow



3. Upper layers can perform local clock gating in RESET/PM/Disabled states. LinkError and LinkReset are not considered as states where clock gating is permitted.1

a. When clock-gated in RESET/Disabled states, link layers that rely on dynamic clock gating to save power should monitor pl_inband_pres signal before requesting lp_state_req = ACTIVE. Because pl_inband_pres gives an indication of logPHY having reached far enough in LTSSM transitions to ensure that some device is connected, this allows upper layers to be clock gated if no device is connected in a slot (and enable SoC level PM flows even if a slot is unpopulated). In Disabled state, pl_inband_pres might be asserted for some protocols. It is still allowed for link layers to clock gate themselves and because the eventual link bringup will have to transition the pl_state_sts through RESET (logPHY is required to do pl_exit_cg_req for DisabledRESET transition), the link layer can sample pl_inband_pres in Reset to determine if it should request Active. If pl_inband_pres de-asserts while pl_state_sts = RESET, then the link layer can return to clock-gated state.

Example sequence of steps for dynamically clock-gated link layers:

Initial State is RESET, link layer is requesting NOP.

1. Firmware writes to logPHY register to start link training.2. After logPHY has reached a safe point in training to determine that something is

connected, it performs the flow to assert pl_inband_pres bit (this includes the corresponding pl_clk_req handshake as described above).

3. Link layer takes all actions required on sampling pl_inband_pres (this is protocol-specific), and begins requesting ACTIVE on lp_state_req (this should be accompanied by lp_wake_req handshake).

4. LogPHY samples the NOPACTIVE transition on lp_state_req and completes the flow required to reflect pl_state_sts = ACTIVE (this includes one or more pl_exit_cg_req handshakes to make sure the receive path of link layer is ready).

2.2.2 Rules for Hot Plug Support with Multiple ProtocolsIt is expected that pl_portmode and pl_portmode_vld are present before clock gating is enabled by firmware, or the sampling of pl_portmode and pl_portmode_vld is on a free running clock.

Rules for link layer:

1. Must sample and store pl_protocol when pl_protocol_vld = 1 and pl_state_sts = RESET and pl_inband_pres = 1. It must treat this saved value as the negotiated protocol until pl_state_sts = RESET and pl_inband_pres = 0.

2. Link layer is allowed to delay lp_exit_cg_ack and/or lp_state_req = ACTIVE until pl_protocol_vld is asserted, but both must assert within a reasonable time after lp_exit_cg_req = 1 and pl_protocol_vld = 1.2

3. Link layer is permitted to clock gate itself when pl_state_sts = RESET and pl_inband_pres = 0 (in which case it will not request for ACTIVE). When this is supported, if pl_inband_pres goes from 10 when pl_state_sts = RESET, the link layer should move pl_state_req from ACTIVE to NOP and go back to clock-gated state.

1. Link layer implementations may not have to do anything special if the logPHY guarantees pl_exit_cg_req remains asserted during LinkError and LinkReset states. Refer to the Logical PHY High Level Architecture Specification to determine if this is the case.

2. For protocols like PCIe and CXL, it is recommended to not exceed 0.5 to 1ms range to avoid LTSSM timeouts.



Rules for logPHY:

It must ensure that if pl_inband_pres = 1 and pl_protocol_vld = 1 and pl_state_sts = RESET, then pl_protocol is the correct protocol for link layers to sample.

2.3 Data TransferAs indicated in the signal list descriptions, when link layer is sending data to the physical layer, data is transferred when lp_irdy, pl_trdy and lp_valid are asserted. Figure 8 shows an example waveform for data transfer from the link layer to the physical layer. Data is transmitted on clock cycles 1, 2, and 5. No assumption should be made by link layer about when pl_trdy can de-assert or for how many cycles it remains de-asserted before it is asserted again, unless explicitly guaranteed by the physical layer.

Figure 8. Data Transfer from Link Layer to Physical Layer

As indicated in the signal list descriptions, when physical layer is sending data to the link layer, there is no backpressure mechanism, and data is transferred whenever pl_valid is asserted.

2.4 Stall Req/Ack MechanismThe Stall Req/Ack mechanism is used by the physical layer to interrupt the packet transfers by the upper layers for conditions where it is required by the upper layers to transmit aligned packets to guarantee correct framing alignment and identification by the receiving link layer. The Stall Req/Ack mechanism must be used when exiting Active state. It is also permissible to use the mechanism and remain in Active through the entire handshake. The Stall Req/Ack mechanism is mandatory for all LPIF implementations. Link layers that don't utilize the Stall Req/ACK mechanism may, for example, flop the stallreq and feed the flop output back as stallack.

The link layer/logPHY pair may choose to differentiate between alignment related stall (for framing) versus state transition related stall—in cases where implementations want to optimize latencies between these two conditions. Thus, LPIF defines a non-blocking stallreq handshake (pl_nbstallreq/lp_nbstallack) to be used for alignment-related stalls, and pl_stallreq to be used for state transitions.

There are two mechanisms allowed for pl_nbstallreq behavior. The rules for each of these follow.



2.4.1 Full Handshake with lp_nbstallackThe rules for pl_nbstallreq/lp_nbstallack are:

1. When the link layer samples pl_nbstallreq, it indicates packet alignment by asserting lp_nbstallack aligned with the lp_valid of the last data phase of a packet. The logPHY samples lp_nbstallack at the same time as the data phase it was aligned with (i.e., lp_irdy, lp_valid, pl_trdy are asserted).

2. LogPHY interprets the lp_nbstallack sampled as indication of packet alignment (or end of packet), and can proceed to take appropriate action (e.g., EDS and SOS insertion for PCIe protocol) after that packet. This may result in eventual backpressure to the link layer through pl_trdy de-assertion.

3. LogPHY must de-assert pl_nbstallreq after sampling lp_nbstallack and before initiating a new pl_nbstallreq request. After lp_nbstallack is seen on the interface, it can take several cycles for logPHY to de-assert pl_nbstallreq, and hence, link layer should wait for de-assertion of pl_nbstallreq before sampling it again.

4. Implementations where the logPHY differentiates between pl_nbstallreq and pl_stallreq, it owns the responsibility to avoid race conditions between the two. It must not assert both signals at the same time. If it chooses to abort pl_nbstallreq and switch over to pl_stallreq, it must internally handle ignoring the lp_nbstallack from the link layer and waiting for lp_stallack. If the logPHY is executing a pl_stallreq handshake, there should be no scenario requiring it to assert pl_nbstallreq at this time (since it is already flushing the link layer for a state transition).

Figure 9. Waveform Showing an Example NBStallReq/Ack Handshake

2.4.2 De-assertion of lp_irdy1. When the link layer samples pl_nbstallreq, it indicates packet alignment by

asserting a bubble on lp_irdy after the last transfer of a packet. Only a single cycle de-assertion is sufficient.

2. LogPHY interprets the absence of lp_irdy as indication of packet alignment (or end of packet), and can proceed to take appropriate action (e.g., EDS and SOS insertion for PCIe protocol) after that packet. This may result in eventual backpressure to the link layer through pl_trdy de-assertion.

3. LogPHY must de-assert pl_nbstallreq after lp_irdy bubble and before initiating a new pl_nbstallreq request. After lp_irdy de-assertion is seen on the interface, it can take several cycles for logPHY to de-assert pl_nbstallreq, and hence, link layer should wait for de-assertion of pl_nbstallreq before sampling it again.

4. Implementations where the logPHY differentiates between pl_nbstallreq and pl_stallreq, it owns the responsibility to avoid race conditions between the two. It must not assert both signals at the same time. If it chooses to abort pl_nbstallreq and switch over to pl_stallreq, it must internally handle ignoring the lp_irdy de-assertion from the link layer and waiting for lp_stallack. If the



logPHY is executing a pl_stallreq handshake, there should be no scenario requiring it to assert pl_nbstallreq at this time (since it is already flushing the link layer for a state transition).

5. This mechanism can only be used when a natural de-assertion of lp_irdy is not possible from the link layers in the middle of packet transfers. There must be no ambiguity in implementation—a bubble on lp_irdy when pl_trdy is asserted MUST indicate packet alignment.

6. Implementations pipelining the LPIF interface using this mechanism must have a corresponding mechanism to transfer the lp_irdy bubble across pipeline when pl_nbstallreq is asserted.

Implementation Note

Because the lp_irdy de-assertion based mechanism has assumptions around the data rates between upper layers and logPHY, logPHY implementations catering to multiple different link layers supporting pl_nbstallreq would benefit from supporting lp_nbstallack behavior.

Figure 10. Waveform Showing the Stall/Req Mechanism

The stallreq/stallack handshake is a four-phase sequence that follows the rules below:

1. The pl_stallreq and lp_stallack must be de-asserted when reset is asserted.2. A rising edge on pl_stallreq shall only occur when lp_stallack is de-asserted.3. A falling edge on pl_stallreq shall only occur when lp_stallack is asserted or

when reset is asserted.4. A rising edge on lp_stallack shall only occur when pl_stallreq is asserted.5. A falling edge on lp_stallack shall only occur when pl_stallreq is de-asserted

or when reset is asserted.

6. When lp_stallack is asserted lp_valid and lp_irdy shall both be de-asserted.1

pl_ stallreq

lp_ stallack

lp_valid

pl_trdy

Pl_lsm_sts

T1 T2 T3 T4 T5

Next State

n cycles

Active Don t Care

Data Packets are aligned

Don t Care



7. While pl_stallreq is asserted, any data presented on the interface must be accepted by the physical layer until the rising edge of lp_stallack. pl_trdy is not required to be asserted consecutively.

8. A state transition on pl_state_sts from ACTIVE to any state (except LinkError) must only occur on clocks in which pl_stallreq and lp_stallack are both asserted. See Section 3.8, LinkError State Rules on page 42 for rules related to LinkError entry.

9. The logic path between pl_stallreq and lp_stallack must contain at least one flop to prevent a combinatorial loop.

10. A complete stallreq/stallack handshake is defined as the completion of all four phases: Rising edge on pl_stallreq, rising edge on lp_stallack, falling edge on pl_stallreq, falling edge on lp_stallack.

To avoid performance penalties, it is recommended that this handshake be completed as quickly as possible while satisfying the above rules.

The following section describes the example shown in Figure 10.

In the cycle T1, pl_stallreq is asserted by the logPHY to indicate stall to the link layer. The link layer is permitted to use this signal to stop accepting any new transactions in its input pipeline. From this point onwards, the link layer must continue to drain the data in its pipeline. The link layer continues to rely on the logPHY to drain the data.

T1 and T1+n cycles, during this time the link layer must continue to assert lp_valid until all the packets in the link layer pipeline are drained. The logPHY is permitted to throttle the link layer during this period. When the link layer pipeline is drained or the link layer is ready with an aligned packet, it must de-assert lp_valid and assert lp_stallack. Link layer is permitted to de-assert lp_valid in earlier cycle than when lp_stallack is asserted.

In cycle T2, link layer asserts lp_stallack signal indicating it has drained its pipeline and has idle or aligned packets.

In cycle T3, physical layer shall de-assert pl_stallreq. lp_valid must continue to stay de-asserted when lp_stallack is asserted.

In cycle T4, lp_stallack is de-asserted. The link layer is permitted to present valid data in the same cycle or subsequent cycles.

Implementation Note

Logical PHY implementations may choose to perform stallreq/stallack handshake in RESET state to prevent upper layers from filling their pipelines. An example where this may be desired is a situation where logPHY needs to finish several rounds of speed negotiations and the changes in speed affect the framing rules from upper layers. If designs choose to perform this handshake during RESET, the mechanism must ensure that there is no race condition or deadlock for this handshake .(An example implementation would create a sequence such that pl_stallreq is asserted before pl_protocol_vld, and link layer does not prepare packets or request ACTIVE until it knows the protocol from LPIF.) Physical layer must keep pl_stallreq asserted until it is ready to transition to final ACTIVE state for link operation. It may go through several cycles of ACTIVERETRAINACTIVE arcs while pl_stallreq is asserted.

1. Implementations are permitted to have logPHY condition lp_valid on lp_irdy (treat lp_valid as enables), and in this case, upper layers are permitted to keep lp_valid asserted and only de-assert lp_irdy.



2.5 StreamID RulesThe lp_stream[7:0] and pl_stream[7:0] signals carry the encoded value that indicates the StreamID number for the protocol. This field is 8-bits wide and the definition of the streamID fields is implementation-specific.

The StreamID signals are optional on the LPIF instance on the link layer and is required to be present on all other LPIF instances (ARB/Mux and PHY). For those implementations where the link layer does not provide the StreamID signals, the corresponding StreamID signals on other instances (ARB/MUX and PHY) must be strapped with the appropriate StreamID value. For those instances, the lp_stream must be strapped to the appropriate value and pl_stream output must be left unconnected. Link layers of this type do not use StreamID and therefore the integrator must ensure that the lp_stream[7:0] is strapped to the appropriate value. The driver of the pl_stream[7:0] signal must comprehend that the link layer is transparent to the value of the forwarded StreamID and therefore must ensure that only the packets intended for the link layer are forwarded.

Link layer is permitted to provide the StreamID signals, but it is required to support StreamID signals in both directions. In this case, the streamID signals must be connected between the link layer and ARB/MUX or PHY. The allocation of the StreamID encoding must be done by the link layer, and the driver of the pl_stream[7:0] must decode the received StreamID and forward the packets to the link layer associated with the received StreamID. When connected to an ARB/MUX, this requires that the ARB/MUX is aware of the StreamID allocation and association with link layer.



Figure 11. Stream Signal Connections

2.6 LPIF Request and Status The lp_state_req values indicate the LPIF state requested by the link layer, and the signal pl_state_sts reflects the state status of the LPIF interface.

Table 9 describes the Requests considered by the physical layer in each of the LPIF interface states. The link layer must take into account the interface state status and make the necessary request modifications.

The requests are listed on the Row and the LPIF state status is listed in the Column.

The entries in Table 9 denote the following:

• Yes: Indicates that the request is considered for next state transition by the physical layer.

• N/A: Not Applicable


Link Layer (0)


Link Layer (1)

PHY

Logical PHY

PCS/AFE

Arbiter and Mux

LPIF(0) LPIF(1)

LPIF

LPIF

pl_streamlp_stream

lp_streamlp_stream Tied Off

pl_stream not connected



• Ignore: Indicates that the request is ignored and has no effect on the next state transition.

Table 9. Requests Considered in Each LPIF State by Physical LayerRequest (Row) Versus Status

(Column) on LPIF

RESET ACTIVE DAPM1 IDLE_L1.1 IDLE_L1.2 IDLE_L1.3 IDLE_L1.4 LinkReset RETRAIN DISABLE SLEEP_L2 LinkError

NOP Yes Ignore

N/A

Ignore Ignore Ignore Ignore Ignore Ignore Ignore Ignore Ignore

ACTIVE Yes2 Ignore Yes Yes Yes Yes Yes Yes Yes Yes Yes

DAPM Ignore Yes Ignore Ignore Ignore Ignore Ignore Ignore Ignore Ignore Ignore

IDLE_L1.1 Ignore Yes Ignore Ignore Ignore Ignore Ignore Ignore Ignore Ignore Ignore




LinkReset Yes2 Yes Yes Yes Yes Yes Ignore Yes Ignore Yes Ignore

RETRAIN Ignore Yes Ignore Ignore Ignore Ignore Ignore Ignore Ignore Ignore Ignore

DISABLE Yes2 Yes Yes Yes Yes Yes Yes Yes Ignore Yes Ignore

SLEEP_L2 Ignore Yes Ignore Ignore Ignore Ignore Ignore Ignore Ignore Ignore Ignore

LinkError(sideband wire)

Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes

1. Value is not reflected on pl_state_sts2. Requires request transition from NOP



3.0 LPIF State Status Machine

The following diagrams list the permissible pl_state_sts transitions. The specific exit conditions are documented in subsequent sections.

Figure 12. pl_state_sts Signal Transitions

3.1 Reset State RulesThe Reset State can be entered on de-assertion of LPIF interface reset signal or from states as described in Figure 12. In this state, the physical layer is permitted to begin its initialization process. The initialization process is physical layer-specific.

The pl_state_sts is not permitted to exit Reset state until requested by the upper layer. The exit from Reset state is requested by the upper layer by changing the lp_state_req signal from NOP encoding value to the permitted next state encoding value.

From any state (except disabled and LinkError)

Reset

L1

LinkError

From any state (except LinkError)

Disabled

From any state

LPIF Reset deassertion

L2Active LinkReset

Retrain

L1 SubstatesL1.1L1.2L1.3L1.4



Figure 13. Transitions from Reset State

The rules for Reset state transition are as follows:

1. ResetActive: The physical layer transitions to the Active state upon observing lp_state_req == Reset (NOP) for at least one clock while pl_state_sts is indicating Reset followed by observing lp_state_req == Active.

2. ResetLinkReset: The physical layer transitions to the LinkReset state upon observing lp_state_req == Reset (NOP) for at least one clock while pl_state_sts is indicating Reset followed by observing lp_state_req == LinkReset OR when directed by Internal LinkReset Request.1 The PHY is permitted to transition through Active State, and when it does, Active state exit conditions apply.

3. ResetDisabled: The physical layer transitions to the Disabled state upon observing lp_state_req == Reset (NOP) for at least one clock while pl_state_sts is indicating Reset followed by observing lp_state_req == Disabled OR when directed by Internal Disabled Request.2 The PHY is permitted to transition through Active State, and when it does, Active state exit conditions apply.

4. ResetLinkError: The physical layer transitions to LinkError based on observing an internal request to move to the LinkError or LinkError Sideband wire assertion.3

The physical layer must ensure that the upper layer PM and clock gating is removed before initiating entry into Active state.

During Initialization the logPHY performs Exit Clock Gating Req/Ack protocol to ensure that the upper layers exit clock gating before first entry into the Active State. It is mandatory to participate in this protocol handshake when initiated on LPIF, even if the upper layers have exited clock gating and for those implementations that do not support upper layer clock gating.

LinkError Sideband Wire asserted || Internal LinkError Request

Reset

LinkErrorDisabledLinkResetActive

Lp_state_req == RESET ##1 lp_state_req == ACTIVE

(Lp_state_req == RESET ##1 lp_state_req == LINKRESET) ||Internal LinkReset Request

(Lp_state_req == RESET ##1 lp_state_req == DISABLED) ||Internal Disabled Request

1. Refer to LinkReset State Rules section 3.6 to see examples of Internal LinkReset requests 2. Refer to Disabled State Rules section 3.7 to see examples of Internal Disabled requests. 3. Refer to LinkError State Rules section 3.8 to see example of internal LinkError requests.



3.2 Active State Rules The Active state to next state transitions are described below.

Figure 14. Transitions from Active State

The rules for Active State transition are as follows:

1. ActiveRetrain: The physical layer transitions to the Retrain state upon observing lp_state_req == Retrain or due to an internal request to retrain the link while pl_state_sts == Active.

2. ActiveL1.x: The physical layer transitions to L1.x based on observing lp_state_req == L1.x while in the Active state

3. ActiveL2: The physical layer transitions to L2 based on observing lp_state_req == L2 while in the Active state

Section 3.9, Common State Handling on page 43 describes the transition from Active to LinkReset, Disable, or LinkError states.

3.3 PM Entry RulesThis section lists the rules for entry into the PM state. Deepest Allowable PM State, L1.1 through L1.4 and L2 are all considered PM states, and entry into these states is denoted in these rules as PM state unless and until specified. Exceptions will be explicitly listed. PHY initiated PM Entry Sequence in the following are protocol-specific, for example, in PCIe, Electrical Idle Ordered Set (EIOS) is used.

L1.x

Lp_state_req == RETRAIN ||Internal Retrain Request

ActiveLp_state_req == L2

Lp_state_req == L1.x

L2Retrain



Figure 15. Example of Successful Entry into PM State

Figure 16. Example of Entry into PM State Rejected

1. Link layer triggers entry into the PM state using lp_state_req signal (specific PM state encoding).

2. Physical layer must initiate the Stall Req/Ack mechanism if conditions of PM entry are satisfied—for example in CXL protocol, the Upstream port logical PHY may immediately begin the StallReq/Ack mechanism as soon as it receives the PM state request (as shown in Figure 15); whereas the Downstream port must wait for an indication from the remote side as well as a state request from the local link layer (as shown in Figure 15).

3. Physical layer begins the process to enter PM state. Physical layer is not required to wait for the Stall Req/Ack protocol to complete before initiating entry into or

DP LPIF[0] Physical Layer

UPLPIF[0] Link Layer

DPLPIF[0] Link Layer

UPLPIF[0] Physical Layer

Physical Layer

This PL_STATE_STS acknowledgment serves as confirmation (eg. for PCIE LL case, this can be treated as electrical idle

seen)

This PL_STATE_STS acknowledgment serves as confirmation (eg. for PCIE LL case, this can be treated as electrical idle

seen)

LPSTATE_STS == ActiveLPSTATE_STS == Active





Physical Layer

Physical Layer does not initiate stallreq since it has not received entry indication from remote

side.



responding to requests from the remote physical layer to enter PM state. See Section 2.4, Stall Req/Ack Mechanism on page 27 for details.

4. After the completion of the Stall Req/Ack protocol, physical layer continues to de-assert TRDY until successful PM Exit, i.e. the LPIF state returns to Active and the physical layer is ready to consume data.

5. Link layer must receive and process packets normally on the LPIF RX path while the interface is in Active state (even if it is requesting PM).

6. The LPIF interface is in PM state when the pl_state_sts value indicates PM state. The pl_state_sts is independent of the underlying physical layer state (for example the LTSSM in PCIe logPHY could be in a different state).

7. The signals pl_phyinl1 and pl_phyinl2 signals indicate when the physical layer state is the corresponding L1 or L2 PM state respectively.

8. For Arb/Mux usages, the physical LSM state is permitted to enter PM state after vLSM LPIF instances on both ends of the Link have entered PM state. LogPHY on either side co-ordinate this using protocol-specific handshake (e.g., EIOS transfer in CXL).

9. When operating in a multi-protocol environment, the LPIF interface is permitted to enter PM state and report PM status via the pl_state_sts signal, while the physical layer continues to operate in non-PM state. The details of this operation are outside the scope of this specification.

3.3.1 DAPM and L1.x ResolutionThe Main Die physical layer is responsible for resolving the DAPM and L1.x requests and returning the appropriate status. The permissible values to be returned on pl_state_sts for DAPM requests are any of the L1.x substates supported by the Main Die physical layer. The permissible values to be returned on pl_state_sts for L1.x requests is the requested or lower L1.x substate.

3.4 PM Exit RulesThe following section lists the exit rules from the PM state.

Figure 17. Exit from PM State (Example is for Exit from L1 State)

PL_STATE_STS ==

Retrain

PL_STATE_STS == Active

PLSTATE_STS == Retrain

PL_STATE_STS == Active

PL_STATE_STS == PM

PL_STATE_STS == PM





Physical Layer

Link Layer must be ready to receive packets



1. Before initiating PM exit (lp_state_req == Active), the link layer must ensure that PM and clock gating is removed.

2. Upon receiving the request to exit PM, physical layer initiates the process to bring the physical layer out of PM state. The mechanism to initiate exit is protocol-specific (for example in PCIe, logPHY takes the link to Recovery state). Refer to the relevant protocol specification (PCI Express Base Specification or CXL Specification) to understand the details of "PHY Initiates Exit" and "PHY Acknowledges Exit" handshakes shown in Figure 17.

3. Upon receiving the request to exit PM from the remote physical layer, the following actions must be taken on the LPIF interface:a. The physical layer must initiate the Exit Clock gating Req/Ack protocol. b. Link layer must request its LPIF interface to transition to Active state (if not

already asserted) once it receives Exit Clock Gating request signal. c. Exit Clock Gating Ack must be asserted by the link layer either before or in the

same cycle the link layer requests its LPIF interface to transition to active state. d. After the Exit Clock Gating Ack signal is asserted, the link layer must be ready

to receive packets on its LPIF interface.e. On exit from L1 (L1.1 through L1.4) to Active state, the LPIF interface must

transition through the Retrain state as intermediate state transition. f. Next state is Reset on an exit from L2 state.

Section 3.9, Common State Handling on page 43 describes PM exit to LinkReset, Disable or LinkError states.

3.5 Retrain State RulesPhysical layer enters Retrain state when directed by link layer or due to Internal Retrain Requests

Physical layer may enter Retrain state due to Internal Retrain Requests such as when:

1. Software writes to a register in the physical layer to enter Retrain. 2. Physical layer autonomously decides to enter Retrain. 3. Remote physical layer requests entry into Retrain.

Entry into Retrain state resets power management state across the interface and power management entry if required must be re-initiated after the interface enters Active state.

Physical layer initiates the Stall Ack/Req protocol, see Section 2.4, Stall Req/Ack Mechanism on page 27 for details

The rules for Retrain state transition are as follows:

1. RetrainActive: The physical layer transitions to the Active state upon observing lp_state_req == Active while the pl_state_sts == Retrain.

2. Transitionary state: The physical layer may transition to the Active state upon observing lp_state_req == LinkReset or Disabled while the pl_state_sts == Retrain. Following the entry into Active the PHY is permitted to make a transition to the requested state.

Section 3.9, Common State Handling on page 43 describes PM exit to LinkReset, Disable, or LinkError states.



Figure 18. Transition from Retrain State

3.6 LinkReset State RulesPhysical layer enters LinkReset state when directed by link layer or due to Internal LinkReset Requests

Physical layer may enter LinkReset state due to Internal LinkReset requests such as when

1. Software writes to a register in the physical layer to enter LinkReset. 2. Remote physical layer requests entry into LinkReset.

The rules for LinkReset State transitions are as follows:

1. LinkResetReset: The physical layer transitions to the Reset state due to an internal request to move to Reset (example reset pin assertion) or lp_state_req == Active OR Disabled while pl_state_sts == LinkReset.

2. LinkResetDisabled The physical layer transitions to Disabled based on observing lp_state_req == Disabled or due to an internal request to move to Disabled while pl_state_sts == LinkReset. See Section 3.7, Disabled State Rules on page 41 for examples of internal request to move to Disabled.

3. Transitionary State: The PHY is permitted to transition through Reset State, and when it does, Reset state exit conditions apply.

4. LinkResetLinkError: The physical layer transitions to LinkError due to an internal request to move to LinkError or LinkError Sideband wire assertion while pl_state_sts == LinkReset. See Section 3.8, LinkError State Rules on page 42 for examples of internal request to move to LinkError.

Retrain

lp_state_req == ACTIVE || lp_state_req == LINKRESET || lp_state_req == DISABLED

ACTIVE



Figure 19. Transitions from LinkReset State

3.7 Disabled State RulesPhysical layer enters Disabled state when directed by link layer or due to Internal Disable Requests

Physical layer may enter Disable state due to Internal Disable requests such as when

1. Software writes to a register in the physical layer to enter Disabled. 2. Remote physical layer requests entry into Disabled.

The rules for Disabled State are as follows:

1. DisabledReset: The physical layer transitions to the Reset state due to an internal request to move to Reset or lp_state_req == Active while pl_state_sts == Disabled.

2. DisabledLinkError: The physical layer transitions to LinkError due to an internal request to move to LinkError or LinkError Sideband wire assertion while pl_state_sts == Disabled. See Section 3.8, LinkError State Rules on page 42 for examples of internal request to move to LinkError.

Disabled

lp_state_req == ACTIVE ||lp_state_req == DISABLED ||

Internal Reset RequestLinkReset LinkError Sideband wire asserted ||

Internal Link Error Request

lp_state_req == DISABLED || Internal Disabled Request

LinkErrorReset



Figure 20. Transitions from Disabled State

3.8 LinkError State RulesPhysical layer enters LinkError state when directed via Linkerror signal or due to Internal LinkError Requests. It is not required to complete the stallreq/ack handshake before entering this state. However, for implementations where LinkError state is not a terminal state (terminal implies SoC needs to go through reset flow after reaching LinkError state. If LinkError is not terminal, it is expected that software can come and retrain the link after clearing error status registers, etc.), the following rules should be followed:

1. If the logPHY decides to perform a pl_stallreq/lp_stallack handshake, it must make sure to provide pl_trdy to the link layer to drain the packets. In cases where there is an uncorrectable internal error in the logPHY these packets could be dropped and not transmitted on the link.

2. If pl_stallreq is asserted when pl_state_sts is LinkError, pl_trdy should be asserted to drain the link layer—LogPHY should internally drop these packets and not forward it to the link.

3. It is required for link layer to internally clean up the data path even if pl_trdy is not asserted and it has sampled LinkError on pl_state_sts for at least one clock cycle.

Physical layer may enter LinkError state due to Internal LinkError requests such as when

1. Encountering physical layer errors due to hardware failure that cannot be corrected by Retraining.

2. Remote physical layer requests entry into LinkError. This rule is only applicable for physical layers that support this specific handshake (e.g., R-Link). It is not applicable for cases like PCIe, where there is no such indication.

Implementations are permitted to consider this the terminal stage for hardware errors that cannot be corrected by training.

lp_state_req == ACTIVE ||Internal Reset Request

Disabled LinkError Sideband wire asserted ||Internal Link Error Request

LinkErrorReset



Implementations are also permitted to implement a minimum residency timer for LinkError state, and the LSM is permitted to move from LinkError state to Reset state on expiration of the minimum residency timer as per the following exit conditions.

The rules for LinkError state are as follows:

LinkErrorReset: The physical layer transitions to Reset due to an internal request to move to Reset (example: reset pin assertion) or lp_state_req == Active while pl_state_sts == LinkError

Figure 21. Transition from LinkError State

3.9 Common State HandlingThis section covers some of the common conditions for exit from Active, Retrain, L1, and L2 to LinkReset, Disable and LinkError states.

The rules are as follows:

1. [Active, Retrain, L1, L2]LinkReset: The physical layer transitions to LinkReset based on observing lp_state_req ==LinkReset or due to an internal request to move to LinkReset while pl_state_sts == Active, Retrain, L1.x, or L2. See Section 3.6, LinkReset State Rules on page 40 for examples of internal requests that can trigger transition to LinkReset.

2. [Active, Retrain, L1, L2]Disabled: The physical layer transitions to Disabled based on observing lp_state_req ==Disabled or due to an internal request to move to Disabled while pl_state_sts == Active, Retrain, L1.x, or L2. See Section 3.7, Disabled State Rules on page 41 for examples of internal requests that can trigger transition to Disabled.

LinkError

lp_state_req == ACTIVE || Internal Reset Request

Reset



3. [Active, Retrain, L1, L2]LinkError: The physical layer transitions to LinkError based on observing an internal request to move to the LinkError or LinkError Sideband wire assertion while state pl_state_sts == Active, Retrain, L1.x, or L2. See Section 3.8, LinkError State Rules on page 42 for examples of internal requests that can trigger transition to LinkError.

Figure 22. Common State Handling

Disabled

lp_state_req == LinkReset ||Internal LinkReset Request

Active, Retrain, L1, L2

LinkError Sideband wire asserted ||Internal LinkError Request

lp_state_req == DISABLED || Internal Disabled Request

LinkErrorLinkReset



4.0 Precise Time Measurement (PTM) Support

LPIF supports the signaling interface required to support Precise Time Measurement (PTM). Protocols that support PTM embed a PTM packet on the LPIF data interfaces. PTM protocol requires that it be notified of the latency the packet incurs as it transitions through the physical layer.

To support this requirement, a simple handshake mechanism is defined on LPIF. The Upper layer protocol asserts the lp_tmstmp signal to indicate the presence of a PTM packet on data lanes. The physical layer is required to sample the lp_tmstmp along with data through its internal data path as close to the physical wires as permitted by implementation. When the data is transferred by the physical layer, the lp_tmstmp signal is turned around and returned to the upper layer protocol as pl_tmstmp signal accompanied by a pl_tmstmp_streamID signal to indicate the streamID associated with the pl_tmstmp signal.

Implementations are required to guarantee a fixed latency for the pl_tmstmp signal from the turn-around point within the implementation.

The pl_tmstmp signal is an orthogonal signal and not associated with the data that might be presented by the physical layer to the upper layers in that clock cycle.

The pl_tmstmp signal will be asserted for exactly the same number of cycles the lp_tmstmp signal was sampled asserted and captured by the physical layer.

The pl_tmstmp_streamID signal is of particular use by the ARB/MUX or an upper layer that supports multiple protocol to associate the pl_tmstmp signal with the protocol entity that initiated the lp_tmstmp signal.



5.0 LPIF Bandwidth Scaling

The Bandwidth on LPIF can be scaled up or down by changing the number of Data lanes that are active and/or by scaling the clock frequency. LPIF is agnostic to the static or dynamic mode of bandwidth scaling; however, it is required that bandwidth changes do not occur during the clock cycle where the data is transferred across LPIF instance.



6.0 Configuration Interface

LPIF provides a configuration interface to facilitate sideband transfer of information between the link layer and logPHY. As an example, link layer can use this interface to read registers in the logPHY. This is an optional interface; other mechanisms can be used instead. This interface currently only supports requests from link layer to logPHY and completions from logPHY to link layer. It does not support requests from logPHY to link layer.

The interface supports 2 classes of transactions—requests and completions. Table 10 shows the different fields for a request. Table 12 shows the different fields of a completion. A fixed number of outstanding requests will be supported through a compile time parameter. All requests are non-posted, meaning that a completion is returned for every request.

Both requests and completions carry a header and either no payload, 1 D-word (32 bits) of payload, or 1 Quad word (64 bits) of payload. For requests, the opcode indicates the size of the payload. For successful completions, the requestor knows how much payload to expect based on the request it sent. This is also indicated in the completion header. Requestors are optionally allowed to check for mismatches in the length indicated by the completion header versus the expected length for the request. For unsuccessful completions also, same length of data is carried as the requesting opcode, but it is all 0. All fields other than the DATA field are considered part of the header.

At the interface, these transactions are packetized into multiple phases depending on the configuration interface width (compile time parameter). Supported interface widths are 8, 16 or 32 bits. lp_cfg_vld and pl_cfg_vld are asserted independently for each phase. They must be asserted on consecutive clock cycles for transferring consecutive phases of the same packet. They may or may not assert on consecutive clock cycles when transferring phases of different packets. Figure 23 shows the packet format for Requests and Completions for a 32-bit interface. Packet formats for 16- and 8- bit interfaces can be found in the Appendix Figure 55 and Figure 56.

The receiver of requests (logPHY in this case) may optionally implement checks for address and BE alignment or consistency with the opcode of the request. In this case, it must respond with Completer Abort status when address and/or BE are not consistent with the opcode.



Table 10. Field Descriptions for a RequestField Description

Opcode[3:0]

Following opcode encodings are supported:4'b0000 - MDRD: 32-bit (DW) Mem Read4'b0001 - MDWR: 32-bit (DW) Mem Write4'b0010 - IORD: 32-bit IO Read4'b0011 - IOWR: 32-bit IO Write4'b0100 - CFGDRD: 32-bit CFG Read4'b0101 - CFGDWR: 32-bit CFG Write4'b0110 - CRDRD: 32-bit Private CFG Read4'b0111 - CRDWR: 32-bit Private CFG Write4'b1000 - MQRD: 64-bit (QW) Mem Read4'b1001 - MQWR: 64-bit (QW) Mem Write4'b1100 - CFGQRD: 64-bit CFG Read4'b1101 - CFGQWR: 64-bit CFG Write4'b1110 - CRQRD: 64-bit Private CFG Read4'b1111 - CRQWR: 64-bit Private CFG Write64-bit opcode support is optional, but strongly recommended. Both link layer and logPHY must ensure interoperability when used together.

CPControl Parity. All fields other than "DP" and "CP" in the Header are protected by Control Parity, and the parity scheme is even (including reserved bits)

DP Data Parity. All fields in data are protected by data parity, and the parity scheme is even.

Addr[26:0]

Address of the request. Different opcodes use this field differently. See Table 11 for details.The following rules apply for the address field: For 64-bit request, Addr[2:0] is reserved.For 32-bit request, Addr[1:0] is reserved.

BE[7:0] Byte Enables for the Request. It is NOT required to be contiguous. BE[7:4] are reserved if the opcode is for a 32-bit request.

EPData Poison. If poison forwarding is enabled, the completer can poison the data on internal errors.

Tag[9:0] Tag for outstanding request

Data Payload. Can be 32 bits or 64 bits wide depending on the Opcode.

Table 11. Mapping of Address Field for Different RequestsOpcode Description

MDRD/MDWR/ MQRD/MQWR {Bar[2:0], Offset[23:0]}, where Bar is the Mem BAR ID—unique across all BARs in logPHY, and Offset is the Byte Offset

IORD/IOWR{Bar[2:0], Rsvd.[7:0], Offset[15:0]}, where Bar is the IO BAR ID—unique across all BARs in logPHY, Offset is the Byte Offset, Rsvd implies the bits are reserved.

CFGRD/CFGWRCFGQRD/CFGQWR

{Bus[2:0], Dev[4:0], Func[2:0], Rsvd[3:0], Byte Offset[11:0]}, where Bus[2:0] is the Bus IDDev is the Device IDFunc is the Function

CRRD/CRWRCRQRD/CRQWR

{Rsvd[2:0], PortID[7:0], Offset[15:0]}, where PortID is a unique ID mapping to private address space of logPHY



Table 12. Field Descriptions for a CompletionField Description

Tag[9:0] Completion Tag associated with the corresponding Request

CPControl Parity. All fields other than "DP" and "CP" in the Header are protected by Control Parity, and the parity scheme is even (including reserved bits)

DP Data Parity. All fields in data are protected by data parity, and the parity scheme is even.

LEN[1:0]

Length of completion in D-Words. It follows the encoding:2'b00 : 0 dword2'b01 : 1 dword2'b10 : 2 dword2'b11 : reserved

Status[2:0]

Completion Status3'b000 - Successful Completion (SC)3'b001 - Unsupported Request (UR)3'b010 - Configuration Request Retry Status (CRS)3'b100 - Completer Abort (CA)

Other encodings are reserved.

Data Payload. Can be 32 bits or 64 bits wide depending on the Opcode.



Figure 23. Packet Format for a 32-bit Interface



Figure 24. Example Waveform for Transactions on Configuration Interface

lp_cfg

clk

pl_cfg

pl_cfg_vld

lp_cfg_vld

lp_cfg

clk

pl_cfg

pl_cfg_vld

lp_cfg_vld

lp_cfg

clk

pl_cfg

pl_cfg_vld

lp_cfg_vld



7.0 Support for Pipelining

Floorplan challenges and/or timing convergence requirements when integrating PHY/link layer IPs might require the insertion of staging buffers as shown in Figure 25. This section describes the implementation considerations for the logPHY when such staging is necessary.

Figure 25. Block Diagram for Pipelined Implementation

The LPIF observability point is defined at the link layer boundary. This makes the link layer agnostic about the pipeline stages, and any changes required to support this are contained within the logPHY. This is also the boundary where pre-Si validation collateral should use the signals for bus function modeling (BFM) or checker purposes. As shown in Figure 25, the signal convention followed in this section considers the link layer interface to be the LPIF signals (lp_*, pl_*) and they are delayed by "n" clocks in each direction with respect to the logPHY interface (lp_*', pl_*').

7.1 LogPHY Implementation ConsiderationsThe number of pipeline stages must be known to logPHY either as a Parameter or a configuration register. The only consequence of adding the staging buffers with respect to logPHY implementation is a change to the generation of pl_trdy' and the sampling of lp_data'. The rules for driving/sampling the remaining signals remain the same as before.

LogPHY must internally stage pl_trdy' by "n" cycles and use the staged value for sampling lp_data' (recall that lp_data is sampled when lp_irdy, lp_valid and pl_trdy are high). Moreover, because the link layer observes a pl_trdy transition that is "n" cycles delayed from pl_trdy' transition, logPHY must account for that when generating the pl_trdy' indication. Thus, logPHY must de-assert pl_trdy' 2*n cycles before it wants to use the link. For example, in the case of PCIE logPHY, one of the reasons for de-assertion of pl_trdy' is when the physical layer is inserting skip ordered sets. In this

LogPHY

Pipestages_n

Link Layer

LPIF Observability Point

lp_* pl_*

pl_*_n

lp_*_n

lp_*’ pl_*’



case, the logPHY must take "n" into account for calculating when to de-assert pl_trdy' and make sure it happens 2*n cycles earlier than it would have otherwise. Figure 27 demonstrates this behavior for n=1.

Note: Even though there is no implementation impact to the other signals of LPIF, it is important to see that the staging buffer decides the minimum round-trip latency for handshakes between the logPHY and the link layer. Figure 26 shows the stallreq/stallack handshake with a staging delay of "n" cycles, and the link layer taking X cycles to return stallack after observing stallreq. As can be seen in Figure 26, we have added 4*n cycles of latency to the stallreq-stallack handshake.

Figure 26. Stallreq StallAck Protocol, Pipelined Implementation

lp_stallack(Link Driver)

lp_valid(Link Driver)

Pl_lsm_sts’

T1 T2 X cycles T3

Next State

n cycles

Active Don’t Care

Data Packets are aligned

Don’t Care

n cycles T4 T5

pl_stallreq(Link receiver)

n cycles

Don’t Care

T6 n cyclesT7

pl_trdy(Link Receiver) Data Packets are aligned

T8

pl_trdy’(PHY Driver)

lp_valid’(PHY Receiver)

pl_stallreq’(PHY driver)

lp_stallack’(PHY Receiver)

Log

ical PH

Y In

terface (LPIF)

Sp

ecification

Rev 1.1©

Intel Corporation

54N

ovember 14, 2020

Figure 27. Example of pipelined data transfer



8.0 Support for PCIe

This section describes the signals and concepts for supporting PCIe protocol between a link layer and logPHY. All waveforms and flow diagrams outlined in this section are examples, and should be considered as such. They are not meant to enumerate all possible corner cases. Implementation should make sure to honor the rules outlined in the specification.

8.1 Encoding for 2.5 GT/s and 5.0 GT/s Data RatesThe legacy modes of PCI Express (2.5 GT/s and 5GT/s) differ in the encoding used to transmit data over the link compared to higher data rates. They use an 8b/10b encoding, and define special 10b symbols used for framing and link management. Because framing is performed in the link layer, and symbol encoding is performed in the logPHY, this specification defines the lp_kchar signal. 1 bit is needed for this signal per byte of data transfer between the link layer and logPHY. This signal is an indication to the logPHY that dictates whether the logPHY treats the data byte as data or a special symbol, and uses that information to look up the appropriate 10b encoding. Refer to the PCI Express Base Specification for details on 8b/10b encoding scheme and symbol encodings.

8.2 L0s SupportThis specification does not support L0s at this time, but we have added pl_in_rxl0s and an Active substate encoding for Tx L0s in anticipation of this support.

Open Issue: Support for L0s will come in at a later version

8.3 Implementation Notes for Certain LPIF SignalsThis section describes behavior/interpretation of certain LPIF signals that can assist implementation for PCIe-specific usages.

• pl_error—When pl_error is asserted from the logPHY, there is no expectation to block the data path or take the link to Retrain instantly—the behavior is implementation-specific based on division of logic between link layer and logPHY. In general, pl_error is used to indicate errors that are correctable through Retrain. Depending on the error, Retrain may be triggered by logical PHY or the link layer.

• pl_trainerror—In addition to any relevant training errors (if applicable), pl_trainerror is used to indicate uncorrectable error to the upper layers (such as parity errors internal to the logical PHY). logPHY transitions to LinkError state and wake up the upper layers via pl_exit_cg_req/lp_exit_cg_ack handshake. This is a level signal that is cleared when transitioning out of LinkError state or with software intervention.

• pl_phyinl2—In order to assist in resetprep flows, logPHY in PCIe mode drives pl_phyinl2 when the IOs are in low power state (e.g., in case of PIPE, when the IOs are in P2). Link layer can use a combination of pl_state_sts and pl_phyinl2 to determine accurate state of the IOs.



8.4 Data Path ExamplesThis section gives a few waveform examples on how the data path is structured between the PCIe link layer and the logPHY. LPIF allows for several possible implementations for different link configurations and operating frequencies of the link layer versus the logPHY. However, it is extremely important that the implementations of the link layer and logPHY are consistent between each other to make sure there is no performance impact because of data path steering.

In all figures below, Byte[0] on lp_data corresponds to Byte[0] of the upper layer packet or FLIT being transferred on the interface. Also, the waveforms in this section assume pl_trdy is always asserted (not shown) for succinct representation.

Figure 28 shows 32B of data transfer between the link layer and the logPHY (the LPIF interface signals are grouped with D-Word (4B) granularity), under the following parameters:

• Link is configured and trained to a x4 width.• Data width is 4B per lane, and LPIF is grouped in D-Word (4B) granularity [n = 16,

numbytes_pervalid = 4]• The interface to analog front-end (e.g., PIPE interface) is also at 4B granularity per

lane and so can keep up with the LPIF bandwidth [no bandwidth mismatch between link layer and PIPE]

Figure 28. Tx Data Path, Example 1

Figure 29 shows another example with the same parameters as above, but the Transaction Layer Packet (TLP) boundary ends on Byte 27 of the payload and the link layer has nothing to send after that. In this case, the logPHY is expected to insert the IDLE symbols following the end of the TLP until the next TLP is made available by the link layer.




Figure 30 shows another example with the following parameters:


numbytes_pervalid = 4]• The interface to analog front-end (e.g., PIPE interface) is also at 4B granularity per

lane and so can keep up with the LPIF bandwidth [no bandwidth mismatch between link layer and serial pins]


Figure 31 shows another example with the following parameters:


numbytes_pervalid = 4]• The interface to analog front-end (e.g., PIPE interface) might or might not be

bandwidth matched to the LPIF interface.



a. If the serial pin bandwidth is matched to the LPIF interface bandwidth, then the logPHY is expected to insert IDLEs for clocks 3 and 4.

b. If the serial pin bandwidth is less than the LPIF interface bandwidth (running in degraded mode for example), then the logPHY may not need to insert IDLEs in clocks 3 and 4. Implementations are expected to be consistent between the link layer and the logPHY in order to avoid inserting unnecessary IDLE symbols or IDLE symbols in the middle of a TLP.


Note: The data width and granularity chosen by link layer and logPHY is implementation-specific. The examples above illustrate one theme of using 4B per lane granularity. Moreover, if the negotiated link width is different than the native link width (a x4 link trained in degraded mode to a x2 width), the adjustment of data width to the negotiated link width instead of the full width as well as any data throttling mechanisms from the link layer is optional and implementation-specific (as long as both the link layer and logPHY are consistent with each other).

On the Receive path, the rest of the data block is forwarded to the LinkLayer without any modification. There is only 1 valid per port, and there are two implementation choices (link layer and logPHY must have consistent implementation). First choice, the logPHY always accumulates data up to the link configured width (regardless of trained width), before forwarding the data to the upper layers. See Figure 32 and Figure 33.

Second choice, the logPHY can change the data width based on the trained width. Link layer must look at pl_lnk_cfg and use that information to determine how many bytes per lane per clock are transferred.

Figure 32. Rx Data Path, Example 1



Figure 33. Rx Data Path, Example 2

8.4.1 Framing-Related SignalsBecause PCIe de-framing is done in the logPHY, LPIF defines signals to indicate the start/end of DLLP, TLP, and EDB placement relative to the data bytes on the interface. Just as the number of PCIe lanes per port, and the associated data-width (bytes or symbols per clock per port) are implementation-specific based on supported configurations, the width of pl_dlpstart, pl_dlpend, pl_tlpstart, pl_tlpend, pl_tlpedb are also implementation-specific and subject to similar expectations when bifurcating the interface. Both the link layer and logPHY must have a common understanding about the association of framing signals with data bytes based on the data-width, bifurcation (pl_portmode) and link trained width settings (pl_lnk_cfg). These signals are only relevant when pl_valid for the corresponding data bytes is asserted. It is required for link layer to check for the specific four byte pattern of EDS token and drop it1. Given below are the rules that govern the width and mapping of framing signals with data bytes, and the subsequent figure lays out example configurations.

1. If the number of lanes associated with a port is 1, the start and end can be on any of the data bytes, the number of signals required for that port is the number of bytes transferred in 1 clock cycle

2. If the number of lanes associated with a port is 2, the start and end can be on any of the symbol times, the number of signals required for that port is the number of bytes transferred in 1 clock cycle

3. If the number of lanes associated with a port is >=42, the start and end are aligned to d-word placement (see the Implementation Example below), and the number of signals required for that port is (symbols_per_clock * lanes_per_port) / 4.

4. When multiple ports of same configurations are supported on the same interface, the total number of bits for each of the framing related signals is the maximum of the above 3 rules multiplied with the total number of ports. With link subdivision, the strong recommendation is that this bus is also shared like data bytes, and equally divided between the ports.

Implementation Example

The implementation example and the associated figures assume logPHY is changing the data width for pl_data according to the trained width of the link. If the logPHY

1. When the number of lanes associated with a port is 1, logPHY may not have enough time to decode EDS token. For other cases, it is permitted for logPHY to detect and drop EDS token.

2. PCIe does not support x3



accumulates data for degraded modes before transmitting on LPIF, then the association would be based on the configured link width (based on pl_portmode).

For 4 symbols per clock, 4 lanes per port, 4 ports (64B data interface), Figure 34 shows the mapping for different configurations/training widths.

1. When trained to x1, there is a 1:1 mapping between the framing signals and data bytes, e.g., bit 0 of pl_tlpstart maps to byte 0 of data, bit 1 maps to byte 1, etc.

2. When trained to x2, the start signals map to even bytes, the end signals map to odd bytes, EDB maps to odd bytes.

3. When trained to x4 or higher, the start signals are dword aligned—bit 0 maps to byte 0, bit 1 maps to byte 4, etc. Correspondingly, the end signals start mapping to 3 bytes ahead of the start signals—bit 0 maps to byte 3, bit 1 maps to byte 7 and so on. EDB follows the same semantics as the end signals.

Figure 34. Mappings for Different Configuration and Training

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

tlp_start 0 4 8 12 16 20 24 28 32 36 40 44 48 52 56 60

tlp_end 3 7 11 15 19 23 27 31 35 39 43 47 51 55 59 63

tlp_edb 3 7 11 15 19 23 27 31 35 39 43 47 51 55 59 63

dllp_start 0 4 8 12 16 20 24 28 32 36 40 44 48 52 56 60

dllp_end 3 7 11 15 19 23 27 31 35 39 43 47 51 55 59 63

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

tlp_start 0 4 8 12

tlp_end 3 7 11 15

tlp_edb 3 7 11 15

dllp_start 0 4 8 12

dllp_end 3 7 11 15

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

tlp_start 0 2 4 6

tlp_end 1 3 5 7

tlp_edb 1 3 5 7

dllp_start 0 2 4 6

dllp_end 1 3 5 7

Asso

ciated Data

Byte

4 Port / x16, link subdivision=x16, trained x16

Asso

ciated Data

Byte

4 Port / x16, bif=x16, trained x4

Asso

ciated Data

Byte


0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

tlp_start 0 1 2 3

tlp_end 0 1 2 3

tlp_edb 0 1 2 3

dllp_start 0 1 2 3

dllp_end 0 1 2 3

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

tlp_start 0 2 4 6 32 36 40 44 48 52 56 60

tlp_end 1 3 5 7 35 39 43 47 51 55 59 63

tlp_edb 1 3 5 7 35 39 43 47 51 55 59 63

dllp_start 0 2 4 6 32 36 40 44 48 52 56 60

dllp_end 1 3 5 7 35 39 43 47 51 55 59 63

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

tlp_start 0 1 2 3 16 18 20 22 32 36 40 44 48 52 56 60

tlp_end 0 1 2 3 17 19 21 23 35 39 43 47 51 55 59 63

tlp_edb 0 1 2 3 17 19 21 23 35 39 43 47 51 55 59 63

dllp_start 0 1 2 3 16 18 20 22 32 36 40 44 48 52 56 60

dllp_end 0 1 2 3 17 19 21 23 35 39 43 47 51 55 59 63

Asso

ciated Data

Byte


Asso

ciated Data

Byte

4 Port / x16, link subdivision=x8x8, trained x2/x8

Asso

ciated Data

Byte

4 Port / x16, link subdivision=x4x4x4x4, trained x1/x2/x4/x4



Figure 35 shows an example of 8 port design—the set of bits used by a port is a function of pl_portmode, but depending on the trained link width, certain bits become not applicable (as shown for the case of a x4 link trained to x2).

Figure 35. Mapping for 8-Port Configuration

8.5 LTSSM to LPIF State MappingsTable 13 indicates how the LTSSM states map to LPIF states.

Table 13. LTSSM State Mapping to LPIF States

PCIE State LPIF State Status Mechanism to Handle PCIe state

Detect Reset Link layer would use NOP to Active transition to move the logPHY out of Detect if the link is already out of reset.

Polling Reset Link layer would use NOP to Active transition to move the logPHY out of Detect if the link is already out of reset.

Configuration Reset/RetrainReset if Configuration was entered from Polling.Retrain if Configuration was entered from Recovery.

Recovery Retrain

L0 Active

RxL0s pl_in_rxl0s wire

TxL0s Active.L0s TxL0s is a substate of Active.

L1 L1 L1.0 (PCIe) LPIF L1.1 1

1. Support for PCIe L1 substates will be added in a later revision of LPIF.

L2 L2

Disabled Disabled

Loopback Master Reset/Retrain

Depending on usage model, the LPIF state may remain in Reset with pl_lnk_up = 0. Implementations are permitted to keep the LPIF state as Retrain (if Loopback is entered from Recovery) with pl_lnk_up = 1.

Loopback Slave Reset/Retrain

Depending on usage model, the LPIF state may remain in Reset with pl_lnk_up = 0. Implementations are permitted to keep the LPIF state as Retrain (if Loopback is entered from Recovery) with pl_lnk_up = 1.

Hot Reset LinkReset

n/a LinkError



Loopback State Handling:

To enable compliance with PCI Express Base Specification, the LTSSM Loopback states are not exposed to link layer.

A typical usage is a Host to Device link put in Loopback. The Host Downstream port is permitted to keep LPIF state in Reset when LTSSM is in Loopback. The Device Upstream port is permitted to keep the LPIF state in Retrain (when LTSSM transitions from Recovery to Loopback), with pl_lnk_up = 1 to prevent the device from triggering reset on a link down event. If Loopback was entered from the LTSSM state of Configuration, the LPIF state is kept the same as when LTSSM was in Configuration (Retrain or Reset). It is expected that device does not trigger self-reset on a link down condition until DLLP exchanges are successful for credit initialization.

Alternative debug/test related loopback is permitted to be enabled if implementations support it. For example, it is possible to have packets generated from the upper layers and a debug mode in logPHY to do a loopback while LTSSM is in L0. This usage however would map to Active state on LPIF.

8.6 LinkError StateIf logPHY changes LPIF state to LinkError without initiation by upper layers, it could be due to a few different scenarios:

• If pl_surprise_lnk_down and pl_trainerror are 0, then this indicates non-fatal LTSSM timeouts or a transitionary state.

• If pl_surprise_lnk_down is 0 and pl_trainerror is 1, this indicates an uncorrectable error in the logical PHY (for example, an internal parity error). The upper layer responsible for updating advanced error reporting registers (AER) should log an uncorrectable internal error in the AER register, and trigger an interrupt if required.

• If pl_surprise_lnk_down is 1, it indicates a surprise link down, logical PHY transitions to Reset.



8.7 Flow Diagram Examples

8.7.1 Initial Bringup to L0 (PCIe)

Figure 36. Initial Link Bringup for PCIe

Link Layer Flexbus LogPHY Link LayerFlexbus LogPHY

LTSSM enters Detect

pl_protocol = discovered protocol

pl_trdy resumes regular Active Throttling

pl_state_status=ACTIVE

Begin 128/130 Training – Train to highest Data Rate supported

LTSSM Enters Recovery.Idle

LTSSM Enters L0

Idle Handshake between LogPHY (8 IDLE received and 16 sent)

LTSSM ready to enter Recovery.IDLE – logPHY must wait for lp_cg_ack before going to Recovery.IDLE

Begin Training Sequence. Go all the way to Gen1 L0logPHY now knows CXL vs PCIe

lp_statereq = NOP/Active pl_state_status = Reset

trdy=0

pl_protocol_valid = 1

pl_exit_cg_req = 1

lp_exit_cg_ack = 1

lp_statereq=ACTIVE

Based on what is connected – if the logPHY decides that we are ok in Gen1/2, it will skip 128/130 and go ahead without 128/130.

DLLP Communication Begins

pl_lnk_up = 1


pl_exit_cg_req =1

lp_exit_cg_ack = 1

pl_lnk_up = 1

lp_statereq=ACTIVE


LTSSM Enters L0


DLLP Communication Begins

LTSSM enters L0 (cannot get to L0 without

exit_cg_ack)

pl_block_dl_init=1

pl_block_dl_init=0

Start Framing in LL

Start Framing in LL

pl_block_dl_init=0

pl_block_dl_init=1

pl_exit_cg_req = 0

lp_exit_cg_ack = 0

pl_exit_cg_req =0

lp_exit_cg_ack = 0





Figure 37 gives an example of interface signal transitions when the flow in Figure 36 is executed.

Note: The figure is just an example. Implementations must follow all the rules of signal transitions listed in the previous sections.

Figure 37. Example Waveform of Signal Transitions

The comments for the arrows in Figure 37 are as follows:

• R1: pl_state_sts only changes to Active after transition to L0 and state_req is Active (state_req can transition to Active at any time). If logPHY knows that it is going to train to higher Gen speeds, it is permitted to not reflect Active when LTSSM is in L0 (since it is only a transitionary L0 state).

• R2: Configuration.Complete is gated on receiving lp_exit_cg_ack, hence entry to L0 will not happen until lp_exit_cg_ack is received. The lp_exit_cg_ack must assert within 1ms of pl_exit_cg_req assertion. Based on implementation choice logPHY may choose to not perform this handshake if it knows that it is going to try and train to higher speeds, and directly do the handshake in Recovery.RcvrCfg (R3) for the highest supported speed (in this case, the logPHY may relax the 1ms timeout to a larger value, as long as there is no risk of LTSSM timeouts).

• R3: Exit from Recovery.RcvrCfg is gated on receiving lp_exit_cg_ack. LogPHY will not enter Recovery.IDLE before receiving it.

• R4: LL must be ready to receive packets when it gives lp_exit_cg_ack. • R5: Entry into Recovery is gated by lp_stallack assertion. This rule relies on

pl_stallreq assertion before pl_protocol_vld, and link layer waiting for pl_protocol_vld before preparing packets/requesting Active.

The lp_exit_cg_ack must assert within 1ms of pl_exit_cg_req assertion—in order to avoid LTSSM timeouts. If the logPHY chooses to not perform the handshake during the "Configuration" LTSSM state, it can extend this timeout to larger values. It is recommended to set this to be no more than 50% of the timeout value of the corresponding LTSSM state. It is strongly recommended for the logPHY for Flexbus usages to implement timeout logic that escalates to a fatal error. If a timeout happened for lp_exit_cg_ack, the logPHY follows LTSSM rules for timeout in the corresponding LTSSM state, and if it ends up back in Detect, it is strongly recommended to have a de-feature bit to park in Detect and wait for software intervention before initiating training again. Because the upper layers may wait for pl_protocol_vld before responding to pl_exit_cg_req, logPHY must make sure it does not assert pl_exit_cg_req too soon before pl_protocol_vld. The relative times between pl_exit_cg_req, pl_protocol_vld, lp_exit_cg_ack must be implemented to prevent LTSSM timeouts.



Figure 38 gives an enlarged view of LTSSM substate transitions during protocol discovery.

Figure 38. Example Waveform Showing LTSSM Substate Transitions

The rules for Figure 38 are as follows:

• R1: Entry into Config.Idle is gated by receiving lp_exit_cg_ack (if the logPHY chooses to do exit_cg_req/ack handshake in Configuration state)

• R2: Upper layers may not respond to pl_exit_cg_req until pl_protocol_vld is asserted

• R3: Upper layers may not respond to pl_stallreq until pl_protocol_vld is asserted

• R4: Entry into Recovery is gated by lp_stallack assertion

LTSSM State

lclk

pl_protocol_vld

pl_protocol

start_training

pl_exit_cg_req

pl_stallreq

lp_exit_cg_ack

lp_stallack

LTSSM State

lclk

pl_protocol_vld

pl_protocol

start_training

pl_exit_cg_req

pl_stallreq

lp_exit_cg_ack

lp_stallack



8.7.2 Recovery Flow Example

Figure 39. Recovery Flow Example


lp_statereq=RETRAIN

LTSSM enters Recovery.RcvrLock

pl_stallreq=1

lp_stallack=1

pl_trdy=0

pl_stallreq=1

lp_stallack=1

pl_trdy=0

pl_state_status=RETRAIN

pl_state_status=RETRAIN


Recovery flow as usual driven from logPHYlp_statereq=ACTIVE

Cg req/ack handshake can be initiated at a convenient time from logPHY –Recovery.Cfg

pl_exit_cg_req=1

lp_exit_cg_ack=1


LTSSM Enters L0

Idle Handshake between LogPHY (eg. 8 IDLE received and 16 sent)

LTSSM ready to enter Recovery.IDLE – logPHY must wait for lp_cg_ack

before going to Recovery.IDLE

pl_trdy resumes Active throttling

pl_state_status=ACTIVEpl_phyinrecenter=0

Communication Begins

LL can ask for ACTIVE ANYTIME.

lp_statereq=ACTIVE

pl_exit_cg_req=1

lp_exit_cg_ack=1

LTSSM Enters L0



Communication BeginsIf lp_state_req is RETRAIN

when logPHY reaches L0, then pl_state_status will move to ACTIVE and then go back to RETRAIN using the same flow from the beginning [LTSSM moves to Recovery and starts

sending TS1]

Pl_stallreq=0

lp_stallack=0

pl_stallreq=0

lp_stallack=0

pl_exit_cg_req=0

lp_exit_cg_ack=0

pl_exit_cg_req=0

lp_exit_cg_ack=0


pl_phyinrecenter=1

pl_phyinrecenter=1



8.7.3 Entry into L1

Figure 40. L1 Entry Example

Rules in PCIe mode for L1 request from the link layer:

1. lp_statereq = L1 must reach the logPHY before or at the same time as the PM_Enter_L1 ACK DLLP.

2. After it has requested L1, link layer cannot change the state req, unless it observes a transition to L1 or Retrain on the pl_state_status.

Link LayerDownstream

Flexbus LogPHYLink LayerUpstreamFlexbus LogPHY

lp_statereq=L1

LTSSM enters L1

pl_stallreq=1

lp_stallack=1

pl_state_sts = L1; pl_trdy = 0

pl_state_sts = L1

PM_Enter_L1 DLLP

PM_Enter_L1 DLLP

PM_Enter_L1 ACK DLLP

lp_state_req = L1

pl_stall_req = 1

pl_stall_ack = 1

pl_trdy = 0

pl_phyinl1 = 1 pl_phyinl1 = 1

LTSSM enters L1


pl_trdy is doing active throttling

Once I/Os are in L1 Once I/Os are in L1



8.7.4 L1 Abort Scenarios

Figure 41. L1 Abort Scenario 1Link Layer

DownstreamFlexbus LogPHY

Link LayerUpstream

Flexbus LogPHY

lp_statereq=L1

LTSSM enters Recovery

pl_stallreq=1

lp_stallack=1

pl_state_sts = RETRAIN; pl_trdy = 0

pl_state_sts = RETRAIN

PM_Enter_L1 DLLP

PM_Enter_L1 DLLP

…..


lp_state_req = L1

pl_stall_req = 1

pl_stall_ack = 1

pl_trdy = 0

pl_phyinrecenter = 1



lp_state_req = ACTIVE

Regular Recovery Exit Flow

logPHY decides to abort and go into recovery



Figure 42. L1 Abort Scenario 2

Link LayerDownstream

Flexbus LogPHYLink LayerUpstream

Flexbus LogPHY

lp_statereq=L1

pl_stallreq=1

lp_stallack=1


pl_state_sts = L1

PM_Enter_L1 DLLP

PM_Enter_L1 DLLP


lp_state_req = L1

pl_stall_req = 1

pl_stall_ack = 1

pl_trdy = 0



pl_rxdatastrm=0


pl_trdy is doing active throttling




Device



9.0 Support for CXL

9.1 Special Notes for LPIF Signalspl_error—In both Flexbus usages, when pl_error is asserted by the logPHY, no valid data should be sent on pl_data until the logPHY transitions LPIF state away from Active, following which rules for regular exit from corresponding state apply. If pl_error and pl_valid are asserted on the same cycle, then the link layer must not consume the corresponding FLIT as a valid FLIT. It must discard and retry it as part of the Retrain flow. For the cases where flit transfer happens over multiple clock cycles in chunks, link layer must reset chunk counters when the state status moves to RETRAIN or when pl_phyinrecenter is asserted.

Implementation Note

In multiple protocol cases with Arb/Mux, it is possible that it detects an ALMP error, but does not have enough time to block in-flight packets to upper layers. This is ok, because upper layers are expected to also check CRC errors for their own FLITs. Arb/Mux must assert pl_error for this scenario on the forwarded flit.

9.2 CXL over Flexbus LogPHYThis section describes the signals and concepts for supporting CXL protocol over Flexbus logPHY. All waveforms and flow diagrams outlined in this section are examples and should be considered as such. They are not meant to enumerate all possible corner cases. Implementation should make sure to honor the rules outlined in the specification.

9.2.1 Data Path ExampleBecause CXL protocol has a fixed FLIT size, both Tx and Rx directions are expected to transfer the FLIT in the same format over the interface. Figures below show data transfer for a 66B FLIT (64B data + 2B CRC) over the interface in the Tx and Rx directions when no link subdivision is supported (*crc* signals are optional in that case). Note that Byte[0] of the FLIT corresponds to Byte[0] (lp_data[0][7:0] or pl_data[0][7:0]) on the data bus and so on for Byte[1] …to Byte[63]. Byte[0] of CRC goes on Byte[64] of the CXL FLIT, and Byte[1] of CRC goes on Byte[65] of the CXL FLIT. On the Tx path, the logPHY is expected to insert IDLE FLITs on the link for any bubbles in lp_valid. For example, in Figure 43, logPHY inserts IDLE FLITs on clock cycles 3 and 4.

Figure 43. Tx Data Transfer Example—No Link Subdivision



On the Rx path, the logPHY is expected to drop IDLE FLITs received from the link.

Figure 44. Rx Data Transfer Example—No Link SubdivisionM

The data bus, crc and valid signals split between the ports when the link is subdivided. In this case, it may take multiple clock cycles (phases) for the link layer to transmit 1 FLIT (66B) of data. CRC bytes should only be valid on the last phase of the data transfer. Figures below show the Tx and Rx paths for 2 x8 configuration. This configuration consists of 2 ports, and in this example, each port gets 32B of data, 1 bit for data valid, 2B of CRC and 1 bit for CRC valid. link layer is not allowed to insert bubbles in the middle of a FLIT transfer on Tx. In the figures below, logPHY may insert IDLE FLITs on clock cycles 3 and 4.

LogPHY may insert bubbles in the middle of a FLIT transfer on Rx.

Implementation Note for Multi-Protocol Support

Implementations that support both PCIe and CXL modes may have more lp_valids than 1 bit per port. As an example, if the data path for PCIe is split as 4B per lane, then there would be 16 bits of lp_valid. In this situation, when the interface is subdivided for a support of 4 ports (as an example), each port gets 4 bits of lp_valid. Implementations of link layer are recommended to drive all 4 bits of lp_valid associated with that port when in CXL mode. It is also permitted for logPHY implementations to determine the appropriate association in CXL mode (assuming LSB of the 4 bits corresponds to the valid for the entire Port in CXL mode).

On the Rx direction, both CXL and PCIe have only 1 bit of valid per port.



Figure 45. Tx Data Transfer Example—Two Ports in x8 Configuration

lclk

lp_data[31:0][7:0]

lp_valid[0]

lp_crc[1:0][7:0]

lp_crc_valid[0]

lp_irdy[0]

pl_trdy[0]

lp_data[63:32][7:0]

lp_valid[1]

lp_crc[3:2][7:0]

lp_crc_valid[1]

lp_irdy[1]

pl_trdy[1]

lclk

lp_data[31:0][7:0]

lp_valid[0]

lp_crc[1:0][7:0]

lp_crc_valid[0]

lp_irdy[0]

pl_trdy[0]

lp_data[63:32][7:0]

lp_valid[1]

lp_crc[3:2][7:0]

lp_crc_valid[1]

lp_irdy[1]

pl_trdy[1]

. . .



Figure 46. Rx Data Transfer Example—Two Ports in x8 Configuration

9.2.2 LTSSM-to-LPIF State MappingSame as Section 8.5, LTSSM to LPIF State Mappings on page 61.

9.2.3 LinkError StateSame as Section 8.6, LinkError State on page 62.

9.2.4 Avoiding Explicit Physical Layer Packet (PLP) Exchange for PMBecause Flexbus logPHY borrows from PCIe semantics to communicate over the physical link—there is an optimization to avoid explicit PLP communication between the logical PHY on the CPU Host and the companion device. This optimization assumes no support for L0s in CXL mode.

In CXL mode, it is possible for the link layer to change lp_state_req from PM request to another state without any update on pl_state_sts. The following rules for Flexbus logPHY can help avoid corner cases without having an explicit PLP exchange between the main die and the companion device.

Rules for main die Flexbus logical PHY [Downstream port]:

1. It must wait for Electrical Idle from companion device (Upstream port) AND lp_state_req from its upper layer before initiating the flow to enter L1.

pl_valid[0]

lclk

pl_crc_valid[0]

pl_crc[1:0][7:0]

pl_data[31:0][7:0]

pl_crc[3:2][7:0]

pl_data[63:32][7:0]

pl_crc_valid[1]

pl_valid[1]

pl_valid[0]

lclk

pl_crc_valid[0]

pl_crc[1:0][7:0]

pl_data[31:0][7:0]

pl_crc[3:2][7:0]

pl_data[63:32][7:0]

pl_crc_valid[1]

pl_valid[1]



2. If Electrical Idle is received and lp_state_req is requesting non-PM state, then the logPHY must transition to Retrain and trigger Recovery on the Link. LogPHY can optionally keep a timeout mechanism to wait for a lp_state_req request to PM state.

Rules for companion device Flexbus logical PHY [Upstream port]:

1. It must initiate PM transition when requested by the upper layers by sending Electrical Idle, after pl_stall_req/lp_stall_ack handshake has finished.

2. Optional implementation of a timeout is permitted—if it does not receive an Electrical Idle from the Downstream port, it is allowed to initiate Recovery on the link.



9.2.5 Flow Diagram Examples

9.2.5.1 Initial Bringup to L0

Figure 47. CXL over Flexbus LogPHY—Initial Entry to L0

Figure 48 gives an example of interface signal transitions when the above flow is executed.


LTSSM enters Detect




Begin 128/130 Training – Train to highest Data Rate supported


LTSSM Enters L0


LTSSM ready to enter Recovery.IDLE – logPHY must wait for lp_cg_ack before going to Recovery.IDLE

Begin Training Sequence. Go all the way to Gen1 L0logPHY now knows CXL vs PCIe

lp_statereq = NOP/Active pl_state_status = Reset

trdy=0


pl_exit_cg_req = 1

lp_exit_cg_ack = 1

State_status=ACTIVE reflected is a function of statereq=ACTIVE and

LTSSM in L0 Status = ACTIVE is for Tx side to

get ready [gates Tx] exit_cg_req/exit_cg_ack

handshake is for receiver to get ready. LL must not assert cg_ack until it is ready to receive packets

logPHY knows if the recovery is initial boot or recovery because of error. For initial boot to >=Gen3 rates, logPHY must not assert trdy=1 until final negotiations are

complete.

lp_statereq=ACTIVE

Based on what is connected – if the logPHY decides that we are ok in Gen1/2, it will skip 128/130 and go ahead without 128/130.


pl_lnk_up = 1

pl_protocol updatepl_protocol_valid = 1

pl_exit_cg_req =1

lp_exit_cg_ack = 1

pl_lnk_up = 1

lp_statereq=ACTIVE


LTSSM Enters L0



LTSSM enters L0 (cannot get to L0 without

exit_cg_ack)

pl_exit_cg_req = 0

lp_exit_cg_ack = 0

pl_exit_cg_req =0

lp_exit_cg_ack = 0




Note: The figure is just an example. Implementations must follow all the rules of signal transitions listed in the previous sections.

Figure 48. Example Waveform for CXL over Flexbus Bringup

The comments for the arrows in Figure 48 follow:

• R1: pl_state_sts only changes to Active after transition to L0 and state_req is Active (state_req can transition to Active at any time). If logPHY knows that it is going to train to higher Gen speeds, it is permitted to not reflect Active when LTSSM is in L0 (since it is only a transitionary L0 state).

• R2: Configuration.Complete is gated on receiving lp_exit_cg_ack, hence entry to L0 will not happen until exit_cg_ack is received. The lp_exit_cg_ack must assert within 1ms of pl_exit_cg_req assertion. Based on implementation choice logPHY may choose to not perform this handshake if it knows that it is going to try and train to higher speeds, and directly do the handshake in Recovery.RcvrCfg (R3) for the highest supported speed (in this case, the logPHY may relax the 1ms timeout to a larger value, as long as there is no risk of LTSSM timeouts).

• R3: Exit from Recovery.RcvrCfg is gated on receiving lp_exit_cg_ack. logPHY will not enter Recovery.IDLE before receiving it.

• R4: LL must be ready to receive packets when it gives lp_exit_cg_ack. • R5: Entry into Recovery is gated by lp_stallack assertion. This rule relies on

pl_stallreq assertion before pl_protocol_vld, and link layer waiting for pl_protocol_vld before preparing packets/requesting Active.

The lp_exit_cg_ack must assert within 1ms of pl_exit_cg_req assertion—in order to avoid LTSSM timeouts. It is strongly recommended for the logPHY for Flexbus usages to implement timeout logic that escalates to a fatal error. If a timeout happened for lp_exit_cg_ack, the logPHY follows LTSSM rules for timeout in the corresponding LTSSM state, and if it ends up back in Detect, it is strongly recommended to have a de-feature bit to park in Detect and wait for software intervention before initiating training again. Because the upper layers may wait for pl_protocol_vld before responding to pl_exit_cg_req, logPHY must make sure it does not assert pl_exit_cg_req too soon before pl_protocol_vld. The relative times between pl_exit_cg_req, pl_protocol_vld, lp_exit_cg_ack must be implemented to prevent LTSSM timeouts.

See Figure 38 for LTSSM substate details.



9.2.5.2 Recovery flow

Figure 49. Recovery Flow for CXL over Flexbus


lp_statereq=RETRAIN


pl_stallreq=1

lp_stallack=1

pl_trdy=0

pl_stallreq=1

lp_stallack=1

pl_trdy=0

pl_state_status=RETRAINpl_phy_in_recenter=1

pl_state_status=RETRAINpl_phy_in_recenter=1


Recovery flow as usual driven from logPHYlp_statereq=ACTIVE

pl_exit_cg_req=1

lp_exit_cg_ack=1


LTSSM Enters L0


LTSSM ready to enter Recovery.IDLE –logPHY must wait for lp_cg_ack before

going to Recovery.IDLE




LL can ask for ACTIVE ANYTIME. lp_statereq=ACTIVE

pl_exit_cg_req=1

lp_exit_cg_ack=1

LTSSM Enters L0

LTSSM ready to enter Recovery.IDLE –logPHY must wait for lp_cg_ack before

going to Recovery.IDLE




If lp_state_req is RETRAIN when logPHY reaches L0, then

pl_state_status will move to ACTIVE and then go back to RETRAIN using the same flow

from the beginning [LTSSM moves to Recovery and starts sending

TS1]

Pl_stallreq=0

lp_stallack=0

pl_stallreq=0

lp_stallack=0

pl_exit_cg_req=0

lp_exit_cg_ack=0

pl_exit_cg_req=0

lp_exit_cg_ack=0




9.2.5.3 Entry into L1

Figure 50. L1 Entry Example

Arb/MuxDownstream

Flexbus LogPHYArb/MuxUpstreamFlexbus LogPHY

LTSSM enters L1

pl_stallreq=1

lp_stallack=1

pl_state_sts = L1; pl_trdy = 0

Pl_state_sts = L1

lp_state_req = L1

pl_stall_req = 1

pl_stall_ack = 1

Pl_trdy = 0

pl_phyinl1

LTSSM enters L1

Pl_trdy is doing active throttling

When all vLSMs are in L1

When all vLSMs are in L1

lp_state_req = L1

logPHY needs to wait for EI from upstream AND statereq=L1 before initiating stallreq

pl_phyinl1Once I/Os are in L1

Once I/Os are in L1



9.2.5.4 L1 Abort Scenario

Figure 51. L1 Abort Scenario

Arb/Mux Flexbus LogPHY Arb/MuxFlexbus LogPHY

lp_statereq=L1


pl_stallreq=1

lp_stallack=1



lp_state_req = L1

pl_stall_req = 1

pl_stall_ack = 1

pl_trdy = 0






logPHY decides to abort and go into recovery



10.0 Bifurcation Support

In case of a bifurcated link, each bifurcated port is expected to have its own LPIF interface. Each of these LPIF interfaces talk independently to the logPHY and have no requirements to be in sync with respect to any flows described in this specification. Both the link layer and the logPHY must be in sync with respect to the bifurcation configuration.

Implementation Note

In cases where the link layer and logPHY support multiple bifurcations (for example in PCIe, it is common to support x16 or 2 x8 or 4 x4 lane configurations), it is strongly recommended that the data bus (lp_data, and pl_data) are shared efficiently in the different bifurcation configurations. The data bus must be wide enough to get full BW for the widest supported configuration. As an example, for PCIe x16 @ 32GT/s -- 64 bytes of data are needed when link layer and logPHY are running at 1 GHz. When configured as 2 x8, the lp_data and pl_data should be split into 2 sets of 32 bytes each, with each set corresponding to one of the bifurcated ports. The link layer and logPHY understand this when interpreting the data streams based on the bifurcation configuration. Moreover, if the maximum bifurcation possible is 4 x4, there will be a total of 4 sets of LPIF control signals and state machines, and it is understood by both link layer and logPHY that only 1 set is active when configured as x16.



11.0 Implementation Notes for Certain Global Flows

This section covers interactions with global entities (software, power management unit, etc.) to enable certain platform-specific flows.

11.1 DPC for PCIe/CXL ModeFigure 52 illustrates the enhanced Downstream Port Containment (eDPC) flow on LPIF in PCIe or as part of the error isolation flow in CXL . Link is expected to train back up without a warm reset1.

Figure 52. DPC for PCIe/CXL Mode

The link layer may decide to not assert lp_linkerror and exercise this flow for DPC if it can manage containment without the need to bring the link down.

1. logPHY is permitted to wait for NOP from upper layer before retraining the link

PCIe:ControllerCXL: Arb/MuxDP LogPHY LogPHY

lp_linkerror = 1

Disabledpl_state_status = LinkError

lp_linkerror = 0

lp_state_req = NOP

pl_state_status = Resetpl_inband_pres = 0

Link <‐>

UPDevice

pl_state_status = Disabled

pl_lnk_up = 0

sec_bus_rst_b = 0

lp_state_req = Active

pl_state_status = Resetwhen EI exit seen

Detect

pl_state_status = Active

Detect

pl_state_status = Active

Controller de‐ asserts lp_linkerror when software has cleared error

status registers

PCIe:ControllerCXL: Arb/Mux

pl_inband_pres = 1


Link trains up to L0

ResetPrep

pl_inband_pres = 0

ResetprepAck

prim_rst_b=0

sec_bus_rst_b = 1Regular post‐reset link bring up



11.2 DPC for CXL Mode (if error isolation is not supported)Figure 53 illustrates the flow in CXL mode. After an error is detected, link is brought down, and it stays down until warm reset.

Figure 53. Containment flow if eDPC is not supported

11.3 Warm Reset FlowFigure 54 illustrates an example of the warm reset flow in CXL mode. In PCIe mode, the actions by the controller and the logPHY are the same, and Arb/Mux is in bypass mode.

ControllerDP

LogPHYDP

LogPHYUP

lp_linkerror = 1

Disabledpl_state_sts = LinkError

Link <‐>

ControllerUP

PMA

pl_state_sts = Disabled

pl_lnk_up = 0

sec_bus_rst_b = 0

Firmware must eventually trigger warm reset

ArbMuxDP

ArbMuxUP

lp_linkerror = 1

pl_state_sts = LinkError

pl_state_sts = Disabled

pl_lnk_up = 0



Figure 54. Hot Reset flow

Rules for this flow (rules apply to both Downstream and Upstream, unless a particular configuration is given at the beginning of the rule):

1. CXL.cachemem returns reset prep ack as soon as it receives reset prep message (hence not shown in the flow above).

2. Arb/Mux propagates LinkReset to both link layers (performing exit_cg_req/ack handshake when necessary)

3. For Downstream port, CXL.io controller asserts lp_force_detect 2ms after observing pl_state_sts = LinkReset. This is to make sure link stays in HotReset for at least 2ms as required by PCIe specification.

4. For Downstream port, if lp_force_detect = 1, Arb/Mux propagates Reset from the logPHY to the link layer that asserted lp_force_detect.

PMA

CXL.io ControllerDP

ArbMuxDP

LogPHYDP

LogPHYUP

Reset Prep lp_state_req = LinkReset

HotReset

HotReset

Min 2ms

HotReset

pl_state_sts = LinkReset

Min 2ms

lp_force_detect = 1


Detect

pl_state_sts = Reset


Reset Prep Ack

Link <‐>

lp_state_req = LinkReset


ArbMuxUP

CXL.io ControllerUP

PMA


pl_lnk_up = 0


sec_bus_rst_b = 0

Reset Prep

lp_state_req = Active [controller maintains Active request]



Reset Prep Ack

prim_rst_b = 0prim_rst_b = 0


2ms

Detect

HotReset




5. LogPHY transitions pl_state_sts to RESET, after it is ready to receive prim_rst_b = 0.

6. CXL.io controller only returns Reset Prep Ack after observing pl_state_sts = RESET.

7. For Upstream port, Arb/Mux propagates RESET from logPHY to CXL.io controller if pl_lnk_up = 0.

For Downstream port—if at any time pl_state_sts moves to Reset/Disabled/Linkerror/L1/L2, then:

1. CXL.cachemem has the same behavior—return reset prep ack as soon as it receives the reset prep message.

2. If pl_state_sts = LinkError or Reset, then CXL.io returns the reset prep ack immediately, and assert lp_force_detect.

3. If pl_state_sts = L1 or L2 or Disabled, then CXL.io asserts lp_force_detect immediately, it waits for pl_state_sts = RESET before returning reset prep ack response. LogPHY moves to RESET when LTSSM moves to DETECT after receiving lp_force_detect.

For Upstream ports—CXL.io detects link down transition conditions (based on LPIF state status[Reset/Disable/LinkError/LinkReset]—and if from cold boot DL state machine was active) to trigger local secondary_bus_rst_b = 0 to SoC. This triggers a reset prep handshake with CXL.io controller. For pl_state_sts = Reset, the reset prep ack is returned instantly. For pl_state_sts = LinkError, the reset prep ack is returned when pl_lnk_up = 0. For pl_state_sts = Disable or LinkReset, the reset prep ack is returned when the pl_state_sts ultimately moves to Reset.

CXL.cachemem behavior is the same between Upstream and Downstream ports.

11.4 Sx FlowRules for entry to Sx state at platform in CXL mode are given below.

1. Flow is initiated by PMA by sending Reset Prep message for Sx entry to CXL.cachemem and CXL.io Controllers

2. If status is ACTIVE, controllers request entry into L2 state through lp_state_req = L2. If status is L1, controllers bring the status to ACTIVE and then request L2.

3. Arb/Mux co-ordinates the L2 transition for each of the vLSMs, followed by L2 transition of the physical link.

4. CXL.cachemem returns reset prep ack after observing pl_state_sts = L2. Implementations are permitted to issue reset_prep_ack without waiting for pl_state_sts = L2, because the CXL.io reset prep ack is gated by the physical link being in L2.

5. CXL.io returns reset prep ack after observing pl_state_sts = L2 and pl_phyinl2 = 1.

6. LogPHY does pl_clk_req/lp_clk_ack handshake before asserting pl_phyinl2 = 1 (see Section 2.2.1, Implementation Rules for Clock Gating on page 24).

For PCIe Mode, the rules are:

1. Flow is initiated by PMA by sending Reset Prep message for Sx entry to PCIe Controller

2. If status is ACTIVE, controller requests entry into L2 state through lp_state_req = L2. If status is L1, controller brings the status to ACTIVE and then requests L2.



3. LogPHY co-ordinates the L2 transition of the physical link.4. Controller returns reset prep ack after observing pl_state_sts = L2 and

pl_phyinl2 = 1.5. LogPHY does pl_clk_req/lp_clk_ack handshake before asserting pl_phyinl2 = 1

(see Section 2.2.1, Implementation Rules for Clock Gating on page 24).

For Downstream ports—if pl_state_sts = Reset or Disabled or LinkError or L2, then:

1. In CXL mode, the CXL.cachemem controller returns reset prep ack immediately. 2. In CXL or PCIe mode, for CXL.io:

a. If pl_state_sts = LinkError or Reset, CXL.io returns the reset prep ack immediately. It also asserts lp_force_detect immediately to prevent the link from training up.

b. If pl_state_sts = Disabled, CXL.io asserts lp_force_detect and wait for pl_state_sts = RESET before returning reset prep ack response.

c. If pl_state_sts = L2, CXL.io returns the reset prep ack response after pl_phyinl2 = 1.

For Upstream ports—CXL.io detects link down transition conditions (based on LPIF state status[Reset/Disable/LinkError/LinkReset]—and if from cold boot DL state machine was active) to trigger local secondary_bus_rst_b = 0 to SoC. This triggers a reset prep handshake with CXL.io controller. For pl_state_sts = Reset, the reset prep ack is returned instantly. For pl_state_sts = LinkError, the reset prep ack is returned when pl_lnk_up = 0. For pl_state_sts = Disable or LinkReset, the reset prep ack is returned when the pl_state_sts ultimately moves to Reset.

CXL.cachemem behavior is the same between Upstream and Downstream ports.



Appendices

A Protocol Link Layer Signals

Table 14 shows which signals of LPIF are relevant for the different protocol link layers and logPHYs. N/A implies Not Applicable. For those signals, the specific decision of tie-off values and consumption is implementation-specific. Safe implementation is for the receiver to ignore. Special cases are annotated as footnotes when appropriate.

Table 14. Applicability of signals to different protocols

Signal Name Native PCIe

Flexbus logPHY

(CXL Mode)

CXL.io CXL.Cache/ Mem (LL)

lclk Yes Yes Yes Yes

pl_trdy Yes Yes Yes Yes

pl_data Yes Yes Yes Yes

pl_valid Yes Yes Yes Yes

pl_crc N/A Yes N/A 1 Yes

pl_crc_valid N/A Yes N/A 1 Yes

pl_stream Yes Yes Yes Yes

pl_error Yes Yes Yes Yes

pl_trainerror Yes Yes Yes Yes

pl_cerror Yes Yes Yes Yes

pl_stallreq Yes Yes Yes Yes

pl_nbstallreq Yes N/A N/A N/A

lp_nbstallack Yes N/A N/A N/A

pl_tmstmp Yes Yes Yes Yes

pl_tmstmp_stream Yes Yes Yes Yes

pl_phyinl1 Yes Yes Yes N/A

pl_phyinl2 Yes Yes Yes N/A

lp_irdy Yes Yes Yes Yes

lp_pri N/A N/A Yes Yes

lp_data Yes Yes Yes Yes

lp_stream Yes Yes Yes Yes

lp_valid Yes Yes Yes Yes

lp_crc N/A Yes N/A 1 Yes

lp_crc_valid N/A Yes N/A 1 Yes

lp_stallack Yes Yes Yes Yes

lp_state_req Yes Yes Yes Yes



pl_state_sts Yes Yes Yes Yes

lp_tmstmp Yes Yes Yes Yes

lp_linkerror Yes Yes Yes Yes

lp_dl_active Yes Yes Yes N/A

pl_quiesce Yes N/A N/A N/A

lp_flushed_all Yes N/A N/A N/A

lp_good_dllp Yes N/A 2 N/A N/A

lp_rcvd_crc_err Yes Yes Yes Yes

lp_kchar Yes N/A N/A N/A

pl_block_dl_init Yes N/A N/A N/A

pl_in_rxl0s Yes N/A N/A N/A

pl_lnk_cfg Yes Yes Yes Yes

pl_lnk_up Yes Yes Yes N/A

pl_rxframe_errmask Yes Yes Yes Yes

pl_portmode Yes Yes Yes Yes

pl_portmode_val Yes Yes Yes Yes

pl_speedmode Yes Yes Yes N/A

pl_byte_err Yes N/A N/A N/A

pl_kchar Yes N/A N/A N/A

pl_clr_lnkeqreq Yes Yes Yes N/A

pl_set_lnkeqreq Yes Yes Yes N/A

pl_inband_pres Yes Yes Yes Yes

lp_device_present Yes Yes Yes N/A

pl_ptm_rx_delay Yes Yes Yes N/A

pl_setlabs Yes Yes Yes N/A

pl_setlbms Yes Yes Yes N/A

pl_surprise_lnk_down Yes Yes Yes N/A

pl_protocol Yes Yes Yes Yes

pl_protocol_vld Yes Yes Yes Yes

pl_err_pipestg Yes Yes Yes N/A

pl_tx_nfts Yes N/A N/A N/A

pl_rx_nfts Yes N/A N/A N/A

pl_sris_en Yes N/A N/A N/A

pl_dlpstart Yes N/A N/A N/A

pl_dlpend Yes N/A N/A N/A

pl_tlpstart Yes N/A N/A N/A



Flexbus logPHY

(CXL Mode)




Figure 55 and Figure 56 show the packet formats for the configuration interface for 16- and 8-bit interface widths, respectively.

pl_tlpend Yes N/A N/A N/A

pl_tlpedb Yes N/A N/A N/A

pl_rx_flush Yes N/A N/A N/A

lp_force_detect Yes Yes Yes N/A

pl_clk_req Yes Yes Yes N/A

lp_clk_ack Yes Yes Yes N/A

lp_wake_req Yes Yes Yes Yes

pl_wake_ack Yes Yes Yes Yes

pl_phyinrecenter Yes Yes Yes Yes

pl_cfg Yes Yes Yes N/A

pl_cfg_vld Yes Yes Yes N/A

lp_cfg Yes Yes Yes N/A

lp_cfg_vld Yes Yes Yes N/A

pl_exit_cg_req Yes Yes Yes Yes

lp_exit_cg_ack Yes Yes Yes Yes

1. CRC bytes for CXL.io are in the TLP itself, no extra bytes needed. 2. Flexbus logPHY in CXL mode must generate this internally, when it receives a

protocolID that is not the IDLE protocolID. Refer to the CXL Specification for encodings. It must ignore the input from LL in this mode.



Flexbus logPHY

(CXL Mode)




Figure 55. Packet Formats for the 16-bit Configuration Interface



Figure 56. Packet Formats for the 8-bit Configuration Interface

A.1 Open IssuesNote: There are no Open Issues in this appendix.



B Open Issues

The Open Issues in this specification follow:

Open: Support for L0s will come in at a later version . . . . . . . . . . . . . . . . . . . . . 55