Introduction to 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 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.

MIPI RFFE Communication

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

National Instruments Hardware for MIPI RFFE

National Instruments has several devices that you can use to control your RFFE device. If you plan to perform parametric tests (leakage, opens and shorts, and so on), consider the NI PXIe-6555 or NI PXIe-6556 as these devices have PPMUs. If you do not need this functionality, consider the NI PXIe-6547.

Regardless of which device you choose, you should be aware of the following:

1. Drive Strength
   Most RFFE devices are designed to be placed close to the master device (that is, centimeters). In production test, the master device may be connected to the slave device via several meters of cabling. Keep in mind this additional cable length may reduce the rate at which the device under test (DUT) can communicate with the master (NI device).
2. Impedance
   RFFE calls for a 75 Ω characteristic impedance; however, the above HSDIO cards have a 50 Ω characteristic impedance. The important question to answer is “Will this be an issue for your application?”

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. The NI PXIe-6547 has a 50 kΩ pull-down, which is sufficient in most cases. On the other hand, the NI PXIe-6555 and NI PXIe-6556 are left floating, which could result in unexpected behavior. To resolve this potential issue, you could add a pull-down or, in the case of the NI PXIe-6556, you could use the active load to accomplish similar behavior.
3. Connectivity
   Digital hardware from NI has several connectivity options including the NI CB-2162 connector board for pin header access, an SMB breakout box called the NI SMB-2163, and the NI SHC68-H1X38 flying lead cable for rapid connectivity to pin headers on evaluation boards.

USB MIPI RFFE From SignalCraft

SignalCraft from Canada offers a low-cost USB option for MIPI RFFE communication. This hardware does not support PPMU capability but provides 75 Ω connectivity, programmable data rates to 26 MHz, and drivers in NI LabVIEW and  ANSI C. Find more information at signalcraft.com. 

National Instruments MIPI RFFE Software

National Instruments high-speed digital hardware requires the NI-HSDIO software driver, which you can download for free from ni.com/downloads/ni-drivers/. NI-HSDIO supports LabVIEW, ANSI C, and .NET programming environments.

A software example for MIPI RFFE is attached to this paper. It contains LabVIEW 2011 code showing how to commutate with a MIPI device. Keep in mind the device you are using may need additional signals (for example, power) and may use a different version of the MIPI Read and Write commands. If this is the case, you need to modify the code with the appropriate functions from the High-Level Commands folder.

Redefining RF test with the world’s first vector signal transceiver     

Downloads

mipi.zip

0 Ratings | 0.00 out of 5

 Print

Reader Comments | Submit a comment »