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 toolsthese 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-2For a high-speed, low-power-consumption interface between a peripheral

and a host for consumer applications.
CSI 2 2.0For 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 400GThe 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 TSNA 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 SPICritical new memory protocols for automotive and industrial
applications that provide higher density performance with the same footprint as previous
generations.
UFS 2.1Improves data security through the use of inline cryptography between the
SoC and UFS Storage device.
USB Type-CEnables 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