MIPI RFFE Communication for RF Semiconductor Devices

Overview

RF front-end devices are used to perform a variety of functions in a mobile device including switching or signal conditioning of RF signal. These devices primarily are most often configured and communicated to via the MIPI RFFE protocol, specifically designed for RF front-end modules. Testing of these devices requires an understanding of the protocol as well as digital instruments capable of reliably writing to and reading from these devices during characterization and production phases.

Contents

RF Front-End Device Communication

RF front-end devices can be defined as an integrated circuit that performs signal conditioning, such as amplification, or switches an RF signal. In a mobile device this is typically a switch or duplexer to route the signal to desired transmit/receive paths, a low noise amplifier (LNA) to amplify the incoming signal, a power amplifier (PA) to amplify the outgoing signal, or an RF transceiver to either upconvert or downconvert the RF signal to baseband. Figure 1 illustrates a common configuration in a mobile device like a phone or tablet.

Figure 1. Simplified RF Front-End Chip Configuration for a Mobile Device

 

Traditional device control of these semiconductor devices is done with custom digital communication or with low-latency serial protocols like SPI or I2C. Because the commands are simple, the digital communication rate does not need to exceed much more than 10 MHz and in the case of I2C it can be below 1 MHz. The challenge with using custom or an assortment of different digital protocols is that the end device manufacturer must configure their device to work with that particular standard if they want to use a particular LNA, PA, or switch. As phones and tablets become denser it becomes more difficult to properly shield the hardware for RF interference.

The MIPI Alliance has created multiple standards for mobile devices, which help solve these issues. See Figure 2, which shows the complete MIPI infrastructure.

Figure 2. MIPI Interfaces in a Mobile Platform (Image courtesy of MIPI Alliance)

 

In particular for RF front-end devices MIPI has developed the MIPI RFFE standard. Similar to other communication standards, RFFE has requirements for both the physical and protocol layers. As expected, RFFE is geared toward controlling RF devices. There are certain addresses reserved for the common RF components (PA, LNA, and so on), rise/fall times limited to help reduce frequency spurs, and several additional considerations. For more detailed information, see the RFFE specification at mipi.org. National Instruments is a MIPI Alliance Adopter.

The remainder of this paper discusses RFFE communication and assumes you have one or more RFFE slave device(s) that needs to be controlled by a National Instruments device acting as the RFFE master device.

 

MIPI RFFE Protocol Basics

Before attempting to communicate with the RFFE device, you must know the slave address, register map, and which commands your RFFE device(s) supports. If an unsupported command or invalid register value is sent the RFFE slave device, it is expected to respond with a No Response Frame (all 0s). If the device manufacturer did not specify which type of RFFE read and (or) write commands are supported, you can use the size of the address and (or) number of bytes to write in the table below to help determine the proper type of command. 

RFFE Register Read Commands

Command

Slave Address (bits)

Address (bits)

Data (bytes)

Register Read

4

5

1

Extended Register Read

4

8

Up to 16

Extended Register Read Long

4

16

Up to 8

 

RFFE Register Write Commands

Command

Slave Address (bits)

Address (bits)

Data (bytes)

Register Write

4

5

1

Extended Register Write

4

8

Up to 16

Extended Register Write Long

4

16

Up to 16

Register 0 Write

4

0

7

 

Using National Instruments Products for MIPI RFFE

For interfacing with MIPI RFFE buses, NI recommends using a PXI digital pattern instrument, such as the PXIe-6571 which provides 32 channels of bidirectional digital I/O with support for communication buses up to 100 MHz. 

  1. Drive Strength
    Most RFFE devices are designed to be placed close to the master device. In production test or validation test, the master device may be connected to the slave device via several meters of cabling. Special considerations may be needed to ensure the device under test (DUT) can communicate with the master (NI device) at higher clock speeds.
  2. Impedance
    The MIPI RFFE specification calls for a 75 Ω characteristic impedance; however, the NI digital pattern instrument has a 50 Ω characteristic impedance. It's important to understand if this will affect your application and what options are available to minimize any signal integrity issues that may be problematic.

For most RFFE devices, testing consists of configuring the DUT using RFFE followed by RF testing. After that test is complete, the device is reconfigured and the next test is run. Because the RFFE commands are not sent during the RF testing, the larger frequency spurs caused by the 50 Ω characteristic impedance are not an issue. However, if your use case requires acquiring/generating RF signals while RFFE commands are sent, you should carefully consider the impact of a 50 Ω system.

Assuming a 50 Ω characteristic impedance works for your application, it is recommended that all cables, load boards, and device connectivity have a 50 Ω characteristic impedance. This helps ensure optimal signal integrity.

  1. Edge Rate
    RFFE specifies a maximum edge rate. Like the characteristic impedance requirement, this helps minimize frequency spurs on the RF signals. If your application falls under the most common use case of configuring the DUT followed by RF testing, this is not an issue as the large frequency spurs do not occur during RF testing.
  2. Pull-Downs
    The RFFE specification calls for the master device to have associated pull-down capable sinking 2 μA per slave device. To address this need, the digital pattern instrument is capable of providing an active load to simulate a pull-up resistor.
  3. Connectivity
    Digital hardware from NI has several connectivity options including the NI CB-2162 connector board for pin header access, the SMB-2163 breakout box with SMB connectivity, and the NI SHC68-H1X38 flying lead cable for rapid connectivity to pin headers on evaluation boards.

 

Developing and Debugging MIPI RFFE Patterns

National Instruments digital pattern instruments require the NI-Digital Pattern driver, featuring APIs for LabVIEW, C, and .NET. Included in the driver is NI Digital Pattern Editor, a full-featured application for designing and debugging digital patterns. 

Figure 3: The NI Digital Pattern Editor provides a rich, powerful, centralized application for designing and debugging your digital patterns and device tests. Learn more at ni.com.

 

Additionally, you can use the NI-Digital API to automate instrument setup, pattern bursting and results processing. To help with this, you can use the open-source LabVIEW MIPI RFFE API, which provides an abstracted method for MIPI RFFE 2.0 register reads and writes. Note that this API is designed for characterization/V&V and not optimized for production test. 

 

Figure 4: The open-source MIPI RFFE API provides an abstracted tool for reading and writing register commands to a MIPI RFFE 2.0 device.