MIPI RFFE is the specification of a bus interface specifically tailored for the needs of current and future mobile wireless systems to control the slave devices in an RF front-end. This article gives an overview of MIPI RFFE Version 1.0 and discusses the desires and rationale behind the development of RFFE, including a survey of existing alternatives.
Mobile phone RF systems have become increasingly complex and will benefit from a single control interface solution.
Need for Unification in Mobile Radio Platforms
During the last decade, the number of mobile phones has grown rapidly, with 1.4 billion devices shipped in 2010, and with no saturation of demand in sight. Over that same time, the complexity has evolved from voice-only 2G devices, then to 3G and, most recently, 4G multi-functional smartphones. In addition, cellular communication complexity has increased with connectivity for Wi-Fi, Bluetooth, GPS, FM radio, and other capabilities.
The addition of these wireless standards creates a need for multi-radio solutions which cover ten or more frequency bands. As a result, the number of devices required for RF front-ends has also increased. For phone manufacturers, the complexities of control for all these devices becomes an ever-mounting challenge.
The MIPI Alliance Specification for RF Front-End Control Interface (RFFE) seeks to address this challenge by providing a bus interface connecting the transceiver, or radio, to the myriad of RF front-end devices such as LNAs, PAs, antenna switches, antenna tuners, DC/DC converters, filters, sensors, and the like. These devices may be controlled by an RFIC, or, alternately, some other source. This commentary provides a brief overview of the features of the RFFE spec which makes It uniquely suitable for the tasks presented by this burgeoning environment.
I would like to add that you also can find information about MIPI as an IP product, in a market survey just completed by IPnest on our website: www.ip-nest.com. This includes a forecast of the MIPI IP business for 2010-2015, the license prices for PHY and Controller IP, the main IP vendors etc... FYI, one of the first customer was Intel.
Or you can attend to IP-SoC in Grenoble (France) on Nov30-Dec1, see:
Excellent post Mr. Boyce. As a MIPI Alliance board member, I wanted to let you know that we are seeing tremendous momentum, both in our membership and interest in our organization - even outside the mobile space. We just reached 200 member companies, including most major semiconductor companies and major mobile OEMs, along with a large ecosystem from IP to test equipment vendors. I wanted to invite others that are interested to checkout our new website at www.mipi.org and the many new resources we have added to learn more (YouTube, LinkedIn, Twitter...). Look for more of these types of articles and news as we continue to grow and improve our industry relations.
I agree that this type of article is useful. I did the same thing for the MIPI SLIMbus specification, publishing it in Portable Design magazine (now out of business). But that article can be found on National Semiconductor's website, and other locations via a web search.
Even though MIPI specs are available only to MIPI members, it is necessary for the engineering community to generally know what these specs could possible do for their designs, and that knowledge could speed up the adoption of the standards as well as possibly broaden application of it. It may also induce companies to join the MIPI Alliance.
In late August, the MIPI Alliance announced its new spec for RF front-end control. (http://www.eetimes.com/discussion/other/4206515/Simplifying-control-in-the-RF-front-end) I asked them to elaborate in an article because there seemed to be some questions out there. Happily, Victor Wilkerson and Gernot Hueber agreed, and this article is now posted for you.
Join our online Radio Show on Friday 11th July starting at 2:00pm Eastern, when EETimes editor of all things fun and interesting, Max Maxfield, and embedded systems expert, Jack Ganssle, will debate as to just what is, and is not, and embedded system.