MIPI Alliance Overview

Mobile Platform Architectures using MIPI® Standards Rick Wietfeldt, Ph.D. Sr. Director, Advanced Connectivity Technology Qualcomm Brian Carlson OMAP Product Line Manager Texas Instruments

Next Generation Mobile Device Platform Architectures IWPC Workshop, San Jose, CA June 20-22, 2011 1 Copyright © © 2010 2010 MIPI MIPI Alliance. Alliance. All All rights rights reserved. reserved. Copyright

Legal Disclaimer

The material contained herein is not a license, either expressly or impliedly, to any IPR owned or controlled by any of the authors or developers of this material or MIPI. The material contained herein is provided on an “AS IS” basis and to the maximum extent permitted by applicable law, this material is provided AS IS AND WITH ALL FAULTS, and the authors and developers of this material and MIPI hereby disclaim all other warranties and conditions, either express, implied or statutory, including, but not limited to, any (if any) implied warranties, duties or conditions of merchantability, of fitness for a particular purpose, of accuracy or completeness of responses, of results, of workmanlike effort, of lack of viruses, and of lack of negligence. ALSO, THERE IS NO WARRANTY OR CONDITION OF TITLE, QUIET ENJOYMENT, QUIET POSSESSION, CORRESPONDENCE TO DESCRIPTION OR NON-INFRINGEMENT WITH REGARD TO THIS MATERIAL. All materials contained herein are protected by copyright laws, and may not be reproduced, republished, distributed, transmitted, displayed, broadcast or otherwise exploited in any manner without the express prior written permission of MIPI Alliance. MIPI, MIPI Alliance and the dotted rainbow arch and all related trademarks, tradenames, and other intellectual property are the exclusive property of MIPI Alliance and cannot be used without its express prior written permission. IN NO EVENT WILL ANY AUTHOR OR DEVELOPER OF THIS MATERIAL OR MIPI BE LIABLE TO ANY OTHER PARTY FOR THE COST OF PROCURING SUBSTITUTE GOODS OR SERVICES, LOST PROFITS, LOSS OF USE, LOSS OF DATA, OR ANY INCIDENTAL, CONSEQUENTIAL, DIRECT, INDIRECT, OR SPECIAL DAMAGES WHETHER UNDER CONTRACT, TORT, WARRANTY, OR OTHERWISE, ARISING IN ANY WAY OUT OF THIS OR ANY OTHER AGREEMENT RELATING TO THIS MATERIAL, WHETHER OR NOT SUCH PARTY HAD ADVANCE NOTICE OF THE POSSIBILITY OF SUCH DAMAGES.

2 Copyright © 2010 MIPI Alliance. All rights reserved.

Agenda • Introduction (Brian Carlson, TI) • MIPI Alliance and its Mission • MIPI Growth and Market Acceptance

• Technical (Rick Wietfeldt, Qualcomm) • MIPI Objectives • MIPI System Block Diagram • MIPI Working Groups and Interfaces • RFFE Overview

• Q&A


Introduction • MIPI Alliance and its Mission • MIPI Growth and Market Acceptance


MIPI Alliance and its Mission • MIPI Alliance is a global, non-profit corporation that operates as an open membership organization. • The mission of MIPI Alliance is to benefit the entire mobile industry by establishing standards for hardware and software interfaces in mobile devices. • Today, over 200 member companies actively participate in the Alliance, developing interface specifications which drive consistency in processor and peripheral interfaces, promoting reuse and compatibility in mobile devices.


MIPI Growth and Market Acceptance A recent research report from IPNest offers insight into the rate of adoption for MIPI specs. •

700M MIPI-powered I.C.’s will be in production in 2010, with projected 6.2B by 2015.

•

MIPI specs claimed a 20% penetration in smartphones in 2009 and will reach 100% by 2013.

•

MIPI specification penetration in other phones will grow from 5% in 2009 to 90% in 2015.


Technical • MIPI Objectives • MIPI System Block Diagram • MIPI Working Groups and Interfaces • RFFE Overview


MIPI Objectives • Amongst ecosystem peers, define a set of standardized chip-to-chip interfaces that meet the requirements of the mobile industry, across the full range of functions within the mobile terminal. • AP/BB (HSI, LLI), AP/PMIC (SPMI), PMIC/Battery (BIF), etc.

Notes: • MIPI should eliminate proprietary, legacy, oftentimes pointto-point or parallel interfaces that hurt interoperability, pin count, power, etc. • MIPI interfaces are chip-to-chip, i.e. “inside the device”, not external interfaces such as AP to TV. 8 Copyright © 2010 MIPI Alliance. All rights reserved.

MIPI System Block Diagram Interface BIF

Battery

CSI

Camera

DigRF

BB/RFIC

Debug

Trace & Debug

DSI

Display

LLI

AP/BB

PHY

D-PHY & M-PHY

RFFE

RF Front End

SLIMbus

Audio

SPMI

AP/BB/PMIC

UniPort

AP/Aux-chip (=UniPro/M-PHY)


MIPI Working Groups & Interfaces Develop: MIPI Technology Roadmap

Working Group

Typical Use

BIF

Battery Interface

PMIC and Battery

CSI

Camera Serial Interface

AP to Camera sensor

DigRF

Digital RF (BB/RFIC)

Baseband to RFIC (Transceiver)

Debug

Trace & Debug

AP/Baseband to external Test Equip

DSI

Display Serial Interface

AP to Display (internal)

LLI

Low Latency Interface

Baseband to AP

PHY

Physical Layer

D-PHY (~1Gbps) and M-PHY (~1.25, 2.5, 5 Gbps)

RFFE

RF Front End

Baseband/RFIC to FE components

SLIMbus

Serial Low-power Inter-chip Media bus

AP/Baseband to Audio components

SPMI

System Power Mgmt Interface

PMIC to AP/Baseband

UniPro

Unified Protocol

Protocol above M-PHY for UFS, CSI-3, DSI-2, etc.

Copyright © 2010 MIPI Alliance. All rights reserved.

10

RF Front-End Control Working Group (from mipi.org) RF Front-End Control (RFFE) was established as a working group in October 2008. The scope is to define a control interface solution for RF front end modules and components. The distinction to DigRF is that whereas DigRF covers the RF IC - BB IC interface, RFFE will cover the control interface from the RF IC to the various front-end modules, i.e. power amplifiers, low noise amplifiers, filters, switches, DC/DC-converters and antennas. The complexity of the RF front-end is increasing. More and more systems and frequency bands must be supported. Eventually the amount of control performed via dedicated control signals has reached such levels (tens of dedicated signals) that a control bus has become a desired solution. A multitude of the front-end components currently and even in future will be based on relatively wide geometry silicon processes. A low complexity solution is essential with such prerequisites. Another key requirement is low EMI as the control solution will operate in a very EMI susceptible environment where tiny disturbances can destroy the RF performance and make the solution useless. RFFE will look into existing simple control solutions (i.e. outcome from MIPI working groups LML and SPMI as well as other possible options) and re-use existing technology. Emphasis will be put on quest for simplicity and EMI robustness, both as source and victim. Signal paths in the RF front end are left out of the scope being currently analog signals. Co-operation with DigRF is needed since RFFE commands might be tunneled over DigRF in some RF control architectures. Copyright © 2010 MIPI Alliance. All rights reserved.

11

MIPI RFFE Specification Overview The RFFE Specification handles time-critical information of all RF Front-End components typical to mobile terminal applications  Low pin count (3): Data, Clock, VIO  Master sources Clock; Data is bidirectional (R/W)  Up to 26 MHz clock operation  VIO available as asynchronous slave reset

 Multi-drop and scalable  1 master, up to 15 slaves per master

 Compact implementation:  Master ~5Kgates; Slave ~0.5Kgates

 Low RF EMI from the bus

 Single and multi-byte R/W commands.  Broadcast messages to multiple slaves.  User defined group ID’s for write commands.  Supports command initiated soft reset.  Based on SPMI, but simplified for FE devices, e.g. removed Multi-Master (and bus arbitration) capability.

 Low latency (