Synopsys Cloud
Cloud native EDA tools & pre-optimized hardware platforms
Request a Free Trial →
Table of Contents
Lately we have seen a trend of serial data transfers in place of parallel data transfer for improved performance and data integrity. One example of this is the migration from PCI/PCI-X to PCI Express. A serial interface between two devices results in fewer number of pins per device package. This not only results in reduced chip and board design cost but also reduces board design complexity. As serial links can be clocked considerably faster than parallel links, they would be highly scalable in terms of performance.
However, to accelerate verification of PCI Express based sub-systems and to accelerate the PCI Express endpoint development time , PIPE (PHY Interface for the PCI Express Architecture) was defined by Intel and was published for industry review in 2002. PIPE is a standard interface defined between a PHY sub-layer which handles the lower levels of serial signaling and the Media Access Layer (MAC) which handles addressing/access control mechanisms. The following diagram illustrates the role PIPE plays in partitioning the PHY layer for PCI Express.
(Source: PHY Interface for thePCI Express Architecture specification, Version 2.00)
With this interface, developers can validate their designs without having to worry about the analog circuitry associated with the Phy interface. For the MAC core verification, the PHY Bus Functional Model (BFM) would be connected directly to it. Without PIPE, it would be required to have the PHY and Serdes (serializer/deserializer) combination along with the Root Complex BFM. Additionally, the user would have to ensure the correctness of the PHY and SerDes behavior as well with the serial interface.
Given the value of the PIPE interface, it is now being widely used. In our recent experiences, we have observed that the different power states in the PIPE interface can create some confusion with respect to their interpretation. This blog post and the next will throw some light on the different power states of this interface. Hopefully, this will lead to a better understanding of the same. The assumption here is that the reader has a high level understanding of PCIe LTSSM.
Power states of PIPE
The power management signals allow the PHY to minimize the power consumption. Four power states, P0, P0s, P1, and P2 are defined for this interface. P0 state is the normal operational state for the PHY. One it transitions from P0 to a lower power state, the PHY can immediately take appropriate power saving measures.
All power states are represented by signals PowerDown [2:0](MAC output). The Bit representation is as follows:
2] [1] [0] Description
0 0 0 P0, normal operation
0 0 1 P0s, low recovery time latency, power saving state
0 1 0 P1, longer recovery time latency, lower power state
0 1 1 P2, lowest power state.
PIPE interface power state can be correlated with power state of LTSSM as mentioned in Base specification (Refer to PCI_Express_Base_r3.0_10Nov10).
- P0 is equivalent to LTSSM State where Data/Order Set can transfer
- P0s is equivalent to L0s of LTSSM
- P1 is equivalent to Disabled, all Detect , and L1.Idle state of LTSSM
- P2 is equivalent to L2 of LTSSM
In states P0, P0s and P1, the PHY is required to keep PCLK operational. For all state transitions between these three states, the PHY indicates successful transition into the designated power state by a single cycle assertion of PhyStatus.
There is a limited set of legal power state transitions that a MAC can cause the PHY to make. Referencing the main state diagram of the LTSSM in the base specification and the mapping of LTSSM states to PHY power states described in the preceding paragraphs, those legal transitions are:
- P0 to P0s
- P0 to P1
- P0 to P2
- P0s to P0
- P1 to P0
- P2 to P1
Given that we understand the valid power state transitions, I would capture more details about the individual power states and all possible transitions in more detail in my subsequent blog. Stay tuned.
Continue Reading
Blog
2 min read
/
Sep 12, 2024
Industry First Verification IP for Arm AMBA DTI-G
