Get email delivery of the Cadence blog featured here
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.
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:
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.
Once you have designed your interface and tested it, you need to worry about compliance:
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.
And when done, a new Step 5: Award yourself a beer.
Earlier this week, Cadence announced ten new VIP solutions. Two MIPI interfaces:
The other nine interfaces are not MIPI standards, but other standards, although some, like UFS and USB Type-C are of importance in mobile:
Next: GLOBALFOUNDRIES' Dual Roadmap
Previous: MemCon 2016: Storage Class Memory