https://kb.ettus.com/api.php?action=feedcontributions&user=JonathonPendlum&feedformat=atomEttus Knowledge Base - User contributions [en]2024-03-28T15:07:49ZUser contributionsMediaWiki 1.26.2https://kb.ettus.com/index.php?title=Getting_Started_with_RFNoC_Development&diff=5919Getting Started with RFNoC Development2023-12-01T05:04:07Z<p>JonathonPendlum: Emphasize that this application is deprecated</p>
<hr />
<div>==Application Note Number==<br />
<br />
'''AN-823'''<br />
<!-- Internal use only: please do keep this updated!<br />
==Revision History==<br />
{| class="wikitable"<br />
!Date<br />
!Author<br />
!Details<br />
|-<br />
|style="text-align:center;"| 2016-07-12<br />
|style="text-align:center;"| Martin Braun<br> Nicolas Cuervo<br />
|style="text-align:center;"| Initial creation<br />
<br />
<br />
|-<br />
|style="text-align:center;"| 2017-01-10<br />
|style="text-align:center;"| Team<br />
|style="text-align:center;"| Added “Digital Gain” example<br />
|-<br />
<br />
|-<br />
|style="text-align:center;"| 2017-05-08<br />
|style="text-align:center;"| Jose Loera<br />
|style="text-align:center;"| Updated example code. Update to Testbench section.<br />
|-<br />
<br />
|-<br />
|style="text-align:center;"| 2017-08-26<br />
|style="text-align:center;"| Jose Loera<br />
|style="text-align:center;"| Updated following sections: '''Abstract'''(This AN is specific to USRP X300/X310), '''Using a graphical interface'''(updated GUI image with newest version and the explanation section), '''Testing out the custom block'''(Updated GRC image that has correct Sampling Rate for RFNoC:Radio block).<br />
|-<br />
<br />
|-<br />
|style="text-align:center;"| 2017-09-07<br />
|style="text-align:center;"| Jose Loera<br />
|style="text-align:center;"| Added link to Video that follows this App Note in the Resources section. Also [https://youtube.com/watch?v=j-EfyPVpaJ8 here]<br />
|-<br />
<br />
|-<br />
|style="text-align:center;"| 2019-10-24<br />
|style="text-align:center;"| Michael Dickens<br />
|style="text-align:center;"| Fixed list of USRPs that this AN is applicable to: all current 3rd generation USRP hardware.<br />
|-<br />
<br />
|}<br />
--><br />
<br />
==Abstract==<br />
'''Note: This application note is DEPRECATED. It applies only to using RFNoC in UHD 3.x. The latest Getting Started in RFNoC application note is available here: [[Getting Started with RFNoC in UHD 4.0]].'''<br />
<br />
This application note guides a user through basic information on the RFNoC architecture, installing necessary software to develop custom RFNoC blocks, also called Computation Engines (CE), and walks through the steps of creating a custom RFNoC block using an example. RFNoC is currently supported on any 3rd generation USRP hardware, currently: E310/E312, E320, N300/N310/N320/N321, and X300/X310. '''However''', this document primarily covers using RFNoC for the USRP X300/X310 and E310/E312. Using RFNoC with the other USRPs is similar to that documented herein.<br />
<br />
==Overview==<br />
First sections deal with installing tools and validating correct tool installation in order to do RFNoC development. Later sections deal with creating a custom RFNoC block, using the built-in testbench architecture, building an FPGA image with the custom block and finally testing out the new block within GNU Radio.<br />
<br />
==Licensing==<br />
The RFNoC code base is open source, including code that executes on the host, as well as code targeted to the USRP hardware (FPGA and microcontroller firmware). RFNoC is available under the open-source GNU Lesser General Public License (LGPL). For more information on our licensing policy, please contact [mailto:info@ettus.com info@ettus.com].<br />
<br />
==Prerequisites==<br />
RFNoC is only supported on 3rd generation USRP hardware as noted in the Abstract.<br />
<br />
In order to build custom USRP FPGA images and RFNoC blocks the following hardware and software are needed.<br />
<br />
* '''Ubuntu 14.04.5 or 16.04.1 (preferred):''' Currently PyBOMBS (which can be used to install the ''Software build tools''), works most reliably in Ubuntu, and thus, we recommend using this distribution. Also, a majority of the scripts used during the build process are Linux (Ubuntu) specific. A PC with multiple cores and 8GB+ of RAM is recommended.<br />
<br />
* '''Xilinx Vivado tools (version 2017.4):''' The specific version depends on the branch and state of the FPGA code. The default install location is <code>/opt/Xilinx/Vivado</code>. Once all of the Software build tools are installed the specific version for the downloaded code can be found in the <code>setupenv.sh</code> file located in the <code>{USER_PREFIX}/src/uhd-fpga/usrp3/top/{DEVICE}</code> directory. Further information can be found [http://files.ettus.com/manual/md_usrp3_build_instructions.html here].<br />
<br />
* '''Software build tools:''' If UHD can be or has been compiled from source on the development PC then all the necessary software build components are present (PyBOMBS can be used to set all this up and instructions on how to do so are given in a following step).<br />
<br />
* Any 3rd generation USRP hardware as noted in the Abstract.<br />
<br />
'''NOTE:'''<br />
* The edition of Xilinx Vivado that is required will depend on which USRP device is being used.<br />
** X3xx series devices: Design Edition or System Edition.<br />
** E3xx series devices: Design Edition, System Edition, or the free WebPack Edition.<br />
* Other operating systems can be used, but the exact steps on how to proceed are not given in this Application Note.<br />
* In some Linux distributions (e.g. Ubuntu) <code>dash</code> is set as default shell, which may cause some issues. It is recommended to set the shell to <code>bash</code> by running the following commands in the terminal. Choose <code><No></code> when prompted by the first command and the second command will validate the that bash will be used.<br />
<br />
$ sudo dpkg-reconfigure dash<br />
$ ll /bin/sh<br />
<br />
==Creating a development environment==<br />
While this Application Note goes through the process of integrating GNU Radio into the RFNoC development flow, it is by no means required to use or develop within the RFNoC framework, but it makes it a great deal easier to use a framework on top of RFNoC for aspects such as visualization and other features. GNU Radio is freely available and more information about it can be found [http://gnuradio.org/ here].<br />
<br />
The following software packages are required in order to setup a development environment/sandbox:<br />
<br />
* UHD<br />
* GNU Radio <br />
* gr-ettus<br />
<br />
===Create development environment using PyBOMBS===<br />
The cleanest way to set this up is to install everything into a dedicated directory. [https://github.com/gnuradio/pybombs PyBOMBS] is the simplest way to do this. If not already installed, PyBOMBS can be setup with the following commands:<br />
<br />
$ sudo apt-get install git<br />
$ sudo apt-get install python-setuptools python-dev python-pip build-essential <br />
<br />
$ sudo pip install git+https://github.com/gnuradio/pybombs.git<br />
$ pybombs recipes add gr-recipes git+https://github.com/gnuradio/gr-recipes.git<br />
$ pybombs recipes add ettus git+https://github.com/EttusResearch/ettus-pybombs.git<br />
<br />
These commands will do the following:<br />
* Install <code>Git</code><br />
* Install <code>pip</code> and other Python dependencies<br />
* Install the latest <code>PyBOMBS</code> from its Git repository<br />
* Add the <code>gr-recipes</code> recipes which are used to install GNU Radio specific software<br />
* Add the <code>ettus</code> recipes which are used to install Ettus Research specific software<br />
<br />
From here, PyBOMBS can be used to setup and install the development environment/sandbox by running the following command:<br />
<br />
$ pybombs prefix init ~/rfnoc -R rfnoc -a rfnoc<br />
<br />
This will do the following:<br />
<br />
* Create a directory in the user’s home directory called <code>rfnoc</code> (any valid directory name will work)<br />
<br />
* Give the prefix an alias of <code>rfnoc</code> ( <code>[-a alias]</code>, e.g. <code>–a rfnoc</code> ), which would be the name given to this path. This name will be used in further steps that use PyBOMBS. When creating the first prefix and omitting the alias, the prefix will be setup as the default.<br />
<br />
* Use the <code>rfnoc</code> prefix recipe ( as opposed to a package recipe like <code>gqrx</code> ) to clone UHD, FPGA, GNU Radio, and gr-ettus sources into the <code>~/rfnoc</code> directory as well as compile and install all the software<br />
<br />
'''NOTE:''' A user can specify how many cores are used by builds when using PyBOMBS. The default is set to 4. For example, this will set the number of cores used to 3:<br />
<br />
$ pybombs config makewidth 3<br />
<br />
The value will be written into a configuration file and then applied to subsequent PyBOMBS commands. This value can temporarily be overridden for a specific build by specifying the <code>--config makewidth=X</code> argument, where “<code>X</code>” is an integer number. If the user only has 4 cores it is recommend to use this argument in the pybombs command to limit the number of cores to <4 (e.g. 3) so that the computer stays responsive. Following are 2 examples, one using less cores and the other using more cores:<br />
<br />
$ pybombs --config makewidth=3 prefix init ~/rfnoc -R rfnoc -a rfnoc <br />
$ pybombs --config makewidth=7 prefix init ~/rfnoc -R rfnoc -a rfnoc<br />
<br />
Then, it is necessary to setup the PyBOMBS environment, so that the system/terminal session will have the environmental variables pointing to this newly created prefix, which is done with the following commands:<br />
<br />
$ cd ~/rfnoc<br />
$ source ./setup_env.sh<br />
<br />
Once the previous command is run, this terminal session will have access to the environmental variables that allow the complete use of the set of software that was just installed with PyBOMBS. If access to the software is needed in other terminals the same command must be run within them.<br />
<br />
'''NOTE:''' Throughout the rest of this document the term <code>{USER_PREFIX}</code> will used at the beginning of different directories. For example, <code>{USER_PREFIX}/src/uhd-fpga/usrp3/tools/scripts</code> is a directory that contains useful scripts for compiling. The term <code>{USER_PREFIX}</code> is used to denote the folders that precede the <code>/src</code> directory. Examples of what <code>{USER_PREFIX}</code> could be: <code>/home/user/rfnoc</code> or <code>/home/user/myDevfolder/</code>. On many Linux environments using <code>~/</code> at the beginning of the target directory path is equivalent to the user’s home directory.( i.e <code>~/</code> is equal to <code>/home/user/</code>). So <code>{USER_PREFIX}</code> could also look like <code>~/rfnoc</code> or <code>~/myDevfolder/</code>.<br />
<br />
===Create the development environment manually===<br />
As an alternative to using PyBOMBS, manually installing and configuring the software is done by following the individual install notes for [http://gnuradio.org/redmine/projects/gnuradio/wiki/InstallingGRFromSource GNU Radio], [https://files.ettus.com/manual/page_build_guide.html UHD] and [https://github.com/EttusResearch/gr-ettus gr-ettus] and by making sure they are reachable by linkers and compilers.<br />
<br />
'''NOTE:''' The Application Note found [https://kb.ettus.com/Building_and_Installing_the_USRP_Open-Source_Toolchain_(UHD_and_GNU_Radio)_on_Linux here] goes through the process of manually installing UHD and GNU Radio on Linux platforms.<br />
<br />
To manually download the software, use these <code>git clone</code> commands, which will select the correct branches:<br />
<br />
$ git clone --recursive -b rfnoc-devel https://github.com/EttusResearch/uhd.git <br />
$ git clone --recursive -b maint https://github.com/gnuradio/gnuradio.git # master branch is also fine instead of maint<br />
$ git clone -b master https://github.com/EttusResearch/gr-ettus.git <br />
$ git clone -b rfnoc-devel https://github.com/EttusResearch/fpga.git<br />
<br />
If UHD, GNU Radio and/or gr-ettus are already installed, it would be sufficient to checkout the branches mentioned and update them them (<code>git pull</code>). Thereafter, rebuild each of the repositories (rebuild order: UHD, GNU Radio, gr-ettus).<br />
<br />
===Verify Environment===<br />
Running the command “<code>uhd_config_info</code>” with the “<code>--version</code>” flag will verify that the installation has been completed successfully.<br />
<br />
'''NOTE:''' The version string output from this command may differ, however it should be similar to the output below.<br />
<br />
$ uhd_config_info --version<br />
linux; GNU C++ version 5.4.0 20160609; Boost_105800; UHD_4.0.0.rfnoc-devel-161- g83150fdd<br />
<br />
4.0.0.rfnoc-devel-161-g83150fdd<br />
<br />
===Testing the default FPGA image and building from existing blocks===<br />
<br />
It is recommended to spend a moment looking at the Ettus Research default image, which is pre-built with a set of RFNoC blocks, as well as building a custom image with a unique set of pre-built RFNoC blocks. To get the default image(s), run the following command:<br />
<br />
$ uhd_images_downloader<br />
<br />
Ettus Research will be updating the default image(s) occasionally, and <code>uhd_images_downloader</code> can be run anytime after running <code>git pull</code> and re-installing to pull the most current images. Images are stored in the <code>{USER_PREFIX}/share/uhd/images</code> directory.<br />
<br />
The following images have the corresponding RFNoC blocks (Computation Engines):<br />
<br />
{| class="wikitable"<br />
!Image Name<br />
!Included Blocks<br />
|-<br />
<br />
|<code>usrp_x300_fpga_HG.bit</code><br />
<code>usrp_x300_fpga_XG.bit</code><br />
<br />
<code>usrp_x310_fpga_HG.bit</code><br />
<br />
<code>usrp_x310_fpga_XG.bit</code><br />
|<code>2x DDC, 2x DUC</code><br />
|-<br />
<br />
|<code>usrp_x300_fpga_RFNOC_HG.bit</code><br />
<code>usrp_x300_fpga_RFNOC_XG.bit</code><br />
|<code>DUC, DDC (one channel), fosphor, window, fft, 2x AXI FIFOs</code><br />
|-<br />
<br />
|<code>usrp_x310_fpga_RFNOC_HG.bit</code><br />
<code>usrp_x310_fpga_RFNOC_XG.bit</code><br />
|<code>DUC, DDC (one channel), fosphor, window, fft, 2x AXI FIFOs, Keep One in N, FIR, Siggen</code><br />
|-<br />
<br />
|<code>usrp_e310_fpga.bit</code><br />
<code>usrp_e310_fpga_sg3.bit</code><br />
|<code>1x DDC, 1x DUC</code><br />
|-<br />
<br />
|<code>usrp_e310_fpga_RFNOC.bit (sg1 version)</code><br />
<code>usrp_e310_fpga_RFNOC_sg3.bit</code><br />
|<code>fosphor, window, fft, 2x AXI FIFOs, FIR</code><br />
|-<br />
<br />
|}<br />
<br />
Instructions on flashing the image to a device can be found [http://files.ettus.com/manual/page_usrp_x3x0.html#x3x0_load_fpga_imgs here] for X3xx series and [http://files.ettus.com/manual/page_usrp_e3x0.html#e3x0_load_fpga_imgs here] for E3xx series.<br />
<br />
'''NOTE:''' FPGA images are specific to the USRP device '''NOT''' the USRP series. For example, a USRP X300 FPGA image will '''NOT''' work on a USRP X310 and vice versa. Loading an image that does not correspond to a USRP device will likely brick the device.<br />
<br />
By following the steps above the following should now be available:<br />
* UHD/RFNoC code downloaded and installed<br />
* FPGA code available<br />
* A valid RFNoC image on your X3xx or E3xx series device<br />
<br />
====Inspect default images====<br />
Run the following command, with a USRP connected to your PC, to verify current image on the USRP.<br />
<br />
$ uhd_usrp_probe<br />
<br />
If an RFNoC image was successfully loaded onto the USRP, there will be a lot of output text (RFNoC code is currently very verbose). The final lines of the output should be similar to the following for an USRP X310 ( e.g. <code>usrp_x310_fpga_HG</code> ):<br />
<br />
| | _____________________________________________________<br />
| | /<br />
| | | RFNoC blocks on this device:<br />
| | | <br />
| | | * DmaFIFO_0<br />
| | | * Radio_0<br />
| | | * Radio_1<br />
| | | * DDC_0<br />
| | | * DDC_1<br />
| | | * DUC_0<br />
| | | * DUC_1<br />
<br />
<br />
Final output for <code>usrp_x310_fpga_RFNOC_HG.bit</code> image:<br />
<br />
| | _____________________________________________________<br />
| | /<br />
| | | RFNoC blocks on this device:<br />
| | | <br />
| | | * DmaFIFO_0<br />
| | | * Radio_0<br />
| | | * Radio_1<br />
| | | * DDC_0<br />
| | | * DUC_0<br />
| | | * FFT_0<br />
| | | * Window_0<br />
| | | * FIR_0<br />
| | | * SigGen_0<br />
| | | * KeepOneInN_0<br />
| | | * fosphor_0<br />
| | | * FIFO_0<br />
| | | * FIFO_1<br />
<br />
<br />
'''NOTE:''' The actual names and number of blocks can differ. The list of blocks should start with the <code>DmaFIFO_x</code> and <code>Radio_x</code>, and then a couple more lines of block IDs should follow.<br />
<br />
====Build custom image with pre-built RFNoC blocks====<br />
Because of the growing number of RFNoC blocks, the user has the option to build an FPGA image with a set of pre-built RFNoC blocks of their choosing. The following steps describe the process for doing this and by so doing will also validate proper tool installation. Because compilation can take a couple of hours, it is recommended the user begin this process while continuing the rest of this guide.<br />
<br />
'''NOTE:''' FPGA compilations can run in the background, however they are very resource intensive. If the user intents to use the same computer that is compiling to walk through the rest of this Application Note, it is recommended that the computer has plenty of resources.<br />
<br />
The script to initiate a compile is called <code>uhd_image_builder.py</code>, and is located in the <code>{USER_PREFIX}/src/uhd-fpga/usrp3/tools/scripts</code> directory. Run the help menu by typing:<br />
<br />
$ cd {USER_PREFIX}/src/uhd-fpga/usrp3/tools/scripts <br />
$ ./uhd_image_builder.py --help<br />
<br />
A more detailed discussion of this script is given in an upcoming section. For now, compiling an FPGA image that has 2 RFNoC blocks (<code>window</code> and <code>fft</code>) and some <code>FIFOs</code>, is done by running the script with the following arguments.<br />
<br />
Example for an X310 USRP:<br />
<br />
$ ./uhd_image_builder.py window fft -d x310 -t X310_RFNOC_HG -m 5 --fill-with-fifos<br />
<br />
Example for an E310 USRP with Speed Grade 3 (sg3) FPGA:<br />
<br />
$ ./uhd_image_builder.py window fft -d e310 -t E310_RFNOC_sg3 -m 5 --fill-with-fifos<br />
<br />
At the end of a successful compilation process, write the new image to a USRP. If the image was compiled for a USRP X310, the following command will load the new image. Update the <code>{IP_Address}</code> of the USRP and <code>{USER_PREFIX}</code> to the appropriate values for your configuration before running the command.<br />
<br />
$ uhd_image_loader --args "type=x300,addr={IP_ADDRESS}" --fpga-path {USER_PREFIX}/src/uhd-fpga/usrp3/top/x300/build/usrp_x310_fpga_RFNOC_HG.bit<br />
<br />
'''NOTE:''' FPGA images are specific to the USRP device '''NOT''' the USRP series. For example, a USRP X300 FPGA image will '''NOT''' work on a USRP X310 and vice versa. Loading an image that does not correspond to a USRP device will likely brick the device. Additional instructions on flashing a custom image to a device can be found [http://files.ettus.com/manual/page_usrp_x3x0.html#x3x0_load_fpga_imgs here] for X3xx series and [http://files.ettus.com/manual/page_usrp_e3x0.html#e3x0_load_fpga_imgs here] for E3xx series.<br />
<br />
After the image has been successfully written to the USRP, power-cycle it and run the “<code>uhd_usrp_probe</code>” utility to view the newly compiled blocks.<br />
<br />
$ uhd_usrp_probe<br />
<br />
The final lines of output for the image built for the X310 is as follows:<br />
<br />
| | _____________________________________________________<br />
| | /<br />
| | | RFNoC blocks on this device:<br />
| | | <br />
| | | * DmaFIFO_0<br />
| | | * Radio_0<br />
| | | * Radio_1<br />
| | | * Window_0<br />
| | | * FFT_0<br />
| | | * FIFO_0<br />
| | | * FIFO_1<br />
| | | * FIFO_2<br />
<br />
===Getting started with UHD + RFNoC===<br />
The following new examples included within the <code>rfnoc-devel</code> branch of UHD, are a good reference on how to use RFNoC from UHD.<br />
<br />
The following example is based off of <code>rx_samples_to_file.cpp</code>. The example can be configured to place an RFNoC block in between the radio and host.<br />
<br />
rfnoc_rx_to_file.cpp<br />
<br />
This next example chains a null source to another block and streams the data to the host.<br />
<br />
rfnoc_nullsource_ce_rx.cpp<br />
<br />
These examples demonstrate the core features and flexibility of RFNoC.<br />
<br />
For more information on UHD and UHD development please refer to the [https://kb.ettus.com/UHD UHD Software Resource page], [https://kb.ettus.com/Getting_Started_with_UHD_and_C%2B%2B Getting Started with UHD and C++ Application Note] or directly to the [http://files.ettus.com/manual/ UHD user manual].<br />
<br />
===Getting started with GNU Radio + RFNoC===<br />
A good way of getting started with RFNoC in a more visual way is to use GNU Radio. The <code>gr-ettus</code> out-of-tree module (OOT) allows a user to use RFNoC blocks in their local GNU Radio / GNU Radio Companion (GRC) installation. This GNU Radio OOT contains blocks that allow you to configure your FPGA through GRC.<br />
<br />
'''NOTE:''' As blocks in the <code>gr-ettus</code> OOT mature, they will be upstreamed to <code>gr-uhd</code>. Also, <code>gr-ettus</code> is a container used by Ettus Research to disseminate experimental or under-development features for <code>gr-uhd</code>. It is not a replacement for <code>gr-uhd</code> (in fact, the latter is a requirement for <code>gr-ettus</code>).<br />
<br />
Examples can be run from <code>gr-ettus/examples/rfnoc</code>, provided that the appropriate RFNoC blocks are compiled into the FPGA image currently running on the USRP.<br />
<br />
A couple of rules for building GNU Radio flowgraphs with RFNoC blocks:<br />
<br />
* You always need a <code>Device3</code> object in your flow graph (it does not get connected, see screenshot below).<br />
* You should have at least two RFNoC blocks connected together. Going <code>GNU Radio Block</code> -> <code>RFNoC Block</code> -> <code>GNU Radio Block</code> is not recommended (it will work, but with suboptimal performance).<br />
<br />
The GNU Radio flowgraph <code>rfnoc_ddc.grc</code> is an example that can be run using the default RFNoC image. Below are screenshots of the flowgraph and what it produces.<br />
<br />
[[File:rfnoc gsg an 1.png|center|800px|]]<br />
<br />
'''NOTE:''' Copy Block: In the RFNoC domain, streams of data can not be split as easily as they are in the GNU Radio domain. The “copy” block depicted in the screenshot above serves the function as a stream splitter. Its main purpose, when “enabled”, is to copy the samples it is getting at its input and put them into the output, but here it is also serving as a boundary between a RFNoC-domain and a GNURadio-domain. In the flowgraph above, after this boundary is passed, the data stream can easily be split into the two sinks to have them run simultaneously (standard GNU Radio functionality). It is possible to connect the GNU Radio blocks directly to RFNoC blocks without a “copy” block, but only one would work at a time (the other ones would have to be disabled). Another way to split data streams from the RFNoC-domain is to use the ”RFNoC: split stream” block, which would split the streams in the RFNoC domain, but this is not very useful here as we are, in any case, moving into the GNURadio-domain.<br />
<br />
[[File:rfnoc gsg an 2.png|center|800px|]]<br />
<br />
For more information on GNURadio development please refer to the [http://gnuradio.org/doc/doxygen/ GNURadio user's manual and API].<br />
<br />
==Starting a custom RFNoC block using RFNoC Modtool==<br />
The figure below shows the basic structure of the RFNoC Stack. Corresponding code is needed in each of the three sections in order to build a custom RFNoC block with GNU Radio integration. A tool called RFNoC Modtool was created in order to minimize the effort needed to implement a new RFNoC block. RFNoC Modtool creates a custom GNU Radio OOT module with the basic structure and the necessary files for each of these sections. RFNoC Modtool is currently a part of the GNU Radio OOT module <code>gr-ettus</code>.<br />
<br />
[[File:rfnoc gsg an 3.png|center|800px|]]<br />
<br />
===RFNoC Modtool Utilization===<br />
'''NOTE:''' Console outputs may vary depending on the version of UHD the user is running. However, functionality should be the same or similar.<br />
<br />
Because the RFNoC Modtool has similar functionality to the <code>gr_modtool</code> [ [http://gnuradio.org/redmine/projects/gnuradio/wiki/OutOfTreeModules gr_modtool] ] provided by GNU Radio, those that have worked with <code>gr_modtool</code> in the past will find the RFNoC Modtool familiar.<br />
<br />
To check the usage of the tool, run the following:<br />
<br />
$ rfnocmodtool help<br />
linux; GNU C++ version 5.4.0 20160609; Boost_105800; UHD_4.0.0.rfnoc-devel-162-g335a1317<br />
<br />
Usage:<br />
rfnocmodtool <command> [options] -- Run <command> with the given options.<br />
rfnocmodtool help -- Show a list of commands.<br />
rfnocmodtool help <command> -- Shows the help for a given command. <br />
<br />
List of possible commands:<br />
<br />
Name Aliases Description<br />
=====================================================================<br />
disable dis Disable block (comments out CMake entries for files) <br />
info getinfo,inf Return information about a given module <br />
remove rm,del Remove block (delete files and remove Makefile entries) <br />
makexml mx Make XML file for GRC block bindings <br />
add insert Add block to the out-of-tree module. <br />
newmod nm,create Create a new out-of-tree module <br />
rename mv Rename a block in the out-of-tree module.<br />
<br />
===Creating an RFNoC OOT Module===<br />
<br />
To start generating an RFNoC OOT module navigate to the source location ( i.e. <code>cd ~/{USER_PREFIX}/src</code> ) and type:<br />
$ rfnocmodtool newmod [NAME OF THE MODULE]<br />
<br />
<br />
Where <code>[NAME OF THE MODULE]</code> is a name the user gives the new module. In the following, a module is created with the name “<code>tutorial</code>”. If the user does not write the name of the module following the <code>newmod</code> command the tool will ask for it interactively. Running this command will create a folder containing the basic folders that you may need for a functional module.<br />
<br />
$ rfnocmodtool newmod tutorial<br />
linux; GNU C++ version 5.4.0 20160609; Boost_105800; UHD_4.0.0.rfnoc-devel-162-g335a1317<br />
<br />
Creating out-of-tree module in ./rfnoc-tutorial... Done.<br />
Use 'rfnocmodtool add' to add a new block to this currently empty module.<br />
<br />
To see what files and directories were created run:<br />
<br />
$ ls rfnoc-tutorial/<br />
apps cmake CMakeLists.txt docs examples grc include lib MANIFEST.md python README.md rfnoc swig<br />
<br />
<br />
In contrast with <code>gr_modtool</code>, this includes a folder called <code>rfnoc</code>, which is where the UHD/FPGA files are located.<br />
<br />
===Adding custom blocks to OOT Module===<br />
In order to add blocks to a module, navigate to the folder just created and use the <code>add</code> command of <code>rfnocmodtool</code>. Continuing with the example above, run the following:<br />
<br />
$ cd rfnoc-tutorial<br />
$ rfnocmodtool add [NAME OF THE BLOCK]<br />
<br />
For demonstrative purposes, a block named <code>gain</code> will be created. The <code>gain</code> block will multiply samples that pass through it by a constant. As before, if the name is not given, the tool will ask the user for the name. There are several arguments that can be passed to the tool, but running the tool without any of these arguments will give the following interactive parsing output:<br />
<br />
$ rfnocmodtool add gain<br />
linux; GNU C++ version 5.4.0 20160609; Boost_105800; UHD_4.0.0.rfnoc-devel-162-g335a1317<br />
<br />
RFNoC module name identified: tutorial<br />
Block/code identifier: gain<br />
Enter valid argument list, including default arguments: <br />
Block NoC ID (Hexadecimal): 1111222233334444<br />
Skip Block Controllers Generation? [UHD block ctrl files] [y/N] N<br />
Skip Block interface files Generation? [GRC block ctrl files] [y/N] N<br />
<br />
Hitting <code>enter</code> on each one of the options will take the default values.<br />
<br />
The following is a description of the valid argument list items:<br />
<br />
* '''NoC ID:''' This ID is a Hexadecimal number which serves as identification between the hardware part and the software part of the design. It can be as long as 16 0-9 A-F digits. If a NoC ID is not provided, it will be set to a random number.<br />
<br />
* '''Block Controllers Generation:''' The block controllers are the C++ control that the user can apply to the UHD-part of the design. In these files, the user can add more control over this layer of the design. Depending on the complexity of the block it may be possible to add all necessary control using NoCScript (more details on NoCScript can be found in the section labeled UHD Integration). In this case the cpp/hpp block control files generation are not needed. Default is to generate as their existence will be ignored if not edited.<br />
<br />
* '''Block Interface:''' Add more design specific functionality to the design at the GNU Radio interface by generating these block-interface files and adding necessary logic. Depending on the complexity of the block it may be possible to add all necessary control using NoC-Script. In this case the block-interface files are not needed. Default is to generate as their existence will be ignored if not edited.<br />
<br />
'''NOTE:''' If the user does not intend to use the block controllers or is not sure if they are needed, the presence of them in the design will do no harm. It is recommended to add them. This leaves the possibility to add more functions inside them in a future stage of development. <br />
<br />
After finishing the parsing, the following files will be generated/edited:<br />
<br />
Adding file 'lib/gain_impl.h'...<br />
Adding file 'lib/gain_impl.cc'...<br />
Adding file 'include/tutorial/gain.h'...<br />
Adding file 'include/tutorial/gain_block_ctrl.hpp'...<br />
Adding file 'lib/gain_block_ctrl_impl.cpp'...<br />
Editing swig/tutorial_swig.i...<br />
Adding file 'python/qa_gain.py'...<br />
Editing python/CMakeLists.txt...<br />
Adding file 'grc/tutorial_gain.xml'...<br />
Adding file 'rfnoc/blocks/gain.xml'...<br />
Adding file 'rfnoc/fpga-src/noc_block_gain.v'...<br />
rfnoc/testbenches/noc_block_gain_tb folder created<br />
Adding file 'rfnoc/testbenches/noc_block_gain_tb/noc_block_gain_tb.sv'...<br />
Adding file 'rfnoc/testbenches/noc_block_gain_tb/Makefile'...<br />
Adding file 'rfnoc/testbenches/noc_block_gain_tb/CMakeLists.txt'...<br />
<br />
==Creating FPGA portion of custom RFNoC Block==<br />
===RFNoC FPGA User Interface (API)===<br />
RFNoC blocks or Computation Engines (CEs) in the FPGA use a NoC Shell instance to interface with the rest of RFNoC. NoC Shell implements RFNoC's core functionality: packet muxing and demuxing, flow control, and the settings register bus (i.e. write/read control/status registers). The NoC Shell has an interface to the RFNoC AXI stream crossbar and a user interface. NoC Shell AXI stream interfaces expect CHDR packets with a proper header. See the manual for information on [https://files.ettus.com/manual/page_rtp.html CHDR and SID].<br />
<br />
'''NOTE:''' AXI Stream is an ARM AMBA standard interface. Xilinx has an [http://www.xilinx.com/support/documentation/ip_documentation/ug761_axi_reference_guide.pdf AXI Reference Guide] with more details on this standard.<br />
<br />
[[File:rfnoc gsg an 4.png|center|800px|]]<br />
<br />
Many designs will want to use an AXI Stream interface with only sample data. However, as stated earlier, the NoC Shell block expects CHDR packets. To ease interfacing user code, the AXI Wrapper block provides the necessary logic to strip and insert the CHDR header, effectively converting packetized sample data into streaming sample data and vice versa. The example RFNoC blocks <code>noc_block_fft.v</code> and <code>noc_block_fir.v</code> show how AXI Wrapper is used to implement existing Xilinx AXI Stream based IP within a computation engine.<br />
<br />
'''NOTE:''' AXI Wrapper also supports AXI Stream buses for configuration. These buses are driven via the setting register bus and do not have back pressure. They also consume two user register addresses per bus.<br />
<br />
The primary user interface consists of four AXI stream interfaces ( <code>tready, tvalid, tlast, tdata</code> ) and a settings register bus ( 8-bit, valid user register addresses: <code>128-255</code> ).<br />
<br />
<br />
{|<br />
|<br />
AXI Stream signals:<br />
* '''m_axis_data_tdata:''' Input sample data packets <br />
** Data coming from host or another CE<br />
* '''s_axis_data_tdata:''' Output sample data packets <br />
** Data going to another CE or host<br />
* '''m_axis_data_tready:''' Input signal to CE<br />
** Used to notify CE that downstream CE is ready for data <br />
* '''s_axis_data_tready:''' Output signal to CE<br />
** Used to notify upstream CE that CE is ready for data <br />
* '''m_axis_data_tvalid:''' Input signal to CE<br />
** Used to indicate upstream CE has valid data <br />
* '''s_axis_data_tvalid:''' Output signal to CE<br />
** Used to indicate to downstream CE that CE has valid data <br />
* '''m_axis_data_tlast:''' Input signal to CE<br />
** Used to delimit packets from upstream CE <br />
* '''s_axis_data_tlast:''' Output signal to CE<br />
** Used to delimit packets to downstream CE<br />
| style="vertical-align:top" |[[File:rfnoc gsg an 5.png|right|500px|]]<br />
|-<br />
|}<br />
<br />
[[File:rfnoc gsg an 6.png|center|800px|]]<br />
<br />
<br />
{|<br />
|<br />
Settings Bus signals:<br />
* '''set_stb:''' Assert to write '''set_data''' to register at '''set_addr'''ess<br />
* '''set_addr:''' Register address to set<br />
* '''set_data:''' Data to set<br />
* '''rb_data:''' Data to read back<br />
* '''rb_strobe:''' Assert to read '''rb_data''' from register at '''set_addr'''ess<br />
<br />
| style="vertical-align:top" |[[File:rfnoc gsg an 7.png|right|500px|]]<br />
|-<br />
|}<br />
For the <code>gain</code> example block the following architecture is desired:<br />
<br />
[[File:rfnoc gsg an 8.png|center|800px|]]<br />
<br />
Open the file <code>rfnoc-tutorial/rfnoc/fpga-src/noc_block_gain.v</code> that contains the RFNoC block skeleton code that was created when the <code>$ rfnocmodtool add gain</code> command was run and modify the following ('''BOLD''' indicates changes to the skeleton code).<br />
<br />
'''localparam [7:0] SR_GAIN = SR_USER_REG_BASE;'''<br />
localparam [7:0] SR_TEST_REG_1 = SR_USER_REG_BASE + 8'd1;<br />
<br />
'''wire [15:0] gain;'''<br />
'''setting_reg #('''<br />
'''.my_addr(SR_GAIN), .awidth(8), .width(16))'''<br />
'''sr_gain ('''<br />
'''.clk(ce_clk), .rst(ce_rst),'''<br />
'''.strobe(set_stb), .addr(set_addr), .in(set_data), .out(gain), .changed());'''<br />
<br />
always @(posedge ce_clk) begin<br />
case(rb_addr)<br />
'''8'd0 : rb_data <= {48'd0, gain};'''<br />
8'd1 : rb_data <= {32'd0, test_reg_1};<br />
default : rb_data <= 64'h0BADC0DE0BADC0DE;<br />
endcase<br />
end<br />
<br />
'''wire [31:0] pipe_in_tdata;'''<br />
'''wire pipe_in_tvalid, pipe_in_tlast;'''<br />
'''wire pipe_in_tready;'''<br />
<br />
'''wire [31:0] pipe_out_tdata;'''<br />
'''wire pipe_out_tvalid, pipe_out_tlast;'''<br />
'''wire pipe_out_tready;'''<br />
<br />
'''// Adding FIFO to ensure Pipeline'''<br />
'''axi_fifo_flop #(.WIDTH(32+1))'''<br />
'''pipeline0_axi_fifo_flop ('''<br />
'''.clk(ce_clk),'''<br />
'''.reset(ce_rst),'''<br />
'''.clear(clear_tx_seqnum),'''<br />
'''.i_tdata({m_axis_data_tlast,m_axis_data_tdata}),'''<br />
'''.i_tvalid(m_axis_data_tvalid),'''<br />
'''.i_tready(m_axis_data_tready),'''<br />
'''.o_tdata({pipe_in_tlast,pipe_in_tdata}),'''<br />
'''.o_tvalid(pipe_in_tvalid),'''<br />
'''.o_tready(pipe_in_tready));''' <br />
<br />
'''wire [15:0] i = pipe_in_tdata[31:16];'''<br />
'''wire [15:0] q = pipe_in_tdata[15:0];'''<br />
<br />
'''wire [31:0] i_mult_gain = i*gain;'''<br />
'''wire [31:0] q_mult_gain = q*gain;'''<br />
<br />
'''wire [31:0] mult_gain = {i_mult_gain[15:0], q_mult_gain[15:0]};'''<br />
'''axi_fifo_flop #(.WIDTH(32+1))'''<br />
'''pipeline1_axi_fifo_flop ('''<br />
'''.clk(ce_clk),'''<br />
'''.reset(ce_rst),'''<br />
'''.clear(clear_tx_seqnum),'''<br />
'''.i_tdata({pipe_in_tlast,mult_gain}),'''<br />
'''.i_tvalid(pipe_in_tvalid),'''<br />
'''.i_tready(pipe_in_tready),'''<br />
'''.o_tdata({pipe_out_tlast,pipe_out_tdata}),'''<br />
'''.o_tvalid(pipe_out_tvalid),'''<br />
'''.o_tready(pipe_out_tready));'''<br />
<br />
'''/* Output Signals */'''<br />
'''assign pipe_out_tready = s_axis_data_tready;'''<br />
'''assign s_axis_data_tvalid = pipe_out_tvalid;'''<br />
'''assign s_axis_data_tlast = pipe_out_tlast;'''<br />
'''assign s_axis_data_tdata = pipe_out_tdata;'''<br />
<br />
The following is a block diagram of the code created by the above Verilog:<br />
<br />
[[File:gain_block_diagram_v01.png|center|800px|]]<br />
<br />
'''NOTE:''' In order to meet timing, FIFO blocks were added to either side of the Multiplication process.<br />
<br />
===Creating and running HDL testbenches===<br />
In order to make the coding iteration process more efficient, it is recommended to create testbenches for all RFNoC blocks before compiling them into the FPGA image. This allows for flaw and/or bug detection early in the design. RFNoC Modtool provides the structure and files ( e.g. noc_block_{USER_BLOCK_NAME}_tb ) for the testbenches of each of the OOT blocks that are added with the <code>$ rfnocmodtool add</code> command.<br />
<br />
Below is a figure that shows the general testbench architecture that is created by the RFNoC Modtool. This architecture allows a user to test their custom block in the exact same environment it will be placed in when it is built into the RFNoC architecture. Other benefits of the testbench architecture include:<br />
* Testing through multiple blocks (e.g. FILTER -> FFT -> AVE) <br />
* Testing with multiple streams (e.g. RFNoC block ADD/SUB takes 2 streams, one that will have a constant added to it and one that will have a constant subtracted from it)<br />
* Data transfer abstraction (e.g. RFNoC Sim Lib API calls to <code>tb_streamer.send</code> and <code>tb_streamer.recv</code> which take care of all the AXI stream signaling)<br />
<br />
[[File:rfnoc gsg an 9.png|center|800px|]]<br />
<br />
'''NOTE:''' The <code>noc_block_tb</code> block is an instantiation of the <code>noc_block_export_io</code> that is used in testbenches to communicate to the RFNoC architecture. This makes it possible to talk “RFNoC” to the user’s custom block and as such the custom block has a complete RFNoC experience (signaling, flowcontrol, addressing, etc)<br />
<br />
From the [[Getting Started with RFNoC Development#Adding_custom_blocks_to_OOT_Module|Adding custom blocks to OOT Module section]] where the <code>gain</code> block was initially created, the last files generated were:<br />
<br />
rfnoc/testbenches/noc_block_gain_tb folder created<br />
Adding file 'rfnoc/testbenches/noc_block_gain_tb/noc_block_gain_tb.sv'...<br />
Adding file 'rfnoc/testbenches/noc_block_gain_tb/Makefile'...<br />
Adding file 'rfnoc/testbenches/noc_block_gain_tb/CMakeLists.txt'...<br />
<br />
<br />
The <code>noc_block_gain_tb</code> is a folder generated to contain all the files related to the test bench of the <code>gain</code> block. Each time a new OOT block is created, a new folder will be generated as well. <br />
<br />
Inside of this folder are the following three files:<br />
<br />
* <code>CMakeLists.txt:</code> this is an empty file used, so far, only to increase the scope of the compilers.<br />
* <code>noc_block_gain_tb.sv:</code> this is a ''System Verilog'' file, in which user custom tests are to be located. This is the '''only''' file that needs to be modified.<br />
* <code>Makefile:</code> This file determines the directives that run the simulation.<br />
<br />
<br />
The <code>noc_block_gain_tb.sv</code> testbench skeleton code creates the following architecture:<br />
<br />
[[File:testbench_arch_gain_v01.png|center|800px|]]<br />
<br />
Open the file <code>rfnoc-tutorial/rfnoc/testbenches/noc_block_gain_tb/noc_block_gain_tb.sv</code> and modify the following lines:<br />
<br />
Right under the “Verification” section:<br />
<br />
initial begin : tb_main<br />
string s;<br />
logic [31:0] random_word;<br />
logic [63:0] readback;<br />
'''logic [15:0] gain;'''<br />
<br />
In the “Test 4 -- Write / readback user registers” section:<br />
<br />
`TEST_CASE_START("Write / readback user registers");<br />
random_word = $random();<br />
'''tb_streamer.write_user_reg(sid_noc_block_gain, noc_block_gain.SR_GAIN, random_word[15:0]);'''<br />
'''tb_streamer.read_user_reg(sid_noc_block_gain, 0, readback);'''<br />
'''$sformat(s, "User register 0 incorrect readback! Expected: %0d, Actual %0d", readback[15:0], random_word[15:0]);'''<br />
'''`ASSERT_ERROR(readback[15:0] == random_word[15:0], s);'''<br />
<br />
In the “Test 5 -- Test sequence” section:<br />
<br />
`TEST_CASE_START("Test sequence");<br />
'''gain = 100;'''<br />
'''tb_streamer.write_user_reg(sid_noc_block_gain, noc_block_gain.SR_GAIN, gain);'''<br />
fork<br />
begin<br />
cvita_payload_t send_payload;<br />
for (int i = 0; i < SPP/2; i++) begin<br />
send_payload.push_back(64'(i));<br />
end<br />
tb_streamer.send(send_payload);<br />
end<br />
begin<br />
cvita_payload_t recv_payload;<br />
cvita_metadata_t md;<br />
logic [63:0] expected_value;<br />
tb_streamer.recv(recv_payload,md);<br />
for (int i = 0; i < SPP/2; i++) begin<br />
'''expected_value = i*gain;'''<br />
<br />
Test #4 verifies that we can write and readback the <code>gain</code> value. Test #5 writes to the <code>gain</code> register, sends a sample set in the form of a ramp (1, 2, 3, 4, etc) to the RFNoC gain block and finally reads the values from the <code>gain</code> block and compares them to expected values. The followings steps will allow the user to run this testbench.<br />
<br />
From within the <code>rfnoc-tutorial</code> directory, create a <code>build</code> directory and enter it by running:<br />
<br />
$ mkdir build && cd build/<br />
<br />
The next step is to run <code>cmake</code>. If PyBOMBS was used to create the development sandbox, <code>cmake</code> will automatically detect the location of the <code>fpga</code> repository. If PyBOMBS was not used, the user must provide the location of where the <code>fpga</code> repository is installed.<br />
<br />
If PyBOMBS used, run:<br />
<br />
$ cmake ../<br />
<br />
If PyBOMBS not used, run:<br />
<br />
$ cmake [-DUHD_FPGA_DIR=/PATH/TO/FPGA/REPOSITORY] ../<br />
<br />
Final output from the <code>$ cmake ../</code> command:<br />
<br />
-- Configuring done<br />
-- Generating done<br />
-- Build files have been written to: /home/widow/rfnoc/src/rfnoc-tutorial/build<br />
<br />
The following command will modify the necessary files and set the correct path to the simulation tools. From now on, every time a new block is added, this command will be run automatically. Remember, only run the following command once for each OOT module (not RFNoC block, but OOT module) created:<br />
<br />
$ make test_tb<br />
Scanning dependencies of target test_tb<br />
Built target test_tb<br />
<br />
Testbenches can be executed by running the command:<br />
<br />
$ make noc_block_[name_of_your_block]_tb <br />
<br />
The gain block testbench can be run by running the following command:<br />
<br />
$ make noc_block_gain_tb<br />
<br />
The simulation will start. Final output should look like this:<br />
<br />
<br />
========================================================<br />
TESTBENCH STARTED: noc_block_gain<br />
========================================================<br />
[TEST CASE 1] (t=000000000) BEGIN: Wait for Reset...<br />
[TEST CASE 1] (t=000001002) DONE... Passed<br />
[TEST CASE 2] (t=000001002) BEGIN: Check NoC ID...<br />
Read GAIN NOC ID: 1111222233334444<br />
[TEST CASE 2] (t=000001238) DONE... Passed<br />
[TEST CASE 3] (t=000001238) BEGIN: Connect RFNoC blocks...<br />
Connecting noc_block_tb (SID: 1:0) to noc_block_gain (SID: 0:0)<br />
Connecting noc_block_gain (SID: 0:0) to noc_block_tb (SID: 1:0)<br />
[TEST CASE 3] (t=000005457) DONE... Passed<br />
[TEST CASE 4] (t=000005457) BEGIN: Write / readback user registers...<br />
[TEST CASE 4] (t=000006888) DONE... Passed<br />
[TEST CASE 5] (t=000006888) BEGIN: Test sequence...<br />
[TEST CASE 5] (t=000007633) DONE... Passed<br />
========================================================<br />
'''TESTBENCH FINISHED: noc_block_gain'''<br />
''' - Time elapsed: 7700 ns''' <br />
''' - Tests Expected: 5'''<br />
''' - Tests Run: 5'''<br />
''' - Tests Passed: 5'''<br />
'''Result: PASSED''' <br />
========================================================<br />
$finish called at time : 7700 ns : File "/home/widow/rfnoc/src/rfnoc-tutorial/rfnoc/testbenches/noc_block_gain_tb/noc_block_gain_tb.sv" Line 10<br />
INFO: [USF-XSim-96] XSim completed. Design snapshot 'noc_block_gain_tb_behav' loaded.<br />
INFO: [USF-XSim-97] XSim simulation ran for 1000000000us<br />
launch_simulation: Time (s): cpu = 00:00:10 ; elapsed = 00:00:12 . Memory (MB): peak = 966.387 ; gain = 54.848 ; free physical = 3080 ; free virtual = 29888<br />
# if [string equal $vivado_mode "batch"] {<br />
# puts "BUILDER: Closing project"<br />
# close_project<br />
# } else {<br />
# puts "BUILDER: In GUI mode. Leaving project open."<br />
# }<br />
BUILDER: Closing project<br />
****** Webtalk v2015.4 (64-bit)<br />
**** SW Build 1412921 on Wed Nov 18 09:44:32 MST 2015<br />
**** IP Build 1412160 on Tue Nov 17 13:47:24 MST 2015<br />
** Copyright 1986-2015 Xilinx, Inc. All Rights Reserved.<br />
<br />
source /home/widow/rfnoc/src/rfnoc-tutorial/rfnoc/testbenches/noc_block_gain_tb/xsim_proj/xsim_proj.hw/webtalk/labtool_webtalk.tcl -notrace<br />
INFO: [Common 17-206] Exiting Webtalk at Tue Jan 10 23:26:20 2017...<br />
INFO: [Common 17-206] Exiting Vivado at Tue Jan 10 23:26:22 2017...<br />
Built target noc_block_gain_tb<br />
<br />
<br />
<br />
With every custom block created, a <code>make</code> directive will be available to run the simulation from the <code>build</code> directory.<br />
<br />
===Building the FPGA image with a custom user block===<br />
In this section steps are given on how to initiate an FPGA build while incorporating the user’s custom RFNoC block. The first sections give general information on building RFNoC images. The remaining two sections show how to initiate FPGA builds using a command line interface and using a graphical interface (coming out soon), respectively.<br />
<br />
====Discussion on number of blocks in an FPGA image====<br />
There is a maximum number of blocks that can be added for each device. The maximum amount of computation engines (CEs/RFNoC blocks) that each device can use is 16, but the amount of custom blocks that can be added depends on the device. <br />
<br />
If using a device from the X3xx series, from the 16 CEs, there are 6 that will be always added and are not subject to direct customization: 1 CE for the AXI bus, 1 CE for the Ethernet Interface, 2 Radios and 2 Dma FIFOS. Because of this, the application will only allow a number of 10 custom blocks on the X3xx series. <br />
<br />
If using a device from the E3xx series, 2 CE engines are always added and are not subject to direct customization: 1 CE for the AXI bus and 1 Radio. This would virtually allow 14 slots for custom blocks. However, given the size of the FPGA on the E3xx series of devices, the application only allows a number of 6 custom blocks. <br />
<br />
'''NOTE:''' Blocks with higher resource utilization may fill up the FPGA and force the user to include less blocks.<br />
<br />
Verify the current maximum values by running the <code>uhd_images_builder.py</code> utility from the scripts directory.<br />
<br />
$ cd {USER_PREFIX}/src/uhd-fpga/usrp3/tools/scripts<br />
$ uhd_image_builder.py --help<br />
<br />
====Discussion on FPGA image targets====<br />
RFNoC target names follow the pattern <code>{DEVICE}_RFNOC_{BUILD_TYPE}</code> with the following build types: <br />
<br />
* <code>HG:</code> 1GigE on SFP+ Port0, 10Gig on SFP+ Port<br />
* <code>XG:</code> 10GigE on both SFP+ ports<br />
* <code>HLS:</code> Vivado High Level Synthesis enabled<br />
* <code>sgX:</code> Speed grade for E300 devices (1 or 3)<br />
<br />
Some examples are:<br />
* <code>X310_RFNOC_HG</code><br />
* <code>X300_RFNOC_HG</code><br />
* <code>X310_RFNOC_XG</code><br />
* <code>X300_RFNOC_XG</code><br />
* <code>X310_RFNOC_HLS_HG</code><br />
* <code>X300_RFNOC_HLS_HG</code><br />
* <code>E310_RFNOC</code> (this is for the speed grade 1 FPGA version of E310, append <code>_sg3</code> for speed grade 3)<br />
<br />
'''NOTE:''' E310, E312 and E313 all have the same FPGA hardware and therefore will use the <code>E310_RFNOC_{BUILD_TYPE}</code> target. USRP E3xx devices have either <code>sg1</code> or <code>sg3</code> hardware, please visit [http://files.ettus.com/e3xx_images/README here] to find out how to differentiate.<br />
<br />
Additional information about the build targets can be found at the build instructions for USRP3, found [http://files.ettus.com/manual/md_usrp3_build_instructions.html here].<br />
<br />
====Image building using the command line====<br />
The script <code>uhd_image_builder.py</code> is used to generate the NoC block instantiation file and build the FPGA image. Run the help menu by typing:<br />
<br />
$ cd {USER_PREFIX}/src/uhd-fpga/usrp3/tools/scripts<br />
$ ./uhd_image_builder.py --help<br />
<br />
usage: uhd_image_builder.py [-h] [-I INCLUDE_DIR [INCLUDE_DIR ...]]<br />
[-m MAX_NUM_BLOCKS] [--fill-with-fifos]<br />
[-o OUTFILE] [-d DEVICE] [-t TARGET] [-g] [-c]<br />
[blocks [blocks ...]]<br />
<br />
Generate the NoC block instantiation file<br />
<br />
positional arguments:<br />
blocks List block names to instantiate.<br />
<br />
optional arguments:<br />
-h, --help show this help message and exit<br />
-I INCLUDE_DIR [INCLUDE_DIR ...], --include-dir INCLUDE_DIR [INCLUDE_DIR ...]<br />
Path directory of the RFNoC Out-of-Tree module<br />
-m MAX_NUM_BLOCKS, --max-num-blocks MAX_NUM_BLOCKS<br />
Maximum number of blocks (Max. Allowed for x310|x300:<br />
10, for e300: 6)<br />
--fill-with-fifos If the number of blocks provided was smaller than the<br />
max number, fill the rest with FIFOs<br />
-o OUTFILE, --outfile OUTFILE<br />
Output /path/filename - By running this directive, you<br />
won't build your IP<br />
-d DEVICE, --device DEVICE<br />
Device to be programmed [x300, x310, e310]<br />
-t TARGET, --target TARGET<br />
Build target - image type [X3X0_RFNOC_HG,<br />
X3X0_RFNOC_XG, E310_RFNOC_sg3...]<br />
-g, --GUI Open Vivado GUI during the FPGA building process<br />
-c, --clean-all Cleans the IP before a new build<br />
<br />
<br />
Here are details on the usage of the script which is followed by an example:<br />
<br />
'''Blocks:''' The first arguments are the names of RFNoC blocks that the user wants to have compiled into the new image which are separated by a space. They can be custom blocks from the user’s OOT module or from the ones that are provided from Ettus, or a combination. Blocks provided by Ettus Research are listed (among other sources necessary for the FPGA build) in the <code>{USER_PREFIX}/src/uhd-fpga/usrp3/lib/rfnoc/Makefile.srcs</code> file. <br />
<br />
These blocks can be identified by the following pattern: <br />
<br />
noc_block_{NAME}.v<br />
<br />
However, as all the RFNoC blocks have the same <code>noc_block_</code> prefix, for simplicity this prefix is omitted when listing the blocks in the <code>uhd_image_builder.py</code> utility. As an example of the incorrect and correct way of adding blocks, consider the following examples when adding the <code>noc_block_null_source_sink</code> and <code>noc_block_siggen</code> blocks:<br />
<br />
Incorrect method: <br />
<br />
$ ./uhd_image_builder.py noc_block_null_source_sink noc_block_siggen ...<br />
<br />
Correct method:<br />
<br />
$ ./uhd_image_builder.py null_source_sink siggen ...<br />
<br />
'''NOTE:''' Blocks generated by the RFNoC Modtool follow the same naming convention.<br />
<br />
There is an increasing list of pre-built blocks. Here is a sample:<br />
<br />
* <code>axi_fifo_loopback</code><br />
* <code>axi_dma_fifo</code><br />
* <code>fir_filter</code><br />
* <code>fft</code><br />
* <code>null_source_sink</code><br />
* <code>schmidl_cox</code><br />
* <code>packet_resizer</code><br />
* <code>split_stream</code><br />
* <code>vector_iir</code><br />
* <code>addsub</code><br />
* <code>window</code><br />
* <code>keep_one_in_n</code><br />
* <code>pfb</code><br />
* <code>export_io</code><br />
* <code>conv_encoder_qpsk</code><br />
* <code>siggen</code><br />
* <code>logpwr</code><br />
* <code>fosphor</code><br />
* <code>moving_avg</code><br />
* <code>ddc</code><br />
* <code>duc</code><br />
<br />
<br />
RFNoC related blocks generally reside in <code>fpga/usrp3/lib/rfnoc/</code>.<br />
<br />
{| class="wikitable" style="margin:auto;"<br />
<br />
!Block<br />
!Filename<br />
!Description<br />
|-<br />
<br />
|FIFO<br />
|[https://github.com/EttusResearch/fpga/blob/maint/usrp3/lib/rfnoc/noc_block_axi_fifo_loopback.v noc_block_axi_fifo_loopback.v]<br />
|Simple FIFO loopback / passthrough block.<br />
|-<br />
<br />
|FFT<br />
|[https://github.com/EttusResearch/fpga/blob/maint/usrp3/lib/rfnoc/noc_block_fft.v noc_block_fft.v]<br />
|Xilinx coregen based Fast Fourier Transform up to length 4096.<br />
|-<br />
<br />
|FIR<br />
|[https://github.com/EttusResearch/fpga/blob/maint/usrp3/lib/rfnoc/noc_block_fir_filter.v noc_block_fir_filter.v]<br />
|Xilinx coregen based Finite Impulse Response Filter, 41 taps, reconfigurable tap coefficients.<br />
|-<br />
<br />
<br />
|Window<br />
|[https://github.com/EttusResearch/fpga/blob/maint/usrp3/lib/rfnoc/noc_block_window.v noc_block_window.v]<br />
|Windowing block for use with FFT block.<br />
|-<br />
<br />
|Vector IIR<br />
|[https://github.com/EttusResearch/fpga/blob/maint/usrp3/lib/rfnoc/noc_block_vector_iir.v noc_block_vector_iir.v]<br />
|Single pole IIR with configurable coefficients that filters data along vectors (i.e. parallel streams of samples). Useful with FFT output.<br />
|-<br />
<br />
|Keep One in N<br />
|[https://github.com/EttusResearch/fpga/blob/maint/usrp3/lib/rfnoc/noc_block_keep_one_in_n.v noc_block_keep_one_in_n.v]<br />
|Keeps one packet every N packets.<br />
|-<br />
<br />
|AddSub<br />
|[https://github.com/EttusResearch/fpga/blob/maint/usrp3/lib/rfnoc/noc_block_addsub.v noc_block_addsub.v]<br />
|Example of using multiple block ports in a single RFNoC block to add and subtract streams.<br />
|-<br />
<br />
|Null Source Sink<br />
|[https://github.com/EttusResearch/fpga/blob/maint/usrp3/lib/rfnoc/noc_block_null_source_sink.v noc_block_null_source_sink.v]<br />
|Generates dummy packets and can consume packets at a configurable rate. Useful for testing.<br />
|-<br />
<br />
|Packet Resizer<br />
|[https://github.com/EttusResearch/fpga/blob/maint/usrp3/lib/rfnoc/noc_block_packet_resizer.v noc_block_packet_resizer.v]<br />
|Resizes input packets to a configurable size (larger or smaller than source packets).<br />
|-<br />
<br />
|Split Stream<br />
|[https://github.com/EttusResearch/fpga/blob/maint/usrp3/lib/rfnoc/noc_block_split_stream.v noc_block_split_stream.v]<br />
|Replicates an input stream to a configurable number of output streams.<br />
|-<br />
<br />
<br />
|}<br />
<br />
<br />
'''NOTE:''' There is a restriction on the amount of blocks that can added into the FPGA image, see the section in this Application Note labeled [[Getting_Started_with_RFNoC_Development#Discussion_on_number_of_blocks_in_an_FPGA_image|Discussion on number of blocks in an FPGA image]] for more information. <br />
<br />
<code>-I INCLUDE_DIR:</code> The <code>-I</code> directive provides the path to top OOT directory, which contains the users <code>rfnoc/fpga-src</code> directory which contains the custom blocks. This path is needed by the Xilinx Vivado tool. Inside the <code>fpga-src</code> directory there is a file called <code>Makefile.srcs</code> that contains the path of the OOT module and a list of all the custom OOT blocks. This is an auto generated file, which is amended every time a new block is added to the OOT module. Manually modifying this file is not recommended. If there are multiple OOT modules with various custom blocks that reside in different directories the way to include them all is by separating the different paths by a space (e.g. <code>-I /first/OOT/path/ /second/OOT/path/</code>).<br />
<br />
'''IMPORTANT:''' Please be sure to terminate the path of your OOT with the "/" character. Otherwise the path might not be recognized.<br />
<br />
<code>-d DEVICE:</code> The <code>-d</code> directive directs the script on which USRP device the build is for. If no <code>–d</code> is included the default is <code>–d x310</code>. Generation-3 USRPs and above all support RFNoC.<br />
<br />
<code>-t TARGET:</code> The <code>–t</code> directive directs the script on which type of image to build for the chosen device. With each USRP device there are several build options to choose from. Detailed information about the build targets can be found at the build instructions for USRP3, found [http://files.ettus.com/manual/md_usrp3_build_instructions.html here]. If <code>-t</code> is not included, a default target will be chosen for the given device. For example, the default <code>X310_RFNOC_HG</code> target builds for the <code>–d x310</code> device. More details on targets can be found in the section of this Application Note labeled [[Getting Started with RFNoC Development#Discussion_on_FPGA_image_targets|Discussion on FPGA image targets]].<br />
<br />
<code>-m MAX_NUM_BLOCKS:</code> The <code>–m</code> directive specifies the max number of RFNoC blocks to build on the FPGA image. An RFNoC image does not need to fill all available slots with RFNoC blocks.<br />
<br />
<code>--fill-with-fifos:</code> The <code>--fill-with-fifos</code> directive will fill the empty RFNoC block slots with FIFOS. As an example, if a user indicates three RFNoC blocks by name and also specifies <code>–m 5</code> then the other two slots will be filed with FIFOs. <br />
<br />
<code>-o OUTFILE:</code> With the <code>-o</code> directive, the RFNoC blocks instantiation file is generated and saved at the desired path with the given name for the user to inspect. The FPGA image will NOT build if this directive is provided. The purpose of the <code>uhd_image_builder.py</code> script is to auto generate an instantiation file and populate the source files needed for the Xilinx Vivado tool to build the FPGA image, however, it may be desirable to only see the effect of adding a custom OOT module in the <code>fpga/</code> directory, or for inspecting the instantiation file. When the directive is not provided the <code>rfnoc_ce_auto_inst_x3x0.v</code> file is overwritten and the FPGA image build process will start automatically (standard use).<br />
<br />
<code>-g, --GUI:</code> Open Vivado GUI during the FPGA building process<br />
<br />
<code>-c, --clean-all:</code> Cleans the IP before a new build<br />
<br />
Here is how to create an X310 FPGA image incorporating the <code>gain</code> block that was created earlier in this Application Note:<br />
<br />
$ cd {USER_PREFIX}/src/uhd-fpga/usrp3/tools/scripts <br />
$ ./uhd_image_builder.py gain ddc fft -I {USER_PREFIX}/src/rfnoc-tutorial/ -d x310 -t X310_RFNOC_HG -m 6 --fill-with-fifos<br />
<br />
<br />
At the end of a successful compilation process, write the new image to a USRP. The following command will load the new image. Update the <code>{IP_Address}</code> of the USRP and <code>{USER_PREFIX}</code> to the appropriate values for your configuration before running the command.<br />
<br />
$ uhd_image_loader --args "type=x300,addr={IP_ADDRESS}" --fpga-path {USER_PREFIX}/src/uhd-fpga/usrp3/top/x300/build/usrp_x310_fpga_RFNOC_HG.bit<br />
<br />
'''NOTE:''' <br />
* The FPGA image building process may take over an hour.<br />
<br />
* FPGA images are specific to the USRP device NOT the USRP series. For example, a USRP X300 FPGA image will '''NOT''' work on a USRP X310 and vice versa. Loading an image that does not correspond to a USRP device will likely brick the device. Additional instructions on flashing a custom image to a device can be found [http://files.ettus.com/manual/page_usrp_x3x0.html#x3x0_load_fpga_imgs here] for X3xx series and [http://files.ettus.com/manual/page_usrp_e3x0.html#e3x0_load_fpga_imgs here] for E3xx series.<br />
<br />
* [Environment setup] - The <code>uhd_image_builder.py</code> script will also set up the Xilinx Vivado environment by automatically running the <code>setupenv.sh</code> script located in the <code>{USER_PREFIX}/src/uhd-fpga/usrp3/top/{device}</code> directory. The <code>setupenv.sh</code> script assumes that Xilinx Vivado is installed in the default location of <code>/opt/Xilinx/Vivado</code>. If the installation is in a different directory the <code>setupenv_base.sh</code> script will need to be modified. The script is located at: <code>{USER_PREFIX}/src/uhd-fpga/usrp3/tools/scripts/setupenv_base.sh</code><br />
<br />
Besides the custom <code>gain</code> block, a <code>DDC</code> and <code>FFT</code> block are also being added along with three <code>FIFOs</code>. The <code>DDC</code>, <code>FFT</code> and <code>FIFO</code> blocks are already in the script's path and therefore do not need their path specified (they ship with the Ettus Research FPGA code). The reason three FIFOs are added is because the max number of blocks was specified to be 6 ( <code>-m 6</code> ) and since only 3 blocks were specifically named the other three slots are filled with FIFOs.<br />
<br />
<br />
[[File:rfnoc gsg an 10.png|center|800px|]]<br />
<br />
'''NOTE:''' Instructions on flashing the image to a device can be found [http://files.ettus.com/manual/page_usrp_x3x0.html#x3x0_load_fpga_imgs here] for X3xx series and [http://files.ettus.com/manual/page_usrp_e3x0.html#e3x0_load_fpga_imgs here] for E3xx series. FPGA images are specific to the USRP device '''NOT''' the USRP series. For example, a USRP X300 FPGA image will '''NOT''' work on a USRP X310 and vice versa. Loading an image that does not correspond to a USRP device will likely brick the device. <br />
<br />
Once the newly compiled image is loaded onto a USRP X3xx running the following command will show what RFNoC blocks are available on the FPGA:<br />
<br />
$ uhd_usrp_probe <br />
<br />
<br />
| | _____________________________________________________<br />
| | /<br />
| | | RFNoC blocks on this device:<br />
| | | <br />
| | | * DmaFIFO_0<br />
| | | * Radio_0<br />
| | | * Radio_1<br />
| | | * '''Block_0'''<br />
| | | * DDC_0<br />
| | | * FFT_0<br />
| | | * FIFO_0<br />
| | | * FIFO_1<br />
| | | * FIFO_2<br />
<br />
<br />
'''NOTE:''' The reason the custom block is called <code>Block_0</code> and not <code>gain_0</code> is because there is still host side software/files that need updated in order for this block to populate it’s proper name. A following section (UHD Integration) will step through the process of updating those host side files.<br />
<br />
====Using a graphical interface====<br />
A graphical user interface for FPGA generation and building is shipped along with the <code>uhd_image_builder.py</code> script. This intuitive application aids in setting up a custom FPGA build. <br />
<br />
This utility is located in the same <code>scripts</code> directory as <code>uhd_image_builder.py</code>. <br />
<br />
To run it, enter the following commands:<br />
<br />
$ cd {USER_PREFIX}/src/uhd-fpga/usrp3/tools/scripts/<br />
$ ./uhd_image_builder_gui<br />
<br />
The application will then be launched:<br />
<br />
[[File:rfnoc gsg an 11.png|center|800px|]]<br />
<br />
'''1. Select build target:''' In this panel the available build targets are listed. This list may vary depending on which branch of the FPGA repository this user is using. Only RFNoC targets are listed. The build type descriptions are:<br />
<br />
* <code>HG:</code> 1GigE on SFP+ Port0, 10Gig on SFP+ Port1<br />
* <code>XG:</code> 10GigE on both SFP+ ports<br />
* <code>HLS:</code> Vivado High Level Synthesis enabled<br />
* <code>sgX:</code> Speed grade for E300 devices (1 or 3)<br />
<br />
'''2. List of blocks available:''' In this panel the available blocks are listed that can be included into a custom design. This list separates the RFNoC blocks provided by Ettus Research and the OOT modules and corresponding blocks that the user adds. Given the hardware differences between the X3xx and E3xx devices, this list will dynamically change when a different device is selected from the panel on the left. This implies that it is necessary to add the OOT modules for each device independently. This is accomplished by using the <code>Add OOT Blocks</code> feature of the application, details of which are explained at #7 (<code>Add OOT Blocks</code>).<br />
<br />
'''3. Blocks in current design:''' This section gives information on the MAX number of blocks for a given USRP (based on the target selection). There is a maximum number of blocks that can be added for each device. See the section in this App Note labeled "Discussion on number of blocks in an FPGA image" for more information.<br />
<br />
'''4. Blocks in current design:''' This panel will be populated by adding elements from the available blocks. All the blocks listed in here will be compiled into the FPGA custom image. There is a maximum number of blocks that can be added for each device. See the section in this App Note labeled "Discussion on number of blocks in an FPGA image" for more information. <br />
<br />
'''5. Add button (>>):''' Manually add the blocks from the central panel into your design.<br />
<br />
'''6. Remove button (<<):''' Remove blocks from the current design (far-left panel)<br />
<br />
'''7. Fill with FIFOs:''' By checking this box, the design will fill any available/unspecified block slots with FIFOs. The number of FIFO blocks that will be instantiated is based on the rules of amount of blocks explained at #3. When less than the max amount of blocks are needed for certain implementation, many users choose to fill their design with FIFO blocks. <br />
<br />
'''8. Open Vivado GUI:''' Open Vivado GUI during the FPGA building process. This allows the user to save a Vivado project with all IP and work within the Vivado GUI for development.<br />
<br />
'''9. Clean IP:''' Cleans the IP before a new build (recompiles all IP).<br />
<br />
'''10. Add OOT blocks:''' Manually add RFNoC Modtool-generated OOT modules by pointing the application to the <code>Makefile.srcs</code> file, which is located in the <code>{USER_PREFIX}/src/{USER-OOT-moddir}/rfnoc/fpga-srcs/</code> directory. After adding this file, blocks will appear under “<code>OOT blocks for XXXX devices</code>”<br />
<br />
'''11. Show Instantiation File:''' The application auto-generates the instantiation file that is going to be used by Vivado to build the FPGA image. This instantiation file can be viewed and edited before starting the build by clicking this button. <br />
<br />
'''12. Import from GRC:''' If the user has a GNU Radio flowgraph with RFNoC blocks already in it, this application can read what RFNoC blocks are in the flowgraph and populate the <code>Blocks in current design</code> section of the application with the necessary RFNoC blocks. '''NOTE:''' All RFNoC blocks pulled from a <code>.grc</code> file must be in the of <code>List of blocks available</code> before beginning the build.<br />
<br />
'''13. Generate .bit file:''' Start the build by clicking this button. <br />
<br />
'''14. uhd_image_builder command:''' The command line command with arguments is dynamically build here as the user selects different options. The user could save this command to use next time they build/compile an FPGA image to avoid having to select all options again. <br />
<br />
'''NOTE:''' See the latter end of the previous section for additional information on what to expect once the compile has started as well as final output.<br />
<br />
==Creating Software/Host portion of custom RFNoC Block==<br />
Now that the FPGA portion is complete the next step is to add software integration to UHD and GNU Radio as depicted in the RFNoC Stack below.<br />
<br />
[[File:rfnoc gsg an 12.png|center|800px|]]<br />
<br />
===UHD integration===<br />
Despite the data processing happening on the FPGA, the host software still has a lot of responsibilities in order for an RFNoC application to function. For example, it needs to know which settings registers are available within an RFNoC block, or what kind of input and output a block has. All of this information goes into the <code>Block Declaration</code>, which is an XML file that is readable by UHD. Often, some simple logic needs to be embedded in the XML file, which we can do by using a simple scripting language called Noc-Script. Changes to the block declaration file are immediately imported into UHD every time an application is executed, and therefore, no software development toolchain needs to be set up.<br />
<br />
The list of things declared by the block declaration file includes:<br />
<br />
* Block name and Noc-ID<br />
* Registers<br />
* Inputs and outputs (including types)<br />
<br />
In some cases, additional C++ code is required to properly control a block from software. In this case, a <code>Block Controller</code> file is required as well as the declaration file. In most cases, the default block controller provided by UHD is sufficient, so no C++ code needs to be written. Writing custom block controllers requires more effort, and means having to set up a programming toolchain. A common reason to write custom C++ block controllers is if setting a register requires a lot of computation, which is not feasible to do within a block declaration file (e.g., using Noc-Script).<br />
<br />
Skeleton code for both the block declaration and the block controller (if required) can be generated through RFNoC Modtool.<br />
<br />
Because the <code>gain</code> block does not require anything other than simply reading and writing to a single register the default block controller will suffice for this example. However, we will need to add information about the register.<br />
<br />
Open the <code>gain.xml</code> file located in the <code>/rfnoc-tutorial/rfnoc/blocks</code> directory and add the following:<br />
<br />
<br />
<?xml version="1.0"?><br />
<nowiki><!--Default XML file--></nowiki><br />
<nocblock><br />
<name>gain</name><br />
<blockname>gain</blockname><br />
<ids><br />
<id revision="0">1111222233334444</id><br />
</ids><br />
'''<nowiki><!-- Registers --></nowiki>'''<br />
'''<registers>'''<br />
'''<setreg>'''<br />
'''<name>GAIN</name>'''<br />
'''<address>128</address>'''<br />
'''</setreg>'''<br />
'''</registers>'''<br />
'''<nowiki><!-- Args --></nowiki>'''<br />
'''<args>'''<br />
'''<arg>'''<br />
'''<name>gain</name>'''<br />
'''<type>double</type>'''<br />
'''<value>1.0</value>'''<br />
'''<check>GE($gain, 0.0) AND LE($gain, 32767.0)</check>'''<br />
'''<check_message>Invalid gain.</check_message>'''<br />
'''<action>'''<br />
'''SR_WRITE("GAIN", IROUND($gain))'''<br />
'''</action>'''<br />
'''</arg>'''<br />
'''</args>'''<br />
<nowiki><!--One input, one output. If this is used, better have all the info the C++ file.--></nowiki><br />
<ports><br />
<sink><br />
'''<name>in0</name>'''<br />
'''<type>sc16</type>'''<br />
</sink><br />
<nowiki><source></nowiki><br />
'''<name>out0</name>'''<br />
'''<type>sc16</type>'''<br />
<nowiki></source></nowiki><br />
</ports><br />
</nocblock><br />
<br />
<br />
===GNU Radio Integration===<br />
GNU Radio is built around the concept of blocks, similarly to RFNoC. When mapping RFNoC into an application, the simple constraint is made that every RFNoC block maps to a single GNU Radio block. Thus, when creating mixed GNU Radio/RFNoC applications, there is a very clear 1:1 mapping between what’s happening in RFNoC and GNU Radio.<br />
<br />
Since most RFNoC blocks behave very similar to one another from GNU Radio’s perspective, it is generally not required to write C++ code for another block. Rather, a default block provided by RFNoC can be used with appropriate configuration. However, in some cases it may be desirable or even necessary to write a custom GNU Radio block for more specific controlling of the underlying RFNoC block. GNU Radio allows writing blocks in either C++ or Python, but since UHD and RFNoC do not have a Python API, a custom wrapper for an RFNoC block needs to be written in C++. RFNoC Modtool will create skeleton files for this purpose.<br />
<br />
The most popular and effective way to use GNU Radio is through the graphical interface, the GNU Radio Companion (GRC). GRC requires a separate description of every GNU Radio block in order to become available in the graphical UI, and the same is true for an RFNoC block that is wrapped in a GNU Radio block (even if the generic RFNoC block wrapper is used). For GNU Radio 3.7 and earlier, GRC bindings for blocks are written as XML files with interspersed Cheetah or Python statements. For a more detailed tutorial on how to write these files, refer to the [http://gnuradio.org/redmine/projects/gnuradio/wiki GNU Radio Documentation] and associated [http://gnuradio.org/redmine/projects/gnuradio/wiki/Guided_Tutorials tutorials].<br />
<br />
====GNU Radio Block Code====<br />
<br />
* C++ or Python, although RFNoC blocks need to be written in C++ (if at all)<br />
* How does GNU Radio interface to RFNoC?<br />
** via C++ infrastructure code in <code>gr-ettus</code><br />
** <code>gr-ettus</code> provides a base RFNoC block class<br />
** Users extend base class for their RFNoC blocks<br />
** Many blocks can use base class “as is”<br />
** No C++ or Python code!<br />
* <code>rfnoc-tutorial/lib/gain_impl.cc</code><br />
** The gain block does not need anything additional<br />
<br />
====GNU Radio Companion Bindings====<br />
* XML<br />
* Describes GNU Radio blocks to GRC<br />
* No recompilation<br />
* Requirement of GNU Radio Companion<br />
* Not strictly necessary for GNU Radio<br />
* Tutorial on how to write them:<br />
** [http://gnuradio.org/redmine/projects/gnuradio/wiki/GNURadioCompanion http://gnuradio.org/redmine/projects/gnuradio/wiki/GNURadioCompanion ]<br />
* Skeleton file generated by RFNoC Modtool<br />
<br />
<br />
Open the <code>tutorial-gain.xml</code> file located in the <code>rfnoc-tutorial/grc</code> directory and edit as follows:<br />
<br />
<br />
<br />
<nowiki><?xml version="1.0"?></nowiki><br />
<block><br />
<name>RFNoC: gain</name><br />
<key>tutorial_gain</key><br />
<category>tutorial</category><br />
<import>import tutorial</import><br />
<make>tutorial.gain(<br />
self.device3,<br />
uhd.stream_args( \# TX Stream Args<br />
cpu_format="'''fc32'''",<br />
otw_format="'''sc16'''",<br />
args="gr_vlen={0},{1}".format(${grvlen}, "" if $grvlen == 1 else "spp={0}".format($grvlen)),<br />
),<br />
uhd.stream_args( \# RX Stream Args<br />
cpu_format="'''fc32'''",<br />
otw_format="'''sc16'''",<br />
args="gr_vlen={0},{1}".format(${grvlen}, "" if $grvlen == 1 else "spp={0}".format($grvlen)),<br />
),<br />
$block_index, $device_index,<br />
)<br />
'''self.$(id).set_arg("gain", $gain)'''<br />
'''</make>'''<br />
'''<callback>set_arg("gain", $gain)</callback>'''<br />
<nowiki><!-- Make one 'param' node for every Parameter you want settable from the GUI.<br />
Sub-nodes:<br />
* name<br />
* key (makes the value accessible as $keyname, e.g. in the make node)<br />
* type --></nowiki><br />
<br />
. <br />
.<br />
.<br />
<br />
<option><br />
<name>Byte</name><br />
<key>u8</key><br />
</option><br />
</param><br />
<param><br />
<name>'''Gain'''</name><br />
<key>'''gain'''</key><br />
'''<value>1.0</value>'''<br />
<type>'''real'''</type><br />
</param><br />
<br />
<nowiki><!-- Make one 'sink' node per input. Sub-nodes:<br />
* name (an identifier for the GUI)<br />
* type<br />
* vlen<br />
* optional (set to 1 for optional inputs) --></nowiki><br />
<sink><br />
<name>in</name><br />
<type>'''complex'''</type><br />
<vlen>$grvlen</vlen><br />
<domain>rfnoc</domain><br />
</sink><br />
<br />
<nowiki><!-- Make one 'source' node per output. Sub-nodes:<br />
* name (an identifier for the GUI)<br />
* type<br />
* vlen<br />
* optional (set to 1 for optional inputs) --></nowiki><br />
<nowiki><source></nowiki><br />
<name>out</name><br />
<type>'''complex'''</type><br />
<vlen>$grvlen</vlen><br />
<domain>rfnoc</domain><br />
<nowiki></source></nowiki><br />
</block><br />
<br />
<br />
'''NOTE:''' Indentation spacing is important in the <code><make></code> section.<br />
<br />
===Compile, Install and Verify===<br />
<br />
$ cd {USER_PREFIX}/src/rfnoc-tutorial/build<br />
$ make install<br />
<br />
$ uhd_usrp_probe <br />
<br />
| | _____________________________________________________<br />
| | /<br />
| | | RFNoC blocks on this device:<br />
| | | <br />
| | | * DmaFIFO_0<br />
| | | * Radio_0<br />
| | | * Radio_1<br />
| | | * '''gain_0'''<br />
| | | * DDC_0<br />
| | | * FFT_0<br />
| | | * FIFO_0<br />
| | | * FIFO_1<br />
| | | * FIFO_2<br />
<br />
'''NOTE:''' In the case where the <code>gain_0</code> does not appear but <code>Block_0</code> does: Most likely, the XML block declaration file (see [[Getting_Started_with_RFNoC_Development#UHD_integration|UHD Integration]] section) for the block contains a NoC-ID that does not match with any NoC-ID defined in the hardware part of the design. The user has to be certain that the description files are up-to-date and that the NoC-ID matches in the SW and HW side. See the [[Getting_Started_with_RFNoC_Development#UHD_integration|UHD Integration]] section to update those host side files.<br />
<br />
==Testing out the custom block==<br />
At this point the custom <code>gain</code> RFNoc Block (Computation Engine) can be used within a GNU Radio flowgraph. Below is an example GRC flowgraph using our new block as well as the output application it produces. <br />
<br />
[[File:rfnoc gsg an 13.png|center|800px|]]<br />
<br />
'''NOTE:''' Copy Block: In the RFNoC domain, streams of data can not be split as easily as they are in the GNU Radio domain. The “copy” block depicted in the screenshot above serves the function as a stream splitter . It’s main purpose, when “enabled”, is to copy the samples it is getting at its input and putting then into the output, but here it is also serving as a boundary between a RFNoC-domain and a GNURadio-domain. In the flowgraph above. after this boundary is passed, the data stream can easily be split into the two sinks to have them run simultaneously (standard GNU Radio functionality). It is possible to connect the GNU Radio blocks directly to RFNoC blocks without a “copy” block, but only one would work at a time (the other ones would have to be disabled). Another way to split data streams from the RFNoC-domain is to use the ”RFNoC: split stream” block, which would split the streams in the RFNoC domain, but this is not very useful here as we are, in any case, moving into the GNURadio-domain.<br />
<br />
[[File:rfnoc gsg an 14.png|center|800px|]]<br />
<br />
==Troubleshooting==<br />
===Xilinx Vivado===<br />
====Compile issues====<br />
=====Synthesis is failing=====<br />
Verify all the correct Xilinx [[Getting Started with RFNoC Development#Prerequisites|prerequisite software]] is installed.<br />
<br />
Additional helpful information can be found in the following Xilinx forum posts:<br />
* https://forums.xilinx.com/t5/Synthesis/Synthesis-failed-without-reporting-any-error/td-p/686000<br />
* https://forums.xilinx.com/t5/Installation-and-Licensing/Vivado-on-Linux-synthesis-fails-with-no-error-message/td-p/732143<br />
<br />
====Environment Setup====<br />
The <code>uhd_image_builder.py</code> script will also set up the Xilinx Vivado environment by automatically running the <code>setupenv.sh</code> located in the <code>{USER_PREFIX}/src/uhd-fpga/usrp3/top/{device}</code> directory. The <code>setupenv.sh</code> script assumes that Xilinx Vivado is installed in the default location of <code>/opt/Xilinx/Vivado</code>. If the installation is in a different directory, then the <code>setupenv_base.sh</code> script will need to be modified. The script is located at: <code>{USER_PREFIX}/src/uhd-fpga/usrp3_rfnoc/tools/scripts/setupenv_base.sh</code>.<br />
<br />
<br />
==Reference Files==<br />
The following reference files are included within the gain_src.tar.gz archive linked below:<br />
<br />
* gain.xml <br />
* noc_block_gain.v <br />
* noc_block_gain_tb.sv <br />
* tutorial_gain.xml<br />
* rfnoc_gain.grc<br />
<br />
[[Media:gain src.tar.gz]]<br />
<br />
==Links and Additional Resources==<br />
===RFNoC additional resources===<br />
* [https://youtube.com/watch?v=j-EfyPVpaJ8 Video: RFNoC Getting Started Video Tutorial]<br />
* [https://kb.ettus.com/Mailing_Lists USRP Mailing List]<br />
* [https://kb.ettus.com/RFNoC RFNoC Software Resources Page]<br />
* [https://www.ettus.com/content/files/RFNoC_Wireless_at_VT_Intro.pdf RFNoC Introduction]<br />
* [https://www.ettus.com/content/files/RFNoC_Wireless_at_VT_FPGA.pdf RFNoC Deep Dive: FPGA]<br />
* [https://www.ettus.com/content/files/RFNoC_Wireless_at_VT_Host.pdf RFNoC Deep Dive: Host side]<br />
* [https://www.youtube.com/watch?v=8cPd3t88djE Video: RFNoC presented at Wireless @ Virginia Tech, 2015 ]<br />
** Explaining the slides of Intro, FPGA and Host presentations above (in that order).<br />
* [https://www.youtube.com/watch?v=51rpjJ2W0Qs Video: It's the RFNoC Life for Us by Martin Braun at GRCon16, 2016]<br />
<br />
===GNU Radio resources===<br />
* [http://gnuradio.org/redmine/projects/gnuradio/wiki/OutOfTreeModules GNU Radio OutOfTree Modules tutorial]<br />
* [http://gnuradio.org/redmine/projects/gnuradio/wiki/InstallingGRFromSource GNU Radio Installation]<br />
* [http://gnuradio.org/redmine/projects/gnuradio/wiki/Tutorials GNU Radio Tutorials]<br />
<br />
===UHD resources===<br />
* [http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com USRP Mailing List]<br />
* [https://kb.ettus.com/UHD UHD Software Resources Page]<br />
* [http://files.ettus.com/manual/md_usrp3_build_instructions.html USRP3 build instructions]<br />
* [http://files.ettus.com/manual/ UHD Manual]<br />
<br />
===Other resources===<br />
* [https://www.xilinx.com/support/documentation/ip_documentation/ug761_axi_reference_guide.pdf Xilinx - AXI reference guide]<br />
* [https://kb.ettus.com/Building_and_Installing_the_USRP_Open-Source_Toolchain_(UHD_and_GNU_Radio)_on_Linux UHD + GNU Radio Application Note (Linux)]<br />
* [http://gnuradio.org/redmine/projects/pybombs/wiki PyBOMBS]<br />
<br />
<br />
<br />
<br />
<br />
[[Category:Application Notes]]</div>JonathonPendlumhttps://kb.ettus.com/index.php?title=X300/X310&diff=5891X300/X3102023-10-27T21:01:14Z<p>JonathonPendlum: Fix missing link in FAQ for programming FPGA</p>
<hr />
<div>== Device Overview ==<br />
The Ettus Research USRP X310 is a high-performance, scalable software defined radio (SDR) platform for designing and deploying next generation wireless communications systems. The hardware architecture combines two extended-bandwidth daughterboard slots covering DC – 6 GHz with up to 160 MHz of baseband bandwidth, multiple high-speed interface options (PCIe, dual 10 GigE, dual 1 GigE), and a large user-programmable Kintex-7 FPGA in a convenient desktop or rack-mountable half-wide 1U form factor.<br />
<br />
== Key Features==<br />
===X300===<br />
{|<br />
|style="vertical-align:top"|<br />
* Xilinx Kintex-7 XC7K325T FPGA<br />
* 14 bit 200 MS/s ADC<br />
* 16 bit 800 MS/s DAC<br />
* Frequency range: DC - 6 GHz with suitable daughterboard<br />
* Up 160MHz bandwidth per channel<br />
* Two wide-bandwidth RF daughterboard slots<br />
* Optional GPSDO<br />
* Multiple high-speed interfaces (Dual 10G, PCIe Express, ExpressCard, Dual 1G)<br />
|[[File:Product x300.jpg|250px|center]] <br />
|}<br />
<br />
===X310===<br />
{|<br />
|style="vertical-align:top"|<br />
* Xilinx Kintex-7 XC7K410T FPGA<br />
* 14 bit 200 MS/s ADC<br />
* 16 bit 800 MS/s DAC<br />
* Frequency range: DC - 6 GHz with suitable daughterboard<br />
* Up 160MHz bandwidth per channel<br />
* Two wide-bandwidth RF daughterboard slots<br />
* Optional GPSDO<br />
* Multiple high-speed interfaces (Dual 10G, PCIe Express, ExpressCard, Dual 1G)<br />
|[[File:Product x310.jpg|250px|center]] <br />
|}<br />
<br />
==Compatible Daughterboards==<br />
* WBX-120 / WBX-40<br />
* SBX-120 / SBX-40<br />
* CBX-120 / CBX-40<br />
* UBX-160 / UBX-40<br />
* BasicTX / BasicRX<br />
* LFRX / LFTX<br />
* TwinRX<br />
* DBSRX2 (EOL)<br />
* RFX Series (EOL)<br />
* TVRX2 (EOL)<br />
<br />
==RF Specifications==<br />
===RF Performance Data (with SBX-120)===<br />
* SSB/LO Suppression -35/50 dBc<br />
* Phase Noise 3.5 GHz 1.0 deg RMS<br />
* Phase Noise 6 GHz 1.5 deg RMS<br />
* Power Output >10dBm<br />
* IIP3 (@ typ NF) 0dBm<br />
* Typical Noise Figure 8dB<br />
<br />
==Hardware Specifications==<br />
* Ettus Research recommends to always use the latest stable version of UHD<br />
<br />
===X300===<br />
* Current Hardware Revision: 8<br />
* Minimum version of UHD required: 3.9.0<br />
<br />
===X310===<br />
* Current Hardware Revision: 8<br />
* Minimum version of UHD required: 3.9.0<br />
<br />
===Clocking and Sampling Rates===<br />
There are two master clock rates (MCR) supported on the X300 and X310: 200.0 MHz and 184.32 MHz.<br />
<br />
The sampling rate must be an integer decimation rate of the MCR. Ideally, this decimation factor should be an even number. An odd decimation factor will result in additional unwanted attenuation (roll-off from the CIC filter in the DUC and DDC blocks in the FPGA). The valid decimation rates are between 1 and 1024.<br />
<br />
For the MCR of 200.0 MHz, the achievable sampling rates using an even decimation factor are 200.0, 100.0, 50.0, 33.33, 25.0, 20.0, 16.67, 14.286 Msps, ... 195.31 Ksps.<br />
<br />
For the MCR of 184.32 MHz, the achievable sampling rates using an even decimation factor are 184.32, 92.16, 46.08, 30.72, 23.04, 18.432, 15.36, 13.166 Msps, ... 180.0 Ksps.<br />
<br />
If the desired sampling rate is not directly supported by the hardware, then it will be necessary to re-sample in software. This can be done in C++ using libraries such as Liquid DSP [https://github.com/jgaeddert/liquid-dsp], or can be done in GNU Radio, in which there are three blocks that perform sampling rate conversion.<br />
<br />
==Physical Specifications==<br />
<br />
===Dimensions===<br />
27.7 x 21.8 x 3.9 cm<br />
<br />
===Weight===<br />
With 2x SBX-120: 1.7kg<br />
<br />
===Drawings===<br />
* [[Media:cu ettus-x3xx.pdf| Enclosure]]<br />
* [[Media:cu x3xx motherboard cca.pdf| Motherboard]]<br />
* [[Media:cu Rackmount Ettus-X3xx.pdf| Rackmount kit]]<br />
<br />
===CAD/STP Models===<br />
====X3xx====<br />
* [[Media:cu x3xx motherboard cca.stp.gz| Motherboard]]<br />
<br />
====X3xx Enclosure====<br />
* [[Media:cu ettus x3xx.stp.gz|Enclosure]]<br />
<br />
==Environmental Specifications==<br />
===Operating Temperature Range===<br />
* X300/X310: 25 °C<br />
<br />
===Operating Humidity Range===<br />
* 10% to 90% non-condensing<br />
<br />
==Schematics==<br />
===X300/X310===<br />
[http://files.ettus.com/schematics/x300/x3xx.pdf X300/X310 Schematics]<br />
<br />
==Key Component Datasheets==<br />
{| class="wikitable" style="width:80%"<br />
!Part Number<br />
!Description<br />
!Schematic ID (Page)<br />
|-<br />
<br />
|[http://www.xilinx.com/support/documentation/data_sheets/ds180_7Series_Overview.pdf XC7K325T] / [http://www.xilinx.com/support/documentation/data_sheets/ds180_7Series_Overview.pdf XC7K410T]<br />
|FPGA<br />
|U23 (3,5,8,9,10,18)<br />
|-<br />
<br />
|[http://www.analog.com/media/en/technical-documentation/data-sheets/AD9146.PDF AD9146]<br />
|Dual Channel, 16-Bit, 1230 MSPS DAC<br />
|U12, U36 (7)<br />
|-<br />
<br />
|[http://www.ti.com/lit/ds/slas635b/slas635b.pdf ADS62P48]<br />
|Dual Channel, 14-Bit 210 MSPS ADC<br />
|U11, U35 (6)<br />
|-<br />
<br />
|[https://www.fairchildsemi.com/datasheets/FI/FIN1002.pdf FIN1002]<br />
|High Speed Differential Receiver<br />
|U3, U5, U31, U32 (4)<br />
|-<br />
<br />
|[http://ww1.microchip.com/downloads/en/DeviceDoc/20001203U.pdf 24LC256T]<br />
|EEPROM<br />
|U530 (11)<br />
|-<br />
<br />
|[http://www.ti.com/lit/ds/symlink/lmk04816.pdf LMK04816BISQ/NOPB_1/3]<br />
|Jitter Cleaner With Dual Loop PLLs<br />
|U531 (11)<br />
|-<br />
<br />
|[http://www.micrel.com/_PDF/HBW/sy89547l.pdf SY89547LMGTR]<br />
|Multiplexer<br />
|U506 (12)<br />
|-<br />
<br />
|[http://www.ti.com/lit/ds/symlink/sn74aup1t17.pdf SN74AUP1T17]<br />
|Single Schmitt-Trigger Buffer Gate<br />
|U6, U519 (12)<br />
|-<br />
<br />
|[http://www.ti.com/lit/ds/symlink/tps54620.pdf TPS54620RGYT]<br />
|Synchronous Step Down SWIFT™ Converter<br />
|U515 (21); U516 (26)<br />
|-<br />
<br />
|[http://cds.linear.com/docs/en/datasheet/1764fb.pdf LT1764EQ-3.3]<br />
|Voltage Regulator<br />
|U27 (21); U516 (26)<br />
|-<br />
<br />
|[http://www.ti.com/lit/ds/symlink/tps7a47.pdf TPS7A47]<br />
|Voltage Regulator<br />
|U28, U532 (21)<br />
|-<br />
<br />
|[http://cds.linear.com/docs/en/datasheet/3603fc.pdf LTC3603EUF_TRPBF]<br />
|Monolithic Synchronous Step-Down Regulator<br />
|U517 (23); U500 (25); U514, U513 (27)<br />
|-<br />
<br />
|[http://www.ti.com/lit/ds/symlink/tps77625.pdf TPS77625_SM]<br />
|Low-Dropout Voltage Regulators<br />
|U30 (23)<br />
|-<br />
<br />
|[http://www.ti.com/lit/ds/symlink/tps79318-ep.pdf TPS79318_SM]<br />
|Low-Dropout Voltage Regulators<br />
|U510 (27)<br />
|-<br />
<br />
|[[Media:agile9598503.pdf|OSC-96MHZ-724821-01]]<br />
|Voltage Controlled Crystal Oscillator<br />
|U25 (11)<br />
|-<br />
<br />
|}<br />
<br />
==GPSDO==<br />
* Support GPSDO NMEA Strings<br />
* [http://www.jackson-labs.com/assets/uploads/main/LC_XO_specsheet.pdf JacksonLabs LC_XO]<br />
<br />
===Sensors===<br />
You can query the lock status with the <code>gps_locked</code> sensor, as well as obtain raw NMEA sentences using the <code>gps_gprmc</code>, and <code>gps_gpgga</code> sensors. Location information can be parsed out of the <code>gps_gpgga</code> sensor by using <code>gpsd</code> or another NMEA parser.<br />
<br />
==FPGA==<br />
* Utilization statistics are subject to change between UHD releases. This information is current as of UHD 3.9.4 and was taken directly from Xilinx Vivado 2014.4.<br />
<br />
===X300===<br />
<pre><br />
1. Slice Logic<br />
--------------<br />
<br />
+----------------------------+-------+-----------+-------+<br />
| Site Type | Used | Available | Util% |<br />
+----------------------------+-------+-----------+-------+<br />
| Slice LUTs | 61622 | 203800 | 30.23 |<br />
| LUT as Logic | 52887 | 203800 | 25.95 |<br />
| LUT as Memory | 8735 | 64000 | 13.64 |<br />
| LUT as Distributed RAM | 1878 | | |<br />
| LUT as Shift Register | 6857 | | |<br />
| Slice Registers | 62961 | 407600 | 15.44 |<br />
| Register as Flip Flop | 62961 | 407600 | 15.44 |<br />
| Register as Latch | 0 | 407600 | 0.00 |<br />
| F7 Muxes | 1209 | 101900 | 1.18 |<br />
| F8 Muxes | 150 | 50950 | 0.29 |<br />
+----------------------------+-------+-----------+-------+<br />
<br />
3. Memory<br />
---------<br />
<br />
+-------------------+------+-----------+-------+<br />
| Site Type | Used | Available | Util% |<br />
+-------------------+------+-----------+-------+<br />
| Block RAM Tile | 409 | 445 | 91.91 |<br />
| RAMB36/FIFO* | 398 | 445 | 89.43 |<br />
| RAMB36E1 only | 398 | | |<br />
| RAMB18 | 22 | 890 | 2.47 |<br />
| RAMB18E1 only | 22 | | |<br />
+-------------------+------+-----------+-------+<br />
* Note: Each Block RAM Tile only has one FIFO logic available and therefore can accommodate only one FIFO36E1 or one FIFO18E1. However, if a FIFO18E1 occupies a Block RAM Tile, that tile can still accommodate a RAMB18E1<br />
<br />
<br />
4. DSP<br />
------<br />
<br />
+----------------+------+-----------+-------+<br />
| Site Type | Used | Available | Util% |<br />
+----------------+------+-----------+-------+<br />
| DSPs | 123 | 840 | 14.64 |<br />
| DSP48E1 only | 123 | | |<br />
+----------------+------+-----------+-------+<br />
<br />
</pre><br />
<br />
===X310===<br />
<pre><br />
1. Slice Logic<br />
--------------<br />
<br />
+----------------------------+-------+-----------+-------+<br />
| Site Type | Used | Available | Util% |<br />
+----------------------------+-------+-----------+-------+<br />
| Slice LUTs | 61616 | 254200 | 24.23 |<br />
| LUT as Logic | 52885 | 254200 | 20.80 |<br />
| LUT as Memory | 8731 | 90600 | 9.63 |<br />
| LUT as Distributed RAM | 1878 | | |<br />
| LUT as Shift Register | 6853 | | |<br />
| Slice Registers | 62958 | 508400 | 12.38 |<br />
| Register as Flip Flop | 62958 | 508400 | 12.38 |<br />
| Register as Latch | 0 | 508400 | 0.00 |<br />
| F7 Muxes | 1209 | 127100 | 0.95 |<br />
| F8 Muxes | 150 | 63550 | 0.23 |<br />
+----------------------------+-------+-----------+-------+<br />
<br />
3. Memory<br />
---------<br />
<br />
+-------------------+------+-----------+-------+<br />
| Site Type | Used | Available | Util% |<br />
+-------------------+------+-----------+-------+<br />
| Block RAM Tile | 409 | 795 | 51.44 |<br />
| RAMB36/FIFO* | 398 | 795 | 50.06 |<br />
| RAMB36E1 only | 398 | | |<br />
| RAMB18 | 22 | 1590 | 1.38 |<br />
| RAMB18E1 only | 22 | | |<br />
+-------------------+------+-----------+-------+<br />
* Note: Each Block RAM Tile only has one FIFO logic available and therefore can accommodate only one FIFO36E1 or one FIFO18E1. However, if a FIFO18E1 occupies a Block RAM Tile, that tile can still accommodate a RAMB18E1<br />
<br />
<br />
4. DSP<br />
------<br />
<br />
+----------------+------+-----------+-------+<br />
| Site Type | Used | Available | Util% |<br />
+----------------+------+-----------+-------+<br />
| DSPs | 123 | 1540 | 7.98 |<br />
| DSP48E1 only | 123 | | |<br />
+----------------+------+-----------+-------+<br />
<br />
<br />
</pre><br />
<br />
<br />
===FPGA User Modifications===<br />
The Verilog code for the FPGA in the USRP X300 and USRP X310 is open-source, and users are free to modify and customize it for their needs. However, certain modifications may result in either bricking the device, or even in physical damage to the unit. Specifically, changing the I/O interface of the FPGA in any way (do not remove any of the I/O for the PCIe interface, such as <code>x300_pcie_int</code> and <code>LvFpga_Chinch_Interface</code>), or modifying the pin and timing constraint files, could result in physical damage to other components on the motherboard, external to the FPGA, and doing this will void the warranty. Also, even if the PCIe interface is not being used, you cannot remove or reassign these pins in the constraint file. The constraint files should not be modified. Please note that modifications to the FPGA are made at the risk of the user, and may not be covered by the warranty of the device.<br />
<br />
<br />
==Firmware==<br />
<br />
The USRP X300 series runs a small amount of software within the FPGA, within a ZPU soft processor. Its main responsibility is to provide access to some registers, handle the networking stacks, and monitor the USRP status.<br />
<br />
The source code for the ZPU is stored in <code>firmware/usrp3/</code> in the UHD repository. To modify the firmware, you need to download a recent ZPU compiler (e.g. from https://github.com/zylin/zpugcc/tree/master/releases/20150428). Unpack the tarball (e.g., into <code>/usr/local</code>) and make sure the <code>zpu-elf-gcc</code> binary is in your path. Then, execute the following steps:<br />
* Create and enter a build directory: <code>mkdir build && cd build</code><br />
* Run cmake: <code>cmake /path/to/firmware/usrp3/</code><br />
** If all is correctly configured, and the ZPU compiler can be found, this will pass without errors.<br />
* Build the firmware: <code>make</code><br />
** This should yield output similar to this:<br />
<br />
<pre><br />
Scanning dependencies of target x300<br />
[ 79%] Generating x300_main.map<br />
[ 83%] Generating x300_main.bin<br />
[ 87%] Generating x300_main.ihx<br />
[ 91%] Generating x300_main.dump<br />
[ 95%] Generating x300_main.rom<br />
[100%] Generating x300_main.coe<br />
[100%] Built target x300<br />
</pre><br />
<br />
* These files will be copied into the <code>build/x310</code> directory.<br />
* To non-persistently load the newly built firmware image into the running FPGA image, simply launch a UHD session with the <code>fw</code> parameter. The binary must be within UHD's image dir, e.g. by copying x300_main.bin to the default image directory (e.g., <code>/usr/local/share/uhd/images</code>) or by temporarily setting the <code>UHD_IMAGES_DIR</code> variable:<br />
<br />
UHD_IMAGES_DIR=/path/to/build/x300 uhd_usrp_probe --args type=x300,fw=x300_main.bin<br />
<br />
* To permanently bake the firmware image into the FPGA bitfile, copy the file <code>x300_main.coe</code> to <code>fpga/usrp3/top/x300/ip/bootram/bootram.coe</code> and rebuild the bitfile.<br />
<br />
==Interfaces and Connectivity==<br />
Follow the links below for additional information on configuring each interface for the USRP X300 or X310 SDRs.<br />
<br />
*[http://files.ettus.com/manual/page_usrp_x3x0.html#x3x0_hw_10gige Dual 10 Gigabit Ethernet] - 200 MS/s Full Duplex @ 16-bit<br />
*[http://files.ettus.com/manual/page_usrp_x3x0.html#x3x0_hw_pcie PCIe Express (Desktop)] - 200 MS/s Full Duplex @ 16-bit<br />
*[http://files.ettus.com/manual/page_usrp_x3x0.html#x3x0_hw_pcie_laptop ExpressCard (Laptop)] - 50 MS/s Full Duplex @ 16-bit<br />
*[http://files.ettus.com/manual/page_usrp_x3x0.html#x3x0_hw_1gige Dual 1 Gigabit Ethernet] - 25 MS/s Full Duplex @ 16-bit<br />
<br />
===Front Panel===<br />
{|<br />
| style="width:50%" |<br />
<br />
* '''JTAG''': USB connector for the on-board USB-JTAG programmer<br />
* '''RF A Group'''<br />
** '''TX/RX LED''': Indicates that data is streaming on the TX/RX channel on daughterboard A<br />
** '''RX2 LED''': Indicates that data is streaming on the RX2 channel on daughterboard A<br />
* '''REF''': Indicates that the external Reference Clock is locked<br />
* '''PPS''': Indicates a valid PPS signal by pulsing once per second<br />
* '''AUX I/O''': Front panel GPIO connector.<br />
* '''GPS''': Indicates that GPS reference is locked<br />
* '''LINK''': Indicates that the host computer is communicating with the device (Activity)<br />
* '''RF B Group'''<br />
** '''TX/RX LED''': Indicates that data is streaming on the TX/RX channel on daughterboard B<br />
** '''RX2 LED''': Indicates that data is streaming on the RX2 channel on daughterboard B<br />
* '''PWR''': Power switch<br />
<br />
| style="vertical-align:top" | [[File:x3x0 fp overlay.png]]<br />
|}<br />
<br />
<br />
<br />
===Rear Panel===<br />
{|<br />
| style="width:50%" |<br />
* '''PWR''': Connector for the USRP-X Series power supply<br />
* '''1G/10G ETH''': SFP+ ports for Ethernet interfaces<br />
* '''REF OUT''': Output port for the exported reference clock<br />
* '''REF IN''': Reference clock input<br />
* '''PCIe x4''': Connector for Cabled PCI Express link<br />
* '''PPS/TRIG OUT''': Output port for the PPS signal<br />
* '''PPS/TRIG IN''': Input port for the PPS signal<br />
* '''GPS''': Connection for the GPS antenna<br />
<br />
| style="vertical-align:top" | [[File:x3x0 rp overlay.png]]<br />
|}<br />
<br />
<br />
===Ref Clock - 10 MHz===<br />
Using an external 10 MHz reference clock, a square wave will offer the best phase noise performance, but a sinusoid is acceptable. The power level of the reference clock cannot exceed +15 dBm.<br />
<br />
===PPS - Pulse Per Second===<br />
Using a PPS signal for timestamp synchronization requires a square wave signal with the following a 5Vpp amplitude.<br />
<br />
To test the PPS input, you can use the following tool from the UHD examples:<br />
<br />
* <code><args></code> are device address arguments (optional if only one USRP device is on your machine)<br />
<br />
cd <install-path>/lib/uhd/examples ./test_pps_input –args=<args><br />
<br />
<br />
===Front Panel GPIO===<br />
{|<br />
| style="width:50%" |<br />
The GPIO port is not meant to drive big loads. You should not try to source more than 5mA per pin.<br />
<br />
The +3.3V is for ESD clamping purposes only and not designed to deliver high currents.<br />
<br />
The switching speed is below 10 MHz.<br />
<br />
| style="vertical-align:top" | [[File:x3x0 gpio conn.png]]<br />
|}<br />
<br />
<br />
====Power on state====<br />
The hardware power on state and UHD initial state for the front-panel GPIOs is high-Z. For the X3xx, there are no external pull-ups/pull-downs for the GPIO pins, but the FPGAs do have them and they are configured as follows: X3xx: pull-down.<br />
<br />
====Pin Mapping====<br />
* Pin 1: +3.3V<br />
* Pin 2: Data[0]<br />
* Pin 3: Data[1]<br />
* Pin 4: Data[2]<br />
* Pin 5: Data[3]<br />
* Pin 6: Data[4]<br />
* Pin 7: Data[5]<br />
* Pin 8: Data[6]<br />
* Pin 9: Data[7]<br />
* Pin 10: Data[8]<br />
* Pin 11: Data[9]<br />
* Pin 12: Data[10]<br />
* Pin 13: Data[11]<br />
* Pin 14: 0V<br />
* Pin 15: 0V<br />
<br />
'''Note''': Please see the [http://files.ettus.com/manual/page_gpio_api.html E3x0/X3x0 GPIO API] for information on configuring and using the GPIO bus.<br />
<br />
===On-Board LEDs===<br />
{| class="wikitable"<br />
<br />
!LED <br />
!Detail<br />
!Description<br />
|-<br />
<br />
| DS1 <br />
| 1.2V <br />
| Power <br />
|-<br />
<br />
| DS2 <br />
| TXRX1 <br />
| Red: TX, Green: RX <br />
|-<br />
<br />
| DS3 <br />
| RX1 <br />
| Green: RX <br />
|-<br />
<br />
| DS4 <br />
| REF <br />
| Reference Lock <br />
|-<br />
<br />
| DS5 <br />
| PPS <br />
| Flashes on Edge <br />
|-<br />
<br />
| DS6 <br />
| GPS <br />
| GPS Lock <br />
|-<br />
<br />
| DS7 <br />
| SFP0 <br />
| Link, Right, Green<br />
|-<br />
<br />
| DS8 <br />
| SFP0 <br />
| Link Activity, Left, Yellow<br />
|-<br />
<br />
| DS10 <br />
| TXRX2 <br />
| Red: TX Green: RX <br />
|-<br />
<br />
| DS11 <br />
| RX2 <br />
| Green: RX <br />
|-<br />
<br />
| DS12 <br />
| 6V <br />
| Daughterboard Power <br />
|-<br />
<br />
| DS13 <br />
| 3.8V <br />
| Power <br />
|-<br />
<br />
| DS14 <br />
| 3.3V <br />
| Management Power <br />
|-<br />
<br />
| DS15 <br />
| 3.3V <br />
| Auxiliary Management Power <br />
|-<br />
<br />
| DS16 <br />
| 3.3V <br />
| FPGA Power <br />
|-<br />
<br />
| DS19 <br />
| SFP1 <br />
| Link Active, Left, Yellow<br />
|-<br />
<br />
| DS20 <br />
| SFP1 <br />
| Link, Right, Green<br />
|-<br />
<br />
| DS21 <br />
| LINK <br />
| Link Activity <br />
|-<br />
<br />
|}<br />
<br />
===Power Connector===<br />
Model: PDP-40 by CUI Inc.<br />
<br />
Power plug connectors for custom power harnesses can be purchased here: https://www.digikey.com/products/en?KeyWords=CP-7340-ND&WT.z_cid=sp_102_buynow<br />
<br />
Assembly instructions: [[Media:pdp-40.pdf]]<br />
<br />
====Pin Detail====<br />
* Pins #1 / #2: 12v<br />
* Pins #3 / #4: Ground<br />
<br />
[[File:pdp 40 power detail.png]]<br />
<br />
==Certifications==<br />
===RoHS===<br />
As of December 1st, 2010 all Ettus Research products are RoHS compliant unless otherwise noted. More information can be found at [http://ettus.com/legal/rohs-information http://ettus.com/legal/rohs-information]<br />
<br />
===China RoHS=== <br />
'''Management Methods for Controlling Pollution Caused by Electronic Information Products Regulation'''<br />
<br />
'''Chinese Customers''' <br />
<br />
National Instruments is in compliance with the Chinese policy on the Restriction of Hazardous Substances (RoHS) used in Electronic Information Products. For more information about the National Instruments China RoHS compliance, visit [http://www.ni.com/environment/rohs_china ni.com/environment/rohs_china].<br />
<br />
==Certificate of Volatility==<br />
<br />
Found on the [https://www.ni.com/en/support/documentation/product-certifications.html NI Product Certifications lookup tool] [https://www.ni.com/pdf/manuals/377356a.pdf here].<br />
<br />
==Downloads==<br />
[http://files.ettus.com/manual/md_fpga.html FPGA Resources]<br />
<br />
[http://files.ettus.com/binaries/uhd_stable/ UHD Stable Binaries]<br />
<br />
[https://github.com/EttusResearch/uhd UHD Source Code on Github]<br />
<br />
==Choosing USRP X310 vs USRP X300==<br />
In terms of host bandwidth, interface options, and all other hardware features the USRP X300 and USRP 310 are identical. However, the USRP X310 provides a larger FPGA, a Xilinx XC7K410T, as opposed to XC7K325T. While both options provide a significant amount of free resources for custom FPGA development, the XC7K410T provides additional design margin, which translates to ease of development and future expandability. Most users choose the USRP X310 for their development.<br />
<br />
{| class="wikitable" style="margin: auto;"<br />
!colspan="3"|USRP X300 and X310 FPGA Resource Summary<br />
|-<br />
|rowspan="2"|Resource Type<br />
|USRP X300 (XC7K325T)<br />
|USRP X310 (XC7K410T)<br />
|-<br />
|Count<br />
|Count<br />
|-<br />
|DSP48 Blocks<br />
|840<br />
|1540<br />
|-<br />
|Block Rams (18kB)<br />
|890<br />
|1590<br />
|-<br />
|Logic Cells<br />
|326,080<br />
|406,720<br />
|-<br />
|Slices (logic)<br />
|50,950<br />
|63,550<br />
|-<br />
|}<br />
<br />
For up-to-date information on FPGA resource utilization in the stock FPGA design, please see "USRP 300/X310 FPGA Resources" in the Ettus Research knowledge base (https://kb.ettus.com).<br />
<br />
==Choosing an RF Daughterboard==<br />
With the increased sample rates used by the USRP X300 and USRP X310, these new device can support extended-bandwidth daughterboards. The WBX-120, SBX-120, and CBX-120 are recommended to take advantage of the full bandwidth capability of the USRP X300 and X310. The WBX-120, SBX-120, and CBX-120 have been upgraded from their predecessors (40 MHz) to use 120 MHz baseband filters. You can select your daughterboard based on the center frequency of your primary application.<br />
<br />
{| class="wikitable" style="margin: auto;"<br />
!Daughterboard<br />
!Frequency Range<br />
!Bandwidth<br />
|-<br />
<br />
|WBX-120<br />
|50 MHz - 2200 MHz<br />
|120 MHz<br />
|-<br />
<br />
|SBX-120<br />
|400 MHz - 4400 MHz<br />
|120 MHz<br />
|-<br />
<br />
|CBX-120<br />
|1200 MHz - 6000 MHz<br />
|120 MHz<br />
|-<br />
<br />
|UBX-160<br />
|10 MHz - 6000 MHz<br />
|160 MHz<br />
|-<br />
<br />
|TwinRX<br />
|10 MHz - 6000 MHz<br />
|80 MHz per channel, 160 MHz total<br />
|-<br />
<br />
|}<br />
<br />
If your application is in the HF frequency range, the LFRX and LFTX are recommended for up to 30 MHz of bandwidth per channel. The BasicRX and BasicTX are ideal for configurations that use an external frontend for tuning and filtering with either an IF or baseband interface.<br />
<br />
The USRP X300 and X310 are backward compatible with legacy daughterboards except for the RFX Series and XCVR2450. Please note, while there are two daughterboard slots, the USRP X300/X310 can only support a single TVRX2.<br />
<br />
<br />
If you plan to transmit or receive over the air, you should also purchase an antenna.<br />
<br />
==Choosing a Host Interface==<br />
<br />
The USRP X300/X310 provide three interface options – 1 Gigabit Ethernet (1 GigE), 10 Gigabit Ethernet (10 GigE), and PCI-Express (PCIe). The PCIe interface is always available regardless of what FPGA image is loaded. Ettus ships two FPGA image variants, the HG or HGS image which has one 1 GigE interfaces and one 10 GigE interfaces, and the XG image which has two 10 GigE interfaces. Generally, Ettus Research recommends using 10 GigE to achieve the maximum throughput available from the USRP X300/X310. PCIe is recommended for applications that require the lowest possible latency, which is a desirable characteristic for PHY/MAC research. If your application does not require the full bandwidth of the USRP ™ X300 and X310, the 1 GigE interface serves as a cost-effective fall-back option. Ettus Research provides a complete interface kit for each of these options, which is also shown in Table 3.<br />
<br />
{| class="wikitable" style="margin: auto;"<br />
!colspan="4"|Table 3 - Interface Performance Summary<br />
|-<br />
!Interface<br />
!Throughput (MS/s @ 16-bit)<br />
!Target<br />
!Recommended Kit<br />
|-<br />
|1 Gigabit<br />
|25 MS/s<br />
|Desktop/Laptop<br />
|Components provided with USRP X300/X310 kit.<br />
For additional connections, purchase the following:<br />
[https://www.ettus.com/product/details/1GIGE-KIT SFP Adapter + GigE Cable]<br />
|-<br />
|10 Gigabit<br />
|200 MS/s<br />
|Desktop<br />
|[https://www.ettus.com/product/details/10GIGE-KIT 10 GigE Interface Kit]<br />
|-<br />
|PCI-Express <br />
(PCIe, 4 lane)<br />
|200 MS/S<br />
|Desktop<br />
|[https://www.ettus.com/product/details/PCIE-KIT PCI-Express Desktop Kit]<br />
|-<br />
|Express Card<br />
(PCIe, 1 lane)<br />
|50 MS/s<br />
|Laptop<br />
|[https://www.ettus.com/product/details/ECARD-KIT ExpressCard Kit]<br />
|-<br />
|}<br />
<br />
<br />
[[File:Connectivity 2.png|700px|center]]<br />
<br />
<center>Figure 2 - Host Interface Options</center><br />
<br />
<br />
===10 Gigabit Ethernet===<br />
See [https://kb.ettus.com/Using_Dual_10_Gigabit_Ethernet_on_the_USRP_X300/X310 this app note] for how to use the X3x0 with dual 10 GbE links.<br />
<br />
'''Recommended 10 Gigabit Ethernet Cards'''<br />
* Intel X520-DA2<br />
** [http://ark.intel.com/products/39776/Intel-Ethernet-Converged-Network-Adapter-X520-DA2 Intel® Ethernet Converged Network Adapter X520-DA2]<br />
* Intel X520-DA1<br />
** [http://ark.intel.com/products/68669/Intel-Ethernet-Converged-Network-Adapter-X520-DA1 Intel® Ethernet Converged Network Adapter X520-DA1 ]<br />
* Intel X710-DA2<br />
** [http://ark.intel.com/products/83964/Intel-Ethernet-Converged-Network-Adapter-X710-DA2 Intel® Ethernet Converged Network Adapter X710-DA2 ]<br />
* Intel X710-DA4<br />
** [http://ark.intel.com/products/83965/Intel-Ethernet-Converged-Network-Adapter-X710-DA4 Intel® Ethernet Converged Network Adapter X710-DA4 ]<br />
* Mellanox MCX4121A-ACAT<br />
** [https://store.mellanox.com/products/mellanox-mcx4121a-acat-connectx-4-lx-en-network-interface-card-25gbe-dual-port-sfp28-pcie3-0-x8-rohs-r6.html Mellanox MCX4121A-ACAT ]<br />
<br />
==International Power Supply Options==<br />
The power supply provided with the USRP X300/X310 kit is packaged with a power cord that is compatible with power outlets in the US/Japan. If you are not using the USRP X300/X310 in the US/Japan, we recommend purchasing the International USRP X300/X310 Power Cord set. <br />
<br />
==Option: GPS Disciplined, Oven-Controlled Oscillator (GPSDO)==<br />
The USRP X300 and USRP X310 provide the option to integrate a high-accuracy GPS-disciplined oscillator (GPSDO). The GPSDO improves the accuracy of the internal frequency reference to 20 ppb, or 0.1 ppb if the GPS is synchronized to the GPS constellation. When synchronized to the GPS constellation, all USRP ™ devices will also be synchronized in time within 50 ns.<br />
<br />
{| class="wikitable" style="margin: auto;"<br />
|<br />
!Internal TCXO<br />
!GPS-Disciplined Clock<br />
|-<br />
|Frequency Reference<br />
|TCXO<br />
|OCXO<br />
|-<br />
|Frequency Accuracy (unlocked)<br />
|± 2.5ppm<br />
± 2,500 Hz @ 1 GHz<br />
|± 25 ppb<br />
± 25 Hz @ 1 GHz<br />
|-<br />
|Frequency Accuracy<br />
|<br />
|± 0.01ppb<br />
|-<br />
|(GPS-Disciplined)<br />
|<br />
|~ ± 0.01 Hz @ 1 GHz<br />
|-<br />
|GPS Time Sync Accuracy<br />
|<br />
|±50ns to UTC Time**<br />
|-<br />
|10 MHz Reference Phase Drift with GPS Sync<br />
|<br />
|<±20ns After 1 Hour**<br />
|-<br />
|}<br />
<br />
==Option: Antenna Kit for GPSDO==<br />
The GPSDO Mini Kit will improve the accuracy of the USRP reference clock, even if it does not receive signals from the GPS Constellation. However, to achieve the best accuracy possible, and to achieve global timing alignment across multiple USRPs, Ettus Research recommends the GPSDO Mini Antenna Kit.<br />
<br />
==Option: General Purpose Input/Output (GPIO) Kit==<br />
The USRP X300 and X310 include a DB15 connector on the front panel that provides convenient access to GPIO signals. Each pin can be configured as an input or output, uses 3.3V-level logic, and is protected with basic anti-static circuitry. These pins can be used to control external devices like RF switches and amplifiers, trigger software events on the host, or even provide basic debugging functionality. The USRP GPIO Kit is an affordable option that provides access to these signals with a DB15 cable and a breakout board. The breakout board allows the user to connect external devices through a terminal block. The user can also solder wires and components into the dedicated prototyping area.<br />
<br />
==Option: Cables for MIMO Expansion==<br />
Multiple USRP X300/X310s can be synchronized for coherent operation by sharing a common 10 MHz and 1 PPS signal. We recommend using a star-distribution topology with an OctoClock or OctoClock-G, as seen in Figure 4. This requires matched length cables to be used for both 10 MHz and 1 PPS.<br />
<br />
For more information about MIMO operation, please see the MIMO and Synchronization Application Note.<br />
[[File:8mimo.png|700px|center]]<br />
<center>Figure 4 - Star-Distribution of 10 MHz/PPS Signals with OctoClock</center><br />
<br />
==Option: USRP X300/X310 Rackmount==<br />
<br />
The USRP X300 and X310 were designed to be used with a [https://www.ettus.com/all-products/rackmount-1u/ 1U Rackmount Assembly] for building high-density MIMO systems in a compact and well-organized setup. This mount supports one or two compatible USRPs, and if two are mounted then there are rubber standoffs between the USRPs to avoid both direct contact and surface scratching. If the user will be developing in a laboratory environment or building a high-channel count USRP system, then a 1U Rackmount Assembly is highly recommended. This specific mount is compatible with only the USRP X300 and X310, and allows the integration of up to four bidirectional -- or eight receive-only -- RF channels per 1U.<br />
<br />
==Guidance on SFP+ Adapters for Fiber Connectivity on USRP X300/X310==<br />
<br />
Ettus Research currently offers direct-connect, copper cabling accessories for the USRP X300 and USRP X310. However, it is also possible to use multi-mode fiber instead of copper connections for these devices. <br />
<br />
The USRP X Series is compatible with most brands of SFP+ fiber adapters. In some cases, other equipment in the systems such as 1/10 Gigabith Ethernet switches are only compatible with specific brands of SFP+ adapters and cables. As a general rule, we recommend checking compatibility with the switches and network cards in your system before purchasing an adapter.<br />
<br />
Ettus Research does test the USRP X Series devices with our [https://www.ettus.com/product/details/10GIGE-KIT 10 Gigabit Ethernet Connectivity Kit] and a Blade Networks G8124 1/10 GigE switch. Here are is a list of known-good cables and adapters.<br />
<br />
Ettus Research has only tested multi-mode fiber accessories.<br />
<br />
===Known-Good Adapters===<br />
* [https://approvedoptics.com/blade-networks-bn-ckm-sp-sr/ Approved Optics Blade Networks BN-CKM-SP-SR-A]<br />
<br />
===Known-Good Cables===<br />
* [https://www.colfaxdirect.com/store/pc/viewPrd.asp?idproduct=995&idcategory=2 Myricom Fiber Cables for 10GBase-SR, 3 Meters 10G-SR-3M]<br />
<br />
==Guidance on 10Gb SFP+ to RJ45 Adapters==<br />
<br />
Many new motherboards come equipped with an onboard 10Gb RJ45 NIC. It is possible to use a SFP+ to RJ45 adapter and operate at 10Gb speeds using a Cat6/7 Ethernet cables.<br />
<br />
Ettus Research has tested the adapters linked below.<br />
<br />
===Known-Good Adapters===<br />
* [https://www.amazon.com/10Gtek-SFP-10G-T-S-Compatible-10GBase-T-Transceiver/dp/B01KFBFL16/ 10Gtek SFP+ to RJ45 Copper Module]<br />
* [https://www.prolabs.com/products/transceivers/brocade/sfpplus/100-1000-10000base/10g-sfpp-t-c ProLabs 10G-SFPP-T-C]<br />
<br />
==FAQ==<br />
USRP™ X300 and USRP™ X310 SDRs Frequently Asked Questions<br />
<br />
* '''What is the bandwidth of the USRP X300/X310'''<br />
<br />
The ADC rate on each analog RX channel is 200 MS/s quadrature, which provides a theoretical analog bandwidth of approximately 80% of the Nyquist bandwidth of +/- 100 MHz (+/- 80 MHz around the center frequency). The resulting maximum theoretical analog bandwidth is 160 MHz. The actual analog bandwidth may be reduced due the RF daughterboard selected.<br />
<br />
RF Daughterboard Bandwidths: See the daughterboard specifications [link]<br />
<br />
FPGA Processing Bandwidth: Up to 200 MS/s quadrature.<br />
<br />
Host Bandwidth: Up to 200 MS/s quadrature, dependent on selected interface<br />
<br />
For more information about achieving the maximum bandwidth with a USRP X300/X310, please see the "USRP X300/X310 Configuration Guide" or the "USRP System Bandwidth" application note.<br />
<br />
* '''How can I program the USRP X300/X310'''<br />
<br />
Like all other USRP models, the USRP X300 and X310 are compatible with the USRP Hardware Driver™ (UHD) architecture. The UHD architecture is a common driver that allows users to develop and execute applications on a host-PC. UHD provides a direct C++ API to control and stream to/from the USRP X300/X310. It also provides compatibility with a variety of third-party software frameworks including GNU Radio, LabVIEW, and Matlab. You may also customize the FPGA image provided with UHD to integrate your own signal processing. For more information about UHD, and supported software frameworks, please see:<br />
<br />
http://files.ettus.com/manual/<br />
<br />
* '''How do I update the FPGA images and firmware with the latest from UHD'''<br />
<br />
You can find more information about updating the FPGA image in the UHD manual: https://files.ettus.com/manual/page_usrp_x3x0.html#x3x0_getting_started_fpga_update<br />
<br />
* '''How can I modify the FPGA of the USRP X300/X310'''<br />
<br />
The source code (Verilog) for the USRP X300/X310 is available in the UHD repository. The build process leverages the existing CMAKE build system used to compile the host-side driver. A Linux-based setup will provide the best results.<br />
<br />
Which FPGA toolchain required to build the FPGA images will depend upon your version of UHD. For more details please see the [[UHD]] Software Resource page.<br />
<br />
* '''How much free space is available in the USRP X300/X310 FPGA'''<br />
<br />
Please see the USRP X300/X310 FPGA resources page for more information.<br />
<br />
* '''What type of PC setup is recommended for use with the USRP X300/X310'''<br />
<br />
The type of PC required depends heavily on the complexity and bandwidth of the application. To demonstrate the USRP X300/X310, we typically use a desktop computer with a quadcore i7, 8+ GB of DDR3, and install the PCIe interface card that is also provide with the 10 GigE, PCIe, and ExpressCard interface kits.<br />
<br />
* '''What frequency range does the USRP X300/X310 cover'''<br />
<br />
The frequency range depends on the daughterboard select by the users. For more information, please see the USRP X300/X310 Configuration Guide.<br />
<br />
* '''What components do I need to purchase for a complete USRP X300/X310 system'''<br />
<br />
For a more comprehensive guide, please see the USRP X300/X310 Configuration Guide.<br />
<br />
* '''What is the difference between the USRP X300/X310'''<br />
<br />
The USRP X310 includes a larger Kintex-7 series FPGA (XC7K410T) with additional development resources for more complex designs. The USRP X300 includes the smaller XC7K325T FPGA.<br />
<br />
* '''What is the part number of the X300/X310 power connector'''<br />
Model: PDP-40 by CUI Inc.<br />
Power plug connectors for custom power harnesses can be purchased here: https://www.digikey.com/products/en?KeyWords=CP-7340-ND&WT.z_cid=sp_102_buynow<br />
<br />
[[Category:Hardware Resources]]</div>JonathonPendlumhttps://kb.ettus.com/index.php?title=Writing_the_USRP_File_System_Disk_Image_to_a_SD_Card&diff=5886Writing the USRP File System Disk Image to a SD Card2023-09-25T21:28:12Z<p>JonathonPendlum: Removed reference to bmaptool as it is not recommended for UHD 4.x images</p>
<hr />
<div>==Application Note Number==<br />
'''AN-630'''<br />
<!-- Internal use only: please do keep this updated!<br />
==Revision History==<br />
{| class="wikitable"<br />
!Date<br />
!Author<br />
!Details<br />
|-<br />
|style="text-align:center;"| 2018-12-12<br />
|style="text-align:center;"| Nate Temple<br />
|style="text-align:center;"| Initial creation<br />
|}<br />
--><br />
<br />
==Abstract==<br />
This application note will provide step-by-step instructions on writing a file system disk image to a SD card using Linux.<br />
<br />
==Required Tools==<br />
* Computer with USB2/3 Interface <br />
* UHD Installation<br />
* microSD card to USB Adapter<br />
<br />
==Downloading the File System Image==<br />
To obtain the file system SD card image for your USRP device, run the command in the next step on the host computer with UHD installed and Internet access. <br />
<br />
===N3xx===<br />
<br />
$ sudo uhd_images_downloader -t sdimg -t n3xx<br />
<br />
Example Output for UHD 3.15.0.0:<br />
<br />
$ sudo uhd_images_downloader -t sdimg -t n3xx<br />
[INFO] Images destination: /usr/local/share/uhd/images<br />
[INFO] No inventory file found at /usr/local/share/uhd/images/inventory.json. Creating an empty one.<br />
845962 kB / 845962 kB (100%) n3xx_common_sdimg_default-v3.15.0.0.zip<br />
[INFO] Images download complete.<br />
<br />
===E31x===<br />
<br />
The Release 4 image comes in two varieties: SG1 and SG3. The variety that you will need depends on the product number of your E310. To see which version you need look over at [https://kb.ettus.com/E310/E312#SD_Card_Images E310/E312 - Ettus Knowledge Base]<br />
<br />
$ sudo uhd_images_downloader -t sdimg -t e310 -t sg1<br />
<br />
or<br />
$ sudo uhd_images_downloader -t sdimg -t e310 -t sg3<br />
<br />
Example Output for UHD 3.15.0.0 for E310 SG3:<br />
<br />
$ sudo uhd_images_downloader -t sdimg -t e310 -t sg3<br />
[INFO] Images destination: /usr/local/share/uhd/images<br />
[INFO] No inventory file found at /usr/local/share/uhd/images/inventory.json. Creating an empty one.<br />
561236 kB / 561236 kB (100%) e3xx_e310_sg3_sdimg_default-v3.15.0.0.zip<br />
[INFO] Images download complete.<br />
<br />
===E320===<br />
<br />
$ sudo uhd_images_downloader -t sdimg -t e320<br />
<br />
Example Output for UHD 3.15.0.0:<br />
<br />
$ sudo uhd_images_downloader -t sdimg -t e320<br />
[INFO] Images destination: /usr/local/share/uhd/images<br />
[INFO] No inventory file found at /usr/local/share/uhd/images/inventory.json. Creating an empty one.<br />
795674 kB / 795674 kB (100%) e3xx_e320_sdimg_default-v3.15.0.0.zip<br />
[INFO] Images download complete.<br />
<br />
==Identifying UHD Installation Prefix==<br />
<br />
In the output of the <code>uhd_images_downloader</code> command above, the folder destination where the images are saved is printed out.<br />
<br />
An alternative method to identify your installation prefix is to run the command:<br />
<br />
$ uhd_config_info --install-prefix<br />
<br />
Example Output:<br />
<br />
Install prefix: /usr/local<br />
<br />
The default folder location for FPGA and SD card images is:<br />
<br />
<UHD_INSTALL_PREFIX>/share/uhd/images/<br />
<br />
<br />
==Writing the File System Image with Linux==<br />
<br />
===Identifying SD Card Mount Location===<br />
<br />
Insert the microSD card into the host computer.<br />
<br />
To identify the device where the microSD card is, run the command:<br />
<br />
dmesg | tail<br />
<br />
Example Output (partially truncated for readability):<br />
<br />
[21265.575488] usb-storage 1-2:1.0: USB Mass Storage device detected<br />
[21266.586983] scsi 0:0:0:0: Direct-Access Generic Mass-Storage 1.11 PQ: 0 ANSI: 2<br />
[21266.588024] sd 0:0:0:0: Attached scsi generic sg0 type 0<br />
[21267.299812] sd 0:0:0:0: [sdb] 31116288 512-byte logical blocks: (15.9 Gb/14.8 GiB)<br />
[21267.302687] sdb: sdb1 sdb2 sdb3 sdb4<br />
<br />
NOTE: In this specific example configuration, the SD card has been attached to <code>sdb</code>.<br />
<br />
Another method to finding the device node the disk is attached at is to use the Linux utility <code>lsblk</code>:<br />
<br />
Example Output:<br />
<br />
$ lsblk<br />
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT<br />
sdb 8:16 1 14.9G 0 disk<br />
├─sdb1 8:17 1 16M 0 part /media/user/boot<br />
├─sdb2 8:18 1 1.9G 0 part /media/user/primary<br />
├─sdb3 8:19 1 1.9G 0 part /media/user/secondary<br />
└─sdb4 8:20 1 11G 0 part /media/user/data<br />
<br />
===Unmount Auto-mounted Partitions===<br />
<br />
Some operating systems by default will auto-mount the partitions on a block device when it is attached. Before writing a new disk image to the SD card, you should first unmount any mounted partitions. This can be done with the Linux utility <code>umount</code> as shown below:<br />
<br />
$ sudo umount /media/user/data<br />
$ sudo umount /media/user/primary<br />
$ sudo umount /media/user/secondary<br />
$ sudo umount /media/user/boot<br />
<br />
Running the command <code>lsblk</code> again will show these partitions have been unmounted:<br />
<br />
Example Output:<br />
<br />
$ lsblk<br />
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT<br />
sdb 8:16 1 14.9G 0 disk<br />
├─sdb1 8:17 1 16M 0 part<br />
├─sdb2 8:18 1 1.9G 0 part<br />
├─sdb3 8:19 1 1.9G 0 part<br />
└─sdb4 8:20 1 11G 0 part<br />
<br />
===Writing the SD Card Image===<br />
<br />
====Using dd to write the disk image====<br />
<br />
'''WARNING:''' The Linux utility <code>dd</code> can cause unrecoverable data loss if the incorrect disk is selected, or if the parameters are input incorrectly. Ensure you have selected the correct input and output parameters for your system configuration.<br />
<br />
NOTE: You must use a 16 Gb or larger SD card for the N3xx and E320 file system images.<br />
<br />
The <code><SD_CARD_DEV_NAME></code> device node depends on your operating system and which other devices are plugged in. Typical values are <code>sdb</code> or <code>mmcblk0</code>.<br />
<br />
The <code><IMAGE></code> value will depend upon which file system image you're writing. Examples for the N300/N310 and E320 are listed below:<br />
<br />
'''N3xx'''<br />
<IMAGE>=/usr/local/share/uhd/images/usrp_n3xx_fs.sdimg<br />
<br />
'''E320'''<br />
<IMAGE>=/usr/local/share/uhd/images/usrp_e320_fs.sdimg<br />
<br />
Write the disk image with the command:<br />
<br />
$ sudo dd if=<IMAGE> of=<SD_CARD_DEV_NAME> bs=1M<br />
<br />
This step of writing the disk image to the SD card can take several minutes to complete.<br />
<br />
Example Output:<br />
<br />
$ sudo dd if=/usr/local/share/uhd/images/usrp_<deivce>_fs.sdimg of=/dev/sdb bs=1M<br />
15160+0 records in<br />
15160+0 records out<br />
15896412160 bytes (16 Gb, 15 GiB) copied, 1160.93 s, 13.7 MB/s<br />
<br />
To ensure the disk is synchronized, run the <code>sync</code> command:<br />
<br />
$ sync<br />
<br />
You can now remove the microSD card from your host computer and insert it into the USRP.<br />
<br />
[[Category:Application Notes]]</div>JonathonPendlumhttps://kb.ettus.com/index.php?title=Ettus_USRP_E300_Embedded_Family_Getting_Started_Guides&diff=5885Ettus USRP E300 Embedded Family Getting Started Guides2023-09-25T20:38:31Z<p>JonathonPendlum: Fix mendor update commands</p>
<hr />
<div>==Kit Contents==<br />
<br />
===E310===<br />
<br />
{|<br />
|style="vertical-align:top"|<br />
* E310 USRP<br />
* Power supply<br />
* 2x SMB-to-SMA adapter<br />
* 1 Gigabit Ethernet cable<br />
* USB2-to-microUSB cable<br />
* Imaged microSD card<br />
* Getting started guide<br />
|[[File:Product e310.png|250px|center]] <br />
|}<br />
<br />
===E312===<br />
<br />
{|<br />
|style="vertical-align:top"|<br />
* E312 USRP<br />
* Power supply<br />
* 2x SMB-to-SMA adapter<br />
* 1 Gigabit Ethernet cable<br />
* USB2-to-microUSB cable<br />
* Imaged microSD card<br />
* Getting started guide<br />
|[[File:Product e312.png|250px|center]] <br />
|}<br />
<br />
===E313===<br />
<br />
{|<br />
|style="vertical-align:top"|<br />
* Protective caps for input ports<br />
* Surface mounting accessory<br />
* Pole mounting accessory<br />
* End conduit interface for USB devices <br />
* Waterproof sleeve for DC power connector<br />
* Waterproof sleeve for PoE (RJ45) connector<br />
* Torx T-20 key<br />
* Mounting accessory assembly guide<br />
* Imaged microSD card<br />
|[[File:E313.png|250px|center]] <br />
''The USRP E313 is a fully assembled device that includes an USRP E310.''<br />
|}<br />
<br />
==Verify the Contents of Your Kit==<br />
<br />
Make sure that your kit contains all the items listed above. If any items are missing, please contact your sales agent or Ettus Research Technical support immediately.<br />
<br />
==You Will Need==<br />
<br />
* A host computer with an available USB 2.0 or 3.0 port<br />
<br />
==Proper Care and Handling==<br />
<br />
All Ettus Research products are individually tested before shipment. The USRP™ is guaranteed to be functional at the time it is received by the customer. Improper use or handling of the USRP™ can easily cause the device to become non-functional. Listed below are some examples of actions which can prevent damage to the unit:<br />
<br />
*Never allow metal objects to touch the circuit board while powered.<br />
*Always properly terminate the transmit port with an antenna or 50Ω load.<br />
*Always handle the board with proper anti-static methods.<br />
*Never allow the board to directly or indirectly come into contact with any voltage spikes.<br />
*Never allow any water, or condensing moisture, to come into contact with the boards.<br />
*Always use caution with FPGA, firmware, or software modifications.<br />
{|<br />
|style="padding-left:10px; padding-right:10px; padding-bottom:10px;" |[[File:Caution.png|24px|center]]<br />
|style="padding-left:10px; padding-right:10px; padding-bottom:10px;" |Never apply more than 0 dBm of power into any RF input.<br />
|-<br />
|style="padding-left:10px; padding-right:10px; padding-bottom:10px;" |[[File:Caution.png|24px|center]]<br />
|style="padding-left:10px; padding-right:10px; padding-bottom:10px;" |Always use at least 30dB attenuation if operating in loopback configuration<br />
|-<br />
|}<br />
<br />
==Install and Setup the Software Tools on Your Host Computer==<br />
<br />
In order to use your Universal Software Radio Peripheral (USRP™), you must have the software tools correctly installed and configured on your host computer. A step-by-step guide for doing this is available at the Building and Installing the USRP Open-Source Toolchain (UHD and GNU Radio) on [[Building and Installing the USRP Open-Source Toolchain (UHD and GNU Radio) on Linux|Linux]], [[Building and Installing the USRP Open-Source Toolchain (UHD and GNU Radio) on OS X|OS X]] and [[Building and Installing the USRP Open Source Toolchain (UHD and GNU Radio) on Windows|Windows]] Application Notes. See the [[Ettus_USRP_E300_Embedded_Family_Hardware_Resources#Hardware_Specifications|Hardware Specifications]] section of the USRP Embedded Series Hardware Resources for additional details on which version of the USRP Hardware Driver, UHD, is required. It is recommended to use the latest stable version of UHD that is available. <br />
<br />
If you have a USB stick with the [[Live SDR Environment]] installed on it, then you may boot your host computer from that. The LiveUSB SDR Environment does not require anything to be installed on your host computer, and contains a Linux-based environment with the UHD software and the GNU Radio framework already installed. More information about the [[Live SDR Environment]] is available at the [[Live SDR Environment Getting Started Guides]] page.<br />
<br />
== USRP E31x Device Specific Operations ==<br />
<br />
=== Powering On the Hardware ===<br />
<br />
With older USRP E31x devices running Firmware version 1, connecting the AC power supply to the device will cause the unit to turn on and boot. By default with Firmware 2.0 and newer the device no longer turns on when AC power is plugged in. To determine the firmware version, once the device is fully booted, login to it and execute<br />
<br />
$ dmesg | grep -i "firmware version"<br />
<br />
If this is the first time powering on a USRP E312 (with battery), allow the battery to fully charge before disconnecting the AC power source.<br />
<br />
Once the device has completed the boot process, you are ready to start using the device over your preferred method of connectivity (Serial Console, Network, or USB peripherals)!<br />
<br />
=== Turning the Device Off/On ===<br />
<br />
You can power the device on and off by pressing the power button. To power the device off, hold the power button down until the button’s LED turns off -- this will take a couple of seconds, and then another 15 seconds for the device to fully shut down. To turn the device on, hold down the power button until the LED turns on.<br />
<br />
To avoid damaging the file system and causing any corruption, do not turn the device off with the power button without first shutting down the system. Use this command to cleanly and properly shut the system down:<br />
<br />
$ shutdown -h now<br />
<br />
=== Autoboot ===<br />
<br />
The USRP E31x can be configured to power on and boot automatically when power is applied. If the firmware is older than 2.0 then it will ''probably'' need to be updated for autoboot to work reliably; email [mailto:support@ettus.com support@ettus.com] for more information.<br />
<br />
To control autoboot on the USRP E31x, first determine the version of UHD, for example by running<br />
<br />
$ uhd_config_info --version<br />
<br />
on the device. The UHD version determines the filesystem location where the <code>autoboot</code> file is located.<br />
<br />
* For UHD 4 and newer<br />
<br />
To enable autoboot:<br />
<br />
$ echo 1 > /sys/devices/soc0/fpga-full/fpga-full:pmu/autoboot<br />
<br />
To disable autoboot:<br />
<br />
$ echo 0 > /sys/devices/soc0/fpga-full/fpga-full:pmu/autoboot<br />
<br />
* For UHD 3.15 and older:<br />
<br />
To enable autoboot:<br />
<br />
$ echo 1 > /sys/devices/axi_pmu.3/autoboot<br />
<br />
To disable autoboot:<br />
<br />
$ echo 0 > /sys/devices/axi_pmu.3/autoboot<br />
<br />
Settings take place immediately; no reboot is required.<br />
<br />
=== Default Password ===<br />
<br />
The default user is <code>root</code> and the password is empty (no password).<br />
<br />
It is recommended to update the <code>root</code> password, which can be done with the command <code>passwd</code>:<br />
<br />
Example Output:<br />
<br />
root@ni-e3x0-SERIAL:~# passwd<br />
Changing password for root<br />
New password:<br />
Re-enter new password:<br />
passwd: password changed.<br />
<br />
==Serial Console Connectivity==<br />
<br />
The easiest way to first communicate with your E31x device is by using the USB Serial Console. Connect a microUSB cable to the Serial Console port on the E31x and connect the other end to a PC. The console will appear as an “FTDI Serial Device” thus, it will likely appear as a ttyUSB device in Linux or a COM port on Windows. In Windows, you will need to edit the properties of the device in ‘Device Manager’ and ‘Enable VCP’. On the PC, open a serial terminal to the E31x using the following parameters: Baud Rate:115200, Data:8bit, Parity: None, Stop:1bit, Flow Control:None.<br />
<br />
On Linux, the following command will typically handle the serial connection:<br />
<br />
sudo screen /dev/ttyUSB0 115200<br />
<br />
You may have to change the device name.<br />
<br />
For additional information about using the serial console and instructions for communicating with the device over other methods (such as connecting with SSH over the network or using and LCD screen, keyboard, and mouse), please refer to the UHD Manual online: https://files.ettus.com/manual/page_usrp_e3xx.html<br />
<br />
==Network Connectivity==<br />
<br />
By default, the E31x device will run a DHCP client on its 1 Gigabit Ethernet port. Assuming your network resolves hostnames (depends on your routers / switches), if you connect the device to your network, you should see it appear with the hostname ettuse300.You can then access the device over SSH.<br />
<br />
If the hostname does not resolve, you can discover the IP address by logging into the device over the serial connection, or checking your network’s DHCP tables.<br />
<br />
Once you have logged in to the device, you can reconfigure the network settings (e.g., you could configure it for a static IP address, if you wish).<br />
<br />
==Updating the Linux File System==<br />
<br />
Before operating the device, it is strongly recommended to update to the latest version of the Embedded Linux file system. If you are operating the device in Network Mode, the version of UHD running on the host machine and E310 USRP must match. <br />
<br />
There are two ways to update the file system for the E310 USRP: <br />
<br />
1. Mender, which is available starting with UHD 4.0.0.0 release only. If you are using UHD 3.15 or prior you'll need to update the microSD card to UHD4 before being able to use Mender to do updates.<br />
<br />
2. Physically remove microSD card from device and write a new file system to the microSD card.<br />
<br />
NOTE: File System Partition Layout<br />
<br />
The SD Card is divided into four partitions. There are two root file system partitions, a "boot" partition and a "data" partition. <br />
<br />
Any data you would like to preserve through Mender updates should be saved to the "data" partition, which is mounted at <code>/data</code>.<br />
<br />
===1. Updating the file system with Mender===<br />
<br />
Mender is third-party software that enables remote updating of the root file system without physically accessing the device (see also the Mender website https://mender.io/ ). Mender can be executed locally on the device, or a Mender server can be set up which can be used to remotely update an arbitrary number of USRP devices. Users can host their own local Mender server, or use servers hosted by Mender as a paid service; contact Mender for more information. <br />
<br />
====Mender Update Process====<br />
<br />
When updating the file system using Mender, the tool will overwrite the root file system partition that is not currently mounted. Any data stored in the root partitions will be permanently lost with a Mender update.<br />
<br />
After updating a partition with Mender, it will reboot into the newly updated partition. Only if the update is confirmed by the user, the update will be made permanent. This means that if an update fails, the device will be always able to reboot into the partition from which the update was originally launched, which presumably is in a working state. Another update can be launched now to correct the previous, failed update, until it works.<br />
<br />
The USRP E31x release images come in two varieties, sg1 and sg1. The variety that you will need depends on the product number of your E31x, which is printed on the bottom of the device. You must use the appropriate files for your specific device. Incorrect files will not work, and will only boot as far as the U-Boot boot loader before stopping.<br />
<br />
For the E310, the product number will be <code>156333X-01L</code>, where X is a letter from A to Z. For devices where X is A, B, C, D, use the <code>sg1</code> files. For devices where X is E or later, use the <code>sg3</code> files.<br />
<br />
For the E312, the product number will be <code>140605X-01L</code>, where X is a letter from A to Z. All E312 USRPs use the <code>sg3</code> files.<br />
<br />
To obtain the file system Mender image (these are files with a <code>.mender</code> suffix), run the following command on the host computer with Internet access:<br />
<br />
$ sudo uhd_images_downloader -t mender -t e310 -t sg# --yes<br />
<br />
where "sg#" is the correct file type as found above, with "#" being either 1 or 3. Example Output:<br />
<br />
$ sudo uhd_images_downloader -t mender -t e310 -t sg3 --yes<br />
[INFO] Using base URL: https://files.ettus.com/binaries/cache/<br />
[INFO] Images destination: /usr/local/share/uhd/images<br />
292014 kB / 292014 kB (100%) e3xx_e310_sg3_mender_default-v4.0.0.0.zip<br />
[INFO] Images download complete.<br />
<br />
NOTE: In the output of the command, the folder destination where the images are saved is printed out.<br />
<br />
NOTE: Regardless of which file type is specified, the extracted mender file will have the same name: <code>usrp_e310_fs.mender</code>.<br />
<br />
Next, you will need to copy this Mender file system image to the USRP E310. This can be done with the Linux utility <code>scp</code>.<br />
<br />
Example code to execute:<br />
<br />
$ scp /usr/local/share/uhd/images/usrp_e310_fs.mender root@192.168.1.51:~/. <br />
<br />
Note: The path and IP may different for your configuration, the command above assumes you're using the default installation path of <code>/usr/local</code> and that the E310's IP is <code>192.168.1.51</code>.<br />
<br />
After copying the Mender file system image to the E310, connect to the E310 using either the Serial Console, or via SSH to gain shell access.<br />
<br />
On the E310, run <code>mender install /path/to/latest.mender</code> to update the file system:<br />
<br />
root@ni-e310-serial:~# mender install /home/root/usrp_e310_fs.mender<br />
<br />
Example Output:<br />
<br />
<pre><br />
root@ni-e310-serial:~# mender install /home/root/usrp_e310_fs.mender <br />
INFO[0000] Start updating from local image file: [/home/root/usrp_e310_fs.mender] module=rootfs<br />
Installing update from the artifact of size 399640064<br />
INFO[0000] opening device /dev/mmcblk0p3 for writing module=block_device<br />
INFO[0000] partition /dev/mmcblk0p3 size: 2046820352 module=block_device<br />
................................ 0% 1024 KiB<br />
................................ 0% 2048 KiB<br />
................................ 0% 3072 KiB<br />
[truncated for readability]<br />
................................ 99% 389120 KiB<br />
................................ 99% 390144 KiB<br />
................................ 100% 390273 KiB<br />
INFO[0740] wrote 2046820352/2046820352 bytes of update to device /dev/mmcblk0p3 module=device<br />
INFO[0744] Enabling partition with new image installed to be a boot candidate: 3 module=device<br />
</pre><br />
<br />
The artifact can also be stored on a remote server:<br />
$ mender install <http://server.name/path/to/latest.mender><br />
<br />
This procedure will take a few minutes to complete. After mender has logged a successful update, reboot the device:<br />
$ reboot<br />
<br />
If the reboot worked, and the device seems functional, commit the changes so that the boot loader knows to permanently boot into this partition:<br />
$ mender -commit<br />
<br />
To identify the currently installed Mender artifact from the command line, the following file can be queried on the E310:<br />
$ cat /etc/mender/artifact_info<br />
<br />
If you are using a Mender server, the updates can be initiated from a web dashboard. From there, you can start the updates without having to log into the device, and you can update groups of USRPs with a few clicks in a web GUI. The dashboard can also be used to inspect the state of USRPs. This is a simple way to update groups of rack-mounted USRPs with custom file systems.<br />
<br />
For more information on updating the file-system, refer to the [https://files.ettus.com/manual/page_usrp_e3xx.html UHD Manual].<br />
<br />
=====Troubleshooting Mender Update=====<br />
<br />
When updating an E31x USRP using mender, it is possible that the update will not apply. For example, if the E31x v3.15.0.0 bootloader is misconfigured then it will not boot into an upgraded mender image. There are 2 solutions to this:<br />
<br />
A. Reimage SD card with full sdimg using dd or bmaptool<br />
<br />
This is the recommended solution. Follow the steps to [[Writing the USRP File System Disk Image to a SD Card|update using the sdimg]]. E31x v4.0.0.0 and later contains the bootloader fix to enable future mender updates.<br />
<br />
B. Manually reconfigure bootloader<br />
<br />
This solution requires some effort, but isn't too difficult. That said, because the SD card is easily accessible on most E31x this is not the recommended solution.<br />
<br />
1) Connect to the [[E310/E312_Getting_Started_Guides#Serial_Console_Connectivity|E31x via serial]]<br />
<br />
2) Boot the device and quickly enter "noautoboot" into the serial console. It can be helpful to have "noautoboot" copied to the clipboard. If completed successfully, you should have a prompt like this:<br />
<br />
Automatic boot in 3s...<br />
Enter 'noautoboot' to enter prompt without timeout<br />
ni-e31x-uboot><br />
<br />
If you don't get this prompt, restart the device and try again.<br />
<br />
3) Configure the bootargs to support mender updates<br />
<br />
setenv bootargs 'root=${mender_kernel_root} rw rootwait uio_pdrv_genirq.of_id=usrp-uio'<br />
saveenv<br />
<br />
4) Reboot device and apply mender image<br />
<br />
NOTE: This solution may brick the E31x USRP if done incorrectly. To unbrick the USRP, follow the solution of overwriting the full SD card image.<br />
<br />
===2. Updating the files system by writing the disk image===<br />
<br />
The microSD card is accessible directly on the Board-only version of the E310 USRP. The E310 Full Enclosure version must be opened with the included Torx wrench. <br />
<br />
NOTE: This method will overwrite all data saved on the microSD card, including any data saved to the <code>/data</code> partition.<br />
<br />
Please see [[Writing the USRP File System Disk Image to a SD Card|this application note]] for step-by-step instructions on writing the file system image to the microSD card.<br />
<br />
==Subdevice Specification Mapping==<br />
<br />
===E310/E312/E313===<br />
<br />
The USRP E31x contains 2 channels, each represented on the front panel as <code>TRX-A / RX2-A</code> and <code>TRX-B / RX2-B</code>. Below is the <code>subdev</code> mapping of RF <br />
<br />
====UHD <3.15.x.x====<br />
* TRX-A / RX2-A = A:0<br />
* TRX-B / RX2-B = B:0<br />
<br />
====UHD 3.15.x.x+====<br />
* TRX-A / RX2-A = A:0<br />
* TRX-B / RX2-B = A:1<br />
<br />
Additional details of UHD Subdevice Specifications can be found here in the UHD Manual: http://files.ettus.com/manual/page_configuration.html#config_subdev<br />
<br />
==Example Programs==<br />
The UHD driver includes several example programs, which may serve as test programs or the basis for your application program. These example programs are already installed on the E31x device, and the source code can be obtained from the UHD repository on GitHub at: https://github.com/EttusResearch/uhd/tree/master/host/examples<br />
<br />
==Test and Verify the Operation of the USRP==<br />
You can quickly verify the operation of your USRP E31x by running the <code>rx_ascii_art_dft</code> UHD example program.<br />
The <code>rx_ascii_art_dft</code> utility is a simple console based, realtime FFT display tool. It is not graphical in nature, so it can be easily run over an SSH connection within a terminal window, and does not need any graphical capability, such as X Windows, to be installed. It can also be run over a serial console connection, although this is not recommended, as the formatting may not render correctly.<br />
<br />
You can run a simple test of the E31x device by connecting an antenna and observing the spectrum of a commercial FM radio station in realtime. Please follow the steps listed below.<br />
<br />
1. Attach an antenna to the RX2A antenna port of the E31x.<br />
<br />
2. Log into the E31x from an external host computer over Ethernet using an SSH client.<br />
<br />
3. At a terminal prompt running on the E31x, run:<br />
<br />
/usr/lib/uhd/examples/rx_ascii_art_dft --freq 88.1e6 --rate 400e3 --gain 30 --ref-lvl -30<br />
<br />
4. Modify the commandline argument "<code>freq</code>" above to specify a tuning frequency for a strong local FM radio station.<br />
<br />
5. You should see a realtime FFT display of 400 KHz of spectrum, centered at the specified tuning frequency.<br />
<br />
6. Type "<code>Q</code>" or <code>Ctrl-C</code> to stop the program and to return to the Linux command line.<br />
<br />
7. You can adjust the size of your terminal window and then rerun the command to enlarge or shrink the FFT display.<br />
<br />
8. You can run with the "help"option to see a description of all available commandline options.<br />
<br />
Additional information is available at the [[Verifying the Operation of the USRP Using UHD and GNU Radio]] Application Note.<br />
<br />
==Battery (E312 Only)==<br />
The USRP E312 is equipped with an integrated 3.7V, 3200mAh lithiumion battery cell. After unboxing the USRP E312 , plug in the power adapter to an AC power source and fully charge the battery. This process with take approximately 2 hours. Do not leave the USRP E312 unit plugged in for more than 24 hours.<br />
<br />
The status LED in the power button indicates the power and charge status of the battery:<br />
<br />
Off: Indicates device is off and not charging.<br />
*Slow Blinking Green: Indicates device is off and charging.<br />
*Fast Blinking Green: Indicates device is on and charging.<br />
*Solid Green: Indicates device is on and not charging (Battery is finished charging).<br />
*Solid Orange: Indicates device is on and discharging.<br />
*Fast Blinking Orange: Indicates device is on, discharging, and charge is below 10% charge.<br />
*Fast Blinking Red: Indicates an error code:<br />
<br />
#Low Voltage Error<br />
#Regulator Low Voltage Error<br />
#FPGA Power Error<br />
#DRAM Power Error<br />
#1.8V Power Rail Error<br />
#3.3V Power Rail Error<br />
#Daughterboard / TX Power Error<br />
#Charger Error<br />
#Charger Temperature Error<br />
#Battery Low Error<br />
#Fuel Gauge Temperature Error<br />
#Global (Enclosure) Temperature Error<br />
<br />
The battery life of the USRP E312 in idle mode is approximately 5 1/2 hours. The battery will enable the USRP E312 to operate for approximately 2 hours 20 minutes, when transmitting and receiving on both channels (2x2 MIMO), with maximum gain settings, at 5 GHz center frequency, and 1 MS/s sample rate. When the power button status LED is in the “Fast Blinking Orange” mode, plug the USRP E312 into an AC power source as soon as possible to recharge the battery.<br />
<br />
If the power button status LED indicates a “Low Voltage Error” (codes 1, 2, 3, 4, 5, 6, 7) or a “Battery Low Error” (code 10), plug the USRP E312 into an AC power source as soon as possible to recharge the battery.<br />
<br />
When the power button status LED indicates at “Temperature Error” or “Charger Error” (codes 8, 9, 11, or 12), power off the USRP E312 unit and allow it to cool down to room temperature. Then, plug in the USRP E312 to and AC power source and fully charge the battery.<br />
<br />
If error codes persist after cooling down and/or recharging the USRP E312, please contact [mailto:support@ettus.com support@ettus.com].<br />
<br />
You can purchase a replacement battery for the E312 at [https://www.ettus.com/product/details/E312-battery https://www.ettus.com/product/details/E312-battery].<br />
<br />
An Application Note covering the replacement of the E312 battery can be found at [[USRP E312 Battery Replacement Instructions]].<br />
<br />
==Battery Calibration Procedure==<br />
In order for the battery gauge to give a usable indication of remaining charge it needs to be calibrated. The procedure for calibration is as follows:<br />
<br />
#Completely charge the battery.<br />
#Type: <code>echo 3200000 >/sys/class/power_supply/BAT/charge_now</code><br />
#Unplug AC power.<br />
#Replug AC power, and wait until charging completes.<br />
<br />
==Battery Safety Information==<br />
To ensure proper use of the battery, please read the the battery specification sheet. This document is available at: [[Media:34118 datasheet.pdf]]<br />
<br />
Because batteries utilize a chemical reaction, battery performance will deteriorate over time even if stored for a long period of time without being used. In addition, if the various usage conditions such as charge, discharge, ambient temperature, etc. are not maintained within the specified ranges, the life expectancy of the battery may be shortened or the device in which the battery is used may be damaged by electrolyte leakage.<br />
<br />
===Handling===<br />
*Do not expose the battery to flame or dispose of it in a fire.<br />
*Do not put the battery in a charger or equipment with the wrong terminals connected.<br />
*Do not short circuit the battery.<br />
*Avoid excessive physical shock or vibration.<br />
*Do not disassemble or deform the battery.<br />
*Do not immerse in water.<br />
*Do not use the battery mixed with other different make, type, or model batteries.<br />
*Keep out of the reach of children.<br />
*Do not use the battery if it appears damaged.<br />
<br />
===Charge and Discharge===<br />
*Always charge the battery while it is installed in the USRP E312 and only use the DC power supply provided in the USRP E312 kit.<br />
*Do not leave the battery charging for longer than 24 hours.<br />
*Never use a modified or damaged USRP E312 DC power supply to charge the battery.<br />
<br />
===Storage===<br />
*Store the battery in a cool, dry, and well-ventilated area. <br />
<br />
===Disposal===<br />
*Regulations vary for different countries. Dispose of the battery in accordance with local regulations.<br />
<br />
==Technical Support and Community Knowledge Base==<br />
Technical support for USRP hardware is available through email only. If the product arrived in a nonfunctional state or you require technical assistance, please contact [mailto:support@ettus.com support@ettus.com]. Please allow 24 to 48 hours for response by email, depending on holidays and weekends, although we are often able to reply more quickly than that.<br />
<br />
We also recommend that you subscribe to the community mailing lists. The mailing lists have a responsive and knowledgeable community of hundreds of developers and technical users who are located around the world. When you join the community, you will be connected to this group of people who can help you learn about SDR and respond to your technical and specific questions. Often your question can be answered quickly on the mailing lists. Each mailing list also provides an archive of all past conversations and discussions going back many years. Your question or problem may have already been addressed before, and a relevant or helpful solution may already exist in the archive.<br />
<br />
Discussions involving the USRP hardware and the UHD software itself are best addressed through the '''usrp-users''' mailing list at [http://usrp-users.ettus.com http://usrp-users.ettus.com].<br />
<br />
Discussions involving the use of [http://gnuradio.org/ GNU Radio] with USRP hardware and UHD software are best addressed through the '''discuss-gnuradio''' mailing list at [https://lists.gnu.org/mailman/listinfo/discussgnuradio https://lists.gnu.org/mailman/listinfo/discussgnuradio].<br />
<br />
Discussions involving the use of [http://openbts.org/ OpenBTS®] with USRP hardware and UHD software are best addressed through the '''openbts-discuss''' mailing list at [https://lists.sourceforge.net/lists/listinfo/openbtsdiscuss https://lists.sourceforge.net/lists/listinfo/openbtsdiscuss].<br />
<br />
The support page on our website is located at [https://www.ettus.com/support https://www.ettus.com/support]. The Knowledge Base is located at [https://kb.ettus.com https://kb.ettus.com].<br />
<br />
==Legal Considerations==<br />
Every country has laws governing the transmission and reception of radio signals. Users are solely responsible for insuring they use their USRP system in compliance with all applicable laws and regulations. Before attempting to transmit and/or receive on any frequency, we recommend that you determine what licenses may be required and what restrictions may apply.<br />
<br />
*NOTE: This USRP product is a piece of test equipment.<br />
<br />
==Sales and Ordering Support==<br />
If you have any non-technical questions related to your order, then please contact us by email at [mailto:orders@ettus.com orders@ettus.com], or by phone at +14086106399 (Monday-Friday, 8 AM - 5 PM, Pacific Time). Please be sure to include your order number and the serial number of your USRP.<br />
<br />
==Terms and Conditions of Sale==<br />
Terms and conditions of sale can be accessed online at the following link: http://www.ettus.com/legal/terms-and-conditions-of-sale<br />
<br />
[[Category:Getting Started Guides]]<br />
[[Category:E310]]<br />
[[Category:E312]]<br />
[[Category:E313]]</div>JonathonPendlumhttps://kb.ettus.com/index.php?title=E320_Getting_Started_Guide&diff=5884E320 Getting Started Guide2023-09-25T20:33:08Z<p>JonathonPendlum: Fix commands for mender update -- missed a command to fix</p>
<hr />
<div>==Kit Contents==<br />
<br />
===E320 Board-only===<br />
{|<br />
|style="vertical-align:top"|<br />
* USRP E320<br />
* Power connector (assembly required) <br />
* 4 M3x0.5, M3x5 Standoffs <br />
* 1 Gb Ethernet Cat-5e Cable (3m)<br />
* USB-A to Micro USB-B Cable (1m)<br />
* 1 Gb SFP+ to RJ45 Adapter<br />
* Getting Started Guide<br />
* Ettus Research Sticker<br />
|[[File:e320 board only.jpg|500px|center]]<br />
|}<br />
<br />
===E320 Full Enclosure===<br />
{|<br />
|style="vertical-align:top"|<br />
* USRP E320 in enclosure <br />
* DC Power Supply (12V, 7A)<br />
* 1 Gb Ethernet Cat-5e Cable (3m)<br />
* USB-A to Micro USB-B Cable (1m)<br />
* 1 Gb SFP+ to RJ45 Adapter<br />
* Getting Started Guide<br />
* Ettus Research Sticker<br />
* T8 Torx Wrench<br />
|[[File:e320 enclosure kit.jpg|500px|center]]<br />
|}<br />
<br />
==Verify the Contents of Your Kit==<br />
Ensure that your kit contains all the items listed above. If any items are missing, please contact sales@ettus.com immediately.<br />
<br />
==You Will Need==<br />
<br />
* For Network Mode: A host computer with an 1 or 10 Gb Ethernet interface. If operating with the 10 Gb Ethernet interface, the "XG" FPGA image must be loaded before the SFP+ port will operate at 10 Gb speeds. Optionally a second 1 Gb Ethernet interface can be used to connect to the onboard ARM CPU for remote management. <br />
<br />
* For Embedded Mode: A host computer is only required for initial device configuration, remote control and management, or data visualization. The host computer can connect to the RJ45 1 Gb port or Serial Console port to remotely access the Open Embedded Linux operating system running on the ARM CPU. Once configured, the USRP E320 can operate as a stand-alone device without a connection to a remote host computer. <br />
<br />
* For Board-only Version: A third-party 10-14V/3A power supply, which requires assembly with the power connect components included in the kit. An assembled power supply can be purchased here: https://www.ettus.com/product/details/12V-PWR<br />
<br />
==Proper Care and Handling==<br />
All Ettus Research products are individually tested before shipment. The USRP is guaranteed to be functional at the time it is received by the customer. Improper use or handling of the USRP can cause the device to become non-functional. Take the following precautions to prevent damage to the unit.<br />
<br />
* Never allow anything especially metal objects to touch the board while it is powered on. <br />
* Always properly terminate the transmit port with an antenna or 50Ω load.<br />
* Always handle the board with proper anti-static methods.<br />
* Never allow the board to directly or indirectly come into contact with any voltage spikes.<br />
* Never allow any water or condensing moisture to come into contact with the device.<br />
* Always use caution with FPGA, firmware, or software modifications.<br />
* Never touch the circuit board or heatsink while the device is powered on. <br />
* All connections should be made/removed while is device is powered off. <br />
<br />
{|<br />
|style="padding-left:10px; padding-right:10px; padding-bottom:10px;" |[[File:Caution.png|24px|center]]<br />
|style="padding-left:10px; padding-right:10px; padding-bottom:10px;" |Never apply more than -15 dBm of power into any RF input.<br />
|-<br />
|style="padding-left:10px; padding-right:10px; padding-bottom:10px;" |[[File:Caution.png|24px|center]]<br />
|style="padding-left:10px; padding-right:10px; padding-bottom:10px;" |Always use at least 30dB attenuation if operating in loopback configuration<br />
|-<br />
|}<br />
<br />
==Install and Setup the Software Tools on Your Host Computer==<br />
<br />
To use your Universal Software Radio Peripheral (USRP™), you must have software tools correctly installed and configured on your host computer. Step-by-step guides for these software tools are found in the Application Notes for Building and Installing the USRP Open-Source Toolchain (UHD and GNU Radio) on [[Building and Installing the USRP Open-Source Toolchain (UHD and GNU Radio) on Linux|Linux]], [[Building and Installing the USRP Open-Source Toolchain (UHD and GNU Radio) on OS X|OS X]] and [[Building and Installing the USRP Open Source Toolchain (UHD and GNU Radio) on Windows|Windows]].<br />
<br />
The USRP E320 requires UHD version 3.13.0.2 or later. It is strongly recommended to use the latest stable release of UHD on both the host computer and the USRP via the filesystem on the SD card. If this release fails to work in some way, then try the maintenance branch of the latest stable version. If you are operating the device in Network Mode, the version of UHD running on the host machine and E320 USRP must match to within the same maintenance release and branch. See the [https://github.com/ettusresearch/uhd UHD GitHub repository] for the latest release and maintenance branch.<br />
<br />
==Connecting the Device==<br />
===Interfaces Overview===<br />
Listed below are the interfaces to connect to the USRP E320. Each interface has specific functionality, limitations and purpose.<br />
<br />
'''Serial Console'''<br />
<br />
The Serial Console provides a low-level interface to the ARM CPU and STM32 microcontroller, typically used for debugging. The serial console can also be used as a JTAG connection to the FPGA.<br />
<br />
'''1 Gb RJ45 Connection'''<br />
<br />
The 1 Gb RJ45 Connection interfaces with the on-board ARM CPU. When operated in "Network mode", this interface can optionally be used for remote control and management traffic. Regardless of the operation mode (Host vs Embedded) this interface can be used to connect to the ARM via SSH. By default, the 1 Gb RJ45 connection is configured to use a DHCP assigned IP address.<br />
<br />
'''SFP+ Connection'''<br />
<br />
The SFP+ Connection supports multiple interfaces for streaming high-speed, low-latency data, depending upon which FPGA image is loaded.<br />
<br />
===Setting up a Serial Console Connection===<br />
It is possible to gain shell access to the device using a serial terminal emulator via the Serial Console port. Most Linux, OS X, or other Unix based operating systems have a utility called <code>screen</code> which can be used for this purpose. <br />
<br />
If you do not have <code>screen</code> installed, it can be installed via your distribution's package manager. For Ubuntu/Debian based operating systems it can be installed with the package manager <code>apt</code> such as:<br />
<br />
sudo apt install screen<br />
<br />
The default Baud Rate for the Serial Console is: <code>115200</code><br />
<br />
The exact device node you should attach to depends on your operating system's driver and other USB devices that might already be connected. Modern Linux systems offer alternatives to simply trying device nodes; instead, the OS might have a directory of symlinks under <code>/dev/serial/by-id</code>:<br />
<br />
$ ls /dev/serial/by-id<br />
usb-FTDI_Dual_RS232-HS-if00-port0<br />
usb-FTDI_Dual_RS232-HS-if01-port0<br />
usb-Silicon_Labs_CP2105_Dual_USB_to_UART_Bridge_Controller_007F6A69-if00-port0<br />
usb-Silicon_Labs_CP2105_Dual_USB_to_UART_Bridge_Controller_007F6A69-if01-port0<br />
<br />
NOTE: Exact names depend on the host operating system version and may differ.<br />
<br />
Every E320 series device connected to USB will by default show up as four different devices. The devices labeled <code>"USB_to_UART_Bridge_Controller"</code> are the devices that offer a serial prompt. The first (with the <code>if00</code> suffix) connects to the <code>STM32 Microcontroller</code>, whereas the second connects to the <code>ARM CPU</code>.<br />
<br />
If you have multiple E320 Serial Consoles connected to a single host, you may have to empirically test nodes.<br />
<br />
Connecting to the ARM CPU can be performed with the command:<br />
<br />
$ sudo screen /dev/serial/by-id/usb-Silicon_Labs_CP2105_Dual_USB_to_UART_Bridge_Controller_007F6A69-if01-port0 115200<br />
<br />
Upon starting the USRP E320, boot messages will appear and rapidly update. Once the boot process successfully completes, a login prompt like the following should appear:<br />
<br />
Alchemy 2018.04 ni-e320-serial ttyPS0<br />
ni-e320-serial login:<br />
<br />
Enter the username: <code>root</code><br />
<br />
By default, the <code>root</code> user's password is left blank. Press the <code>Enter</code> key when prompted for a password.<br />
<br />
You should now be presented with a shell prompt similar to the following:<br />
<br />
root@ni-e320-<motherboard serial #>:~#<br />
<br />
Using the default configuration, the serial console will show all kernel log messages (which are not available when using SSH) and give access to the boot loader (U-boot prompt). This can be used to debug kernel or boot-loader issues more efficiently than when logged in via SSH.<br />
<br />
===Connecting to the microcontroller===<br />
<br />
Using the Serial Console interface, it is possible to connect to the STM32 microcontroller with the command below. The STM32 controls the power sequencing and several other low-level device operations.<br />
<br />
$ sudo screen /dev/serial/by-id/usb-Silicon_Labs_CP2105_Dual_USB_to_UART_Bridge_Controller_007F6A69-if00-port0 115200<br />
<br />
The STM32 interface provides a very simple prompt. The command <code>help</code> will list all available commands. A direct connection to the microcontroller can be used to hard-reset the device without physically accessing it (i.e., emulating a power button press) and other low-level diagnostics.<br />
<br />
===Connecting to the ARM via SSH===<br />
By default, the RJ45 1 Gb management interface is configured to be assigned a DHCP IP address.<br />
<br />
If you have access to a network which provides a DHCP server (such as a common router's LAN), attach the RJ45 1 Gb port to this network. Details vary by vendor, however, most router management interfaces will provide a list of attached devices to the LAN including their IP address.<br />
<br />
Without access to a router management interface, you can identify the IP address by connecting to the ARM CPU via Serial Console as detailed in the section above and running the command <code>ip a</code>:<br />
<br />
Example Output:<br />
<br />
<pre><br />
# ip a<br />
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue qlen 1000<br />
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00<br />
inet 127.0.0.1/8 scope host lo<br />
valid_lft forever preferred_lft forever<br />
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000<br />
link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff<br />
inet 192.168.1.151/24 brd 192.168.1.255 scope global dynamic eth0<br />
valid_lft 42865sec preferred_lft 42865sec<br />
3: sfp0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8000 qdisc pfifo_fast qlen 1000<br />
link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff<br />
inet 192.168.10.2/24 brd 192.168.10.255 scope global sfp0<br />
valid_lft forever preferred_lft forever<br />
</pre><br />
<br />
If you do not have access to a network with a DHCP server, you can create one using the Linux utility <code>dnsmasq</code>:<br />
<br />
$ sudo dnsmasq -i <ETHERNET_ADAPTER_NAME> --dhcp-range=192.168.1.50,192.168.1.100 --except-interface=lo --bind-dynamic --no-daemon<br />
<br />
NOTE: Modify the value <code><ETHERNET_ADAPTER_NAME></code> to match the interface you would like to create a DHCP server on.<br />
<br />
After the device has obtained an IP address, you can remotely log into it from a Linux or macOS systems with SSH, as shown below:<br />
<br />
$ ssh root@192.168.1.51<br />
<br />
NOTE: The IP address may vary depending on your network setup.<br />
<br />
NOTE: The <code>root</code> password is empty/blank.<br />
<br />
On Microsoft Windows, the SSH connection can be established using the third-party program, such as PuTTY.<br />
<br />
After logging in, you should be presented with a shell prompt like the following:<br />
<br />
root@ni-e320-<motherboard serial #>:~#<br />
<br />
==Updating the Linux File System==<br />
Before operating the device, it is strongly recommended to update to the latest version of the Embedded Linux file system. If you are operating the device in Network Mode, the version of UHD running on the host machine and E320 USRP must match. <br />
<br />
There is two ways to update the file system for the E320 USRP: <br />
<br />
1. Mender<br />
<br />
2. Physically remove microSD card from device and write a new file system to the microSD card. <br />
<br />
===File System Partition Layout===<br />
The SD Card is divided into four partitions. There are two root file system partitions, a "boot" partition and a "data" partition. <br />
<br />
Any data you would like to preserve through Mender updates should be saved to the "data" partition, which is mounted at <code>/data</code>.<br />
<br />
===Updating the file system with Mender===<br />
Mender is third-party software that enables remote updating of the root file system without physically accessing the device (see also the Mender website https://mender.io). Mender can be executed locally on the device, or a Mender server can be set up which can be used to remotely update an arbitrary number of USRP devices. Users can host their own local Mender server, or use servers hosted by Mender as a paid service; contact Mender for more information. <br />
<br />
====Mender Update Process====<br />
When updating the file system using Mender, the tool will overwrite the root file system partition that is not currently mounted. Any data stored in the root partitions will be permanently lost with a Mender update.<br />
<br />
After updating a partition with Mender, it will reboot into the newly updated partition. Only if the update is confirmed by the user, the update will be made permanent. This means that if an update fails, the device will be always able to reboot into the partition from which the update was originally launched, which presumably is in a working state. Another update can be launched now to correct the previous, failed update, until it works.<br />
<br />
To obtain the file system Mender image (these are files with a <code>.mender</code> suffix), run the following command on the host computer with Internet access:<br />
<br />
$ sudo uhd_images_downloader -t mender -t e320 --yes<br />
<br />
Example Output:<br />
[INFO] Using base URL: https://files.ettus.com/binaries/cache/<br />
[INFO] Images destination: /usr/local/share/uhd/images<br />
[INFO] No inventory file found at /usr/local/share/uhd/images/inventory.json. Creating an empty one.<br />
301483 kB / 301483 kB (100%) e3xx_e320_mender_default-v4.4.0.0.zip<br />
[INFO] Images download complete.<br />
<br />
NOTE: In the output of the command, the folder destination where the images are saved is printed out.<br />
<br />
Next, you will need to copy this Mender file system image to the USRP E320. This can be done with the Linux utility <code>scp</code>.<br />
<br />
$ scp /usr/local/share/uhd/images/usrp_e320_fs.mender root@192.168.1.51:~/. <br />
<br />
Note: The path and IP may different for your configuration, the command above assumes you're using the default installation path of <code>/usr/local</code> and that the E320's IP is <code>192.168.1.51</code>.<br />
<br />
After copying the Mender file system image to the E320, connect to the E320 using either the Serial Console, or via SSH to gain shell access.<br />
<br />
On the E320, run <code>mender install /path/to/latest.mender</code> to update the file system:<br />
<br />
root@ni-e320-serial:~# mender install /home/root/usrp_e320_fs.mender<br />
<br />
Example Output:<br />
<br />
<pre><br />
root@ni-e320-316E375:~# mender install /home/root/usrp_e320_fs.mender <br />
INFO[0000] Start updating from local image file: [/home/root/usrp_e320_fs.mender] module=rootfs<br />
Installing update from the artifact of size 399640064<br />
INFO[0000] opening device /dev/mmcblk0p3 for writing module=block_device<br />
INFO[0000] partition /dev/mmcblk0p3 size: 2046820352 module=block_device<br />
................................ 0% 1024 KiB<br />
................................ 0% 2048 KiB<br />
................................ 0% 3072 KiB<br />
[truncated for readability]<br />
................................ 99% 389120 KiB<br />
................................ 99% 390144 KiB<br />
................................ 100% 390273 KiB<br />
INFO[0740] wrote 2046820352/2046820352 bytes of update to device /dev/mmcblk0p3 module=device<br />
INFO[0744] Enabling partition with new image installed to be a boot candidate: 3 module=device<br />
<br />
</pre><br />
<br />
The artifact can also be stored on a remote server:<br />
$ mender install <http://server.name/path/to/latest.mender><br />
<br />
This procedure will take a few minutes to complete. After mender has logged a successful update, reboot the device:<br />
$ reboot<br />
<br />
If the reboot worked, and the device seems functional, commit the changes so that the boot loader knows to permanently boot into this partition:<br />
$ mender -commit<br />
<br />
To identify the currently installed Mender artifact from the command line, the following file can be queried on the E320:<br />
$ cat /etc/mender/artifact_info<br />
<br />
If you are using a Mender server, the updates can be initiated from a web dashboard. From there, you can start the updates without having to log into the device, and you can update groups of USRPs with a few clicks in a web GUI. The dashboard can also be used to inspect the state of USRPs. This is a simple way to update groups of rack-mounted USRPs with custom file systems.<br />
<br />
For more information on updating the file-system, refer to the E3xx page in the Devices section of the UHD Manual at http://uhd.ettus.com.<br />
<br />
===Updating the files system by writing the disk image===<br />
The microSD card is accessible directly on the Board-only version of the E320 USRP. The E320 Full Enclosure version must be opened with the included Torx wrench. <br />
<br />
NOTE: This method will overwrite all data saved on the microSD card, including any data saved to the <code>/data</code> partition.<br />
<br />
Please see the separate application note, [[Writing the USRP File System Disk Image to a SD Card]], for step-by-step instructions on writing the file system image to the microSD card.<br />
<br />
==Updating the Network Configurations==<br />
The USRP E320 systemd network configuration files are located either at: <code>/etc/systemd/network/</code><br />
<br />
# ls /etc/systemd/network/<br />
eth0.network sfp0.network <br />
<br />
or for newer versions of the file system: <code>/data/network/</code><br />
<br />
# ls /data/network/<br />
eth0.network int0.network sfp0.network<br />
<br />
For details on configuration please refer to the [https://www.freedesktop.org/software/systemd/man/systemd.network.html systemd-networkd manual pages].<br />
<br />
The factory settings are as follows:<br />
<pre><br />
eth0 (DHCP):<br />
<br />
[Match]<br />
Name=eth0<br />
<br />
[Network]<br />
DHCP=v4<br />
<br />
[DHCPv4]<br />
UseHostname=false<br />
<br />
sfp0 (static):<br />
<br />
[Match]<br />
Name=sfp0<br />
<br />
[Network]<br />
Address=192.168.10.2/24<br />
<br />
[Link]<br />
MTUBytes=8000<br />
</pre><br />
<br />
Additional notes on networking:<br />
<br />
* Care needs to be taken when editing these files on the device, since <code>vi</code> / <code>vim</code> sometimes generates undo files (e.g. <code>/data/network/sfp0.network~</code>), that <code>systemd-networkd</code> might accidentally pick up.<br />
* Temporarily setting the IP addresses or MTU sizes via <code>ifconfig</code> or other command line tools will only change the value until the next reboot or reload of the FPGA image.<br />
* If the MTU of the device and host computers differ, streaming issues can occur.<br />
* Streaming via SFP0 at 1 Gb rates requires a MTU of <code>1500</code><br />
* Streaming via SFP0 at 10 Gb rates requires a MTU of <code>8000</code><br />
<br />
For addition details on network configuration here: https://files.ettus.com/manual/page_usrp_e320.html#e320_network_configuration<br />
<br />
==Updating the FPGA Image==<br />
<br />
===Network mode FPGA Image Update===<br />
The FPGA image should match the version of UHD installed on the host computer when operated in Network mode. <br />
<br />
Network mode FPGA image updates must be made through the RJ45 management interface.<br />
<br />
To obtain all the FPGA images for your installed version of UHD, run the following command on the host computer with internet access:<br />
<br />
$ sudo uhd_images_downloader -t e320 -t fpga<br />
<br />
Example Output:<br />
<br />
$ uhd_images_downloader -t e320 -t fpga<br />
[INFO] Images destination: /usr/local/share/uhd/images<br />
[INFO] No inventory file found at /usr/local/share/uhd/images/inventory.json. Creating an empty one.<br />
05920 kB / 05920 kB (100%) e3xx_e320_fpga_default-g494ae8bb.zip<br />
[INFO] Images download complete.<br />
<br />
There is two versions of the E320 FPGA images shipped with UHD:<br />
<br />
- <code>1G</code> for 1 Gb rates on the SFP+ port (default image)<br />
<br />
- <code>XG</code> for 10 Gb rates on the SFP+ port<br />
<br />
In this example, we load the <code>XG</code> variant of the FPGA image.<br />
<br />
$ uhd_image_loader --args "type=e3xx,mgmt_addr=<E320_RJ45_IP_ADDR>,fpga=XG"<br />
<br />
Example Output:<br />
<br />
$ uhd_image_loader --args "mgmt_addr=192.168.1.51,type=e3xx,fpga=XG"<br />
[INFO] [UHD] linux; GNU C++ version 5.4.0 20160609; Boost_105800; UHD_3.13.1.0-1-gd3b7e90a<br />
[INFO] [MPMD] Initializing 1 device(s) in parallel with args: mgmt_addr=192.168.1.51,type=e3xx,product=e320,serial=316E375,claimed=False,skip_init=1<br />
[INFO] [MPMD] Claimed device without full initialization.<br />
[INFO] [MPMD IMAGE LOADER] Starting update. This may take a while.<br />
[INFO] [MPM.PeriphManager] Updating component `fpga'<br />
[INFO] [MPM.PeriphManager] Updating component `dts'<br />
[INFO] [MPM.RPCServer] Resetting peripheral manager.<br />
[INFO] [MPM.PeriphManager] Device serial number: 316E375<br />
[INFO] [MPMD IMAGE LOADER] Update component function succeeded.<br />
[INFO] [MPM.PeriphManager] Found 1 daughterboard(s).<br />
<br />
The FPGA is immediately updated, and this FPGA image will continue to be used. The device does not need to be power cycled to use the new image. <br />
<br />
To load a different FPGA image (i.e. <code>1G</code>), modify the device argument <code>fpga=</code> to a value of <code>fpga=1G</code>.<br />
<br />
To specify the path to a custom FPGA image, use the <code>--fpga-path</code> argument.<br />
<br />
$ uhd_image_loader --args "type=e3xx,mgmt_addr=<E320_RJ45_IP_ADDR>" --fpga-path=/path/to/custom/fpga.bit<br />
<br />
<br />
{|<br />
|style="padding-left:10px; padding-right:10px; padding-bottom:10px;" |[[File:Caution.png|24px|center]]<br />
|style="padding-left:10px; padding-right:10px; padding-bottom:10px;" |The Verilog code for the FPGA in the USRP E320 is open-source, and users are free to modify and customize it for their needs. However, certain modifications may result in either bricking the device, or even in physical damage to the unit. Please note that modifications to the FPGA are made at the risk of the user, and may not be covered by the warranty of the device.<br />
|-<br />
|}<br />
<br />
<br />
===Embedded Mode FPGA Image Update===<br />
<br />
It is possible to update the FPGA image when operated in Embedded mode. Connect to the ARM CPU [[#Setting_up_a_Serial_Console_Connection|via Serial Console]] or [[E320_Getting_Started_Guide#Connecting_to_the_ARM_via_SSH| via SSH]]. It is generally recommend to use SSH over the RJ45 interface for remote management. <br />
<br />
Run the command <code>uhd_images_downloader</code> to download the FPGA images to the device's file system:<br />
<br />
NOTE: The 1 Gb RJ45 management interface will require Internet access for this next step.<br />
<br />
<pre><br />
root@ni-e320-serial:~# python3 /usr/bin/uhd_images_downloader -t e320 -t fpga<br />
[INFO] Images destination: /usr/share/uhd/images<br />
[INFO] No inventory file found at /usr/share/uhd/images/inventory.json. Creating an empty one.<br />
05920 kB / 05920 kB (100%) e3xx_e320_fpga_default-g494ae8bb.zip<br />
[INFO] Images download complete.<br />
</pre><br />
<br />
NOTE: The default UHD FPGA Images destination within the E320's file-system is <code>/usr/share/uhd/images</code>. The default UHD FPGA Images destination on a typical host installation is <code>/usr/local/share/uhd/images</code>.<br />
<br />
Updating the FPGA image from the ARM CPU is the same as detailed above for a Network mode update:<br />
<br />
<pre><br />
root@ni-e320-serial:~# uhd_image_loader --args "type=e3xx,fpga=1G"<br />
[INFO] [UHD] linux; GNU C++ version 7.3.0; Boost_106600; UHD_3.13.1.0-0-unknown<br />
[INFO] [MPMD] Initializing 1 device(s) in parallel with args: mgmt_addr=127.0.0.1,type=e3xx,product=e320,serial=316E375,claimed=False,skip_init=1<br />
[INFO] [MPM.PeriphManager.UDP] No CHDR interfaces found!<br />
[INFO] [MPM.PeriphManager.UDP] No CHDR interfaces found!<br />
[INFO] [MPMD] Claimed device without full initialization.<br />
[INFO] [MPMD IMAGE LOADER] Starting update. This may take a while.<br />
[INFO] [MPM.PeriphManager] Updating component `fpga'<br />
[INFO] [MPM.PeriphManager] Updating component `dts'<br />
[INFO] [MPM.RPCServer] Resetting peripheral manager.<br />
[INFO] [MPM.PeriphManager] Device serial number: 316E375<br />
[INFO] [MPMD IMAGE LOADER] Update component function succeeded.<br />
[INFO] [MPM.PeriphManager] Found 1 daughterboard(s).<br />
<br />
</pre><br />
<br />
For more information on updating the FPGA image, refer to the UHD Manual at http://uhd.ettus.com.<br />
<br />
==Setting Up a Streaming Connection==<br />
The device supports multiple high-speed, low-latency interfaces on the SFP+ port for streaming samples to the host computer.<br />
<br />
===1 Gb Streaming via SFP+ Port ===<br />
Complete the steps below to set up a streaming connection over the 1 Gb Ethernet interface on the <code>SFP+ Port</code>.<br />
<br />
NOTE: The <code>1G</code> FPGA image must be loaded for the <code>SFP+ Port</code> to operate at 1 Gb speeds. If the <code>XG</code> image is loaded, the port will be unresponsive at 1Gb speeds.<br />
<br />
1. Configure your Host's 1 Gb Ethernet interface as shown below. This interface should be separate from the 1 Gb NIC/network which is connected to the 1 Gb RJ45 management interface. <br />
<br />
IP Address: 192.168.10.1<br />
Subnet Mask: 255.255.255.0<br />
Gateway: 0.0.0.0<br />
MTU: 1500<br />
<br />
NOTE: When operating the <code>SFP+ Port</code> at 1 Gb speeds, it is important to set a MTU of <code>1500</code> and not a value of <code>automatic</code>. Mismatched MTU values on either the Host or E320 may cause flow control errors. Your computer may need to be restarted for the MTU value to take effect.<br />
<br />
2. Insert the RJ45-to-SFP+ adapter into the <code>SFP+ Port</code>.<br />
<br />
3. Connect the SFP+ adapter on the device to an Ethernet port on the host computer using a standard Ethernet cable.<br />
<br />
The Green LED above the <code>SFP+ Port</code> should illuminate.<br />
<br />
4. To test the connection, <code>ping</code> the device at address <code>192.168.10.2</code> from the host, as shown below:<br />
<br />
$ ping 192.168.10.2<br />
PING 192.168.10.2 (192.168.10.2) 56(84) bytes of data.<br />
64 bytes from 192.168.10.2: icmp_seq=1 ttl=64 time=1.06 ms<br />
^C<br />
--- 192.168.10.2 ping statistics ---<br />
1 packets transmitted, 1 received, 0% packet loss, time 0ms<br />
rtt min/avg/max/mdev = 1.065/1.065/1.065/0.000 ms<br />
<br />
Press <code>CTRL+C</code> to stop the ping program.<br />
<br />
5. Verify your MTU is set correctly for 1 Gb speeds on the E320. See the section [[E320_Getting_Started_Guide#Updating_the_Network_Configurations|Updating the Network Configurations]] for additional details.<br />
<br />
Proceed to the next section [[E320_Getting_Started_Guide#Verifying_Device_Operation|Verifying Device Operation]].<br />
<br />
===10 Gb Streaming via SFP+ Port===<br />
Load the <code>XG</code> FPGA image for 10 Gb streaming as detailed in the section [[E320_Getting_Started_Guide#Updating_the_FPGA_Image|Updating the FPGA Image]]. You will need to use a 10 GigE cable that can be plugged in directly to the SFP+ connector on the board. <br />
<br />
NOTE: The <code>XG</code> FPGA image must be loaded for the <code>SFP+ Port</code> to operate at 10 Gb speeds. If the <code>1G</code> image is loaded, the port will be unresponsive at 10 Gb speeds. Mismatched MTU values on either the Host or E320 may cause flow control errors.<br />
<br />
1. Configure your Host's 10 Gb Ethernet interface as shown below. <br />
<br />
IP Address: 192.168.10.1<br />
Subnet Mask: 255.255.255.0<br />
Gateway: 0.0.0.0<br />
MTU: 8000<br />
<br />
NOTE: When operating the <code>SFP+ Port</code> at 10 Gb speeds, it is important to set a MTU of <code>8000</code> and not a value of <code>automatic</code>. Mismatched MTU values on either the Host or E320 may cause flow control errors. Your computer may need to be restarted for the MTU value to take effect.<br />
<br />
2. Connect the SFP+ port on the device to an Ethernet port on the host computer using a 10 Gb SFP+ copper or fiber cable.<br />
<br />
The Green LED above the <code>SFP+ Port</code> should illuminate.<br />
<br />
4. To test the connection, <code>ping</code> the device at address <code>192.168.10.2</code> from the host, as shown below:<br />
<br />
$ ping 192.168.10.2<br />
PING 192.168.10.2 (192.168.10.2) 56(84) bytes of data.<br />
64 bytes from 192.168.10.2: icmp_seq=1 ttl=64 time=1.06 ms<br />
^C<br />
--- 192.168.10.2 ping statistics ---<br />
1 packets transmitted, 1 received, 0% packet loss, time 0ms<br />
rtt min/avg/max/mdev = 1.065/1.065/1.065/0.000 ms<br />
<br />
Press <code>CTRL+C</code> to stop the ping program.<br />
<br />
5. Verify your MTU is set correctly for 10 Gb speeds on the E320. See the section [[E320_Getting_Started_Guide#Updating_the_Network_Configurations|Updating the Network Configurations]] for additional details.<br />
<br />
Proceed to the next section [[E320_Getting_Started_Guide#Verifying_Device_Operation|Verifying Device Operation]].<br />
<br />
==Verifying Device Operation==<br />
Once you have successfully setup a management interface and streaming interface, you can now verify the devices operation using the include UHD utilities.<br />
<br />
===Subdevice Specification Mapping===<br />
The USRP E320 contains 2 channels, each represented on the front panel as <code>RF A</code> and <code>RF B</code>. Below is the <code>subdev</code> mapping of RF Ports.<br />
<br />
'''E320'''<br />
* RF A = A:0<br />
* RF B = A:1<br />
<br />
Additional details of UHD Subdevice Specifications can be found here in the UHD Manual: http://files.ettus.com/manual/page_configuration.html#config_subdev<br />
<br />
===Supported Sample Rates===<br />
<br />
The USRP E320 supports master clock rate from 200 kHz to 61.44 MHz and can be changed by adding <code>master_clock_rate=<rate></code> to the default UHD args. The default master clock rate is 16 MHz. <br />
<br />
Sample rates as delivered to/from the host computer for USRP devices are constrained to follow several important rules.<br />
<br />
It is important to understand that strictly-integer decimation and interpolation are used within USRP hardware to meet the requested sample rate requirements of the application at hand. That means that the desired sample rate must meet the requirement that master-clock-rate/desired-sample-rate be an integer ratio. Further, it is strongly desirable for that ratio to be even. This ratio is the decimation (down-conversion) or interpolation (up-conversion) factor. The decimation or interpolation factor may be between 1 and 1024. There are further constraints on the decimation or interpolation factor. If the decimation or interpolation factor exceeds 128, then it must be evenly divisible by 2. If the decimation or interpolation factor exceeds 256, then it must be evenly divisible by 4.<br />
<br />
Additional information on Sample Rates can be found here in the UHD Manual: http://files.ettus.com/manual/page_general.html#general_sampleratenotes<br />
<br />
===Probe the USRP E320===<br />
The UHD utility <code>uhd_usrp_probe</code> provides detailed information of the USRP device.<br />
<br />
From your host computer, run the command <code>uhd_usrp_probe</code>:<br />
<br />
<pre><br />
$ uhd_usrp_probe --args "addr=192.168.10.2"<br />
[INFO] [UHD] linux; GNU C++ version 5.4.0 20160609; Boost_105800; UHD_3.13.1.0-1-gd3b7e90a<br />
[INFO] [MPMD] Initializing 1 device(s) in parallel with args: mgmt_addr=192.168.10.2,type=e3xx,product=e320,serial=316E375,claimed=False,addr=192.168.10.2<br />
[INFO] [MPM.PeriphManager] init() called with device args `product=e320,mgmt_addr=192.168.10.2'.<br />
[INFO] [0/DmaFIFO_0] Initializing block control (NOC ID: 0xF1F0D00000000000)<br />
[INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1343 MB/s)<br />
[INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1335 MB/s)<br />
[INFO] [0/Radio_0] Initializing block control (NOC ID: 0x12AD100000003320)<br />
[INFO] [0/DDC_0] Initializing block control (NOC ID: 0xDDC0000000000000)<br />
[INFO] [0/DUC_0] Initializing block control (NOC ID: 0xD0C0000000000002)<br />
[INFO] [0/Radio_0] Performing CODEC loopback test... <br />
[INFO] [0/Radio_0] CODEC loopback test passed<br />
[INFO] [0/Radio_0] Performing CODEC loopback test... <br />
[INFO] [0/Radio_0] CODEC loopback test passed<br />
_____________________________________________________<br />
/<br />
| Device: E300-Series Device<br />
| _____________________________________________________<br />
| /<br />
| | Mboard: ni-e320-316E375<br />
| | eeprom_version: 2<br />
| | mpm_version: 3.13.1.0-gd3b7e90a<br />
| | pid: 58144<br />
| | product: e320<br />
| | rev: 2<br />
| | rpc_connection: remote<br />
| | serial: 316E375<br />
| | type: e3xx<br />
| | MPM Version: 1.2<br />
| | FPGA Version: 3.0<br />
| | RFNoC capable: Yes<br />
| | <br />
| | Time sources: internal, external, gpsdo<br />
| | Clock sources: external, internal, gpsdo<br />
| | Sensors: gps_locked, temp_main_power, ref_locked, temp_rf_channelA, temp_fpga, gps_sky, temp_rf_channelB, fan, temp_internal, gps_tpv, gps_time<br />
| | _____________________________________________________<br />
| | /<br />
| | | RX Dboard: A<br />
| | | _____________________________________________________<br />
| | | /<br />
| | | | RX Frontend: 0<br />
| | | | Name: Neon<br />
| | | | Antennas: RX2, TX/RX<br />
| | | | Sensors: lo_locked, ad9361_temperature, rssi, lo_lock<br />
| | | | Freq range: 70.000 to 6000.000 MHz<br />
| | | | Gain range PGA: 0.0 to 76.0 step 1.0 dB<br />
| | | | Bandwidth range: 20000000.0 to 40000000.0 step 0.0 Hz<br />
| | | | Connection Type: IQ<br />
| | | | Uses LO offset: No<br />
| | | _____________________________________________________<br />
| | | /<br />
| | | | RX Frontend: 1<br />
| | | | Name: Neon<br />
| | | | Antennas: RX2, TX/RX<br />
| | | | Sensors: lo_locked, ad9361_temperature, rssi, lo_lock<br />
| | | | Freq range: 70.000 to 6000.000 MHz<br />
| | | | Gain range PGA: 0.0 to 76.0 step 1.0 dB<br />
| | | | Bandwidth range: 20000000.0 to 40000000.0 step 0.0 Hz<br />
| | | | Connection Type: IQ<br />
| | | | Uses LO offset: No<br />
| | | _____________________________________________________<br />
| | | /<br />
| | | | RX Codec: A<br />
| | | | Name: AD9361 Dual ADC<br />
| | | | Gain Elements: None<br />
| | _____________________________________________________<br />
| | /<br />
| | | TX Dboard: A<br />
| | | _____________________________________________________<br />
| | | /<br />
| | | | TX Frontend: 0<br />
| | | | Name: Neon<br />
| | | | Antennas: TX/RX<br />
| | | | Sensors: lo_locked, ad9361_temperature<br />
| | | | Freq range: 47.000 to 6000.000 MHz<br />
| | | | Gain range PGA: 0.0 to 89.8 step 0.2 dB<br />
| | | | Bandwidth range: 20000000.0 to 40000000.0 step 0.0 Hz<br />
| | | | Connection Type: IQ<br />
| | | | Uses LO offset: No<br />
| | | _____________________________________________________<br />
| | | /<br />
| | | | TX Frontend: 1<br />
| | | | Name: Neon<br />
| | | | Antennas: TX/RX<br />
| | | | Sensors: lo_locked, ad9361_temperature<br />
| | | | Freq range: 47.000 to 6000.000 MHz<br />
| | | | Gain range PGA: 0.0 to 89.8 step 0.2 dB<br />
| | | | Bandwidth range: 20000000.0 to 40000000.0 step 0.0 Hz<br />
| | | | Connection Type: IQ<br />
| | | | Uses LO offset: No<br />
| | | _____________________________________________________<br />
| | | /<br />
| | | | TX Codec: A<br />
| | | | Name: AD9361 Dual DAC<br />
| | | | Gain Elements: None<br />
| | _____________________________________________________<br />
| | /<br />
| | | RFNoC blocks on this device:<br />
| | | <br />
| | | * DmaFIFO_0<br />
| | | * Radio_0<br />
| | | * DDC_0<br />
| | | * DUC_0<br />
<br />
</pre><br />
<br />
<br />
<br />
===ASCII Art Example===<br />
The UHD driver includes several example programs, which may serve as test programs or the basis for your application program. The source code can be obtained from the UHD repository on github at: https://github.com/EttusResearch/uhd/tree/master/host/examples<br />
<br />
You can quickly verify the operation of your USRP E320 by running the <code>rx_ascii_art_dft</code> UHD example program.<br />
<br />
The <code>rx_ascii_art_dft</code> utility is a simple console based, real-time FFT display tool. It is not graphical in nature, so it can be easily run over an SSH connection within a terminal window, and does not need any graphical capability, such as X Windows, to be installed. It can also be run over a serial console connection, although this is not recommended, as the formatting may not render correctly.<br />
<br />
You can run a simple test of the E320 USRP by connecting an antenna and observing the spectrum of a commercial FM radio station in real-time, following the steps below:<br />
<br />
1. Attach an antenna to the <code>RF A / RX2</code> antenna port of the E320.<br />
<br />
2. From your host computer, run the command:<br />
<br />
$ /usr/local/lib/uhd/examples/rx_ascii_art_dft \<br />
--args "addr=192.168.10.2" \<br />
--freq 98.5e6 \<br />
--rate 2e6 \<br />
--gain 40 \<br />
--ref-lvl="-30" \<br />
--dyn-rng 90 \<br />
--ant "RX2" \<br />
--subdev "A:0"<br />
<br />
NOTE: Modify the commandline argument <code>freq</code> above to specify a tuning frequency for a strong local FM radio station. You will also need to update the IP Address to match your device IP.<br />
<br />
3. You should see a real-time FFT display of 2 MHz of spectrum, centered at the specified tuning frequency.<br />
<br />
4. Type "<code>Q</code>" to stop the program and to return to the Linux command line.<br />
<br />
5. You can run with the <code>--help</code> argument to see a description of all available command-line options.<br />
<br />
Example Output:<br />
<br />
<pre><br />
$ ./rx_ascii_art_dft --args "addr=192.168.10.2" --freq 98.5e6 --rate 2e6 --gain 40 --ref-lvl="-30" --dyn-rng 90 --ant "RX2" --subdev "A:0"<br />
<br />
Creating the usrp device with: addr=192.168.10.2...<br />
[INFO] [UHD] linux; GNU C++ version 5.4.0 20160609; Boost_105800; UHD_3.13.1.0-1-gd3b7e90a<br />
[INFO] [MPMD] Initializing 1 device(s) in parallel with args: mgmt_addr=192.168.10.2,type=e3xx,product=e320,serial=316E375,claimed=False,addr=192.168.10.2<br />
[INFO] [0/DmaFIFO_0] Initializing block control (NOC ID: 0xF1F0D00000000000)<br />
[INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1334 MB/s)<br />
[INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1325 MB/s)<br />
[INFO] [0/Radio_0] Initializing block control (NOC ID: 0x12AD100000003320)<br />
[INFO] [0/DDC_0] Initializing block control (NOC ID: 0xDDC0000000000000)<br />
[INFO] [0/DUC_0] Initializing block control (NOC ID: 0xD0C0000000000002)<br />
[INFO] [MPM.PeriphManager] init() called with device args `product=e320,mgmt_addr=192.168.10.2'.<br />
[INFO] [0/Radio_0] Performing CODEC loopback test... <br />
[INFO] [0/Radio_0] CODEC loopback test passed<br />
[INFO] [0/Radio_0] Performing CODEC loopback test... <br />
[INFO] [0/Radio_0] CODEC loopback test passed<br />
Using Device: Single USRP:<br />
Device: E300-Series Device<br />
Mboard 0: ni-e320-316E375<br />
RX Channel: 0<br />
RX DSP: 0<br />
RX Dboard: A<br />
RX Subdev: Neon<br />
TX Channel: 0<br />
TX DSP: 0<br />
TX Dboard: A<br />
TX Subdev: Neon<br />
TX Channel: 1<br />
TX DSP: 1<br />
TX Dboard: A<br />
TX Subdev: Neon<br />
<br />
Setting RX Rate: 2.000000 Msps...<br />
Actual RX Rate: 2.000000 Msps...<br />
<br />
Setting RX Freq: 98.500000 MHz...<br />
Actual RX Freq: 98.500000 MHz...<br />
<br />
Setting RX Gain: 40.000000 dB...<br />
Actual RX Gain: 40.000000 dB...<br />
<br />
Checking RX: all_los: locked ...<br />
<br />
Done!<br />
</pre><br />
<br />
===Benchmarking your system===<br />
Included with the UHD driver example programs is a utility, <code>benchmark_rate</code> to benchmark the transport link of the system.<br />
<br />
A system's maximum performance is dependent upon many factors. <code>benchmark_rate</code> will exercise the transport link and CPU of the system.<br />
<br />
====1 Gb Interface====<br />
NOTE: This example requires the <code>1G</code> FPGA image to be loaded.<br />
<br />
This example will test one full-duplex stream using "RFA/A:0", at a rate of 2 MS/s, for 60 seconds:<br />
<br />
/usr/local/lib/uhd/examples/benchmark_rate \<br />
--args "addr=192.168.10.2" \<br />
--duration 60 \<br />
--channels "0" \<br />
--rx_rate 2e6 \<br />
--rx_subdev "A:0" \<br />
--tx_rate 2e6 \<br />
--tx_subdev "A:0"<br />
<br />
This example will test two full-duplex streams at 2 MS/s, for 60 seconds:<br />
<br />
/usr/local/lib/uhd/examples/benchmark_rate \<br />
--args "addr=192.168.10.2" \<br />
--duration 60 \<br />
--channels "0,1" \<br />
--rx_rate 2e6 \<br />
--rx_subdev "A:0 A:1" \<br />
--tx_rate 2e6 \<br />
--tx_subdev "A:0 A:1"<br />
<br />
This example will test two full-duplex streams at 12.5 MS/s, for 60 seconds:<br />
<br />
/usr/local/lib/uhd/examples/benchmark_rate \<br />
--args "addr=192.168.10.2,master_clock_rate=25e6" \<br />
--duration 60 \<br />
--channels "0,1" \<br />
--rx_rate 12.5e6 \<br />
--rx_subdev "A:0 A:1" \<br />
--tx_rate 12.5e6 \<br />
--tx_subdev "A:0 A:1"<br />
<br />
When streaming samples over a 1 Gb transport link, the maximum accumulative rate for all channels is 25 MS/s with a <code>sc16</code> OTW format. To achieve higher streaming rates, it is recommended to use the 10 Gb interfaces.<br />
<br />
====10 Gb Interface ====<br />
NOTE: These examples require the <code>XG</code> FPGA image to be loaded.<br />
<br />
This example will test one full-duplex stream using "RFA/A:0", at a rate of 61.44 MS/s, for 60 seconds:<br />
<br />
/usr/local/lib/uhd/examples/benchmark_rate \<br />
--args "addr=192.168.10.2,master_clock_rate=61.44e6" \<br />
--duration 60 \<br />
--channels "0" \<br />
--rx_rate 61.44e6 \<br />
--rx_subdev "A:0" \<br />
--tx_rate 61.44e6 \<br />
--tx_subdev "A:0" <br />
<br />
This example will test two full-duplex stream, at a rate of 30.72 MS/s, for 60 seconds:<br />
<br />
/usr/local/lib/uhd/examples/benchmark_rate \<br />
--args "addr=192.168.10.2,master_clock_rate=61.44e6" \<br />
--duration 60 \<br />
--channels "0,1" \<br />
--rx_rate 30.72e6 \<br />
--rx_subdev "A:0 A:1" \<br />
--tx_rate 30.72e6 \<br />
--tx_subdev "A:0 A:1"<br />
<br />
==USRP E320 Device Specific Operations==<br />
<br />
===Turning the Device Off/On===<br />
To avoid damaging the file system and causing any corruption, do not turn the device off with the power button without first shutting down the system. Use this command to cleanly and properly shut the system down:<br />
<br />
shutdown -h now<br />
<br />
=== Autoboot ===<br />
<br />
The USRP E320 can be configured to power on and boot automatically when power is applied. By default, autoboot is disabled on all USRPs that support it. To control autoboot on the USRP E320, first determine the current value for <code>MCU_FLAGS[0]</code> by running <code>eeprom-dump</code>; the meaning of the <code>MCU_FLAGS[0]</code> [https://files.ettus.com/manual/page_usrp_e3xx.html#e320_eeprom_flags is found in the UHD manual]. The least significant bit when <code>MCU_FLAGS[0]</code> is viewed as a binary value controls the autoboot.<br />
<br />
For example<br />
<pre><br />
root@ni-e320-XXXXXXX:~# eeprom-dump<br />
-- PID/REV: e320 0002<br />
-- MCU_FLAGS[0]: 00000008<br />
-- MCU_FLAGS[1]: 00000000<br />
-- MCU_FLAGS[2]: 00000000<br />
-- MCU_FLAGS[3]: 00000000<br />
-- Serial: XXXXXXX<br />
-- eth_addr0: XX:XX:XX:XX:XX:XX<br />
-- eth_addr1: XX:XX:XX:XX:XX:XX<br />
-- eth_addr2: XX:XX:XX:XX:XX:XX<br />
-- DT-Compat/MCU-Compat: 0000 0002<br />
-- CRC: cbd79a61 (matches)<br />
</pre><br />
shows <code>-- MCU_FLAGS[0]: 00000008</code>; <code>0x08</code> (<code>0b00001000</code> in binary) indicates that autoboot is disabled. If this value were <code>0x09</code> (<code>0b00001001</code> in binary) it would indicate that autoboot is enabled because least significant bit is 1; same would be true if this value is <code>0x01</code> (<code>0b00000001</code> in binary).<br />
<br />
To enable or disable autoboot, copy the existing value of <code>MCU_FLAGS[0]</code> retrieved by <code>eeprom-dump</code> into <code><MCU_FLAGS[0]></code> below and run the command:<br />
<br />
* Disable autoboot on USRP E320 (sets least significant bit to 0), regardless of whether currently enabled or disabled:<br />
<pre><br />
root@ni-e320-XXXXXXX:~# eeprom-set-flags $((0x<MCU_FLAGS[0]> & ~0x1))<br />
</pre><br />
Thus, for the value noted above (autoboot is already disabled, so this command doesn't actually change anything):<br />
<pre><br />
root@ni-e320-XXXXXXX:~# eeprom-set-flags $((0x00000008 & ~0x1))<br />
-- PID/REV: e320 0002<br />
-- MCU_FLAGS[0]: 00000008<br />
-- MCU_FLAGS[1]: 00000000<br />
-- MCU_FLAGS[2]: 00000000<br />
-- MCU_FLAGS[3]: 00000000<br />
-- Serial: XXXXXXX<br />
-- eth_addr0: XX:XX:XX:XX:XX:XX<br />
-- eth_addr1: XX:XX:XX:XX:XX:XX<br />
-- eth_addr2: XX:XX:XX:XX:XX:XX<br />
-- DT-Compat/MCU-Compat: 0000 0002<br />
-- CRC: cbd79a61 (matches)<br />
-- Reading back <br />
-- PID/REV: e320 0002<br />
-- MCU_FLAGS[0]: 00000008<br />
-- MCU_FLAGS[1]: 00000000<br />
-- MCU_FLAGS[2]: 00000000<br />
-- MCU_FLAGS[3]: 00000000<br />
-- Serial: XXXXXXX<br />
-- eth_addr0: XX:XX:XX:XX:XX:XX<br />
-- eth_addr1: XX:XX:XX:XX:XX:XX<br />
-- eth_addr2: XX:XX:XX:XX:XX:XX<br />
-- DT-Compat/MCU-Compat: 0000 0002<br />
-- CRC: 448fb572 (matches)<br />
</pre><br />
<br />
* Enable autoboot on USRP E320 (sets least significant bit to 1), regardless of whether currently enabled or disabled. For example when changing from autoboot disabled to enabled:<br />
<pre><br />
root@ni-e320-XXXXXXX:~# eeprom-set-flags $((0x<MCU_FLAGS[0]> | 0x1))<br />
</pre><br />
Thus, for the value noted above:<br />
<pre><br />
root@ni-e320-XXXXXXX:~# eeprom-set-flags $((0x00000008 | 0x1))<br />
-- PID/REV: e320 0002<br />
-- MCU_FLAGS[0]: 00000008<br />
-- MCU_FLAGS[1]: 00000000<br />
-- MCU_FLAGS[2]: 00000000<br />
-- MCU_FLAGS[3]: 00000000<br />
-- Serial: XXXXXXX<br />
-- eth_addr0: XX:XX:XX:XX:XX:XX<br />
-- eth_addr1: XX:XX:XX:XX:XX:XX<br />
-- eth_addr2: XX:XX:XX:XX:XX:XX<br />
-- DT-Compat/MCU-Compat: 0000 0002<br />
-- CRC: cbd79a61 (matches)<br />
-- Reading back <br />
-- PID/REV: e320 0002<br />
-- MCU_FLAGS[0]: 00000009<br />
-- MCU_FLAGS[1]: 00000000<br />
-- MCU_FLAGS[2]: 00000000<br />
-- MCU_FLAGS[3]: 00000000<br />
-- Serial: XXXXXXX<br />
-- eth_addr0: XX:XX:XX:XX:XX:XX<br />
-- eth_addr1: XX:XX:XX:XX:XX:XX<br />
-- eth_addr2: XX:XX:XX:XX:XX:XX<br />
-- DT-Compat/MCU-Compat: 0000 0002<br />
-- CRC: 448fb572 (matches)<br />
</pre><br />
<br />
If setting this flag ''does not'' allow autoboot control on the USRP E320, then the device boot firmware needs to be updated. This update is accomplished via the following instructions.<br />
<br />
On the USRP E320 via ssh or serial terminal, [https://files.ettus.com/binaries/misc/upgrade_mcu_neon_v1.1.7358-a190641-musl-glibc-rev3-6.tar.gz download the update MCU firmware] and extract it:<br />
<pre><br />
root@ni-e320-XXXXXXX:~# curl https://files.ettus.com/binaries/misc/upgrade_mcu_neon_v1.1.7358-a190641-musl-glibc-rev3-6.tar.gz | tar zxf -<br />
</pre><br />
This will create a directory <code>upgrade_mcu_neon_v1.1.7358-a190641-musl-glibc-rev3-6</code>. Go into this directory and run the firmware flash script:<br />
<pre><br />
root@ni-e320-XXXXXXX:~# cd upgrade_mcu_neon_v1.1.7358-a190641-musl-glibc-rev3-6<br />
root@ni-e320-XXXXXXX:~/upgrade_mcu_neon_v1.1.7358-a190641-musl-glibc-rev3-6# ./flash-firmware.sh<br />
This script updates the microcontroller firmware (RO part). The change is<br />
persistent across power cycles. Incorrect updates can only fixed be a manual<br />
process which requires opening the enclosure.<br />
<br />
Updating the microcontroller firmware (RO part) is only required if the Ettus<br />
Research support told you to do so.<br />
<br />
Press "y" to continue<br />
</pre><br />
At the prompt, press the <code>y</code> key to continue. Pressing any other key aborts the procedure:<br />
<pre><br />
Press "y" to continue n<br />
<br />
aborting<br />
root@ni-e320-317F9BF:~/upgrade_mcu_neon_v1.1.7358-a190641-musl-glibc-rev3-6# <br />
</pre><br />
Pressing the <code>y</code> key:<br />
<pre><br />
Press "y" to continue y<br />
<br />
This script will flash ec-neon-rev3.RO.flat to the device<br />
old RO version: neon_vX.X.XXXX-XXXXXXX<br />
new RO version: neon_v1.1.7358-a190641<br />
<br />
Press "y" to continue<br />
</pre><br />
At the prompt, press the <code>y</code> key ''again'' to continue. Pressing any other key aborts the procedure as before.<br />
<pre><br />
Press "y" to continue y<br />
<br />
./ectool --interface=dev reboot_ec RW<br />
./ectool --interface=dev flashread 0x0 65536 ec-neon-rev3.RO.flat.old<br />
Reading 65536 bytes at offset 0...<br />
done.<br />
./ectool --interface=dev flasherase 0x0 65536<br />
Erasing 65536 bytes at offset 0...<br />
done.<br />
./ectool --interface=dev flashwrite 0x0 ec-neon-rev3.RO.flat<br />
Reading 49592 bytes from ec-neon-rev3.RO.flat...<br />
Writing to offset 0...<br />
Write size 112...<br />
done.<br />
<br />
copying new firmware files<br />
'ec-neon-rev3.bin' -> '/lib/firmware/ni/ec-neon-rev3.bin'<br />
'ec-neon-rev3.RW.bin' -> '/lib/firmware/ni/ec-neon-rev3.RW.bin'<br />
root@ni-e320-317F9BF:~/upgrade_mcu_neon_v1.1.7358-a190641-musl-glibc-rev3-6# <br />
</pre><br />
<br />
Once the script is done, reboot the USRP (e.g., <code>shutdown -r now</code>), and when it comes up the autoboot flag should now work as desired. If these instructions ''do not'' work, then email [mailto:support@ettus.com support@ettus.com] and ask for alternative instructions on how to update the USRP E320 RO and RW boot firmware such that this EEPROM flag setting is honored.<br />
<br />
===Default Password===<br />
The default user is <code>root</code> and the password is empty (no password).<br />
<br />
It is recommended to update the <code>root</code> password, which can be done with the command <code>passwd</code>:<br />
<br />
Example Output:<br />
<br />
root@ni-e320-serial:~# passwd<br />
Changing password for root<br />
New password:<br />
Re-enter new password:<br />
passwd: password changed.<br />
<br />
==Known Issues==<br />
===Problematic NICs===<br />
In some streaming modes, the Intel I219-LM NIC can produce flow control and sequence errors. It is recommended to use a USB3 to 1 Gb Ethernet Adapter for hosts which have an I219-LM NIC.<br />
<br />
==Technical Support and Community Knowledge Base==<br />
Technical support for USRP hardware is available through email only. If the product arrived in a nonfunctional state or you require technical assistance, please contact [mailto:support@ettus.com support@ettus.com]. Please allow 24 to 48 hours for response by email, depending on holidays and weekends, although we are often able to reply more quickly than that.<br />
<br />
We also recommend that you subscribe to the community mailing lists. The mailing lists have a responsive and knowledgeable community of hundreds of developers and technical users who are located around the world. When you join the community, you will be connected to this group of people who can help you learn about SDR and respond to your technical and specific questions. Often your question can be answered quickly on the mailing lists. Each mailing list also provides an archive of all past conversations and discussions going back many years. Your question or problem may have already been addressed before, and a relevant or helpful solution may already exist in the archive.<br />
<br />
Discussions involving the USRP hardware and the UHD software itself are best addressed through the '''usrp-users''' mailing list at [http://usrp-users.ettus.com http://usrp-users.ettus.com].<br />
<br />
Discussions involving the use of [http://gnuradio.org/ GNU Radio] with USRP hardware and UHD software are best addressed through the '''discuss-gnuradio''' mailing list at [https://lists.gnu.org/mailman/listinfo/discussgnuradio https://lists.gnu.org/mailman/listinfo/discussgnuradio].<br />
<br />
Discussions involving the use of [http://openbts.org/ OpenBTS®] with USRP hardware and UHD software are best addressed through the '''openbts-discuss''' mailing list at [https://lists.sourceforge.net/lists/listinfo/openbtsdiscuss https://lists.sourceforge.net/lists/listinfo/openbtsdiscuss].<br />
<br />
The support page on our website is located at [https://www.ettus.com/support https://www.ettus.com/support]. The Knowledge Base is located at [https://kb.ettus.com https://kb.ettus.com].<br />
<br />
==Legal Considerations==<br />
Every country has laws governing the transmission and reception of radio signals. Users are solely responsible for insuring they use their USRP system in compliance with all applicable laws and regulations. Before attempting to transmit and/or receive on any frequency, we recommend that you determine what licenses may be required and what restrictions may apply.<br />
<br />
*NOTE: This USRP product is a piece of test equipment.<br />
<br />
==Sales and Ordering Support==<br />
If you have any non-technical questions related to your order, then please contact us by email at [mailto:orders@ettus.com orders@ettus.com], or by phone at +14086106399 (Monday-Friday, 8 AM - 5 PM, Pacific Time). Please be sure to include your order number and the serial number of your USRP.<br />
<br />
==Terms and Conditions of Sale==<br />
Terms and conditions of sale can be accessed online at the following link: http://www.ettus.com/legal/terms-and-conditions-of-sale<br />
<br />
[[Category:Getting Started Guides]]<br />
[[Category:E320]]</div>JonathonPendlumhttps://kb.ettus.com/index.php?title=E320_Getting_Started_Guide&diff=5883E320 Getting Started Guide2023-09-25T20:31:07Z<p>JonathonPendlum: Fix commands for mender update</p>
<hr />
<div>==Kit Contents==<br />
<br />
===E320 Board-only===<br />
{|<br />
|style="vertical-align:top"|<br />
* USRP E320<br />
* Power connector (assembly required) <br />
* 4 M3x0.5, M3x5 Standoffs <br />
* 1 Gb Ethernet Cat-5e Cable (3m)<br />
* USB-A to Micro USB-B Cable (1m)<br />
* 1 Gb SFP+ to RJ45 Adapter<br />
* Getting Started Guide<br />
* Ettus Research Sticker<br />
|[[File:e320 board only.jpg|500px|center]]<br />
|}<br />
<br />
===E320 Full Enclosure===<br />
{|<br />
|style="vertical-align:top"|<br />
* USRP E320 in enclosure <br />
* DC Power Supply (12V, 7A)<br />
* 1 Gb Ethernet Cat-5e Cable (3m)<br />
* USB-A to Micro USB-B Cable (1m)<br />
* 1 Gb SFP+ to RJ45 Adapter<br />
* Getting Started Guide<br />
* Ettus Research Sticker<br />
* T8 Torx Wrench<br />
|[[File:e320 enclosure kit.jpg|500px|center]]<br />
|}<br />
<br />
==Verify the Contents of Your Kit==<br />
Ensure that your kit contains all the items listed above. If any items are missing, please contact sales@ettus.com immediately.<br />
<br />
==You Will Need==<br />
<br />
* For Network Mode: A host computer with an 1 or 10 Gb Ethernet interface. If operating with the 10 Gb Ethernet interface, the "XG" FPGA image must be loaded before the SFP+ port will operate at 10 Gb speeds. Optionally a second 1 Gb Ethernet interface can be used to connect to the onboard ARM CPU for remote management. <br />
<br />
* For Embedded Mode: A host computer is only required for initial device configuration, remote control and management, or data visualization. The host computer can connect to the RJ45 1 Gb port or Serial Console port to remotely access the Open Embedded Linux operating system running on the ARM CPU. Once configured, the USRP E320 can operate as a stand-alone device without a connection to a remote host computer. <br />
<br />
* For Board-only Version: A third-party 10-14V/3A power supply, which requires assembly with the power connect components included in the kit. An assembled power supply can be purchased here: https://www.ettus.com/product/details/12V-PWR<br />
<br />
==Proper Care and Handling==<br />
All Ettus Research products are individually tested before shipment. The USRP is guaranteed to be functional at the time it is received by the customer. Improper use or handling of the USRP can cause the device to become non-functional. Take the following precautions to prevent damage to the unit.<br />
<br />
* Never allow anything especially metal objects to touch the board while it is powered on. <br />
* Always properly terminate the transmit port with an antenna or 50Ω load.<br />
* Always handle the board with proper anti-static methods.<br />
* Never allow the board to directly or indirectly come into contact with any voltage spikes.<br />
* Never allow any water or condensing moisture to come into contact with the device.<br />
* Always use caution with FPGA, firmware, or software modifications.<br />
* Never touch the circuit board or heatsink while the device is powered on. <br />
* All connections should be made/removed while is device is powered off. <br />
<br />
{|<br />
|style="padding-left:10px; padding-right:10px; padding-bottom:10px;" |[[File:Caution.png|24px|center]]<br />
|style="padding-left:10px; padding-right:10px; padding-bottom:10px;" |Never apply more than -15 dBm of power into any RF input.<br />
|-<br />
|style="padding-left:10px; padding-right:10px; padding-bottom:10px;" |[[File:Caution.png|24px|center]]<br />
|style="padding-left:10px; padding-right:10px; padding-bottom:10px;" |Always use at least 30dB attenuation if operating in loopback configuration<br />
|-<br />
|}<br />
<br />
==Install and Setup the Software Tools on Your Host Computer==<br />
<br />
To use your Universal Software Radio Peripheral (USRP™), you must have software tools correctly installed and configured on your host computer. Step-by-step guides for these software tools are found in the Application Notes for Building and Installing the USRP Open-Source Toolchain (UHD and GNU Radio) on [[Building and Installing the USRP Open-Source Toolchain (UHD and GNU Radio) on Linux|Linux]], [[Building and Installing the USRP Open-Source Toolchain (UHD and GNU Radio) on OS X|OS X]] and [[Building and Installing the USRP Open Source Toolchain (UHD and GNU Radio) on Windows|Windows]].<br />
<br />
The USRP E320 requires UHD version 3.13.0.2 or later. It is strongly recommended to use the latest stable release of UHD on both the host computer and the USRP via the filesystem on the SD card. If this release fails to work in some way, then try the maintenance branch of the latest stable version. If you are operating the device in Network Mode, the version of UHD running on the host machine and E320 USRP must match to within the same maintenance release and branch. See the [https://github.com/ettusresearch/uhd UHD GitHub repository] for the latest release and maintenance branch.<br />
<br />
==Connecting the Device==<br />
===Interfaces Overview===<br />
Listed below are the interfaces to connect to the USRP E320. Each interface has specific functionality, limitations and purpose.<br />
<br />
'''Serial Console'''<br />
<br />
The Serial Console provides a low-level interface to the ARM CPU and STM32 microcontroller, typically used for debugging. The serial console can also be used as a JTAG connection to the FPGA.<br />
<br />
'''1 Gb RJ45 Connection'''<br />
<br />
The 1 Gb RJ45 Connection interfaces with the on-board ARM CPU. When operated in "Network mode", this interface can optionally be used for remote control and management traffic. Regardless of the operation mode (Host vs Embedded) this interface can be used to connect to the ARM via SSH. By default, the 1 Gb RJ45 connection is configured to use a DHCP assigned IP address.<br />
<br />
'''SFP+ Connection'''<br />
<br />
The SFP+ Connection supports multiple interfaces for streaming high-speed, low-latency data, depending upon which FPGA image is loaded.<br />
<br />
===Setting up a Serial Console Connection===<br />
It is possible to gain shell access to the device using a serial terminal emulator via the Serial Console port. Most Linux, OS X, or other Unix based operating systems have a utility called <code>screen</code> which can be used for this purpose. <br />
<br />
If you do not have <code>screen</code> installed, it can be installed via your distribution's package manager. For Ubuntu/Debian based operating systems it can be installed with the package manager <code>apt</code> such as:<br />
<br />
sudo apt install screen<br />
<br />
The default Baud Rate for the Serial Console is: <code>115200</code><br />
<br />
The exact device node you should attach to depends on your operating system's driver and other USB devices that might already be connected. Modern Linux systems offer alternatives to simply trying device nodes; instead, the OS might have a directory of symlinks under <code>/dev/serial/by-id</code>:<br />
<br />
$ ls /dev/serial/by-id<br />
usb-FTDI_Dual_RS232-HS-if00-port0<br />
usb-FTDI_Dual_RS232-HS-if01-port0<br />
usb-Silicon_Labs_CP2105_Dual_USB_to_UART_Bridge_Controller_007F6A69-if00-port0<br />
usb-Silicon_Labs_CP2105_Dual_USB_to_UART_Bridge_Controller_007F6A69-if01-port0<br />
<br />
NOTE: Exact names depend on the host operating system version and may differ.<br />
<br />
Every E320 series device connected to USB will by default show up as four different devices. The devices labeled <code>"USB_to_UART_Bridge_Controller"</code> are the devices that offer a serial prompt. The first (with the <code>if00</code> suffix) connects to the <code>STM32 Microcontroller</code>, whereas the second connects to the <code>ARM CPU</code>.<br />
<br />
If you have multiple E320 Serial Consoles connected to a single host, you may have to empirically test nodes.<br />
<br />
Connecting to the ARM CPU can be performed with the command:<br />
<br />
$ sudo screen /dev/serial/by-id/usb-Silicon_Labs_CP2105_Dual_USB_to_UART_Bridge_Controller_007F6A69-if01-port0 115200<br />
<br />
Upon starting the USRP E320, boot messages will appear and rapidly update. Once the boot process successfully completes, a login prompt like the following should appear:<br />
<br />
Alchemy 2018.04 ni-e320-serial ttyPS0<br />
ni-e320-serial login:<br />
<br />
Enter the username: <code>root</code><br />
<br />
By default, the <code>root</code> user's password is left blank. Press the <code>Enter</code> key when prompted for a password.<br />
<br />
You should now be presented with a shell prompt similar to the following:<br />
<br />
root@ni-e320-<motherboard serial #>:~#<br />
<br />
Using the default configuration, the serial console will show all kernel log messages (which are not available when using SSH) and give access to the boot loader (U-boot prompt). This can be used to debug kernel or boot-loader issues more efficiently than when logged in via SSH.<br />
<br />
===Connecting to the microcontroller===<br />
<br />
Using the Serial Console interface, it is possible to connect to the STM32 microcontroller with the command below. The STM32 controls the power sequencing and several other low-level device operations.<br />
<br />
$ sudo screen /dev/serial/by-id/usb-Silicon_Labs_CP2105_Dual_USB_to_UART_Bridge_Controller_007F6A69-if00-port0 115200<br />
<br />
The STM32 interface provides a very simple prompt. The command <code>help</code> will list all available commands. A direct connection to the microcontroller can be used to hard-reset the device without physically accessing it (i.e., emulating a power button press) and other low-level diagnostics.<br />
<br />
===Connecting to the ARM via SSH===<br />
By default, the RJ45 1 Gb management interface is configured to be assigned a DHCP IP address.<br />
<br />
If you have access to a network which provides a DHCP server (such as a common router's LAN), attach the RJ45 1 Gb port to this network. Details vary by vendor, however, most router management interfaces will provide a list of attached devices to the LAN including their IP address.<br />
<br />
Without access to a router management interface, you can identify the IP address by connecting to the ARM CPU via Serial Console as detailed in the section above and running the command <code>ip a</code>:<br />
<br />
Example Output:<br />
<br />
<pre><br />
# ip a<br />
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue qlen 1000<br />
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00<br />
inet 127.0.0.1/8 scope host lo<br />
valid_lft forever preferred_lft forever<br />
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000<br />
link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff<br />
inet 192.168.1.151/24 brd 192.168.1.255 scope global dynamic eth0<br />
valid_lft 42865sec preferred_lft 42865sec<br />
3: sfp0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8000 qdisc pfifo_fast qlen 1000<br />
link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff<br />
inet 192.168.10.2/24 brd 192.168.10.255 scope global sfp0<br />
valid_lft forever preferred_lft forever<br />
</pre><br />
<br />
If you do not have access to a network with a DHCP server, you can create one using the Linux utility <code>dnsmasq</code>:<br />
<br />
$ sudo dnsmasq -i <ETHERNET_ADAPTER_NAME> --dhcp-range=192.168.1.50,192.168.1.100 --except-interface=lo --bind-dynamic --no-daemon<br />
<br />
NOTE: Modify the value <code><ETHERNET_ADAPTER_NAME></code> to match the interface you would like to create a DHCP server on.<br />
<br />
After the device has obtained an IP address, you can remotely log into it from a Linux or macOS systems with SSH, as shown below:<br />
<br />
$ ssh root@192.168.1.51<br />
<br />
NOTE: The IP address may vary depending on your network setup.<br />
<br />
NOTE: The <code>root</code> password is empty/blank.<br />
<br />
On Microsoft Windows, the SSH connection can be established using the third-party program, such as PuTTY.<br />
<br />
After logging in, you should be presented with a shell prompt like the following:<br />
<br />
root@ni-e320-<motherboard serial #>:~#<br />
<br />
==Updating the Linux File System==<br />
Before operating the device, it is strongly recommended to update to the latest version of the Embedded Linux file system. If you are operating the device in Network Mode, the version of UHD running on the host machine and E320 USRP must match. <br />
<br />
There is two ways to update the file system for the E320 USRP: <br />
<br />
1. Mender<br />
<br />
2. Physically remove microSD card from device and write a new file system to the microSD card. <br />
<br />
===File System Partition Layout===<br />
The SD Card is divided into four partitions. There are two root file system partitions, a "boot" partition and a "data" partition. <br />
<br />
Any data you would like to preserve through Mender updates should be saved to the "data" partition, which is mounted at <code>/data</code>.<br />
<br />
===Updating the file system with Mender===<br />
Mender is third-party software that enables remote updating of the root file system without physically accessing the device (see also the Mender website https://mender.io). Mender can be executed locally on the device, or a Mender server can be set up which can be used to remotely update an arbitrary number of USRP devices. Users can host their own local Mender server, or use servers hosted by Mender as a paid service; contact Mender for more information. <br />
<br />
====Mender Update Process====<br />
When updating the file system using Mender, the tool will overwrite the root file system partition that is not currently mounted. Any data stored in the root partitions will be permanently lost with a Mender update.<br />
<br />
After updating a partition with Mender, it will reboot into the newly updated partition. Only if the update is confirmed by the user, the update will be made permanent. This means that if an update fails, the device will be always able to reboot into the partition from which the update was originally launched, which presumably is in a working state. Another update can be launched now to correct the previous, failed update, until it works.<br />
<br />
To obtain the file system Mender image (these are files with a <code>.mender</code> suffix), run the following command on the host computer with Internet access:<br />
<br />
$ sudo uhd_images_downloader -t mender -t e320 --yes<br />
<br />
Example Output:<br />
[INFO] Using base URL: https://files.ettus.com/binaries/cache/<br />
[INFO] Images destination: /usr/local/share/uhd/images<br />
[INFO] No inventory file found at /usr/local/share/uhd/images/inventory.json. Creating an empty one.<br />
301483 kB / 301483 kB (100%) e3xx_e320_mender_default-v4.4.0.0.zip<br />
[INFO] Images download complete.<br />
<br />
NOTE: In the output of the command, the folder destination where the images are saved is printed out.<br />
<br />
Next, you will need to copy this Mender file system image to the USRP E320. This can be done with the Linux utility <code>scp</code>.<br />
<br />
$ scp /usr/local/share/uhd/images/usrp_e320_fs.mender root@192.168.1.51:~/. <br />
<br />
Note: The path and IP may different for your configuration, the command above assumes you're using the default installation path of <code>/usr/local</code> and that the E320's IP is <code>192.168.1.51</code>.<br />
<br />
After copying the Mender file system image to the E320, connect to the E320 using either the Serial Console, or via SSH to gain shell access.<br />
<br />
On the E320, run <code>mender install /path/to/latest.mender</code> to update the file system:<br />
<br />
root@ni-e320-serial:~# mender install /home/root/usrp_e320_fs.mender<br />
<br />
Example Output:<br />
<br />
<pre><br />
root@ni-e320-316E375:~# mender -rootfs /home/root/usrp_e320_fs.mender <br />
INFO[0000] Start updating from local image file: [/home/root/usrp_e320_fs.mender] module=rootfs<br />
Installing update from the artifact of size 399640064<br />
INFO[0000] opening device /dev/mmcblk0p3 for writing module=block_device<br />
INFO[0000] partition /dev/mmcblk0p3 size: 2046820352 module=block_device<br />
................................ 0% 1024 KiB<br />
................................ 0% 2048 KiB<br />
................................ 0% 3072 KiB<br />
[truncated for readability]<br />
................................ 99% 389120 KiB<br />
................................ 99% 390144 KiB<br />
................................ 100% 390273 KiB<br />
INFO[0740] wrote 2046820352/2046820352 bytes of update to device /dev/mmcblk0p3 module=device<br />
INFO[0744] Enabling partition with new image installed to be a boot candidate: 3 module=device<br />
<br />
</pre><br />
<br />
The artifact can also be stored on a remote server:<br />
$ mender install <http://server.name/path/to/latest.mender><br />
<br />
This procedure will take a few minutes to complete. After mender has logged a successful update, reboot the device:<br />
$ reboot<br />
<br />
If the reboot worked, and the device seems functional, commit the changes so that the boot loader knows to permanently boot into this partition:<br />
$ mender -commit<br />
<br />
To identify the currently installed Mender artifact from the command line, the following file can be queried on the E320:<br />
$ cat /etc/mender/artifact_info<br />
<br />
If you are using a Mender server, the updates can be initiated from a web dashboard. From there, you can start the updates without having to log into the device, and you can update groups of USRPs with a few clicks in a web GUI. The dashboard can also be used to inspect the state of USRPs. This is a simple way to update groups of rack-mounted USRPs with custom file systems.<br />
<br />
For more information on updating the file-system, refer to the E3xx page in the Devices section of the UHD Manual at http://uhd.ettus.com.<br />
<br />
===Updating the files system by writing the disk image===<br />
The microSD card is accessible directly on the Board-only version of the E320 USRP. The E320 Full Enclosure version must be opened with the included Torx wrench. <br />
<br />
NOTE: This method will overwrite all data saved on the microSD card, including any data saved to the <code>/data</code> partition.<br />
<br />
Please see the separate application note, [[Writing the USRP File System Disk Image to a SD Card]], for step-by-step instructions on writing the file system image to the microSD card.<br />
<br />
==Updating the Network Configurations==<br />
The USRP E320 systemd network configuration files are located either at: <code>/etc/systemd/network/</code><br />
<br />
# ls /etc/systemd/network/<br />
eth0.network sfp0.network <br />
<br />
or for newer versions of the file system: <code>/data/network/</code><br />
<br />
# ls /data/network/<br />
eth0.network int0.network sfp0.network<br />
<br />
For details on configuration please refer to the [https://www.freedesktop.org/software/systemd/man/systemd.network.html systemd-networkd manual pages].<br />
<br />
The factory settings are as follows:<br />
<pre><br />
eth0 (DHCP):<br />
<br />
[Match]<br />
Name=eth0<br />
<br />
[Network]<br />
DHCP=v4<br />
<br />
[DHCPv4]<br />
UseHostname=false<br />
<br />
sfp0 (static):<br />
<br />
[Match]<br />
Name=sfp0<br />
<br />
[Network]<br />
Address=192.168.10.2/24<br />
<br />
[Link]<br />
MTUBytes=8000<br />
</pre><br />
<br />
Additional notes on networking:<br />
<br />
* Care needs to be taken when editing these files on the device, since <code>vi</code> / <code>vim</code> sometimes generates undo files (e.g. <code>/data/network/sfp0.network~</code>), that <code>systemd-networkd</code> might accidentally pick up.<br />
* Temporarily setting the IP addresses or MTU sizes via <code>ifconfig</code> or other command line tools will only change the value until the next reboot or reload of the FPGA image.<br />
* If the MTU of the device and host computers differ, streaming issues can occur.<br />
* Streaming via SFP0 at 1 Gb rates requires a MTU of <code>1500</code><br />
* Streaming via SFP0 at 10 Gb rates requires a MTU of <code>8000</code><br />
<br />
For addition details on network configuration here: https://files.ettus.com/manual/page_usrp_e320.html#e320_network_configuration<br />
<br />
==Updating the FPGA Image==<br />
<br />
===Network mode FPGA Image Update===<br />
The FPGA image should match the version of UHD installed on the host computer when operated in Network mode. <br />
<br />
Network mode FPGA image updates must be made through the RJ45 management interface.<br />
<br />
To obtain all the FPGA images for your installed version of UHD, run the following command on the host computer with internet access:<br />
<br />
$ sudo uhd_images_downloader -t e320 -t fpga<br />
<br />
Example Output:<br />
<br />
$ uhd_images_downloader -t e320 -t fpga<br />
[INFO] Images destination: /usr/local/share/uhd/images<br />
[INFO] No inventory file found at /usr/local/share/uhd/images/inventory.json. Creating an empty one.<br />
05920 kB / 05920 kB (100%) e3xx_e320_fpga_default-g494ae8bb.zip<br />
[INFO] Images download complete.<br />
<br />
There is two versions of the E320 FPGA images shipped with UHD:<br />
<br />
- <code>1G</code> for 1 Gb rates on the SFP+ port (default image)<br />
<br />
- <code>XG</code> for 10 Gb rates on the SFP+ port<br />
<br />
In this example, we load the <code>XG</code> variant of the FPGA image.<br />
<br />
$ uhd_image_loader --args "type=e3xx,mgmt_addr=<E320_RJ45_IP_ADDR>,fpga=XG"<br />
<br />
Example Output:<br />
<br />
$ uhd_image_loader --args "mgmt_addr=192.168.1.51,type=e3xx,fpga=XG"<br />
[INFO] [UHD] linux; GNU C++ version 5.4.0 20160609; Boost_105800; UHD_3.13.1.0-1-gd3b7e90a<br />
[INFO] [MPMD] Initializing 1 device(s) in parallel with args: mgmt_addr=192.168.1.51,type=e3xx,product=e320,serial=316E375,claimed=False,skip_init=1<br />
[INFO] [MPMD] Claimed device without full initialization.<br />
[INFO] [MPMD IMAGE LOADER] Starting update. This may take a while.<br />
[INFO] [MPM.PeriphManager] Updating component `fpga'<br />
[INFO] [MPM.PeriphManager] Updating component `dts'<br />
[INFO] [MPM.RPCServer] Resetting peripheral manager.<br />
[INFO] [MPM.PeriphManager] Device serial number: 316E375<br />
[INFO] [MPMD IMAGE LOADER] Update component function succeeded.<br />
[INFO] [MPM.PeriphManager] Found 1 daughterboard(s).<br />
<br />
The FPGA is immediately updated, and this FPGA image will continue to be used. The device does not need to be power cycled to use the new image. <br />
<br />
To load a different FPGA image (i.e. <code>1G</code>), modify the device argument <code>fpga=</code> to a value of <code>fpga=1G</code>.<br />
<br />
To specify the path to a custom FPGA image, use the <code>--fpga-path</code> argument.<br />
<br />
$ uhd_image_loader --args "type=e3xx,mgmt_addr=<E320_RJ45_IP_ADDR>" --fpga-path=/path/to/custom/fpga.bit<br />
<br />
<br />
{|<br />
|style="padding-left:10px; padding-right:10px; padding-bottom:10px;" |[[File:Caution.png|24px|center]]<br />
|style="padding-left:10px; padding-right:10px; padding-bottom:10px;" |The Verilog code for the FPGA in the USRP E320 is open-source, and users are free to modify and customize it for their needs. However, certain modifications may result in either bricking the device, or even in physical damage to the unit. Please note that modifications to the FPGA are made at the risk of the user, and may not be covered by the warranty of the device.<br />
|-<br />
|}<br />
<br />
<br />
===Embedded Mode FPGA Image Update===<br />
<br />
It is possible to update the FPGA image when operated in Embedded mode. Connect to the ARM CPU [[#Setting_up_a_Serial_Console_Connection|via Serial Console]] or [[E320_Getting_Started_Guide#Connecting_to_the_ARM_via_SSH| via SSH]]. It is generally recommend to use SSH over the RJ45 interface for remote management. <br />
<br />
Run the command <code>uhd_images_downloader</code> to download the FPGA images to the device's file system:<br />
<br />
NOTE: The 1 Gb RJ45 management interface will require Internet access for this next step.<br />
<br />
<pre><br />
root@ni-e320-serial:~# python3 /usr/bin/uhd_images_downloader -t e320 -t fpga<br />
[INFO] Images destination: /usr/share/uhd/images<br />
[INFO] No inventory file found at /usr/share/uhd/images/inventory.json. Creating an empty one.<br />
05920 kB / 05920 kB (100%) e3xx_e320_fpga_default-g494ae8bb.zip<br />
[INFO] Images download complete.<br />
</pre><br />
<br />
NOTE: The default UHD FPGA Images destination within the E320's file-system is <code>/usr/share/uhd/images</code>. The default UHD FPGA Images destination on a typical host installation is <code>/usr/local/share/uhd/images</code>.<br />
<br />
Updating the FPGA image from the ARM CPU is the same as detailed above for a Network mode update:<br />
<br />
<pre><br />
root@ni-e320-serial:~# uhd_image_loader --args "type=e3xx,fpga=1G"<br />
[INFO] [UHD] linux; GNU C++ version 7.3.0; Boost_106600; UHD_3.13.1.0-0-unknown<br />
[INFO] [MPMD] Initializing 1 device(s) in parallel with args: mgmt_addr=127.0.0.1,type=e3xx,product=e320,serial=316E375,claimed=False,skip_init=1<br />
[INFO] [MPM.PeriphManager.UDP] No CHDR interfaces found!<br />
[INFO] [MPM.PeriphManager.UDP] No CHDR interfaces found!<br />
[INFO] [MPMD] Claimed device without full initialization.<br />
[INFO] [MPMD IMAGE LOADER] Starting update. This may take a while.<br />
[INFO] [MPM.PeriphManager] Updating component `fpga'<br />
[INFO] [MPM.PeriphManager] Updating component `dts'<br />
[INFO] [MPM.RPCServer] Resetting peripheral manager.<br />
[INFO] [MPM.PeriphManager] Device serial number: 316E375<br />
[INFO] [MPMD IMAGE LOADER] Update component function succeeded.<br />
[INFO] [MPM.PeriphManager] Found 1 daughterboard(s).<br />
<br />
</pre><br />
<br />
For more information on updating the FPGA image, refer to the UHD Manual at http://uhd.ettus.com.<br />
<br />
==Setting Up a Streaming Connection==<br />
The device supports multiple high-speed, low-latency interfaces on the SFP+ port for streaming samples to the host computer.<br />
<br />
===1 Gb Streaming via SFP+ Port ===<br />
Complete the steps below to set up a streaming connection over the 1 Gb Ethernet interface on the <code>SFP+ Port</code>.<br />
<br />
NOTE: The <code>1G</code> FPGA image must be loaded for the <code>SFP+ Port</code> to operate at 1 Gb speeds. If the <code>XG</code> image is loaded, the port will be unresponsive at 1Gb speeds.<br />
<br />
1. Configure your Host's 1 Gb Ethernet interface as shown below. This interface should be separate from the 1 Gb NIC/network which is connected to the 1 Gb RJ45 management interface. <br />
<br />
IP Address: 192.168.10.1<br />
Subnet Mask: 255.255.255.0<br />
Gateway: 0.0.0.0<br />
MTU: 1500<br />
<br />
NOTE: When operating the <code>SFP+ Port</code> at 1 Gb speeds, it is important to set a MTU of <code>1500</code> and not a value of <code>automatic</code>. Mismatched MTU values on either the Host or E320 may cause flow control errors. Your computer may need to be restarted for the MTU value to take effect.<br />
<br />
2. Insert the RJ45-to-SFP+ adapter into the <code>SFP+ Port</code>.<br />
<br />
3. Connect the SFP+ adapter on the device to an Ethernet port on the host computer using a standard Ethernet cable.<br />
<br />
The Green LED above the <code>SFP+ Port</code> should illuminate.<br />
<br />
4. To test the connection, <code>ping</code> the device at address <code>192.168.10.2</code> from the host, as shown below:<br />
<br />
$ ping 192.168.10.2<br />
PING 192.168.10.2 (192.168.10.2) 56(84) bytes of data.<br />
64 bytes from 192.168.10.2: icmp_seq=1 ttl=64 time=1.06 ms<br />
^C<br />
--- 192.168.10.2 ping statistics ---<br />
1 packets transmitted, 1 received, 0% packet loss, time 0ms<br />
rtt min/avg/max/mdev = 1.065/1.065/1.065/0.000 ms<br />
<br />
Press <code>CTRL+C</code> to stop the ping program.<br />
<br />
5. Verify your MTU is set correctly for 1 Gb speeds on the E320. See the section [[E320_Getting_Started_Guide#Updating_the_Network_Configurations|Updating the Network Configurations]] for additional details.<br />
<br />
Proceed to the next section [[E320_Getting_Started_Guide#Verifying_Device_Operation|Verifying Device Operation]].<br />
<br />
===10 Gb Streaming via SFP+ Port===<br />
Load the <code>XG</code> FPGA image for 10 Gb streaming as detailed in the section [[E320_Getting_Started_Guide#Updating_the_FPGA_Image|Updating the FPGA Image]]. You will need to use a 10 GigE cable that can be plugged in directly to the SFP+ connector on the board. <br />
<br />
NOTE: The <code>XG</code> FPGA image must be loaded for the <code>SFP+ Port</code> to operate at 10 Gb speeds. If the <code>1G</code> image is loaded, the port will be unresponsive at 10 Gb speeds. Mismatched MTU values on either the Host or E320 may cause flow control errors.<br />
<br />
1. Configure your Host's 10 Gb Ethernet interface as shown below. <br />
<br />
IP Address: 192.168.10.1<br />
Subnet Mask: 255.255.255.0<br />
Gateway: 0.0.0.0<br />
MTU: 8000<br />
<br />
NOTE: When operating the <code>SFP+ Port</code> at 10 Gb speeds, it is important to set a MTU of <code>8000</code> and not a value of <code>automatic</code>. Mismatched MTU values on either the Host or E320 may cause flow control errors. Your computer may need to be restarted for the MTU value to take effect.<br />
<br />
2. Connect the SFP+ port on the device to an Ethernet port on the host computer using a 10 Gb SFP+ copper or fiber cable.<br />
<br />
The Green LED above the <code>SFP+ Port</code> should illuminate.<br />
<br />
4. To test the connection, <code>ping</code> the device at address <code>192.168.10.2</code> from the host, as shown below:<br />
<br />
$ ping 192.168.10.2<br />
PING 192.168.10.2 (192.168.10.2) 56(84) bytes of data.<br />
64 bytes from 192.168.10.2: icmp_seq=1 ttl=64 time=1.06 ms<br />
^C<br />
--- 192.168.10.2 ping statistics ---<br />
1 packets transmitted, 1 received, 0% packet loss, time 0ms<br />
rtt min/avg/max/mdev = 1.065/1.065/1.065/0.000 ms<br />
<br />
Press <code>CTRL+C</code> to stop the ping program.<br />
<br />
5. Verify your MTU is set correctly for 10 Gb speeds on the E320. See the section [[E320_Getting_Started_Guide#Updating_the_Network_Configurations|Updating the Network Configurations]] for additional details.<br />
<br />
Proceed to the next section [[E320_Getting_Started_Guide#Verifying_Device_Operation|Verifying Device Operation]].<br />
<br />
==Verifying Device Operation==<br />
Once you have successfully setup a management interface and streaming interface, you can now verify the devices operation using the include UHD utilities.<br />
<br />
===Subdevice Specification Mapping===<br />
The USRP E320 contains 2 channels, each represented on the front panel as <code>RF A</code> and <code>RF B</code>. Below is the <code>subdev</code> mapping of RF Ports.<br />
<br />
'''E320'''<br />
* RF A = A:0<br />
* RF B = A:1<br />
<br />
Additional details of UHD Subdevice Specifications can be found here in the UHD Manual: http://files.ettus.com/manual/page_configuration.html#config_subdev<br />
<br />
===Supported Sample Rates===<br />
<br />
The USRP E320 supports master clock rate from 200 kHz to 61.44 MHz and can be changed by adding <code>master_clock_rate=<rate></code> to the default UHD args. The default master clock rate is 16 MHz. <br />
<br />
Sample rates as delivered to/from the host computer for USRP devices are constrained to follow several important rules.<br />
<br />
It is important to understand that strictly-integer decimation and interpolation are used within USRP hardware to meet the requested sample rate requirements of the application at hand. That means that the desired sample rate must meet the requirement that master-clock-rate/desired-sample-rate be an integer ratio. Further, it is strongly desirable for that ratio to be even. This ratio is the decimation (down-conversion) or interpolation (up-conversion) factor. The decimation or interpolation factor may be between 1 and 1024. There are further constraints on the decimation or interpolation factor. If the decimation or interpolation factor exceeds 128, then it must be evenly divisible by 2. If the decimation or interpolation factor exceeds 256, then it must be evenly divisible by 4.<br />
<br />
Additional information on Sample Rates can be found here in the UHD Manual: http://files.ettus.com/manual/page_general.html#general_sampleratenotes<br />
<br />
===Probe the USRP E320===<br />
The UHD utility <code>uhd_usrp_probe</code> provides detailed information of the USRP device.<br />
<br />
From your host computer, run the command <code>uhd_usrp_probe</code>:<br />
<br />
<pre><br />
$ uhd_usrp_probe --args "addr=192.168.10.2"<br />
[INFO] [UHD] linux; GNU C++ version 5.4.0 20160609; Boost_105800; UHD_3.13.1.0-1-gd3b7e90a<br />
[INFO] [MPMD] Initializing 1 device(s) in parallel with args: mgmt_addr=192.168.10.2,type=e3xx,product=e320,serial=316E375,claimed=False,addr=192.168.10.2<br />
[INFO] [MPM.PeriphManager] init() called with device args `product=e320,mgmt_addr=192.168.10.2'.<br />
[INFO] [0/DmaFIFO_0] Initializing block control (NOC ID: 0xF1F0D00000000000)<br />
[INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1343 MB/s)<br />
[INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1335 MB/s)<br />
[INFO] [0/Radio_0] Initializing block control (NOC ID: 0x12AD100000003320)<br />
[INFO] [0/DDC_0] Initializing block control (NOC ID: 0xDDC0000000000000)<br />
[INFO] [0/DUC_0] Initializing block control (NOC ID: 0xD0C0000000000002)<br />
[INFO] [0/Radio_0] Performing CODEC loopback test... <br />
[INFO] [0/Radio_0] CODEC loopback test passed<br />
[INFO] [0/Radio_0] Performing CODEC loopback test... <br />
[INFO] [0/Radio_0] CODEC loopback test passed<br />
_____________________________________________________<br />
/<br />
| Device: E300-Series Device<br />
| _____________________________________________________<br />
| /<br />
| | Mboard: ni-e320-316E375<br />
| | eeprom_version: 2<br />
| | mpm_version: 3.13.1.0-gd3b7e90a<br />
| | pid: 58144<br />
| | product: e320<br />
| | rev: 2<br />
| | rpc_connection: remote<br />
| | serial: 316E375<br />
| | type: e3xx<br />
| | MPM Version: 1.2<br />
| | FPGA Version: 3.0<br />
| | RFNoC capable: Yes<br />
| | <br />
| | Time sources: internal, external, gpsdo<br />
| | Clock sources: external, internal, gpsdo<br />
| | Sensors: gps_locked, temp_main_power, ref_locked, temp_rf_channelA, temp_fpga, gps_sky, temp_rf_channelB, fan, temp_internal, gps_tpv, gps_time<br />
| | _____________________________________________________<br />
| | /<br />
| | | RX Dboard: A<br />
| | | _____________________________________________________<br />
| | | /<br />
| | | | RX Frontend: 0<br />
| | | | Name: Neon<br />
| | | | Antennas: RX2, TX/RX<br />
| | | | Sensors: lo_locked, ad9361_temperature, rssi, lo_lock<br />
| | | | Freq range: 70.000 to 6000.000 MHz<br />
| | | | Gain range PGA: 0.0 to 76.0 step 1.0 dB<br />
| | | | Bandwidth range: 20000000.0 to 40000000.0 step 0.0 Hz<br />
| | | | Connection Type: IQ<br />
| | | | Uses LO offset: No<br />
| | | _____________________________________________________<br />
| | | /<br />
| | | | RX Frontend: 1<br />
| | | | Name: Neon<br />
| | | | Antennas: RX2, TX/RX<br />
| | | | Sensors: lo_locked, ad9361_temperature, rssi, lo_lock<br />
| | | | Freq range: 70.000 to 6000.000 MHz<br />
| | | | Gain range PGA: 0.0 to 76.0 step 1.0 dB<br />
| | | | Bandwidth range: 20000000.0 to 40000000.0 step 0.0 Hz<br />
| | | | Connection Type: IQ<br />
| | | | Uses LO offset: No<br />
| | | _____________________________________________________<br />
| | | /<br />
| | | | RX Codec: A<br />
| | | | Name: AD9361 Dual ADC<br />
| | | | Gain Elements: None<br />
| | _____________________________________________________<br />
| | /<br />
| | | TX Dboard: A<br />
| | | _____________________________________________________<br />
| | | /<br />
| | | | TX Frontend: 0<br />
| | | | Name: Neon<br />
| | | | Antennas: TX/RX<br />
| | | | Sensors: lo_locked, ad9361_temperature<br />
| | | | Freq range: 47.000 to 6000.000 MHz<br />
| | | | Gain range PGA: 0.0 to 89.8 step 0.2 dB<br />
| | | | Bandwidth range: 20000000.0 to 40000000.0 step 0.0 Hz<br />
| | | | Connection Type: IQ<br />
| | | | Uses LO offset: No<br />
| | | _____________________________________________________<br />
| | | /<br />
| | | | TX Frontend: 1<br />
| | | | Name: Neon<br />
| | | | Antennas: TX/RX<br />
| | | | Sensors: lo_locked, ad9361_temperature<br />
| | | | Freq range: 47.000 to 6000.000 MHz<br />
| | | | Gain range PGA: 0.0 to 89.8 step 0.2 dB<br />
| | | | Bandwidth range: 20000000.0 to 40000000.0 step 0.0 Hz<br />
| | | | Connection Type: IQ<br />
| | | | Uses LO offset: No<br />
| | | _____________________________________________________<br />
| | | /<br />
| | | | TX Codec: A<br />
| | | | Name: AD9361 Dual DAC<br />
| | | | Gain Elements: None<br />
| | _____________________________________________________<br />
| | /<br />
| | | RFNoC blocks on this device:<br />
| | | <br />
| | | * DmaFIFO_0<br />
| | | * Radio_0<br />
| | | * DDC_0<br />
| | | * DUC_0<br />
<br />
</pre><br />
<br />
<br />
<br />
===ASCII Art Example===<br />
The UHD driver includes several example programs, which may serve as test programs or the basis for your application program. The source code can be obtained from the UHD repository on github at: https://github.com/EttusResearch/uhd/tree/master/host/examples<br />
<br />
You can quickly verify the operation of your USRP E320 by running the <code>rx_ascii_art_dft</code> UHD example program.<br />
<br />
The <code>rx_ascii_art_dft</code> utility is a simple console based, real-time FFT display tool. It is not graphical in nature, so it can be easily run over an SSH connection within a terminal window, and does not need any graphical capability, such as X Windows, to be installed. It can also be run over a serial console connection, although this is not recommended, as the formatting may not render correctly.<br />
<br />
You can run a simple test of the E320 USRP by connecting an antenna and observing the spectrum of a commercial FM radio station in real-time, following the steps below:<br />
<br />
1. Attach an antenna to the <code>RF A / RX2</code> antenna port of the E320.<br />
<br />
2. From your host computer, run the command:<br />
<br />
$ /usr/local/lib/uhd/examples/rx_ascii_art_dft \<br />
--args "addr=192.168.10.2" \<br />
--freq 98.5e6 \<br />
--rate 2e6 \<br />
--gain 40 \<br />
--ref-lvl="-30" \<br />
--dyn-rng 90 \<br />
--ant "RX2" \<br />
--subdev "A:0"<br />
<br />
NOTE: Modify the commandline argument <code>freq</code> above to specify a tuning frequency for a strong local FM radio station. You will also need to update the IP Address to match your device IP.<br />
<br />
3. You should see a real-time FFT display of 2 MHz of spectrum, centered at the specified tuning frequency.<br />
<br />
4. Type "<code>Q</code>" to stop the program and to return to the Linux command line.<br />
<br />
5. You can run with the <code>--help</code> argument to see a description of all available command-line options.<br />
<br />
Example Output:<br />
<br />
<pre><br />
$ ./rx_ascii_art_dft --args "addr=192.168.10.2" --freq 98.5e6 --rate 2e6 --gain 40 --ref-lvl="-30" --dyn-rng 90 --ant "RX2" --subdev "A:0"<br />
<br />
Creating the usrp device with: addr=192.168.10.2...<br />
[INFO] [UHD] linux; GNU C++ version 5.4.0 20160609; Boost_105800; UHD_3.13.1.0-1-gd3b7e90a<br />
[INFO] [MPMD] Initializing 1 device(s) in parallel with args: mgmt_addr=192.168.10.2,type=e3xx,product=e320,serial=316E375,claimed=False,addr=192.168.10.2<br />
[INFO] [0/DmaFIFO_0] Initializing block control (NOC ID: 0xF1F0D00000000000)<br />
[INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1334 MB/s)<br />
[INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1325 MB/s)<br />
[INFO] [0/Radio_0] Initializing block control (NOC ID: 0x12AD100000003320)<br />
[INFO] [0/DDC_0] Initializing block control (NOC ID: 0xDDC0000000000000)<br />
[INFO] [0/DUC_0] Initializing block control (NOC ID: 0xD0C0000000000002)<br />
[INFO] [MPM.PeriphManager] init() called with device args `product=e320,mgmt_addr=192.168.10.2'.<br />
[INFO] [0/Radio_0] Performing CODEC loopback test... <br />
[INFO] [0/Radio_0] CODEC loopback test passed<br />
[INFO] [0/Radio_0] Performing CODEC loopback test... <br />
[INFO] [0/Radio_0] CODEC loopback test passed<br />
Using Device: Single USRP:<br />
Device: E300-Series Device<br />
Mboard 0: ni-e320-316E375<br />
RX Channel: 0<br />
RX DSP: 0<br />
RX Dboard: A<br />
RX Subdev: Neon<br />
TX Channel: 0<br />
TX DSP: 0<br />
TX Dboard: A<br />
TX Subdev: Neon<br />
TX Channel: 1<br />
TX DSP: 1<br />
TX Dboard: A<br />
TX Subdev: Neon<br />
<br />
Setting RX Rate: 2.000000 Msps...<br />
Actual RX Rate: 2.000000 Msps...<br />
<br />
Setting RX Freq: 98.500000 MHz...<br />
Actual RX Freq: 98.500000 MHz...<br />
<br />
Setting RX Gain: 40.000000 dB...<br />
Actual RX Gain: 40.000000 dB...<br />
<br />
Checking RX: all_los: locked ...<br />
<br />
Done!<br />
</pre><br />
<br />
===Benchmarking your system===<br />
Included with the UHD driver example programs is a utility, <code>benchmark_rate</code> to benchmark the transport link of the system.<br />
<br />
A system's maximum performance is dependent upon many factors. <code>benchmark_rate</code> will exercise the transport link and CPU of the system.<br />
<br />
====1 Gb Interface====<br />
NOTE: This example requires the <code>1G</code> FPGA image to be loaded.<br />
<br />
This example will test one full-duplex stream using "RFA/A:0", at a rate of 2 MS/s, for 60 seconds:<br />
<br />
/usr/local/lib/uhd/examples/benchmark_rate \<br />
--args "addr=192.168.10.2" \<br />
--duration 60 \<br />
--channels "0" \<br />
--rx_rate 2e6 \<br />
--rx_subdev "A:0" \<br />
--tx_rate 2e6 \<br />
--tx_subdev "A:0"<br />
<br />
This example will test two full-duplex streams at 2 MS/s, for 60 seconds:<br />
<br />
/usr/local/lib/uhd/examples/benchmark_rate \<br />
--args "addr=192.168.10.2" \<br />
--duration 60 \<br />
--channels "0,1" \<br />
--rx_rate 2e6 \<br />
--rx_subdev "A:0 A:1" \<br />
--tx_rate 2e6 \<br />
--tx_subdev "A:0 A:1"<br />
<br />
This example will test two full-duplex streams at 12.5 MS/s, for 60 seconds:<br />
<br />
/usr/local/lib/uhd/examples/benchmark_rate \<br />
--args "addr=192.168.10.2,master_clock_rate=25e6" \<br />
--duration 60 \<br />
--channels "0,1" \<br />
--rx_rate 12.5e6 \<br />
--rx_subdev "A:0 A:1" \<br />
--tx_rate 12.5e6 \<br />
--tx_subdev "A:0 A:1"<br />
<br />
When streaming samples over a 1 Gb transport link, the maximum accumulative rate for all channels is 25 MS/s with a <code>sc16</code> OTW format. To achieve higher streaming rates, it is recommended to use the 10 Gb interfaces.<br />
<br />
====10 Gb Interface ====<br />
NOTE: These examples require the <code>XG</code> FPGA image to be loaded.<br />
<br />
This example will test one full-duplex stream using "RFA/A:0", at a rate of 61.44 MS/s, for 60 seconds:<br />
<br />
/usr/local/lib/uhd/examples/benchmark_rate \<br />
--args "addr=192.168.10.2,master_clock_rate=61.44e6" \<br />
--duration 60 \<br />
--channels "0" \<br />
--rx_rate 61.44e6 \<br />
--rx_subdev "A:0" \<br />
--tx_rate 61.44e6 \<br />
--tx_subdev "A:0" <br />
<br />
This example will test two full-duplex stream, at a rate of 30.72 MS/s, for 60 seconds:<br />
<br />
/usr/local/lib/uhd/examples/benchmark_rate \<br />
--args "addr=192.168.10.2,master_clock_rate=61.44e6" \<br />
--duration 60 \<br />
--channels "0,1" \<br />
--rx_rate 30.72e6 \<br />
--rx_subdev "A:0 A:1" \<br />
--tx_rate 30.72e6 \<br />
--tx_subdev "A:0 A:1"<br />
<br />
==USRP E320 Device Specific Operations==<br />
<br />
===Turning the Device Off/On===<br />
To avoid damaging the file system and causing any corruption, do not turn the device off with the power button without first shutting down the system. Use this command to cleanly and properly shut the system down:<br />
<br />
shutdown -h now<br />
<br />
=== Autoboot ===<br />
<br />
The USRP E320 can be configured to power on and boot automatically when power is applied. By default, autoboot is disabled on all USRPs that support it. To control autoboot on the USRP E320, first determine the current value for <code>MCU_FLAGS[0]</code> by running <code>eeprom-dump</code>; the meaning of the <code>MCU_FLAGS[0]</code> [https://files.ettus.com/manual/page_usrp_e3xx.html#e320_eeprom_flags is found in the UHD manual]. The least significant bit when <code>MCU_FLAGS[0]</code> is viewed as a binary value controls the autoboot.<br />
<br />
For example<br />
<pre><br />
root@ni-e320-XXXXXXX:~# eeprom-dump<br />
-- PID/REV: e320 0002<br />
-- MCU_FLAGS[0]: 00000008<br />
-- MCU_FLAGS[1]: 00000000<br />
-- MCU_FLAGS[2]: 00000000<br />
-- MCU_FLAGS[3]: 00000000<br />
-- Serial: XXXXXXX<br />
-- eth_addr0: XX:XX:XX:XX:XX:XX<br />
-- eth_addr1: XX:XX:XX:XX:XX:XX<br />
-- eth_addr2: XX:XX:XX:XX:XX:XX<br />
-- DT-Compat/MCU-Compat: 0000 0002<br />
-- CRC: cbd79a61 (matches)<br />
</pre><br />
shows <code>-- MCU_FLAGS[0]: 00000008</code>; <code>0x08</code> (<code>0b00001000</code> in binary) indicates that autoboot is disabled. If this value were <code>0x09</code> (<code>0b00001001</code> in binary) it would indicate that autoboot is enabled because least significant bit is 1; same would be true if this value is <code>0x01</code> (<code>0b00000001</code> in binary).<br />
<br />
To enable or disable autoboot, copy the existing value of <code>MCU_FLAGS[0]</code> retrieved by <code>eeprom-dump</code> into <code><MCU_FLAGS[0]></code> below and run the command:<br />
<br />
* Disable autoboot on USRP E320 (sets least significant bit to 0), regardless of whether currently enabled or disabled:<br />
<pre><br />
root@ni-e320-XXXXXXX:~# eeprom-set-flags $((0x<MCU_FLAGS[0]> & ~0x1))<br />
</pre><br />
Thus, for the value noted above (autoboot is already disabled, so this command doesn't actually change anything):<br />
<pre><br />
root@ni-e320-XXXXXXX:~# eeprom-set-flags $((0x00000008 & ~0x1))<br />
-- PID/REV: e320 0002<br />
-- MCU_FLAGS[0]: 00000008<br />
-- MCU_FLAGS[1]: 00000000<br />
-- MCU_FLAGS[2]: 00000000<br />
-- MCU_FLAGS[3]: 00000000<br />
-- Serial: XXXXXXX<br />
-- eth_addr0: XX:XX:XX:XX:XX:XX<br />
-- eth_addr1: XX:XX:XX:XX:XX:XX<br />
-- eth_addr2: XX:XX:XX:XX:XX:XX<br />
-- DT-Compat/MCU-Compat: 0000 0002<br />
-- CRC: cbd79a61 (matches)<br />
-- Reading back <br />
-- PID/REV: e320 0002<br />
-- MCU_FLAGS[0]: 00000008<br />
-- MCU_FLAGS[1]: 00000000<br />
-- MCU_FLAGS[2]: 00000000<br />
-- MCU_FLAGS[3]: 00000000<br />
-- Serial: XXXXXXX<br />
-- eth_addr0: XX:XX:XX:XX:XX:XX<br />
-- eth_addr1: XX:XX:XX:XX:XX:XX<br />
-- eth_addr2: XX:XX:XX:XX:XX:XX<br />
-- DT-Compat/MCU-Compat: 0000 0002<br />
-- CRC: 448fb572 (matches)<br />
</pre><br />
<br />
* Enable autoboot on USRP E320 (sets least significant bit to 1), regardless of whether currently enabled or disabled. For example when changing from autoboot disabled to enabled:<br />
<pre><br />
root@ni-e320-XXXXXXX:~# eeprom-set-flags $((0x<MCU_FLAGS[0]> | 0x1))<br />
</pre><br />
Thus, for the value noted above:<br />
<pre><br />
root@ni-e320-XXXXXXX:~# eeprom-set-flags $((0x00000008 | 0x1))<br />
-- PID/REV: e320 0002<br />
-- MCU_FLAGS[0]: 00000008<br />
-- MCU_FLAGS[1]: 00000000<br />
-- MCU_FLAGS[2]: 00000000<br />
-- MCU_FLAGS[3]: 00000000<br />
-- Serial: XXXXXXX<br />
-- eth_addr0: XX:XX:XX:XX:XX:XX<br />
-- eth_addr1: XX:XX:XX:XX:XX:XX<br />
-- eth_addr2: XX:XX:XX:XX:XX:XX<br />
-- DT-Compat/MCU-Compat: 0000 0002<br />
-- CRC: cbd79a61 (matches)<br />
-- Reading back <br />
-- PID/REV: e320 0002<br />
-- MCU_FLAGS[0]: 00000009<br />
-- MCU_FLAGS[1]: 00000000<br />
-- MCU_FLAGS[2]: 00000000<br />
-- MCU_FLAGS[3]: 00000000<br />
-- Serial: XXXXXXX<br />
-- eth_addr0: XX:XX:XX:XX:XX:XX<br />
-- eth_addr1: XX:XX:XX:XX:XX:XX<br />
-- eth_addr2: XX:XX:XX:XX:XX:XX<br />
-- DT-Compat/MCU-Compat: 0000 0002<br />
-- CRC: 448fb572 (matches)<br />
</pre><br />
<br />
If setting this flag ''does not'' allow autoboot control on the USRP E320, then the device boot firmware needs to be updated. This update is accomplished via the following instructions.<br />
<br />
On the USRP E320 via ssh or serial terminal, [https://files.ettus.com/binaries/misc/upgrade_mcu_neon_v1.1.7358-a190641-musl-glibc-rev3-6.tar.gz download the update MCU firmware] and extract it:<br />
<pre><br />
root@ni-e320-XXXXXXX:~# curl https://files.ettus.com/binaries/misc/upgrade_mcu_neon_v1.1.7358-a190641-musl-glibc-rev3-6.tar.gz | tar zxf -<br />
</pre><br />
This will create a directory <code>upgrade_mcu_neon_v1.1.7358-a190641-musl-glibc-rev3-6</code>. Go into this directory and run the firmware flash script:<br />
<pre><br />
root@ni-e320-XXXXXXX:~# cd upgrade_mcu_neon_v1.1.7358-a190641-musl-glibc-rev3-6<br />
root@ni-e320-XXXXXXX:~/upgrade_mcu_neon_v1.1.7358-a190641-musl-glibc-rev3-6# ./flash-firmware.sh<br />
This script updates the microcontroller firmware (RO part). The change is<br />
persistent across power cycles. Incorrect updates can only fixed be a manual<br />
process which requires opening the enclosure.<br />
<br />
Updating the microcontroller firmware (RO part) is only required if the Ettus<br />
Research support told you to do so.<br />
<br />
Press "y" to continue<br />
</pre><br />
At the prompt, press the <code>y</code> key to continue. Pressing any other key aborts the procedure:<br />
<pre><br />
Press "y" to continue n<br />
<br />
aborting<br />
root@ni-e320-317F9BF:~/upgrade_mcu_neon_v1.1.7358-a190641-musl-glibc-rev3-6# <br />
</pre><br />
Pressing the <code>y</code> key:<br />
<pre><br />
Press "y" to continue y<br />
<br />
This script will flash ec-neon-rev3.RO.flat to the device<br />
old RO version: neon_vX.X.XXXX-XXXXXXX<br />
new RO version: neon_v1.1.7358-a190641<br />
<br />
Press "y" to continue<br />
</pre><br />
At the prompt, press the <code>y</code> key ''again'' to continue. Pressing any other key aborts the procedure as before.<br />
<pre><br />
Press "y" to continue y<br />
<br />
./ectool --interface=dev reboot_ec RW<br />
./ectool --interface=dev flashread 0x0 65536 ec-neon-rev3.RO.flat.old<br />
Reading 65536 bytes at offset 0...<br />
done.<br />
./ectool --interface=dev flasherase 0x0 65536<br />
Erasing 65536 bytes at offset 0...<br />
done.<br />
./ectool --interface=dev flashwrite 0x0 ec-neon-rev3.RO.flat<br />
Reading 49592 bytes from ec-neon-rev3.RO.flat...<br />
Writing to offset 0...<br />
Write size 112...<br />
done.<br />
<br />
copying new firmware files<br />
'ec-neon-rev3.bin' -> '/lib/firmware/ni/ec-neon-rev3.bin'<br />
'ec-neon-rev3.RW.bin' -> '/lib/firmware/ni/ec-neon-rev3.RW.bin'<br />
root@ni-e320-317F9BF:~/upgrade_mcu_neon_v1.1.7358-a190641-musl-glibc-rev3-6# <br />
</pre><br />
<br />
Once the script is done, reboot the USRP (e.g., <code>shutdown -r now</code>), and when it comes up the autoboot flag should now work as desired. If these instructions ''do not'' work, then email [mailto:support@ettus.com support@ettus.com] and ask for alternative instructions on how to update the USRP E320 RO and RW boot firmware such that this EEPROM flag setting is honored.<br />
<br />
===Default Password===<br />
The default user is <code>root</code> and the password is empty (no password).<br />
<br />
It is recommended to update the <code>root</code> password, which can be done with the command <code>passwd</code>:<br />
<br />
Example Output:<br />
<br />
root@ni-e320-serial:~# passwd<br />
Changing password for root<br />
New password:<br />
Re-enter new password:<br />
passwd: password changed.<br />
<br />
==Known Issues==<br />
===Problematic NICs===<br />
In some streaming modes, the Intel I219-LM NIC can produce flow control and sequence errors. It is recommended to use a USB3 to 1 Gb Ethernet Adapter for hosts which have an I219-LM NIC.<br />
<br />
==Technical Support and Community Knowledge Base==<br />
Technical support for USRP hardware is available through email only. If the product arrived in a nonfunctional state or you require technical assistance, please contact [mailto:support@ettus.com support@ettus.com]. Please allow 24 to 48 hours for response by email, depending on holidays and weekends, although we are often able to reply more quickly than that.<br />
<br />
We also recommend that you subscribe to the community mailing lists. The mailing lists have a responsive and knowledgeable community of hundreds of developers and technical users who are located around the world. When you join the community, you will be connected to this group of people who can help you learn about SDR and respond to your technical and specific questions. Often your question can be answered quickly on the mailing lists. Each mailing list also provides an archive of all past conversations and discussions going back many years. Your question or problem may have already been addressed before, and a relevant or helpful solution may already exist in the archive.<br />
<br />
Discussions involving the USRP hardware and the UHD software itself are best addressed through the '''usrp-users''' mailing list at [http://usrp-users.ettus.com http://usrp-users.ettus.com].<br />
<br />
Discussions involving the use of [http://gnuradio.org/ GNU Radio] with USRP hardware and UHD software are best addressed through the '''discuss-gnuradio''' mailing list at [https://lists.gnu.org/mailman/listinfo/discussgnuradio https://lists.gnu.org/mailman/listinfo/discussgnuradio].<br />
<br />
Discussions involving the use of [http://openbts.org/ OpenBTS®] with USRP hardware and UHD software are best addressed through the '''openbts-discuss''' mailing list at [https://lists.sourceforge.net/lists/listinfo/openbtsdiscuss https://lists.sourceforge.net/lists/listinfo/openbtsdiscuss].<br />
<br />
The support page on our website is located at [https://www.ettus.com/support https://www.ettus.com/support]. The Knowledge Base is located at [https://kb.ettus.com https://kb.ettus.com].<br />
<br />
==Legal Considerations==<br />
Every country has laws governing the transmission and reception of radio signals. Users are solely responsible for insuring they use their USRP system in compliance with all applicable laws and regulations. Before attempting to transmit and/or receive on any frequency, we recommend that you determine what licenses may be required and what restrictions may apply.<br />
<br />
*NOTE: This USRP product is a piece of test equipment.<br />
<br />
==Sales and Ordering Support==<br />
If you have any non-technical questions related to your order, then please contact us by email at [mailto:orders@ettus.com orders@ettus.com], or by phone at +14086106399 (Monday-Friday, 8 AM - 5 PM, Pacific Time). Please be sure to include your order number and the serial number of your USRP.<br />
<br />
==Terms and Conditions of Sale==<br />
Terms and conditions of sale can be accessed online at the following link: http://www.ettus.com/legal/terms-and-conditions-of-sale<br />
<br />
[[Category:Getting Started Guides]]<br />
[[Category:E320]]</div>JonathonPendlumhttps://kb.ettus.com/index.php?title=E310/E312&diff=5865E310/E3122023-09-18T23:36:11Z<p>JonathonPendlum: Remove old information and update content to be consistent with UHD 4.x releases</p>
<hr />
<div>== Device Overview ==<br />
The USRP E310 offers a portable stand-alone SDR platform designed for field deployment. The flexible 2x2 MIMO AD9361 transceiver from Analog Devices provides up to 56 MHz of instantaneous bandwidth and spans frequencies from 70 MHz – 6 GHz to cover multiple bands of interest.<br />
<br />
== Key Features==<br />
===E310===<br />
{|<br />
|style="vertical-align:top"|<br />
*Xilinx Zynq 7020 SoC: 7 Series FPGA with ARM Cortex A9 667 MHz dual-core processor<br />
*Analog Devices AD9361 RFIC direct-conversion transceiver<br />
*Frequency range: 70 MHz - 6 GHz<br />
*Up to 56 MHz of instantaneous bandwidth<br />
*2x2 MIMO transceiver<br />
*Up to 10 MS/s sample data transfer rate to ARM processor<br />
*RX, TX filter banks<br />
*Integrated GPS receiver<br />
*9-axis inertial measurement unit<br />
*RF Network on Chip (RFNoC™) FPGA development framework support<br />
|[[File:Product e310.png|250px|center]] <br />
|}<br />
<br />
===E312===<br />
{|<br />
|style="vertical-align:top"|<br />
*Battery Operated<br />
*Xilinx Zynq 7020 SoC: 7 Series FPGA with ARM Cortex A9 866 MHz dual-core processor<br />
*Analog Devices AD9361 RFIC direct-conversion transceiver<br />
*Frequency range: 70 MHz - 6 GHz<br />
*Up to 56 MHz of instantaneous bandwidth<br />
*2x2 MIMO transceiver<br />
*Up to 10 MS/s sample data transfer rate to ARM processor<br />
*RX, TX filter banks<br />
*Integrated GPS receiver<br />
*9-axis inertial measurement unit<br />
*RF Network on Chip (RFNoC™) FPGA development framework support<br />
|[[File:Product e312.png|250px|center]] <br />
|}<br />
<br />
== Daughterboard Specifications==<br />
===E310 MIMO XCVR board===<br />
The USRP E310 MIMO XCVR daughterboard features an integrated MIMO capable RF frontend.<br />
<br />
===Tuning===<br />
The RF frontend has individually tunable receive and transmit chains. Both transmit and receive can be used in a MIMO configuration. For the MIMO case, both receive frontends share the RX LO, and both transmit frontends share the TX LO. Each LO is tunable between 50 MHz and 6 GHz.<br />
<br />
===Gains===<br />
All frontends have individual analog gain controls. The receive frontends have 76 dB of available gain; and the transmit frontends have 89.5 dB of available gain. Gain settings are application specific, but it is recommended that users consider using at least half of the available gain to get reasonable dynamic range.<br />
<br />
===LO lock status===<br />
The frontends provide a lo-locked sensor that can be queried through the UHD API.<br />
<br />
<syntaxhighlight lang="c++"><br />
// assumes 'usrp' is a valid uhd::usrp::multi_usrp::sptr instance<br />
// get status for rx frontend<br />
usrp->get_rx_sensor("lo-locked");<br />
// get status for tx frontend<br />
usrp->get_tx_sensor("lo-locked");<br />
</syntaxhighlight><br />
<br />
===Filter and Antenna Switches===<br />
The transmit and receive filter banks uses switches to select between the available filters. These paths are also dependent on the antenna switch settings. Incorrectly setting the switches generally results in attenuated input / output power. Receive filters are band pass (series high & low pass filters), transmit filters are low pass.<br />
<br />
Source code related to controlling the filter band and antenna switches resides in <code>e300_impl.c</code>. Specifically, refer to methods <code>e300_impl::_update_bandsel</code>, <code>e300_impl::_update_atrs</code>, <code>e300_impl::_update_gpio</code>, and <code>e300_impl::_update_enables</code>. Generally, these methods set the switches depending on the state of transmit and receive streams.<br />
<br />
The following sections provide switch setting tables for antenna and filter selection for frontends A & B receive and transmit paths. For futher details refer to the schematics.<br />
<br />
===Side A Filter and Antenna Switches===<br />
''Note: X = don't care, T = If full duplex, set bits according to transmit table, otherwise don't care. Filter range A – B will be selected if A <= freq < B.''<br />
<br />
'''Receive'''<br />
<br />
{| class="wikitable"<br />
!RX Port <br />
!RX Filter (MHz) <br />
!VCTXRX2_V1,V2 <br />
!VCRX2_V1,V2 <br />
!RX2_BANDSEL[2:0] <br />
!RX2B_BANDSEL[1:0] <br />
!RX2C_BANDSEL[1:0] <br />
|-<br />
<br />
| style="text-align: center" | TRX-A <br />
| style="text-align: center" | &lt; 450 <br />
| style="text-align: center" | 01 <br />
| style="text-align: center" | 10 <br />
| style="text-align: center" | 101 <br />
| style="text-align: center" | XX <br />
| style="text-align: center" | 01 <br />
|-<br />
<br />
| style="text-align: center" | TRX-A <br />
| style="text-align: center" | 450 &ndash; 700 <br />
| style="text-align: center" | 01 <br />
| style="text-align: center" | 10 <br />
| style="text-align: center" | 011 <br />
| style="text-align: center" | XX <br />
| style="text-align: center" | 11 <br />
|-<br />
<br />
| style="text-align: center" | TRX-A <br />
| style="text-align: center" | 700 &ndash; 1200 <br />
| style="text-align: center" | 01 <br />
| style="text-align: center" | 10 <br />
| style="text-align: center" | 001 <br />
| style="text-align: center" | XX <br />
| style="text-align: center" | 10 <br />
|-<br />
<br />
| style="text-align: center" | TRX-A <br />
| style="text-align: center" | 1200 &ndash; 1800 <br />
| style="text-align: center" | 01 <br />
| style="text-align: center" | 10 <br />
| style="text-align: center" | 000 <br />
| style="text-align: center" | 01 <br />
| style="text-align: center" | XX <br />
|-<br />
<br />
| style="text-align: center" | TRX-A <br />
| style="text-align: center" | 1800 &ndash; 2350 <br />
| style="text-align: center" | 01 <br />
| style="text-align: center" | 10 <br />
| style="text-align: center" | 010 <br />
| style="text-align: center" | 11 <br />
| style="text-align: center" | XX <br />
|-<br />
<br />
| style="text-align: center" | TRX-A <br />
| style="text-align: center" | 2350 &ndash; 2600 <br />
| style="text-align: center" | 01 <br />
| style="text-align: center" | 10 <br />
| style="text-align: center" | 100 <br />
| style="text-align: center" | 10 <br />
| style="text-align: center" | XX <br />
|-<br />
<br />
| style="text-align: center" | TRX-A <br />
| style="text-align: center" | 2600 &ndash; 6000 <br />
| style="text-align: center" | 01 <br />
| style="text-align: center" | 01 <br />
| style="text-align: center" | XXX <br />
| style="text-align: center" | XX <br />
| style="text-align: center" | XX <br />
|-<br />
<br />
| style="text-align: center" | RX2-A <br />
| style="text-align: center" | 70 &ndash; 450 <br />
| style="text-align: center" | TT <br />
| style="text-align: center" | 01 <br />
| style="text-align: center" | 101 <br />
| style="text-align: center" | XX <br />
| style="text-align: center" | 01 <br />
|-<br />
<br />
| style="text-align: center" | RX2-A <br />
| style="text-align: center" | 450 &ndash; 700 <br />
| style="text-align: center" | TT <br />
| style="text-align: center" | 01 <br />
| style="text-align: center" | 011 <br />
| style="text-align: center" | XX <br />
| style="text-align: center" | 11 <br />
|-<br />
<br />
| style="text-align: center" | RX2-A <br />
| style="text-align: center" | 700 &ndash; 1200 <br />
| style="text-align: center" | TT <br />
| style="text-align: center" | 01 <br />
| style="text-align: center" | 001 <br />
| style="text-align: center" | XX <br />
| style="text-align: center" | 10 <br />
|-<br />
<br />
| style="text-align: center" | RX2-A <br />
| style="text-align: center" | 1200 &ndash; 1800 <br />
| style="text-align: center" | TT <br />
| style="text-align: center" | 01 <br />
| style="text-align: center" | 000 <br />
| style="text-align: center" | 01 <br />
| style="text-align: center" | XX <br />
|-<br />
<br />
| style="text-align: center" | RX2-A <br />
| style="text-align: center" | 1800 &ndash; 2350 <br />
| style="text-align: center" | TT <br />
| style="text-align: center" | 01 <br />
| style="text-align: center" | 010 <br />
| style="text-align: center" | 11 <br />
| style="text-align: center" | XX <br />
|-<br />
<br />
| style="text-align: center" | RX2-A <br />
| style="text-align: center" | 2350 &ndash; 2600 <br />
| style="text-align: center" | TT <br />
| style="text-align: center" | 01 <br />
| style="text-align: center" | 100 <br />
| style="text-align: center" | 10 <br />
| style="text-align: center" | XX <br />
|-<br />
<br />
| style="text-align: center" | RX2-A <br />
| style="text-align: center" | &gt;= 2600 <br />
| style="text-align: center" | TT <br />
| style="text-align: center" | 10 <br />
| style="text-align: center" | XXX <br />
| style="text-align: center" | XX <br />
| style="text-align: center" | XX <br />
|-<br />
|}<br />
<br />
'''Transmit'''<br />
{| class="wikitable"<br />
<br />
! TX Port <br />
! TX Filter (MHz) <br />
! VCTXRX2_V1,V2 <br />
! TX_ENABLE2A,2B <br />
! TX_BANDSEL[2:0] <br />
|-<br />
<br />
| style="text-align:center;" | TRX-A <br />
| style="text-align:center;" | &lt; 117.7 <br />
| style="text-align:center;" | 10 <br />
| style="text-align:center;" | 01 <br />
| style="text-align:center;" | 111 <br />
|-<br />
<br />
| style="text-align:center;" | TRX-A <br />
| style="text-align:center;" | 117.7 &ndash; 178.2 <br />
| style="text-align:center;" | 10 <br />
| style="text-align:center;" | 01 <br />
| style="text-align:center;" | 110 <br />
|-<br />
<br />
| style="text-align:center;" | TRX-A <br />
| style="text-align:center;" | 178.2 &ndash; 284.3 <br />
| style="text-align:center;" | 10 <br />
| style="text-align:center;" | 01 <br />
| style="text-align:center;" | 101 <br />
|-<br />
<br />
| style="text-align:center;" | TRX-A <br />
| style="text-align:center;" | 284.3 &ndash; 453.7 <br />
| style="text-align:center;" | 10 <br />
| style="text-align:center;" | 01 <br />
| style="text-align:center;" | 100 <br />
|-<br />
<br />
| style="text-align:center;" | TRX-A <br />
| style="text-align:center;" | 453.7 &ndash; 723.8 <br />
| style="text-align:center;" | 10 <br />
| style="text-align:center;" | 01 <br />
| style="text-align:center;" | 011 <br />
|-<br />
<br />
| style="text-align:center;" | TRX-A <br />
| style="text-align:center;" | 723.8 &ndash; 1154.9 <br />
| style="text-align:center;" | 10 <br />
| style="text-align:center;" | 01 <br />
| style="text-align:center;" | 010 <br />
|-<br />
<br />
| style="text-align:center;" | TRX-A <br />
| style="text-align:center;" | 1154.9 &ndash; 1842.6 <br />
| style="text-align:center;" | 10 <br />
| style="text-align:center;" | 01 <br />
| style="text-align:center;" | 001 <br />
|-<br />
<br />
| style="text-align:center;" | TRX-A <br />
| style="text-align:center;" | 1842.6 &ndash; 2940.0 <br />
| style="text-align:center;" | 10 <br />
| style="text-align:center;" | 01 <br />
| style="text-align:center;" | 000 <br />
|-<br />
<br />
| style="text-align:center;" | TRX-A <br />
| style="text-align:center;" | &gt;= 2940.0 <br />
| style="text-align:center;" | 11 <br />
| style="text-align:center;" | 10 <br />
| style="text-align:center;" | XXX <br />
|-<br />
<br />
|}<br />
<br />
''Note: Although the transmit filters are low pass, this table describes UHD's tuning range for selecting each filter path. The table also includes the required transmit enable state.''<br />
<br />
<br />
===Side B Filter and Antenna Switches===<br />
''Note: X = don't care, T = If full duplex, set bits according to transmit table, otherwise don't care. Filter range A – B will be selected if A <= freq < B.''<br />
<br />
'''Receive'''<br />
{| class="wikitable"<br />
! RX Port <br />
! RX Filter (MHz) <br />
! VCTXRX1_V1,V2 <br />
! VCRX1_V1,V2 <br />
! RX1_BANDSEL[2:0] <br />
! RX1B_BANDSEL[1:0] <br />
! RX1C_BANDSEL[1:0] <br />
|-<br />
<br />
| style="text-align:center;" | TRX-B <br />
| style="text-align:center;" | &lt; 450 <br />
| style="text-align:center;" | 10 <br />
| style="text-align:center;" | 01 <br />
| style="text-align:center;" | 100 <br />
| style="text-align:center;" | XX <br />
| style="text-align:center;" | 10 <br />
|-<br />
<br />
| style="text-align:center;" | TRX-B <br />
| style="text-align:center;" | 450 &ndash; 700 <br />
| style="text-align:center;" | 10 <br />
| style="text-align:center;" | 01 <br />
| style="text-align:center;" | 010 <br />
| style="text-align:center;" | XX <br />
| style="text-align:center;" | 11 <br />
|-<br />
<br />
| style="text-align:center;" | TRX-B <br />
| style="text-align:center;" | 700 &ndash; 1200 <br />
| style="text-align:center;" | 10 <br />
| style="text-align:center;" | 01 <br />
| style="text-align:center;" | 000 <br />
| style="text-align:center;" | XX <br />
| style="text-align:center;" | 01 <br />
|-<br />
<br />
| style="text-align:center;" | TRX-B <br />
| style="text-align:center;" | 1200 &ndash; 1800 <br />
| style="text-align:center;" | 10 <br />
| style="text-align:center;" | 01 <br />
| style="text-align:center;" | 001 <br />
| style="text-align:center;" | 10 <br />
| style="text-align:center;" | XX <br />
|-<br />
<br />
| style="text-align:center;" | TRX-B <br />
| style="text-align:center;" | 1800 &ndash; 2350 <br />
| style="text-align:center;" | 10 <br />
| style="text-align:center;" | 01 <br />
| style="text-align:center;" | 011 <br />
| style="text-align:center;" | 11 <br />
| style="text-align:center;" | XX <br />
|-<br />
<br />
| style="text-align:center;" | TRX-B <br />
| style="text-align:center;" | 2350 &ndash; 2600 <br />
| style="text-align:center;" | 10 <br />
| style="text-align:center;" | 01 <br />
| style="text-align:center;" | 101 <br />
| style="text-align:center;" | 01 <br />
| style="text-align:center;" | XX <br />
|-<br />
<br />
| style="text-align:center;" | TRX-B <br />
| style="text-align:center;" | 2600 &ndash; 6000 <br />
| style="text-align:center;" | 10 <br />
| style="text-align:center;" | 10 <br />
| style="text-align:center;" | XXX <br />
| style="text-align:center;" | XX <br />
| style="text-align:center;" | XX <br />
|-<br />
<br />
| style="text-align:center;" | RX2-B <br />
| style="text-align:center;" | 70 &ndash; 450 <br />
| style="text-align:center;" | TT <br />
| style="text-align:center;" | 10 <br />
| style="text-align:center;" | 100 <br />
| style="text-align:center;" | XX <br />
| style="text-align:center;" | 10 <br />
|-<br />
<br />
| style="text-align:center;" | RX2-B <br />
| style="text-align:center;" | 450 &ndash; 700 <br />
| style="text-align:center;" | TT <br />
| style="text-align:center;" | 10 <br />
| style="text-align:center;" | 010 <br />
| style="text-align:center;" | XX <br />
| style="text-align:center;" | 11 <br />
|-<br />
<br />
| style="text-align:center;" | RX2-B <br />
| style="text-align:center;" | 700 &ndash; 1200 <br />
| style="text-align:center;" | TT <br />
| style="text-align:center;" | 10 <br />
| style="text-align:center;" | 000 <br />
| style="text-align:center;" | XX <br />
| style="text-align:center;" | 01 <br />
|-<br />
<br />
| style="text-align:center;" | RX2-B <br />
| style="text-align:center;" | 1200 &ndash; 1800 <br />
| style="text-align:center;" | TT <br />
| style="text-align:center;" | 10 <br />
| style="text-align:center;" | 001 <br />
| style="text-align:center;" | 10 <br />
| style="text-align:center;" | XX <br />
|-<br />
<br />
| style="text-align:center;" | RX2-B <br />
| style="text-align:center;" | 1800 &ndash; 2350 <br />
| style="text-align:center;" | TT <br />
| style="text-align:center;" | 10 <br />
| style="text-align:center;" | 011 <br />
| style="text-align:center;" | 11 <br />
| style="text-align:center;" | XX <br />
|-<br />
<br />
| style="text-align:center;" | RX2-B <br />
| style="text-align:center;" | 2350 &ndash; 2600 <br />
| style="text-align:center;" | TT <br />
| style="text-align:center;" | 10 <br />
| style="text-align:center;" | 101 <br />
| style="text-align:center;" | 01 <br />
| style="text-align:center;" | XX <br />
|-<br />
<br />
| style="text-align:center;" | RX2-B <br />
| style="text-align:center;" | &gt;= 2600 <br />
| style="text-align:center;" | TT <br />
| style="text-align:center;" | 01 <br />
| style="text-align:center;" | XXX <br />
| style="text-align:center;" | XX <br />
| style="text-align:center;" | XX <br />
|-<br />
<br />
|}<br />
<br />
<br />
'''Transmit'''<br />
{| class="wikitable"<br />
<br />
! TX Port <br />
! TX Filter (MHz) <br />
! VCTXRX1_V1,V2 <br />
! TX_ENABLE1A,1B <br />
! TX1_BANDSEL[2:0] <br />
|-<br />
<br />
| style="text-align:center;" | TRX-B <br />
| style="text-align:center;" | &lt; 117.7 <br />
| style="text-align:center;" | 00 <br />
| style="text-align:center;" | 01 <br />
| style="text-align:center;" | 111 <br />
|-<br />
<br />
| style="text-align:center;" | TRX-B <br />
| style="text-align:center;" | 117.7 &ndash; 178.2 <br />
| style="text-align:center;" | 00 <br />
| style="text-align:center;" | 01 <br />
| style="text-align:center;" | 110 <br />
|-<br />
<br />
| style="text-align:center;" | TRX-B <br />
| style="text-align:center;" | 178.2 &ndash; 284.3 <br />
| style="text-align:center;" | 00 <br />
| style="text-align:center;" | 01 <br />
| style="text-align:center;" | 101 <br />
|-<br />
<br />
| style="text-align:center;" | TRX-B <br />
| style="text-align:center;" | 284.3 &ndash; 453.7 <br />
| style="text-align:center;" | 00 <br />
| style="text-align:center;" | 01 <br />
| style="text-align:center;" | 100 <br />
|-<br />
<br />
| style="text-align:center;" | TRX-B <br />
| style="text-align:center;" | 453.7 &ndash; 723.8 <br />
| style="text-align:center;" | 00 <br />
| style="text-align:center;" | 01 <br />
| style="text-align:center;" | 011 <br />
|-<br />
<br />
| style="text-align:center;" | TRX-B <br />
| style="text-align:center;" | 723.8 &ndash; 1154.9 <br />
| style="text-align:center;" | 00 <br />
| style="text-align:center;" | 01 <br />
| style="text-align:center;" | 010 <br />
|-<br />
<br />
| style="text-align:center;" | TRX-B <br />
| style="text-align:center;" | 1154.9 &ndash; 1842.6 <br />
| style="text-align:center;" | 00 <br />
| style="text-align:center;" | 01 <br />
| style="text-align:center;" | 001 <br />
|-<br />
<br />
| style="text-align:center;" | TRX-B <br />
| style="text-align:center;" | 1842.6 &ndash; 2940.0 <br />
| style="text-align:center;" | 00 <br />
| style="text-align:center;" | 01 <br />
| style="text-align:center;" | 000 <br />
|-<br />
<br />
| style="text-align:center;" | TRX-B <br />
| style="text-align:center;" | &gt;= 2940.0 <br />
| style="text-align:center;" | 11 <br />
| style="text-align:center;" | 10 <br />
| style="text-align:center;" | XXX <br />
|-<br />
<br />
|}<br />
<br />
''Note: Although the transmit filters are low pass, the following table describes UHD's tuning range for selecting each filter path. The table also includes the required transmit enable states.''<br />
<br />
<br />
<br />
==RF Specifications==<br />
===RF Performance===<br />
* SSB/LO Suppression -35/50 dBc<br />
* Phase Noise 3.5 GHz 1.0 deg RMS<br />
* Phase Noise 6 GHz 1.5 deg RMS<br />
* Power Output >10dBm<br />
* IIP3 (@ typ NF) -20dBm<br />
* Typical Noise Figure <8dB<br />
<br />
===Input/Output Impedance===<br />
* All RF Ports are matched to 50 Ohm with -10dB or better return loss generally. Detailed test is pending.<br />
<br />
==Hardware Specifications==<br />
* Ettus Research recommends to always use the latest stable version of UHD<br />
<br />
===E310===<br />
* Current Hardware Revision: 1<br />
* Minimum version of UHD required: 3.8.0<br />
* Required version on the host computer must match what is running on the E310<br />
<br />
===E312===<br />
* Current Hardware Revision: 1<br />
* Minimum version of UHD required: 3.8.5<br />
* Required version on the host computer must match what is running on the E312<br />
<br />
==Physical Specifications==<br />
<br />
===Dimensions===<br />
* 133 x 68 x 26.4 mm<br />
<br />
==Environmental Specifications==<br />
===Operating Temperature Range===<br />
* E310 0-40 °C<br />
* E312 0-40 °C<br />
<br />
===Operating Humidity Range===<br />
* 10% to 90% non-condensing<br />
<br />
==Schematics==<br />
===E310===<br />
[http://files.ettus.com/schematics/e310/e310.pdf E310 Schematics]<br />
<br />
[http://files.ettus.com/schematics/e310/e310_db.pdf E310 DB]<br />
<br />
[[Media: E310_System_Diagram.png|E310 Architecture]]<br />
<br />
==Key Component Datasheets==<br />
{| class="wikitable" style="width:80%"<br />
!Part Number<br />
!Description<br />
!Schematic ID (Page)<br />
|-<br />
! colspan="3" | Motherboard <br />
|-<br />
|[http://www.ti.com.cn/cn/lit/ds/symlink/txs02612.pdf TXS02612RTWR]<br />
|SDIO PORT EXPANDER<br />
|U23 (2)<br />
|-<br />
|[http://www.xilinx.com/support/documentation/data_sheets/ds187-XC7Z010-XC7Z020-Data-Sheet.pdf XC7Z020-1CLG484CES9919]<br />
|FPGA<br />
|U11 (2,3,4,8,11,13)<br />
|-<br />
<br />
|[http://www.xilinx.com/products/silicon-devices/soc/zynq-7000.html Xilinx Zynq Product Page ]<br />
|FPGA<br />
| -<br />
|-<br />
<br />
|[http://ww1.microchip.com/downloads/en/DeviceDoc/00001678A.pdf USB3340-EZK-TR]<br />
|ULPI Transceiver<br />
|U33 (5)<br />
|-<br />
|[http://www.akm.com/akm/en/file/datasheet/AK4571VQ.pdf AK4571VQP]<br />
|Audio CODEC<br />
|U30 (6)<br />
|-<br />
|[http://www.ftdichip.com/Support/Documents/DataSheets/ICs/DS_FT230X.pdf FT230XQ-R]<br />
|UART Interface<br />
|U32 (6)<br />
|-<br />
|[http://www.marvell.com/transceivers/assets/Alaska_88E1512-001_product_brief.pdf 88E1512]<br />
|Gigabit Ethernet Transceiver<br />
|U13 (7)<br />
|-<br />
|[http://ww1.microchip.com/downloads/en/DeviceDoc/21210N.pdf 24LC024/SN]<br />
|EEPROM<br />
|U5 (9)<br />
|-<br />
|[http://datasheets.maximintegrated.com/en/ds/DS1339-DS1339U.pdf DS1339,SM]<br />
|Real-Time Clock<br />
|U6 (9)<br />
|-<br />
|[http://www.analog.com/media/en/technical-documentation/data-sheets/ADT7408.pdf ADT7408]<br />
|Temperature Sensor<br />
|U8 (9)<br />
|-<br />
|[https://www.invensense.com/wp-content/uploads/2015/02/MPU-9150-Datasheet.pdf MPU-9150]<br />
|Motion Processing Unit<br />
|U3 (9)<br />
|-<br />
<br />
|[http://www.invensense.com/products/motion-tracking/9-axis/mpu-9150/ InvenSense MPU-9150 Product Page]<br />
| Motion Processing Unit<br />
|U3 (9)<br />
|-<br />
<br />
|[https://ae-bst.resource.bosch.com/media/_tech/media/datasheets/BST-BMP180-DS000-121.pdf BMP180]<br />
|Digital pressure sensor<br />
|U4 (9)<br />
|-<br />
|[http://www.ti.com/lit/ds/symlink/bq24192.pdf BQ24192]<br />
|Adapter Charger<br />
|U1 (10)<br />
|-<br />
|[http://www.ti.com/lit/ds/symlink/tps54478.pdf TPS54478]<br />
|Step-Down Switcher<br />
|U20 (10)<br />
|-<br />
|[https://datasheets.maximintegrated.com/en/ds/MAX6509-MAX6510.pdf MAX6510HAUT-T]<br />
|Temperature Switches<br />
|U35 (10)<br />
|-<br />
|[http://www.atmel.com/images/doc8008.pdf ATTINY88-MU]<br />
|Microcontroller<br />
|U18 (10)<br />
|-<br />
|[http://www.ti.com/lit/ds/symlink/tps61253.pdf TPS61253YFF]<br />
|Step-Up Converter<br />
|U19 (10)<br />
|-<br />
<br />
|[https://www.u-blox.com/sites/default/files/products/documents/AMY-6_ProductSummary_%28GPS.G6-HW-10039%29.pdf AMY-6M]<br />
|GPS Module<br />
|U12 (6)<br />
|-<br />
<br />
<br />
! colspan="3" | Daughterboard <br />
|-<br />
!Part Number<br />
!Description<br />
!Schematic ID (Page)<br />
|-<br />
<br />
|[http://www.analog.com/en/products/rf-microwave/integrated-transceivers-transmitters-receivers/wideband-transceivers-ic/ad9361.html#product-overview AD9361 Product Page]<br />
|2 x 2 RF Agile Transceiver <br />
| U8 (3)<br />
|-<br />
<br />
|[http://ww1.microchip.com/downloads/en/devicedoc/21203m.pdf 24AA256] <br />
|EEPROM<br />
|U15 (2)<br />
|-<br />
<br />
|[https://www.minicircuits.com/pdfs/TC1-1-43A+.pdf TC-1-43A+] <br />
|RF Transformer<br />
|T6 (3); T5 (3); T4 (3)<br />
|-<br />
<br />
|[https://www.minicircuits.com/pdfs/TC1-1-13M+.pdf TC1-1-13M+]<br />
|RF Transformer<br />
|T7 (3); T10 (3); T1 (3)<br />
|-<br />
<br />
|[http://www.ti.com/lit/ds/symlink/tps62140.pdf TPS62140]<br />
|Step-Down Converter<br />
|U19 (4)<br />
|-<br />
<br />
|[http://www.analog.com/media/en/technical-documentation/data-sheets/ADP1752_1753.pdf ADP1753ACPZ-R7]<br />
|Linear Regulator<br />
|U17 (4); U18 (4)<br />
|-<br />
<br />
|[http://www.rfmd.com/store/downloads/dl/file/id/28671/sga4563z_data_sheet.pdf SGA-4563Z]<br />
|MMIC AMPLIFIER<br />
|U12 (5); U4 (5)<br />
|-<br />
<br />
|[http://www.skyworksinc.com/uploads/documents/SKY13418_485LF_201712D.pdf SKY13418-485LF]<br />
|Antenna Switch <br />
|U13 (5); U3 (5); U16 (5); U2 (5); U10 (6); U5 (6)<br />
|-<br />
<br />
|[http://www.skyworksinc.com/uploads/documents/SKY13373_460LF_201264N.pdf SKY13373-460LF]<br />
|SP3T Switch<br />
|U11 (6); U9 (6); U6 (6); U7 (6); SW4 (7); SW1 (7)<br />
|-<br />
<br />
|[http://www.avagotech.com/docs/AV02-0966EN MGA-81563]<br />
|Amplifier<br />
|U14 (5); U1 (5)<br />
|-<br />
<br />
|[https://www.minicircuits.com/pdfs/LFCN-5850+.pdf LFCN-5850+]<br />
|Low Pass Filter<br />
|FL32 (5); FL1 (5)<br />
|-<br />
<br />
|[https://www.minicircuits.com/pdfs/LFCN-2750.pdf LFCN-2750+]<br />
|Low Pass Filter<br />
|FL37 (5); FL4 (5)<br />
|-<br />
<br />
|[https://www.minicircuits.com/pdfs/LFCN-2250.pdf LFCN-2250+]<br />
|Low Pass Filter<br />
|FL23 (6); FL20 (6)<br />
|-<br />
<br />
|[https://www.minicircuits.com/pdfs/LFCN-1700.pdf LFCN-1700+]<br />
|Low Pass Filter<br />
|FL40 (5); FL2 (5)<br />
|-<br />
<br />
|[https://www.minicircuits.com/pdfs/LFCN-1575.pdf LFCN-1575+]<br />
|Low Pass Filter<br />
|FL25 (6); FL17 (6)<br />
|-<br />
<br />
|[https://www.minicircuits.com/pdfs/LFCN-1000.pdf LFCN-1000+]<br />
|Low Pass Filter<br />
|FL33 (5); FL9 (5); FL27 (6); FL15 (6)<br />
|-<br />
<br />
|[https://www.minicircuits.com/pdfs/LFCN-575.pdf LFCN-575+]<br />
|Low Pass Filter<br />
|FL36 (5); FL5 (5)<br />
|-<br />
<br />
|[https://www.minicircuits.com/pdfs/LFCN-530.pdf LFCN-530+]<br />
|Low Pass Filter<br />
|FL29 (6); FL13 (6)<br />
|-<br />
<br />
|[https://www.minicircuits.com/pdfs/LFCN-400.pdf LFCN-400+]<br />
|Low Pass Filter<br />
|FL38 (5); FL3 (5); FL30 (6); FL11 (6)<br />
|-<br />
<br />
|[https://www.minicircuits.com/pdfs/LFCN-225.pdf LFCN-225]<br />
|Low Pass Filter<br />
|FL39 (5); FL6 (5)<br />
|-<br />
<br />
|[https://www.minicircuits.com/pdfs/LFCN-160+.pdf LFCN-160+]<br />
|Low Pass Filter<br />
|FL34 (5); FL8 (5)<br />
|-<br />
<br />
|[https://www.minicircuits.com/pdfs/LFCN-80.pdf LFCN-80+]<br />
|Low Pass Filter<br />
|FL35 (5); FL7 (5)<br />
|-<br />
<br />
<br />
|[https://www.minicircuits.com/pdfs/HFCN-1600.pdf HFCN-1600+]<br />
|High Pass Filter<br />
|FL22 (6); FL19 (6)<br />
|-<br />
<br />
|[https://www.minicircuits.com/pdfs/HFCN-1100+.pdf HFCN-1100+]<br />
|High Pass Filter<br />
|FL24 (6); FL16 (6)<br />
|-<br />
<br />
|[https://www.minicircuits.com/pdfs/HFCN-650.pdf HFCN-650+]<br />
|High Pass Filter<br />
|FL26 (6); FL14 (6)<br />
|-<br />
<br />
|[https://www.minicircuits.com/pdfs/HFCN-440+.pdf HFCN-440+]<br />
|High Pass Filter<br />
|FL28 (6); FL12 (6)<br />
|-<br />
<br />
<br />
|[https://www.minicircuits.com/pdfs/BFCN-2435+.pdf BFCN-2435+]<br />
|Bandpass Filter<br />
|FL21 (6); FL18 (6)<br />
|-<br />
<br />
|[https://www.fairchildsemi.com/datasheets/FD/FDG6301N.pdf FDG6301N]<br />
|Dual N-Channel, Digital FET<br />
|Q8 (7); Q5 (7)<br />
|-<br />
<br />
|[http://www.farnell.com/datasheets/461118.pdf HSMS-8202]<br />
|Mixer Diodes<br />
|CR1 (7); CR2 (7); CR3 (7); CR4 (7)<br />
|-<br />
<br />
|[http://www.ti.com.cn/cn/lit/ds/symlink/lp5900.pdf LP5900TL]<br />
|Linear Regulator<br />
|U25 (8)<br />
|-<br />
<br />
|[http://www.analog.com/media/en/technical-documentation/data-sheets/ADP150.pdf ADP150AUJZ-3.0]<br />
|Linear Regulator<br />
|U22 (8)<br />
|-<br />
<br />
|[http://www.analog.com/media/en/technical-documentation/data-sheets/AD5662.pdf AD5662RBJ]<br />
|16-Bit nanoDAC<br />
|U21 (8)<br />
|-<br />
<br />
|[http://www.ti.com/lit/ds/symlink/sn74aup1t57.pdf SN74AUP1T57]<br />
|Voltage Translator<br />
|U27 (8); U28 (8); U29 (8)<br />
|-<br />
<br />
<br />
|}<br />
<br />
Request a detailed whitepaper covering features and components from [mailto:info@ettus.com info@ettus.com]<br />
<br />
==Mechanical Information==<br />
<br />
===Weight===<br />
* Partial Enclosure 225 g<br />
* Full Enclosure 375 g<br />
<br />
===Drawings===<br />
====E310====<br />
* [[File:E310_Dimensional_Sketches.pdf]]<br />
* [[File:cu e310 motherboard cca.pdf]]<br />
* [[File:cu E310 daughtercard cca.pdf]]<br />
* [[File:cu usrp-e310.pdf]]<br />
====E312====<br />
* [[File:cu e312 motherboard cca.pdf]]<br />
* [[File:cu e312 daughtercard cca.pdf]]<br />
* [[File:cu ettus-e312.pdf]]<br />
<br />
==FPGA==<br />
* Utilization statistics are subject to change between UHD releases. This information is current as of UHD 3.9.4 and was taken directly from Xilinx Vivado 2014.4.<br />
<br />
===E310/E312===<br />
<pre><br />
1. Slice Logic<br />
--------------<br />
<br />
+----------------------------+-------+-----------+-------+<br />
| Site Type | Used | Available | Util% |<br />
+----------------------------+-------+-----------+-------+<br />
| Slice LUTs | 36203 | 53200 | 68.05 |<br />
| LUT as Logic | 28108 | 53200 | 52.83 |<br />
| LUT as Memory | 8095 | 17400 | 46.52 |<br />
| LUT as Distributed RAM | 870 | | |<br />
| LUT as Shift Register | 7225 | | |<br />
| Slice Registers | 36562 | 106400 | 34.36 |<br />
| Register as Flip Flop | 36562 | 106400 | 34.36 |<br />
| Register as Latch | 0 | 106400 | 0.00 |<br />
| F7 Muxes | 376 | 26600 | 1.41 |<br />
| F8 Muxes | 125 | 13300 | 0.93 |<br />
+----------------------------+-------+-----------+-------+<br />
<br />
3. Memory<br />
---------<br />
<br />
+-------------------+------+-----------+-------+<br />
| Site Type | Used | Available | Util% |<br />
+-------------------+------+-----------+-------+<br />
| Block RAM Tile | 97 | 140 | 69.28 |<br />
| RAMB36/FIFO* | 90 | 140 | 64.28 |<br />
| RAMB36E1 only | 90 | | |<br />
| RAMB18 | 14 | 280 | 5.00 |<br />
| RAMB18E1 only | 14 | | |<br />
+-------------------+------+-----------+-------+<br />
* Note: Each Block RAM Tile only has one FIFO logic available and therefore can accommodate only one FIFO36E1 or one FIFO18E1. However, if a FIFO18E1 occupies a Block RAM Tile, that tile can still accommodate a RAMB18E1<br />
<br />
<br />
4. DSP<br />
------<br />
<br />
+----------------+------+-----------+-------+<br />
| Site Type | Used | Available | Util% |<br />
+----------------+------+-----------+-------+<br />
| DSPs | 120 | 220 | 54.54 |<br />
| DSP48E1 only | 120 | | |<br />
+----------------+------+-----------+-------+<br />
<br />
</pre><br />
<br />
==Interfaces and Connectivity==<br />
*10/100/1000 BASE-T Ethernet<br />
*Stereo audio out, mono mic in<br />
*Integrated GPS receiver<br />
*Host USB support<br />
*9-axis IMU<br />
<br />
===Front Panel===<br />
{|<br />
| style="width:50%" |<br />
*'''RF A Group'''<br />
**'''TX/RX LED:''' Indicates that data is streaming on the TX/RX channel on frontend side A<br />
**'''RX2 LED:''' Indicates that data is streaming on the RX2 channel on frontend side A<br />
*'''RF B Group'''<br />
**'''TX/RX LED:''' Indicates that data is streaming on the TX/RX channel on frontend B<br />
**'''RX2 LED:''' Indicates that data is streaming on the RX2 channel on frontend B<br />
*'''PWR:''' Power switch with integrated status LED, for status description see below.<br />
*'''SYNC:''' Input port for external PPS signal<br />
*'''GPS:''' Connection for the GPS antenna<br />
*'''AUDIO:''' Audio input / output<br />
<br />
The status LED in the power switch indicates the power and charge status. It's behavior is firmware version dependent.<br />
<br />
*'''Version 1''' (original E310)<br />
**'''Off:''' Indicates device is off and not charging<br />
**'''Solid Red:''' Indicates device is charging<br />
**'''Solid Green:''' Indicates device is on<br />
**'''Fast Blinking Red:''' Indicates an error code<br />
***1 - Low voltage error<br />
***2 - Regulator low voltage error<br />
***3 - FPGA power error<br />
***4 - DRAM power error<br />
***5 - 1.8V rail power error<br />
***6 - 3.3V rail power error<br />
***7 - Daughterboard / TX power error<br />
***9 - Temperature error<br />
<br />
*'''Version 2''' (E312 and upgraded E310)<br />
**'''Off:''' Indicates device is off and not charging<br />
**'''Slow Blinking Green:''' Indicates device is off and charging<br />
**'''Fast Blinking Green:''' Indicates device is on and charging<br />
**'''Solid Green:''' Indicates device is on (and not charging, if E312)<br />
**'''Solid Orange:''' Indicates device is on and discharging<br />
**'''Fast Blinking Orange:''' Indicates device is on, discharging, and charge is below 10% charge<br />
**'''Fast Blinking Red:''' Indicates an error code<br />
***1 - Low voltage error<br />
***2 - Regulator low voltage error<br />
***3 - FPGA power error<br />
***4 - DRAM power error<br />
***5 - 1.8V rail power error<br />
***6 - 3.3V rail power error<br />
***7 - Daughterboard / TX power error<br />
***8 - Charger error<br />
***9 - Charger temperature error<br />
***10 - Battery low error<br />
***11 - Fuel Gauge temperature error<br />
***12 - Global (case) temperature error<br />
<br />
| style="vertical-align:top" | [[File:e3x0 fp overlay.png]]<br />
|}<br />
<br />
===Rear Panel===<br />
{|<br />
| style="width:50%" |<br />
*'''PWR:''' Locking connector (Kycon KLDHCX-0202-A-LT) for the USRP-E Series power supply<br />
*'''1G ETH:''' RJ45 port for Ethernet interfaces<br />
*'''USB:''' USB 2.0 Port<br />
*'''SERIAL:''' Micro USB connection for serial uart console<br />
<br />
<br />
| style="vertical-align:top" | [[File:e3x0 rp overlay.png]]<br />
<br />
|}<br />
<br />
===GPIO===<br />
{|<br />
<br />
| style="width:60%" |<br />
'''Pin Mapping'''<br />
* Pin 1: +3.3V<br />
* Pin 2: Reserved<br />
* Pin 3: Data[5]<br />
* Pin 4: Reserved<br />
* Pin 5: Data[4]<br />
* Pin 6: Data[0]<br />
* Pin 7: Data[3]<br />
* Pin 8: Data[1]<br />
* Pin 9: 0V<br />
* Pin 10: Data[2]<br />
|[[File:e3x0 gpio conn.png]]<br />
|}<br />
* Please see the [http://files.ettus.com/manual/page_gpio_api.html E3x0/X3x0 GPIO API] for information on configuring and using the GPIO bus.<br />
<br />
===Audio===<br />
{|<br />
| style="width:60%" | <br />
* The E3x0 2.5 mm Audio Jack TRRS pins are assigned as follows: Tip=Mic, Ring1=Right, Ring2=Left, Sleeve=GND.<br />
* The Left/Right audio outputs are compatible with typical low-impedance headphones (16 to 32 Ohms). The Microphone pin provides approximately 2 mA bias at 2.2 V when not suspended. A variety of pin configurations can be found on commonly available headsets, so an adapter may be required.<br />
<br />
|[[File:TRRS.png]]<br />
<br />
|}<br />
<br />
==E312 Battery==<br />
The USRP E312 is equipped with an integrated 3.7V, 3200mAh lithiumion battery cell. After unboxing the USRP E312 , plug in the power adapter to an AC power source and fully charge the battery. This process with take approximately 2 hours. Do not leave the USRP E312 unit plugged in for more than 24 hours.<br />
<br />
The status LED in the power button indicates the power and charge status of the battery:<br />
<br />
Off: Indicates device is off and not charging.<br />
*Slow Blinking Green: Indicates device is off and charging.<br />
*Fast Blinking Green: Indicates device is on and charging.<br />
*Solid Green: Indicates device is on and not charging (Battery is finished charging).<br />
*Solid Orange: Indicates device is on and discharging.<br />
*Fast Blinking Orange: Indicates device is on, discharging, and charge is below 10% charge.<br />
*Fast Blinking Red: Indicates an error code:<br />
<br />
#Low Voltage Error<br />
#Regulator Low Voltage Error<br />
#FPGA Power Error<br />
#DRAM Power Error<br />
#1.8V Power Rail Error<br />
#3.3V Power Rail Error<br />
#Daughterboard / TX Power Error<br />
#Charger Error<br />
#Charger Temperature Error<br />
#Battery Low Error<br />
#Fuel Gauge Temperature Error<br />
#Global (Enclosure) Temperature Error<br />
<br />
The battery life of the USRP E312 in idle mode is approximately 5 1/2 hours. The battery will enable the USRP E312 to operate for approximately 2 hours 20 minutes, when transmitting and receiving on both channels (2x2 MIMO), with maximum gain settings, at 5 GHz center frequency, and 1 MS/s sample rate. When the power button status LED is in the “Fast Blinking Orange” mode, plug the USRP E312 into an AC power source as soon as possible to recharge the battery.<br />
<br />
If the power button status LED indicates a “Low Voltage Error” (codes 1, 2, 3, 4, 5, 6, 7) or a “Battery Low Error” (code 10), plug the USRP E312 into an AC power source as soon as possible to recharge the battery.<br />
<br />
When the power button status LED indicates at “Temperature Error” or “Charger Error” (codes 8, 9, 11, or 12), power off the USRP E312 unit and allow it to cool down to room temperature. Then, plug in the USRP E312 to and AC power source and fully charge the battery.<br />
<br />
If error codes persist after cooling down and/or recharging the USRP E312, please contact [mailto:support@ettus.com support@ettus.com].<br />
<br />
You can purchase a replacement battery for the E312 at [https://www.ettus.com/product/details/E312-battery https://www.ettus.com/product/details/E312-battery].<br />
<br />
An Application Note covering the replacement of the E312 battery can be found at [[USRP E312 Battery Replacement Instructions]].<br />
<br />
==Certifications==<br />
===RoHS===<br />
As of December 1st, 2010 all Ettus Research products are RoHS compliant unless otherwise noted. More information can be found at [http://ettus.com/legal/rohs-information http://ettus.com/legal/rohs-information]<br />
<br />
==Certificate of Volatility==<br />
===E310===<br />
* [[Media:volatility USRP E310 r1.pdf]]<br />
<br />
===E312===<br />
* [[Media:USRP E31x CoV.pdf]]<br />
<br />
==SD Card Images==<br />
<br />
The E31x SD card images can be obtained two ways:<br />
<br />
* Using uhd_images_downloader. See these instructions: https://files.ettus.com/manual/page_usrp_e3xx.html#update_sdcard<br />
* Direct download from [https://files.ettus.com/binaries/cache/e3xx/ https://files.ettus.com/binaries/cache/e3xx/]<br />
<br />
'''Note:''' Obsolete images, such as the alpha, beta, and Release 4 images, are located here: [https://files.ettus.com/e3xx_images/ https://files.ettus.com/e3xx_images/]. These release are no longer supported and provided here for archival purposes only.<br />
<br />
If choosing to directly download the SD card image, please note that they are sorted by UHD version with the format <code>meta-ettus-vUHD_VERSION</code>. For example, the UHD 4.5 release is meta-ettus-v4.5.0.0. Each release contains SD card images and the SDK (OE cross-compiler build environment) for the USRP E31x. There is a manifest file that shows which packages, and which versions, are included in the OE build within each folder.<br />
<br />
We highly recommend customers use UHD 4.5 or later. It is fine if you are already successfully using an older version, but at some point it is recommended that you upgrade to a current version so that you benefit from the latest bug fixes, new features, stability improvements, and other enhancements.<br />
<br />
The UHD 4.5+ release images include UHD 4.5 (or later), GNU Radio 3.8, Python 3, and the corresponding FPGA image file.<br />
<br />
'''Note:''' An 8 GB SD card is required for the Release 4 image.<br />
<br />
The SD card image contains both the FPGA image and the OS for the E31x. The FPGA image is located in the file system of the E31x in the <code>/usr/local/share/uhd/images</code> directory.<br />
<br />
The E31x image comes in two speed grade varieties, sg1 and sg3. The majority of USRP E31x devices use the sg3 image, but older devices may use sg1. The version that you will need depends on the product number of your E31x, which is printed on the bottom of the device.<br />
<br />
{| class="wikitable"<br />
| rowspan="2" | E310 (15633'''X'''-01L)<br />
|X= A, B, C, D<br />
|e3xx_e310_sg1<br />
|-<br />
|X= E or later<br />
|e3xx_e310_sg3<br />
|-<br />
|E312 (140605'''X'''-01L)<br />
|X = All<br />
|e3xx_e310_sg3<br />
|}<br />
<br />
For the E310, the product number will be <code>156333'''X'''-01L</code>, where X is a letter from A to Z. For devices where X is A, B, C, D, the image starting with <code>e3xx_e310_sg1</code> should be used. For devices where X is E or later, the images under the <code>e3xx_e310_sg1</code> folder should be used. You must use the appropriate image for your specific device. The incorrect image will not work, and will only boot as far as the U-Boot boot loader before stopping.<br />
<br />
For the E312, the product number will be <code>140605'''X'''-01L</code>, where X is a letter from A to Z. The image starting with <code>e3xx_e310_sg3</code> folder should be used for all E312 devices.<br />
<br />
You can burn the image to an SD card using the "<code>dd</code>" tool. Instructions on how to use this tool are located at the links below:<br />
<br />
* https://files.ettus.com/manual/page_usrp_e3xx.html#e3xx_sdcard<br />
<br />
* https://kb.ettus.com/Writing_the_USRP_File_System_Disk_Image_to_a_SD_Card<br />
<br />
The SD image files have an *.zip extension. You can uncompress these files with any zip compatible tool, such as 7-Zip. Please see the links below for further information.<br />
<br />
'''7-Zip'''<br />
* http://www.7-zip.org/<br />
* https://en.wikipedia.org/wiki/7-Zip<br />
<br />
==Security Notes==<br />
The OpenEmbedded project reported a security vulnerability for OE-Core (http://lists.openembedded.org/pipermail/openembedded-architecture/2017-June/000638.html). If you are an USRP E-Series user that is building binary ipkgs which you then distribute to your customers, you may be affected by this issue. No other workflows are impacted.<br />
<br />
The vulnerability is documented as CVE-2017-9731 (https://cve.mitre.org/cgi-bin/cvename.cgi?name=2017-9731). The specific issue is that information in the <code>SRC_URI</code> for software repositories used by OE recipes is "leaked" by binary ipkgs. For example, if you are using the E-Series OE-generated SDK to build binary ipkgs, and the <code>URI</code> you use for your source code repository contains sensitive information (e.g., <code>https://github.com/company-name/secret-project-name</code>, or <code>local-server.internal.com?USER=admin&PASSWORD=password</code>), then that information will be leaked in the <code>Source:</code> field of the <code>ipkg</code>.<br />
<br />
The OpenEmbedded team has merged a fix for this into OE-Core <code>master</code>, and backported the change to previous versions of OpenEmbedded. Generally, including sensitive information in the <code>SRC_URIs</code> is not a good idea, and we highly recommend users avoid doing this in their build process. Some recommendations provided on the OpenEmbedded discussion list:<br />
<br />
* Use non-confidential path names (i.e., don’t include confidential customer or project names in build paths).<br />
* Change or manage the host name of your build system so that it is non-confidential, like <code>build-1</code> instead of <code>secret-product.my-company.internal.com</code>.<br />
* Use a "build user" who does not have network credentials to access sensitive machines during the build process.<br />
<br />
If you have any questions about this, or need help determining if this issue affects you, please let us know by contacting [mailto:support@ettus.com support@ettus.com].<br />
<br />
==Additional Resources==<br />
* [http://www51.honeywell.com/aero/common/documents/myaerospacecatalog-documents/Defense_Brochures-documents/Magnetic__Literature_Application_notes-documents/AN203_Compass_Heading_Using_Magnetometers.pdf COMPASS HEADING USING MAGNETOMETERS]<br />
<br />
==Downloads==<br />
<br />
[http://files.ettus.com/e3xx_images/ FPGA Images]<br />
<br />
[http://files.ettus.com/e3xx_images/README FPGA Images Read Me] <br />
<br />
[http://files.ettus.com/manual/md_fpga.html FPGA Resources]<br />
<br />
[http://files.ettus.com/binaries/uhd_stable/ UHD Stable Binaries]<br />
<br />
[https://github.com/EttusResearch/uhd UHD Source Code on Github]<br />
<br />
<br />
<br />
<br />
[[Category:Hardware Resources]]</div>JonathonPendlumhttps://kb.ettus.com/index.php?title=B200/B210/B200mini/B205mini&diff=5793B200/B210/B200mini/B205mini2023-03-22T01:21:09Z<p>JonathonPendlum: Correct maximum input power</p>
<hr />
<div>== Device Overview ==<br />
The USRP Bus Series provides a fully integrated, single board, Universal Software Radio Peripheral platform with continuous frequency coverage from 70 MHz – 6 GHz. Designed for low-cost experimentation, it combines a fully integrated direct conversion transceiver providing up to 56MHz of real-time bandwidth, an open and reprogrammable Spartan6 FPGA, and fast and convenient bus-powered SuperSpeed USB 3.0 connectivity.<br />
<br />
== Key Features==<br />
=== B200===<br />
{|<br />
|style="vertical-align:top"|<br />
* Xilinx Spartan 6 XC6SLX75 FPGA<br />
* Analog Devices AD9364 RFIC direct-conversion transceiver<br />
* Frequency range: 70 MHz - 6 GHz<br />
* Up to 56 MHz of instantaneous bandwidth<br />
* Full duplex, SISO (1 Tx & 1 Rx)<br />
* Fast and convenient bus-powered USB 3.0 connectivity<br />
* Optional Board Mounted GPSDO<br />
|[[File:Product b200.png|250px|center]] <br />
|}<br />
<br />
=== B210===<br />
{|<br />
|style="vertical-align:top"|<br />
* Xilinx Spartan 6 XC6SLX150 FPGA<br />
* Analog Devices AD9361 RFIC direct-conversion transceiver<br />
* Frequency range: 70 MHz - 6 GHz<br />
* Up to 56 MHz of instantaneous bandwidth (61.44MS/s quadrature)<br />
* Full duplex, MIMO (2 Tx & 2 Rx)<br />
* Fast and convenient bus-powered USB 3.0 connectivity<br />
* Optional Board Mounted GPSDO <br />
|[[File:Product b210.png|250px|center]] <br />
|}<br />
<br />
=== B200mini===<br />
{|<br />
|style="vertical-align:top"|<br />
* Xilinx Spartan-6 XC6SLX75 FPGA<br />
* Analog Devices AD9364 RFIC direct-conversion transceiver<br />
* Frequency range: 70 MHz - 6 GHz<br />
* Up to 56 MHz of instantaneous bandwidth<br />
* Full duplex, SISO (1 Tx & 1 Rx)<br />
* Fast and convenient bus-powered USB 3.0 connectivity<br />
|[[File:Product b200 mini.png|250px|center]] <br />
|}<br />
<br />
=== B200mini-i===<br />
{|<br />
|style="vertical-align:top"|<br />
* Industrial-grade Xilinx Spartan-6 XC6SLX75 FPGA<br />
* Analog Devices AD9364 RFIC direct-conversion transceiver<br />
* Frequency range: 70 MHz - 6 GHz<br />
* Up to 56 MHz of instantaneous bandwidth<br />
* Full duplex, SISO (1 Tx & 1 Rx)<br />
* Fast and convenient bus-powered USB 3.0 connectivity<br />
|[[File:Product b200 mini i.png|250px|center]] <br />
|}<br />
<br />
=== B205mini-i===<br />
{|<br />
|style="vertical-align:top"|<br />
* Industrial-grade Xilinx Spartan-6 XC6SLX150 FPGA<br />
* Analog Devices AD9364 RFIC direct-conversion transceiver<br />
* Frequency range: 70 MHz - 6 GHz<br />
* Up to 56 MHz of instantaneous bandwidth<br />
* Full duplex, SISO (1 Tx & 1 Rx)<br />
* Fast and convenient bus-powered USB 3.0 connectivity<br />
|[[File:Product b200 mini i.png|250px|center]] <br />
|}<br />
<br />
==Frontend Specifications==<br />
===Tuning===<br />
<br />
The RF frontend has individually tunable receive and transmit chains. On the B200 and B200 mini, there is one transmit and one receive RF frontend. On the B210, both transmit and receive can be used in a MIMO configuration. For the MIMO case on the B210 only, both receive frontends share the RX LO, and both transmit frontends share the TX LO. Each LO is independently tunable between 50 MHz and 6 GHz and can be used with 1 or 2 channels; all channels using the same LO must use the same sampling parameters, including the sample rate and RF center frequency.<br />
<br />
===Gains===<br />
All frontends have individual analog gain controls. The receive frontends have 76 dB of available gain; and the transmit frontends have 89.8 dB of available gain. Gain settings are application specific, but it is recommended that users consider using at least half of the available gain to get reasonable dynamic range.<br />
<br />
===Bandwidths===<br />
The analog frontend has a seamlessly adjustable bandwidth of 200 kHz to 56 MHz.<br />
<br />
Generally, when requesting any possible master clock rate, UHD will automatically configure the analog filters to avoid any aliasing (RX) or out-of-band emissions whilst letting through the cleanest possible signal.<br />
<br />
If you, however, happen to have a very strong interferer within half the master clock rate of your RX LO frequency, you might want to reduce this analog bandwidth. You can do so by calling uhd::usrp::multi_usrp::set_rx_bandwidth(bw).<br />
<br />
The property to control the analog RX bandwidth is bandwidth/value.<br />
<br />
UHD will not allow you to set bandwidths larger than your current master clock rate.<br />
<br />
==RF Specifications==<br />
The USRP B200/B210/B200mini/B205mini are derived from the Analog devices AD936x integrated transceiver chip, the overall RF performance of the device is largely governed by the transceiver chip itself. <br />
<br />
===RF Performance===<br />
* SSB/LO Suppression -35/50 dBc<br />
* Phase Noise 3.5 GHz 1.0 deg RMS<br />
* Phase Noise 6 GHz 1.5 deg RMS<br />
* Power Output >10dBm<br />
* IIP3 (@ typ NF) -20dBm<br />
* Typical Noise Figure <8dB<br />
* Maximum Input Power: -15 dBm<br />
<br />
===Input/Output Impedance===<br />
All RF Ports are matched to 50 Ohm with -10dB or better return loss generally. Detailed test is pending.<br />
<br />
===Input Power Levels===<br />
* The maximum input power for the B200/B210/B200mini/B205mini is 0 dBm.<br />
<br />
===RF Performance Data===<br />
====B200mini / B205mini====<br />
* [[Media:B200mini B205 RF Performance Data 20160119.pdf]]<br />
<br />
====B200 / B210====<br />
* [[Media:B200 RF Performance.pdf]]<br />
<br />
==Hardware Specifications==<br />
* Ettus Research recommends to always use the latest stable version of UHD<br />
<br />
=== B200===<br />
* Current Hardware Revision: 6<br />
* Minimum version of UHD required: 3.8.4<br />
* B200 Rev 5 (AD9364-based board) requires minimum UHD 3.8.4<br />
<br />
=== B210===<br />
* Current Hardware Revision: 5<br />
* Minimum version of UHD required: 3.6.0<br />
<br />
=== B200mini===<br />
* Current Hardware Revision: 2<br />
* Minimum version of UHD required: 3.9.0<br />
<br />
=== B200mini-i===<br />
* Current Hardware Revision: 2<br />
* Minimum version of UHD required: 3.9.0<br />
<br />
=== B205mini-i===<br />
* Current Hardware Revision: 1<br />
* Minimum version of UHD required: 3.9.2<br />
<br />
==Physical Specifications==<br />
===Dimensions===<br />
* B200mini/B205mini 5.0 x 8.4 cm<br />
* B200/B210 9.7 x 15.5 x 1.5 cm<br />
<br />
===Weight===<br />
* B200mini 24.0 g<br />
* B200/B210 350 g<br />
<br />
===Drawings===<br />
====B200mini====<br />
* [[Media:B200mini_drawing.png| Board only]]<br />
* [[Media:cu usrp-b200mini.pdf| B20xmini Enclosure]]<br />
<br />
====B200====<br />
* [[Media:cu ettus b200 cca.pdf| Board only]]<br />
<br />
====B210====<br />
* [[Media:cu ettus b210 cca.pdf| Board only]]<br />
<br />
====B200/B210 Enclosure====<br />
* [[Media:cu ettus-b2xx-full-enclosure.pdf|Enclosure]]<br />
<br />
===CAD/STP Models===<br />
====B200mini====<br />
* [[Media:B200mini.stp.tar.gz| B200mini with Enclosure]]<br />
* [[Media:B200mini enclosure-only.stp.tar.gz| Enclosure only]]<br />
* [[Media:cu ettus b200mini cca.stp.tar.gz| Board only ]]<br />
<br />
====B20xmini-i====<br />
* [[Media:b20xmini-i._thermal_insert.stp.tar.gz| B20xmini-i Thermal Insert]]<br />
<br />
====B200====<br />
* [[Media:cu ettus b200 cca.stp.tar.gz| Board only]]<br />
<br />
====B210====<br />
* [[Media:cu ettus b210 cca.stp.gz| Board only]]<br />
<br />
====B200/B210 Enclosure====<br />
* [[Media:cu ettus-b200-b210-case.zip|Enclosure]]<br />
<br />
==Environmental Specifications==<br />
===Operating Temperature Range===<br />
* B200 / B210: 25 °C<br />
* B200mini - Board Only: 0 - 40 °C <br />
* B200mini - With Enclosure: -20 - 60°C <br />
* B200mini-i / B205mini-i - Board Only: 0 - 45 °C <br />
* B200mini-i / B205mini-i - With I-Grade Enclosure: -40 - 75°C<br />
<br />
===Operating Humidity Range===<br />
* 10% to 90% non-condensing<br />
<br />
==Schematics==<br />
===B200mini/B200mini-i/B205mini-i===<br />
[http://files.ettus.com/schematics/b200mini/b200mini.pdf B200mini/B200mini-i/B205mini-i Schematics]<br />
<br />
===B200/B210===<br />
[http://files.ettus.com/schematics/b200/b210.pdf B200/B210 Schematics]<br />
<br />
==Key Component Datasheets==<br />
{| class="wikitable" style="width:80%"<br />
!Part Number<br />
!Description<br />
!Schematic ID (Page)<br />
<br />
|-<br />
|[https://www.minicircuits.com/pdfs/TCM1-63AX+.pdf Mini-Circuits TCM1-63AX+]<br />
|Transformer<br />
|T1 (1,3); T2 (1,3)<br />
|-<br />
<br />
|-<br />
|[http://www.analog.com/en/products/rf-microwave/integrated-transceivers-transmitters-receivers/wideband-transceivers-ic/ad9364.html#product-overview Analog Devices AD9364]<br />
|RF Transceiver<br />
|U1 (2)<br />
|-<br />
|[http://www.analog.com/en/products/rf-microwave/integrated-transceivers-transmitters-receivers/wideband-transceivers-ic/ad9361.html#product-overview Analog Devices AD9361]<br />
|RF Transceiver<br />
|U2 (2,8)<br />
|-<br />
<br />
|[http://www.analog.com/en/design-center/landing-pages/001/ad9361-ad9364-integ-rf-agile-transceiver-design-res.html AD9361/AD9364 Product Page]<br />
|RF Transceiver<br />
| - <br />
|-<br />
|[http://www.xilinx.com/products/silicon-devices/fpga/spartan-6.html Xilinx Spartan-6 Product Page]<br />
|FPGA<br />
|rowspan="2"|U1 (2,3,4,6); PG1 (6); U18B, U18C (7); U18D (8); U18E, U18F (9); U18G, U18H (10)<br />
|-<br />
|[http://www.xilinx.com/support/documentation/data_sheets/ds160.pdf XC6SLX75 / XC6SLX150]<br />
|FPGA<br />
|-<br />
|[http://www.analog.com/media/en/technical-documentation/data-sheets/ADF4001.pdf ADF4001]<br />
|Frequency Synthesizer<br />
|U101 (1)<br />
|-<br />
<br />
|[http://www.cypress.com/file/140296/download CYUSB3014]<br />
|rowspan="2"|FX3: SuperSpeed USB Controller<br />
|rowspan="2"|U3 (5,6); U13 (5)<br />
|-<br />
<br />
|[http://www.cypress.com/applications/ez-usb-fx3-superspeed-usb-30-peripheral-controller-collateral-guide EZ-USB FX3™ Product Page]<br />
|-<br />
<br />
|[http://www.skyworksinc.com/uploads/documents/SKY13317_373LF_200914K.pdf SKY13317]<br />
|Antenna Switch<br />
|U801, U810 (8)<br />
|-<br />
|[http://www.anaren.com/sites/default/files/BD3150L50100A00%20Data%20sheet%20Rev%20C.pdf BD3150L50100A00]<br />
|Balun<br />
|U802, U808, U809, U815 (8)<br />
|-<br />
|[https://www.minicircuits.com/pdfs/PGA-102+.pdf PGA−102+]<br />
|Amplifier<br />
|U804, U817 (8)<br />
|-<br />
<br />
<br />
|[http://www.ctscorp.com/wp-content/uploads/2015/11/008-0371-0.pdf VCTCXO]<br />
|VCTCXO (B200mini only)<br />
| -<br />
|-<br />
<br />
|[https://www.ctscorp.com/wp-content/uploads/2015/11/008-0334-0.pdf 525L20DA40M0000]<br />
|VCTCXO (B200/B210 only)<br />
| X100 (1)<br />
|-<br />
<br />
|[http://www.jackson-labs.com/index.php/products/lc_xo Jackson Labs LC_XO] [http://www.jackson-labs.com/assets/uploads/main/LC_XO_specsheet.pdf Spec Sheet] [http://www.jackson-labs.com/assets/uploads/main/LC_XO_Manual.pdf Manual]<br />
|Optional GPSDO (B200/B210 only)<br />
|U100 (1)<br />
|-<br />
|}<br />
<br />
==Enclosures==<br />
<br />
* SMA connectors should be torqued to 4 inch-pounds<br />
<br />
===B200mini===<br />
* [https://www.ettus.com/all-products/usrp-b200mini-enclosure/ B200mini C-Grade Enclosure]<br />
* [https://www.ettus.com/all-products/usrp-b200mini-i-enclosure/ B200mini I-Grade Enclosure]<br />
<br />
===B205mini===<br />
* [https://www.ettus.com/all-products/usrp-b205mini-i-enclosure/ B205mini I-Grade Enclosure]<br />
<br />
===B200/B210===<br />
* [https://www.ettus.com/product/details/USRP-B200-Enclosure USRP B200/B210 Enclosure]<br />
** Full Steel Enclosure<br />
** Compatible with green USRP B200 and B210 devices (revision 6 or later)<br />
** Front and rear K-Slots for anti-theft protection<br />
<br />
==FPGA==<br />
* Utilization statistics are subject to change between UHD releases. This information is current as of UHD 3.9.4.<br />
===B200===<br />
<pre><br />
Device utilization summary:<br />
---------------------------<br />
<br />
Selected Device : 6slx75fgg484-3<br />
<br />
<br />
Slice Logic Utilization:<br />
Number of Slice Registers: 15781 out of 93296 16%<br />
Number of Slice LUTs: 19987 out of 46648 42%<br />
Number used as Logic: 15983 out of 46648 34%<br />
Number used as Memory: 4004 out of 11072 36%<br />
Number used as RAM: 972<br />
Number used as SRL: 3032<br />
<br />
Slice Logic Distribution:<br />
Number of LUT Flip Flop pairs used: 24062<br />
Number with an unused Flip Flop: 8281 out of 24062 34%<br />
Number with an unused LUT: 4075 out of 24062 16%<br />
Number of fully used LUT-FF pairs: 11706 out of 24062 48%<br />
Number of unique control sets: 434<br />
<br />
IO Utilization:<br />
Number of IOs: 172<br />
Number of bonded IOBs: 155 out of 280 55%<br />
IOB Flip Flops/Latches: 124<br />
<br />
Specific Feature Utilization:<br />
Number of Block RAM/FIFO: 144 out of 172 83%<br />
Number using Block RAM only: 144<br />
Number of BUFG/BUFGCTRLs: 4 out of 16 25%<br />
Number of DSP48A1s: 76 out of 132 57%<br />
</pre><br />
<br />
===B210===<br />
<pre><br />
Device utilization summary:<br />
---------------------------<br />
<br />
Selected Device : 6slx150fgg484-3<br />
<br />
<br />
Slice Logic Utilization:<br />
Number of Slice Registers: 29310 out of 184304 15%<br />
Number of Slice LUTs: 36486 out of 92152 39%<br />
Number used as Logic: 29279 out of 92152 31%<br />
Number used as Memory: 7207 out of 21680 33%<br />
Number used as RAM: 1752<br />
Number used as SRL: 5455<br />
<br />
Slice Logic Distribution:<br />
Number of LUT Flip Flop pairs used: 43635<br />
Number with an unused Flip Flop: 14325 out of 43635 32%<br />
Number with an unused LUT: 7149 out of 43635 16%<br />
Number of fully used LUT-FF pairs: 22161 out of 43635 50%<br />
Number of unique control sets: 723<br />
<br />
IO Utilization:<br />
Number of IOs: 180<br />
Number of bonded IOBs: 163 out of 338 48%<br />
IOB Flip Flops/Latches: 148<br />
<br />
Specific Feature Utilization:<br />
Number of Block RAM/FIFO: 186 out of 268 69%<br />
Number using Block RAM only: 186<br />
Number of BUFG/BUFGCTRLs: 4 out of 16 25%<br />
Number of DSP48A1s: 152 out of 180 84%<br />
</pre><br />
<br />
===B200mini===<br />
<pre><br />
Device utilization summary:<br />
---------------------------<br />
<br />
Selected Device : 6slx75csg484-3<br />
<br />
<br />
Slice Logic Utilization:<br />
Number of Slice Registers: 15949 out of 93296 17%<br />
Number of Slice LUTs: 19963 out of 46648 42%<br />
Number used as Logic: 16140 out of 46648 34%<br />
Number used as Memory: 3823 out of 11072 34%<br />
Number used as RAM: 972<br />
Number used as SRL: 2851<br />
<br />
Slice Logic Distribution:<br />
Number of LUT Flip Flop pairs used: 23859<br />
Number with an unused Flip Flop: 7910 out of 23859 33%<br />
Number with an unused LUT: 3896 out of 23859 16%<br />
Number of fully used LUT-FF pairs: 12053 out of 23859 50%<br />
Number of unique control sets: 429<br />
<br />
IO Utilization:<br />
Number of IOs: 123<br />
Number of bonded IOBs: 114 out of 328 34%<br />
IOB Flip Flops/Latches: 147<br />
<br />
Specific Feature Utilization:<br />
Number of Block RAM/FIFO: 110 out of 172 63%<br />
Number using Block RAM only: 110<br />
Number of BUFG/BUFGCTRLs: 6 out of 16 37%<br />
Number of DSP48A1s: 76 out of 132 57%<br />
Number of PLL_ADVs: 1 out of 6 16%<br />
</pre><br />
<br />
===B205mini===<br />
<pre><br />
Device utilization summary:<br />
---------------------------<br />
<br />
Selected Device : 6slx150csg484-3<br />
<br />
<br />
Slice Logic Utilization:<br />
Number of Slice Registers: 15949 out of 184304 8%<br />
Number of Slice LUTs: 19963 out of 92152 21%<br />
Number used as Logic: 16140 out of 92152 17%<br />
Number used as Memory: 3823 out of 21680 17%<br />
Number used as RAM: 972<br />
Number used as SRL: 2851<br />
<br />
Slice Logic Distribution:<br />
Number of LUT Flip Flop pairs used: 23859<br />
Number with an unused Flip Flop: 7910 out of 23859 33%<br />
Number with an unused LUT: 3896 out of 23859 16%<br />
Number of fully used LUT-FF pairs: 12053 out of 23859 50%<br />
Number of unique control sets: 429<br />
<br />
IO Utilization:<br />
Number of IOs: 123<br />
Number of bonded IOBs: 114 out of 338 33%<br />
IOB Flip Flops/Latches: 147<br />
<br />
Specific Feature Utilization:<br />
Number of Block RAM/FIFO: 110 out of 268 41%<br />
Number using Block RAM only: 110<br />
Number of BUFG/BUFGCTRLs: 6 out of 16 37%<br />
Number of DSP48A1s: 76 out of 180 42%<br />
Number of PLL_ADVs: 1 out of 6 16%<br />
</pre><br />
<br />
==Interfaces and Connectivity==<br />
B200/B210/B200mini - USB 3.0<br />
<br />
===GPIO===<br />
====Power on state====<br />
The hardware power on state and UHD initial state for the front-panel GPIOs is high-Z. For the B2xx, B2xxmini there are no external pull-ups/pull-downs for the GPIO pins, but the FPGAs do have them and they are configured as follows: B2xx: pull-up, B2xxmini: pull-up.<br />
<br />
====Output Current====<br />
The GPIOs are configured as LVCMOS33 outputs with pull-ups on the B2xx. The strength for LVCMOS and LVTTL on Spartan 6 is 12 mA if not otherwise specified.<br />
<br />
===Timing Reference Input===<br />
====B200mini/B200mini-i/B205mini-i====<br />
* 1-PPS or 10 MHz input<br />
<br />
=====1-PPS=====<br />
* Maximum: -5V / +5V<br />
* Minimum: 0V / +2.5V<br />
<br />
=====10 MHz=====<br />
* Maximum: 0V / +5V<br />
* Minimum: 0V / +1.8V<br />
'''OR'''<br />
* +10dBm ~ +27dBm<br />
<br />
====B200/B210====<br />
=====1-PPS=====<br />
* Maximum: 5V<br />
=====10 MHz=====<br />
* Maximum: 15dBm (3.5Vpp into 50 ohms)<br />
<br />
==Certifications==<br />
===RoHS===<br />
As of December 1st, 2010 all Ettus Research products are RoHS compliant unless otherwise noted. More information can be found at [http://ettus.com/legal/rohs-information http://ettus.com/legal/rohs-information]<br />
<br />
===China RoHS=== <br />
'''Management Methods for Controlling Pollution Caused by Electronic Information Products Regulation'''<br />
<br />
'''Chinese Customers''' <br />
<br />
National Instruments is in compliance with the Chinese policy on the Restriction of Hazardous Substances (RoHS) used in Electronic Information Products. For more information about the National Instruments China RoHS compliance, visit [http://www.ni.com/environment/rohs_china ni.com/environment/rohs_china].<br />
<br />
===Certifications for European Union===<br />
In order to ensure compliance with EU certifications for radio equipment, a ferrite bead (included in kits with NI part number 785825-01 and 785826-01) should be affixed onto the GPIO cable, if in use. This is achieved by opening the snap-on ferrite bead and enclosing it around the GPIO cable(s).<br />
<br />
In addition to the part numbers listed above, these ferrite beads can be sourced through Fair-Rite using part number 0443164251.<br />
<br />
==Certificate of Volatility==<br />
===B200/B210===<br />
* [[Media:volatility USRP B200 B210 r1.pdf]]<br />
<br />
==Downloads==<br />
<br />
[http://files.ettus.com/manual/md_fpga.html FPGA Resources]<br />
<br />
[http://files.ettus.com/binaries/uhd_stable/ UHD Stable Binaries]<br />
<br />
[https://github.com/EttusResearch/uhd UHD Source Code on Github]<br />
<br />
==FAQ==<br />
This is a list of frequently asked questions on the USRP [https://www.ettus.com/product/details/UB200-KIT B200]/[https://www.ettus.com/product/details/UB210-KIT B210]/[https://www.ettus.com/product/details/USRP-B200mini B200mini]. If you have questions that are not answered in this document, please contact us - [mailto:info@ettus.com info@ettus.com].<br />
<br />
'''Will the USRP [https://www.ettus.com/product/details/UB200-KIT B200]/[https://www.ettus.com/product/details/UB210-KIT B210] work with USB 2.0?'''<br />
<br />
Yes, both the USRP B200 and USRP B210 will fall back to the USB 2.0 standard if a USB 3.0 port is not available. There are several things to consider. First, the USB 2.0 data rates are slower. Depending on the USB controller, operating system, and other factors, you may achieve a sample rate up to 8 MS/s with USB 2.0. Also, you may not be able to bus-power the USRP B200/B210 in USB 2.0 mode.<br />
<br />
<br />
'''What samples rates should I expect with USB 3.0? USB 2.0?'''<br />
<br />
The performance and throughput of USB 3.0 can vary between host controllers. Ettus Research recommends using the Intel Series 7, 8, and 9 USB controllers. In Linux, the command <code>lspci</code> will show the USB controller on the system.<br />
<br />
<br />
'''When can I power the USRP B200/B210/B200mini off USB?'''<br />
<br />
The experience will vary across various controllers. Generally speaking, bus-power is ideal for SISO operation. If you are using both channels of a USRP B210 we recommend an external power supply. We [https://www.ettus.com/all-products/powersupply/ sell an external power supply that works with a variety of USRPs].<br />
<br />
MIMO operation with the USRP B210 is not recommended when using the USRP B210 on bus-power. It is also not recommended to run the B210 on bus-power if a GPS-disciplined oscillator is installed.<br />
<br />
'''How much power does the USRP consume?'''<br />
<br />
The table below shows power consumption (Watts) of a USRP B210 run with a 6V power supply. Figures on a 5V supply (USB power), or with a USRP B200 will be moderately lower. The sample rates shown are aggregate sample rates on the USB 3.0 interface.<br />
<br />
{| class="wikitable"<br />
!<br />
!5 Msps<br />
!15.36 Msps<br />
!30.72 Msps<br />
!56 Msps<br />
!61.44 Msps<br />
|-<br />
|1 RX<br />
|1.92<br />
|2.112<br />
|2.184<br />
|2.508<br />
|<br />
|-<br />
|2 RX<br />
|2.148<br />
|2.436<br />
|2.508<br />
|2.64<br />
|<br />
|-<br />
|1 TX<br />
|2.184<br />
|2.34<br />
|2.352<br />
|2.22<br />
|<br />
|-<br />
|2 TX<br />
|2.76<br />
|2.88<br />
|2.904<br />
|2.64<br />
|<br />
|-<br />
|Full Duplex (1x1)<br />
|2.508<br />
|2.736<br />
|2.796<br />
|3.168<br />
|<br />
|-<br />
|2x2 MIMO<br />
|3.252<br />
|3.588<br />
|3.672<br />
|4.11<br />
|4.092<br />
|-<br />
|}<br />
<br />
<br />
'''Can I build a multi-unit system with the USRP B200/B210?'''<br />
<br />
It is possible to synchronize multiple USRP B200/B210 devices using the 10 MHz/1 PPS inputs and an external distribution system like to the OctoClock-G. However, [http://www.ettus.com/kb/detail/usrp-b200-and-b210-usb-30-streaming-rate-benchmarks USB 3.0/2.0 performance] varies dramatically when multiple devices are streaming through the same controller. Generally, we recommend using the USRP N200/N210 if you need to build a high-channel count system.<br />
<br />
<br />
'''Can I access the source code for the USRP B200/B210?'''<br />
<br />
Yes. The USRP B200/B210 is supported by the USRP Hardware DriverTM software. You can find the driver and FPGA source code for the USRP B200/B210, and all other USRP models, in the UHD git repository:<br />
<br />
http://files.ettus.com/manual/page_build_guide.html<br />
<br />
<br />
'''What operating systems does the USRP B200/B210 work on?'''<br />
<br />
The USRP B200/B210 is supported on [http://files.ettus.com/manual/page_install.html Linux, OSX (MacOSX / macOS) and Windows].<br />
<br />
<br />
'''Does the USRP B200/B210 work with GNU Radio?'''<br />
<br />
Yes. The USRP B200/B210 work with our GNU Radio plugin - gr-uhd.<br />
<br />
<br />
'''Does the USRP B200/B210 work with MATLAB and Simulink?'''<br />
<br />
Yes. You need to install the [http://www.mathworks.com/hardware-support/usrp.html Communications System Toolbox Support Package for USRP Radio].<br />
<br />
<br />
'''Does the USRP B200/B210 work with OpenBTS?'''<br />
<br />
Yes. This is a third-party application and you can find instructions here: [http://wush.net/trac/rangepublic/wiki/BuildInstallRun OpenBTS - Build, Install, Run.]<br />
<br />
For support, please sign up and contact the [https://lists.sourceforge.net/lists/listinfo/openbts-discuss OpenBTS mailing list].<br />
<br />
<br />
'''What tools do I need to program the FPGA?'''<br />
<br />
The USRP [https://www.ettus.com/product/details/UB200-KIT B200] and USRP [https://www.ettus.com/product/details/UB210-KIT B210] include a Spartan 6 XC6SLX75 and XC6S150, respectively. The USRP B200 can be programmed with the free version of Xilinx tools, while the larger FPGA on the USRP B210 requires a licensed seat.<br />
<br />
<br />
'''Can I use a GPSDO with the USRP B200/B210?'''<br />
<br />
Ettus Research offers a [https://www.ettus.com/product/details/GPSDO-MINI Board-Mounted GPS-Disciplined OCXO] and a [https://www.ettus.com/product/details/GPSDO-TCXO-MODULE Board-Mounted GPS-Disciplined TCXO], which are compatible with the USRP B200/B210. These provide a high-accuracy XO, which can be disciplined to the global GPS standard. Please note: When the GPSDO OCXO model is integrated on the USRP B200/B210, the device should be powered with an external supply instead of USB bus power. The TCXO version can be USB bus powered.<br />
<br />
<br />
<br />
<br />
[[Category:Hardware Resources]]</div>JonathonPendlumhttps://kb.ettus.com/index.php?title=B200/B210/B200mini/B205mini_Getting_Started_Guides&diff=5413B200/B210/B200mini/B205mini Getting Started Guides2022-05-20T22:08:46Z<p>JonathonPendlum: Correct wrong RX max input power</p>
<hr />
<div>==Kit Contents==<br />
* USRP B200 / B210 / B200mini / B205mini<br />
* USB 3.0 Cable<br />
* Universal power supply (B210 only)<br />
<br />
{|<br />
|style="vertical-align:top"|<br />
||[[File:Product b200.png|250px|center]] <br />
||[[File:Product b210.png|250px|center]] <br />
||[[File:Product b200 mini.png|250px|center]] <br />
|}<br />
<br />
==Verify the Contents of Your Kit==<br />
Make sure that your kit contains all the items listed above. If any items are missing, please contact your sales agent or Ettus Research Technical support immediately.<br />
<br />
==You Will Need==<br />
* A host computer with an available USB 2.0 or 3.0 port<br />
<br />
==Proper Care and Handling==<br />
All Ettus Research products are individually tested before shipment. The USRP™ is guaranteed to be functional at the time it is received by the customer. Improper use or handling of the USRP™ can easily cause the device to become non-functional. Listed below are some examples of actions which can prevent damage to the unit:<br />
<br />
*Never allow metal objects to touch the circuit board while powered.<br />
*Always properly terminate the transmit port with an antenna or 50Ω load.<br />
*Always handle the board with proper anti-static methods.<br />
*Never allow the board to directly or indirectly come into contact with any voltage spikes.<br />
*Never allow any water, or condensing moisture, to come into contact with the boards.<br />
*Always use caution with FPGA, firmware, or software modifications.<br />
{|<br />
|style="padding-left:10px; padding-right:10px; padding-bottom:10px;" |[[File:Caution.png|24px|center]]<br />
|style="padding-left:10px; padding-right:10px; padding-bottom:10px;" |Never apply more than -15 dBm of power into any RF input.<br />
|-<br />
|style="padding-left:10px; padding-right:10px; padding-bottom:10px;" |[[File:Caution.png|24px|center]]<br />
|style="padding-left:10px; padding-right:10px; padding-bottom:10px;" |Always use at least 30dB attenuation if operating in loopback configuration<br />
|-<br />
|}<br />
<br />
==Install and Setup the Software Tools on Your Host Computer==<br />
In order to use your Universal Software Radio Peripheral (USRP™), you must have the software tools correctly installed and configured on your host computer. A step-by-step guide for doing this is available at the Building and Installing the USRP Open-Source Toolchain (UHD and GNU Radio) on [[Building and Installing the USRP Open-Source Toolchain (UHD and GNU Radio) on Linux|Linux]], [[Building and Installing the USRP Open-Source Toolchain (UHD and GNU Radio) on OS X|OS X]] and [[Building and Installing the USRP Open Source Toolchain (UHD and GNU Radio) on Windows|Windows]] Application Notes. Release 3.8.4 or later of the USRP Hardware Driver, UHD, is required. It is recommended to use the latest stable version of UHD that is available. <br />
<br />
If you have a USB stick with the [[Live SDR Environment]] installed on it, then you may boot your host computer from that. The LiveUSB SDR Environment does not require anything to be installed on your host computer, and contains a Linux-based environment with the UHD software and the GNU Radio framework already installed. More information about the [[Live SDR Environment]] is available at the [[Live SDR Environment Getting Started Guides]] page.<br />
<br />
==Connect the USRP to the Host Computer==<br />
The included USB 3.0 cable provides power and data connectivity for the USRP Bus Series. The host-side of the cable must be plugged into either a USB 2.0 or 3.0 port. Note that the USB 2.0 link provides less bandwidth than the USB 3.0 link. Also note that an external DC power supply must be connected if using a GPSDO (B200/B210 only).<br />
<br />
==Test and Verify the Operation of the USRP==<br />
Once the software tools are installed on the host computer, or using the [[Live SDR Environment]], verify the correct operation of the USRP by running the utility programs on the host computer. More information is available at the [[Verifying the Operation of the USRP Using UHD and GNU Radio]] Application Note.<br />
<br />
==Technical Support and Community Knowledge Base==<br />
Technical support for USRP hardware is available through email only. If the product arrived in a nonfunctional state or you require technical assistance, please contact [mailto:support@ettus.com support@ettus.com]. Please allow 24 to 48 hours for response by email, depending on holidays and weekends, although we are often able to reply more quickly than that.<br />
<br />
We also recommend that you subscribe to the community mailing lists. The mailing lists have a responsive and knowledgeable community of hundreds of developers and technical users who are located around the world. When you join the community, you will be connected to this group of people who can help you learn about SDR and respond to your technical and specific questions. Often your question can be answered quickly on the mailing lists. Each mailing list also provides an archive of all past conversations and discussions going back many years. Your question or problem may have already been addressed before, and a relevant or helpful solution may already exist in the archive.<br />
<br />
Discussions involving the USRP hardware and the UHD software itself are best addressed through the '''usrp-users''' mailing list at [http://usrp-users.ettus.com http://usrp-users.ettus.com].<br />
<br />
Discussions involving the use of [http://gnuradio.org/ GNU Radio] with USRP hardware and UHD software are best addressed through the '''discuss-gnuradio''' mailing list at [https://lists.gnu.org/mailman/listinfo/discussgnuradio https://lists.gnu.org/mailman/listinfo/discussgnuradio].<br />
<br />
Discussions involving the use of [http://openbts.org/ OpenBTS®] with USRP hardware and UHD software are best addressed through the '''openbts-discuss''' mailing list at [https://lists.sourceforge.net/lists/listinfo/openbtsdiscuss https://lists.sourceforge.net/lists/listinfo/openbtsdiscuss].<br />
<br />
The support page on our website is located at [https://www.ettus.com/support https://www.ettus.com/support]. The Knowledge Base is located at [https://kb.ettus.com https://kb.ettus.com].<br />
<br />
==Legal Considerations==<br />
Every country has laws governing the transmission and reception of radio signals. Users are solely responsible for insuring they use their USRP system in compliance with all applicable laws and regulations. Before attempting to transmit and/or receive on any frequency, we recommend that you determine what licenses may be required and what restrictions may apply.<br />
<br />
*NOTE: This USRP product is a piece of test equipment.<br />
<br />
==Sales and Ordering Support==<br />
If you have any non-technical questions related to your order, then please contact us by email at [mailto:orders@ettus.com orders@ettus.com], or by phone at +14086106399 (Monday-Friday, 8 AM - 5 PM, Pacific Time). Please be sure to include your order number and the serial number of your USRP.<br />
<br />
==Terms and Conditions of Sale==<br />
Terms and conditions of sale can be accessed online at the following link: http://www.ettus.com/legal/terms-and-conditions-of-sale<br />
<br />
[[Category:Getting Started Guides]]</div>JonathonPendlumhttps://kb.ettus.com/index.php?title=RFNoC_4_Migration_Guide&diff=5284RFNoC 4 Migration Guide2022-02-16T19:32:39Z<p>JonathonPendlum: Updates for UHD 4.1 and fixing typos</p>
<hr />
<div>=Abstract=<br />
<br />
The UHD 4.0 release includes a major upgrade to the RFNoC framework called RFNoC 4. This article is a guide to aid users in migrating their existing RFNoC blocks from RFNoC 3 to RFNoC 4. The RFNoC Block Development Environment section provides guidance on how to setup an environment for developing out-of-tree RFNoC blocks in RFNoC 4. The UHD, FPGA, GNU Radio Migration sections provide general information on topics that most users will encounter when migrating their blocks. Finally, an equivalent RFNoC 3 and RFNoC 4 implementation of a digital gain RFNoC Block has been provided as a reference.<br />
<br />
=Prerequisites=<br />
<br />
===Dependencies (Ubuntu 20.04)===<br />
sudo apt-get install autoconf automake build-essential ccache cmake cpufrequtils doxygen ethtool \<br />
g++ git inetutils-tools libboost-all-dev libncurses5 libncurses5-dev libusb-1.0-0 libusb-1.0-0-dev \<br />
libusb-dev python3-dev python3-mako python3-numpy python3-requests python3-scipy python3-setuptools \<br />
python3-ruamel.yaml libtinfo5 libncurses5<br />
<br />
===Vivado 2019.1 Design Edition===<br />
<br />
Please reference to Xilinx (xilinx.com) for installation instructions.<br />
<br />
''Note: The dependencies step above included installing libtinfo5 libncurses5, which is a workaround for getting Vivado 2019.1 to run on Ubuntu 20.04''<br />
<br />
===UHD 4.1===<br />
git clone --branch UHD-4.1 https://github.com/ettusresearch/uhd.git uhd<br />
mkdir uhd/host/build; cd uhd/host/build<br />
cmake ..<br />
make<br />
sudo make install<br />
<br />
===GNU Radio 3.8===<br />
'' Note: If your design does not use GNU Radio, then installing GNU Radio and gr-ettus is not required ''<br />
<br />
git clone --branch maint-3.8 --recursive https://github.com/gnuradio/gnuradio.git gnuradio<br />
mkdir gnuradio/build; cd gnuradio/build;<br />
cmake ..<br />
make<br />
sudo make install<br />
<br />
Please refer to the [https://wiki.gnuradio.org/index.php/UbuntuInstall GNU Radio Build Instructions] for dependencies and a more detailed description.<br />
<br />
===gr-ettus===<br />
git clone --branch maint-3.8-uhd4.0 https://github.com/ettusresearch/gr-ettus.git gr-ettus<br />
mkdir gr-ettus/build; cd gr-ettus/build;<br />
cmake -DENABLE_QT=True ..<br />
make<br />
sudo make install<br />
<br />
=RFNoC Block Development Environment=<br />
<br />
Two options exist for developing RFNoC blocks depending on whether the your RFNoC block integrates with GNU Radio in an out-of-tree module or if it only uses UHD’s C++ API in a standalone application. The sections below outline how to setup the development environment for each scenario.<br />
<br />
===Migrating a GNU Radio Out-of-Tree Module===<br />
<br />
The tool rfnocmodtool automates the process of creating GNU Radio out-of-tree (OOT) modules that also have support for RFNoC blocks. This tool is part of gr-ettus and it has been ported to RFNoC 4.<br />
<br />
Due to changes in almost every source file, it is recommended to use rfnocmodtool to generate a new RFNoC block from scratch and then update the generated “skeleton” files.<br />
<br />
====Creating a RFNoC Block with rfnocmodtool====<br />
<br />
The following steps show how to create an OOT module called ''example'' and RFNoC block called ''gain'' using rfnocmodtool. The naming is only for example purposes.<br />
<br />
rfnocmodtool newmod<br />
Name of the new module: '''example'''<br />
<br />
cd rfnoc-tutorial<br />
rfnocmodtool add<br />
Enter name of block/code (without module name prefix): '''gain'''<br />
Enter valid argument list, including default arguments: ''(leave blank)''<br />
Add Python QA code? [y/N] '''N'''<br />
Add C++ QA code? [y/N] '''N'''<br />
Block NoC ID (Hexadecimal): ''(Enter Noc ID of your block)''<br />
Skip Block Controllers Generation? [UHD block ctrl files] [y/N] '''N'''<br />
Skip Block interface files Generation? [GRC block ctrl files] [y/N] '''N'''<br />
<br />
''Note: Noc IDs have been reduced from 64-bits in RFNoC 3 to 32-bits in RFNoC 4''<br />
<br />
The following are the relevant files that need to be updated when migrating your RFNoC Block.<br />
<br />
rfnoc-example/<br />
grc/<br />
example_gain.block.yml – RFNoC Block GNU Radio Companion YAML file<br />
examples/<br />
gain.grc – Example flowgraph using gain RFNoC Block<br />
include/tutorial/<br />
gain.h – GNU Radio block C++ header<br />
gain_block_ctrl.hpp – RFNoC Block Controller C++ header<br />
lib/<br />
gain_impl.cc – GNU Radio block C++ source<br />
gain_impl.h – GNU Radio block C++ header<br />
gain_block_ctrl_impl.cpp – RFNoC Block Controller C++ source<br />
rfnoc/blocks/<br />
gain.yml – RFNoC Block Description YAML file<br />
rfnoc/fpga/rfnoc_block_gain<br />
noc_shell_gain.v – RFNoC Block Noc Shell Verilog Source<br />
rfnoc_block_gain.v – RFNoC Block Verilog Source<br />
rfnoc_block_gain_tb.v – RFNoC Block Testbench<br />
rfnoc/icores<br />
gain_x310_rfnoc_image_core.yml – Image Core YAML file with gain block<br />
<br />
====Building OOT module====<br />
<br />
cd rfnoc-tutorial<br />
mkdir build; cd build<br />
cmake -DUHD_FPGA_DIR=''(path to uhd/fpga directory)'' ..<br />
make<br />
sudo make install<br />
<br />
====Running a testbench====<br />
CMake automatically creates makefile targets to run the generated testbench code for each added RFNoC block. For example, here is how to run the gain block testbench:<br />
<br />
cd rfnoc-tutorial/build<br />
make rfnoc_block_gain_tb<br />
<br />
====Building a FPGA image====<br />
CMake automatically creates makefile targets to build FPGA images using the generated image core yaml files found in rfnoc/icore. Every RFNoC block created by rfnocmodtool automatically has an image core yaml file generated in that directory. For example, here is how to build an FPGA image using the image core yaml file generated for the gain block:<br />
<br />
cd rfnoc-tutorial/build<br />
make gain_x310_rfnoc_image_core<br />
<br />
===Migrating a Standalone UHD C++ Application===<br />
<br />
For applications that only use the UHD API, an example out-of-tree (UHD source tree) RFNoC block exists called rfnoc-example. It is located in the UHD source at uhd/host/examples/rfnoc-example. This directory can be copied outside of the UHD source tree and used a starting point to migrate your RFNoC block.<br />
<br />
The following are the relevant files that need to be updated when migrating your RFNoC Block.<br />
<br />
rfnoc-example/<br />
apps/<br />
init_gain_block.cpp – Example C++ application testing gain block<br />
blocks/<br />
gain.yml – RFNoC Block Description YAML file<br />
fpga/rfnoc_block_gain<br />
noc_shell_gain.v – RFNoC Block Noc Shell Verilog Source<br />
rfnoc_block_gain.v – RFNoC Block Verilog Source<br />
rfnoc_block_gain_tb.v – RFNoC Block Testbench<br />
icores/<br />
x310_rfnoc_image_core.yml – Example Image Core YAML file<br />
include/rfnoc/example<br />
gain_block_control.hpp – RFNoC Block Controller C++ header<br />
lib/<br />
gain_block_control.cpp – RFNoC Block Controller C++ source<br />
<br />
====Building rfnoc-example====<br />
<br />
cd rfnoc-example<br />
mkdir build; cd build<br />
cmake ..<br />
make<br />
sudo make install<br />
<br />
====Running a testbench====<br />
CMake automatically creates makefile targets to run RFNoC Block testbench simulations. For every RFNoC block subdirectory listed in the CMakeLists.txt file in the rfnoc-example/fpga directory, a target with the RFNoC block name appended with “_tb” is added as a makefile target. For example, here is how to run the gain RFNoC block testbench:<br />
<br />
cd rfnoc-example/build<br />
make rfnoc_block_gain_tb<br />
<br />
====Building a FPGA image====<br />
CMake automatically creates makefile targets to build a FPGA image for each image core yaml file listed in the CMakeLists.txt file in the rfnoc-example/icore directory. Each image core yaml file must be listed in the CMakeLists.txt. For example, here is how to build an FPGA image using the image core yaml file generated for the gain block:<br />
<br />
cd rfnoc-tutorial/build<br />
make gain_x310_rfnoc_image_core<br />
<br />
=Example RFNoC 3 to RFNoC 4 Block Migration=<br />
<br />
This ZIP archive, [[File:migration_example.zip]], contains equivalent RFNoC 3 and RFNoC 4 versions of a digital gain RFNoC Block. The following sections will refer to files in this archive to show how the file structure changes when migrating from RFNoC 3 to RFNoC 4.<br />
<br />
=UHD Software Migration=<br />
<br />
Migration reference files for this section from the Gain RFNoC Block example:<br />
<br />
{| class="wikitable"<br />
! Description || RFNoC 3 Files || RFNoC 4 Files<br />
|-<br />
| Block Description || rfnoc/blocks/gain.xml || lib/gain_block_ctrl_impl.cpp <br>include/example/gain_block_ctrl.hpp<br />
|-<br />
| Block Controller || rfnoc/blocks/gain.yml || lib/gain_block_ctrl_impl.cpp <br>include/example/gain_block_ctrl.hpp<br />
|}<br />
<br />
''Note: Files are relative to the rfnoc-example directory in the respective rfnoc3 and rfnoc4 directories''<br />
<br />
===Noc Script XML Replaced by Block Description YAML===<br />
<br />
RFNoC 3 used Noc Script XML, a domain specific language, to describe the configuration of a RFNoC block: the Noc ID, register names and addresses, args for writing to the registers, and the input/output ports.<br />
<br />
RFNoC 4 replaces the Noc Script XML file with an easier to read and edit Block Description YAML file format. From a high level, the Block Description YAML file serves a similar function as the Noc Script XML file, with some similarities and key differences outlined in table below:<br />
<br />
{| class="wikitable"<br />
! Item || Noc Script XML || Block Descript YAML || RFNoC 4 Notes<br />
|-<br />
| Block Name<br />
||<br />
<name>gain</name><br />
||<br />
module_name: gain<br />
||<br />
|-<br />
| Noc ID<br />
||<br />
<id>B160000000000000</id><br />
||<br />
noc_id: 0xB16<br />
||<br />
Noc ID are limited to 32-bits<br />
|-<br />
| Registers<br />
||<br />
<registers><br />
<setreg><br />
<name>GAIN</name><br />
<address>128</address><br />
</setreg><br />
</registers><br />
||<br />
N/A<br />
||<br />
Registers must be defined in the Block Controller<br />
|-<br />
| Arguments<br />
||<br />
<args><br />
<arg><br />
<name>gain</name><br />
<type>int</type><br />
...<br />
</arg><br />
</args><br />
||<br />
N/A<br />
||<br />
Args are implemented with properties in the Block Controller<br />
|-<br />
| Data Ports<br />
||<br />
<ports><br />
<sink><br />
<name>in</name><br />
</sink><br />
<source><br />
<name>out</name><br />
</source><br />
</ports><br />
||<br />
data:<br />
fpga_iface: axis_pyld_ctxt<br />
clk_domain: rfnoc_chdr<br />
inputs:<br />
in:<br />
...<br />
outputs:<br />
out:<br />
...<br />
||<br />
|-<br />
| Control Ports<br />
||<br />
N/A<br />
||<br />
control:<br />
sw_iface: nocscript<br />
fpga_iface: ctrlport<br />
interface_direction: slave<br />
...<br />
||<br />
|-<br />
| Clocking<br />
||<br />
N/A<br />
||<br />
clocks:<br />
- name: rfnoc_chdr<br />
freq: "[]"<br />
- name: rfnoc_ctrl<br />
freq: "[]"<br />
||<br />
|}<br />
<br />
''Note: For a more detailed description of the RFNoC 4 Block Description YAML syntax and the various options, see the [https://files.ettus.com/app_notes/RFNoC_Specification.pdf RFNoC Specification].''<br />
<br />
===RFNoC API Changes===<br />
<br />
Much of the user facing RFNoC software API has not changed or remains very similar between RFNoC 3 and RFNoC 4. The table below outlines some of the notable differences:<br />
<br />
{| class="wikitable"<br />
! RFNoC 3 || RFNoC 4 || RFNoC 4 Notes<br />
|-<br />
|<br />
usrp = uhd::device3::make(...)<br />
||<br />
graph = uhd::rfnoc::rfnoc_graph::make()<br />
||<br />
No longer need to create a device3 object<br />
|-<br />
|<br />
usrp->get_block_ctrl(...)<br />
||<br />
graph->get_block(...)<br />
||<br />
Rename<br />
|-<br />
|<br />
N/A<br />
||<br />
graph->enumerate_static_connections()<br />
||<br />
Used to check static connections, for example the DDC and DUC blocks are usually statically connected to the radio block<br />
|-<br />
|<br />
usrp->get_tx_streamer(...)<br />
||<br />
graph->create_tx_streamer(...)<br />
||<br />
Rename<br />
|-<br />
|<br />
usrp->get_rx_streamer(...)<br />
||<br />
graph->create_rx_streamer(...)<br />
||<br />
Rename<br />
|-<br />
|<br />
N/A<br />
||<br />
graph->commit()<br />
||<br />
Commit graph and run initial checks<br />
|-<br />
|<br />
sr_write(...)<br />
||<br />
regs().poke32(...)<br />
||<br />
Address increments by 4<br />
|-<br />
|<br />
sr_read32(...)<br />
||<br />
regs().peek32(...)<br />
||<br />
Address increments by 4<br />
|-<br />
|<br />
sr_read64(...)<br />
||<br />
regs().poke64(...)<br />
||<br />
Address increments by 8<br />
|-<br />
|<br />
set_arg(...)<br />
||<br />
set_property(...)<br />
||<br />
Block args replaced with block properties concept<br />
|-<br />
|<br />
get_arg(...)<br />
||<br />
get_property(...)<br />
||<br />
Block args replaced with block properties concept<br />
|}<br />
<br />
===Block Properties===<br />
<br />
In RFNoC 3, RFNoC blocks can have arguments (also known as args) that are used to write user registers. This is implemented in the Noc Script XML in the <args> section.<br />
<br />
RFNoC 4 expands and generalizes this concept with block properties: a high-level representation of the state of the block. Zero or more properties can be defined by the user in their RFNoC Block’s Block Controller C++ class. When read or written to, they can trigger a callback to a user defined resolver function. The [https://files.ettus.com/app_notes/RFNoC_Specification.pdf RFNoC Specification] provides more details on properties in the “Block Properties” section.<br />
<br />
The following shows an example of how to migrate a RFNoC 3 Noc Script XML “arg” based register write to a RFNoC 4 property based implementation in the Block Controller:<br />
<br />
====RFNoC 3 Noc Script XML snippet====<br />
<registers><br />
<setreg><br />
<name>GAIN</name><br />
<address>128</address><br />
</setreg><br />
</registers><br />
<br />
<args><br />
<arg><br />
<name>gain</name><br />
<type>int</type><br />
<value>1</value><br />
<check>GE($gain, 0) AND LE($gain, 32767)</check><br />
<check_message>Gain must be in the range [0, 32767]</check_message><br />
<action>SR_WRITE("GAIN", $gain)</action><br />
</arg><br />
</args><br />
<br />
====RFNoC 4 Block Controller Class====<br />
<br />
// <registers><br />
// <setreg><br />
// <name>GAIN</name><br />
// <address>128</address><br />
// </setreg><br />
// </registers><br />
// Note: In RFNoC 4, register addresses can start at address 0 instead of address 128 as in RFNoC 3.<br />
const uint32_t gain_block_ctrl::REG_GAIN_ADDR = 0;<br />
const uint32_t gain_block_ctrl::REG_GAIN_DEFAULT = 1;<br />
<br />
class gain_block_ctrl_impl : public gain_block_ctrl<br />
{<br />
public:<br />
RFNOC_BLOCK_CONSTRUCTOR(gain_block_ctrl)<br />
{<br />
_register_props();<br />
}<br />
private:<br />
void _register_props()<br />
{<br />
register_property(&_user_reg, [this]() {<br />
int user_reg = this->_user_reg.get();<br />
// <check>GE($gain, 0) AND LE($gain, 32767)</check><br />
// <check_message>Gain must be in the range [0, 32767]</check_message><br />
if (user_reg < 0 || user_reg > 32767) {<br />
throw uhd::value_error("Size value must be in [0,32767]");<br />
}<br />
// <action>SR_WRITE("GAIN", $gain)</action><br />
this->regs().poke32(REG_USER_ADDR, user_reg);<br />
});<br />
}<br />
<br />
// <name>gain</name><br />
// <type>int</type><br />
// <value>1</value><br />
property_t<int> _user_reg{"gain", REG_USER_DEFAULT, {res_source_info::USER}};<br />
}<br />
<br />
As the above shows, writing to a register can be replicated with a property and a resolver function. Of course, the resolver function can also be made much more sophisticated. For additional examples, see the in-tree block controllers in [https://github.com/EttusResearch/uhd/tree/master/host/lib/rfnoc uhd/host/lib/rfnoc].<br />
<br />
=FPGA Migration=<br />
<br />
Migration reference files for this section from the Gain RFNoC Block example:<br />
<br />
{| class="wikitable"<br />
! Description || RFNoC 3 Files || RFNoC 4 Files<br />
|-<br />
| Block Verilog Code || rfnoc/fpga-src/noc_block_gain.v || rfnoc/fpga/rfnoc_block_gain/rfnoc_block_gain.v<br />
|-<br />
| Block Noc Shell || N/A || rfnoc/fpga/rfnoc_block_gain/noc_shell_gain.v<br />
|-<br />
| Block Testbnech || rfnoc/testbench/noc_block_gain/noc_block_gain_tb.sv || rfnoc/fpga/rfnoc_block_gain/rfnoc_block_gain_tb.sv<br />
|-<br />
| Image Core || N/A || rfnoc/icores/gain_x310_rfnoc_image_core.yml<br />
|}<br />
<br />
''Note: Files are relative to the rfnoc-example directory in the respective rfnoc3 and rfnoc4 directories''<br />
<br />
===Noc Shell Changes===<br />
<br />
RFNoC 4 replaces the highly parameterized RFNoC 3 Noc Shell with a per-block customized Noc Shell generated from the block’s Block Description YAML file. The Noc Shell generated via rfnocmodtool or the existing one in rfnoc-example is acceptable for most blocks that require one input and output data port.<br />
<br />
====Generating a Custom Noc Shell====<br />
<br />
Some blocks may need multiple data ports or other modifications. This requires editing the Block Description YAML file and then using the Python script rfnoc_create_verilog.py (found in uhd/host/utils/rfnoc_blocktool) to generate a new Noc Shell instance.<br />
<br />
The argument “-c” is used to provide the YAML file location. “-d” provides the output destination directory.<br />
<br />
''Note: It is suggested to not set the destination directory to your existing RFNoC block code, as the script will automatically overwrite the existing code!''<br />
<br />
Example usage:<br />
rfnoc_create_verilog.py -c ./rfnoc-example/rfnoc/blocks/gain.yml -d ./output/<br />
<br />
====Changing Noc ID without using rfnoc_create_verilog====<br />
<br />
In the generated Noc Shell Verilog code, a block’s Noc ID can be changed by updating the NOC_ID parameter on the ''backend_iface'' module. Make sure this matches the Noc ID in both the Block Description YAML file and Block Controller C++ code.<br />
<br />
====Goodbye AXI Wrapper====<br />
<br />
The RFNoC 3 version of Noc Shell outputs / accepts CHDR data packets consisting of a header, optional timestamp, and payload on a 64-bit AXI stream bus. Most designs then used a module called AXI Wrapper to handle the conversion between CHDR data packets and sample streams on a 32-bit AXI stream bus. AXI Wrapper also supported SIMPLE_MODE which for some use cases could transparently handle the header portion of the CHDR data packet. Otherwise, the user would need to set the header via m_axis_data_tuser.<br />
<br />
In RFNoC 4, Noc Shell has absorbed AXI Wrapper’s functionality. Noc Shell outputs two AXI stream buses per input / output port: a payload and context bus. The payload bus is in most cases identical to AXI Wrapper’s output: a 32-bit stream of samples on an AXI Stream bus with packets delimited by tlast. The context AXI stream bus carries the header, optional timestamp, and optional metadata. If your block used AXI Wrapper’s SIMPLE_MODE, then you can loop the context bus back into Noc Shell. If not, you will need to modify the context bus data. Refer to the [https://files.ettus.com/app_notes/RFNoC_Specification.pdf RFNoC Specification] for the format and timing diagram of the context bus.<br />
<br />
''Important Note: If your block used the AXI Rate Change module, Noc Shell has another data port mode to support this use case called '''axis_data''' that can be set in the Block Descriptor YAML file (see the fpga_iface entry). This mode causes the Noc Shell data ports to look more like AXI Wrapper’s and therefore makes them compatible with AXI Rate Change. See the DDC, DUC, or Keep One in N RFNoC Blocks for an example.''<br />
<br />
===Settings Bus replaced by CtrlPort===<br />
<br />
CtrlPort replaces the Settings Bus in RFNoC 4. The CtrlPort bus is similar to the Settings Bus with a few key differences. The table below compares the signaling between the two bus formats and provides notes on any differences. Timing diagrams and additional information on the CtrlPort bus are also available in the [https://files.ettus.com/app_notes/RFNoC_Specification.pdf RFNoC Specification].<br />
<br />
{| class="wikitable"<br />
! Settings Bus (RFNoC 3) || CtrlPort (RFNoC 4) || RFNoC 4 Notes<br />
|-<br />
| set_stb || ctrlport_reg_wr || Write strobe<br />
|-<br />
| set_addr || ctrlport_req_addr || 20-bits instead of 8-bits, increments by 4 instead of by 1, no reserved addresses (versus addresses 0-127 for Settings Bus)<br />
|-<br />
| set_data || ctrlport_req_data || Write data<br />
|-<br />
| N/A || ctrlport_req_rd || Read strobe equivalent of ctrlport_req_wr<br />
|-<br />
| rb_addr || N/A || CtrlPort uses ctrlport_req_addr for both '''read and write''' addresses<br />
|-<br />
| rb_data || ctrlport_resp_data || Read data, 32-bits instead of 64-bits<br />
|-<br />
| rb_stb || N/A || CtrlPort requires ack strobe for '''reads and writes'''<br />
|}<br />
<br />
<br />
One additional difference when using CtrlPort is that there is not an equivalent Settings Register module. The bus is simple enough to setup a clocked process to handle reading from and writing to registers. See the Verilog example below:<br />
<br />
// Note: Register addresses increment by 4<br />
localparam REG_USER_ADDR = 0; // Address for example user register<br />
localparam REG_USER_DEFAULT = 0; // Default value for user register<br />
<br />
reg [31:0] reg_user = REG_USER_DEFAULT;<br />
<br />
always @(posedge ctrlport_clk) begin<br />
if (ctrlport_rst) begin<br />
reg_user = REG_USER_DEFAULT;<br />
end else begin<br />
// Default assignment<br />
m_ctrlport_resp_ack <= 0;<br />
<br />
// Read user register<br />
if (m_ctrlport_req_rd) begin // Read request<br />
case (m_ctrlport_req_addr)<br />
REG_USER_ADDR: begin<br />
m_ctrlport_resp_ack <= 1;<br />
m_ctrlport_resp_data <= reg_user;<br />
end<br />
endcase<br />
end<br />
<br />
// Write user register<br />
if (m_ctrlport_req_wr) begin // Write requst<br />
case (m_ctrlport_req_addr)<br />
REG_USER_ADDR: begin<br />
m_ctrlport_resp_ack <= 1;<br />
reg_user <= m_ctrlport_req_data[31:0];<br />
end<br />
endcase<br />
end<br />
end<br />
end<br />
<br />
''Important Note: For blocks that make heavy use of the Settings Bus and/or Settings Registers, there is a CtrlPort to Settings Bus bridge available called '''ctrlport_to_settings_bus'''. See the Keep One In N RFNoC Block for example code on how to interface with it.''<br />
<br />
===Testbench Infrastructure===<br />
<br />
While RFNoC 4 does overhaul the RFNoC 3 testbench infrastructure API, most of the high level concepts remain the same. The table below outlines some of the commonly used RFNoC 3 functions / code and the RFNoC 4 equivalent.<br />
<br />
{| class="wikitable"<br />
! Operation || RFNoC 3 || RFNoC 4<br />
|-<br />
| Setup RFNoC<br />
||<br />
`RFNOC_SIM_INIT(...)<br />
`RFNOC_ADD_BLOCK(...)<br />
`RFNOC_CONNECT(...)<br />
||<br />
RfnocBlockCtrlBfm #(...) blk_ctrl = new(...);<br />
blk_ctrl.connect_master_data_port(...)<br />
blk_ctrl.connect_slave_data_port(...)<br />
''Note: Instantiate one Block Controller BFM per RFNoC Block''<br />
|-<br />
| Setup Test Cases<br />
||<br />
`TEST_CASE_START(...)<br />
`TEST_CASE_DONE(...)<br />
||<br />
test.start_test(...)<br />
test.end_test()<br />
|-<br />
| Register Read<br />
||<br />
tb_streamer.read_reg(...)<br />
||<br />
blk_ctrl.reg_read(...)<br />
|-<br />
| Register Write<br />
||<br />
tb_streamer.write_reg(...)<br />
||<br />
blk_ctrl.reg_write(...)<br />
|-<br />
| Send Data / Samples<br />
||<br />
tb_streamer.send(...)<br />
||<br />
blk_ctrl.send_items(...)<br />
|-<br />
| Receive Data / Samples<br />
||<br />
tb_streamer.recv(...)<br />
||<br />
blk_ctrl.recv_items(...)<br />
|}<br />
<br />
===Building FPGA images using Image Core YAML Files===<br />
<br />
RFNoC 4 replaces uhd_image_builder, the RFNoC 3 FPGA image building tool, with a new tool called rfnoc_image_builder. This tool produces a FPGA bitstream based on an Image Core YAML file that describes the device configuration (e.g. X310 with dual 10GigE) and included RFNoC blocks along with their connections (both static and dynamic), clocking, and I/O.<br />
<br />
Both rfnocmodtool and the UHD in-tree example called rfnoc-example automatically setup make targets to handle running rfnoc_image_builder. If you want to use rfnoc_image_builder directly, more details can be found in the [https://kb.ettus.com/Getting_Started_with_RFNoC_in_UHD_4.0 Getting Started with RFNoC in UHD 4.0].<br />
<br />
=GNU Radio Software Migration=<br />
<br />
RFNoC 4 supports GNU Radio 3.8 only. Most of your RFNoC Block’s GNU Radio related changes will be due to API differences between GNU Radio 3.7 to 3.8. These changes are outside of the scope of this article. Instead, refer to [https://wiki.gnuradio.org/index.php/GNU_Radio_3.8_OOT_Module_Porting_Guide GNU Radio 3.8 Migration Guide] and [https://wiki.gnuradio.org/index.php/YAML_GRC GNU Radio Companion YAML] sites for more information.<br />
<br />
Migration reference files for this section from the Gain RFNoC Block example:<br />
<br />
{| class="wikitable"<br />
! Description || RFNoC 3 Files || RFNoC 4 Files<br />
|-<br />
| GNU Radio Block || lib/gain_impl.cc<br>lib/gain_impl.h<br>include/example/gain.h || lib/gain_impl.cc<br>lib/gain_impl.h<br>include/example/gain.h<br />
|-<br />
| GRC Block Description || grc/gain.xml || grc/gain.yml<br />
|-<br />
| Example GRC Flowgraph || examples/gain.grc || examples/gain.grc<br />
|}<br />
<br />
''Note: Files are relative to the rfnoc-example directory in the respective rfnoc3 and rfnoc4 directories''<br />
<br />
===RX & TX Streamer Blocks===<br />
<br />
When transition between a RFNoC block and a GNU Radio block or vice versa, you must insert either a RX stream or TX streamer block respectively. This differs from RFNoC 3, where a RFNoC block could be directly connected to a GNU Radio block.<br />
<br />
[[File:rx_tx_streamer.png|border]]<br />
<br />
===Setting RFNoC Block Properties Directly in GNU Radio===<br />
<br />
The base class for RFNoC Block’s in GNU Radio have a set of functions that provide a shortcut to getting and setting properties without writing custom class methods. The table below lists the functions.<br />
<br />
{| class="wikitable"<br />
! Property Type || Set Property || Get Property<br />
|-<br />
| Integer || set_int_property(...) || get_int_property(...)<br />
|-<br />
| Double || set_double_property(...) || get_double_property(...)<br />
|-<br />
| Bool || set_bool_property(...) || get_bool_property(...)<br />
|-<br />
| String || set_string_property(...) || get_string_property(...)<br />
|-<br />
|}<br />
<br />
'''Example code for GNU Radio Companion YAML Block Description file'''<br />
templates:<br />
imports: |-<br />
import example<br />
make: |-<br />
example.gain(<br />
self.rfnoc_graph,<br />
uhd.device_addr(${block_args}),<br />
${device_select},<br />
${instance_select})<br />
self.${id}.set_int_property('gain', ${gain})<br />
callbacks:<br />
- set_int_property('gain', ${gain})</div>JonathonPendlumhttps://kb.ettus.com/index.php?title=File:migration_example.zip&diff=5283File:migration example.zip2022-02-16T19:32:12Z<p>JonathonPendlum: JonathonPendlum uploaded a new version of File:migration example.zip</p>
<hr />
<div>Example designs for RFNoC 4 Migration Guide</div>JonathonPendlumhttps://kb.ettus.com/index.php?title=Knowledge_Base&diff=5282Knowledge Base2022-02-16T18:47:13Z<p>JonathonPendlum: /* Getting Started Guides */</p>
<hr />
<div>Welcome to the Ettus Research Knowledge Base (KB). The KB is continuously being updated and expanded. If you have any suggestions, or do not find what you are looking for, then please [http://www.ettus.com/contact Contact Us].<br />
__NOTOC__<br />
<div class="row"><br />
<div class="col-1-3"><br />
== [[Getting Started Guides|<i class="fa fa-road"></i> Getting Started Guides]] ==<br />
<br />
'''Motherboards'''<br />
* [[B200/B210/B200mini/B205mini Getting Started Guides|B200/B210/B200mini/B205mini]]<br />
* [[Ettus USRP E300 Embedded Family Getting Started Guides|E310/E312/E313]]<br />
* [[E320 Getting Started Guide|E320]]<br />
* [[N200/N210 Getting Started Guides|N200/N210]]<br />
* [[USRP N300/N310/N320/N321 Getting Started Guide|N300/N310/N320/N321]]<br />
* [[X300/X310 Getting Started Guides|X300/X310]]<br />
* [[USRP-2974 Getting Started Guide|USRP-2974]]<br />
* [[USRP X410 Getting Started Guide|X410]]<br />
<br />
'''Daughterboards'''<br />
* [[BasicTX/BasicRX Getting Started Guides|BasicTX/BasicRX]]<br />
* [[CBX Getting Started Guides|CBX]]<br />
* [[LFTX/LFRX Getting Started Guides|LFTX/LFRX]]<br />
* [[SBX Getting Started Guides|SBX]]<br />
* [[TwinRX Getting Started Guides|TwinRX]]<br />
* [[UBX Getting Started Guides|UBX]]<br />
* [[WBX Getting Started Guides|WBX]]<br />
<br />
'''Other'''<br />
* [[Getting_Started_with_RFNoC_in_UHD_4.0|RFNoC Development (UHD 4.x)]]<br />
* [[RFNoC_4_Migration_Guide|RFNoC Migration Guide (UHD 3.x to UHD 4.x)]]<br />
* [[Getting_Started_with_RFNoC_Development|RFNoC Development (UHD 3.x)]]<br />
* [[Live SDR Environment Getting Started Guides|Live SDR Environment]]<br />
* [[OctoClock CDA-2990 Getting Started Guides|OctoClock CDA-2990]]<br />
* [[Using Ethernet-Based Synchronization on the USRP™ N3xx Devices|White Rabbit]]<br />
* [[Getting Started with DPDK and UHD|DPDK]]<br />
<br />
</div><br />
<div class="col-1-3"><br />
<br />
== [[Hardware Resources|<i class="fa fa-cogs"></i> Hardware Resources]] ==<br />
'''Motherboards'''<br />
* [[B200/B210/B200mini/B205mini]]<br />
* [[Ettus USRP E300 Embedded Family Hardware Resources|E310/E312/E313]]<br />
* [[E320|E320]]<br />
* [[N200/N210]]<br />
* [[N300/N310]]<br />
* [[N320/N321]]<br />
* [[X300/X310]]<br />
* [[USRP-2974]]<br />
<br />
'''Daughterboards'''<br />
* [[BasicTX/BasicRX]]<br />
* [[CBX]]<br />
* [[LFTX/LFRX]]<br />
* [[SBX]]<br />
* [[TwinRX]]<br />
* [[UBX]]<br />
* [[WBX]]<br />
<br />
'''Other'''<br />
* [[OctoClock CDA-2990]]<br />
* [[GPSDO]]<br />
* [[Antennas]]<br />
<br />
</div><br />
<div class="col-1-3"><br />
<br />
== [[Software Resources|<i class="fa fa-desktop"></i> Software Resources]] ==<br />
'''Ettus Products'''<br />
* [[UHD]]<br />
* [[UHD Python API]]<br />
* [[Getting_Started_with_RFNoC_in_UHD_4.0|RFNoC (UHD 4.x)]]<br />
* [[RFNoC]] (UHD 3.x)<br />
<br />
'''Third Party'''<br />
* [[GNU Radio]]<br />
* [[LabVIEW]]<br />
* [[Matlab/Simulink]]<br />
* [[OpenBTS]]<br />
* [[Eurecom OpenAirInterface (OAI)]]<br />
* [[srsLTE/srsUE]]<br />
* [[Gqrx]]<br />
* [[Fosphor]]<br />
<br />
'''Reference Architectures'''<br />
* [[Open Architecture For Radar and EW Research]]<br />
<br />
</div><br />
</div><br />
<br />
<div class="row"><br />
<div class="col-1-3"><br />
<br />
== [[UHD and USRP User Manual|<i class="fa fa-flag"></i> UHD and USRP User Manual]] ==<br />
'''Software'''<br />
* [http://files.ettus.com/manual/ UHD Manual (master)]<br />
* [https://files.ettus.com/manual_archive/ UHD Manual Archive (previous releases)]<br />
<br />
'''Motherboards'''<br />
* [http://files.ettus.com/manual/page_usrp_b200.html B200/B210/B200mini/B205mini]<br />
* [http://files.ettus.com/manual/page_usrp_x3x0.html X300/X310]<br />
* [http://files.ettus.com/manual/page_usrp2.html N200/N210]<br />
* [http://files.ettus.com/manual/page_usrp_n3xx.html N300/N310/N320/N321]<br />
* [http://files.ettus.com/manual/page_usrp_e3xx.html E310/E312/E313/E320]<br />
<br />
'''Daughterboards'''<br />
* [http://files.ettus.com/manual/page_dboards.html#dboards_basictx BasicRX/LFRX]<br />
* [http://files.ettus.com/manual/page_dboards.html#dboards_basicrx BasicTX/LFTX]<br />
* [http://files.ettus.com/manual/page_dboards.html#dboards_cbx CBX]<br />
* [http://files.ettus.com/manual/page_dboards.html#dboards_sbx SBX]<br />
* [http://files.ettus.com/manual/page_dboards.html#dboards_wbx WBX]<br />
* [http://files.ettus.com/manual/page_dboards.html#dboards_ubx UBX]<br />
* [http://files.ettus.com/manual/page_dboards.html#dboards_twinrx TwinRX]<br />
<br />
'''Other'''<br />
* [http://files.ettus.com/manual/page_octoclock.html OctoClock]<br />
<br />
</div><br />
<div class="col-1-3"><br />
<br />
== [[Application Notes|<i class="fa fa-file-text-o"></i> Application Notes]] ==<br />
Application Notes (AN) and technical articles written by engineers, for engineers. These articles offer experienced analysis, design ideas, reference designs, and tutorials—to make you productive and successful using USRP devices.<br />
</div><br />
<div class="col-1-3"><br />
<br />
== [[Additional Resources|<i class="fa fa-book"></i> Additional Resources]] ==<br />
* [[Suggested Reading|Suggested Reading]]<br />
* [[Suggested Videos|Suggested Videos]]<br />
* [[SDR Events]]<br />
* [[CGRAN]]<br />
</div><br />
</div><br />
<br />
<br />
<div class="row"><br />
<div class="col-1-3"><br />
<br />
== [[Technical Support|<i class="fa fa-life-ring"></i> Technical Support]] ==<br />
* [[Email|Email]]<br />
* [[Mailing Lists|Mailing Lists]]<br />
* [[Slack|Slack]]<br />
* [[Internet Relay Chat (IRC)|Internet Relay Chat (IRC)]]<br />
* [[StackExchange|StackExchange]]<br />
* [[Ordering and Fulfillment Help | Ordering and Fulfillment Help]]<br />
<br />
</div><br />
<div class="col-1-3"><br />
<br />
== [[Faq|<i class="fa fa-info-circle"></i> FAQ]] ==<br />
* [[Technical FAQ|Technical]]<br />
* [[Licensing FAQ|Licensing]]<br />
<br />
<br />
</div><br />
<div class="col-1-3"><br />
<br />
== [[Legacy Products| <i class="fa fa-hourglass-end"></i> Legacy Products]] ==<br />
'''Motherboards'''<br />
* [[USRP1|USRP1]]<br />
* [[USRP2|USRP2]]<br />
* [[E100/E110|E100/E110]]<br />
* [[B100]]<br />
<br />
'''Daughterboards'''<br />
* [[DBSRX2]]<br />
* [[TVRX2]]<br />
* [[XCVR2450]]</div>JonathonPendlumhttps://kb.ettus.com/index.php?title=Mailing_Lists&diff=5090Mailing Lists2021-03-18T18:30:59Z<p>JonathonPendlum: Updated usrp mailing list URLs</p>
<hr />
<div>== usrp-users ==<br />
Discussions involving the USRP hardware and the UHD software itself are best addressed through the '''usrp-users''' mailing list at [https://lists.ettus.com/list/usrp-users.lists.ettus.com https://lists.ettus.com/list/usrp-users.lists.ettus.com].<br />
<br/><br />
<br/><br />
The list archives can be found at [https://lists.ettus.com/empathy/list/usrp-users.lists.ettus.com https://lists.ettus.com/empathy/list/usrp-users.lists.ettus.com].<br />
<br />
== discuss-gnuradio ==<br />
<br />
Discussions involving the use of [https://www.gnuradio.org GNU Radio] with USRP hardware and UHD software are best addressed through the '''discuss-gnuradio''' mailing list at [https://lists.gnu.org/mailman/listinfo/discuss-gnuradio https://lists.gnu.org/mailman/listinfo/discuss-gnuradio].<br />
<br/><br />
<br/><br />
The list archives can be found at [http://lists.gnu.org/archive/html/discuss-gnuradio/ http://lists.gnu.org/archive/html/discuss-gnuradio/].<br />
<br />
== openbts-discuss ==<br />
<br />
Discussions involving the use of [http://www.openbts.org OpenBTS®] with USRP hardware and UHD software are best addressed through the '''openbts-discuss''' mailing list at [https://lists.sourceforge.net/lists/listinfo/openbts-discuss https://lists.sourceforge.net/lists/listinfo/openbts-discuss].<br />
<br/><br />
<br/><br />
The list archives can be found at [https://sourceforge.net/p/openbts/mailman/openbts-discuss/ https://sourceforge.net/p/openbts/mailman/openbts-discuss/].<br />
<br />
== srslte-users ==<br />
<br />
Discussions involving the use of [https://github.com/srsLTE/srsLTE srsLTE], from [https://www.softwareradiosystems.com/ Software Radio Systems], with USRP hardware and UHD software are best addressed through the '''srslte-users''' mailing list at [https://www.softwareradiosystems.com/mailman/listinfo/srslte-users https://www.softwareradiosystems.com/mailman/listinfo/srslte-users].<br />
<br/><br />
<br/><br />
The list archives can be found at [https://www.softwareradiosystems.com/pipermail/srslte-users/ https://www.softwareradiosystems.com/pipermail/srslte-users/].<br />
<br />
== Open Air Interface (OAI) Mailing Lists ==<br />
<br />
Discussions involving the use of [https://www.openairinterface.org/ OAI] with USRP hardware and UHD software are best addressed through the their mailing list. Several mailing lists exist for OAI depending upon the subject, for a list of OAI mailing lists see the following links: <br />
*[https://gitlab.eurecom.fr/oai/openairinterface5g/wikis/AskQuestions https://gitlab.eurecom.fr/oai/openairinterface5g/wikis/AskQuestions]<br />
* [https://gitlab.eurecom.fr/oai/openairinterface5g/wikis/MailingList https://gitlab.eurecom.fr/oai/openairinterface5g/wikis/MailingList].<br />
<br />
The list archives can be found at the following links:<br />
* [http://lists.eurecom.fr/sympa/arc/openair5g-user http://lists.eurecom.fr/sympa/arc/openair5g-user]<br />
* [http://lists.eurecom.fr/sympa/arc/openair5g-devel http://lists.eurecom.fr/sympa/arc/openair5g-devel]<br />
* [http://lists.eurecom.fr/sympa/arc/openaircn-user http://lists.eurecom.fr/sympa/arc/openaircn-user]<br />
* [http://lists.eurecom.fr/sympa/arc/openaircn-devel http://lists.eurecom.fr/sympa/arc/openaircn-devel]<br />
<br />
<br />
[[Category:Technical Support]]</div>JonathonPendlumhttps://kb.ettus.com/index.php?title=Application_Notes&diff=5067Application Notes2020-12-29T21:35:45Z<p>JonathonPendlum: </p>
<hr />
<div>Application Notes (AN) and technical articles written by engineers, for engineers. These articles offer experienced analysis, design ideas, reference designs, and tutorials—to make you productive and successful using USRP devices.<br />
<br />
{| class="wikitable"<br />
!colspan="4"|Application Notes<br />
|-<br />
<br />
<br />
! style="text-align:center;"| Number<br />
! style="text-align:center;"| Title<br />
! style="text-align:center;"| Abstract<br />
! style="text-align:center;"| Author<br />
|-<br />
<br />
<br />
|style="width: 10%; text-align: center;"| AN-445<br />
|style="width: 30%;"| [[Building and Installing the USRP Open-Source Toolchain (UHD and GNU Radio) on Linux]]<br />
|style="width: 50%;"| This AN provides a comprehensive step-by-step guide for building, installing, and maintaining the open-source toolchain, specifically UHD and GNU Radio, for the USRP from source code on the Linux platform. Other alternate installation methods are also discussed.<br />
|style="width: 10%; text-align: center;"| Neel Pandeya<br />
|-<br />
<br />
<br />
|style="width: 10%; text-align: center;"| AN-788<br />
|style="width: 30%;"| [[Building and Installing the USRP Open-Source Toolchain (UHD and GNU Radio) on OS X]]<br />
|style="width: 50%;"| This AN provides a comprehensive step-by-step guide for building, installing, and maintaining the open-source toolchain, specifically UHD and GNU Radio, for the USRP from source code on the Mac OS X platform.<br />
|style="width: 10%; text-align: center;"|Michael Dickens<br />
|-<br />
<br />
<br />
|style="width: 10%; text-align: center;"| AN-666<br />
|style="width: 30%;"| [[Mean Time Between Failure (MTBF) of USRPs and Daughterboards]]<br />
|style="width: 50%;"| This AN provides information about the MTBF for USRPs and daughterboards<br />
|style="width: 10%; text-align: center;"|Michael Dickens<br />
|-<br />
<br />
<br />
|style="width: 10%; text-align: center;"| AN-111<br />
|style="width: 30%;"| [[UHD Device Eraser and Certificates of Volatility]]<br />
|style="width: 50%;"| This AN provides an overview of the UHD Device Eraser utility as well as links to the Certificates of Volatility for all Ettus products.<br />
|style="width: 10%; text-align: center;"|Michael Dickens<br />
|-<br />
<br />
<br />
|style="width: 10%; text-align: center;"| AN-611<br />
|style="width: 30%;"| [[Building and Installing the USRP Open Source Toolchain (UHD and GNU Radio) on Windows]]<br />
|style="width: 50%;"| This AN provides a comprehensive step-by-step guide for building, installing, and maintaining the open-source toolchain, specifically UHD and GNU Radio, for the USRP from source code on the Windows platform.<br />
|style="width: 10%; text-align: center;"|Derek Kozel<br />
|-<br />
<br />
<br />
|style="width: 10%; text-align: center;"| AN-936<br />
|style="width: 30%;"| [[Verifying the Operation of the USRP Using UHD and GNU Radio]]<br />
|style="width: 50%;"| This AN explains how to use UHD and GNU Radio, once installed, to verify the correct operation of the USRP. Several test procedures are explained in detail. Several tests make use of an optional spectrum analyzer and signal generator.<br />
|style="width: 10%; text-align: center;"|Neel Pandeya<br />
|-<br />
<br />
<br />
|style="width: 10%; text-align: center;"| AN-561<br />
|style="width: 30%;"| [[Implementation of a Simple FM Receiver in GNU Radio]]<br />
|style="width: 50%;"| This AN shows a quick and simple implementation of an FM receiver for the USRP using GNU Radio. The goal is to easily demonstrate a practical application, and to verify that the USRP is functioning properly.<br />
|style="width: 10%; text-align: center;"|Neel Pandeya<br />
|-<br />
<br />
<br />
|style="width: 10%; text-align: center;"| AN-188<br />
|style="width: 30%;"| [[Interrogating Passive Wireless SAW Sensors with the USRP]]<br />
|style="width: 50%;"| Typical interrogator design for wireless SAW sensor systems require many discrete components and lengthy build times, making it difficult to rapidly adapt to sensor designs in a research environment. We have employed the USRP B200 as a SAW sensor interrogation system. Interrogation of wideband orthogonal frequency coded (OFC) SAW sensors imposes strict requirements on the timing and synchronization of the transceiver. The USRP FPGA has been modified to operate in a synchronous, pulsed mode of operation, allowing rapid data acquisition and the full 56MHz bandwidth to be utilized. Data from the USRP is passed to a custom matched filter correlator routine to extract sensor parameters. The system is capable of interrogating multiple sensors, simultaneously. Demonstration of the system is accomplished by wirelessly interrogating SAW sensors at 915MHz and extracting temperature.<br />
|style="width: 10%; text-align: center;"|Trip Humphries<br />
|-<br />
<br />
<br />
|style="width: 10%; text-align: center;"| AN-322<br />
|style="width: 30%;"| [[Experiments with the UBX Daughterboard in the HF Band]]<br />
|style="width: 50%;"| We show the results of experiments with the UBX daughtercard on an USRP X310 platform for use in the HF frequency range, from 1.8MHz to 30MHz. While the UBX is nominally rated for use only down to 10 MHz, with careful flow-graph design, and pre-filtering, it provides quite-good performance across the HF bands.<br />
|style="width: 10%; text-align: center;"|Marcus Leech<br />
|-<br />
<br />
<br />
|style="width: 10%; text-align: center;"| AN-363<br />
|style="width: 30%;"| [[Implementation of an ADS-B/Mode-S Receiver in GNU Radio]]<br />
|style="width: 50%;"| This AN guides the reader through the implementation of an ADS-B receiver using the gr-air-modes Out-of-Tree (OOT) module for GNU Radio. An explanation of ADS-B is also provided, and several real-world, over-the-air examples and profiled.<br />
|style="width: 10%; text-align: center;"|Nate Temple<br />
|-<br />
<br />
<br />
|style="width: 10%; text-align: center;"| AN-177<br />
|style="width: 30%;"| [[About USRP Bandwidths and Sampling Rates]]<br />
|style="width: 50%;"| This AN provides insight into the topics of USRP architecture, system bandwidth, host interface throughput, and available sampling rates.<br />
|style="width: 10%; text-align: center;"|Neel Pandeya <br> Nate Temple<br />
|-<br />
<br />
<br />
|style="width: 10%; text-align: center;"| AN-881<br />
|style="width: 30%;"| [[Selecting a USRP Device]]<br />
|style="width: 50%;"| This AN explores the USRP family at a high level, compares devices across several primary features, and walks the reader through the process of selecting a particular device for the their application.<br />
|style="width: 10%; text-align: center;"|Neel Pandeya <br> Nate Temple<br />
|-<br />
<br />
<br />
|style="width: 10%; text-align: center;"| AN-492<br />
|style="width: 30%;"| [[Selecting a RF Daughterboard]]<br />
|style="width: 50%;"| This AN explores the RF daughterboards used by the N-series and X-series USRP devices at a high level, compares devices across several primary features, and walks the reader through the process of selecting a particular device for the their application.<br />
|style="width: 10%; text-align: center;"|Neel Pandeya <br> Nate Temple<br />
|-<br />
<br />
<br />
|style="width: 10%; text-align: center;"| AN-204<br />
|style="width: 30%;"| [[Getting Started with UHD and C++]]<br />
|style="width: 50%;"| This AN explains how to write and build C++ programs that use the UHD API and introduces<br />
|style="width: 10%; text-align: center;"|Neel Pandeya <br> Nate Temple<br />
|-<br />
<br />
<br />
|style="width: 10%; text-align: center;"| AN-117<br />
|style="width: 30%;"| [[GPSDO Selection Guide]]<br />
|style="width: 50%;"| This AN explains how to select and use a GPSDO with the USRP B-, N-, and X-series devices.<br />
|style="width: 10%; text-align: center;"|Neel Pandeya <br> Nate Temple<br />
|-<br />
<br />
<br />
|style="width: 10%; text-align: center;"| AN-503<br />
|style="width: 30%;"| [[Converting an X310 into an NI-USRP Rio]]<br />
|style="width: 50%;"| This Application Note explains how to use an Ettus Research-branded USRP with LabVIEW, and in effect, convert it into an NI-USRP RIO.<br />
|style="width: 10%; text-align: center;"|Tim Fountain<br />
|-<br />
<br />
|style="width: 10%; text-align: center;"| AN-638<br />
|style="width: 30%;"| [[Running UHD and GNU Radio on NI-USRP RIO]]<br />
|style="width: 50%;"| This AN explains the process to updating your USRP-Rio to run UHD and GNU Radio. <br />
|style="width: 10%; text-align: center;"|Neel Pandeya <br> Nate Temple<br />
|-<br />
<br />
|style="width: 10%; text-align: center;"| AN-882<br />
|style="width: 30%;"| [[Synchronization and MIMO Capability with USRP Devices]]<br />
|style="width: 50%;"| Discusses the requirements for Multiple-In-Multiple-Out (MIMO) and phased-array systems. Summarizes the MIMO capability of each USRP device and daughterboard, and shows how to build MIMO systems with the USRP product family.<br />
|style="width: 10%; text-align: center;"|Neel Pandeya <br> Nate Temple<br />
|-<br />
<br />
|style="width: 10%; text-align: center;"| AN-309<br />
|style="width: 30%;"| [[About the Motherboard and Daughtercard EEPROM on USRP Devices]]<br />
|style="width: 50%;"| This AN discusses the EEPROM storage on various USRP devices and daughtercards. This guides explains how to update the EEPROM contents and recover from EEPROM corruption. The product codes, which are also stored in the EEPROM, for all USRP devices and daughtercards are also given for reference.<br />
|style="width: 10%; text-align: center;"|Trip Humphries<br />
|-<br />
<br />
<br />
|style="width: 10%; text-align: center;"| AN-325<br />
|style="width: 30%;"| [[N200/N210 Device Recovery]]<br />
|style="width: 50%;"| This application note covers the details of recovering your N200/N210.<br />
|style="width: 10%; text-align: center;"|Neel Pandeya <br> Nate Temple<br />
|-<br />
<br />
<br />
<br />
|style="width: 10%; text-align: center;"| AN-504<br />
|style="width: 30%;"| [[USRP N Series Quick Start (Daughterboard Installation)]]<br />
|style="width: 50%;"| This application note is a detailed step-by-step guide to install a daughterboard into the USRP N200/N210.<br />
|style="width: 10%; text-align: center;"|Neel Pandeya <br> Nate Temple<br />
|-<br />
<br />
|style="width: 10%; text-align: center;"| AN-904<br />
|style="width: 30%;"| [[USRP X Series Quick Start (Daughterboard Installation)]]<br />
|style="width: 50%;"| This application note is a detailed step-by-step guide to install a daughterboard into the USRP X300/X310.<br />
|style="width: 10%; text-align: center;"|Neel Pandeya <br> Nate Temple<br />
|-<br />
<br />
<br />
|style="width: 10%; text-align: center;"| AN-311<br />
|style="width: 30%;"| [[Software Development on the E310 and E312]]<br />
|style="width: 50%;"| This application note covers the software development process on the USRP E310 and E312. <br />
|style="width: 10%; text-align: center;"|Martin Braun<br>Nicolas Cuervo<br />
|-<br />
<br />
<br />
|style="width: 10%; text-align: center;"| AN-296<br />
|style="width: 30%;"| [[Using Dual 10 Gigabit Ethernet on the USRP X300/X310]]<br />
|style="width: 50%;"| This short guide is meant to help in quickly setting up an X-series USRP for use over two 10 Gigabit Ethernet links simultaneously. <br />
|style="width: 10%; text-align: center;"|Paul David<br />
|-<br />
<br />
<br />
|style="width: 10%; text-align: center;"| AN-823<br />
|style="width: 30%;"| [[Getting Started with RFNoC Development]]<br />
|style="width: 50%;"| This application note gives a brief introduction into the steps required to start developing RFNoC blocks on your computer with UHD 3. <br />
|style="width: 10%; text-align: center;"|Martin Braun<br>Nicolas Cuervo<br />
|-<br />
<br />
<br />
|style="width: 10%; text-align: center;"| AN-178<br />
|style="width: 30%;"| [[Resolving Audio Codec Enumeration Issues On The E31x]]<br />
|style="width: 50%;"| This application note covers Resolving Audio Codec Enumeration Issues On The E31x. <br />
|style="width: 10%; text-align: center;"|Logan Fagg<br />
|-<br />
<br />
<br />
<br />
|style="width: 10%; text-align: center;"| AN-244<br />
|style="width: 30%;"| [[Direction Finding with the USRP™ X-Series and TwinRX™]]<br />
|style="width: 50%;"| This application note covers using the USRP™ TwinRX™ daughterboard in a direction find application using the MUSIC algorithm. <br />
|style="width: 10%; text-align: center;"|Srikanth Pagadarai<br>Travis Collins<br>Alexander M. Wyglinski<br />
|-<br />
<br />
<br />
<br />
|style="width: 10%; text-align: center;"| AN-335<br />
|style="width: 30%;"| [[Streaming processed data from the E31x with GNU Radio and ZMQ]]<br />
|style="width: 50%;"| This application note will demonstrate using the USRP E310 to remotely stream processed data to a host machine. <br />
|style="width: 10%; text-align: center;"| Nate Temple<br />
|-<br />
<br />
|style="width: 10%; text-align: center;"| AN-121<br />
|style="width: 30%;"| [[Debugging FPGA images]]<br />
|style="width: 50%;"| This application note covers the basics to get you through the process of probing the signals inside an FPGA. In order to accomplish that, we will review briefly the 'Xilinx ChipScope Analyzer' and will apply it to one of our core RFNoC blocks: the RFNoC Signal generator. <br />
|style="width: 10%; text-align: center;"|Nicolas Cuervo<br>Sugandha Gupta <br />
|-<br />
<br />
<br />
|style="width: 10%; text-align: center;"| AN-732<br />
|style="width: 30%;"| [[USRP E312 Battery Replacement Instructions]]<br />
|style="width: 50%;"| This application note covers replacing the battery cell inside the USRP E312. <br />
|style="width: 10%; text-align: center;"| Robin Coxe<br />
|-<br />
<br />
|style="width: 10%; text-align: center;"| AN-305<br />
|style="width: 30%;"| [[X300/X310 Device Recovery]]<br />
|style="width: 50%;"| This application note covers the details of recovering the USRP X300/X310 via JTAG. <br />
|style="width: 10%; text-align: center;"| Nate Temple<br />
|-<br />
<br />
<br />
|style="width: 10%; text-align: center;"| AN-832<br />
|style="width: 30%;"| [[Mapping Between ER-USRP and NI-USRP Product Numbers]]<br />
|style="width: 50%;"| This application note covers the details of the mapping between Ettus Research USRP and National Instruments USRP product numbers. <br />
|style="width: 10%; text-align: center;"| Nate Temple<br />
|-<br />
<br />
<br />
<br />
|style="width: 10%; text-align: center;"| AN-315<br />
|style="width: 30%;"| [[Software Development on the E3xx USRP - Building RFNoC UHD / GNU Radio / gr-ettus from Source]]<br />
|style="width: 50%;"| This application note is one of a multi-part series which will cover the software development process on the USRP E310, E312 and E313. It will cover building the rfnoc-devel branch of UHD, GNU Radio and gr-ettus from source for the host machine, and cross-compiling the rfnoc-devel branch of UHD, GNU Radio and gr-ettus for the E3xx USRP. <br />
|style="width: 10%; text-align: center;"| Nate Temple<br />
|-<br />
<br />
<br />
<br />
<br />
|style="width: 10%; text-align: center;"| AN-142<br />
|style="width: 30%;"| [[Transmitting DVB-S2 with GNU Radio and an USRP B210]]<br />
|style="width: 50%;"| This application note will demonstrate using an USRP B210 and the GNU Radio DTV example flowgraph to transmit a DVB-S2 video stream to an off-the-shelf satellite receiver. <br />
|style="width: 10%; text-align: center;"| Nate Temple<br />
|-<br />
<br />
<br />
<br />
<br />
|style="width: 10%; text-align: center;"| AN-158<br />
|style="width: 30%;"| [[Using Ethernet-Based Synchronization on the USRP™ N3xx Devices]]<br />
|style="width: 50%;"| This application note provides instructions for synchronizing multiple USRP N3xx devices using White Rabbit Ethernet-based synchronization. <br />
|style="width: 10%; text-align: center;"| Dan Baker<br />
Wan Liu <br />
|-<br />
<br />
<br />
<br />
|style="width: 10%; text-align: center;"| AN-642<br />
|style="width: 30%;"| [[Using the RFNoC Replay Block]]<br />
|style="width: 50%;"| This application note guides a user through basic use of the RFNoC Replay block and explains how to run the UHD Replay example. This example covers use on the X300/X310 and N310 products. <br />
|style="width: 10%; text-align: center;"| Wade Fife<br />
|-<br />
<br />
<br />
|style="width: 10%; text-align: center;"| AN-630<br />
|style="width: 30%;"| [[Writing the USRP File System Disk Image to a SD Card]]<br />
|style="width: 50%;"| This application note will provide step-by-step instructions on writing a file system disk image to a SD card using Linux. <br />
|style="width: 10%; text-align: center;"| Nate Temple<br />
|-<br />
<br />
|style="width: 10%; text-align: center;"| AN-524<br />
|style="width: 30%;"| [[Building and Installing UHD and GNU Radio in an Offline Environment]]<br />
|style="width: 50%;"| This application note will provide step-by-step instructions on building and installing UHD and GNU Radio in an offline environment. <br />
|style="width: 10%; text-align: center;"| Nate Temple<br />
|-<br />
<br />
|style="width: 10%; text-align: center;"| AN-525<br />
|style="width: 30%;"| [[Building and Installing UHD and GNU Radio to a Custom Prefix]]<br />
|style="width: 50%;"| This application note provides step-by-step instructions on building and installing UHD and GNU Radio to a local directory. <br />
|style="width: 10%; text-align: center;"| Nate Temple<br />
|-<br />
<br />
<br />
|style="width: 10%; text-align: center;"| AN-725<br />
|style="width: 30%;"| [[USRP N320/N321 LO Distribution]]<br />
|style="width: 50%;"| This application note provides an overview of using the LO Distribution of the N320/N321 USRPs.<br />
<br />
|style="width: 10%; text-align: center;"| Brian Avenell <br />
|-<br />
<br />
<br />
|style="width: 10%; text-align: center;"| AN-452<br />
|style="width: 30%;"| [[5G NR EVM Measurements with the USRP N320/N321]]<br />
|style="width: 50%;"| Example EVM measurements are shown using the USRP N320/N321 receiver and the 5G New Radio (5G NR) modulation standard. The use of I/Q image calibration and spur-dodging are demonstrated as methods to improve EVM performance. <br />
|style="width: 10%; text-align: center;"| Drew Fischer<br />
|-<br />
<br />
|style="width: 10%; text-align: center;"| AN-620<br />
|style="width: 30%;"| [[Troubleshooting X300/X310 Device Discovery Issues]]<br />
|style="width: 50%;"| Troubleshooting guide to intended to cover some of the most commonly recommended steps to enable USRP connectivity. <br />
|style="width: 10%; text-align: center;"| Sam Reiter<br />
|-<br />
<br />
|style="width: 10%; text-align: center;"| AN-088<br />
|style="width: 30%;"| [[USRP Host Performance Tuning Tips and Tricks]]<br />
|style="width: 50%;"| This application note provides various tips and tricks for tuning your host computer for best performance when working with USRP devices. <br />
|style="width: 10%; text-align: center;"| Nate Temple<br />
|-<br />
<br />
|style="width: 10%; text-align: center;"| AN-355<br />
|style="width: 30%;"| [[Modifying an X310 Chassis for External LO Sharing]]<br />
|style="width: 50%;"| This document describes how to modify an X310 chassis to wire the LO out of the back plate. Doing this will allow the user to export and import an LO signal as desired when using a compatible daughterboard such as the TwinRX. <br />
|style="width: 10%; text-align: center;"| Sam Reiter<br />
|-<br />
<br />
|style="width: 10%; text-align: center;"| AN-500<br />
|style="width: 30%;"| [[Getting Started with DPDK and UHD]]<br />
|style="width: 50%;"| This application note walks through the process to get started with the Data Plane Development Kit (DPDK) driver within UHD. <br />
|style="width: 10%; text-align: center;"| Nate Temple<br />
Alex Williams<br />
|-<br />
<br />
|style="width: 10%; text-align: center;"| AN-800<br />
|style="width: 30%;"| [[Enabling Ethernet Connectivity on Octoclock and Octoclock-G]]<br />
|style="width: 50%;"| This document supplements the UHD Manual's guide for updating the Octoclock bootloader to allow for Ethernet communications with the device. <br />
|style="width: 10%; text-align: center;"| Sam Reiter<br />
|-<br />
<br />
|style="width: 10%; text-align: center;"| AN-621<br />
|style="width: 30%;"| [[Troubleshooting N310/N320 Device Discovery Issues]]<br />
|style="width: 50%;"| Troubleshooting guide to intended to cover some of the most commonly recommended steps to enable USRP connectivity. Serves as a supplement to the N3xx getting started guide. <br />
|style="width: 10%; text-align: center;"| Sam Reiter<br />
|-<br />
<br />
|style="width: 10%; text-align: center;"| AN-883<br />
|style="width: 30%;"| [[Synchronizing USRP Events Using Timed Commands in UHD]]<br />
|style="width: 50%;"| Guide to cover common USRP synchronization scenarios and deep-dive into the use of timed commands within USRPs. <br />
|style="width: 10%; text-align: center;"| Sam Reiter<br />
|-<br />
<br />
|style="width: 10%; text-align: center;"| AN-400<br />
|style="width: 30%;"| [[Getting Started with RFNoC in UHD 4.0]]<br />
|style="width: 50%;"| This AN describes how use RFNoC in UHD 4.0, including building FPGA images for RFNoC, changing which blocks are included in the build, and creating your own RFNoC blocks.<br />
|style="width: 10%; text-align: center;"| Sugandha Gupta<br>Brent Stapleton<br>Wade Fife <br />
|-<br />
<br />
|style="width: 10%; text-align: center;"| AN-401<br />
|style="width: 30%;"| [[RFNoC 4 Migration Guide]]<br />
|style="width: 50%;"| Guide on how to migrate RFNoC blocks written for RFNoC 3 to RFNoC 4.<br />
|style="width: 10%; text-align: center;"| Jonathon Pendlum<br />
|-<br />
<br />
|}</div>JonathonPendlumhttps://kb.ettus.com/index.php?title=RFNoC_4_Migration_Guide&diff=5066RFNoC 4 Migration Guide2020-12-29T08:39:02Z<p>JonathonPendlum: </p>
<hr />
<div>=Abstract=<br />
<br />
The UHD 4.0 release includes a major upgrade to the RFNoC framework called RFNoC 4. This article is a guide to aid users in migrating their existing RFNoC blocks from RFNoC 3 to RFNoC 4. The RFNoC Block Development Environment section provides guidance on how to setup an environment for developing out-of-tree RFNoC blocks in RFNoC 4. The UHD, FPGA, GNU Radio Migration sections provide general information on topics that most users will encounter when migrating their blocks. Finally, an equivalent RFNoC 3 and RFNoC 4 implementation of a digital gain RFNoC Block has been provided as a reference.<br />
<br />
=Prerequisites=<br />
<br />
===Dependencies (Ubuntu 20.04)===<br />
git cmake g++ libboost-all-dev libgmp-dev swig \<br />
python3-numpy python3-mako python3-sphinx python3-lxml \<br />
doxygen libfftw3-dev libsdl1.2-dev libgsl-dev libqwt-qt5-dev \<br />
libqt5opengl5-dev python3-pyqt5 liblog4cpp5-dev libzmq3-dev \<br />
python3-yaml python3-click python3-click-plugins python3-zmq \<br />
python3-scipy python3-gi python3-gi-cairo gobject-introspection \<br />
gir1.2-gtk-3.0 build-essential libusb-1.0-0-dev python3-docutils \<br />
python3-setuptools python3-ruamel.yaml python-is-python3 \<br />
libtinfo5 libncurses5<br />
<br />
===Vivado 2019.1 Design Edition===<br />
<br />
Please reference to Xilinx (xilinx.com) for installation instructions.<br />
<br />
''Note: The dependencies step above included installing libtinfo5 libncurses5, which is a workaround for getting Vivado 2019.1 to run on Ubunbtu 20.04''<br />
<br />
===UHD 4.0===<br />
git clone --branch UHD-4.0 https://github.com/ettusresearch/uhd.git uhd<br />
mkdir uhd/host/build; cd uhd/host/build<br />
cmake ..<br />
make<br />
sudo make install<br />
<br />
===GNU Radio 3.8===<br />
'' Note: If your design does not use GNU Radio, then installing GNU Radio and gr-ettus is not required ''<br />
<br />
git clone --branch maint-3.8 --recursive https://github.com/gnuradio/gnuradio.git gnuradio<br />
mkdir gnuradio/build; cd gnuradio/build;<br />
cmake ..<br />
make<br />
sudo make install<br />
<br />
===gr-ettus===<br />
git clone --branch maint-3.8-uhd4.0 https://github.com/ettusresearch/gr-ettus.git gr-ettus<br />
mkdir gr-ettus/build; cd gr-ettus/build;<br />
cmake -DENABLE_QT=True ..<br />
make<br />
sudo make install<br />
<br />
=RFNoC Block Development Environment=<br />
<br />
Two options exist for developing RFNoC blocks depending on whether the your RFNoC block integrates with GNU Radio in an out-of-tree module or if it only uses UHD’s C++ API in a standalone application. The sections below outline how to setup the development environment for each scenario.<br />
<br />
===Migrating a GNU Radio Out-of-Tree Module===<br />
<br />
The tool rfnocmodtool automates the process of creating GNU Radio out-of-tree (OOT) modules that also have support for RFNoC blocks. This tool is part of gr-ettus and it has been ported to RFNoC 4.<br />
<br />
Due to changes in almost every source file, it is recommended to use rfnocmodtool to generate a new RFNoC block from scratch and then update the generated “skeleton” files.<br />
<br />
====Creating a RFNoC Block with rfnocmodtool====<br />
<br />
The following steps show how to create an OOT module called ''example'' and RFNoC block called ''gain'' using rfnocmodtool. The naming is only for example purposes.<br />
<br />
rfnocmodtool newmod<br />
Name of the new module: '''example'''<br />
<br />
cd rfnoc-tutorial<br />
rfnocmodtool add<br />
Enter name of block/code (without module name prefix): '''gain'''<br />
Enter valid argument list, including default arguments: ''(leave blank)''<br />
Add Python QA code? [y/N] '''N'''<br />
Add C++ QA code? [y/N] '''N'''<br />
Block NoC ID (Hexadecimal): ''(Enter Noc ID of your block)''<br />
Skip Block Controllers Generation? [UHD block ctrl files] [y/N] '''N'''<br />
Skip Block interface files Generation? [GRC block ctrl files] [y/N] '''N'''<br />
<br />
''Note: Noc IDs have been reduced from 64-bits in RFNoC 3 to 32-bits in RFNoC 4''<br />
<br />
The following are the relevant files that need to be updated when migrating your RFNoC Block.<br />
<br />
rfnoc-example/<br />
grc/<br />
example_gain.block.yml – RFNoC Block GNU Radio Companion YAML file<br />
examples/<br />
gain.grc – Example flowgraph using gain RFNoC Block<br />
include/tutorial/<br />
gain.h – GNU Radio block C++ header<br />
gain_block_ctrl.hpp – RFNoC Block Controller C++ header<br />
lib/<br />
gain_impl.cc – GNU Radio block C++ source<br />
gain_impl.h – GNU Radio block C++ header<br />
gain_block_ctrl_impl.cpp – RFNoC Block Controller C++ source<br />
rfnoc/blocks/<br />
gain.yml – RFNoC Block Description YAML file<br />
rfnoc/fpga/rfnoc_block_gain<br />
noc_shell_gain.v – RFNoC Block Noc Shell Verilog Source<br />
rfnoc_block_gain.v – RFNoC Block Verilog Source<br />
rfnoc_block_gain_tb.v – RFNoC Block Testbench<br />
rfnoc/icores<br />
gain_x310_rfnoc_image_core.yml – Image Core YAML file with gain block<br />
<br />
====Building OOT module====<br />
<br />
cd rfnoc-tutorial<br />
mkdir build; cd build<br />
cmake -DUHD_FPGA_DIR=''(path to uhd/fpga directory)'' ..<br />
make<br />
sudo make install<br />
<br />
====Running a testbench====<br />
CMake automatically creates makefile targets to run the generated testbench code for each added RFNoC block. For example, here is how to run the gain block testbench:<br />
<br />
cd rfnoc-tutorial/build<br />
make rfnoc_block_gain_tb<br />
<br />
====Building a FPGA image====<br />
CMake automatically creates makefile targets to build FPGA images using the generated image core yaml files found in rfnoc/icore. Every RFNoC block created by rfnocmodtool automatically has an image core yaml file generated in that directory. For example, here is how to build an FPGA image using the image core yaml file generated for the gain block:<br />
<br />
cd rfnoc-tutorial/build<br />
make gain_x310_rfnoc_image_core<br />
<br />
===Migrating a Standalone UHD C++ Application===<br />
<br />
For applications that only use the UHD API, an example out-of-tree (UHD source tree) RFNoC block exists called rfnoc-example. It is located in the UHD source at uhd/host/examples/rfnoc-example. This directory can be copied outside of the UHD source tree and used a starting point to migrate your RFNoC block.<br />
<br />
The following are the relevant files that need to be updated when migrating your RFNoC Block.<br />
<br />
rfnoc-example/<br />
apps/<br />
init_gain_block.cpp – Example C++ application testing gain block<br />
blocks/<br />
gain.yml – RFNoC Block Description YAML file<br />
fpga/rfnoc_block_gain<br />
noc_shell_gain.v – RFNoC Block Noc Shell Verilog Source<br />
rfnoc_block_gain.v – RFNoC Block Verilog Source<br />
rfnoc_block_gain_tb.v – RFNoC Block Testbench<br />
icores/<br />
x310_rfnoc_image_core.yml – Example Image Core YAML file<br />
include/rfnoc/example<br />
gain_block_control.hpp – RFNoC Block Controller C++ header<br />
lib/<br />
gain_block_control.cpp – RFNoC Block Controller C++ source<br />
<br />
====Building rfnoc-example====<br />
<br />
cd rfnoc-example<br />
mkdir build; cd build<br />
cmake ..<br />
make<br />
sudo make install<br />
<br />
====Running a testbench====<br />
CMake automatically creates makefile targets to run RFNoC Block testbench simulations. For every RFNoC block subdirectory listed in the CMakeLists.txt file in the rfnoc-example/fpga directory, a target with the RFNoC block name appended with “_tb” is added as a makefile target. For example, here is how to run the gain RFNoC block testbench:<br />
<br />
cd rfnoc-example/build<br />
make rfnoc_block_gain_tb<br />
<br />
====Building a FPGA image====<br />
CMake automatically creates makefile targets to build a FPGA image for each image core yaml file listed in the CMakeLists.txt file in the rfnoc-example/icore directory. Each image core yaml file must be listed in the CMakeLists.txt. For example, here is how to build an FPGA image using the image core yaml file generated for the gain block:<br />
<br />
cd rfnoc-tutorial/build<br />
make gain_x310_rfnoc_image_core<br />
<br />
=Example RFNoC 3 to RFNoC 4 Block Migration=<br />
<br />
This ZIP archive, [[File:migration_example.zip]], contains equivalent RFNoC 3 and RFNoC 4 versions of a digital gain RFNoC Block. The following sections will refer to files in this archive to show how the file structure changes when migrating from RFNoC 3 to RFNoC 4.<br />
<br />
=UHD Software Migration=<br />
<br />
Migration reference files for this section from Gain RFNoC Block example:<br />
<br />
{| class="wikitable"<br />
! Description || RFNoC 3 Files || RFNoC 4 Files<br />
|-<br />
| Block Description || rfnoc/blocks/gain.xml || lib/gain_block_ctrl_impl.cpp <br>include/example/gain_block_ctrl.hpp<br />
|-<br />
| Block Controller || rfnoc/blocks/gain.yml || lib/gain_block_ctrl_impl.cpp <br>include/example/gain_block_ctrl.hpp<br />
|}<br />
<br />
''Note: Files are relative to the rfnoc-example directory in the respective rfnoc3 and rfnoc4 directories''<br />
<br />
===Noc Script XML Replaced by Block Description YAML===<br />
<br />
RFNoC 3 used Noc Script XML, a domain specific language, to describe the configuration of a RFNoC block: the Noc ID, register names and addresses, args for writing to the registers, and the input/output ports.<br />
<br />
RFNoC 4 replaces the Noc Script XML file with an easier to read and edit Block Description YAML file format. From a high level, the Block Description YAML file serves a similar function as the Noc Script XML file, with some similarities and key differences outlined in table below:<br />
<br />
{| class="wikitable"<br />
! Item || Noc Script XML || Block Descript YAML || RFNoC 4 Notes<br />
|-<br />
| Block Name<br />
||<br />
<name>gain</name><br />
||<br />
module_name: gain<br />
||<br />
|-<br />
| Noc ID<br />
||<br />
<id>B160000000000000</id><br />
||<br />
noc_id: 0xB16<br />
||<br />
Noc ID are limited to 32-bits<br />
|-<br />
| Registers<br />
||<br />
<registers><br />
<setreg><br />
<name>GAIN</name><br />
<address>128</address><br />
</setreg><br />
</registers><br />
||<br />
N/A<br />
||<br />
Registers must be defined in the Block Controller<br />
|-<br />
| Arguments<br />
||<br />
<args><br />
<arg><br />
<name>gain</name><br />
<type>int</type><br />
...<br />
</arg><br />
</args><br />
||<br />
N/A<br />
||<br />
Args are implemented with properties in the Block Controller<br />
|-<br />
| Data Ports<br />
||<br />
<ports><br />
<sink><br />
<name>in</name><br />
</sink><br />
<source><br />
<name>out</name><br />
</source><br />
</ports><br />
||<br />
data:<br />
fpga_iface: axis_pyld_ctxt<br />
clk_domain: rfnoc_chdr<br />
inputs:<br />
in:<br />
...<br />
outputs:<br />
out:<br />
...<br />
||<br />
|-<br />
| Control Ports<br />
||<br />
N/A<br />
||<br />
control:<br />
sw_iface: nocscript<br />
fpga_iface: ctrlport<br />
interface_direction: slave<br />
...<br />
||<br />
|-<br />
| Clocking<br />
||<br />
N/A<br />
||<br />
clocks:<br />
- name: rfnoc_chdr<br />
freq: "[]"<br />
- name: rfnoc_ctrl<br />
freq: "[]"<br />
||<br />
|}<br />
<br />
''Note: For a more detailed description of the RFNoC 4 Block Description YAML syntax and the various options, see the [https://files.ettus.com/app_notes/RFNoC_Specification.pdf RFNoC Specification].''<br />
<br />
===RFNoC API Changes===<br />
<br />
Much of the user facing RFNoC software API has not changed or remains very similar between RFNoC 3 and RFNoC 4. The table below outlines some of the notable differences:<br />
<br />
{| class="wikitable"<br />
! RFNoC 3 || RFNoC 4 || RFNoC 4 Notes<br />
|-<br />
|<br />
usrp = uhd::device3::make(...)<br />
||<br />
graph = uhd::rfnoc::rfnoc_graph::make()<br />
||<br />
No longer need to create a device3 object<br />
|-<br />
|<br />
usrp->get_block_ctrl(...)<br />
||<br />
graph->get_block(...)<br />
||<br />
Rename<br />
|-<br />
|<br />
N/A<br />
||<br />
graph->enumerate_static_connections()<br />
||<br />
Used to check static connections, usually for detecting hwen a DDC or DUC is statically connected to the radio and requires setting the sample<br />
|-<br />
|<br />
usrp->get_tx_streamer(...)<br />
||<br />
graph->create_tx_streamer(...)<br />
||<br />
Rename<br />
|-<br />
|<br />
usrp->get_rx_streamer(...)<br />
||<br />
graph->create_rx_streamer(...)<br />
||<br />
Rename<br />
|-<br />
|<br />
N/A<br />
||<br />
graph->commit()<br />
||<br />
Commit graph and run initial checks<br />
|-<br />
|<br />
sr_write(...)<br />
||<br />
regs().poke32(...)<br />
||<br />
Address increments by 4<br />
|-<br />
|<br />
sr_read32(...)<br />
||<br />
regs().peek32(...)<br />
||<br />
Address increments by 4<br />
|-<br />
|<br />
sr_read64(...)<br />
||<br />
regs().poke64(...)<br />
||<br />
Address increments by 8<br />
|-<br />
|<br />
set_arg(...)<br />
||<br />
set_property(...)<br />
||<br />
Block args replaced with block properties concept<br />
|-<br />
|<br />
get_arg(...)<br />
||<br />
get_property(...)<br />
||<br />
Block args replaced with block properties concept<br />
|}<br />
<br />
===Block Properties===<br />
<br />
In RFNoC 3, RFNoC blocks can have arguments (also known as args) that are used to write user registers. This is implemented in the Noc Script XML in the <args> section.<br />
<br />
RFNoC 4 expands and generalizes this concept with block properties: a high-level representation of the state of the block. Zero or more properties can be defined by the user in their RFNoC Block’s Block Controller C++ class. When read or written to, they can trigger a call back to a user defined resolver function. The [https://files.ettus.com/app_notes/RFNoC_Specification.pdf RFNoC Specification] provides more details on properties in the “Block Properties” section.<br />
<br />
The following shows an example of how to migrate a RFNoC 3 Noc Script XML “arg” based register write to a RFNoC 4 property based implementation in the Block Controller:<br />
<br />
====RFNoC 3 Noc Script XML snippet====<br />
<registers><br />
<setreg><br />
<name>GAIN</name><br />
<address>128</address><br />
</setreg><br />
</registers><br />
<br />
<args><br />
<arg><br />
<name>gain</name><br />
<type>int</type><br />
<value>1</value><br />
<check>GE($gain, 0) AND LE($gain, 32767)</check><br />
<check_message>Gain must be in the range [0, 32767]</check_message><br />
<action>SR_WRITE("GAIN", $gain)</action><br />
</arg><br />
</args><br />
<br />
====RFNoC 4 Block Controller Class====<br />
<br />
// <registers><br />
// <setreg><br />
// <name>GAIN</name><br />
// <address>128</address><br />
// </setreg><br />
// </registers><br />
// Note: In RFNoC 4, register addresses can start at address 0 instead of address 128 as in RFNoC 3.<br />
const uint32_t gain_block_ctrl::REG_GAIN_ADDR = 128;<br />
const uint32_t gain_block_ctrl::REG_GAIN_DEFAULT = 1;<br />
<br />
class gain_block_ctrl_impl : public gain_block_ctrl<br />
{<br />
public:<br />
RFNOC_BLOCK_CONSTRUCTOR(gain_block_ctrl)<br />
{<br />
_register_props();<br />
}<br />
private:<br />
void _register_props()<br />
{<br />
register_property(&_user_reg, [this]() {<br />
int user_reg = this->_user_reg.get();<br />
// <check>GE($gain, 0) AND LE($gain, 32767)</check><br />
// <check_message>Gain must be in the range [0, 32767]</check_message><br />
if (user_reg < 0 || user_reg > 32767) {<br />
throw uhd::value_error("Size value must be in [0,32767]");<br />
}<br />
// <action>SR_WRITE("GAIN", $gain)</action><br />
this->regs().poke32(REG_USER_ADDR, user_reg);<br />
});<br />
}<br />
<br />
// <name>gain</name><br />
// <type>int</type><br />
// <value>1</value><br />
property_t<int> _user_reg{"gain", REG_USER_DEFAULT, {res_source_info::USER}};<br />
}<br />
<br />
As the above shows, writing to a register can be replicated with a property and a resolver function. Of course, the resolver function can also be made much more sophisticated. For additional examples, see the in-tree block controllers in uhd/host/lib/rfnoc.<br />
<br />
=FPGA Migration=<br />
<br />
Migration reference files for this section from Gain RFNoC Block example:<br />
<br />
{| class="wikitable"<br />
! Description || RFNoC 3 Files || RFNoC 4 Files<br />
|-<br />
| Block Verilog Code || rfnoc/fpga-src/noc_block_gain.v || rfnoc/fpga/rfnoc_block_gain/rfnoc_block_gain.v<br />
|-<br />
| Block Noc Shell || N/A || rfnoc/fpga/rfnoc_block_gain/noc_shell_gain.v<br />
|-<br />
| Block Testbnech || rfnoc/testbench/noc_block_gain/noc_block_gain_tb.sv || rfnoc/fpga/rfnoc_block_gain/rfnoc_block_gain_tb.sv<br />
|-<br />
| Image Core || N/A || rfnoc/icores/gain_x310_rfnoc_image_core.yml<br />
|}<br />
<br />
''Note: Files are relative to the rfnoc-example directory in the respective rfnoc3 and rfnoc4 directories''<br />
<br />
===Noc Shell Changes===<br />
<br />
RFNoC 4 replaces the highly parameterized RFNoC 3 Noc Shell with a per-block customized Noc Shell generated from the block’s Block Description YAML file. The Noc Shell generated via rfnocmodtool or the existing one in rfnoc-example is acceptable for most blocks that require one input and output data port.<br />
<br />
====Generating a Custom Noc Shell====<br />
<br />
Some blocks may need multiple data ports or other modifications. This requires editing the Block Description YAML file and then using the Python script rfnoc_create_verilog.py (found in uhd/host/utils/rfnoc_blocktool) to generate a new Noc Shell instance.<br />
<br />
The argument “-c” is used to provide the YAML file location. “-d” provides the output destination directory.<br />
<br />
''Note: It is suggested to not set the destination directory to your existing RFNoC block code, as the script will automatically overwrite the existing code!''<br />
<br />
Example usage:<br />
rfnoc_create_verilog.py -c ./rfnoc-example/rfnoc/blocks/gain.yml -d ./output/<br />
<br />
====Changing Noc ID without using rfnoc_create_verilog====<br />
<br />
In the generated Noc Shell Verilog code, a block’s Noc ID can be changed by updating the NOC_ID parameter on the ''backend_iface'' module. Make sure this matches the Noc ID in both the Block Description YAML file and Block Controller C++ code.<br />
<br />
====Goodbye AXI Wrapper====<br />
<br />
The RFNoC 3 version of Noc Shell outputs / accepts CHDR data packets consisting of a header, optional timestamp, and payload on a 64-bit AXI stream bus. Most designs then used a module called AXI Wrapper to handle the conversion between CHDR data packets and sample streams on a 32-bit AXI stream bus. AXI Wrapper also supported SIMPLE_MODE which for some use cases could transparently handle the header portion of the CHDR data packet. Otherwise, the user would need to set the header via m_axis_data_tuser.<br />
<br />
In RFNoC 4, Noc Shell has absorbed AXI Wrapper’s functionality. Noc Shell outputs two AXI stream buses per input / output port: a payload and context bus. The payload bus is in most cases identical to AXI Wrapper’s output: a 32-bit stream of samples on an AXI Stream bus with packets delimited by tlast. The context AXI stream bus carries the header, optional timestamp, and optional metadata. If your block used AXI Wrapper’s SIMPLE_MODE, then you can loop the context bus back into Noc Shell. If not, you will need to modify the context bus data. Refer to the [https://files.ettus.com/app_notes/RFNoC_Specification.pdf RFNoC Specification] for the format and timing diagram of the context bus.<br />
<br />
''Important Note: If your block used the AXI Rate Change module, Noc Shell has another data port mode to support this use case called '''axis_data''' that can be set in the Block Descriptor YAML file (see the fpga_iface entry). This mode causes the Noc Shell data ports to look more like AXI Wrapper’s and therefore makes them compatible with AXI Rate Change. See the DDC, DUC, or Keep One in N RFNoC Blocks for an example.''<br />
<br />
===Settings Bus replaced by CtrlPort===<br />
<br />
CtrlPort replaces the Settings Bus in RFNoC 4. The CtrlPort bus is similar to the Settings Bus with a few key differences. The table below compares the signaling between the two bus formats and provides notes on any differences. Timing diagrams and additional information on the CtrlPort bus is also available in the [https://files.ettus.com/app_notes/RFNoC_Specification.pdf RFNoC Specification].<br />
<br />
{| class="wikitable"<br />
! Settings Bus (RFNoC 3) || CtrlPort (RFNoC 4) || RFNoC 4 Notes<br />
|-<br />
| set_stb || ctrlport_reg_wr || Write strobe<br />
|-<br />
| set_addr || ctrlport_req_addr || 20-bits instead of 8-bits, increments by 4 instead of by 1, no reserved addresses (versus addresses 0-127 for Settings Bus)<br />
|-<br />
| set_data || ctrlport_req_data || Write data<br />
|-<br />
| N/A || ctrlport_req_rd || Read strobe equivalent of ctrlport_req_wr<br />
|-<br />
| rb_addr || N/A || CtrlPort uses ctrlport_req_addr for both '''read and write''' addresses<br />
|-<br />
| rb_data || ctrlport_resp_data || Read data, 32-bits instead of 64-bits<br />
|-<br />
| rb_stb || N/A || CtrlPort requires ack strobe for '''reads and writes'''<br />
|}<br />
<br />
<br />
One additional difference when using CtrlPort is that there is not an equivalent Settings Register module. The bus is simple enough to setup a clocked process to handle reading from and writing to registers. See the Verilog example below:<br />
<br />
// Note: Register addresses increment by 4<br />
localparam REG_USER_ADDR = 0; // Address for example user register<br />
localparam REG_USER_DEFAULT = 0; // Default value for user register<br />
<br />
reg [31:0] reg_user = REG_USER_DEFAULT;<br />
<br />
always @(posedge ctrlport_clk) begin<br />
if (ctrlport_rst) begin<br />
reg_user = REG_USER_DEFAULT;<br />
end else begin<br />
// Default assignment<br />
m_ctrlport_resp_ack <= 0;<br />
<br />
// Read user register<br />
if (m_ctrlport_req_rd) begin // Read request<br />
case (m_ctrlport_req_addr)<br />
REG_USER_ADDR: begin<br />
m_ctrlport_resp_ack <= 1;<br />
m_ctrlport_resp_data <= reg_user;<br />
end<br />
endcase<br />
end<br />
<br />
// Write user register<br />
if (m_ctrlport_req_wr) begin // Write requst<br />
case (m_ctrlport_req_addr)<br />
REG_USER_ADDR: begin<br />
m_ctrlport_resp_ack <= 1;<br />
reg_user <= m_ctrlport_req_data[31:0];<br />
end<br />
endcase<br />
end<br />
end<br />
end<br />
<br />
''Important Note: For blocks that make heavy use of the Settings Bus and/or Settings Registers, there is a CtrlPort to Settings Bus bridge available called '''ctrlport_to_settings_bus'''. See the Keep One In N RFNoC Block for example code on how to interface with it.''<br />
<br />
===Testbench Infrastructure===<br />
<br />
While RFNoC 4 does overhaul the RFNoC 3 testbench infrastructure API, most of the high level concepts remain the same. The table below outlines some of the commonly used RFNoC 3 functions / code and the RFNoC 4 equivalent.<br />
<br />
{| class="wikitable"<br />
! Operation || RFNoC 3 || RFNoC 4<br />
|-<br />
| Setup RFNoC<br />
||<br />
`RFNOC_SIM_INIT(...)<br />
`RFNOC_ADD_BLOCK(...)<br />
`RFNOC_CONNECT(...)<br />
||<br />
RfnocBlockCtrlBfm #(...) blk_ctrl = new(...);<br />
blk_ctrl.connect_master_data_port(...)<br />
blk_ctrl.connect_slave_data_port(...)<br />
''Note: Instantiate one Block Controller BFM per RFNoC Block''<br />
|-<br />
| Setup Test Cases<br />
||<br />
`TEST_CASE_START(...)<br />
`TEST_CASE_DONE(...)<br />
||<br />
test.start_test(...)<br />
test.end_test()<br />
|-<br />
| Register Read<br />
||<br />
tb_streamer.read_reg(...)<br />
||<br />
blk_ctrl.reg_read(...)<br />
|-<br />
| Register Write<br />
||<br />
tb_streamer.write_reg(...)<br />
||<br />
blk_ctrl.reg_write(...)<br />
|-<br />
| Send Data / Samples<br />
||<br />
tb_streamer.send(...)<br />
||<br />
blk_ctrl.send_items(...)<br />
|-<br />
| Receive Data / Samples<br />
||<br />
tb_streamer.recv(...)<br />
||<br />
blk_ctrl.recv_items(...)<br />
|}<br />
<br />
===Building FPGA images using Image Core YAML Files===<br />
<br />
RFNoC 4 replaces uhd_image_builder, the RFNoC 3 FPGA image building tool, with a new tool called rfnoc_image_builder. This tool produces a FPGA bitstream based on an Image Core YAML file that describes the device configuration (e.g. X310 with dual 10GigE) and included RFNoC blocks along with their connections (both static and dynamic), clocking, and I/O.<br />
<br />
Both rfnocmodtool and the UHD in-tree example called rfnoc-example automatically setup make targets to handle running rfnoc_image_builder. If you want to use rfnoc_image_builder directly, more details can be found in the [https://kb.ettus.com/Getting_Started_with_RFNoC_in_UHD_4.0 Getting Started with RFNoC in UHD 4.0].<br />
<br />
=GNU Radio Software Migration=<br />
<br />
RFNoC 4 supports GNU Radio 3.8 only. Most of your RFNoC Block’s GNU Radio related changes will be due to API differences between GNU Radio 3.7 to 3.8. These changes are outside of the scope of this article. Instead, refer to [https://wiki.gnuradio.org/index.php/GNU_Radio_3.8_OOT_Module_Porting_Guide GNU Radio 3.8 Migration Guide] and [https://wiki.gnuradio.org/index.php/YAML_GRC GNU Radio Companion YAML] sites for more information.<br />
<br />
Migration reference files for this section from Gain RFNoC Block example:<br />
<br />
{| class="wikitable"<br />
! Description || RFNoC 3 Files || RFNoC 4 Files<br />
|-<br />
| GNU Radio Block || lib/gain_impl.cc<br>lib/gain_impl.h<br>include/example/gain.h || lib/gain_impl.cc<br>lib/gain_impl.h<br>include/example/gain.h<br />
|-<br />
| GRC Block Description || grc/gain.xml || grc/gain.yml<br />
|-<br />
| Example GRC Flowgraph || examples/gain.grc || examples/gain.grc<br />
|}<br />
<br />
''Note: Files are relative to the rfnoc-example directory in the respective rfnoc3 and rfnoc4 directories''<br />
<br />
===RX & TX Streamer Blocks===<br />
<br />
When transition between a RFNoC block and a GNU Radio block or vice versa, you must insert either a RX stream or TX streamer block respectively. This differs from RFNoC 3, where a RFNoC block could be directly connected to a GNU Radio block.<br />
<br />
[[File:rx_tx_streamer.png|border]]<br />
<br />
===Setting RFNoC Block Properties Directly in GNU Radio===<br />
<br />
The base class for RFNoC Block’s in GNU Radio have a set of functions that provide a shortcut to getting and setting properties without writing custom class methods. The table below lists the functions.<br />
<br />
{| class="wikitable"<br />
! Property Type || Set Property || Get Property<br />
|-<br />
| Integer || set_int_property(...) || get_int_property(...)<br />
|-<br />
| Double || set_double_property(...) || get_double_property(...)<br />
|-<br />
| Bool || set_bool_property(...) || get_bool_property(...)<br />
|-<br />
| String || set_string_property(...) || get_string_property(...)<br />
|-<br />
|}<br />
<br />
'''Example code for GNU Radio Companion YAML Block Description file'''<br />
templates:<br />
imports: |-<br />
import example<br />
make: |-<br />
example.gain(<br />
self.rfnoc_graph,<br />
uhd.device_addr(${block_args}),<br />
${device_select},<br />
${instance_select})<br />
self.${id}.set_int_property('gain', ${gain})<br />
callbacks:<br />
- set_int_property('gain', ${gain})</div>JonathonPendlumhttps://kb.ettus.com/index.php?title=File:migration_example.zip&diff=5065File:migration example.zip2020-12-29T08:19:59Z<p>JonathonPendlum: Example designs for RFNoC 4 Migration Guide</p>
<hr />
<div>Example designs for RFNoC 4 Migration Guide</div>JonathonPendlumhttps://kb.ettus.com/index.php?title=RFNoC_4_Migration_Guide&diff=5064RFNoC 4 Migration Guide2020-12-29T08:06:04Z<p>JonathonPendlum: Created page with "=Abstract= The UHD 4.0 release includes a major upgrade to the RFNoC framework called RFNoC 4. This article is a guide to aid users in migrating their existing RFNoC blocks f..."</p>
<hr />
<div>=Abstract=<br />
<br />
The UHD 4.0 release includes a major upgrade to the RFNoC framework called RFNoC 4. This article is a guide to aid users in migrating their existing RFNoC blocks from RFNoC 3 to RFNoC 4. The RFNoC Block Development Environment section provides guidance on how to setup an environment for developing out-of-tree RFNoC blocks in RFNoC 4. The UHD, FPGA, GNU Radio Migration sections provide general information on topics that most users will encounter when migrating their blocks. Finally, an equivalent RFNoC 3 and RFNoC 4 implementation of a digital gain RFNoC Block has been provided as a reference.<br />
<br />
=Prerequisites=<br />
<br />
===Dependencies (Ubuntu 20.04)===<br />
git cmake g++ libboost-all-dev libgmp-dev swig \<br />
python3-numpy python3-mako python3-sphinx python3-lxml \<br />
doxygen libfftw3-dev libsdl1.2-dev libgsl-dev libqwt-qt5-dev \<br />
libqt5opengl5-dev python3-pyqt5 liblog4cpp5-dev libzmq3-dev \<br />
python3-yaml python3-click python3-click-plugins python3-zmq \<br />
python3-scipy python3-gi python3-gi-cairo gobject-introspection \<br />
gir1.2-gtk-3.0 build-essential libusb-1.0-0-dev python3-docutils \<br />
python3-setuptools python3-ruamel.yaml python-is-python3 \<br />
libtinfo5 libncurses5<br />
<br />
===Vivado 2019.1 Design Edition===<br />
<br />
Please reference to Xilinx (xilinx.com) for installation instructions.<br />
<br />
''Note: The dependencies step above included installing libtinfo5 libncurses5, which is a workaround for getting Vivado 2019.1 to run on Ubunbtu 20.04''<br />
<br />
===UHD 4.0===<br />
git clone --branch UHD-4.0 https://github.com/ettusresearch/uhd.git uhd<br />
mkdir uhd/host/build; cd uhd/host/build<br />
cmake ..<br />
make<br />
sudo make install<br />
<br />
===GNU Radio 3.8===<br />
'' Note: If your design does not use GNU Radio, then installing GNU Radio and gr-ettus is not required ''<br />
<br />
git clone --branch maint-3.8 --recursive https://github.com/gnuradio/gnuradio.git gnuradio<br />
mkdir gnuradio/build; cd gnuradio/build;<br />
cmake ..<br />
make<br />
sudo make install<br />
<br />
===gr-ettus===<br />
git clone --branch maint-3.8-uhd4.0 https://github.com/ettusresearch/gr-ettus.git gr-ettus<br />
mkdir gr-ettus/build; cd gr-ettus/build;<br />
cmake -DENABLE_QT=True ..<br />
make<br />
sudo make install<br />
<br />
=RFNoC Block Development Environment=<br />
<br />
Two options exist for developing RFNoC blocks depending on whether the your RFNoC block integrates with GNU Radio in an out-of-tree module or if it only uses UHD’s C++ API in a standalone application. The sections below outline how to setup the development environment for each scenario.<br />
<br />
===Migrating a GNU Radio Out-of-Tree Module===<br />
<br />
The tool rfnocmodtool automates the process of creating GNU Radio out-of-tree (OOT) modules that also have support for RFNoC blocks. This tool is part of gr-ettus and it has been ported to RFNoC 4.<br />
<br />
Due to changes in almost every source file, it is recommended to use rfnocmodtool to generate a new RFNoC block from scratch and then update the generated “skeleton” files.<br />
<br />
====Creating a RFNoC Block with rfnocmodtool====<br />
<br />
The following steps show how to create an OOT module called ''example'' and RFNoC block called ''gain'' using rfnocmodtool. The naming is only for example purposes.<br />
<br />
rfnocmodtool newmod<br />
Name of the new module: '''example'''<br />
<br />
cd rfnoc-tutorial<br />
rfnocmodtool add<br />
Enter name of block/code (without module name prefix): '''gain'''<br />
Enter valid argument list, including default arguments: ''(leave blank)''<br />
Add Python QA code? [y/N] '''N'''<br />
Add C++ QA code? [y/N] '''N'''<br />
Block NoC ID (Hexadecimal): ''(Enter Noc ID of your block)''<br />
Skip Block Controllers Generation? [UHD block ctrl files] [y/N] '''N'''<br />
Skip Block interface files Generation? [GRC block ctrl files] [y/N] '''N'''<br />
<br />
''Note: Noc IDs have been reduced from 64-bits in RFNoC 3 to 32-bits in RFNoC 4''<br />
<br />
The following are the relevant files that need to be updated when migrating your RFNoC Block.<br />
<br />
rfnoc-example/<br />
grc/<br />
example_gain.block.yml – RFNoC Block GNU Radio Companion YAML file<br />
examples/<br />
gain.grc – Example flowgraph using gain RFNoC Block<br />
include/tutorial/<br />
gain.h – GNU Radio block C++ header<br />
gain_block_ctrl.hpp – RFNoC Block Controller C++ header<br />
lib/<br />
gain_impl.cc – GNU Radio block C++ source<br />
gain_impl.h – GNU Radio block C++ header<br />
gain_block_ctrl_impl.cpp – RFNoC Block Controller C++ source<br />
rfnoc/blocks/<br />
gain.yml – RFNoC Block Description YAML file<br />
rfnoc/fpga/rfnoc_block_gain<br />
noc_shell_gain.v – RFNoC Block Noc Shell Verilog Source<br />
rfnoc_block_gain.v – RFNoC Block Verilog Source<br />
rfnoc_block_gain_tb.v – RFNoC Block Testbench<br />
rfnoc/icores<br />
gain_x310_rfnoc_image_core.yml – Image Core YAML file with gain block<br />
<br />
====Building OOT module====<br />
<br />
cd rfnoc-tutorial<br />
mkdir build; cd build<br />
cmake -DUHD_FPGA_DIR=''(path to uhd/fpga directory)'' ..<br />
make<br />
sudo make install<br />
<br />
====Running a testbench====<br />
CMake automatically creates makefile targets to run the generated testbench code for each added RFNoC block. For example, here is how to run the gain block testbench:<br />
<br />
cd rfnoc-tutorial/build<br />
make rfnoc_block_gain_tb<br />
<br />
====Building a FPGA image====<br />
CMake automatically creates makefile targets to build FPGA images using the generated image core yaml files found in rfnoc/icore. Every RFNoC block created by rfnocmodtool automatically has an image core yaml file generated in that directory. For example, here is how to build an FPGA image using the image core yaml file generated for the gain block:<br />
<br />
cd rfnoc-tutorial/build<br />
make gain_x310_rfnoc_image_core<br />
<br />
===Migrating a Standalone UHD C++ Application===<br />
<br />
For applications that only use the UHD API, an example out-of-tree (UHD source tree) RFNoC block exists called rfnoc-example. It is located in the UHD source at uhd/host/examples/rfnoc-example. This directory can be copied outside of the UHD source tree and used a starting point to migrate your RFNoC block.<br />
<br />
The following are the relevant files that need to be updated when migrating your RFNoC Block.<br />
<br />
rfnoc-example/<br />
apps/<br />
init_gain_block.cpp – Example C++ application testing gain block<br />
blocks/<br />
gain.yml – RFNoC Block Description YAML file<br />
fpga/rfnoc_block_gain<br />
noc_shell_gain.v – RFNoC Block Noc Shell Verilog Source<br />
rfnoc_block_gain.v – RFNoC Block Verilog Source<br />
rfnoc_block_gain_tb.v – RFNoC Block Testbench<br />
icores/<br />
x310_rfnoc_image_core.yml – Example Image Core YAML file<br />
include/rfnoc/example<br />
gain_block_control.hpp – RFNoC Block Controller C++ header<br />
lib/<br />
gain_block_control.cpp – RFNoC Block Controller C++ source<br />
<br />
====Building rfnoc-example====<br />
<br />
cd rfnoc-example<br />
mkdir build; cd build<br />
cmake ..<br />
make<br />
sudo make install<br />
<br />
====Running a testbench====<br />
CMake automatically creates makefile targets to run RFNoC Block testbench simulations. For every RFNoC block subdirectory listed in the CMakeLists.txt file in the rfnoc-example/fpga directory, a target with the RFNoC block name appended with “_tb” is added as a makefile target. For example, here is how to run the gain RFNoC block testbench:<br />
<br />
cd rfnoc-example/build<br />
make rfnoc_block_gain_tb<br />
<br />
====Building a FPGA image====<br />
CMake automatically creates makefile targets to build a FPGA image for each image core yaml file listed in the CMakeLists.txt file in the rfnoc-example/icore directory. Each image core yaml file must be listed in the CMakeLists.txt. For example, here is how to build an FPGA image using the image core yaml file generated for the gain block:<br />
<br />
cd rfnoc-tutorial/build<br />
make gain_x310_rfnoc_image_core<br />
<br />
=Example RFNoC 3 to RFNoC 4 Block Migration=<br />
<br />
Attached to this article is a ZIP file called '''''migration_example.zip'''''. This archive contains equivalent RFNoC 3 and RFNoC 4 versions of a RFNoC Block implementing digital gain. The following sections begin with outlining what files were updating during this example migration.<br />
<br />
=UHD Software Migration=<br />
<br />
Migration reference files for this section from Gain RFNoC Block example:<br />
<br />
{| class="wikitable"<br />
! Description || RFNoC 3 Files || RFNoC 4 Files<br />
|-<br />
| Block Description || rfnoc/blocks/gain.xml || lib/gain_block_ctrl_impl.cpp <br>include/example/gain_block_ctrl.hpp<br />
|-<br />
| Block Controller || rfnoc/blocks/gain.yml || lib/gain_block_ctrl_impl.cpp <br>include/example/gain_block_ctrl.hpp<br />
|}<br />
<br />
''Note: Files are relative to the rfnoc-example directory in the respective rfnoc3 and rfnoc4 directories''<br />
<br />
===Noc Script XML Replaced by Block Description YAML===<br />
<br />
RFNoC 3 used Noc Script XML, a domain specific language, to describe the configuration of a RFNoC block: the Noc ID, register names and addresses, args for writing to the registers, and the input/output ports.<br />
<br />
RFNoC 4 replaces the Noc Script XML file with an easier to read and edit Block Description YAML file format. From a high level, the Block Description YAML file serves a similar function as the Noc Script XML file, with some similarities and key differences outlined in table below:<br />
<br />
{| class="wikitable"<br />
! Item || Noc Script XML || Block Descript YAML || RFNoC 4 Notes<br />
|-<br />
| Block Name<br />
||<br />
<name>gain</name><br />
||<br />
module_name: gain<br />
||<br />
|-<br />
| Noc ID<br />
||<br />
<id>B160000000000000</id><br />
||<br />
noc_id: 0xB16<br />
||<br />
Noc ID are limited to 32-bits<br />
|-<br />
| Registers<br />
||<br />
<registers><br />
<setreg><br />
<name>GAIN</name><br />
<address>128</address><br />
</setreg><br />
</registers><br />
||<br />
N/A<br />
||<br />
Registers must be defined in the Block Controller<br />
|-<br />
| Arguments<br />
||<br />
<args><br />
<arg><br />
<name>gain</name><br />
<type>int</type><br />
...<br />
</arg><br />
</args><br />
||<br />
N/A<br />
||<br />
Args are implemented with properties in the Block Controller<br />
|-<br />
| Data Ports<br />
||<br />
<ports><br />
<sink><br />
<name>in</name><br />
</sink><br />
<source><br />
<name>out</name><br />
</source><br />
</ports><br />
||<br />
data:<br />
fpga_iface: axis_pyld_ctxt<br />
clk_domain: rfnoc_chdr<br />
inputs:<br />
in:<br />
...<br />
outputs:<br />
out:<br />
...<br />
||<br />
|-<br />
| Control Ports<br />
||<br />
N/A<br />
||<br />
control:<br />
sw_iface: nocscript<br />
fpga_iface: ctrlport<br />
interface_direction: slave<br />
...<br />
||<br />
|-<br />
| Clocking<br />
||<br />
N/A<br />
||<br />
clocks:<br />
- name: rfnoc_chdr<br />
freq: "[]"<br />
- name: rfnoc_ctrl<br />
freq: "[]"<br />
||<br />
|}<br />
<br />
''Note: For a more detailed description of the RFNoC 4 Block Description YAML syntax and the various options, see the [https://files.ettus.com/app_notes/RFNoC_Specification.pdf RFNoC Specification].''<br />
<br />
===RFNoC API Changes===<br />
<br />
Much of the user facing RFNoC software API has not changed or remains very similar between RFNoC 3 and RFNoC 4. The table below outlines some of the notable differences:<br />
<br />
{| class="wikitable"<br />
! RFNoC 3 || RFNoC 4 || RFNoC 4 Notes<br />
|-<br />
|<br />
usrp = uhd::device3::make(...)<br />
||<br />
graph = uhd::rfnoc::rfnoc_graph::make()<br />
||<br />
No longer need to create a device3 object<br />
|-<br />
|<br />
usrp->get_block_ctrl(...)<br />
||<br />
graph->get_block(...)<br />
||<br />
Rename<br />
|-<br />
|<br />
N/A<br />
||<br />
graph->enumerate_static_connections()<br />
||<br />
Used to check static connections, usually for detecting hwen a DDC or DUC is statically connected to the radio and requires setting the sample<br />
|-<br />
|<br />
usrp->get_tx_streamer(...)<br />
||<br />
graph->create_tx_streamer(...)<br />
||<br />
Rename<br />
|-<br />
|<br />
usrp->get_rx_streamer(...)<br />
||<br />
graph->create_rx_streamer(...)<br />
||<br />
Rename<br />
|-<br />
|<br />
N/A<br />
||<br />
graph->commit()<br />
||<br />
Commit graph and run initial checks<br />
|-<br />
|<br />
sr_write(...)<br />
||<br />
regs().poke32(...)<br />
||<br />
Address increments by 4<br />
|-<br />
|<br />
sr_read32(...)<br />
||<br />
regs().peek32(...)<br />
||<br />
Address increments by 4<br />
|-<br />
|<br />
sr_read64(...)<br />
||<br />
regs().poke64(...)<br />
||<br />
Address increments by 8<br />
|-<br />
|<br />
set_arg(...)<br />
||<br />
set_property(...)<br />
||<br />
Block args replaced with block properties concept<br />
|-<br />
|<br />
get_arg(...)<br />
||<br />
get_property(...)<br />
||<br />
Block args replaced with block properties concept<br />
|}<br />
<br />
===Block Properties===<br />
<br />
In RFNoC 3, RFNoC blocks can have arguments (also known as args) that are used to write user registers. This is implemented in the Noc Script XML in the <args> section.<br />
<br />
RFNoC 4 expands and generalizes this concept with block properties: a high-level representation of the state of the block. Zero or more properties can be defined by the user in their RFNoC Block’s Block Controller C++ class. When read or written to, they can trigger a call back to a user defined resolver function. The [https://files.ettus.com/app_notes/RFNoC_Specification.pdf RFNoC Specification] provides more details on properties in the “Block Properties” section.<br />
<br />
The following shows an example of how to migrate a RFNoC 3 Noc Script XML “arg” based register write to a RFNoC 4 property based implementation in the Block Controller:<br />
<br />
====RFNoC 3 Noc Script XML snippet====<br />
<registers><br />
<setreg><br />
<name>GAIN</name><br />
<address>128</address><br />
</setreg><br />
</registers><br />
<br />
<args><br />
<arg><br />
<name>gain</name><br />
<type>int</type><br />
<value>1</value><br />
<check>GE($gain, 0) AND LE($gain, 32767)</check><br />
<check_message>Gain must be in the range [0, 32767]</check_message><br />
<action>SR_WRITE("GAIN", $gain)</action><br />
</arg><br />
</args><br />
<br />
====RFNoC 4 Block Controller Class====<br />
<br />
// <registers><br />
// <setreg><br />
// <name>GAIN</name><br />
// <address>128</address><br />
// </setreg><br />
// </registers><br />
// Note: In RFNoC 4, register addresses can start at address 0 instead of address 128 as in RFNoC 3.<br />
const uint32_t gain_block_ctrl::REG_GAIN_ADDR = 128;<br />
const uint32_t gain_block_ctrl::REG_GAIN_DEFAULT = 1;<br />
<br />
class gain_block_ctrl_impl : public gain_block_ctrl<br />
{<br />
public:<br />
RFNOC_BLOCK_CONSTRUCTOR(gain_block_ctrl)<br />
{<br />
_register_props();<br />
}<br />
private:<br />
void _register_props()<br />
{<br />
register_property(&_user_reg, [this]() {<br />
int user_reg = this->_user_reg.get();<br />
// <check>GE($gain, 0) AND LE($gain, 32767)</check><br />
// <check_message>Gain must be in the range [0, 32767]</check_message><br />
if (user_reg < 0 || user_reg > 32767) {<br />
throw uhd::value_error("Size value must be in [0,32767]");<br />
}<br />
// <action>SR_WRITE("GAIN", $gain)</action><br />
this->regs().poke32(REG_USER_ADDR, user_reg);<br />
});<br />
}<br />
<br />
// <name>gain</name><br />
// <type>int</type><br />
// <value>1</value><br />
property_t<int> _user_reg{"gain", REG_USER_DEFAULT, {res_source_info::USER}};<br />
}<br />
<br />
As the above shows, writing to a register can be replicated with a property and a resolver function. Of course, the resolver function can also be made much more sophisticated. For additional examples, see the in-tree block controllers in uhd/host/lib/rfnoc.<br />
<br />
=FPGA Migration=<br />
<br />
Migration reference files for this section from Gain RFNoC Block example:<br />
<br />
{| class="wikitable"<br />
! Description || RFNoC 3 Files || RFNoC 4 Files<br />
|-<br />
| Block Verilog Code || rfnoc/fpga-src/noc_block_gain.v || rfnoc/fpga/rfnoc_block_gain/rfnoc_block_gain.v<br />
|-<br />
| Block Noc Shell || N/A || rfnoc/fpga/rfnoc_block_gain/noc_shell_gain.v<br />
|-<br />
| Block Testbnech || rfnoc/testbench/noc_block_gain/noc_block_gain_tb.sv || rfnoc/fpga/rfnoc_block_gain/rfnoc_block_gain_tb.sv<br />
|-<br />
| Image Core || N/A || rfnoc/icores/gain_x310_rfnoc_image_core.yml<br />
|}<br />
<br />
''Note: Files are relative to the rfnoc-example directory in the respective rfnoc3 and rfnoc4 directories''<br />
<br />
===Noc Shell Changes===<br />
<br />
RFNoC 4 replaces the highly parameterized RFNoC 3 Noc Shell with a per-block customized Noc Shell generated from the block’s Block Description YAML file. The Noc Shell generated via rfnocmodtool or the existing one in rfnoc-example is acceptable for most blocks that require one input and output data port.<br />
<br />
====Generating a Custom Noc Shell====<br />
<br />
Some blocks may need multiple data ports or other modifications. This requires editing the Block Description YAML file and then using the Python script rfnoc_create_verilog.py (found in uhd/host/utils/rfnoc_blocktool) to generate a new Noc Shell instance.<br />
<br />
The argument “-c” is used to provide the YAML file location. “-d” provides the output destination directory.<br />
<br />
''Note: It is suggested to not set the destination directory to your existing RFNoC block code, as the script will automatically overwrite the existing code!''<br />
<br />
Example usage:<br />
rfnoc_create_verilog.py -c ./rfnoc-example/rfnoc/blocks/gain.yml -d ./output/<br />
<br />
====Changing Noc ID without using rfnoc_create_verilog====<br />
<br />
In the generated Noc Shell Verilog code, a block’s Noc ID can be changed by updating the NOC_ID parameter on the ''backend_iface'' module. Make sure this matches the Noc ID in both the Block Description YAML file and Block Controller C++ code.<br />
<br />
====Goodbye AXI Wrapper====<br />
<br />
The RFNoC 3 version of Noc Shell outputs / accepts CHDR data packets consisting of a header, optional timestamp, and payload on a 64-bit AXI stream bus. Most designs then used a module called AXI Wrapper to handle the conversion between CHDR data packets and sample streams on a 32-bit AXI stream bus. AXI Wrapper also supported SIMPLE_MODE which for some use cases could transparently handle the header portion of the CHDR data packet. Otherwise, the user would need to set the header via m_axis_data_tuser.<br />
<br />
In RFNoC 4, Noc Shell has absorbed AXI Wrapper’s functionality. Noc Shell outputs two AXI stream buses per input / output port: a payload and context bus. The payload bus is in most cases identical to AXI Wrapper’s output: a 32-bit stream of samples on an AXI Stream bus with packets delimited by tlast. The context AXI stream bus carries the header, optional timestamp, and optional metadata. If your block used AXI Wrapper’s SIMPLE_MODE, then you can loop the context bus back into Noc Shell. If not, you will need to modify the context bus data. Refer to the [https://files.ettus.com/app_notes/RFNoC_Specification.pdf RFNoC Specification] for the format and timing diagram of the context bus.<br />
<br />
''Important Note: If your block used the AXI Rate Change module, Noc Shell has another data port mode to support this use case called '''axis_data''' that can be set in the Block Descriptor YAML file (see the fpga_iface entry). This mode causes the Noc Shell data ports to look more like AXI Wrapper’s and therefore makes them compatible with AXI Rate Change. See the DDC, DUC, or Keep One in N RFNoC Blocks for an example.''<br />
<br />
===Settings Bus replaced by CtrlPort===<br />
<br />
CtrlPort replaces the Settings Bus in RFNoC 4. The CtrlPort bus is similar to the Settings Bus with a few key differences. The table below compares the signaling between the two bus formats and provides notes on any differences. Timing diagrams and additional information on the CtrlPort bus is also available in the [https://files.ettus.com/app_notes/RFNoC_Specification.pdf RFNoC Specification].<br />
<br />
{| class="wikitable"<br />
! Settings Bus (RFNoC 3) || CtrlPort (RFNoC 4) || RFNoC 4 Notes<br />
|-<br />
| set_stb || ctrlport_reg_wr || Write strobe<br />
|-<br />
| set_addr || ctrlport_req_addr || 20-bits instead of 8-bits, increments by 4 instead of by 1, no reserved addresses (versus addresses 0-127 for Settings Bus)<br />
|-<br />
| set_data || ctrlport_req_data || Write data<br />
|-<br />
| N/A || ctrlport_req_rd || Read strobe equivalent of ctrlport_req_wr<br />
|-<br />
| rb_addr || N/A || CtrlPort uses ctrlport_req_addr for both '''read and write''' addresses<br />
|-<br />
| rb_data || ctrlport_resp_data || Read data, 32-bits instead of 64-bits<br />
|-<br />
| rb_stb || N/A || CtrlPort requires ack strobe for '''reads and writes'''<br />
|}<br />
<br />
<br />
One additional difference when using CtrlPort is that there is not an equivalent Settings Register module. The bus is simple enough to setup a clocked process to handle reading from and writing to registers. See the Verilog example below:<br />
<br />
// Note: Register addresses increment by 4<br />
localparam REG_USER_ADDR = 0; // Address for example user register<br />
localparam REG_USER_DEFAULT = 0; // Default value for user register<br />
<br />
reg [31:0] reg_user = REG_USER_DEFAULT;<br />
<br />
always @(posedge ctrlport_clk) begin<br />
if (ctrlport_rst) begin<br />
reg_user = REG_USER_DEFAULT;<br />
end else begin<br />
// Default assignment<br />
m_ctrlport_resp_ack <= 0;<br />
<br />
// Read user register<br />
if (m_ctrlport_req_rd) begin // Read request<br />
case (m_ctrlport_req_addr)<br />
REG_USER_ADDR: begin<br />
m_ctrlport_resp_ack <= 1;<br />
m_ctrlport_resp_data <= reg_user;<br />
end<br />
endcase<br />
end<br />
<br />
// Write user register<br />
if (m_ctrlport_req_wr) begin // Write requst<br />
case (m_ctrlport_req_addr)<br />
REG_USER_ADDR: begin<br />
m_ctrlport_resp_ack <= 1;<br />
reg_user <= m_ctrlport_req_data[31:0];<br />
end<br />
endcase<br />
end<br />
end<br />
end<br />
<br />
''Important Note: For blocks that make heavy use of the Settings Bus and/or Settings Registers, there is a CtrlPort to Settings Bus bridge available called '''ctrlport_to_settings_bus'''. See the Keep One In N RFNoC Block for example code on how to interface with it.''<br />
<br />
===Testbench Infrastructure===<br />
<br />
While RFNoC 4 does overhaul the RFNoC 3 testbench infrastructure API, most of the high level concepts remain the same. The table below outlines some of the commonly used RFNoC 3 functions / code and the RFNoC 4 equivalent.<br />
<br />
{| class="wikitable"<br />
! Operation || RFNoC 3 || RFNoC 4<br />
|-<br />
| Setup RFNoC<br />
||<br />
`RFNOC_SIM_INIT(...)<br />
`RFNOC_ADD_BLOCK(...)<br />
`RFNOC_CONNECT(...)<br />
||<br />
RfnocBlockCtrlBfm #(...) blk_ctrl = new(...);<br />
blk_ctrl.connect_master_data_port(...)<br />
blk_ctrl.connect_slave_data_port(...)<br />
''Note: Instantiate one Block Controller BFM per RFNoC Block''<br />
|-<br />
| Setup Test Cases<br />
||<br />
`TEST_CASE_START(...)<br />
`TEST_CASE_DONE(...)<br />
||<br />
test.start_test(...)<br />
test.end_test()<br />
|-<br />
| Register Read<br />
||<br />
tb_streamer.read_reg(...)<br />
||<br />
blk_ctrl.reg_read(...)<br />
|-<br />
| Register Write<br />
||<br />
tb_streamer.write_reg(...)<br />
||<br />
blk_ctrl.reg_write(...)<br />
|-<br />
| Send Data / Samples<br />
||<br />
tb_streamer.send(...)<br />
||<br />
blk_ctrl.send_items(...)<br />
|-<br />
| Receive Data / Samples<br />
||<br />
tb_streamer.recv(...)<br />
||<br />
blk_ctrl.recv_items(...)<br />
|}<br />
<br />
===Building FPGA images using Image Core YAML Files===<br />
<br />
RFNoC 4 replaces uhd_image_builder, the RFNoC 3 FPGA image building tool, with a new tool called rfnoc_image_builder. This tool produces a FPGA bitstream based on an Image Core YAML file that describes the device configuration (e.g. X310 with dual 10GigE) and included RFNoC blocks along with their connections (both static and dynamic), clocking, and I/O.<br />
<br />
Both rfnocmodtool and the UHD in-tree example called rfnoc-example automatically setup make targets to handle running rfnoc_image_builder. If you want to use rfnoc_image_builder directly, more details can be found in the [https://kb.ettus.com/Getting_Started_with_RFNoC_in_UHD_4.0 Getting Started with RFNoC in UHD 4.0].<br />
<br />
=GNU Radio Software Migration=<br />
<br />
RFNoC 4 supports GNU Radio 3.8 only. Most of your RFNoC Block’s GNU Radio related changes will be due to API differences between GNU Radio 3.7 to 3.8. These changes are outside of the scope of this article. Instead, refer to [https://wiki.gnuradio.org/index.php/GNU_Radio_3.8_OOT_Module_Porting_Guide GNU Radio 3.8 Migration Guide] and [https://wiki.gnuradio.org/index.php/YAML_GRC GNU Radio Companion YAML] sites for more information.<br />
<br />
Migration reference files for this section from Gain RFNoC Block example:<br />
<br />
{| class="wikitable"<br />
! Description || RFNoC 3 Files || RFNoC 4 Files<br />
|-<br />
| GNU Radio Block || lib/gain_impl.cc<br>lib/gain_impl.h<br>include/example/gain.h || lib/gain_impl.cc<br>lib/gain_impl.h<br>include/example/gain.h<br />
|-<br />
| GRC Block Description || grc/gain.xml || grc/gain.yml<br />
|-<br />
| Example GRC Flowgraph || examples/gain.grc || examples/gain.grc<br />
|}<br />
<br />
''Note: Files are relative to the rfnoc-example directory in the respective rfnoc3 and rfnoc4 directories''<br />
<br />
===RX & TX Streamer Blocks===<br />
<br />
When transition between a RFNoC block and a GNU Radio block or vice versa, you must insert either a RX stream or TX streamer block respectively. This differs from RFNoC 3, where a RFNoC block could be directly connected to a GNU Radio block.<br />
<br />
[[File:rx_tx_streamer.png|border]]<br />
<br />
===Setting RFNoC Block Properties Directly in GNU Radio===<br />
<br />
The base class for RFNoC Block’s in GNU Radio have a set of functions that provide a shortcut to getting and setting properties without writing custom class methods. The table below lists the functions.<br />
<br />
{| class="wikitable"<br />
! Property Type || Set Property || Get Property<br />
|-<br />
| Integer || set_int_property(...) || get_int_property(...)<br />
|-<br />
| Double || set_double_property(...) || get_double_property(...)<br />
|-<br />
| Bool || set_bool_property(...) || get_bool_property(...)<br />
|-<br />
| String || set_string_property(...) || get_string_property(...)<br />
|-<br />
|}<br />
<br />
'''Example code for GNU Radio Companion YAML Block Description file'''<br />
templates:<br />
imports: |-<br />
import example<br />
make: |-<br />
example.gain(<br />
self.rfnoc_graph,<br />
uhd.device_addr(${block_args}),<br />
${device_select},<br />
${instance_select})<br />
self.${id}.set_int_property('gain', ${gain})<br />
callbacks:<br />
- set_int_property('gain', ${gain})</div>JonathonPendlumhttps://kb.ettus.com/index.php?title=File:rx_tx_streamer.png&diff=5063File:rx tx streamer.png2020-12-29T07:59:55Z<p>JonathonPendlum: Diagram for RFNoC 4 Migration Guide</p>
<hr />
<div>Diagram for RFNoC 4 Migration Guide</div>JonathonPendlumhttps://kb.ettus.com/index.php?title=File:rfnoc4_workshop_slides_2020_part_2.pdf&diff=5055File:rfnoc4 workshop slides 2020 part 2.pdf2020-12-16T05:17:16Z<p>JonathonPendlum: RFNoC4 slides presented at GRCon 2020. Part 2 of 2.</p>
<hr />
<div>RFNoC4 slides presented at GRCon 2020. Part 2 of 2.</div>JonathonPendlumhttps://kb.ettus.com/index.php?title=File:rfnoc4_workshop_slides_2020_part_1.pdf&diff=5054File:rfnoc4 workshop slides 2020 part 1.pdf2020-12-16T05:13:05Z<p>JonathonPendlum: RFNoC4 slides presented at GRCon 2020. Part 1 of 2.</p>
<hr />
<div>RFNoC4 slides presented at GRCon 2020. Part 1 of 2.</div>JonathonPendlumhttps://kb.ettus.com/index.php?title=File:rfnoc3_workshop_slides_202008_part_2.pdf&diff=5053File:rfnoc3 workshop slides 202008 part 2.pdf2020-12-16T05:05:21Z<p>JonathonPendlum: RFNoC3 slides presented at NEWSDR 2020. This is the final revision of these slides as RFNoC4 has been released. Part 2 of 2.</p>
<hr />
<div>RFNoC3 slides presented at NEWSDR 2020. This is the final revision of these slides as RFNoC4 has been released. Part 2 of 2.</div>JonathonPendlumhttps://kb.ettus.com/index.php?title=File:rfnoc3_workshop_slides_202008_part_1.pdf&diff=5052File:rfnoc3 workshop slides 202008 part 1.pdf2020-12-16T05:03:37Z<p>JonathonPendlum: RFNoC3 slides presented at NEWSDR 2020. This is the final revision of these slides as RFNoC4 has been released. Part 1 of 2.</p>
<hr />
<div>RFNoC3 slides presented at NEWSDR 2020. This is the final revision of these slides as RFNoC4 has been released. Part 1 of 2.</div>JonathonPendlum