Cadence's History with MIPI

I talked last week to Kevin Yee, Sachin Dhingra, and Moshik Rubin about the history of MIPI, Cadence's involvement with MIPI, and the upcoming MIPI DevCon that will take place on September 14 and 15 at the Computer History Museum in Mountain View. Steve Brown has already written MIPI DevCon 2016 – Mobile and Beyond about Cadence's involvement in MIPI DevCon, so I won't repeat all the same information here.

MIPI History

Kevin told me that he has been involved with MIPI for about 10 years, at other companies, and now at Cadence. Since MIPI only started in 2003, he has been involved for a lot of its life. He is also involved with several of the working groups such as SoundWire and display. But more importantly, he is co-chair of the marketing steering group that sets the direction that MIPI is going.

Given that lead-in, the obvious question to ask was, "So what is the direction that MIPI is going in?"

Kevin told me that the original charter was mobile. They created a family of specifications designed to work together for the mobile market, basically in phone handsets (or terminals, in the jargon). They developed about 20 different specifications. They want to continue to focus on mobile, in particular as we move from 4G to 5G, to make sure that any standards that need updating are addressed. But they are now going into other markets, what MIPI calls "beyond mobile." In particular, this means automotive, IoT, and industrial. For example, CSI-2, the camera interface, is the standard interface used in cars for ADAS and the transition to autonomous driving. IoT devices with cameras also typically use that interface, but they also use SoundWire for audio and the display interface. There is a new spec, I3C (a follow-up to the ubiquitous I2C originally developed by Philips for use in televisions) for sensors. This is expected to be important in IoT, industrial, medical, and more.

So these days, MIPI's focus is still mobile, but also to keep an eye on these other markets to ensure the standards address them, too. For example, SoundWire is looking at extended lengths for speakers and microphones in environments other than mobile (smartphones are not very big, so they don't need to support long distances; cars are much bigger, obviously).

In the past, MIPI has been a relatively private organization, with the specs only readily available to contributing and adopting members. There have historically been three face-to-face meetings each year (Europe, US, Asia). Usually one of them has a demo day showing products developed with MIPI. For the "beyond mobile" part of the market this has led to holding the first MIPI developers conference. They were starting to get a lot of questions from non-member companies and even from other divisions of companies that didn't even realize they were already members.

MIPI Design IP

I asked Sachin to tell me a bit of the history of how we build up our portfolio of verification and design IP for MIPI standards.

He told me we have been involved on the verification IP (VIP) side since the beginning. We then acquired a DPHY and MPHY with the acquisition of Cosmic, along with a front-end radio controller. Evatronics had the Slimbus audio interface that morphed into SoundWire, where we are the IP market leaders. We needed a controller for the DPHY, so we licensed one. We built up the camera interface internally and productized it.

We are now focusing on MIPI in automotive; in particular, the camera interface is almost universally popular in automotive. We are on several working groups that are important in automotive, such as camera, display, and audio. The camera interface is being extended with some specific requirements for automotive for ADAS with multiple cameras.

MIPI VIP

I asked Moshik to give me the story of Cadence's VIP for MIPI standards. He told me that we became a contributing member in 2007 when MIPI started to take off. Initially we were passive and didn't really get involved in the specification itself. At some level, creating verification IP (VIP), we don't care about whatever the standard turns out to be, we implement.

But we started to take an active role in the different working groups for the various protocols, especially on the VIP side. We have a unique angle since the verification guys are the people who decide whether a particular action is "in spec" or not. So once you put VIP experts on the group that defines the spec, then the spec becomes clearer and better defined, since verification engineers are constantly thinking about how they would verify different aspects of the protocol. We have been heavily involved in UniPro, CSI-2, and SoundWire. We see the fruits not just in clearer standards but when customers come to us and ask about whether or not something is the spec's intention, and we can say "yes, that's exactly how our VIP is built."

MIPI tries to address all the different aspects of mobile devices (and now 'beyond mobile"). The goal was to standardize everything in smartphones/tablets. There needs to be a broad ROI for users to follow the standard. Sometimes there is already a de facto standard and so, even if the new standard is good, it may not make sense to switch. Cadence always has question marks about whether to invest or wait-and-see. On the MIPI side we took the decision to go with them and start to develop VIP early and assume it will take over at some point. Sometimes adoption is fast, and sometimes the VIP sits on the shelf for a time since adoption is slow. For example, the CSI-3 camera standard has not been adopted aggressively since the CSI-2 standard was good enough and provided the capabilities required.

On the VIP side at MIPI DevCon, we have three papers since our team members are the experts on VIP for MIPI. One will talk about I2C and I3C. Our expert on UniPro will talk about verifying complex protocols, ensuring that one implementation works with other implementations. Moshik said that he was going to talk about how to use pre-silicon scenarios to check compliance (post-silicon is a bit too late to discover you have a major compliance problem!).

On the exhibit floor we picked one protocol, CSI-2, and will use it to show the different vehicles and how you would use them in practice if you were developing an interface. We have the TripleCheck compliance suite that tests all corner cases, injects errors, etc. There is a detailed functional coverage and verification plan that lets the user look from day one and see what the verification objectives are and see progress.

One the first day, you bring up the TripleCheck verification plan, and then can watch progress through the entire effort as the tests are run successfully. And when something fails, we have the CSI-2 protocol debugger. Typically, the designer of an SoC is not an expert on every protocol used (there may be a dozen), so it is hard to find the root cause (a bug in the design, deadlock, a configuration issue, it could be lots of things). Cadence has a protocol debugger GUI that visualizes the channels, state-machines, warnings, and errors. You can go back and forth it time and see the problem clearly until you nail down the cause.

The Cadence MIPI portfolio contains VIP for CSI-2/3, DSI, SLIMbus, DigRF, D-PHY, M-PHY, C-PHY, UniPro, LLI, and SoundWire. Collect the whole set.

MIPI DevCon

The four papers that Cadence plans to present during MIPI DevCon are:

• I3C High Data Rate Modes—From Spec to Real-Life Devices – Alex Passi, Senior Principal Software Engineer, Wednesday, September 14, Track 2, 11:15am
• CSI-2 Application for Vision and Sensor Fusion Systems – Richard Sproul, Senior Principal Design Engineer, Wednesday, September 14, Track 2, 2:30pm
• Effective Verification of Stacked and Layered Protocols – Ofir Michaeli, Software Engineering Manager, Thursday, September 15, Track 3, 11:15am
• Using MIPI Alliance Conformance Test Suites in Multi-Layer Pre-Silicon Verification – Moshik Rubin, Product Marketing Group Director, September 15, Track 4, 4:30pm

You can also preview the detailed agenda for all of MIPI DevCon.

Next:Facebook's Aquila Flies...and OpenCellular

Previous: SiFive: a RISC-V Fabless Semiconductor Company