MIPI RFFE Communication for RF Semiconductor Devices

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 I²C. Because the commands are simple, the digital communication rate does not need to exceed much more than 10 MHz and in the case of I²C 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.

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

RFFE Register Write Commands

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.

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.}

• Learn how to effortlessly perform digital interface compliance testing
• Learn more about RF front end testing with PXI
• Explore using the Semiconductor Test System for RF front end test