Solutions to Resolve Traditional PHY Verification Challenges

Yogesh Chaudhary, Mentor Graphics India (Pvt.) Ltd.

Abstract:

This article describes the challenges faced with the traditional approach for the PHY verification. During this article, while going into details of PHY verification, we will discuss the solution provided to do the PHY verification with minimal effort, without investing in understanding of the multiple protocol stacks being used by PHY’s. The new provided approach would help users to develop test suite which can be easily reused for the verification of multiple PHY’s. The solution incorporates a host of benefits, including faster, more flexible verification and easier debugging.

OVERVIEW

PHY’s are present in each and every domain whether it is memory (DDR2/DDR3/DDR4/LPDDR3), Ethernet, SATA, USB, PCIe and the latest addition of PHYs is from the mobile industry. In a fast-paced mobile industry, the challenge of completing a reliable PHY verification is multifold. With the MIPI alliance to have introduced multiple PHYs (M-PHY, D-PHY and C-PHY) to support variety of protocol stacks, verifying the underlying PHYs requires thorough understanding of the protocol stack, which only makes the verification more complex and harder to debug.

PHY INTRODUCTION

In addition to analog signaling, the common functionalities of the physical layer in all the domains led the industry to define a common PHY that multiple protocols could use and that segregates the PHY logic from that of the general ASICs. However, the PHY does need to transfer data back and forth with the protocol stack.

Each PHY has two logical interfaces – serial and parallel. Depending on the protocol stack requirements, both the interfaces generally have six building blocks such as parallel TX and RX, buffers, encoder and decoder, serialization and deserialization, lane management, and driver TX and receiver RX. The PHY communicates with the protocol stack on the parallel interface and transmits (receives) the processed data to (from) the receiving (transmitting) PHY on the serial interface.

Given this design of the common PHY, a comprehensive and reliable PHY verification requires expertise of the corresponding protocol stack as well.

What if there is an option to focus just on verifying the PHY without investing time and effort understanding the corresponding protocol stack? What if there are two options? What if both the options also make verification faster and more flexible with easier debugging?

TRADITIONAL APPROACH

For the mobile industry, the MIPI alliance prominently drives two PHYs – M-PHY and D-PHY/C-PHY. M-PHY is the successor of D-PHY, requiring less pins and providing more bandwidth with improved power efficiency. So, they both have different applications that can be connected to them on the parallel interface.

Refer to the following figure that depicts the typical use-models:

So, the problem with the traditional approach of verifying M-PHY or D-PHY is that it requires a thorough understanding of the specifications of the corresponding protocol stack. In addition, none of the protocols supports all PHY features and because each protocol stack has its own space and defined application, the top message in each protocol is different. In practical scenarios, the time constraints and pressure to release the design early in the market do not provide liberty to comprehend the protocol stack specifications.

Generally, with the traditional approach, the PHY verification is either of the two:

• Standalone PHY verification or
• Use-model based PHY verification

In the standalone PHY verification, the Verification IP (VIP) is connected to the PHY DUT at the serial interface and provides the sequences (or sequence items) at the parallel interface that initiate the traffic. However, in this configuration, you do not need to understand the protocol stack specifications, but you do need to write your own glue logic that can end up as a full application Bus Functional Model (BFM) including all protocol intricacies. Consequently, you need to configure the parallel interface of the PHY DUT by hand and the process for writing PHY test cases is different in the standalone PHY verification. So, its usage is very much confined as you need to build an application bus functional model to handle the parallel interface of the PHY DUT, which in-terms, you will end up building a full VIP with all the protocol intricacies.

In the use-model based PHY verification, which is highly used you connect the VIPs at both the serial and parallel interfaces of the PHY DUT. However, the VIPs at both the interfaces must belong to the same protocol stack. For a comprehensive PHY verification, you need to build multiple environments – specific to each supported protocol stack.

The limitations of this approach are:

• You need to comprehend not just one, but multiple protocol stacks, which may not be practical for a PHY verification engineer given the time constraints of the verification cycle
• Because none of the protocol stacks provide the full PHY functionality, multiple verification environments might be required including:
  • Pin connections
  • Initial bring up for each specific protocol stack
  • Clock configuration for each specific protocol stack
• In case you set up multiple verification environments for the single PHY, you will also need to perform test planning, coding, execution, and regression set up multiple times to do the robust PHY verification
• With the multiple protocol stacks involved, the process of debug and troubleshoot becomes more complex
• No reusability of the multiple verification environments and test suites

All these limitations put together create a high maintenance PHY verification environment that requires huge effort, time, and investment.

We were facing hard time to convince users and ourselves that complete PHY verification can be done with using multiple protocol stack VIPs. When we failed multiple times then it forced us to think over it again to search a perfect solution.

Note: The VIP here refers to a model that has BFM, stimulus generator, coverage collector, and a protocol checker.

SOLUTIONS

Having faced many limitations, problems and weakness with traditional PHY DUT verification, we started with the MIPI M-PHY and D-PHY. We did lot of brainstorming and gone through all the supported protocol stack specifications by the MIPI M-PHY and D-PHY and we came up with these solutions:

• Generic APIs for protocol stacks
• Generic Physical Adapter (PA) layer for the PHY parallel interface

Generic APIs

We have developed a generic layer of APIs that rests just above the protocol stack and provides the flexibility to initiate and debug the data transfers with the protocol stack without having to understand the protocol intricacies. The generic APIs, however, are specific to the underlying PHYs – a separate layer of generic APIs for M-PHY and another layer for D-PHY/C-PHY.

Now, you do not have to know the details of any of the protocol stack being used by the M-PHY or D-PHY/C-PHY. You just have to know the M-PHY or D-PHY specification and can directly co-relate these generic API’s with the respective PHY functionality, which you have already studied in the M-PHY, D-PHY and C-PHY specification.

For example, let us consider that you need the M-PHY DUT to exit from HIBERN8, which requires a specific process for each protocol stack – UniPro, DigRF, and LLI. With the generic API, “link_up”, you do not need to understand the protocol-specific process. You just need to use the generic API and initiate the data transfer.

Refer to the following figure:

When link_up API is used, the API takes care of the protocol specific intricacies involved to bring up the connection between the protocol stack, underlying PHY (M-PHY in this case), and the adjoining M-PHY.

So, in a nutshell, the M-PHY generic APIs make the test cases easy to create and reuse for all the protocol stacks using M-PHY, which in turn yields high return and low maintenance test suite.

Generic PA Layer

During a comprehensive study of how M-PHY and D-PHY layers interact with the protocol stacks, we found that the last layer (the protocol physical adapter layer) in all the protocol stacks that interacts to M-PHY and D-PHY via parallel interface is almost similar.

Could that be an opportunity to create another solution for a robust M-PHY and D-PHY verification without having to understand protocol stacks?

Can this protocol physical adaptor layer (PA layer) be extracted to provide a comprehensive PHY verification VIP?

Yes… probably and it definitely worked as a prototype!

Now the team is working on productizing the solution and, going forward, plans to map the first solution (generic APIs) with the second solution (generic PA layer) to provide the perfect solution for a robust and reliable M-PHY and D-PHY verification that will not require a thorough understanding of the protocol stacks. Refer to the following figure:

CONCLUSION

This article describes various techniques and solutions for the PHY verification which are based on our study of the MIPI M-PHY and D-PHY. These techniques can be used in your M-PHY and D-PHY/C-PHY DUT verification process to save time and improve the quality of results, increasing confidence. This PA layer VIP will eliminate all the issue those are faced by the PHY verification engineers. The PA layer VIP would be highly configurable verification IP, which can be used in any SV UVM environment.

These techniques can be make generic to support the multiple PHY’s being used with different protocols like PCIe, USB and SATA depending upon the feasibility and requirement.

REFERENCES

1. MIPI Alliance (www.mipi.org)
2. MIPI Alliance Specification for D-PHY, version 1.2
3. MIPI Alliance Specification for M-PHY, version 3.1
4. For more information about MIPI Alliance’s physical layer specifications, please visit http://www.mipi.org/specifications/physical-layer