Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

MIPI DevCon 2016: MIPI RFFE - Challenging the WiFi/Bluetooth Status Quo by Unifying eFEM Control

581 views

Published on

Expecting the drive for an SoC solution optimized for both form factor, pin count, and routing complexity will push eFEM vendors in a new direction, Intel's John Oakley describes using the MIPI RFFE serial communication interface to control multiple RF components for Wi-Fi/Bluetooth-enabled products.

Since the serial communication adds an overhead time for each configuration, the suggested Master-Slave mapping helps minimize the number of telegrams for SISO, MIMO and Concurrent Dual Band (CDB) cases, while complying with the MIPI RFFE Specification.

Published in: Mobile
  • Be the first to comment

  • Be the first to like this

MIPI DevCon 2016: MIPI RFFE - Challenging the WiFi/Bluetooth Status Quo by Unifying eFEM Control

  1. 1. RFFE: Challenging the WiFi/Bluetooth Status Quo by Unifying eFEM Control John Oakley Intel Corporation
  2. 2. Abstract •  Today’s high-end wireless marketplace, where users seek high data rates and increased Wi- Fi performance, requires challenging the status quo: the control scheme dominated by discrete control signaling used by eFEMs targeting the Wi-Fi/Bluetooth technology segment. •  Expecting that the drive for an SoC solution optimized for both form factor, pin count, and routing complexity will push eFEM vendors in a new direction, this presentation describes use of the MIPI RFFE serial communication interface to control multiple RF components for Wi-Fi/Bluetooth-enabled products. •  Since the serial communication adds an overhead time for each configuration, the suggested Master-Slave mapping helps minimize the number of telegrams for SISO, MIMO and Concurrent Dual Band (CDB) cases, while complying with the MIPI RFFE Specification. •  MIPI RFFE is a well adopted specification, developed by the MIPI Alliance, to offer a common, widespread method for controlling RF Front-End designs. The MIPI Alliance determined that the majority of today’s RF communication standards are proprietary or de- facto and are not utilized industry-wide, and developed the MIPI RFFE specification in order to establish a single standard for eFEM communication, from the PHY level to the protocol and software levels. 2
  3. 3. Introduction •  The pursuit of high data rates and increased performance for WiFi forces strict requirements on both TX and RX in order to compete in the high end market segment. Current trend is to suggest proliferations that incorporates external Front End (eFEM) components, in order to achieve those high-end requirements. •  The eFEM controls use discrete logic GPIOs, and with the increase in external units, multi-band support and functionality, we result in an increase in package pinout as well as complexity on the routing, affecting the cost and Form Factor (FF). •  This presentation summarizes a method for using MIPI RFFE serial communication interface to control external/peripheral RF components for WiFi (up to 2x2 dual-band) and BT products. 3
  4. 4. Example 2x2 WiFi/BT Front End •  For example, 2x2 WiFi/BT solutions implement 13 discrete control pins and 4 analog pins, for supporting up to 4 eFEMs, two WiFi Low Band (LB) and BT, and two for WiFi High Band (HB). 4
  5. 5. Improved Example 2x2 Front End • An example front using MIPI RFFE connections, reducing the connections to the SOC to 3 wires. 5
  6. 6. Today’s WiFi/BT front end •  Today the eFEMs are controlled by discrete signaling. eFEM vendors have consolidated common configurations for different eFEM system modes. The figure below illustrates example eFEM modules for LB and HB. The table below details the control configuration commonly used on LB and HB eFEMs, showing all system modes for LB and for HB. 6
  7. 7. Suggested WiFi/BT System Modes •  To unify the control of the front end devices, it is helpful to identify the system modes. The table below shows nine typical system modes for a 2x2 system. •  An example of how these system modes are configured via RFFE control registers. •  The enable/disable can be done with a single broadcast RFFE write to Reg1. •  The mode switch can be done with a single broadcast RFFE write to Reg0. 7
  8. 8. Simplified Control Interface •  Using the Reg0 and Reg1, the control of the WiFi/BT front end can be quickly and easily updated for the given use case. 8 •  Keeping the control simple minimizes necessary the firmware support. •  Adapting for front end differences does not change control procedure. •  For example, a 2x2 front end could expanded to a 3x3 front end minimal firmware changes.
  9. 9. RFFE Implementation Advantages •  Using a standard like MIPI RFFE allows for a reduced pin count of the Connectivity SOC device. •  Today’s products are growing in complexity in features and interconnect, RFFE allows this interconnect complexity to be managed and controlled. •  Carefully specifying the various devices allows for broadcast writes with minimal latency and firmware overhead. •  With a GPO based approach, each device is typically independently controlled. •  With a RFFE based approach, there is a common control interface and common mechanisms. eFEMs can be controlled simultaneously. •  MIPI RFFE is normally pull-down to ground and uses control skew rate transitions which helps isolate SOC noise from the eFEMs. 9
  10. 10. RFFE Implementation Advantages cont… •  MIPI RFFE allows for more control options without changing the chip interconnect. •  Adding a new control feature/register to an eFEM does not change the connection. •  MIPI RFFE allows for the possibility of reading eFEM devices to determine failure cases (like overheating). •  Adding debug and reliability is a KPI for many products. •  Billions of devices in the world use MIPI RFFE already. 10
  11. 11. Continued Reading • MIPI published a white paper with more details on usage RFFE in WiFi/BT Front Ends. •  http://resources.mipi.org/rffe-whitepaper 11

×