Example Code
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.
- RF|Wireless
Hardware
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.
- 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.
- 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:
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.
- 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.
- 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.
- 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.
- RFFE command allows you to select one of the supported MIPI RFFE commands for bursting.
- Register Data contains all the information that the user may supply to the API in order to dynamically burst a register read or write.
- Slave Address is any value between 0 and 16 (0x0 and 0xF)
- 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)
- 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)
- 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)
- 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.
- 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.
- 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.
- 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.
- 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:
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.
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.
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.
Example code from the Example Code Exchange in the NI Community is licensed with the MIT license.
