Advertisement

Blog

MIPI Creates the I3C Sensor Interface

I recently spoke to Ken Foust from Intel regarding his being the chair of the MIPI Sensor Working Group and the important standards work they are doing there. I also had a conversation with Peter Lefkin, the Managing Director of the MIPI Alliance about I3C.

Foust had worked closely with the MEMS Industry Group (MIG) to survey that industry regarding their thoughts on sensor interface and problems they are having in that area. Companies such as Intel, Qualcom, NXP and TI gave their valuable comments and all of them had the same “pain” points.

Lefkin said that they wanted a new interface for sensors that would be backwards compatible with I2C and SPI buses. “Mobile” products were the main concern. These are automobile communications, wearables, smartphones, tablets and touchscreens and the like. See Figure 1.

Figure 1

MIPI interfaces are used in mobile platforms. The red arrow and circle in the diagram refers to the fact that MIPI Sensor Interface Naming is under final development. (Image courtesy of MIPI Alliance)

MIPI interfaces are used in mobile platforms. The red arrow and circle in the diagram refers to the fact that MIPI Sensor Interface Naming is under final development. (Image courtesy of MIPI Alliance)

The I3C interface was conceived as a possible solution, but there were “pain” points associated with that concept as well. Power and cost were a concern with existing interfaces and would be a problem here too since I3C is conceived as a combination of I2C and SPI . Buffering would need to be built in as well as the capability of storing data while the processor sleeps. I2C is fast and handles this by waking up and goes back to sleep when done, but I2C and SPI are typically best used for clearing large FIFOs and not optimum for sensors. Increased bandwidth was also needed beyond the I2C 400kHz/1MHz going up to 10 to 30 MHz.

Regarding cost, the sensor would be typically off on its own and then get an interrupt on the GPIO with the way today’s Apps Processors function—so more pins are required. Pin requirements are important since high tier mobile SoCs have 10 to 20 I/Os. Most sensors using I2C require one or more interrupts; SPI requires an interrupt and a chip select; some sensors require a dedicated “sleep” signal. See Figure 2.

Figure 2

Too many I/Os and fragmented interfaces are a problem with today's solutions. (Image courtesy of MIPI Alliance)

Too many I/Os and fragmented interfaces are a problem with today’s solutions. (Image courtesy of MIPI Alliance)

Figure 3

This diagram shows what the MEMS industry wants/needs. (Image courtesy of MIPI Alliance)

This diagram shows what the MEMS industry wants/needs. (Image courtesy of MIPI Alliance)

So the MIPI Group is off with the following goals in mind by 1Q2015:

Define a standardized Sensor Interface

  • Consistent within the scope of the MIPI Alliance
    1. Enable device interface compatibility between MIPI member companies
  • Strive to re-use an existing industry interface (in whole or in part)
  • Flexible and able to evolve
    1. Provide value to adopters and focus on Sensor Vendors
    2. Anticipate future architectures for mobile and complimentary industry needs
    3. Unify a fragmented interface industry, in and out of mobile
  • Interface features focus on:
    1. Low cost implementation on the sensor side (< 2000 gates)
    2. Reduced signal count interface
    3. In-band interrupts
    4. In-band command codes
    5. Reduced interface power consumption – support push/pull IO
    6. Reconfigurable systems – support dynamic addressing
    7. Increased bandwidth > 10Mbps – Newer Requirement
    • Implemented via supported HDR (High Data Rate) Modes
    • Data, transcoded ternary symbols for example, transmitted on rising and falling SCL/SDA

Let’s keep an eye on this development because it will be critical to the hopeful ramping up of billions of sensors in the IoT going forward in a cost–effective and expedient way.

13 comments on “MIPI Creates the I3C Sensor Interface

  1. goafrit2
    January 1, 2015

    Great vision and my only recommendation is that they make it open. I understand the value of IP but the inability to get USB port into Android devices because of Intel patents make some of us that use Android have a feeling that we are not getting full value from the devices. So let them work on interface and make it possible to cross-license and use.

  2. goafrit2
    January 1, 2015

    >> Let's keep an eye on this development because it will be critical to the hopeful ramping up of billions of sensors in the IoT going forward in a cost–effective and expedient way.

    Absolutely, the IoT world is at the phase where we need a Working Group to help define and structure standards. The sector will get into paralysis if we do not have interoperability. Any interface or standard that can make that possible will be helpful in the community

  3. Victor Lorenzo
    January 2, 2015

    Lefkin said that they wanted a new interface for sensors that would be backwards compatible with I2C and SPI buses.

    With the exception of audio ports, LCD and camera devices, almost all sensors in mobile devices require very low data bandwidth, perfectly achievable with low cost I2C and SPI interfaces. For extremely high data bandwidths a pair of LVDS SER/DES ports can be more than enough.

    At present almost all SoCs include at least one SPI and at least one I2C interface so almost any sensor using one of those interfaces can be integrated with relative easy. In fact, there are plenty of hardware debugging tools for those interfaces so we don't need to waste a lot of time for firmware/hardware debugging and troubleshooting.

    Perhaps the real goal should be in creating standardized logical interfaces and command sets, some sort of plug-n-play capability. That backward compatibility, from my hardware designer and firmware programmer point of view, will simply add more cost at silicon and software level, and at the end we will only use the new one or the old one.

  4. goafrit2
    January 2, 2015

    >> Perhaps the real goal should be in creating standardized logical interfaces and command sets, some sort of plug-n-play capability.

    Standardization that does not take into consideration backward compatibility may have probems of wide acceptability. Understand that companies have products in the market and it may not be smart for them to give them up because there is a new standard. Sure, there is cost associated as well as the software issues you noted, but making this backward compatitble may be a good roadmap

  5. fasmicro
    January 2, 2015

    Good point – the devil is the software. People do not give hardware designers a lot of credit. We are code and write software but the type that makes signals change. It could be more challenging than anything out there.

  6. Victor Lorenzo
    January 3, 2015

    @fasmicro >> “People do not give hardware designers a lot of credit.

    In the vast majority of general public products electronic and electromechanic hardware parts are kept hidden under fancy and/or ergonomic designs. People see the “function” of the device and judges all the work according to that. The software guys use to take all credit when the product succeeds in the marked.

    On the projects managing side, I've seen too many managers thinking in terms that hardware design is limited to gather and put together a few good app notes and reference designs.

    From my personal experience I could say that taking someone with no electronics background or instruction, even in the case of a person who knows all Protel/Altium SCH/PCB shortcuts and commands, for creating a product's hardware from a few reference designs is a huge mistake. You will definitely end up creating new and new and new revisions over and over to correct an infinite number of errors.

    We need good firmware and application programmers, but, simply put in plain text, having good and experienced hardware designers is also must.

  7. kiranvalentine
    January 6, 2015

    good website and be lated happy new year every one

  8. fasmicro
    January 6, 2015

    >> We need good firmware and application programmers, but, simply put in plain text, having good and experienced hardware designers is also must

    I agree on that. It is easier to find help on software than to do for hardware. Hardware takes experience because you have to precisely control signals. That may not always be necessary for software where brute force strategy can work.

  9. Victor Lorenzo
    January 6, 2015

    @fasmicro >> “That may not always be necessary for software where brute force strategy can work

    The point was, combined with your comment ;-), that at the end, when managers decline recruiting experienced hardware designers for reducing cost, unexperienced designers use “brute force” methods for hardware design too. That almost definitely leads to a very low quality product.

    But brute forcing in hardware can be ssssssslightly different from its software similar…. I especially like this sequence of events:

    1) ..it consumes a little more power than expected, but not too much, I think…

    2) ..it is getting warm, but it should be normal. Is not it?

    3) …ups!! Where did that smoke come from?

    For some different reasons, but that hapened to an ex-colleague with a RF power amplifier… seems like the prototype liked more being an uncontrolled oscillator than an amplifier… well, as usual.

  10. nasimson
    January 7, 2015

    @fasmicro:

    >  It is easier to find help on software than to do for hardware. Hardware
    > takes experience because you have to precisely control signals.

    Despite hardware being a much older science, software engineering is much easier & wider-spread discipline. It seems that hardware sciences are approaching physical limits of nano and pico lengths while software has still a long way to go. 

  11. nasimson
    January 7, 2015

    @fasmicro:

    >  the devil is the software. People do not give hardware designers a lot of credit.

    People see the last item on the top of stack. Hardware gets hidden by firmware; firmware gets eclipsed by OS; OS gets eclipsed by Apps. Its the apps that users get to see, use and appreciate. So developers of apps get more credit than OS and hardware designers.

  12. goafrit2
    January 10, 2015

    >> So developers of apps get more credit than OS and hardware designers.

    Excellent comment. It is not just the users – the investors, VCs etc see it the same way. It is hard to get a valuation for hardware companies in billions of dollars but software/apps startups do that easily. Maybe hardware designers are not fashionable!

  13. samicksha
    January 13, 2015

    certainly yes developers will play key role here, but as MIPI comments, We set out to develop an interface that is evolutionary, not revolutionary, and that advances I2C and SPI,

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.