VIP Central

 

Demystifying PCIe PIPE 5.1 SerDes Architecture

Artificial intelligence and machine learning are rapidly penetrating a wide spectrum of devices, driving the re-architecture of SoC designs and 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 the latest PCIe protocol specifications, as well as upgrades in PIPE (PHY Interface for the PCI Express) specification as the preferred PHY interface.

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. 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. SerDes architecture for PIPE interface achieves scalability by introducing several key changes to the responsibilities of the Physical Coding Sublayer (PCS) and Media Access Layer (MAC), along with updates to the signaling interface.

Figure 1: Partitioning PHY Layer for PCI Express

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

• 8b/10b or 128b/130b encoding/decoding performed by MAC
• Elastic Buffer Control maintained by MAC, RxStatus is only used for Receiver Detection purpose
• PHY presents RxData synchronous to recovered clock ‘RxClk’, over a pipe width determined by ‘RxWidth’
• RxPolarity field no longer used for SerDes architecture, MAC is responsible for inverting receiver polarity
• Loopback performed by MAC
• New supported 64-bit data width exclusively for SerDes architecture
• PIPE Data Widths of 10/20/40 bits, as opposed to 8/16/32

With all the changes brought in by SerDes architecture, it becomes challenging to debug and comprehend the new formatting of PIPE data on the interface. Specifically, new PIPE widths and the shifting of encoder/decoder into MAC causes data on PIPE interface to appear much differently than it did for any previous PIPE versions. As you read on, you’ll see how we try to break up data into smaller units to present a clear picture of how information is exchanged over the interface.

TxData/RxData signal widths are 10-bit multiples (80/40/20/10). For 8b/10b encoding, each 10 bits carry 10b encoded data. At 128b/130b encoding, each 10 bits carry 8 bits of data and upper two bits are reserved.

Figure 2: Data Transfer across PIPE SerDes Architecture

Let us look at COM symbol transmitted at Gen1/Gen2 speed over a 40-bit PIPE width in the figure below. 8b/10b encoded value for COM (0011111010) occupies all bits [9:0] of TxData.

Bit ‘a’ (out of ‘abcdeifghj’) should go first into the interface, so it will be 17c.

Figure 3: 8b/10b Special Character Symbol Codes

Note that the remaining 2 bits in 17c (i.e. 0001 0111 1100) corresponds to the next symbol.
Now let’s look at block encoded data. While presenting data on TxData/RxData, only 8 bits out of each 10-bit slices are used and upper two bits are reserved. Consider a Gen3 Electrical Idle Ordered Set (EIEOS) on a 40-bit pipe interface.

• The encoding adds 2 sync header bits in front of the block. Please note that they are TxSyncHeader and RxSyncHeader here.

So, the data we see on the interface will be 3F0033F001

 

 

SerDes architecture is seeing rapid adoption across the board. As the PIPE specification continues to evolve, design and verification cycles of complex PCI Express controllers and PHYs will become more intricate and time consuming. Synopsys PCI Express VIP fully supports PIPE 5.1 and offers a mature and comprehensive verification solution.

To learn more about Synopsys VIP visit: http://synopsys.com/vip