How to Verify MIPI Protocols

At the recent MIPI DevCon, Cadence's Ofir Michaeli gave two presentations on verification. The first was Effective Vertification of Stacked and Layered Protocols. Then he was back later in the day to cover Using MIPI Conformance Test Suites for Pre-Siicon Verification. I believe that for this second presentation, he was standing in for Moshik Rubin.

Verification of Layered Protocols

The above diagram shows how the MIPI specifications fit together. At the top are the various interfaces out to the world, such as the almost universal CSI-2 camera interface. One feature most interfaces have in common is that they are layered, with application-level protocols, then a transport-level protocol, down to the M-PHY physical layer.

I'm not going to go into all these protocols in detail, but the above diagram gives a high-level view of UFS. This stands for Universal Flash Storage and does what you would expect: it provides a low-power flash interface for use in mobile systems such as smartphones and tablets. This shows the hierarchy of the protocols from the UFS command set layer all the way down to UniPro and MPHY at the bottom.

So what is the best strategy for verifying something like this? The first recommendation is not to start from scratch. Get some verification IP (VIP) as a starting point. VIP helps by:

• Checking protocol compliance to the specification
• Providing a full coverage model
• Generating and driving test sequences
• Providing flexibility and configurability with different capability settings
• Being independent of the DUT (since you didn't develop it)
• Being reliable: When considering "make vs buy", don't forget that VIP has many years of development and has been reused across many designs

So how do you do verification? Firstly, start as early as possible. A verification plan should start from the specification and map each line in the specification into one or more verification items. If that sounds like a lot of work, it is. A little rule of thumb is that anywhere the description says "shall", there is something that needs to be tested (does anyone say "shall" except people writing standards?). But ignoring something seemingly unimportant risks something not being tested and escaping. As this expands into test cases, the complexity can explode. For example, the PA Hibernate description is three pages (just a few paragraphs are above), 32 test scenarios, and thousands of test cases.

The next bit of advice is to use a passive agent. You need both an active master agent and a passive slave agent. The active agent behaves as the actual hardware should. For example, it will generate protocol traffic just like real hardware. If bad packets are seen, they will be handled like in the real world (probably just dropped). Meanwhile, the passive agent just listens, and never sends any traffic. But it can check if the protocol is handled correctly, and it can log unusual events such as bad packets.

You need to invest in tools. Since Cadence sells tools, you'd expect us to say that, but there is a lot of evidence that the amount invested in tools for verification is out of step with the amount of time spent on it. Instead of investing in time and headcount, invest in tools so you don't need so much of either. Debug tools, VIP, coverage analysis tools—these can all make a huge difference in the effectiveness of any verification team.

Using MIPI Conformance Suites for Verification

Once you have designed your interface and tested it, you need to worry about compliance:

• Products must pass conformance testing to be on the integrators list
• How do I know all the spec-related scenarios have been covered?
• How do we create tests to cover all those scenarios?
• After running the tests, some areas still aren't covered, how do I fill the holes?
• Aargh. The spec changed. How do I apply the change while ensuring nothing got broken?

A MIPI Conformance Test Suite (CTS) is a list of tests that complement the specification and enable measurement of conformance. It is used for interoparability testing at an official lab post-silicon. It covers all specifications in the main flows. However, it is not a comprehensive verification plan. Of course post-silicon compliance testing is too late to discover problems, pre-silicon is where we need to identify (and correct) problems.

The four steps to compliance are captured in the loop below:

For example, here is a line from the MIPI D-PHY CTS:

That allows to use the CTS to define completeness criteria:

Don't expect the CTS to do everything for you. CTS are aimed at post-silicon inter-operability testing, not pre-silicon verification. However, CTS can be leveraged for pre-silicon by using each CTS scenario for the four steps in the loop above.

1. Completeness criteria: executable and measurable
2. Self-checking logic: based on the expected results of the CTS test
3. Intelligent stimuli generator: to cover all relevant CTS scenarios
4. Report status of completeness: to show clear view of progress for each CTS test
5. Rinse and repeat

And when done, a new Step 5: Award yourself a beer.

New VIP Solutions

Earlier this week, Cadence announced ten new VIP solutions. Two MIPI interfaces:

• MIPI DSI-2—For a high-speed, low-power-consumption interface between a peripheral and a host for consumer applications.
• CSI 2 2.0—For a high-speed, robust, scalable, low-power and cost-effective camera interface that supports a wide range of imaging for mobile applications.

The other nine interfaces are not MIPI standards, but other standards, although some, like UFS and USB Type-C are of importance in mobile:

• Ethernet 400G—The highest performance Ethernet standard critical for enterprise networking to support the increasing bandwidth needs of video on demand, cloud computing, and big data applications.
• Ethernet TSN—A new set of specifications ideal for low-latency applications, such as real-time audio/video streaming, that require time-sensitive communication necessary in automotive and industrial automation. Cadence will be the first in the industry to support this specification.
• SPI NAND and Octal SPI—Critical new memory protocols for automotive and industrial applications that provide higher density performance with the same footprint as previous generations.
• UFS 2.1—Improves data security through the use of inline cryptography between the SoC and UFS Storage device.
• USB Type-C—Enables power delivery, alternate modes, and high-speed data over a single connector for consumer and mobile applications.
• DisplayPort (1.3, 1.4) and Embedded DisplayPort (eDP 1.4a, 1.4b)—For 8K resolution and scaling at reduced power envelopes for consumer and mobile applications.
• Display Stream Compression (DSC)—Enables real-time, visually lossless image compression for consumer and mobile applications.

Next: GLOBALFOUNDRIES' Dual Roadmap

Previous: MemCon 2016: Storage Class Memory