PIPE 5.1.1 for PCIe 5.0, DP 1.4, USB 3.2, SATA

Artificial intelligence and machine learning are rapidly penetrating a wide spectrum of devices, driving the re-architecture of SoC designs, requiring more memory space and higher bandwidth to transfer and process data. This change requires higher speed interfaces and wider buses, paving the path for enhancements in latest PCIe, USB, DP, and SATA protocol specifications, as well as upgrades in PIPE (PHY Interface for the PCI Express) specification as the preferred PHY interface.

PCIe base specification has advanced to version 5.0, revision 0.7, and is expected to graduate to revision 1.0 soon. PCIe 5.0 has introduced a higher link speed of 32 GT/s as its primary new feature, also referred as Gen5 speed. To accelerate PCIe system development, PIPE interface is widely being used in the industry. With the base specification graduating to 5.0, PIPE specification is also catching up and has advanced to version 5.1.1. The latest specifications version enables PIPE interface to achieve Gen5 speed and provides several additional enhancements.

PIPE specification has evolved to version 5.1.1 not only to match the latest specifications but also to scale up for future enhancements in the protocols. In our previous blog on PIPE – PCIe PIPE 4.4.1: Enabler for PCIe 4.0, we discussed about features available in PIPE specifications version 4.4. In this blog we will talk about new features added in PIPE specifications version 5.1.1.

PIPE 4.4.1 has already isolated digital and analog aspects of PHY designs from the controller designs, providing a definitive boost in the SoC development cycle, as now the controller designs must only cater to the protocol aspects it is being designed for. However, with the PIPE 4.4.1, PHY vendors should either develop different PHYs for different protocols or design a single complex PHY to cater to multiple protocols like PCIe, USB, and SATA. This usage model is not scalable when design must be upgraded to accommodate all the enhancements and upgrades in PCIe, USB, DP, and SATA protocol specifications. Additionally, a new tunneling protocol is also emerging to transmit USB, PCIe and DP over a common PHY. This has paved the path for a PHY design which is simple and protocol agnostic and can handle higher bandwidth at lower real estate cost. These requirements are smartly resolved with PIPE 5.1.1 by introducing new features ‘SerDes architecture’ and ‘Low Pin Count interface’.

SerDes architecture makes a PIPE 5 PHY protocol agnostic with all the protocol specific logic shifted to the controller. This simplifies the PHY design and allows it to be shared easily by different protocol stacks. A Low Pin Count interface caters to the low real estate cost requirement. With wider data buses, data path already consumes many pins on the interface. To reduce the total pin count; most of the non-time critical sideband signaling handshake is moved over MBI bus. The effective result is lesser number of pins across PIPE interface with a wider data path in place. This approach is also scalable for future protocol enhancements.

The PIPE 5.1.1 specifications has some additional updates other than SerDes architecture and Low Pin Count interface. The following list summarizes all the major upgrades in PIPE 5.1.1:

• Added support for Display Port and Converged IO protocols along with maintaining support for PCIe, USB, and SATA protocols
• Low Pin Count Interface
  • Removed legacy handshake signals
  • Mapped legacy signals into Message Bus registers of PHY and MAC
  • Introduced usage of message bus commands [reads and writes] to communicate handshake between PHY and MAC for all the following sub-features
    • Receiver equalization
    • Dynamic equalization
    • TxDeemph, FS, LF, LocalFS, LocalLF settings
    • Receiver margining
    • Lane margining
    • Elastic buffer control
    • Polarity inversion
    • Block align control
  • SerDes Architecture
    • Enables SerDes data path equivalent to an existing conventional 8/16/32-bit data path
    • Enables new wider SerDes data path equivalent to conventional 64-bit data path.
  • Low power L1 Sub States support using sideband signals
  • Deprecated “PCLK as PHY out mode” for the operations of PIPE interface
  • Mandated “PCLK as PHY input mode” for the operations of PIPE interface
    • This simplifies PHY designs as the burden of ‘clock generation’ now shifts into the Controller design
  • Added MAC and PHY handshake for communicating ‘rate’, ‘width’ and ‘pclk_rate’ signals changes
    • PclkChangeOk and PclkChangeAck signals are used for this handshake
    • PclkChangeOk signal is used by PHY to communicate to MAC that it is ready for the MAC to change rate, width or Pclk frequency
    • PclkChangeAck signal is used by MAC to communicate to PHY that the change in rate, width or Pclk frequency is complete and stable
  • Added support to Receiver detection in P2 power state
  • Deprecated ‘lane turn off’ signaling

Many of these updates provide future scalable solutions at the cost of being backwards incompatible. One such example is the requirement to deprecate legacy sideband signals and use MBI bus for signaling the handshake between MAC and PHY Message Bus register space. Legacy PIPE interface for sideband signals (ex. equalization signals), mandatory for performing Receiver equalization and Dynamic equalization features for any device compliant to PCIe 4.0, is no longer applicable for a device compliant with PCIe 5.0. Receiver equalization and Dynamic equalization is carried over MBI bus using MBI read and write commands for registers from MAC and PHY’s Message Bus register space.

Another drastic architectural change is the optional support to SerDes architecture. Support to SerDes architecture is optional for a PCIe 4.0 device, but is mandatory for a PCIe 5.0 device. With the introduction of SerDes architecture, PHY implements minimal digital logic as compared to the original PIPE architecture. This makes PHY design scalable as well as easily sharable between different protocols. The PHY designs are still recommended to support conventional architecture to retain interoperability with MACs that choose not to migrate to SerDes architecture. The difference between conventional architecture and SerDes architecture is depicted in the figure below.