Example Code

MIPI RFFE API for PXIe-657x Digital Pattern Instrument - Register Read and Write in LabVIEW

Products and Environment

This section reflects the products and operating system used to create the example.

To download NI software, including the products shown below, visit ni.com/downloads.

    Hardware

  • RF|Wireless

Code and Documents

Attachment

Overview

The MIPI RFFE API for PXIe-657x Digital Pattern Instrument is a lightweight abstraction of the MIPI RFFE v2.0 protocol geared toward flexiblity and programmatic control of RFFE register reads and writes in LabVIEW. The API is not optimized for test time performance, but geared towards characterization, lab, and debug, where the flexibility of creating dynamic RFFE commands on the fly is ideal. 

 

NOTE: This API is open source and is not fully tested. Users of the API are liable to make corrections or edits to the API for any and all issues identified. Feel free to post a comment with a description of the issue found, and it will be reviewed and potentially updated on this page.


Hardware Description

The below block diagram indicates the digital subsystem that is being implemented by the API. The digital clock, data, and power supply are all controlled via digital lines in the project.

 

Block Diagram of a typical RFFE DUT test setupBlock Diagram of a typical RFFE DUT test setup

 

  • RFFECLK is a return low (RL) timed signal that is timed 15% after RFFEDATA transitions. This ensures sufficient setup time for data to be stable before a clock transition occurs on the line.
  • RFFEDATA is a non-return (NR) timed signal that contains dynamic data.
    • RFFEDATA is configured with an internal pull down of 1.5 mA to 0V through the use of active load on the PXIe-6570. This represents how the RFFE specification expects the data line when not being driven.
  • RFFEVIO is a digital power supply pin that should remain high during use of the API. This ensures the DUT remains powered up in between dynamic command executions and you do not lose the DUT state in between configuring dynamic commands. It is set to 1.8V using the PPMU Source Voltage command of the NI-Digital driver.

For voltage levels, all default levels are 0V to 1.8V with a 0.9V threshold for reading high/low digital logic.

 

For timing, 1 MHz is the default vector rate for RFFE communication, and is stable for both reads and writes. There are more details which may be used to help ensure you have accurate and successful RFFE reads and writes:

  • RFFE writes are generally going to work at all vector rates since the PXIe-657x controls the timing and drive strength. Although there are no forseeable issues at this time, this API has not been thoroughly tested at all rates, some V&V may be required to ensure the specific application will be successful.
  • RFFE reads may be accomplished based on a variety of factors:
    • Reads above 10 MHz may become influenced by propagation delay through the transmission line. There are two main ways to address this with the PXIe-657x instrument:
      • You may use TDR (time domain reflectometry) to programmatically find the length of the transmission line for you and add delay to your digital line(s). This is accomplished through the NI-Digital driver or through Digital Pattern Editor (DPE). Running TDR requires the end of the line to be disconnected and open, so either depopulate the DUT from the socket, or remove the evaluation board from the cable connecting the 657x to your DUT. Run TDR and save the values for application later on. This API does not automatically run TDR for you.
      • At higher rates, you may need to push the time in which you read in a particular vector/cycle outside of the period to achieve passing communication. This is influenced by the strobe value in the RFFEDATA timeset. For instance, at 52 MHz, if your time to valid is 25 ns, you will have to set strobe to 25 ns + 60% of cycle period to accurately read back data. Since the period is ~19 ns, this puts the strobe into the next vector in the pattern, which is acceptable operation on the 657x.

LabVIEW Project Description

The LabVIEW project is organized in the following manner:

  • Controls contains the type defs for the project
  • Digital Project contains the Digital Pattern Editor project, various configuration sheets for the PXIe-657x, and some same source waveform files used for debugging dynamic patterns in DPE
    • RFFE Command Patterns contains all standard .digipat files for each RFFE command that is supported. The PXIe-657x will load all patterns into memory when loaded, thus allowing the PXIe-657x to communicate RFFE in combination with the use of the API. These patterns are not intended to be used outside of the context of the API.
  • Documentation contains a placeholder for future documentation on this API
  • Examples contains two examples that are ready to use out of the box
    • MIPI RFFE Command Panel.vi allows the user to select from any supported RFFE command and execute that command in a single user-defined burst. The pattern data is configured at run-time though user selection.
    • MIPI RFFE Multi-Register Command Panel.vi is a sample that shows a user how to use the API to perform multiple reads and/or writes in a row programmatically. It currently defaults to using Extended Register Reads and Extended Register Writes only.
  • Main VIs contains all the high level subVI's used in the examples within the Examples folder.
    • MIPI RFFE - Burst RFFE Command.vi is the encapsulated burst needed for programmatic bursting of multiple commands.
    • MIPI RFFE - Multi-Command.vi allows a user to string multiple reads and writes together dynamically.
  • subVI contains all VI's used in the API that are not high level. These encapsulations help maintain code and enable best practices for code development.

Example Description

In the Examples folder, you will find the following front panels. Below is a description of their functionality and intended use.

 

MIPI RFFE Command Panel.vi

This example uses a while loop with event structure to loop indefinitely until the user stops the program. The program is intended to execute one RFFE command call at a time based upon the user selecting "Execute Command". The RFFE command and Register Data controls can be modified dynamically and bursted at any time the program is running.

 

Command Panel v1.0.1Command Panel v1.0.1

 

  1. Select the digital pattern instrument in the resource name control. NOTE: You will have to change the pin map to correct reference your instrument before running this example, otherwise you will see an error.
  2. Using the default pin map, the pin name for data is RFFEDATA. You may change the physical location of this pin through the pin map.
    1. The pattern supports RFFECLK and RFFEVIO pins as well, which must be used in the pin map. Removing these pins will require further modification of the pattern files in order to make the API work successfully.
  3. RFFE command allows you to select one of the supported MIPI RFFE commands for bursting.
  4. Register Data contains all the information that the user may supply to the API in order to dynamically burst a register read or write.
    1. Slave Address is any value between 0 and 16 (0x0 and 0xF)
    2. Register Address is within the range of the selected command (Ex. reg0write ignores register addess since it always writes to reg0. Regwrite allows a 4-bit address up to 0xF)
    3. Byte Count is for reads only. Determines how many bytes of data should be returned from the read command (Ex. Regread returns 1 byte of data. Extended Regread returns from 1 to 16 bytes of data)
    4. Register Data (write) allows the user to input the data to be written. (Ex. Regwrite uses one byte of data, all other data in the control is ignored. Extended Regwrite uses anywhere from 1 to 16 bytes of data. The length of data in the array determines the amount of bytes written)
  5. Read data is populated when a read call is returned.

MIPI RFFE Multi-Command Panel.vi

This example shows one example of creating a VI from the API to create a new function that allows for multiple register reads or writes to occur programmatically. This example simply allows multiple extended register writes and/or multiple extended register reads. Note: A future example can be added if there is a desire to have various RFFE commands to execute in a sequence through an API call.

 

Multi-Command Panel v1.0.1Multi-Command Panel v1.0.1

  1. Select the digital pattern instrument in the resource name control. NOTE: You will have to change the pin map to correct reference your instrument before running this example, otherwise you will see an error.
  2. Using the default pin map, the pin name for data is RFFEDATA. You may change the physical location of this pin through the pin map.
    1. The pattern supports RFFECLK and RFFEVIO pins as well, which must be used in the pin map. Removing these pins will require further modification of the pattern files in order to make the API work successfully.
  3. The user may use each element in Multi-Command Write and Multi-Command Read to create an individual RFFE command burst. For instance, if there were two elements in Multi-Command Write enabled, the Execute Command button would burst back to back both commands for one button press. The user may leave the opposing array empty if they only want to read or only want to write.

API Description

A summary of the API can be found below, along with recommendations on using the API:

Image of initialization for the digital pattern instrument and the MIPI RFFE APIImage of initialization for the digital pattern instrument and the MIPI RFFE API

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

To initialize the API, the NI-Digital driver is used along with a digital pattern instrument project (.digiproj). The VI's are organized to make corresponding functions logical to the end user.

  • Loading the pin map to the instrument allows the instrument to understand which pins are available on the DUT, and to which physical location the pins correspond to on the digital pattern instrument. The user will be required to modify this file for their application.
  • Loading specification, levels, and timing sheets provide key configuration data that will setup the digital pattern instrument. Settings such as voltage levels, frequency of the patterns, and other configurations may be modified by the user for their application.
  • Loading pattern files (.digipat) is done using the RFFE template patterns. This is to be left unmodified by the user for the API to work correctly. Any additions or changes to these patterns may cause the API to behave in an indeterminate manner.

Optional user change to insert a bring up pattern before running the panel with a DUTOptional user change to insert a bring up pattern before running the panel with a DUT

An optional step in the command panel block diagram is to enable a code subset which allows a user to define a pattern to burst before the command panel begins. This is useful when working with DUTs that require a specific sequence of register writes before it is operational. 

 

 

To select your command programmatically, there is a Burst RFFE Command VI that allows you to do so.

 

Allows users to programmatically choose the command and burst the patternAllows users to programmatically choose the command and burst the pattern

 

Finally, for programmatically bursting a sequence of register commands, there is a Multi-Command VI that allows you to perform multiple extended register reads or writes. This can be modified if the types of commands need to change in the sequence. Note: please leave a comment for feedback on the types of register sequence burst commands needed and it can be considered for addition in future API revisions.

 

Allows a user to input an array of register writes and reads for bursting. The order of the bursts will be all extended register writes first, followed by all the extended register reads.Allows a user to input an array of register writes and reads for bursting. The order of the bursts will be all extended register writes first, followed by all the extended register reads.


Hardware and Software Requirements

LabVIEW 17.0 and NI-Digital 17.0 or greater 

PXIe-657x (6570, 6571) or equivalent product


Steps to Implement or Execute Code

  1. Install required software
  2. Setup necessary hardware
  3. Download and unzip attached folder. The folder contains all files necessary to run the API and example command panels.

Additional Information or References

MIPI RF Front-End Interface (RFFE) from mipi.org

MIPI RFFE Communication for RF Semiconductor Devices from ni.com

 

Kyle A.
National Instruments
Senior Applications Engineer

Example code from the Example Code Exchange in the NI Community is licensed with the MIT license.

Comments
SunshineDesign
Active Participant
Active Participant
on

This API is pretty useful. I have gotten to know Kyle and work with him on this to test and use. I just integrated it into a first test project that I delivered and it works great. Kuddos to Kyle and NI for bringing this to the table.

Chloe-zhitao
NI Employee (retired)
on

Hi,Kyle_A:

Can this APIs could be used in MIPI RFFE v1.10?

Is this API compatible with v1.10

Thanks!

vincent.lai@tctechinc.com
Member
Member
on

Hi Kyle_A

 

I am not hardware nor MIPI expert and would like to ask something about MIPI RFFE spec and SDATA pin level setting.

Your example set SDATA pin termination mode to "active load" with Vcom=0V and Iol 1.5mA, Ioh -1.5mA.

Also you wrote "This represents how the RFFE specification expects the data line when not being driven."

 

I checked the spec.  In pin physical I/O chapter, it mentions "SDATA and SCLK pull-downs may be implemented as internal or external components or current sources."  Does this reflect your SDATA pin setting?  If not, would you please tell more about the reason behind this termination mode setting.

 

Thank you

Kyle_A.
Active Participant
Active Participant
on

Hi Vincent,

 

The main reason I added active load here is to give a small assist for receiving data from the RFFE DUT which is typically a weak driver based on the MIPI RFFE spec. It is not necessary and can be removed if it is causing worse performance in your specific application use case. I found in some cases the active load termination can improve edge performance based on the speed and loading conditions of the system setup. I have been considering removing this from the API as default since it technically does not belong based on the spec. However, an additional 1.5 mA of drive strength does not cause too great of a change to the overall communication signal integrity, whether needed or not. Hope this helps explain.

Kyle A.
National Instruments
Senior Applications Engineer
jonghkim
Member
Member
on

Hi Kyle,

 

This is a pretty good 🙂

songli766454
Member
Member
on

Hi Kyle,

 

Can the MIPI REEF API be used in c# to communicate with PXIe-657x ?