Ettus Knowledge Base - User contributions [en]

USRP N300/N310/N320/N321 Getting Started Guide

2026-08-05T14:30:00Z

JonathonPendlum: Correct 1Gb Streaming SFP Port 0 section, "RJ45 - SFP+ adapter" corrected to "SFP to RJ45 adapter"

==Kit Contents==
===N300===
{|
|style="vertical-align:top"|
* USRP N300
* DC Power Supply (12V, 7A)
* 1 SFP to RJ45 Adapter
* 1 Gigabit Ethernet Cat-5e Cable (3m)
* USB-A to Micro USB-B Cable (1m)
* Getting Started Guide
* Ettus Research Sticker
||[[File:n300 kit.png|450px|center]]
|}
===N310===

{|
|style="vertical-align:top"|
* USRP N310
* DC Power Supply (12V, 7A)
* 1 SFP to RJ45 Adapter
* 1 Gigabit Ethernet Cat-5e Cable (3m)
* USB-A to Micro USB-B Cable (1m)
* Getting Started Guide
* Ettus Research Sticker
||[[File:n310 kit.png|500px|center]]
|}

===N320===

{|
|style="vertical-align:top"|
* USRP N320
* DC Power Supply (12V, 7A)
* 1 SFP to RJ45 Adapter
* 1 Gigabit Ethernet Cat-5e Cable (3m)
* USB-A to Micro USB-B Cable (1m)
* Getting Started Guide
* Ettus Research Sticker
|[[File:n320 kit.png|500px|center]]
|}

===N321===

{|
|style="vertical-align:top"|
* USRP N321
* DC Power Supply (12V, 7A)
* 1 SFP to RJ45 Adapter
* 1 Gigabit Ethernet Cat-5e Cable (3m)
* USB-A to Micro USB-B Cable (1m)
* Getting Started Guide
* Ettus Research Sticker
||[[File:n321 kit.png|500px|center]]
|}

==Verify the Contents of Your Kit==

Ensure that your kit contains all the items listed above.

==You Will Need==
* microSD Card Writer

* For Network Mode: A host computer with an available 1 or 10 Gigabit Ethernet interface for sample streaming. In addition to the Ethernet interface used for sampling streaming, your host computer will require a separate 1 Gigabit Ethernet interface for command and control streaming.

* For Stand-Alone Embedded Mode: A host computer with an available 1 Gigabit Ethernet port or a USB 2.0 port to remotely access the embedded Linux operating system running on ARM CPU.

==Proper Care and Handling==
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.

* Never allow metal objects to touch the circuit board while powered.
* Always properly terminate the transmit port with an antenna or 50Ω load.
* Always handle the board with proper anti-static methods.
* Never allow the board to directly or indirectly come into contact with any voltage spikes.
* Never allow any water or condensing moisture to come into contact with the device.
* Always use caution with FPGA, firmware, or software modifications.

{|
|style="padding-left:10px; padding-right:10px; padding-bottom:10px;" |[[File:Caution.png|24px|center]]
|style="padding-left:10px; padding-right:10px; padding-bottom:10px;" |Never apply more than -15 dBm of power into any RF input.
|-
|style="padding-left:10px; padding-right:10px; padding-bottom:10px;" |[[File:Caution.png|24px|center]]
|style="padding-left:10px; padding-right:10px; padding-bottom:10px;" |Always use at least 30dB attenuation if operating in loopback configuration
|-
|}

==Install and Setup the Software Tools on Your Host Computer==
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.

To find the latest release of UHD, see the UHD repository at https://github.com/EttusResearch/uhd.

The USRP N310 requires UHD version 3.11.0.0 or later.

The USRP N300 requires UHD version 3.12.0.0 or later.

The USRP N320/N321 requires UHD version 3.14.0.0 or later.

White Rabbit Ethernet-Based Synchronization of the N3xx USRP requires UHD version 3.12.0.0 or later. For additional details on White Rabbit Ethernet-Based Synchronization, please see the application note, [[Using Ethernet-Based Synchronization on the USRP™ N3xx Devices]].

'''When you receive a brand-new device, it is strongly recommended that you download the most recent filesystem image from the Ettus Research website and write it to the SD card that comes with the unit. It is not recommended that you use the SD card from the factory as-is. Instructions on downloading the latest filesystem image and writing it to the SD card are listed below.'''

'''Note that if you are operating the device in Network Mode, the version of UHD running on the host computer and the USRP N3xx must match.'''

==Connecting the Device==
===Interfaces Overview===
Listed below are the interfaces to connect to the USRP N3xx. Each interface has specific functionality, limitations and purpose.

'''Serial Console'''

The Serial Console provides a low level interface to the device typically used for debugging.

'''1 Gigabit RJ45 Connection'''

The 1 Gigabit RJ45 Connection interfaces with the on-board ARM CPU. When operated in "Network mode", this interface can optionally be used for UHD management traffic. Regardless of the operation mode (Network vs Embedded) this interface can be used to connect to the ARM via SSH. By default, the 1Gb RJ45 connection is configured to use a DHCP assigned IP address.

'''Dual SFP+ Connections'''

The Dual SFP+ Connections support multiple configurations for streaming high-speed, low-latency data, depending upon the FPGA image which is loaded.

'''QSFP+ Connection (N320/ N321 Only)'''

The QSFP+ Connection supports 2 x 10Gb lanes for streaming high-speed, low-latency data, while the onboard SFP0 connection is used for White Rabbit Ethernet-Based Synchronization.

===Setting up a Serial Console Connection===
It is possible to gain shell access to the device using a serial terminal emulator via the Serial Console port. Most Linux, OSX, or other Unix based operating systems have a tool called <code>screen</code> which can be used for this purpose.

If you do not have <code>screen</code> installed, it can be installed via your package manager. For Ubuntu/Debian based operating systems it can be installed with <code>apt</code> such as:

sudo apt install screen

The default Baud Rate for the Serial Console is: <code>115200</code>

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>:

$ ls /dev/serial/by-id
usb-Digilent_Digilent_USB_Device_25163511FE00-if00-port0
usb-Digilent_Digilent_USB_Device_25163511FE00-if01-port0
usb-Silicon_Labs_CP2105_Dual_USB_to_UART_Bridge_Controller_007F6CB5-if00-port0
usb-Silicon_Labs_CP2105_Dual_USB_to_UART_Bridge_Controller_007F6CB5-if01-port0

NOTE: Exact names depend on the host operating system version and may differ.

Every N3XX 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>ARM CPU</code>, whereas the second connects to the <code>STM32 Microcontroller</code>.

If you have multiple N3xx Serial Consoles connected to a single host, you may have to empirically test nodes.

Connecting to the ARM CPU can be performed with the command:

$ sudo screen /dev/serial/by-id/usb-Silicon_Labs_CP2105_Dual_USB_to_UART_Bridge_Controller_007F6CB5-if00-port0 115200

Upon starting the USRP N3xx, boot messages will appear and rapidly update. Once the boot process successfully completes, a login prompt like the following should appear:

OpenEmbedded test ni-n3xx-313ABDA ttyPS0

ni-n3xx-313ABDA login:

Enter the username: <code>root</code>

By default, the <code>root</code> user's password is left blank. Press the <code>Enter</code> key when prompted for a password.

You should now be presented with a shell prompt similar to the following:

root@ni-n3xx-<motherboard serial #>:~#

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.

====Connecting to the microcontroller====

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.

$ sudo screen /dev/serial/by-id/usb-Silicon_Labs_CP2105_Dual_USB_to_UART_Bridge_Controller_007F6CB5-if01-port0 115200

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.

===Connecting to the ARM via SSH===
By default, the RJ45 1Gb management interface is configured to be assigned a DHCP IP address.

If you have access to a network which provides a DHCP server (such as a common router's LAN), attach the RJ45 1Gb 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.

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>:

Example Output:

<pre>
# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.151/24 brd 192.168.1.255 scope global dynamic eth0
valid_lft 42865sec preferred_lft 42865sec
3: sfp0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc pfifo_fast qlen 1000
link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
inet 192.168.10.2/24 brd 192.168.10.255 scope global sfp0
valid_lft forever preferred_lft forever
4: sfp1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 9000 qdisc pfifo_fast qlen 1000
link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
</pre>

If you do not have access to a network with a DHCP server, you can create one using the Linux utility <code>dnsmasq</code>:

$ sudo dnsmasq -i <ETHERNET_ADAPTER_NAME> --dhcp-range=192.168.1.151,192.168.1.254 --except-interface=lo --bind-dynamic --no-daemon

NOTE: Modify the value <code><ETHERNET_ADAPTER_NAME></code> to match the interface you would like to create a DHCP server on.

After the device has obtained an IP address, you can remotely log into it from a Linux or macOS system with SSH, as shown below:

$ ssh root@192.168.1.151

NOTE: The IP address may vary depending on your network setup.

NOTE: The <code>root</code> password default password is empty/blank.

On Microsoft Windows, the SSH connection can be established using the third-party program Putty.

After logging in, you should be presented with a shell like the following:

root@ni-n3xx-<motherboard serial #>:~#

==Updating the Linux File System==
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 N3xx USRP must match.

There is two ways to update the file system for the N3xx USRP:

1. Mender

2. Physically remove microSD card from device and write a new file system to the microSD card.

===File System Partition Layout===
The SD Card is divided into four partitions. There is two root file system partitions, a boot partition and a data partition.

Any data you would like to preserve through Mender updates should be saved to the <code>data</code> partition, which is mounted at <code>/data</code>.

===Updating the file system with Mender===
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.

====Mender Update Process====

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.

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.

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:
$ sudo uhd_images_downloader -t mender -t n3xx --yes

Example Output:
[INFO] Using base URL: https://files.ettus.com/binaries/cache/
[INFO] Images destination: /usr/local/share/uhd/images
365684 kB / 365684 kB (100%) n3xx_common_mender_default-v4.6.0.0.zip
[INFO] Images download complete.

The downloaded "zip" archive is extracted into the <code>Images destination</code> directory with the filename <code>usrp_n3xx_fs.mender</code>. Next, you will need to copy this Mender file system image from the <code>Images destination</code> directory to the USRP N3xx to have its filesystem changed. This can be done with the Linux utility <code>scp</code>, for example as follows:

$ scp /usr/local/share/uhd/images/usrp_n3xx_fs.mender root@192.168.1.51:~/.

Note: The path and IP may be different for your configuration; the command above assumes you're using the default UHD installation path of <code>/usr/local</code> and that the N3xx's IP is <code>192.168.1.51</code>.

After copying the Mender file system image to the N3xx, connect to the N3xx to gain shell access via either the Serial Console or SSH.

On the N3xx, you first need to determine the version of UHD currently running on the USRP; an easy way to do this is via the command
# uhd_config_info --version

Example output:
UHD 3.14.1.1-0-g0347a6d8

The mender command to execute is different for UHD version 4.0 or newer versus prior to version 4.0. For the former use <code>mender install</code> followed by the mender file; for the latter use <code>mender -f -rootfs</code> followed by the mender file. Starting with UHD version 4.0 one can use mender to upgrade or downgrade the UHD filesystem version between any UHD v4 versions (e.g., 4.1 to 4.6; 4.6 to 4.1). The following commands assume that the UHD filesystem is version 4; if not then substitute the other mender command.

Run <code>mender install /path/to/latest.mender</code> to update the file system, e.g.:

# mender install usrp_n3xx_fs.mender

The artifact can also be stored on a remote server:
# mender install <nowiki>http://server.name/path/to/latest.mender</nowiki>

This procedure will take a quite a few minutes to complete. While executing, mender will show progress, e.g.:
................................ 0% 1024 KiB
...
................................ 1% 4096 KiB
...
................................ 99% 386048 KiB
............ 100% 386458 KiB
INFO[3865] wrote 7851737088/7851737088 bytes of update to device /dev/mmcblk0p3 module=device
INFO[3871] Enabling partition with new image installed to be a boot candidate: 3 module=device

After mender has logged a successful update, reboot the device:
# reboot

Upon reboot log back in to the USRP N3xx and run the command <code>uhd_find_devices</code> to verify that the UHD version is as desired and that the command runs successfully -- it should find at a minimum the USRP it is being executed on and will find more if other USRPs are on the same network.

If upon reboot the device is not working or the UHD version is not as desired, then the easiest way forward is to [https://kb.ettus.com/USRP_N300/N310/N320/N321_Getting_Started_Guide#Updating_the_files_system_by_writing_the_disk_image overwrite the sdcard filesystem manually] with the desired UHD version.

If upon reboot everything is as desired and the device seems functional, then commit the changes so that the boot loader knows to permanently boot into this partition:
# mender commit

To identify the currently installed Mender artifact from the command line, the following file can be queried on the N3xx:
# mender show-artifact

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.

For more information on updating the filesystem, refer to the [https://files.ettus.com/manual/ UHD Manual].

===Updating the files system by writing the disk image===
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 SD card.

==Updating the Network Configurations==
The USRP N3xx systemd network configuration files are located at: <code>/data/network/</code>

# ls /data/network/
eth0.network int0.network sfp0.network sfp1.network

or for older versions of the file system: <code>/etc/systemd/network/</code>

# ls /etc/systemd/network/
eth0.network sfp0.network sfp1.network

For details on configuration please refer to the [https://www.freedesktop.org/software/systemd/man/systemd.network.html systemd-networkd manual pages].

The factory settings are as follows:
<pre>
eth0 (DHCP):

[Match]
Name=eth0

[Network]
DHCP=ipv4

[DHCP]
UseHostname=false

sfp0 (static):

[Match]
Name=sfp0

[Network]
Address=192.168.10.2/24

[Link]
MTUBytes=9000

sfp1 (static):

[Match]
Name=sfp1

[Network]
Address=192.168.20.2/24

[Link]
MTUBytes=9000
</pre>

Additional notes on networking:

* 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>/etc/systemd/network/sfp0.network~</code>), that <code>systemd-networkd</code> might accidentally pick up.
* 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.
* If the MTU of the device and host computers differ, streaming issues can occur.
* Streaming via SFP0 at 1 Gb rates requires a MTU of <code>1500</code>
* Streaming via SFP0 at 10 Gb rates requires a MTU of <code>9000</code>

For addition details on network configuration here: https://files.ettus.com/manual/page_usrp_n3xx.html#n3xx_network_configuration

==Updating the FPGA Image==

===Network Mode FPGA Image Update===
The FPGA image should match the version of UHD installed on the host computer, when operated in Network mode. Connect the device to the host computer using either the RJ45 or SFP+ port, refer to the section above for detailed instructions.

To obtain all the FPGA images for a specific version of UHD, run the following command on the host computer with internet access:

$ sudo uhd_images_downloader

Example Output:

$ sudo uhd_images_downloader
[INFO] Images destination: /usr/local/share/uhd/images
00006 kB / 00006 kB (100%) usrp1_b100_fw_default-g6bea23d.zip
19810 kB / 19810 kB (100%) x3xx_x310_fpga_default-gf1ba32fe.zip
02757 kB / 02757 kB (100%) usrp2_n210_fpga_default-g6bea23d.zip
02123 kB / 02123 kB (100%) n230_n230_fpga_default-ge57dfe0.zip
00522 kB / 00522 kB (100%) usrp1_b100_fpga_default-g6bea23d.zip
00491 kB / 00491 kB (100%) b2xx_b200_fpga_default-ge57dfe0.zip
02415 kB / 02415 kB (100%) usrp2_n200_fpga_default-g6bea23d.zip
08988 kB / 08988 kB (100%) e3xx_e320_fpga_default-g3de8954a.zip
23045 kB / 23045 kB (100%) n3xx_n310_fpga_default-g3de8954a.zip
00523 kB / 00523 kB (100%) b2xx_b205mini_fpga_default-ge57dfe0.zip
18937 kB / 18937 kB (100%) x3xx_x300_fpga_default-gf1ba32fe.zip
00017 kB / 00017 kB (100%) octoclock_octoclock_fw_default-g14000041.zip
00007 kB / 00007 kB (100%) usrp2_usrp2_fw_default-g6bea23d.zip
00009 kB / 00009 kB (100%) usrp2_n200_fw_default-g6bea23d.zip
00450 kB / 00450 kB (100%) usrp2_usrp2_fpga_default-g6bea23d.zip
00144 kB / 00144 kB (100%) b2xx_common_fw_default-ga69ab0c.zip
25107 kB / 25107 kB (100%) n3xx_n320_fpga_default-g3de8954a.zip
00464 kB / 00464 kB (100%) b2xx_b200mini_fpga_default-ge57dfe0.zip
00319 kB / 00319 kB (100%) usrp1_usrp1_fpga_default-g6bea23d.zip
04839 kB / 04839 kB (100%) usb_common_windrv_default-g14000041.zip
00009 kB / 00009 kB (100%) usrp2_n210_fw_default-g6bea23d.zip
16065 kB / 16065 kB (100%) n3xx_n300_fpga_default-g3de8954a.zip
05578 kB / 05578 kB (100%) e3xx_e310_fpga_default-g4bc2c6f.zip
00885 kB / 00885 kB (100%) b2xx_b210_fpga_default-ge57dfe0.zip
[INFO] Images download complete.

NOTE: In the above example output, the Images Destination folder is printed:

[INFO] Images destination: /usr/local/share/uhd/images

To list the N3xx FPGA images with a full path, run the command:

$ ls -w 1 /usr/local/share/uhd/images/usrp_n3*.bit

/usr/local/share/uhd/images/usrp_n300_fpga_AA.bit
/usr/local/share/uhd/images/usrp_n300_fpga_HG.bit
/usr/local/share/uhd/images/usrp_n300_fpga_WX.bit
/usr/local/share/uhd/images/usrp_n300_fpga_XG.bit
/usr/local/share/uhd/images/usrp_n310_fpga_AA.bit
/usr/local/share/uhd/images/usrp_n310_fpga_HG.bit
/usr/local/share/uhd/images/usrp_n310_fpga_WX.bit
/usr/local/share/uhd/images/usrp_n310_fpga_XG.bit
/usr/local/share/uhd/images/usrp_n320_fpga_AQ.bit
/usr/local/share/uhd/images/usrp_n320_fpga_HG.bit
/usr/local/share/uhd/images/usrp_n320_fpga_WX.bit
/usr/local/share/uhd/images/usrp_n320_fpga_XG.bit
/usr/local/share/uhd/images/usrp_n320_fpga_XQ.bit

To update the default <code>HG</code> variant of FPGA image, run the command:

$ uhd_image_loader --args "type=n3xx,addr=<N3xx_IP_ADDR>,fpga=HG"

Example Output:

uhd_image_loader --args "type=n3xx,addr=192.168.1.151,fpga=HG"
[INFO] [UHD] linux; GNU C++ version 5.4.0 20160609; Boost_105800; UHD_3.11.1.HEAD-0-gad6b0935
[INFO] [MPMD] Initializing 1 device(s) in parallel with args: mgmt_addr=192.168.1.151,type=n3xx,product=n310,serial=313ABDA,claimed=False,skip_init=1
[INFO] [MPM.main] Launching USRP/MPM, version: 3.11.1.0-gunknown
[INFO] [MPM.main] Spawning RPC process...
[INFO] [MPM.PeriphManager] Device serial number: 313ABDA
[INFO] [MPM.PeriphManager] Found 2 daughterboard(s).
[INFO] [MPM.PeriphManager.UDP] No CHDR interfaces found!
[INFO] [MPM.PeriphManager.UDP] No CHDR interfaces found!
[INFO] [MPM.RPCServer] RPC server ready!
[INFO] [MPM.RPCServer] Spawning watchdog task...
[INFO] [MPM.PeriphManager.UDP] No CHDR interfaces found!
[INFO] [MPMD] Claimed device without full initialization.
[INFO] [MPMD IMAGE LOADER] Starting update. This may take a while.
[INFO] [MPM.PeriphManager] Updating component `fpga'
[INFO] [MPM.PeriphManager] Updating component `dts'
[INFO] [MPM.RPCServer] Resetting peripheral manager.
[INFO] [MPM.PeriphManager] Device serial number: 313ABDA
[INFO] [MPM.PeriphManager] Found 2 daughterboard(s).
[INFO] [MPMD IMAGE LOADER] Update component function succeeded.

To load a different default FPGA image (i.e. <code>XG</code>, <code>WG</code>), modify the device argument <code>fpga=</code> to a value of <code>fpga=XG</code> or <code>fpga=WG</code>.

To specify the path to a custom FPGA image, use the <code>--fpga-path</code> argument.

$ uhd_image_loader --args "type=n3xx,addr=<N3xx_IP_ADDR>" --fpga-path=/path/to/custom/fpga.bit

The Verilog code for the FPGA in the USRP N3xx 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.

===Embedded Mode FPGA Image Update===

It is possible to update the FPGA image when operated in Embedded mode. Connect to the ARM CPU via Serial Console or SSH as detailed in the section above.

Updating the FPGA image from the ARM CPU is the same as detailed above for a Network mode update, except it is not required to provide an <code>addr</code> device argument.

uhd_image_loader --args "type=n3xx,fpga=HG"

<pre>
root@ni-n3xx-313ABDA:~# uhd_image_loader --args "type=n3xx,fpga=HG"
[INFO] [UHD] linux; GNU C++ version 7.2.0; Boost_106400; UHD_3.11.1.0-0-unknown
[INFO] [MPMD] Initializing 1 device(s) in parallel with args: mgmt_addr=127.0.0.1,type=n3xx,product=n310,serial=313ABDA,claimed=False,skip_init=1
[INFO] [MPMD] Claimed device without full initialization.
[INFO] [MPMD IMAGE LOADER] Starting update. This may take a while.
[INFO] [MPM.PeriphManager] Updating component `fpga'
[INFO] [MPM.PeriphManager] Updating component `dts'
[INFO] [MPM.RPCServer] Resetting peripheral manager.
[INFO] [MPM.PeriphManager] Device serial number: 313ABDA
[INFO] [MPM.PeriphManager] Found 2 daughterboard(s).
[INFO] [MPMD IMAGE LOADER] Update component function succeeded.
</pre>

For more information on updating the FPGA image, refer to the UHD Manual at http://uhd.ettus.com .

==Setting Up a Streaming Connection==
The device supports multiple, high-speed, low-latency interfaces on the SFP+ ports for streaming samples to the host computer.

===1Gb Streaming SFP Port 0===
Complete the steps below to set up a streaming connection over the 1 Gigabit Ethernet interface on <code>SFP Port 0</code>.

When streaming via SFP Port 0 at 1 Gb speeds, it is important that the connection is direct between the Host and USRP. Placing a switch or other network gear between the Host and USRP can reduce throughput of the transport link. It is also generally recommended to avoid using USB to Ethernet Adapters for the high speed streaming interface, as they may limit performance or cause periodic flow control errors.

NOTE: The <code>HG</code> FPGA image must be loaded for <code>SFP Port 0</code> to operate at 1Gb speeds. If the <code>XG</code> image is loaded, the port will be unresponsive at 1Gb speeds.

1. Configure your Host's Ethernet adapter as shown below. This interface should be separate from the 1Gb NIC/network which is connected to the 1Gb RJ45 management interface.

IP Address: 192.168.10.1
Subnet Mask: 255.255.255.0
Gateway: 0.0.0.0
MTU: 1500

NOTE: When operating <code>SFP Port 0</code> at 1Gb speeds, it is important to set a MTU of <code>1500</code> and not a value of <code>automatic</code>.

2. Insert the SFP to RJ45 adapter into <code>SFP Port 0</code> .

3. Connect the adapter to a host computer using the Ethernet cable to SFP0.

The Green LED above <code>SFP Port 0</code> should illuminate.

4. To test the connection, <code>ping</code> the device at address <code>192.168.10.2</code> from the host, as shown
below:

$ ping 192.168.10.2
PING 192.168.10.2 (192.168.10.2) 56(84) bytes of data.
64 bytes from 192.168.10.2: icmp_seq=1 ttl=64 time=1.06 ms
^C
--- 192.168.10.2 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 1.065/1.065/1.065/0.000 ms

Press <code>CTRL+C</code> to stop the ping program.

Proceed to the next section "Verifying Device Operation".

===10Gb Streaming SFP Port 1===
Complete the steps below to set up a streaming connection over the 10 Gigabit Ethernet interface on <code>SFP Port 1</code>.

NOTE: Both the <code>HG</code> and <code>XG</code> FPGA images support 10Gb speeds over SFP Port 1.

1. Configure your Host's 10Gb Ethernet adapter as shown below.

IP Address: 192.168.20.1
Subnet Mask: 255.255.255.0
Gateway: 0.0.0.0
MTU: 9000

NOTE: When operating at 10Gb speeds, it is important to set a MTU of <code>9000</code> and not a value of <code>automatic</code>.

2. Connect the USRP to a host computer using either a 10Gb SFP or Fiber cable to <code>SFP Port 1</code>.

The Green LED above <code>SFP Port 1</code> should illuminate.

3. To test the connection, <code>ping</code> the device at address <code>192.168.20.2</code> from the host, as shown
below:

$ ping 192.168.20.2

Press <code>CTRL+C</code> to stop the ping program.

Proceed to the next section "Verifying Device Operation".

===Dual 10Gb Streaming SFP Ports 0/1===
Complete the steps below to set up a streaming connections over the Dual 10 Gigabit Ethernet interface on <code>SFP Ports 0/1</code>.

NOTE: The <code>XG</code> FPGA image must be loaded for <code>SFP Port 0</code> to operate at 10 Gb speeds. If the <code>HG</code> image is loaded, the port will be unresponsive at 10 Gb speeds.

1. Configure your Host's #1 10Gb Ethernet adapter as shown below.

IP Address: 192.168.10.1
Subnet Mask: 255.255.255.0
Gateway: 0.0.0.0
MTU: 9000

2. Configure your Host's #2 10Gb Ethernet adapter as shown below.

IP Address: 192.168.20.1
Subnet Mask: 255.255.255.0
Gateway: 0.0.0.0
MTU: 9000

NOTE: When operating at 10Gb speeds, it is important to set a MTU of <code>9000</code> and not a value of <code>automatic</code>.

3. Connect the USRP to a host computer using either a 10Gb SFP or Fiber cables to <code>SFP Ports 0/1</code>.

The Green LEDs above <code>SFP Ports 0/1</code> should illuminate.

4. To test the <code>SFP Port 0</code> connection, <code>ping</code> the device at address <code>192.168.10.2</code> from the host, as shown below:

$ ping 192.168.10.2

Press <code>CTRL+C</code> to stop the ping program.

5. To test the <code>SFP Port 1</code> connection, <code>ping</code> the device at address <code>192.168.20.2</code> from the host, as shown below:

$ ping 192.168.20.2

Press <code>CTRL+C</code> to stop the ping program.

Proceed to the next section "Verifying Device Operation".

For more details on Network Setup and Configuration, please see the “Interfaces and Connectivity” section on the [[N300/N310]] or [[N320/N321]] hardware resources pages.

==Verifying Device Operation==
Once you have successfully setup a management interface and streaming interface, you can now verify the devices operation using the included UHD utilities.

===Subdevice Specification Mapping===
====N300====
The USRP N300 contains 2 channels, each represented on the front panel as <code>RF0-1</code>. Below is the <code>subdev</code> mapping of RF Ports.

* RF0 = A:0
* RF1 = A:1

====N310====
The USRP N310 contains 4 channels, each represented on the front panel as <code>RF0-3</code>. Below is the <code>subdev</code> mapping of RF Ports.

=====UHD 3.11.x.x - 3.12.x.x=====
* RF0 = A:0
* RF1 = B:0
* RF2 = C:0
* RF3 = D:0

=====UHD 3.13.x.x+=====
* RF0 = A:0
* RF1 = A:1
* RF2 = B:0
* RF3 = B:1

====N320====
The USRP N320 contains 2 channels, each represented on the front panel as <code>RF0-1</code>. Below is the <code>subdev</code> mapping of RF Ports.

* RF0 = A:0
* RF1 = B:0

====N321====
The USRP N321 contains 2 channels, each represented on the front panel as <code>RF0-1</code>. Below is the <code>subdev</code> mapping of RF Ports.

* RF0 = A:0
* RF1 = B:0

Additional details of UHD Subdevice Specifications can be found here in the UHD Manual: http://files.ettus.com/manual/page_configuration.html#config_subdev

===Supported Sample Rates===

The USRP N300/N310 supports the three fixed Master Clock Rates listed below.

* 122.88 MHz
* 125.00 MHz
* 153.60 MHz

The USRP N320/N321 supports the three fixed Master Clock Rates listed below.

* 200.00 MHz
* 245.76 MHz
* 250.00 MHz

Sample rates as delivered to/from the host computer for USRP devices are constrained to follow several important rules.

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.

====Example Sample Rates====
Listed below are common sample rates for the given master clock rates. This is not a complete listing of the supported sample rates.

{| class="wikitable"
!Master Clock Rate
!colspan="20"|Decimation / Interpolation Rate <br> Host Sample Rate [Msps]
|-

|style="text-align:center;"| 1
|style="text-align:center;"| 2
|style="text-align:center;"| 4
|style="text-align:center;"| 6
|style="text-align:center;"| 8
|style="text-align:center;"| 10
|style="text-align:center;"| 12
|style="text-align:center;"| 14
|style="text-align:center;"| 16
|style="text-align:center;"| 18
|style="text-align:center;"| 20
|style="text-align:center;"| 30
|style="text-align:center;"| 32
|style="text-align:center;"| 64
|style="text-align:center;"| 100
|style="text-align:center;"| 128
|style="text-align:center;"| 200
|style="text-align:center;"| 256
|style="text-align:center;"| 512
|style="text-align:center;"| 1024
|-

|style="text-align:center;"| 122.88e6
|style="text-align:center;"| 61.44e6
|style="text-align:center;"| 30.72e6
|style="text-align:center;"| 20.48e6
|style="text-align:center;"| 15.36e6
|style="text-align:center;"| 12.288e6
|style="text-align:center;"| 10.24e6
|style="text-align:center;"| 8.7771e6
|style="text-align:center;"| 7.68e6
|style="text-align:center;"| 6.8267e6
|style="text-align:center;"| 6.144e6
|style="text-align:center;"| 4.096e6
|style="text-align:center;"| 3.84e6
|style="text-align:center;"| 1.92e6
|style="text-align:center;"| 1.2288e6
|style="text-align:center;"| 960e3
|style="text-align:center;"| 614.4e3
|style="text-align:center;"| 480e3
|style="text-align:center;"| 240e3
|style="text-align:center;"| 120e3
|-

|style="text-align:center;"| 125e6
|style="text-align:center;"| 62.5e6
|style="text-align:center;"| 31.25e6
|style="text-align:center;"| 20.833e6
|style="text-align:center;"| 15.625e6
|style="text-align:center;"| 12.5e6
|style="text-align:center;"| 10.417e6
|style="text-align:center;"| 8.9286e6
|style="text-align:center;"| 7.8125e6
|style="text-align:center;"| 6.9444e6
|style="text-align:center;"| 6.25e6
|style="text-align:center;"| 4.1667e6
|style="text-align:center;"| 3.90625e6
|style="text-align:center;"| 1.953125e6
|style="text-align:center;"| 1.25e6
|style="text-align:center;"| 976.5625e3
|style="text-align:center;"| 625e3
|style="text-align:center;"| 488.28125e3
|style="text-align:center;"| 244.14e3
|style="text-align:center;"| 122.07e3

|-

|style="text-align:center;"| 153.6e6
|style="text-align:center;"| 76.8e6
|style="text-align:center;"| 38.4e6
|style="text-align:center;"| 25.6e6
|style="text-align:center;"| 19.2e6
|style="text-align:center;"| 15.36e6
|style="text-align:center;"| 12.8e6
|style="text-align:center;"| 10.971e6
|style="text-align:center;"| 9.6e6
|style="text-align:center;"| 8.5333e6
|style="text-align:center;"| 7.68e6
|style="text-align:center;"| 5.12e6
|style="text-align:center;"| 4.8e6
|style="text-align:center;"| 2.4e6
|style="text-align:center;"| 1.536e6
|style="text-align:center;"| 1.2e6
|style="text-align:center;"| 768e3
|style="text-align:center;"| 600e3
|style="text-align:center;"| 300e3
|style="text-align:center;"| 150e3

|-

|}

====N320/N321 Example Sample Rates====
Listed below are common sample rates for the given master clock rates. This is not a complete listing of the supported sample rates.

{| class="wikitable"
!Master Clock Rate
!colspan="20"|Decimation / Interpolation Rate <br> Host Sample Rate [Msps]
|-

|style="text-align:center;"| 1
|style="text-align:center;"| 2
|style="text-align:center;"| 4
|style="text-align:center;"| 6
|style="text-align:center;"| 8
|style="text-align:center;"| 10
|style="text-align:center;"| 12
|style="text-align:center;"| 14
|style="text-align:center;"| 16
|style="text-align:center;"| 18
|style="text-align:center;"| 20
|style="text-align:center;"| 30
|style="text-align:center;"| 32
|style="text-align:center;"| 64
|style="text-align:center;"| 100
|style="text-align:center;"| 128
|style="text-align:center;"| 200
|style="text-align:center;"| 256
|style="text-align:center;"| 512
|style="text-align:center;"| 1024
|-

|style="text-align:center;"| 200e6
|style="text-align:center;"| 100e6
|style="text-align:center;"| 50e6
|style="text-align:center;"| 33.33e6
|style="text-align:center;"| 25e6
|style="text-align:center;"| 20e6
|style="text-align:center;"| 16.66e6
|style="text-align:center;"| 14.2857e6
|style="text-align:center;"| 12.5e6
|style="text-align:center;"| 11.11e6
|style="text-align:center;"| 10e6
|style="text-align:center;"| 6.667e6
|style="text-align:center;"| 6.25e6
|style="text-align:center;"| 3.125e6
|style="text-align:center;"| 2e6
|style="text-align:center;"| 1.5625e6
|style="text-align:center;"| 1e6
|style="text-align:center;"| 781.25e3
|style="text-align:center;"| 390.625e3
|style="text-align:center;"| 195.3125e3

|-

|style="text-align:center;"| 245.76e6
|style="text-align:center;"| 122.88e6
|style="text-align:center;"| 61.44e6
|style="text-align:center;"| 30.72e6
|style="text-align:center;"| 20.48e6
|style="text-align:center;"| 15.36e6
|style="text-align:center;"| 12.288e6
|style="text-align:center;"| 10.24e6
|style="text-align:center;"| 8.7771e6
|style="text-align:center;"| 7.68e6
|style="text-align:center;"| 6.8267e6
|style="text-align:center;"| 6.144e6
|style="text-align:center;"| 4.096e6
|style="text-align:center;"| 3.84e6
|style="text-align:center;"| 1.92e6
|style="text-align:center;"| 1.2288e6
|style="text-align:center;"| 960e3
|style="text-align:center;"| 614.4e3
|style="text-align:center;"| 480e3
|style="text-align:center;"| 240e3
|-

|style="text-align:center;"| 250e6
|style="text-align:center;"| 125e6
|style="text-align:center;"| 62.5e6
|style="text-align:center;"| 31.25e6
|style="text-align:center;"| 20.833e6
|style="text-align:center;"| 15.625e6
|style="text-align:center;"| 12.5e6
|style="text-align:center;"| 10.417e6
|style="text-align:center;"| 8.9286e6
|style="text-align:center;"| 7.8125e6
|style="text-align:center;"| 6.9444e6
|style="text-align:center;"| 6.25e6
|style="text-align:center;"| 4.1667e6
|style="text-align:center;"| 3.90625e6
|style="text-align:center;"| 1.953125e6
|style="text-align:center;"| 1.25e6
|style="text-align:center;"| 976.5625e3
|style="text-align:center;"| 625e3
|style="text-align:center;"| 488.28125e3
|style="text-align:center;"| 244.14e3

|-

|}

Additional information on Sample Rates can be found here in the UHD Manual: http://files.ettus.com/manual/page_general.html#general_sampleratenotes

===Probe the USRP===

====N300/N310====
The UHD utility <code>uhd_usrp_probe</code> provides detailed information of the USRP device.

From your host computer, run the command <code>uhd_usrp_probe</code>:

<pre>
$ uhd_usrp_probe
[INFO] [UHD] linux; GNU C++ version 5.4.0 20160609; Boost_105800; UHD_3.13.1.HEAD-0-ga0a71d10
[INFO] [MPMD] Initializing 1 device(s) in parallel with args: mgmt_addr=192.168.10.2,type=n3xx,product=n310,serial=313ABDA,claimed=False,addr=192.168.10.2
[INFO] [MPM.main] Launching USRP/MPM, version: 3.13.1.0-gd3b7e90a
[INFO] [MPM.main] Spawning RPC process...
[INFO] [MPM.PeriphManager] Device serial number: 313ABDA
[INFO] [MPM.PeriphManager] Initialized 2 daughterboard(s).
[INFO] [MPM.PeriphManager] init() called with device args `time_source=internal,clock_source=internal'.
[INFO] [MPM.RPCServer] RPC server ready!
[INFO] [MPM.RPCServer] Spawning watchdog task...
[INFO] [0/DmaFIFO_0] Initializing block control (NOC ID: 0xF1F0D00000000004)
[INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1355 MB/s)
[INFO] [MPM.PeriphManager] init() called with device args `mgmt_addr=192.168.10.2,clock_source=internal,time_source=internal,product=n310'.
[INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1358 MB/s)
[INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1355 MB/s)
[INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1345 MB/s)
[INFO] [0/Radio_0] Initializing block control (NOC ID: 0x12AD100000011312)
[INFO] [0/Radio_1] Initializing block control (NOC ID: 0x12AD100000011312)
[INFO] [0/DDC_0] Initializing block control (NOC ID: 0xDDC0000000000000)
[INFO] [0/DDC_1] Initializing block control (NOC ID: 0xDDC0000000000000)
[INFO] [0/DUC_0] Initializing block control (NOC ID: 0xD0C0000000000002)
[INFO] [0/DUC_1] Initializing block control (NOC ID: 0xD0C0000000000002)
_____________________________________________________
/
| Device: N300-Series Device
| _____________________________________________________
| /
| | Mboard: ni-n3xx-313ABDA
| | eeprom_version: 1
| | mpm_version: 3.13.1.0-gd3b7e90a
| | pid: 16962
| | product: n310
| | rev: 3
| | rpc_connection: remote
| | serial: 313ABDA
| | type: n3xx
| | MPM Version: 1.2
| | FPGA Version: 5.2
| | RFNoC capable: Yes
| |
| | Time sources: internal, external, gpsdo, sfp0
| | Clock sources: external, internal, gpsdo
| | Sensors: gps_tpv, ref_locked, gps_time, gps_locked, temp, gps_sky, fan
| | _____________________________________________________
| | /
| | | RX Dboard: A
| | | _____________________________________________________
| | | /
| | | | RX Frontend: 0
| | | | Name: Magnesium
| | | | Antennas: TX/RX, RX2, CAL, LOCAL
| | | | Sensors: lo_locked, ad9371_lo_locked, lowband_lo_locked
| | | | Freq range: 1.000 to 6000.000 MHz
| | | | Gain range all: 0.0 to 75.0 step 0.5 dB
| | | | Gain range rfic: 0.0 to 0.0 step 0.0 dB
| | | | Gain range dsa: 0.0 to 0.0 step 0.0 dB
| | | | Gain range amp: 0.0 to 0.0 step 0.0 dB
| | | | Bandwidth range: 20000000.0 to 100000000.0 step 0.0 Hz
| | | | Connection Type: IQ
| | | | Uses LO offset: No
| | | _____________________________________________________
| | | /
| | | | RX Frontend: 1
| | | | Name: Magnesium
| | | | Antennas: TX/RX, RX2, CAL, LOCAL
| | | | Sensors: lo_locked, ad9371_lo_locked, lowband_lo_locked
| | | | Freq range: 1.000 to 6000.000 MHz
| | | | Gain range all: 0.0 to 75.0 step 0.5 dB
| | | | Gain range rfic: 0.0 to 0.0 step 0.0 dB
| | | | Gain range dsa: 0.0 to 0.0 step 0.0 dB
| | | | Gain range amp: 0.0 to 0.0 step 0.0 dB
| | | | Bandwidth range: 20000000.0 to 100000000.0 step 0.0 Hz
| | | | Connection Type: IQ
| | | | Uses LO offset: No
| | | _____________________________________________________
| | | /
| | | | RX Codec: A
| | | | Name: AD9371 Dual ADC
| | | | Gain Elements: None
| | _____________________________________________________
| | /
| | | RX Dboard: B
| | | _____________________________________________________
| | | /
| | | | RX Frontend: 0
| | | | Name: Magnesium
| | | | Antennas: TX/RX, RX2, CAL, LOCAL
| | | | Sensors: lo_locked, ad9371_lo_locked, lowband_lo_locked
| | | | Freq range: 1.000 to 6000.000 MHz
| | | | Gain range all: 0.0 to 75.0 step 0.5 dB
| | | | Gain range rfic: 0.0 to 0.0 step 0.0 dB
| | | | Gain range dsa: 0.0 to 0.0 step 0.0 dB
| | | | Gain range amp: 0.0 to 0.0 step 0.0 dB
| | | | Bandwidth range: 20000000.0 to 100000000.0 step 0.0 Hz
| | | | Connection Type: IQ
| | | | Uses LO offset: No
| | | _____________________________________________________
| | | /
| | | | RX Frontend: 1
| | | | Name: Magnesium
| | | | Antennas: TX/RX, RX2, CAL, LOCAL
| | | | Sensors: lo_locked, ad9371_lo_locked, lowband_lo_locked
| | | | Freq range: 1.000 to 6000.000 MHz
| | | | Gain range all: 0.0 to 75.0 step 0.5 dB
| | | | Gain range rfic: 0.0 to 0.0 step 0.0 dB
| | | | Gain range dsa: 0.0 to 0.0 step 0.0 dB
| | | | Gain range amp: 0.0 to 0.0 step 0.0 dB
| | | | Bandwidth range: 20000000.0 to 100000000.0 step 0.0 Hz
| | | | Connection Type: IQ
| | | | Uses LO offset: No
| | | _____________________________________________________
| | | /
| | | | RX Codec: B
| | | | Name: AD9371 Dual ADC
| | | | Gain Elements: None
| | _____________________________________________________
| | /
| | | TX Dboard: A
| | | _____________________________________________________
| | | /
| | | | TX Frontend: 0
| | | | Name: Magnesium
| | | | Antennas: TX/RX
| | | | Sensors: lo_locked, ad9371_lo_locked, lowband_lo_locked
| | | | Freq range: 1.000 to 6000.000 MHz
| | | | Gain range all: 0.0 to 65.0 step 0.5 dB
| | | | Gain range rfic: 0.0 to 0.0 step 0.0 dB
| | | | Gain range dsa: 0.0 to 0.0 step 0.0 dB
| | | | Gain range amp: 0.0 to 0.0 step 0.0 dB
| | | | Bandwidth range: 20000000.0 to 100000000.0 step 0.0 Hz
| | | | Connection Type: IQ
| | | | Uses LO offset: No
| | | _____________________________________________________
| | | /
| | | | TX Frontend: 1
| | | | Name: Magnesium
| | | | Antennas: TX/RX
| | | | Sensors: lo_locked, ad9371_lo_locked, lowband_lo_locked
| | | | Freq range: 1.000 to 6000.000 MHz
| | | | Gain range all: 0.0 to 65.0 step 0.5 dB
| | | | Gain range rfic: 0.0 to 0.0 step 0.0 dB
| | | | Gain range dsa: 0.0 to 0.0 step 0.0 dB
| | | | Gain range amp: 0.0 to 0.0 step 0.0 dB
| | | | Bandwidth range: 20000000.0 to 100000000.0 step 0.0 Hz
| | | | Connection Type: IQ
| | | | Uses LO offset: No
| | | _____________________________________________________
| | | /
| | | | TX Codec: A
| | | | Name: AD9371 Dual DAC
| | | | Gain Elements: None
| | _____________________________________________________
| | /
| | | TX Dboard: B
| | | _____________________________________________________
| | | /
| | | | TX Frontend: 0
| | | | Name: Magnesium
| | | | Antennas: TX/RX
| | | | Sensors: lo_locked, ad9371_lo_locked, lowband_lo_locked
| | | | Freq range: 1.000 to 6000.000 MHz
| | | | Gain range all: 0.0 to 65.0 step 0.5 dB
| | | | Gain range rfic: 0.0 to 0.0 step 0.0 dB
| | | | Gain range dsa: 0.0 to 0.0 step 0.0 dB
| | | | Gain range amp: 0.0 to 0.0 step 0.0 dB
| | | | Bandwidth range: 20000000.0 to 100000000.0 step 0.0 Hz
| | | | Connection Type: IQ
| | | | Uses LO offset: No
| | | _____________________________________________________
| | | /
| | | | TX Frontend: 1
| | | | Name: Magnesium
| | | | Antennas: TX/RX
| | | | Sensors: lo_locked, ad9371_lo_locked, lowband_lo_locked
| | | | Freq range: 1.000 to 6000.000 MHz
| | | | Gain range all: 0.0 to 65.0 step 0.5 dB
| | | | Gain range rfic: 0.0 to 0.0 step 0.0 dB
| | | | Gain range dsa: 0.0 to 0.0 step 0.0 dB
| | | | Gain range amp: 0.0 to 0.0 step 0.0 dB
| | | | Bandwidth range: 20000000.0 to 100000000.0 step 0.0 Hz
| | | | Connection Type: IQ
| | | | Uses LO offset: No
| | | _____________________________________________________
| | | /
| | | | TX Codec: B
| | | | Name: AD9371 Dual DAC
| | | | Gain Elements: None
| | _____________________________________________________
| | /
| | | RFNoC blocks on this device:
| | |
| | | * DmaFIFO_0
| | | * Radio_0
| | | * Radio_1
| | | * DDC_0
| | | * DDC_1
| | | * DUC_0
| | | * DUC_1

</pre>

====N320====

<pre>

$ uhd_usrp_probe
[INFO] [UHD] linux; GNU C++ version 7.3.0; Boost_106600; UHD_3.14.0.0-0-g6875d061
[INFO] [MPMD] Initializing 1 device(s) in parallel with args: mgmt_addr=127.0.0.1,type=n3xx,product=n320,serial=3181FFA,claimed=False
[INFO] [MPM.main] Launching USRP/MPM, version: 3.14.0.0-g6875d061
[INFO] [MPM.main] Spawning RPC process...
[INFO] [MPM.PeriphManager] Device serial number: 3181FFA
[INFO] [MPM.Rhodium-0] Successfully loaded all peripherals!
[INFO] [MPM.Rhodium-1] Successfully loaded all peripherals!
[INFO] [MPM.PeriphManager] Initialized 2 daughterboard(s).
[INFO] [MPM.PeriphManager] No QSFP board detected: Assuming it is disabled in the device tree overlay (e.g., HG, XG images).
[INFO] [MPM.PeriphManager] init() called with device args `time_source=internal,clock_source=internal'.
[INFO] [MPM.Rhodium-0] init() called with args `time_source=internal,clock_source=internal'
[INFO] [MPM.Rhodium-1] init() called with args `time_source=internal,clock_source=internal'
[INFO] [MPM.Rhodium-0.init.LMK04828] LMK initialized and locked!
[INFO] [MPM.Rhodium-1.init.LMK04828] LMK initialized and locked!
[INFO] [MPM.Rhodium-1.DAC37J82] DAC PLL Locked!
[INFO] [MPM.Rhodium-1.AD9695] ADC PLL Locked!
[INFO] [MPM.Rhodium-1.init] JESD204B Link Initialization & Training Complete
[INFO] [MPM.Rhodium-0.DAC37J82] DAC PLL Locked!
[INFO] [MPM.Rhodium-0.AD9695] ADC PLL Locked!
[INFO] [MPM.Rhodium-0.init] JESD204B Link Initialization & Training Complete
[INFO] [MPM.RPCServer] RPC server ready!
[INFO] [MPM.RPCServer] Spawning watchdog task...
[INFO] [MPM.PeriphManager] init() called with device args `mgmt_addr=127.0.0.1,clock_source=internal,time_source=internal,product=n320'.
[INFO] [MPM.Rhodium-0] init() called with args `mgmt_addr=127.0.0.1,clock_source=internal,time_source=internal,product=n320'
[INFO] [MPM.Rhodium-1] init() called with args `mgmt_addr=127.0.0.1,clock_source=internal,time_source=internal,product=n320'
[INFO] [0/Replay_0] Initializing block control (NOC ID: 0x4E91A00000000004)
[INFO] [0/Radio_0] Initializing block control (NOC ID: 0x12AD100000000320)
[INFO] [0/Radio_1] Initializing block control (NOC ID: 0x12AD100000000320)
[INFO] [0/DDC_0] Initializing block control (NOC ID: 0xDDC0000000000001)
[INFO] [0/DDC_1] Initializing block control (NOC ID: 0xDDC0000000000001)
[INFO] [0/DUC_0] Initializing block control (NOC ID: 0xD0C0000000000000)
[INFO] [0/DUC_1] Initializing block control (NOC ID: 0xD0C0000000000000)
[INFO] [0/FIFO_0] Initializing block control (NOC ID: 0xF1F0000000000000)
[INFO] [0/FIFO_1] Initializing block control (NOC ID: 0xF1F0000000000000)
_____________________________________________________
/
| Device: N300-Series Device
| _____________________________________________________
| /
| | Mboard: ni-n3xx-3181FFA
| | eeprom_version: 2
| | mpm_version: 3.14.0.0-g6875d061
| | pid: 16962
| | product: n320
| | rev: 6
| | rpc_connection: local
| | serial: 3181FFA
| | type: n3xx
| | MPM Version: 1.2
| | FPGA Version: 5.3
| | FPGA git hash: 3de8954.clean
| | RFNoC capable: Yes
| |
| | Time sources: internal, external, gpsdo, sfp0
| | Clock sources: external, internal, gpsdo
| | Sensors: gps_tpv, temp, gps_sky, fan, gps_time, gps_locked, ref_locked, gps_gpgga
| | _____________________________________________________
| | /
| | | RX Dboard: A
| | | ID: Unknown (0x0152)
| | | Serial: 3175A79
| | | _____________________________________________________
| | | /
| | | | RX Frontend: 0
| | | | Name: Rhodium
| | | | Antennas: TX/RX, RX2, CAL, TERM
| | | | Sensors: lo_locked
| | | | Freq range: 1.000 to 6000.000 MHz
| | | | Gain range all: 0.0 to 60.0 step 1.0 dB
| | | | Bandwidth range: 250000000.0 to 250000000.0 step 0.0 Hz
| | | | Connection Type:
| | | | Uses LO offset: No
| | | _____________________________________________________
| | | /
| | | | RX Codec: A
| | | | Name: ad9695-625
| | | | Gain Elements: None
| | _____________________________________________________
| | /
| | | RX Dboard: B
| | | ID: Unknown (0x0152)
| | | Serial: 3175A67
| | | _____________________________________________________
| | | /
| | | | RX Frontend: 0
| | | | Name: Rhodium
| | | | Antennas: TX/RX, RX2, CAL, TERM
| | | | Sensors: lo_locked
| | | | Freq range: 1.000 to 6000.000 MHz
| | | | Gain range all: 0.0 to 60.0 step 1.0 dB
| | | | Bandwidth range: 250000000.0 to 250000000.0 step 0.0 Hz
| | | | Connection Type:
| | | | Uses LO offset: No
| | | _____________________________________________________
| | | /
| | | | RX Codec: B
| | | | Name: ad9695-625
| | | | Gain Elements: None
| | _____________________________________________________
| | /
| | | TX Dboard: A
| | | ID: Unknown (0x0152)
| | | Serial: 3175A79
| | | _____________________________________________________
| | | /
| | | | TX Frontend: 0
| | | | Name: Rhodium
| | | | Antennas: TX/RX, CAL, TERM
| | | | Sensors: lo_locked
| | | | Freq range: 1.000 to 6000.000 MHz
| | | | Gain range all: 0.0 to 60.0 step 1.0 dB
| | | | Bandwidth range: 250000000.0 to 250000000.0 step 0.0 Hz
| | | | Connection Type:
| | | | Uses LO offset: No
| | | _____________________________________________________
| | | /
| | | | TX Codec: A
| | | | Name: dac37j82
| | | | Gain Elements: None
| | _____________________________________________________
| | /
| | | TX Dboard: B
| | | ID: Unknown (0x0152)
| | | Serial: 3175A67
| | | _____________________________________________________
| | | /
| | | | TX Frontend: 0
| | | | Name: Rhodium
| | | | Antennas: TX/RX, CAL, TERM
| | | | Sensors: lo_locked
| | | | Freq range: 1.000 to 6000.000 MHz
| | | | Gain range all: 0.0 to 60.0 step 1.0 dB
| | | | Bandwidth range: 250000000.0 to 250000000.0 step 0.0 Hz
| | | | Connection Type:
| | | | Uses LO offset: No
| | | _____________________________________________________
| | | /
| | | | TX Codec: B
| | | | Name: dac37j82
| | | | Gain Elements: None
| | _____________________________________________________
| | /
| | | RFNoC blocks on this device:
| | |
| | | * Replay_0
| | | * Radio_0
| | | * Radio_1
| | | * DDC_0
| | | * DDC_1
| | | * DUC_0
| | | * DUC_1
| | | * FIFO_0
| | | * FIFO_1

</pre>

====N321====

<pre>
$ uhd_usrp_probe
[INFO] [UHD] linux; GNU C++ version 7.3.1 20180712 (Red Hat 7.3.1-6); Boost_106400; UHD_3.14.0.0-0-g6875d061
[INFO] [MPMD] Initializing 1 device(s) in parallel with args: mgmt_addr=192.168.20.2,type=n3xx,product=n320,serial=3166646,claimed=False,addr=192.168.20.2
[INFO] [MPM.PeriphManager] init() called with device args `time_source=internal,clock_source=internal,product=n320,mgmt_addr=192.168.20.2'.
[INFO] [MPM.Rhodium-0] init() called with args `time_source=internal,clock_source=internal,product=n320,mgmt_addr=192.168.20.2'
[INFO] [MPM.Rhodium-1] init() called with args `time_source=internal,clock_source=internal,product=n320,mgmt_addr=192.168.20.2'
[INFO] [0/Replay_0] Initializing block control (NOC ID: 0x4E91A00000000004)
[INFO] [0/Radio_0] Initializing block control (NOC ID: 0x12AD100000000320)
[INFO] [0/Radio_1] Initializing block control (NOC ID: 0x12AD100000000320)
[INFO] [0/DDC_0] Initializing block control (NOC ID: 0xDDC0000000000001)
[INFO] [0/DDC_1] Initializing block control (NOC ID: 0xDDC0000000000001)
[INFO] [0/DUC_0] Initializing block control (NOC ID: 0xD0C0000000000000)
[INFO] [0/DUC_1] Initializing block control (NOC ID: 0xD0C0000000000000)
[INFO] [0/FIFO_0] Initializing block control (NOC ID: 0xF1F0000000000000)
[INFO] [0/FIFO_1] Initializing block control (NOC ID: 0xF1F0000000000000)
_____________________________________________________
/
| Device: N300-Series Device
| _____________________________________________________
| /
| | Mboard: ni-n3xx-3166646
| | eeprom_version: 2
| | mpm_version: 3.14.0.0-g6875d061
| | pid: 16962
| | product: n320
| | rev: 6
| | rpc_connection: remote
| | serial: 3166646
| | type: n3xx
| | MPM Version: 1.2
| | FPGA Version: 5.3
| | FPGA git hash: 3de8954.clean
| | RFNoC capable: Yes
| |
| | Time sources: internal, external, gpsdo, sfp0
| | Clock sources: external, internal, gpsdo
| | Sensors: gps_sky, gps_time, gps_gpgga, gps_locked, fan, gps_tpv, ref_locked, temp
| | _____________________________________________________
| | /
| | | RX Dboard: B
| | | ID: Unknown (0x0152)
| | | Serial: 316D814
| | | _____________________________________________________
| | | /
| | | | RX Frontend: 0
| | | | Name: Rhodium
| | | | Antennas: TX/RX, RX2, CAL, TERM
| | | | Sensors: lo_locked
| | | | Freq range: 1.000 to 6000.000 MHz
| | | | Gain range all: 0.0 to 60.0 step 1.0 dB
| | | | Bandwidth range: 250000000.0 to 250000000.0 step 0.0 Hz
| | | | Connection Type:
| | | | Uses LO offset: No
| | | _____________________________________________________
| | | /
| | | | RX Codec: B
| | | | Name: ad9695-625
| | | | Gain Elements: None
| | _____________________________________________________
| | /
| | | RX Dboard: A
| | | ID: Unknown (0x0152)
| | | Serial: 316D810
| | | _____________________________________________________
| | | /
| | | | RX Frontend: 0
| | | | Name: Rhodium
| | | | Antennas: TX/RX, RX2, CAL, TERM
| | | | Sensors: lo_locked
| | | | Freq range: 1.000 to 6000.000 MHz
| | | | Gain range all: 0.0 to 60.0 step 1.0 dB
| | | | Bandwidth range: 250000000.0 to 250000000.0 step 0.0 Hz
| | | | Connection Type:
| | | | Uses LO offset: No
| | | _____________________________________________________
| | | /
| | | | RX Codec: A
| | | | Name: ad9695-625
| | | | Gain Elements: None
| | _____________________________________________________
| | /
| | | TX Dboard: B
| | | ID: Unknown (0x0152)
| | | Serial: 316D814
| | | _____________________________________________________
| | | /
| | | | TX Frontend: 0
| | | | Name: Rhodium
| | | | Antennas: TX/RX, CAL, TERM
| | | | Sensors: lo_locked
| | | | Freq range: 1.000 to 6000.000 MHz
| | | | Gain range all: 0.0 to 60.0 step 1.0 dB
| | | | Bandwidth range: 250000000.0 to 250000000.0 step 0.0 Hz
| | | | Connection Type:
| | | | Uses LO offset: No
| | | _____________________________________________________
| | | /
| | | | TX Codec: B
| | | | Name: dac37j82
| | | | Gain Elements: None
| | _____________________________________________________
| | /
| | | TX Dboard: A
| | | ID: Unknown (0x0152)
| | | Serial: 316D810
| | | _____________________________________________________
| | | /
| | | | TX Frontend: 0
| | | | Name: Rhodium
| | | | Antennas: TX/RX, CAL, TERM
| | | | Sensors: lo_locked
| | | | Freq range: 1.000 to 6000.000 MHz
| | | | Gain range all: 0.0 to 60.0 step 1.0 dB
| | | | Bandwidth range: 250000000.0 to 250000000.0 step 0.0 Hz
| | | | Connection Type:
| | | | Uses LO offset: No
| | | _____________________________________________________
| | | /
| | | | TX Codec: A
| | | | Name: dac37j82
| | | | Gain Elements: None
| | _____________________________________________________
| | /
| | | RFNoC blocks on this device:
| | |
| | | * Replay_0
| | | * Radio_0
| | | * Radio_1
| | | * DDC_0
| | | * DDC_1
| | | * DUC_0
| | | * DUC_1
| | | * FIFO_0
| | | * FIFO_1

</pre>

If you see warnings such as:

[WARNING] [UDP] The recv buffer could not be resized sufficiently.

You need to resize the socket buffers for your network interface card:

sudo sysctl -w net.core.rmem_max=288000
sudo sysctl -w net.core.wmem_max=288000
sudo sysctl -w net.core.rmem_max=33554432

===ASCII Art Example===
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

You can quickly verify the operation of your USRP N3xx by running the <code>rx_ascii_art_dft</code> UHD example program.

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.

You can run a simple test of the N3xx USRP by connecting an antenna and observing the spectrum of a commercial FM radio station in real-time, following the steps below:

1. Attach an antenna to the <code>Ch0/RX2</code> antenna port of the N3xx.

2. From your host computer, run the command:

'''N300/N310'''
<pre>
$ /usr/local/lib/uhd/examples/rx_ascii_art_dft --args "master_clock_rate=125e6,mgmt_addr=192.168.1.151,addr=192.168.10.2" --freq 98.5e6 --rate 2.5e6 --gain 50 --ref-lvl="-50" --dyn-rng 90 --ant "RX2" --subdev "A:0"
</pre>

'''N320/N321'''
<pre>
$ /usr/local/lib/uhd/examples/rx_ascii_art_dft --args "master_clock_rate=250e6,mgmt_addr=192.168.1.151,addr=192.168.10.2" --freq 98.5e6 --rate 2.5e6 --gain 50 --ref-lvl="-50" --dyn-rng 90 --ant "RX2" --subdev "A:0"
</pre>

NOTE: Modify the command line 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.

3. You should see a real-time FFT display of 2.5 MHz of spectrum, centered at the specified tuning frequency.

4. Type "<code>Q</code>" or <code>Ctrl-C</code> to stop the program and to return to the Linux command line.

5. You can run with the <code>--help</code> argument to see a description of all available command-line options.

Example Output:

<pre>
$ /usr/local/lib/uhd/examples/rx_ascii_art_dft --args "master_clock_rate=125e6,mgmt_addr=192.168.1.151,addr=192.168.10.2" --freq 98.5e6 --rate 2.5e6 --gain 50 --ref-lvl="-50" --dyn-rng 90 --ant "RX2" --subdev "A:0"

Creating the usrp device with: master_clock_rate=125e6,mgmt_addr=192.168.1.151,addr=192.168.10.2...
[INFO] [UHD] linux; GNU C++ version 5.4.0 20160609; Boost_105800; UHD_3.11.1.HEAD-0-gad6b0935
[INFO] [MPMD] Initializing 1 device(s) in parallel with args: mgmt_addr=192.168.1.151,type=n3xx,product=n310,serial=313ABDA,claimed=False,master_clock_rate=125e6,addr=192.168.10.2
[INFO] [MPM.main] Launching USRP/MPM, version: 3.11.1.0-gunknown
[INFO] [MPM.main] Spawning RPC process...
[INFO] [MPM.PeriphManager] Device serial number: 313ABDA
[INFO] [MPM.PeriphManager] Found 2 daughterboard(s).
[INFO] [MPM.RPCServer] RPC server ready!
[INFO] [MPM.RPCServer] Spawning watchdog task...
[INFO] [MPM.PeriphManager] init() called with device args `mgmt_addr=192.168.1.151,product=n310,master_clock_rate=125e6'.
[INFO] [0/DmaFIFO_0] Initializing block control (NOC ID: 0xF1F0D00000000004)
[INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1336 MB/s)
[INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1338 MB/s)
[INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1346 MB/s)
[INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1350 MB/s)
[INFO] [0/Radio_0] Initializing block control (NOC ID: 0x12AD100000000310)
[INFO] [0/Radio_1] Initializing block control (NOC ID: 0x12AD100000000310)
[INFO] [0/Radio_2] Initializing block control (NOC ID: 0x12AD100000000310)
[INFO] [0/Radio_3] Initializing block control (NOC ID: 0x12AD100000000310)
[INFO] [0/DDC_0] Initializing block control (NOC ID: 0xDDC0000000000001)
[INFO] [0/DDC_1] Initializing block control (NOC ID: 0xDDC0000000000001)
[INFO] [0/DDC_2] Initializing block control (NOC ID: 0xDDC0000000000001)
[INFO] [0/DDC_3] Initializing block control (NOC ID: 0xDDC0000000000001)
[INFO] [0/DUC_0] Initializing block control (NOC ID: 0xD0C0000000000000)
[INFO] [0/DUC_1] Initializing block control (NOC ID: 0xD0C0000000000000)
[INFO] [0/DUC_2] Initializing block control (NOC ID: 0xD0C0000000000000)
[INFO] [0/DUC_3] Initializing block control (NOC ID: 0xD0C0000000000000)
Using Device: Single USRP:
Device: N300-Series Device
Mboard 0: ni-n3xx-313ABDA
RX Channel: 0
RX DSP: 0
RX Dboard: A
RX Subdev: Magnesium
TX Channel: 0
TX DSP: 0
TX Dboard: A
TX Subdev: Magnesium
TX Channel: 1
TX DSP: 0
TX Dboard: B
TX Subdev: Magnesium
TX Channel: 2
TX DSP: 0
TX Dboard: C
TX Subdev: Magnesium
TX Channel: 3
TX DSP: 0
TX Dboard: D
TX Subdev: Magnesium

Setting RX Rate: 2.500000 Msps...
Actual RX Rate: 2.500000 Msps...

Setting RX Freq: 98.500000 MHz...
Actual RX Freq: 98.500000 MHz...

Setting RX Gain: 50.000000 dB...
Actual RX Gain: 50.000000 dB...

Checking RX: all_los: locked ...

Done!
</pre>

===Benchmarking your system===
Included with the UHD driver example programs is a utility, <code>benchmark_rate</code> to benchmark the transport link of the system.

A system's maximum performance is dependent upon many factors. <code>benchmark_rate</code> will exercise the transport link and CPU of the system.

====1 Gb Interface====
NOTE: This example requires the <code>HG</code> FPGA image to be loaded.

'''N300/N310'''

This example will test one full-duplex stream using "RF0/A:0", at a rate of 3.84 MS/s, for 60 seconds:

/usr/local/lib/uhd/examples/benchmark_rate \
--args "type=n3xx,mgmt_addr=192.168.1.151,addr=192.168.10.2,master_clock_rate=122.88e6" \
--duration 60 \
--channels "0" \
--rx_rate 3.84e6 \
--rx_subdev "A:0" \
--tx_rate 3.84e6 \
--tx_subdev "A:0"

'''N310'''

This example will test four full-duplex streams at 1.25 MS/s, for 60 seconds:

/usr/local/lib/uhd/examples/benchmark_rate \
--args "type=n3xx,mgmt_addr=192.168.1.151,addr=192.168.10.2,master_clock_rate=125e6" \
--duration 60 \
--channels "0,1,2,3" \
--rx_rate 1.25e6 \
--rx_subdev "A:0 A:1 B:0 B:1" \
--tx_rate 1.25e6 \
--tx_subdev "A:0 A:1 B:0 B:1"

'''N320/N321'''

This example will test one full-duplex stream using "RF0/A:0", at a rate of 3.84 MS/s, for 60 seconds:

/usr/local/lib/uhd/examples/benchmark_rate \
--args "type=n3xx,mgmt_addr=192.168.1.151,addr=192.168.10.2,master_clock_rate=245.76e6" \
--duration 60 \
--channels "0" \
--rx_rate 3.84e6 \
--rx_subdev "A:0" \
--tx_rate 3.84e6 \
--tx_subdev "A:0"

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.

====10 Gb Interface SFP 1====
NOTE: This example will work with either the <code>HG</code> or <code>XG</code> FPGA image.

'''N300/N310'''

This example will test one full-duplex stream using "RF0/A:0", at a rate of 31.25 MS/s, for 60 seconds:

/usr/local/lib/uhd/examples/benchmark_rate \
--args "type=n3xx,mgmt_addr=192.168.1.151,addr=192.168.20.2,master_clock_rate=125e6" \
--duration 60 \
--channels "0" \
--rx_rate 31.25e6 \
--rx_subdev "A:0" \
--tx_rate 31.25e6 \
--tx_subdev "A:0"

'''N320/N321'''

This example will test one full-duplex stream using "RF0/A:0", at a rate of 31.25 MS/s, for 60 seconds:

/usr/local/lib/uhd/examples/benchmark_rate \
--args "type=n3xx,mgmt_addr=192.168.1.151,addr=192.168.20.2,master_clock_rate=250e6" \
--duration 60 \
--channels "0" \
--rx_rate 31.25e6 \
--rx_subdev "A:0" \
--tx_rate 31.25e6 \
--tx_subdev "A:0"

'''N310'''

This example will test four full-duplex streams at 30.72 MS/s, for 60 seconds:

/usr/local/lib/uhd/examples/benchmark_rate \
--args "type=n3xx,mgmt_addr=192.168.1.151,addr=192.168.20.2,master_clock_rate=122.88e6" \
--duration 60 \
--channels "0,1,2,3" \
--rx_rate 30.72e6 \
--rx_subdev "A:0 A:1 B:0 B:1" \
--tx_rate 30.72e6 \
--tx_subdev "A:0 A:1 B:0 B:1"

'''N320/N321'''

This example will test two full-duplex streams at 30.72 MS/s, for 60 seconds:

/usr/local/lib/uhd/examples/benchmark_rate \
--args "type=n3xx,mgmt_addr=192.168.1.151,addr=192.168.20.2,master_clock_rate=245.76e6" \
--duration 60 \
--channels "0,1,2,3" \
--rx_rate 30.72e6 \
--rx_subdev "A:0 B:0" \
--tx_rate 30.72e6 \
--tx_subdev "A:0 B:0"

====Dual 10 Gb Interface====
NOTE: This example requires the <code>XG</code> FPGA image to be loaded.

'''N310'''

This example will test four full-duplex streams at 62.5 MS/s, for 60 seconds:

/usr/local/lib/uhd/examples/benchmark_rate \
--args "type=n3xx,mgmt_addr=192.168.1.151,addr=192.168.10.2,second_addr=192.168.20.2,master_clock_rate=125e6" \
--duration 60 \
--channels "0,1,2,3" \
--rx_rate 62.5e6 \
--rx_subdev "A:0 A:1 B:0 B:1" \
--tx_rate 62.5e6 \
--tx_subdev "A:0 A:1 B:0 B:1"

'''N320/N321'''

This example will test two full-duplex streams at 62.5 MS/s, for 60 seconds:

/usr/local/lib/uhd/examples/benchmark_rate \
--args "type=n3xx,mgmt_addr=192.168.1.151,addr=192.168.10.2,second_addr=192.168.20.2,master_clock_rate=250e6" \
--duration 60 \
--channels "0,1,2,3" \
--rx_rate 62.5e6 \
--rx_subdev "A:0 B:0" \
--tx_rate 62.5e6 \
--tx_subdev "A:0 B:0"

==USRP N3xx Device Specific Operations==

===White Rabbit Ethernet-Based Synchronization===
* [[Using Ethernet-Based Synchronization on the USRP™ N3xx Devices]]

===N320/N321===
* [[USRP N320/N321 LO Distribution]]
* [[5G NR EVM Measurements with the USRP N320/N321]]

===Turning the Device Off/On===
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:

shutdown -h now

===Enable Auto Booting===
Auto booting of the N3xx when power is applied can be configured by enabling the flag on the device's EEPROM with the following command:

eeprom-set-flags 0x1

===Default Password===
The default user is <code>root</code> and the password is empty (no password).

It is recommended to update the <code>root</code> password, which can be done with the command <code>passwd</code>:

Example Output:

root@ni-n3xx-serial:~# passwd
Changing password for root
New password:
Re-enter new password:
passwd: password changed.

[[Category:Getting Started Guides]]
[[Category:N300]]
[[Category:N310]]
[[Category:N320]]
[[Category:N321]]

USRP N300/N310/N320/N321 Getting Started Guide

2026-08-05T14:27:08Z

JonathonPendlum: Corrected Kit Contents section, devices ship with SFP to RJ45 Adapter, not SFP+

==Kit Contents==
===N300===
{|
|style="vertical-align:top"|
* USRP N300
* DC Power Supply (12V, 7A)
* 1 SFP to RJ45 Adapter
* 1 Gigabit Ethernet Cat-5e Cable (3m)
* USB-A to Micro USB-B Cable (1m)
* Getting Started Guide
* Ettus Research Sticker
||[[File:n300 kit.png|450px|center]]
|}
===N310===

{|
|style="vertical-align:top"|
* USRP N310
* DC Power Supply (12V, 7A)
* 1 SFP to RJ45 Adapter
* 1 Gigabit Ethernet Cat-5e Cable (3m)
* USB-A to Micro USB-B Cable (1m)
* Getting Started Guide
* Ettus Research Sticker
||[[File:n310 kit.png|500px|center]]
|}

===N320===

{|
|style="vertical-align:top"|
* USRP N320
* DC Power Supply (12V, 7A)
* 1 SFP to RJ45 Adapter
* 1 Gigabit Ethernet Cat-5e Cable (3m)
* USB-A to Micro USB-B Cable (1m)
* Getting Started Guide
* Ettus Research Sticker
|[[File:n320 kit.png|500px|center]]
|}

===N321===

{|
|style="vertical-align:top"|
* USRP N321
* DC Power Supply (12V, 7A)
* 1 SFP to RJ45 Adapter
* 1 Gigabit Ethernet Cat-5e Cable (3m)
* USB-A to Micro USB-B Cable (1m)
* Getting Started Guide
* Ettus Research Sticker
||[[File:n321 kit.png|500px|center]]
|}

==Verify the Contents of Your Kit==

Ensure that your kit contains all the items listed above.

==You Will Need==
* microSD Card Writer

* For Network Mode: A host computer with an available 1 or 10 Gigabit Ethernet interface for sample streaming. In addition to the Ethernet interface used for sampling streaming, your host computer will require a separate 1 Gigabit Ethernet interface for command and control streaming.

* For Stand-Alone Embedded Mode: A host computer with an available 1 Gigabit Ethernet port or a USB 2.0 port to remotely access the embedded Linux operating system running on ARM CPU.

==Proper Care and Handling==
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.

* Never allow metal objects to touch the circuit board while powered.
* Always properly terminate the transmit port with an antenna or 50Ω load.
* Always handle the board with proper anti-static methods.
* Never allow the board to directly or indirectly come into contact with any voltage spikes.
* Never allow any water or condensing moisture to come into contact with the device.
* Always use caution with FPGA, firmware, or software modifications.

{|
|style="padding-left:10px; padding-right:10px; padding-bottom:10px;" |[[File:Caution.png|24px|center]]
|style="padding-left:10px; padding-right:10px; padding-bottom:10px;" |Never apply more than -15 dBm of power into any RF input.
|-
|style="padding-left:10px; padding-right:10px; padding-bottom:10px;" |[[File:Caution.png|24px|center]]
|style="padding-left:10px; padding-right:10px; padding-bottom:10px;" |Always use at least 30dB attenuation if operating in loopback configuration
|-
|}

==Install and Setup the Software Tools on Your Host Computer==
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.

To find the latest release of UHD, see the UHD repository at https://github.com/EttusResearch/uhd.

The USRP N310 requires UHD version 3.11.0.0 or later.

The USRP N300 requires UHD version 3.12.0.0 or later.

The USRP N320/N321 requires UHD version 3.14.0.0 or later.

White Rabbit Ethernet-Based Synchronization of the N3xx USRP requires UHD version 3.12.0.0 or later. For additional details on White Rabbit Ethernet-Based Synchronization, please see the application note, [[Using Ethernet-Based Synchronization on the USRP™ N3xx Devices]].

'''When you receive a brand-new device, it is strongly recommended that you download the most recent filesystem image from the Ettus Research website and write it to the SD card that comes with the unit. It is not recommended that you use the SD card from the factory as-is. Instructions on downloading the latest filesystem image and writing it to the SD card are listed below.'''

'''Note that if you are operating the device in Network Mode, the version of UHD running on the host computer and the USRP N3xx must match.'''

==Connecting the Device==
===Interfaces Overview===
Listed below are the interfaces to connect to the USRP N3xx. Each interface has specific functionality, limitations and purpose.

'''Serial Console'''

The Serial Console provides a low level interface to the device typically used for debugging.

'''1 Gigabit RJ45 Connection'''

The 1 Gigabit RJ45 Connection interfaces with the on-board ARM CPU. When operated in "Network mode", this interface can optionally be used for UHD management traffic. Regardless of the operation mode (Network vs Embedded) this interface can be used to connect to the ARM via SSH. By default, the 1Gb RJ45 connection is configured to use a DHCP assigned IP address.

'''Dual SFP+ Connections'''

The Dual SFP+ Connections support multiple configurations for streaming high-speed, low-latency data, depending upon the FPGA image which is loaded.

'''QSFP+ Connection (N320/ N321 Only)'''

The QSFP+ Connection supports 2 x 10Gb lanes for streaming high-speed, low-latency data, while the onboard SFP0 connection is used for White Rabbit Ethernet-Based Synchronization.

===Setting up a Serial Console Connection===
It is possible to gain shell access to the device using a serial terminal emulator via the Serial Console port. Most Linux, OSX, or other Unix based operating systems have a tool called <code>screen</code> which can be used for this purpose.

If you do not have <code>screen</code> installed, it can be installed via your package manager. For Ubuntu/Debian based operating systems it can be installed with <code>apt</code> such as:

sudo apt install screen

The default Baud Rate for the Serial Console is: <code>115200</code>

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>:

$ ls /dev/serial/by-id
usb-Digilent_Digilent_USB_Device_25163511FE00-if00-port0
usb-Digilent_Digilent_USB_Device_25163511FE00-if01-port0
usb-Silicon_Labs_CP2105_Dual_USB_to_UART_Bridge_Controller_007F6CB5-if00-port0
usb-Silicon_Labs_CP2105_Dual_USB_to_UART_Bridge_Controller_007F6CB5-if01-port0

NOTE: Exact names depend on the host operating system version and may differ.

Every N3XX 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>ARM CPU</code>, whereas the second connects to the <code>STM32 Microcontroller</code>.

If you have multiple N3xx Serial Consoles connected to a single host, you may have to empirically test nodes.

Connecting to the ARM CPU can be performed with the command:

$ sudo screen /dev/serial/by-id/usb-Silicon_Labs_CP2105_Dual_USB_to_UART_Bridge_Controller_007F6CB5-if00-port0 115200

Upon starting the USRP N3xx, boot messages will appear and rapidly update. Once the boot process successfully completes, a login prompt like the following should appear:

OpenEmbedded test ni-n3xx-313ABDA ttyPS0

ni-n3xx-313ABDA login:

Enter the username: <code>root</code>

By default, the <code>root</code> user's password is left blank. Press the <code>Enter</code> key when prompted for a password.

You should now be presented with a shell prompt similar to the following:

root@ni-n3xx-<motherboard serial #>:~#

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.

====Connecting to the microcontroller====

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.

$ sudo screen /dev/serial/by-id/usb-Silicon_Labs_CP2105_Dual_USB_to_UART_Bridge_Controller_007F6CB5-if01-port0 115200

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.

===Connecting to the ARM via SSH===
By default, the RJ45 1Gb management interface is configured to be assigned a DHCP IP address.

If you have access to a network which provides a DHCP server (such as a common router's LAN), attach the RJ45 1Gb 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.

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>:

Example Output:

<pre>
# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.151/24 brd 192.168.1.255 scope global dynamic eth0
valid_lft 42865sec preferred_lft 42865sec
3: sfp0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc pfifo_fast qlen 1000
link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
inet 192.168.10.2/24 brd 192.168.10.255 scope global sfp0
valid_lft forever preferred_lft forever
4: sfp1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 9000 qdisc pfifo_fast qlen 1000
link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
</pre>

If you do not have access to a network with a DHCP server, you can create one using the Linux utility <code>dnsmasq</code>:

$ sudo dnsmasq -i <ETHERNET_ADAPTER_NAME> --dhcp-range=192.168.1.151,192.168.1.254 --except-interface=lo --bind-dynamic --no-daemon

NOTE: Modify the value <code><ETHERNET_ADAPTER_NAME></code> to match the interface you would like to create a DHCP server on.

After the device has obtained an IP address, you can remotely log into it from a Linux or macOS system with SSH, as shown below:

$ ssh root@192.168.1.151

NOTE: The IP address may vary depending on your network setup.

NOTE: The <code>root</code> password default password is empty/blank.

On Microsoft Windows, the SSH connection can be established using the third-party program Putty.

After logging in, you should be presented with a shell like the following:

root@ni-n3xx-<motherboard serial #>:~#

==Updating the Linux File System==
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 N3xx USRP must match.

There is two ways to update the file system for the N3xx USRP:

1. Mender

2. Physically remove microSD card from device and write a new file system to the microSD card.

===File System Partition Layout===
The SD Card is divided into four partitions. There is two root file system partitions, a boot partition and a data partition.

Any data you would like to preserve through Mender updates should be saved to the <code>data</code> partition, which is mounted at <code>/data</code>.

===Updating the file system with Mender===
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.

====Mender Update Process====

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.

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.

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:
$ sudo uhd_images_downloader -t mender -t n3xx --yes

Example Output:
[INFO] Using base URL: https://files.ettus.com/binaries/cache/
[INFO] Images destination: /usr/local/share/uhd/images
365684 kB / 365684 kB (100%) n3xx_common_mender_default-v4.6.0.0.zip
[INFO] Images download complete.

The downloaded "zip" archive is extracted into the <code>Images destination</code> directory with the filename <code>usrp_n3xx_fs.mender</code>. Next, you will need to copy this Mender file system image from the <code>Images destination</code> directory to the USRP N3xx to have its filesystem changed. This can be done with the Linux utility <code>scp</code>, for example as follows:

$ scp /usr/local/share/uhd/images/usrp_n3xx_fs.mender root@192.168.1.51:~/.

Note: The path and IP may be different for your configuration; the command above assumes you're using the default UHD installation path of <code>/usr/local</code> and that the N3xx's IP is <code>192.168.1.51</code>.

After copying the Mender file system image to the N3xx, connect to the N3xx to gain shell access via either the Serial Console or SSH.

On the N3xx, you first need to determine the version of UHD currently running on the USRP; an easy way to do this is via the command
# uhd_config_info --version

Example output:
UHD 3.14.1.1-0-g0347a6d8

The mender command to execute is different for UHD version 4.0 or newer versus prior to version 4.0. For the former use <code>mender install</code> followed by the mender file; for the latter use <code>mender -f -rootfs</code> followed by the mender file. Starting with UHD version 4.0 one can use mender to upgrade or downgrade the UHD filesystem version between any UHD v4 versions (e.g., 4.1 to 4.6; 4.6 to 4.1). The following commands assume that the UHD filesystem is version 4; if not then substitute the other mender command.

Run <code>mender install /path/to/latest.mender</code> to update the file system, e.g.:

# mender install usrp_n3xx_fs.mender

The artifact can also be stored on a remote server:
# mender install <nowiki>http://server.name/path/to/latest.mender</nowiki>

This procedure will take a quite a few minutes to complete. While executing, mender will show progress, e.g.:
................................ 0% 1024 KiB
...
................................ 1% 4096 KiB
...
................................ 99% 386048 KiB
............ 100% 386458 KiB
INFO[3865] wrote 7851737088/7851737088 bytes of update to device /dev/mmcblk0p3 module=device
INFO[3871] Enabling partition with new image installed to be a boot candidate: 3 module=device

After mender has logged a successful update, reboot the device:
# reboot

Upon reboot log back in to the USRP N3xx and run the command <code>uhd_find_devices</code> to verify that the UHD version is as desired and that the command runs successfully -- it should find at a minimum the USRP it is being executed on and will find more if other USRPs are on the same network.

If upon reboot the device is not working or the UHD version is not as desired, then the easiest way forward is to [https://kb.ettus.com/USRP_N300/N310/N320/N321_Getting_Started_Guide#Updating_the_files_system_by_writing_the_disk_image overwrite the sdcard filesystem manually] with the desired UHD version.

If upon reboot everything is as desired and the device seems functional, then commit the changes so that the boot loader knows to permanently boot into this partition:
# mender commit

To identify the currently installed Mender artifact from the command line, the following file can be queried on the N3xx:
# mender show-artifact

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.

For more information on updating the filesystem, refer to the [https://files.ettus.com/manual/ UHD Manual].

===Updating the files system by writing the disk image===
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 SD card.

==Updating the Network Configurations==
The USRP N3xx systemd network configuration files are located at: <code>/data/network/</code>

# ls /data/network/
eth0.network int0.network sfp0.network sfp1.network

or for older versions of the file system: <code>/etc/systemd/network/</code>

# ls /etc/systemd/network/
eth0.network sfp0.network sfp1.network

For details on configuration please refer to the [https://www.freedesktop.org/software/systemd/man/systemd.network.html systemd-networkd manual pages].

The factory settings are as follows:
<pre>
eth0 (DHCP):

[Match]
Name=eth0

[Network]
DHCP=ipv4

[DHCP]
UseHostname=false

sfp0 (static):

[Match]
Name=sfp0

[Network]
Address=192.168.10.2/24

[Link]
MTUBytes=9000

sfp1 (static):

[Match]
Name=sfp1

[Network]
Address=192.168.20.2/24

[Link]
MTUBytes=9000
</pre>

Additional notes on networking:

* 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>/etc/systemd/network/sfp0.network~</code>), that <code>systemd-networkd</code> might accidentally pick up.
* 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.
* If the MTU of the device and host computers differ, streaming issues can occur.
* Streaming via SFP0 at 1 Gb rates requires a MTU of <code>1500</code>
* Streaming via SFP0 at 10 Gb rates requires a MTU of <code>9000</code>

For addition details on network configuration here: https://files.ettus.com/manual/page_usrp_n3xx.html#n3xx_network_configuration

==Updating the FPGA Image==

===Network Mode FPGA Image Update===
The FPGA image should match the version of UHD installed on the host computer, when operated in Network mode. Connect the device to the host computer using either the RJ45 or SFP+ port, refer to the section above for detailed instructions.

To obtain all the FPGA images for a specific version of UHD, run the following command on the host computer with internet access:

$ sudo uhd_images_downloader

Example Output:

$ sudo uhd_images_downloader
[INFO] Images destination: /usr/local/share/uhd/images
00006 kB / 00006 kB (100%) usrp1_b100_fw_default-g6bea23d.zip
19810 kB / 19810 kB (100%) x3xx_x310_fpga_default-gf1ba32fe.zip
02757 kB / 02757 kB (100%) usrp2_n210_fpga_default-g6bea23d.zip
02123 kB / 02123 kB (100%) n230_n230_fpga_default-ge57dfe0.zip
00522 kB / 00522 kB (100%) usrp1_b100_fpga_default-g6bea23d.zip
00491 kB / 00491 kB (100%) b2xx_b200_fpga_default-ge57dfe0.zip
02415 kB / 02415 kB (100%) usrp2_n200_fpga_default-g6bea23d.zip
08988 kB / 08988 kB (100%) e3xx_e320_fpga_default-g3de8954a.zip
23045 kB / 23045 kB (100%) n3xx_n310_fpga_default-g3de8954a.zip
00523 kB / 00523 kB (100%) b2xx_b205mini_fpga_default-ge57dfe0.zip
18937 kB / 18937 kB (100%) x3xx_x300_fpga_default-gf1ba32fe.zip
00017 kB / 00017 kB (100%) octoclock_octoclock_fw_default-g14000041.zip
00007 kB / 00007 kB (100%) usrp2_usrp2_fw_default-g6bea23d.zip
00009 kB / 00009 kB (100%) usrp2_n200_fw_default-g6bea23d.zip
00450 kB / 00450 kB (100%) usrp2_usrp2_fpga_default-g6bea23d.zip
00144 kB / 00144 kB (100%) b2xx_common_fw_default-ga69ab0c.zip
25107 kB / 25107 kB (100%) n3xx_n320_fpga_default-g3de8954a.zip
00464 kB / 00464 kB (100%) b2xx_b200mini_fpga_default-ge57dfe0.zip
00319 kB / 00319 kB (100%) usrp1_usrp1_fpga_default-g6bea23d.zip
04839 kB / 04839 kB (100%) usb_common_windrv_default-g14000041.zip
00009 kB / 00009 kB (100%) usrp2_n210_fw_default-g6bea23d.zip
16065 kB / 16065 kB (100%) n3xx_n300_fpga_default-g3de8954a.zip
05578 kB / 05578 kB (100%) e3xx_e310_fpga_default-g4bc2c6f.zip
00885 kB / 00885 kB (100%) b2xx_b210_fpga_default-ge57dfe0.zip
[INFO] Images download complete.

NOTE: In the above example output, the Images Destination folder is printed:

[INFO] Images destination: /usr/local/share/uhd/images

To list the N3xx FPGA images with a full path, run the command:

$ ls -w 1 /usr/local/share/uhd/images/usrp_n3*.bit

/usr/local/share/uhd/images/usrp_n300_fpga_AA.bit
/usr/local/share/uhd/images/usrp_n300_fpga_HG.bit
/usr/local/share/uhd/images/usrp_n300_fpga_WX.bit
/usr/local/share/uhd/images/usrp_n300_fpga_XG.bit
/usr/local/share/uhd/images/usrp_n310_fpga_AA.bit
/usr/local/share/uhd/images/usrp_n310_fpga_HG.bit
/usr/local/share/uhd/images/usrp_n310_fpga_WX.bit
/usr/local/share/uhd/images/usrp_n310_fpga_XG.bit
/usr/local/share/uhd/images/usrp_n320_fpga_AQ.bit
/usr/local/share/uhd/images/usrp_n320_fpga_HG.bit
/usr/local/share/uhd/images/usrp_n320_fpga_WX.bit
/usr/local/share/uhd/images/usrp_n320_fpga_XG.bit
/usr/local/share/uhd/images/usrp_n320_fpga_XQ.bit

To update the default <code>HG</code> variant of FPGA image, run the command:

$ uhd_image_loader --args "type=n3xx,addr=<N3xx_IP_ADDR>,fpga=HG"

Example Output:

uhd_image_loader --args "type=n3xx,addr=192.168.1.151,fpga=HG"
[INFO] [UHD] linux; GNU C++ version 5.4.0 20160609; Boost_105800; UHD_3.11.1.HEAD-0-gad6b0935
[INFO] [MPMD] Initializing 1 device(s) in parallel with args: mgmt_addr=192.168.1.151,type=n3xx,product=n310,serial=313ABDA,claimed=False,skip_init=1
[INFO] [MPM.main] Launching USRP/MPM, version: 3.11.1.0-gunknown
[INFO] [MPM.main] Spawning RPC process...
[INFO] [MPM.PeriphManager] Device serial number: 313ABDA
[INFO] [MPM.PeriphManager] Found 2 daughterboard(s).
[INFO] [MPM.PeriphManager.UDP] No CHDR interfaces found!
[INFO] [MPM.PeriphManager.UDP] No CHDR interfaces found!
[INFO] [MPM.RPCServer] RPC server ready!
[INFO] [MPM.RPCServer] Spawning watchdog task...
[INFO] [MPM.PeriphManager.UDP] No CHDR interfaces found!
[INFO] [MPMD] Claimed device without full initialization.
[INFO] [MPMD IMAGE LOADER] Starting update. This may take a while.
[INFO] [MPM.PeriphManager] Updating component `fpga'
[INFO] [MPM.PeriphManager] Updating component `dts'
[INFO] [MPM.RPCServer] Resetting peripheral manager.
[INFO] [MPM.PeriphManager] Device serial number: 313ABDA
[INFO] [MPM.PeriphManager] Found 2 daughterboard(s).
[INFO] [MPMD IMAGE LOADER] Update component function succeeded.

To load a different default FPGA image (i.e. <code>XG</code>, <code>WG</code>), modify the device argument <code>fpga=</code> to a value of <code>fpga=XG</code> or <code>fpga=WG</code>.

To specify the path to a custom FPGA image, use the <code>--fpga-path</code> argument.

$ uhd_image_loader --args "type=n3xx,addr=<N3xx_IP_ADDR>" --fpga-path=/path/to/custom/fpga.bit

The Verilog code for the FPGA in the USRP N3xx 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.

===Embedded Mode FPGA Image Update===

It is possible to update the FPGA image when operated in Embedded mode. Connect to the ARM CPU via Serial Console or SSH as detailed in the section above.

Updating the FPGA image from the ARM CPU is the same as detailed above for a Network mode update, except it is not required to provide an <code>addr</code> device argument.

uhd_image_loader --args "type=n3xx,fpga=HG"

<pre>
root@ni-n3xx-313ABDA:~# uhd_image_loader --args "type=n3xx,fpga=HG"
[INFO] [UHD] linux; GNU C++ version 7.2.0; Boost_106400; UHD_3.11.1.0-0-unknown
[INFO] [MPMD] Initializing 1 device(s) in parallel with args: mgmt_addr=127.0.0.1,type=n3xx,product=n310,serial=313ABDA,claimed=False,skip_init=1
[INFO] [MPMD] Claimed device without full initialization.
[INFO] [MPMD IMAGE LOADER] Starting update. This may take a while.
[INFO] [MPM.PeriphManager] Updating component `fpga'
[INFO] [MPM.PeriphManager] Updating component `dts'
[INFO] [MPM.RPCServer] Resetting peripheral manager.
[INFO] [MPM.PeriphManager] Device serial number: 313ABDA
[INFO] [MPM.PeriphManager] Found 2 daughterboard(s).
[INFO] [MPMD IMAGE LOADER] Update component function succeeded.
</pre>

For more information on updating the FPGA image, refer to the UHD Manual at http://uhd.ettus.com .

==Setting Up a Streaming Connection==
The device supports multiple, high-speed, low-latency interfaces on the SFP+ ports for streaming samples to the host computer.

===1Gb Streaming SFP Port 0===
Complete the steps below to set up a streaming connection over the 1 Gigabit Ethernet interface on <code>SFP Port 0</code>.

When streaming via SFP Port 0 at 1 Gb speeds, it is important that the connection is direct between the Host and USRP. Placing a switch or other network gear between the Host and USRP can reduce throughput of the transport link. It is also generally recommended to avoid using USB to Ethernet Adapters for the high speed streaming interface, as they may limit performance or cause periodic flow control errors.

NOTE: The <code>HG</code> FPGA image must be loaded for <code>SFP Port 0</code> to operate at 1Gb speeds. If the <code>XG</code> image is loaded, the port will be unresponsive at 1Gb speeds.

1. Configure your Host's Ethernet adapter as shown below. This interface should be separate from the 1Gb NIC/network which is connected to the 1Gb RJ45 management interface.

IP Address: 192.168.10.1
Subnet Mask: 255.255.255.0
Gateway: 0.0.0.0
MTU: 1500

NOTE: When operating <code>SFP Port 0</code> at 1Gb speeds, it is important to set a MTU of <code>1500</code> and not a value of <code>automatic</code>.

2. Insert the RJ45 – SFP+ adapter into <code>SFP Port 0</code> .

3. Connect the adapter to a host computer using the Ethernet cable to SFP0.

The Green LED above <code>SFP Port 0</code> should illuminate.

4. To test the connection, <code>ping</code> the device at address <code>192.168.10.2</code> from the host, as shown
below:

$ ping 192.168.10.2
PING 192.168.10.2 (192.168.10.2) 56(84) bytes of data.
64 bytes from 192.168.10.2: icmp_seq=1 ttl=64 time=1.06 ms
^C
--- 192.168.10.2 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 1.065/1.065/1.065/0.000 ms

Press <code>CTRL+C</code> to stop the ping program.

Proceed to the next section "Verifying Device Operation".

===10Gb Streaming SFP Port 1===
Complete the steps below to set up a streaming connection over the 10 Gigabit Ethernet interface on <code>SFP Port 1</code>.

NOTE: Both the <code>HG</code> and <code>XG</code> FPGA images support 10Gb speeds over SFP Port 1.

1. Configure your Host's 10Gb Ethernet adapter as shown below.

IP Address: 192.168.20.1
Subnet Mask: 255.255.255.0
Gateway: 0.0.0.0
MTU: 9000

NOTE: When operating at 10Gb speeds, it is important to set a MTU of <code>9000</code> and not a value of <code>automatic</code>.

2. Connect the USRP to a host computer using either a 10Gb SFP or Fiber cable to <code>SFP Port 1</code>.

The Green LED above <code>SFP Port 1</code> should illuminate.

3. To test the connection, <code>ping</code> the device at address <code>192.168.20.2</code> from the host, as shown
below:

$ ping 192.168.20.2

Press <code>CTRL+C</code> to stop the ping program.

Proceed to the next section "Verifying Device Operation".

===Dual 10Gb Streaming SFP Ports 0/1===
Complete the steps below to set up a streaming connections over the Dual 10 Gigabit Ethernet interface on <code>SFP Ports 0/1</code>.

NOTE: The <code>XG</code> FPGA image must be loaded for <code>SFP Port 0</code> to operate at 10 Gb speeds. If the <code>HG</code> image is loaded, the port will be unresponsive at 10 Gb speeds.

1. Configure your Host's #1 10Gb Ethernet adapter as shown below.

IP Address: 192.168.10.1
Subnet Mask: 255.255.255.0
Gateway: 0.0.0.0
MTU: 9000

2. Configure your Host's #2 10Gb Ethernet adapter as shown below.

IP Address: 192.168.20.1
Subnet Mask: 255.255.255.0
Gateway: 0.0.0.0
MTU: 9000

NOTE: When operating at 10Gb speeds, it is important to set a MTU of <code>9000</code> and not a value of <code>automatic</code>.

3. Connect the USRP to a host computer using either a 10Gb SFP or Fiber cables to <code>SFP Ports 0/1</code>.

The Green LEDs above <code>SFP Ports 0/1</code> should illuminate.

4. To test the <code>SFP Port 0</code> connection, <code>ping</code> the device at address <code>192.168.10.2</code> from the host, as shown below:

$ ping 192.168.10.2

Press <code>CTRL+C</code> to stop the ping program.

5. To test the <code>SFP Port 1</code> connection, <code>ping</code> the device at address <code>192.168.20.2</code> from the host, as shown below:

$ ping 192.168.20.2

Press <code>CTRL+C</code> to stop the ping program.

Proceed to the next section "Verifying Device Operation".

For more details on Network Setup and Configuration, please see the “Interfaces and Connectivity” section on the [[N300/N310]] or [[N320/N321]] hardware resources pages.

==Verifying Device Operation==
Once you have successfully setup a management interface and streaming interface, you can now verify the devices operation using the included UHD utilities.

===Subdevice Specification Mapping===
====N300====
The USRP N300 contains 2 channels, each represented on the front panel as <code>RF0-1</code>. Below is the <code>subdev</code> mapping of RF Ports.

* RF0 = A:0
* RF1 = A:1

====N310====
The USRP N310 contains 4 channels, each represented on the front panel as <code>RF0-3</code>. Below is the <code>subdev</code> mapping of RF Ports.

=====UHD 3.11.x.x - 3.12.x.x=====
* RF0 = A:0
* RF1 = B:0
* RF2 = C:0
* RF3 = D:0

=====UHD 3.13.x.x+=====
* RF0 = A:0
* RF1 = A:1
* RF2 = B:0
* RF3 = B:1

====N320====
The USRP N320 contains 2 channels, each represented on the front panel as <code>RF0-1</code>. Below is the <code>subdev</code> mapping of RF Ports.

* RF0 = A:0
* RF1 = B:0

====N321====
The USRP N321 contains 2 channels, each represented on the front panel as <code>RF0-1</code>. Below is the <code>subdev</code> mapping of RF Ports.

* RF0 = A:0
* RF1 = B:0

Additional details of UHD Subdevice Specifications can be found here in the UHD Manual: http://files.ettus.com/manual/page_configuration.html#config_subdev

===Supported Sample Rates===

The USRP N300/N310 supports the three fixed Master Clock Rates listed below.

* 122.88 MHz
* 125.00 MHz
* 153.60 MHz

The USRP N320/N321 supports the three fixed Master Clock Rates listed below.

* 200.00 MHz
* 245.76 MHz
* 250.00 MHz

Sample rates as delivered to/from the host computer for USRP devices are constrained to follow several important rules.

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.

====Example Sample Rates====
Listed below are common sample rates for the given master clock rates. This is not a complete listing of the supported sample rates.

{| class="wikitable"
!Master Clock Rate
!colspan="20"|Decimation / Interpolation Rate <br> Host Sample Rate [Msps]
|-

|style="text-align:center;"| 1
|style="text-align:center;"| 2
|style="text-align:center;"| 4
|style="text-align:center;"| 6
|style="text-align:center;"| 8
|style="text-align:center;"| 10
|style="text-align:center;"| 12
|style="text-align:center;"| 14
|style="text-align:center;"| 16
|style="text-align:center;"| 18
|style="text-align:center;"| 20
|style="text-align:center;"| 30
|style="text-align:center;"| 32
|style="text-align:center;"| 64
|style="text-align:center;"| 100
|style="text-align:center;"| 128
|style="text-align:center;"| 200
|style="text-align:center;"| 256
|style="text-align:center;"| 512
|style="text-align:center;"| 1024
|-

|style="text-align:center;"| 122.88e6
|style="text-align:center;"| 61.44e6
|style="text-align:center;"| 30.72e6
|style="text-align:center;"| 20.48e6
|style="text-align:center;"| 15.36e6
|style="text-align:center;"| 12.288e6
|style="text-align:center;"| 10.24e6
|style="text-align:center;"| 8.7771e6
|style="text-align:center;"| 7.68e6
|style="text-align:center;"| 6.8267e6
|style="text-align:center;"| 6.144e6
|style="text-align:center;"| 4.096e6
|style="text-align:center;"| 3.84e6
|style="text-align:center;"| 1.92e6
|style="text-align:center;"| 1.2288e6
|style="text-align:center;"| 960e3
|style="text-align:center;"| 614.4e3
|style="text-align:center;"| 480e3
|style="text-align:center;"| 240e3
|style="text-align:center;"| 120e3
|-

|style="text-align:center;"| 125e6
|style="text-align:center;"| 62.5e6
|style="text-align:center;"| 31.25e6
|style="text-align:center;"| 20.833e6
|style="text-align:center;"| 15.625e6
|style="text-align:center;"| 12.5e6
|style="text-align:center;"| 10.417e6
|style="text-align:center;"| 8.9286e6
|style="text-align:center;"| 7.8125e6
|style="text-align:center;"| 6.9444e6
|style="text-align:center;"| 6.25e6
|style="text-align:center;"| 4.1667e6
|style="text-align:center;"| 3.90625e6
|style="text-align:center;"| 1.953125e6
|style="text-align:center;"| 1.25e6
|style="text-align:center;"| 976.5625e3
|style="text-align:center;"| 625e3
|style="text-align:center;"| 488.28125e3
|style="text-align:center;"| 244.14e3
|style="text-align:center;"| 122.07e3

|-

|style="text-align:center;"| 153.6e6
|style="text-align:center;"| 76.8e6
|style="text-align:center;"| 38.4e6
|style="text-align:center;"| 25.6e6
|style="text-align:center;"| 19.2e6
|style="text-align:center;"| 15.36e6
|style="text-align:center;"| 12.8e6
|style="text-align:center;"| 10.971e6
|style="text-align:center;"| 9.6e6
|style="text-align:center;"| 8.5333e6
|style="text-align:center;"| 7.68e6
|style="text-align:center;"| 5.12e6
|style="text-align:center;"| 4.8e6
|style="text-align:center;"| 2.4e6
|style="text-align:center;"| 1.536e6
|style="text-align:center;"| 1.2e6
|style="text-align:center;"| 768e3
|style="text-align:center;"| 600e3
|style="text-align:center;"| 300e3
|style="text-align:center;"| 150e3

|-

|}

====N320/N321 Example Sample Rates====
Listed below are common sample rates for the given master clock rates. This is not a complete listing of the supported sample rates.

{| class="wikitable"
!Master Clock Rate
!colspan="20"|Decimation / Interpolation Rate <br> Host Sample Rate [Msps]
|-

|style="text-align:center;"| 1
|style="text-align:center;"| 2
|style="text-align:center;"| 4
|style="text-align:center;"| 6
|style="text-align:center;"| 8
|style="text-align:center;"| 10
|style="text-align:center;"| 12
|style="text-align:center;"| 14
|style="text-align:center;"| 16
|style="text-align:center;"| 18
|style="text-align:center;"| 20
|style="text-align:center;"| 30
|style="text-align:center;"| 32
|style="text-align:center;"| 64
|style="text-align:center;"| 100
|style="text-align:center;"| 128
|style="text-align:center;"| 200
|style="text-align:center;"| 256
|style="text-align:center;"| 512
|style="text-align:center;"| 1024
|-

|style="text-align:center;"| 200e6
|style="text-align:center;"| 100e6
|style="text-align:center;"| 50e6
|style="text-align:center;"| 33.33e6
|style="text-align:center;"| 25e6
|style="text-align:center;"| 20e6
|style="text-align:center;"| 16.66e6
|style="text-align:center;"| 14.2857e6
|style="text-align:center;"| 12.5e6
|style="text-align:center;"| 11.11e6
|style="text-align:center;"| 10e6
|style="text-align:center;"| 6.667e6
|style="text-align:center;"| 6.25e6
|style="text-align:center;"| 3.125e6
|style="text-align:center;"| 2e6
|style="text-align:center;"| 1.5625e6
|style="text-align:center;"| 1e6
|style="text-align:center;"| 781.25e3
|style="text-align:center;"| 390.625e3
|style="text-align:center;"| 195.3125e3

|-

|style="text-align:center;"| 245.76e6
|style="text-align:center;"| 122.88e6
|style="text-align:center;"| 61.44e6
|style="text-align:center;"| 30.72e6
|style="text-align:center;"| 20.48e6
|style="text-align:center;"| 15.36e6
|style="text-align:center;"| 12.288e6
|style="text-align:center;"| 10.24e6
|style="text-align:center;"| 8.7771e6
|style="text-align:center;"| 7.68e6
|style="text-align:center;"| 6.8267e6
|style="text-align:center;"| 6.144e6
|style="text-align:center;"| 4.096e6
|style="text-align:center;"| 3.84e6
|style="text-align:center;"| 1.92e6
|style="text-align:center;"| 1.2288e6
|style="text-align:center;"| 960e3
|style="text-align:center;"| 614.4e3
|style="text-align:center;"| 480e3
|style="text-align:center;"| 240e3
|-

|style="text-align:center;"| 250e6
|style="text-align:center;"| 125e6
|style="text-align:center;"| 62.5e6
|style="text-align:center;"| 31.25e6
|style="text-align:center;"| 20.833e6
|style="text-align:center;"| 15.625e6
|style="text-align:center;"| 12.5e6
|style="text-align:center;"| 10.417e6
|style="text-align:center;"| 8.9286e6
|style="text-align:center;"| 7.8125e6
|style="text-align:center;"| 6.9444e6
|style="text-align:center;"| 6.25e6
|style="text-align:center;"| 4.1667e6
|style="text-align:center;"| 3.90625e6
|style="text-align:center;"| 1.953125e6
|style="text-align:center;"| 1.25e6
|style="text-align:center;"| 976.5625e3
|style="text-align:center;"| 625e3
|style="text-align:center;"| 488.28125e3
|style="text-align:center;"| 244.14e3

|-

|}

Additional information on Sample Rates can be found here in the UHD Manual: http://files.ettus.com/manual/page_general.html#general_sampleratenotes

===Probe the USRP===

====N300/N310====
The UHD utility <code>uhd_usrp_probe</code> provides detailed information of the USRP device.

From your host computer, run the command <code>uhd_usrp_probe</code>:

<pre>
$ uhd_usrp_probe
[INFO] [UHD] linux; GNU C++ version 5.4.0 20160609; Boost_105800; UHD_3.13.1.HEAD-0-ga0a71d10
[INFO] [MPMD] Initializing 1 device(s) in parallel with args: mgmt_addr=192.168.10.2,type=n3xx,product=n310,serial=313ABDA,claimed=False,addr=192.168.10.2
[INFO] [MPM.main] Launching USRP/MPM, version: 3.13.1.0-gd3b7e90a
[INFO] [MPM.main] Spawning RPC process...
[INFO] [MPM.PeriphManager] Device serial number: 313ABDA
[INFO] [MPM.PeriphManager] Initialized 2 daughterboard(s).
[INFO] [MPM.PeriphManager] init() called with device args `time_source=internal,clock_source=internal'.
[INFO] [MPM.RPCServer] RPC server ready!
[INFO] [MPM.RPCServer] Spawning watchdog task...
[INFO] [0/DmaFIFO_0] Initializing block control (NOC ID: 0xF1F0D00000000004)
[INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1355 MB/s)
[INFO] [MPM.PeriphManager] init() called with device args `mgmt_addr=192.168.10.2,clock_source=internal,time_source=internal,product=n310'.
[INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1358 MB/s)
[INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1355 MB/s)
[INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1345 MB/s)
[INFO] [0/Radio_0] Initializing block control (NOC ID: 0x12AD100000011312)
[INFO] [0/Radio_1] Initializing block control (NOC ID: 0x12AD100000011312)
[INFO] [0/DDC_0] Initializing block control (NOC ID: 0xDDC0000000000000)
[INFO] [0/DDC_1] Initializing block control (NOC ID: 0xDDC0000000000000)
[INFO] [0/DUC_0] Initializing block control (NOC ID: 0xD0C0000000000002)
[INFO] [0/DUC_1] Initializing block control (NOC ID: 0xD0C0000000000002)
_____________________________________________________
/
| Device: N300-Series Device
| _____________________________________________________
| /
| | Mboard: ni-n3xx-313ABDA
| | eeprom_version: 1
| | mpm_version: 3.13.1.0-gd3b7e90a
| | pid: 16962
| | product: n310
| | rev: 3
| | rpc_connection: remote
| | serial: 313ABDA
| | type: n3xx
| | MPM Version: 1.2
| | FPGA Version: 5.2
| | RFNoC capable: Yes
| |
| | Time sources: internal, external, gpsdo, sfp0
| | Clock sources: external, internal, gpsdo
| | Sensors: gps_tpv, ref_locked, gps_time, gps_locked, temp, gps_sky, fan
| | _____________________________________________________
| | /
| | | RX Dboard: A
| | | _____________________________________________________
| | | /
| | | | RX Frontend: 0
| | | | Name: Magnesium
| | | | Antennas: TX/RX, RX2, CAL, LOCAL
| | | | Sensors: lo_locked, ad9371_lo_locked, lowband_lo_locked
| | | | Freq range: 1.000 to 6000.000 MHz
| | | | Gain range all: 0.0 to 75.0 step 0.5 dB
| | | | Gain range rfic: 0.0 to 0.0 step 0.0 dB
| | | | Gain range dsa: 0.0 to 0.0 step 0.0 dB
| | | | Gain range amp: 0.0 to 0.0 step 0.0 dB
| | | | Bandwidth range: 20000000.0 to 100000000.0 step 0.0 Hz
| | | | Connection Type: IQ
| | | | Uses LO offset: No
| | | _____________________________________________________
| | | /
| | | | RX Frontend: 1
| | | | Name: Magnesium
| | | | Antennas: TX/RX, RX2, CAL, LOCAL
| | | | Sensors: lo_locked, ad9371_lo_locked, lowband_lo_locked
| | | | Freq range: 1.000 to 6000.000 MHz
| | | | Gain range all: 0.0 to 75.0 step 0.5 dB
| | | | Gain range rfic: 0.0 to 0.0 step 0.0 dB
| | | | Gain range dsa: 0.0 to 0.0 step 0.0 dB
| | | | Gain range amp: 0.0 to 0.0 step 0.0 dB
| | | | Bandwidth range: 20000000.0 to 100000000.0 step 0.0 Hz
| | | | Connection Type: IQ
| | | | Uses LO offset: No
| | | _____________________________________________________
| | | /
| | | | RX Codec: A
| | | | Name: AD9371 Dual ADC
| | | | Gain Elements: None
| | _____________________________________________________
| | /
| | | RX Dboard: B
| | | _____________________________________________________
| | | /
| | | | RX Frontend: 0
| | | | Name: Magnesium
| | | | Antennas: TX/RX, RX2, CAL, LOCAL
| | | | Sensors: lo_locked, ad9371_lo_locked, lowband_lo_locked
| | | | Freq range: 1.000 to 6000.000 MHz
| | | | Gain range all: 0.0 to 75.0 step 0.5 dB
| | | | Gain range rfic: 0.0 to 0.0 step 0.0 dB
| | | | Gain range dsa: 0.0 to 0.0 step 0.0 dB
| | | | Gain range amp: 0.0 to 0.0 step 0.0 dB
| | | | Bandwidth range: 20000000.0 to 100000000.0 step 0.0 Hz
| | | | Connection Type: IQ
| | | | Uses LO offset: No
| | | _____________________________________________________
| | | /
| | | | RX Frontend: 1
| | | | Name: Magnesium
| | | | Antennas: TX/RX, RX2, CAL, LOCAL
| | | | Sensors: lo_locked, ad9371_lo_locked, lowband_lo_locked
| | | | Freq range: 1.000 to 6000.000 MHz
| | | | Gain range all: 0.0 to 75.0 step 0.5 dB
| | | | Gain range rfic: 0.0 to 0.0 step 0.0 dB
| | | | Gain range dsa: 0.0 to 0.0 step 0.0 dB
| | | | Gain range amp: 0.0 to 0.0 step 0.0 dB
| | | | Bandwidth range: 20000000.0 to 100000000.0 step 0.0 Hz
| | | | Connection Type: IQ
| | | | Uses LO offset: No
| | | _____________________________________________________
| | | /
| | | | RX Codec: B
| | | | Name: AD9371 Dual ADC
| | | | Gain Elements: None
| | _____________________________________________________
| | /
| | | TX Dboard: A
| | | _____________________________________________________
| | | /
| | | | TX Frontend: 0
| | | | Name: Magnesium
| | | | Antennas: TX/RX
| | | | Sensors: lo_locked, ad9371_lo_locked, lowband_lo_locked
| | | | Freq range: 1.000 to 6000.000 MHz
| | | | Gain range all: 0.0 to 65.0 step 0.5 dB
| | | | Gain range rfic: 0.0 to 0.0 step 0.0 dB
| | | | Gain range dsa: 0.0 to 0.0 step 0.0 dB
| | | | Gain range amp: 0.0 to 0.0 step 0.0 dB
| | | | Bandwidth range: 20000000.0 to 100000000.0 step 0.0 Hz
| | | | Connection Type: IQ
| | | | Uses LO offset: No
| | | _____________________________________________________
| | | /
| | | | TX Frontend: 1
| | | | Name: Magnesium
| | | | Antennas: TX/RX
| | | | Sensors: lo_locked, ad9371_lo_locked, lowband_lo_locked
| | | | Freq range: 1.000 to 6000.000 MHz
| | | | Gain range all: 0.0 to 65.0 step 0.5 dB
| | | | Gain range rfic: 0.0 to 0.0 step 0.0 dB
| | | | Gain range dsa: 0.0 to 0.0 step 0.0 dB
| | | | Gain range amp: 0.0 to 0.0 step 0.0 dB
| | | | Bandwidth range: 20000000.0 to 100000000.0 step 0.0 Hz
| | | | Connection Type: IQ
| | | | Uses LO offset: No
| | | _____________________________________________________
| | | /
| | | | TX Codec: A
| | | | Name: AD9371 Dual DAC
| | | | Gain Elements: None
| | _____________________________________________________
| | /
| | | TX Dboard: B
| | | _____________________________________________________
| | | /
| | | | TX Frontend: 0
| | | | Name: Magnesium
| | | | Antennas: TX/RX
| | | | Sensors: lo_locked, ad9371_lo_locked, lowband_lo_locked
| | | | Freq range: 1.000 to 6000.000 MHz
| | | | Gain range all: 0.0 to 65.0 step 0.5 dB
| | | | Gain range rfic: 0.0 to 0.0 step 0.0 dB
| | | | Gain range dsa: 0.0 to 0.0 step 0.0 dB
| | | | Gain range amp: 0.0 to 0.0 step 0.0 dB
| | | | Bandwidth range: 20000000.0 to 100000000.0 step 0.0 Hz
| | | | Connection Type: IQ
| | | | Uses LO offset: No
| | | _____________________________________________________
| | | /
| | | | TX Frontend: 1
| | | | Name: Magnesium
| | | | Antennas: TX/RX
| | | | Sensors: lo_locked, ad9371_lo_locked, lowband_lo_locked
| | | | Freq range: 1.000 to 6000.000 MHz
| | | | Gain range all: 0.0 to 65.0 step 0.5 dB
| | | | Gain range rfic: 0.0 to 0.0 step 0.0 dB
| | | | Gain range dsa: 0.0 to 0.0 step 0.0 dB
| | | | Gain range amp: 0.0 to 0.0 step 0.0 dB
| | | | Bandwidth range: 20000000.0 to 100000000.0 step 0.0 Hz
| | | | Connection Type: IQ
| | | | Uses LO offset: No
| | | _____________________________________________________
| | | /
| | | | TX Codec: B
| | | | Name: AD9371 Dual DAC
| | | | Gain Elements: None
| | _____________________________________________________
| | /
| | | RFNoC blocks on this device:
| | |
| | | * DmaFIFO_0
| | | * Radio_0
| | | * Radio_1
| | | * DDC_0
| | | * DDC_1
| | | * DUC_0
| | | * DUC_1

</pre>

====N320====

<pre>

$ uhd_usrp_probe
[INFO] [UHD] linux; GNU C++ version 7.3.0; Boost_106600; UHD_3.14.0.0-0-g6875d061
[INFO] [MPMD] Initializing 1 device(s) in parallel with args: mgmt_addr=127.0.0.1,type=n3xx,product=n320,serial=3181FFA,claimed=False
[INFO] [MPM.main] Launching USRP/MPM, version: 3.14.0.0-g6875d061
[INFO] [MPM.main] Spawning RPC process...
[INFO] [MPM.PeriphManager] Device serial number: 3181FFA
[INFO] [MPM.Rhodium-0] Successfully loaded all peripherals!
[INFO] [MPM.Rhodium-1] Successfully loaded all peripherals!
[INFO] [MPM.PeriphManager] Initialized 2 daughterboard(s).
[INFO] [MPM.PeriphManager] No QSFP board detected: Assuming it is disabled in the device tree overlay (e.g., HG, XG images).
[INFO] [MPM.PeriphManager] init() called with device args `time_source=internal,clock_source=internal'.
[INFO] [MPM.Rhodium-0] init() called with args `time_source=internal,clock_source=internal'
[INFO] [MPM.Rhodium-1] init() called with args `time_source=internal,clock_source=internal'
[INFO] [MPM.Rhodium-0.init.LMK04828] LMK initialized and locked!
[INFO] [MPM.Rhodium-1.init.LMK04828] LMK initialized and locked!
[INFO] [MPM.Rhodium-1.DAC37J82] DAC PLL Locked!
[INFO] [MPM.Rhodium-1.AD9695] ADC PLL Locked!
[INFO] [MPM.Rhodium-1.init] JESD204B Link Initialization & Training Complete
[INFO] [MPM.Rhodium-0.DAC37J82] DAC PLL Locked!
[INFO] [MPM.Rhodium-0.AD9695] ADC PLL Locked!
[INFO] [MPM.Rhodium-0.init] JESD204B Link Initialization & Training Complete
[INFO] [MPM.RPCServer] RPC server ready!
[INFO] [MPM.RPCServer] Spawning watchdog task...
[INFO] [MPM.PeriphManager] init() called with device args `mgmt_addr=127.0.0.1,clock_source=internal,time_source=internal,product=n320'.
[INFO] [MPM.Rhodium-0] init() called with args `mgmt_addr=127.0.0.1,clock_source=internal,time_source=internal,product=n320'
[INFO] [MPM.Rhodium-1] init() called with args `mgmt_addr=127.0.0.1,clock_source=internal,time_source=internal,product=n320'
[INFO] [0/Replay_0] Initializing block control (NOC ID: 0x4E91A00000000004)
[INFO] [0/Radio_0] Initializing block control (NOC ID: 0x12AD100000000320)
[INFO] [0/Radio_1] Initializing block control (NOC ID: 0x12AD100000000320)
[INFO] [0/DDC_0] Initializing block control (NOC ID: 0xDDC0000000000001)
[INFO] [0/DDC_1] Initializing block control (NOC ID: 0xDDC0000000000001)
[INFO] [0/DUC_0] Initializing block control (NOC ID: 0xD0C0000000000000)
[INFO] [0/DUC_1] Initializing block control (NOC ID: 0xD0C0000000000000)
[INFO] [0/FIFO_0] Initializing block control (NOC ID: 0xF1F0000000000000)
[INFO] [0/FIFO_1] Initializing block control (NOC ID: 0xF1F0000000000000)
_____________________________________________________
/
| Device: N300-Series Device
| _____________________________________________________
| /
| | Mboard: ni-n3xx-3181FFA
| | eeprom_version: 2
| | mpm_version: 3.14.0.0-g6875d061
| | pid: 16962
| | product: n320
| | rev: 6
| | rpc_connection: local
| | serial: 3181FFA
| | type: n3xx
| | MPM Version: 1.2
| | FPGA Version: 5.3
| | FPGA git hash: 3de8954.clean
| | RFNoC capable: Yes
| |
| | Time sources: internal, external, gpsdo, sfp0
| | Clock sources: external, internal, gpsdo
| | Sensors: gps_tpv, temp, gps_sky, fan, gps_time, gps_locked, ref_locked, gps_gpgga
| | _____________________________________________________
| | /
| | | RX Dboard: A
| | | ID: Unknown (0x0152)
| | | Serial: 3175A79
| | | _____________________________________________________
| | | /
| | | | RX Frontend: 0
| | | | Name: Rhodium
| | | | Antennas: TX/RX, RX2, CAL, TERM
| | | | Sensors: lo_locked
| | | | Freq range: 1.000 to 6000.000 MHz
| | | | Gain range all: 0.0 to 60.0 step 1.0 dB
| | | | Bandwidth range: 250000000.0 to 250000000.0 step 0.0 Hz
| | | | Connection Type:
| | | | Uses LO offset: No
| | | _____________________________________________________
| | | /
| | | | RX Codec: A
| | | | Name: ad9695-625
| | | | Gain Elements: None
| | _____________________________________________________
| | /
| | | RX Dboard: B
| | | ID: Unknown (0x0152)
| | | Serial: 3175A67
| | | _____________________________________________________
| | | /
| | | | RX Frontend: 0
| | | | Name: Rhodium
| | | | Antennas: TX/RX, RX2, CAL, TERM
| | | | Sensors: lo_locked
| | | | Freq range: 1.000 to 6000.000 MHz
| | | | Gain range all: 0.0 to 60.0 step 1.0 dB
| | | | Bandwidth range: 250000000.0 to 250000000.0 step 0.0 Hz
| | | | Connection Type:
| | | | Uses LO offset: No
| | | _____________________________________________________
| | | /
| | | | RX Codec: B
| | | | Name: ad9695-625
| | | | Gain Elements: None
| | _____________________________________________________
| | /
| | | TX Dboard: A
| | | ID: Unknown (0x0152)
| | | Serial: 3175A79
| | | _____________________________________________________
| | | /
| | | | TX Frontend: 0
| | | | Name: Rhodium
| | | | Antennas: TX/RX, CAL, TERM
| | | | Sensors: lo_locked
| | | | Freq range: 1.000 to 6000.000 MHz
| | | | Gain range all: 0.0 to 60.0 step 1.0 dB
| | | | Bandwidth range: 250000000.0 to 250000000.0 step 0.0 Hz
| | | | Connection Type:
| | | | Uses LO offset: No
| | | _____________________________________________________
| | | /
| | | | TX Codec: A
| | | | Name: dac37j82
| | | | Gain Elements: None
| | _____________________________________________________
| | /
| | | TX Dboard: B
| | | ID: Unknown (0x0152)
| | | Serial: 3175A67
| | | _____________________________________________________
| | | /
| | | | TX Frontend: 0
| | | | Name: Rhodium
| | | | Antennas: TX/RX, CAL, TERM
| | | | Sensors: lo_locked
| | | | Freq range: 1.000 to 6000.000 MHz
| | | | Gain range all: 0.0 to 60.0 step 1.0 dB
| | | | Bandwidth range: 250000000.0 to 250000000.0 step 0.0 Hz
| | | | Connection Type:
| | | | Uses LO offset: No
| | | _____________________________________________________
| | | /
| | | | TX Codec: B
| | | | Name: dac37j82
| | | | Gain Elements: None
| | _____________________________________________________
| | /
| | | RFNoC blocks on this device:
| | |
| | | * Replay_0
| | | * Radio_0
| | | * Radio_1
| | | * DDC_0
| | | * DDC_1
| | | * DUC_0
| | | * DUC_1
| | | * FIFO_0
| | | * FIFO_1

</pre>

====N321====

<pre>
$ uhd_usrp_probe
[INFO] [UHD] linux; GNU C++ version 7.3.1 20180712 (Red Hat 7.3.1-6); Boost_106400; UHD_3.14.0.0-0-g6875d061
[INFO] [MPMD] Initializing 1 device(s) in parallel with args: mgmt_addr=192.168.20.2,type=n3xx,product=n320,serial=3166646,claimed=False,addr=192.168.20.2
[INFO] [MPM.PeriphManager] init() called with device args `time_source=internal,clock_source=internal,product=n320,mgmt_addr=192.168.20.2'.
[INFO] [MPM.Rhodium-0] init() called with args `time_source=internal,clock_source=internal,product=n320,mgmt_addr=192.168.20.2'
[INFO] [MPM.Rhodium-1] init() called with args `time_source=internal,clock_source=internal,product=n320,mgmt_addr=192.168.20.2'
[INFO] [0/Replay_0] Initializing block control (NOC ID: 0x4E91A00000000004)
[INFO] [0/Radio_0] Initializing block control (NOC ID: 0x12AD100000000320)
[INFO] [0/Radio_1] Initializing block control (NOC ID: 0x12AD100000000320)
[INFO] [0/DDC_0] Initializing block control (NOC ID: 0xDDC0000000000001)
[INFO] [0/DDC_1] Initializing block control (NOC ID: 0xDDC0000000000001)
[INFO] [0/DUC_0] Initializing block control (NOC ID: 0xD0C0000000000000)
[INFO] [0/DUC_1] Initializing block control (NOC ID: 0xD0C0000000000000)
[INFO] [0/FIFO_0] Initializing block control (NOC ID: 0xF1F0000000000000)
[INFO] [0/FIFO_1] Initializing block control (NOC ID: 0xF1F0000000000000)
_____________________________________________________
/
| Device: N300-Series Device
| _____________________________________________________
| /
| | Mboard: ni-n3xx-3166646
| | eeprom_version: 2
| | mpm_version: 3.14.0.0-g6875d061
| | pid: 16962
| | product: n320
| | rev: 6
| | rpc_connection: remote
| | serial: 3166646
| | type: n3xx
| | MPM Version: 1.2
| | FPGA Version: 5.3
| | FPGA git hash: 3de8954.clean
| | RFNoC capable: Yes
| |
| | Time sources: internal, external, gpsdo, sfp0
| | Clock sources: external, internal, gpsdo
| | Sensors: gps_sky, gps_time, gps_gpgga, gps_locked, fan, gps_tpv, ref_locked, temp
| | _____________________________________________________
| | /
| | | RX Dboard: B
| | | ID: Unknown (0x0152)
| | | Serial: 316D814
| | | _____________________________________________________
| | | /
| | | | RX Frontend: 0
| | | | Name: Rhodium
| | | | Antennas: TX/RX, RX2, CAL, TERM
| | | | Sensors: lo_locked
| | | | Freq range: 1.000 to 6000.000 MHz
| | | | Gain range all: 0.0 to 60.0 step 1.0 dB
| | | | Bandwidth range: 250000000.0 to 250000000.0 step 0.0 Hz
| | | | Connection Type:
| | | | Uses LO offset: No
| | | _____________________________________________________
| | | /
| | | | RX Codec: B
| | | | Name: ad9695-625
| | | | Gain Elements: None
| | _____________________________________________________
| | /
| | | RX Dboard: A
| | | ID: Unknown (0x0152)
| | | Serial: 316D810
| | | _____________________________________________________
| | | /
| | | | RX Frontend: 0
| | | | Name: Rhodium
| | | | Antennas: TX/RX, RX2, CAL, TERM
| | | | Sensors: lo_locked
| | | | Freq range: 1.000 to 6000.000 MHz
| | | | Gain range all: 0.0 to 60.0 step 1.0 dB
| | | | Bandwidth range: 250000000.0 to 250000000.0 step 0.0 Hz
| | | | Connection Type:
| | | | Uses LO offset: No
| | | _____________________________________________________
| | | /
| | | | RX Codec: A
| | | | Name: ad9695-625
| | | | Gain Elements: None
| | _____________________________________________________
| | /
| | | TX Dboard: B
| | | ID: Unknown (0x0152)
| | | Serial: 316D814
| | | _____________________________________________________
| | | /
| | | | TX Frontend: 0
| | | | Name: Rhodium
| | | | Antennas: TX/RX, CAL, TERM
| | | | Sensors: lo_locked
| | | | Freq range: 1.000 to 6000.000 MHz
| | | | Gain range all: 0.0 to 60.0 step 1.0 dB
| | | | Bandwidth range: 250000000.0 to 250000000.0 step 0.0 Hz
| | | | Connection Type:
| | | | Uses LO offset: No
| | | _____________________________________________________
| | | /
| | | | TX Codec: B
| | | | Name: dac37j82
| | | | Gain Elements: None
| | _____________________________________________________
| | /
| | | TX Dboard: A
| | | ID: Unknown (0x0152)
| | | Serial: 316D810
| | | _____________________________________________________
| | | /
| | | | TX Frontend: 0
| | | | Name: Rhodium
| | | | Antennas: TX/RX, CAL, TERM
| | | | Sensors: lo_locked
| | | | Freq range: 1.000 to 6000.000 MHz
| | | | Gain range all: 0.0 to 60.0 step 1.0 dB
| | | | Bandwidth range: 250000000.0 to 250000000.0 step 0.0 Hz
| | | | Connection Type:
| | | | Uses LO offset: No
| | | _____________________________________________________
| | | /
| | | | TX Codec: A
| | | | Name: dac37j82
| | | | Gain Elements: None
| | _____________________________________________________
| | /
| | | RFNoC blocks on this device:
| | |
| | | * Replay_0
| | | * Radio_0
| | | * Radio_1
| | | * DDC_0
| | | * DDC_1
| | | * DUC_0
| | | * DUC_1
| | | * FIFO_0
| | | * FIFO_1

</pre>

If you see warnings such as:

[WARNING] [UDP] The recv buffer could not be resized sufficiently.

You need to resize the socket buffers for your network interface card:

sudo sysctl -w net.core.rmem_max=288000
sudo sysctl -w net.core.wmem_max=288000
sudo sysctl -w net.core.rmem_max=33554432

===ASCII Art Example===
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

You can quickly verify the operation of your USRP N3xx by running the <code>rx_ascii_art_dft</code> UHD example program.

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.

You can run a simple test of the N3xx USRP by connecting an antenna and observing the spectrum of a commercial FM radio station in real-time, following the steps below:

1. Attach an antenna to the <code>Ch0/RX2</code> antenna port of the N3xx.

2. From your host computer, run the command:

'''N300/N310'''
<pre>
$ /usr/local/lib/uhd/examples/rx_ascii_art_dft --args "master_clock_rate=125e6,mgmt_addr=192.168.1.151,addr=192.168.10.2" --freq 98.5e6 --rate 2.5e6 --gain 50 --ref-lvl="-50" --dyn-rng 90 --ant "RX2" --subdev "A:0"
</pre>

'''N320/N321'''
<pre>
$ /usr/local/lib/uhd/examples/rx_ascii_art_dft --args "master_clock_rate=250e6,mgmt_addr=192.168.1.151,addr=192.168.10.2" --freq 98.5e6 --rate 2.5e6 --gain 50 --ref-lvl="-50" --dyn-rng 90 --ant "RX2" --subdev "A:0"
</pre>

NOTE: Modify the command line 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.

3. You should see a real-time FFT display of 2.5 MHz of spectrum, centered at the specified tuning frequency.

4. Type "<code>Q</code>" or <code>Ctrl-C</code> to stop the program and to return to the Linux command line.

5. You can run with the <code>--help</code> argument to see a description of all available command-line options.

Example Output:

<pre>
$ /usr/local/lib/uhd/examples/rx_ascii_art_dft --args "master_clock_rate=125e6,mgmt_addr=192.168.1.151,addr=192.168.10.2" --freq 98.5e6 --rate 2.5e6 --gain 50 --ref-lvl="-50" --dyn-rng 90 --ant "RX2" --subdev "A:0"

Creating the usrp device with: master_clock_rate=125e6,mgmt_addr=192.168.1.151,addr=192.168.10.2...
[INFO] [UHD] linux; GNU C++ version 5.4.0 20160609; Boost_105800; UHD_3.11.1.HEAD-0-gad6b0935
[INFO] [MPMD] Initializing 1 device(s) in parallel with args: mgmt_addr=192.168.1.151,type=n3xx,product=n310,serial=313ABDA,claimed=False,master_clock_rate=125e6,addr=192.168.10.2
[INFO] [MPM.main] Launching USRP/MPM, version: 3.11.1.0-gunknown
[INFO] [MPM.main] Spawning RPC process...
[INFO] [MPM.PeriphManager] Device serial number: 313ABDA
[INFO] [MPM.PeriphManager] Found 2 daughterboard(s).
[INFO] [MPM.RPCServer] RPC server ready!
[INFO] [MPM.RPCServer] Spawning watchdog task...
[INFO] [MPM.PeriphManager] init() called with device args `mgmt_addr=192.168.1.151,product=n310,master_clock_rate=125e6'.
[INFO] [0/DmaFIFO_0] Initializing block control (NOC ID: 0xF1F0D00000000004)
[INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1336 MB/s)
[INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1338 MB/s)
[INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1346 MB/s)
[INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1350 MB/s)
[INFO] [0/Radio_0] Initializing block control (NOC ID: 0x12AD100000000310)
[INFO] [0/Radio_1] Initializing block control (NOC ID: 0x12AD100000000310)
[INFO] [0/Radio_2] Initializing block control (NOC ID: 0x12AD100000000310)
[INFO] [0/Radio_3] Initializing block control (NOC ID: 0x12AD100000000310)
[INFO] [0/DDC_0] Initializing block control (NOC ID: 0xDDC0000000000001)
[INFO] [0/DDC_1] Initializing block control (NOC ID: 0xDDC0000000000001)
[INFO] [0/DDC_2] Initializing block control (NOC ID: 0xDDC0000000000001)
[INFO] [0/DDC_3] Initializing block control (NOC ID: 0xDDC0000000000001)
[INFO] [0/DUC_0] Initializing block control (NOC ID: 0xD0C0000000000000)
[INFO] [0/DUC_1] Initializing block control (NOC ID: 0xD0C0000000000000)
[INFO] [0/DUC_2] Initializing block control (NOC ID: 0xD0C0000000000000)
[INFO] [0/DUC_3] Initializing block control (NOC ID: 0xD0C0000000000000)
Using Device: Single USRP:
Device: N300-Series Device
Mboard 0: ni-n3xx-313ABDA
RX Channel: 0
RX DSP: 0
RX Dboard: A
RX Subdev: Magnesium
TX Channel: 0
TX DSP: 0
TX Dboard: A
TX Subdev: Magnesium
TX Channel: 1
TX DSP: 0
TX Dboard: B
TX Subdev: Magnesium
TX Channel: 2
TX DSP: 0
TX Dboard: C
TX Subdev: Magnesium
TX Channel: 3
TX DSP: 0
TX Dboard: D
TX Subdev: Magnesium

Setting RX Rate: 2.500000 Msps...
Actual RX Rate: 2.500000 Msps...

Setting RX Freq: 98.500000 MHz...
Actual RX Freq: 98.500000 MHz...

Setting RX Gain: 50.000000 dB...
Actual RX Gain: 50.000000 dB...

Checking RX: all_los: locked ...

Done!
</pre>

===Benchmarking your system===
Included with the UHD driver example programs is a utility, <code>benchmark_rate</code> to benchmark the transport link of the system.

A system's maximum performance is dependent upon many factors. <code>benchmark_rate</code> will exercise the transport link and CPU of the system.

====1 Gb Interface====
NOTE: This example requires the <code>HG</code> FPGA image to be loaded.

'''N300/N310'''

This example will test one full-duplex stream using "RF0/A:0", at a rate of 3.84 MS/s, for 60 seconds:

/usr/local/lib/uhd/examples/benchmark_rate \
--args "type=n3xx,mgmt_addr=192.168.1.151,addr=192.168.10.2,master_clock_rate=122.88e6" \
--duration 60 \
--channels "0" \
--rx_rate 3.84e6 \
--rx_subdev "A:0" \
--tx_rate 3.84e6 \
--tx_subdev "A:0"

'''N310'''

This example will test four full-duplex streams at 1.25 MS/s, for 60 seconds:

/usr/local/lib/uhd/examples/benchmark_rate \
--args "type=n3xx,mgmt_addr=192.168.1.151,addr=192.168.10.2,master_clock_rate=125e6" \
--duration 60 \
--channels "0,1,2,3" \
--rx_rate 1.25e6 \
--rx_subdev "A:0 A:1 B:0 B:1" \
--tx_rate 1.25e6 \
--tx_subdev "A:0 A:1 B:0 B:1"

'''N320/N321'''

This example will test one full-duplex stream using "RF0/A:0", at a rate of 3.84 MS/s, for 60 seconds:

/usr/local/lib/uhd/examples/benchmark_rate \
--args "type=n3xx,mgmt_addr=192.168.1.151,addr=192.168.10.2,master_clock_rate=245.76e6" \
--duration 60 \
--channels "0" \
--rx_rate 3.84e6 \
--rx_subdev "A:0" \
--tx_rate 3.84e6 \
--tx_subdev "A:0"

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.

====10 Gb Interface SFP 1====
NOTE: This example will work with either the <code>HG</code> or <code>XG</code> FPGA image.

'''N300/N310'''

This example will test one full-duplex stream using "RF0/A:0", at a rate of 31.25 MS/s, for 60 seconds:

/usr/local/lib/uhd/examples/benchmark_rate \
--args "type=n3xx,mgmt_addr=192.168.1.151,addr=192.168.20.2,master_clock_rate=125e6" \
--duration 60 \
--channels "0" \
--rx_rate 31.25e6 \
--rx_subdev "A:0" \
--tx_rate 31.25e6 \
--tx_subdev "A:0"

'''N320/N321'''

This example will test one full-duplex stream using "RF0/A:0", at a rate of 31.25 MS/s, for 60 seconds:

/usr/local/lib/uhd/examples/benchmark_rate \
--args "type=n3xx,mgmt_addr=192.168.1.151,addr=192.168.20.2,master_clock_rate=250e6" \
--duration 60 \
--channels "0" \
--rx_rate 31.25e6 \
--rx_subdev "A:0" \
--tx_rate 31.25e6 \
--tx_subdev "A:0"

'''N310'''

This example will test four full-duplex streams at 30.72 MS/s, for 60 seconds:

/usr/local/lib/uhd/examples/benchmark_rate \
--args "type=n3xx,mgmt_addr=192.168.1.151,addr=192.168.20.2,master_clock_rate=122.88e6" \
--duration 60 \
--channels "0,1,2,3" \
--rx_rate 30.72e6 \
--rx_subdev "A:0 A:1 B:0 B:1" \
--tx_rate 30.72e6 \
--tx_subdev "A:0 A:1 B:0 B:1"

'''N320/N321'''

This example will test two full-duplex streams at 30.72 MS/s, for 60 seconds:

/usr/local/lib/uhd/examples/benchmark_rate \
--args "type=n3xx,mgmt_addr=192.168.1.151,addr=192.168.20.2,master_clock_rate=245.76e6" \
--duration 60 \
--channels "0,1,2,3" \
--rx_rate 30.72e6 \
--rx_subdev "A:0 B:0" \
--tx_rate 30.72e6 \
--tx_subdev "A:0 B:0"

====Dual 10 Gb Interface====
NOTE: This example requires the <code>XG</code> FPGA image to be loaded.

'''N310'''

This example will test four full-duplex streams at 62.5 MS/s, for 60 seconds:

/usr/local/lib/uhd/examples/benchmark_rate \
--args "type=n3xx,mgmt_addr=192.168.1.151,addr=192.168.10.2,second_addr=192.168.20.2,master_clock_rate=125e6" \
--duration 60 \
--channels "0,1,2,3" \
--rx_rate 62.5e6 \
--rx_subdev "A:0 A:1 B:0 B:1" \
--tx_rate 62.5e6 \
--tx_subdev "A:0 A:1 B:0 B:1"

'''N320/N321'''

This example will test two full-duplex streams at 62.5 MS/s, for 60 seconds:

/usr/local/lib/uhd/examples/benchmark_rate \
--args "type=n3xx,mgmt_addr=192.168.1.151,addr=192.168.10.2,second_addr=192.168.20.2,master_clock_rate=250e6" \
--duration 60 \
--channels "0,1,2,3" \
--rx_rate 62.5e6 \
--rx_subdev "A:0 B:0" \
--tx_rate 62.5e6 \
--tx_subdev "A:0 B:0"

==USRP N3xx Device Specific Operations==

===White Rabbit Ethernet-Based Synchronization===
* [[Using Ethernet-Based Synchronization on the USRP™ N3xx Devices]]

===N320/N321===
* [[USRP N320/N321 LO Distribution]]
* [[5G NR EVM Measurements with the USRP N320/N321]]

===Turning the Device Off/On===
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:

shutdown -h now

===Enable Auto Booting===
Auto booting of the N3xx when power is applied can be configured by enabling the flag on the device's EEPROM with the following command:

eeprom-set-flags 0x1

===Default Password===
The default user is <code>root</code> and the password is empty (no password).

It is recommended to update the <code>root</code> password, which can be done with the command <code>passwd</code>:

Example Output:

root@ni-n3xx-serial:~# passwd
Changing password for root
New password:
Re-enter new password:
passwd: password changed.

[[Category:Getting Started Guides]]
[[Category:N300]]
[[Category:N310]]
[[Category:N320]]
[[Category:N321]]

Writing the USRP File System Disk Image to a SD Card

2026-07-30T04:11:32Z

JonathonPendlum: Add missing dd flags

==Application Note Number==
'''AN-630'''


==Abstract==
This application note will provide step-by-step instructions on writing a file system disk image to a SD card using Linux.

==Required Tools==
* Computer with USB2/3 Interface
* UHD Installation
* microSD card to USB Adapter

==Downloading the File System Image==
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.

===N3xx===

$ sudo uhd_images_downloader -t sdimg -t n3xx

Example Output for UHD 3.15.0.0:

$ sudo uhd_images_downloader -t sdimg -t n3xx
[INFO] Images destination: /usr/local/share/uhd/images
[INFO] No inventory file found at /usr/local/share/uhd/images/inventory.json. Creating an empty one.
845962 kB / 845962 kB (100%) n3xx_common_sdimg_default-v3.15.0.0.zip
[INFO] Images download complete.

===E31x===

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]

$ sudo uhd_images_downloader -t sdimg -t e310 -t sg1

or
$ sudo uhd_images_downloader -t sdimg -t e310 -t sg3

Example Output for UHD 3.15.0.0 for E310 SG3:

$ sudo uhd_images_downloader -t sdimg -t e310 -t sg3
[INFO] Images destination: /usr/local/share/uhd/images
[INFO] No inventory file found at /usr/local/share/uhd/images/inventory.json. Creating an empty one.
561236 kB / 561236 kB (100%) e3xx_e310_sg3_sdimg_default-v3.15.0.0.zip
[INFO] Images download complete.

===E320===

$ sudo uhd_images_downloader -t sdimg -t e320

Example Output for UHD 3.15.0.0:

$ sudo uhd_images_downloader -t sdimg -t e320
[INFO] Images destination: /usr/local/share/uhd/images
[INFO] No inventory file found at /usr/local/share/uhd/images/inventory.json. Creating an empty one.
795674 kB / 795674 kB (100%) e3xx_e320_sdimg_default-v3.15.0.0.zip
[INFO] Images download complete.

==Identifying UHD Installation Prefix==

In the output of the <code>uhd_images_downloader</code> command above, the folder destination where the images are saved is printed out.

An alternative method to identify your installation prefix is to run the command:

$ uhd_config_info --install-prefix

Example Output:

Install prefix: /usr/local

The default folder location for FPGA and SD card images is:

<UHD_INSTALL_PREFIX>/share/uhd/images/

==Writing the File System Image with Linux==

===Identifying SD Card Mount Location===

Insert the microSD card into the host computer.

To identify the device where the microSD card is, run the command:

dmesg | tail

Example Output (partially truncated for readability):

[21265.575488] usb-storage 1-2:1.0: USB Mass Storage device detected
[21266.586983] scsi 0:0:0:0: Direct-Access Generic Mass-Storage 1.11 PQ: 0 ANSI: 2
[21266.588024] sd 0:0:0:0: Attached scsi generic sg0 type 0
[21267.299812] sd 0:0:0:0: [sdb] 31116288 512-byte logical blocks: (15.9 Gb/14.8 GiB)
[21267.302687] sdb: sdb1 sdb2 sdb3 sdb4

NOTE: In this specific example configuration, the SD card has been attached to <code>sdb</code>.

Another method to finding the device node the disk is attached at is to use the Linux utility <code>lsblk</code>:

Example Output:

$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sdb 8:16 1 14.9G 0 disk
├─sdb1 8:17 1 16M 0 part /media/user/boot
├─sdb2 8:18 1 1.9G 0 part /media/user/primary
├─sdb3 8:19 1 1.9G 0 part /media/user/secondary
└─sdb4 8:20 1 11G 0 part /media/user/data

===Unmount Auto-mounted Partitions===

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:

$ sudo umount /media/user/data
$ sudo umount /media/user/primary
$ sudo umount /media/user/secondary
$ sudo umount /media/user/boot

Running the command <code>lsblk</code> again will show these partitions have been unmounted:

Example Output:

$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sdb 8:16 1 14.9G 0 disk
├─sdb1 8:17 1 16M 0 part
├─sdb2 8:18 1 1.9G 0 part
├─sdb3 8:19 1 1.9G 0 part
└─sdb4 8:20 1 11G 0 part

===Writing the SD Card Image===

====Using dd to write the disk image====

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

NOTE: You must use a 16 Gb or larger SD card for the N3xx and E320 file system images.

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

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:

'''N3xx'''
<IMAGE>=/usr/local/share/uhd/images/usrp_n3xx_fs.sdimg

'''E320'''
<IMAGE>=/usr/local/share/uhd/images/usrp_e320_fs.sdimg

Write the disk image with the command:

$ sudo dd if=<IMAGE> of=<SD_CARD_DEV_NAME> bs=1M status=progress oflag=direct conv=fsync

This step of writing the disk image to the SD card can take several minutes to complete.

Example Output:

$ sudo dd if=/usr/local/share/uhd/images/usrp_<deivce>_fs.sdimg of=/dev/sdb bs=1M status=progress oflag=direct conv=fsync
15160+0 records in
15160+0 records out
15896412160 bytes (16 Gb, 15 GiB) copied, 1160.93 s, 13.7 MB/s

You can now remove the microSD card from your host computer and insert it into the USRP.

[[Category:Application Notes]]

N200/N210 Getting Started Guides

2026-05-06T14:39:28Z

JonathonPendlum: Add EOL notice

==End-of-Life (EOL)==
<span style="color:#FF0000">'''Please note that this product is now End-of-Life (EOL) and is no longer available for sale through Ettus Research. It is not recommended for use in new designs or in new projects.'''</span>

==Kit Contents==
* USRP N200/N210
* 1 Gigabit Ethernet Cable
* Power Supply
* 2 SMA-Bulkhead Cables
{|
||[[File:Product n200.jpg|250px|center]]
||[[File:Product n210.jpg|250px|center]]
|}

==Verify the Contents of Your Kit==
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.

==You Will Need==
* A host computer with an available 1-GigE port

==Proper Care and Handling==
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:

*Never allow metal objects to touch the circuit board while powered.
*Always properly terminate the transmit port with an antenna or 50Ω load.
*Always handle the board with proper anti-static methods.
*Never allow the board to directly or indirectly come into contact with any voltage spikes.
*Never allow any water, or condensing moisture, to come into contact with the boards.
*Always use caution with FPGA, firmware, or software modifications.
{|
|style="padding-left:10px; padding-right:10px; padding-bottom:10px;" |[[File:Caution.png|24px|center]]
|style="padding-left:10px; padding-right:10px; padding-bottom:10px;" |Never apply more than -15 dBm of power into any RF input.
|-
|style="padding-left:10px; padding-right:10px; padding-bottom:10px;" |[[File:Caution.png|24px|center]]
|style="padding-left:10px; padding-right:10px; padding-bottom:10px;" |Always use at least 30dB attenuation if operating in loopback configuration
|-
|}

==Assembly==
The USRP N200/N210 and compatible RF daughterboards are shipped separately. To operate the device you will need to install the RF daughterboards and supplied bulkhead cables. This can be accomplished by removing the top plate of the USRP N200/N210, which is secured with two screws. After installation, the daughterboards and cables should be secured with the hardware provided. The device must be powered off when installing daughterboards to avoid potential damage. For detailed step-by-step instructions on assembling up your USRP N200/N210, see the [[USRP N Series Quick Start (Daughterboard Installation)]] page.

==Install and Setup the Software Tools on Your Host Computer==
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.

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.

==Test and Verify the Operation of the USRP==
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.

==Technical Support and Community Knowledge Base==
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.

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.

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

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

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

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

==Legal Considerations==
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.

*NOTE: This USRP product is a piece of test equipment.

==Sales and Ordering Support==
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.

==Terms and Conditions of Sale==
Terms and conditions of sale can be accessed online at the following link: http://www.ettus.com/legal/terms-and-conditions-of-sale

[[Category:Getting Started Guides]]

N200/N210

2026-05-06T14:37:22Z

JonathonPendlum: Add EOL notice

==End-of-Life (EOL)==
<span style="color:#FF0000">'''Please note that this product is now End-of-Life (EOL) and is no longer available for sale through Ettus Research. It is not recommended for use in new designs or in new projects.'''</span>

== Device Overview ==

The USRP Network Series offers high-bandwidth, high-dynamic range processing capability. The Gigabit Ethernet interface of the USRP Network Series allows high-speed streaming capability up to 50 MS/s in both directions (8-bit samples). These features, combined with plug-and-play MIMO capability make the USRP Network an ideal candidate for software defined radio systems with demanding performance requirements.

== Key Features==

===N200===

{|
|style="vertical-align:top"|
*50 MHz of RF bandwidth with 8 bit samples
*25 MHz of RF bandwidth with 16 bit samples
*Gigabit Ethernet connectivity
*MIMO capable - requires two or more USRP N200 devices as motherboard has one daughterboard slot (1 RX + 1 TX connectors)
*Onboard FPGA processing
*FPGA: Xilinx® Spartan® 3A-DSP XC3SD1800A
*ADCs: 14-bits 100 MS/s
*DACs: 16-bits 400 MS/s
*Ability to lock to external 5 or 10 MHz clock reference
*TCXO Frequency Reference (~2.5ppm)
*Optional internal GPS locked reference oscillator
*FPGA code can be changed with Xilinx® ISE® WebPACK™ tools
*Frequency range: DC - 6 GHz with suitable daughterboard
|[[File:Product n200.jpg|250px|center]]
|}

===N210===

{|
|style="vertical-align:top"|
*50 MHz of RF bandwidth with 8 bit samples
*25 MHz of RF bandwidth with 16 bit samples
*Gigabit Ethernet connectivity
*MIMO capable - requires two or more USRP N210 devices as motherboard has one daughterboard slot (1 RX + 1 TX connectors)
*Onboard FPGA processing
*FPGA: Xilinx® Spartan® 3A-DSP XC3SD3400A
*ADCs: 14-bits 100 MS/s
*DACs: 16-bits 400 MS/s
*Ability to lock to external 5 or 10 MHz clock reference
*TCXO Frequency Reference (~2.5ppm)
*Optional internal GPS locked reference oscillator
*FPGA code can only be changed with the paid version of the Xilinx® ISE® Design Suite tools
*Frequency range: DC - 6 GHz with suitable daughterboard
|[[File:Product n210.jpg|250px|center]]
|}

==Compatible Daughterboards==

* SBX-40
* UBX-40
* WBX-40
* CBX-40
* LFRX / LFTX
* BasicRX / BasicTX
* DBSRX2 (EOL)
* RFX Series (EOL)
* TVRX2 (EOL)

==RF Specifications==

===RF Performance Data (with WBX)===

* SSB/LO Suppression -35/50 dBc
* Phase Noise 1.8 GHz 10kHz -80 dBc/Hz
* Phase Noise 1.8 GHz 100kHz -100 dBc/Hz
* Phase Noise 1.8 GHz 1MHz -137 dBc/Hz
* Power Output 15 dBm
* IIP3 (@ typ NF) 0 dBm
* Typical Noise Figure 5 dB

==Hardware Specifications==

* Ettus Research recommends to always use the latest stable version of UHD

===N200===

* Current Hardware Revision: 4
* Minimum version of UHD required: 3.8.0

===N210===

* Current Hardware Revision: 4
* Minimum version of UHD required: 3.8.0

==Physical Specifications==

===Dimensions===

22 x 16 x 5 cm

===Weight===

1.2 kg

===Drawings===

* [[File:cu usrp-n2x0 motherboard.pdf]]
* [[File:cu ettus-usrp-n2x0.pdf]]

===CAD/STP Models===

====N2xx====

* [[Media:cu usrp-n2x0 motherboard.stp.gz| Motherboard]]

====N2xx Enclosure====

* [[Media:cu ettus-usrp-n2x0.stp.gz|Enclosure]]

==Environmental Specifications==

===Operating Temperature Range===

* N200/N210: 25 °C

===Operating Humidity Range===

* 10% to 90% non-condensing

==Schematics==

===N200/N210===

[http://files.ettus.com/schematics/n200/n2xx.pdf N200/N210 Schematics]

==Key Component Datasheets==

{| class="wikitable" style="width:80%"
!Part Number
!Description
!Schematic ID (Page)
|-
|[http://www.analog.com/media/en/technical-documentation/data-sheets/AD9777.pdf AD9777]
|Dual Channel, 16-Bit DAC
|U3 (1)
|-
|[http://www.ti.com/lit/ds/symlink/ads62p45.pdf ADS62P4X]
|Dual Channel, 14-Bit ADC
|U2 (1)
|-
|[http://www.xilinx.com/support/documentation/data_sheets/ds529.pdf XC3SD3400AFG676]
|FPGA
|U1 (2,8,9,10,11,12)
|-
|[http://www.analog.com/media/en/technical-documentation/data-sheets/AD9510.pdf AD9510]
|Clock Distribution IC
|U9 (4)
|-
|[http://download.siliconexpert.com/pdfs/2008/04/26/isys/lsi/ds06-161gphy_et1011c_09-28-2007.pdf ET1011C2]
|Gigabit Ethernet Transceiver
|U12 (6)
|-
|[http://www.cypress.com/file/43236/download CY7C1354C]
|Pipelined SRAM
|U19 (7)
|-
|[http://www.ti.com/lit/ds/symlink/max232.pdf MAX232]
|Drivers/Receiver
|U25 (10)
|-
|}

==FPGA==

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

===N200===

<pre>
Device utilization summary:
---------------------------

Selected Device : 3sd1800afg676-5

Number of Slices: 18356 out of 16640 110% (*)
Number of Slice Flip Flops: 20466 out of 33280 61%
Number of 4 input LUTs: 32968 out of 33280 99%
Number used as logic: 28511
Number used as Shift registers: 3945
Number used as RAMs: 512
Number of IOs: 338
Number of bonded IOBs: 331 out of 519 63%
IOB Flip Flops: 342
Number of BRAMs: 41 out of 84 48%
Number of GCLKs: 6 out of 24 25%
Number of DCMs: 1 out of 8 12%
Number of DSP48s: 31 out of 84 36%
</pre>

===N210===

<pre>
Device utilization summary:
---------------------------

Selected Device : 3sd3400afg676-5

Number of Slices: 18349 out of 23872 76%
Number of Slice Flip Flops: 20475 out of 47744 42%
Number of 4 input LUTs: 32986 out of 47744 69%
Number used as logic: 28529
Number used as Shift registers: 3945
Number used as RAMs: 512
Number of IOs: 338
Number of bonded IOBs: 331 out of 469 70%
IOB Flip Flops: 342
Number of BRAMs: 41 out of 126 32%
Number of GCLKs: 6 out of 24 25%
Number of DCMs: 1 out of 8 12%
Number of DSP48s: 31 out of 126 24%

</pre>

==Interfaces and Connectivity==

===N200/N210===

* Gigabit Ethernet

==Certifications==

===RoHS===

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]

===China RoHS===

'''Management Methods for Controlling Pollution Caused by Electronic Information Products Regulation'''

'''Chinese Customers'''

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

==Letter of Volatility==

Found on the [https://www.ni.com/en/support/documentation/product-certifications.html NI Product Certifications lookup tool] [https://www.ni.com/pdf/manuals/377355a.pdf here].

==Recovering the N200/N210==

For a detailed guide to recovering the N200/N210, please see the [[N200/N210 Device Recovery]] application note.

==Downloads==

[https://files.ettus.com/manual/md_fpga.html FPGA Resources]

[https://files.ettus.com/binaries/uhd_stable/ UHD Stable Binaries]

[https://github.com/EttusResearch/uhd UHD Source Code on Github]

[[Category:Hardware Resources]]

Synchronizing USRP Events Using Timed Commands in UHD

2025-12-27T07:29:29Z

JonathonPendlum: Make example clearer by showing that the set_rx_freq() call has a channel parameter

==Application Note Number==
'''AN-883'''


==Abstract==
This AN discusses Timed Commands in UHD. We will explore use cases, theory of operation, and multi_usrp based examples of timed command used in UHD 3.x.

==Timed Commands: Overview and Usecases==

Timed Commands are an important aspect of using a USRP. They allow a user to coordinate USRP state changes with nanosecond precision across multiple devices. Examples of timed command use cases include:

<ul>
<li> Configuring multiple channels of a single USRP to change frequency simultaneously.
<li> Configuring the channels on multiple USRPs to synchronously retune and ensure a predictable phase offset between channels ([https://kb.ettus.com/Synchronization_and_MIMO_Capability_with_USRP_Devices#MIMO_Capability_of_Ettus_Research_USRP_Devices if supported by daughterboard]).
<li> Changing the state of a USRP's GPIO line at an absolute time.
<li> Coordinating a simultaneous change of gain and frequency in a USRP.
<li> Scheduling frequency hopping at set time increments.
<li> Using RFNoC blocks like the Replay Block to transmit phase coherent bursts.
</ul>

===A System-Level Example===
A common use case of timed commands is to ensure a predictable and repeatable phase offset between the channels of multiple USRPs. Before we dive into the low level details of timed commands, lets take a high level look at where they are used in configuring a phase coherent MIMO system.

There are four key elements required for phase coherent operation of resync-capable USRPs:
<ol>
<li> All USRPs share a common reference clock (10MHz Ref)
<li> All USRPs share a common sense of time (PPS)
<li> LO and DSP tuning is synchronous
<li> Streaming is started synchronously
</ol>
LO sharing is implemented in some USRP products, but will not be covered in this example. Here is a physical configuration satisfying the requirements listed above:

[[File:Mimo Setup.png|1200px|center]]
<center>Figure 1 - Example system configuration with Host PC, Octoclock, and X310 radios</center>

Now that the system has all the physical connections necessary, we need to coordinate things in our host code. This will include importing the 10MHz Ref and PPS as well as ensuring synchronous tuning and streaming.

First, we need to create a <code>multi_usrp</code> object that contains both USRPs in our physical configuration:

uhd::usrp::multi_usrp::sptr usrp = uhd::usrp::multi_usrp::make("addr0=192.168.10.2,addr1=192.168.10.3");

Next, we'll let the USRPs know that they should expect a 10MHz clock on their "Ref In" port, and a PPS signal on their "PPS In" port:

usrp->set_clock_source("external");
usrp->set_time_source("external");

At this point, both USRPs are locked to an external reference and a common PPS signal. Next we want to tell both USRPs to reset their sense of time to 0.000s on the next PPS edge:

usrp->set_time_next_pps(uhd::time_spec_t(0.0));
std::this_thread::sleep_for(std::chrono::milliseconds(1000));

We won't cover it much in this application note, but for now understand <code>time_spec_t</code> is the UHD API's means of formatting time values for a USRP. After we reset the USRP's sense of time, we wait 1 second to ensure a PPS rising edge occurs and latches the 0.000s value to both USRPs. At this point, both USRPs should have a shared sense of time. We've now satisfied the first and second requirements for phase coherent USRP operation. Let's move on to synchronously tuning using timed commands:

usrp->clear_command_time();

usrp->set_command_time(usrp->get_time_now() + uhd::time_spec_t(0.1)); //set cmd time for .1s in the future

uhd::tune_request_t tune_request(freq);
usrp->set_rx_freq(tune_request, channel); // Call once per channel
std::this_thread::sleep_for(std::chrono::milliseconds(110)); //sleep 110ms (~10ms after retune occurs) to allow LO to lock

usrp->clear_command_time();

With the above code block, we are able to set a command time equal to the current time + 0.1s. Any commands that are called after <code>set_command_time()</code> will be sent to the USRP with a timestamp corresponding to the argument passed to <code>set_command_time()</code>. Because of this timestamp, the USRP will wait until the command time passes to execute the tune request. This will ensure that the LO and DSP chain of our USRPs are retuned synchronously (on the same clock cycle), satisfying the third requirement for phase coherent operation.

The final step in configuring our system is to set up synchronous streaming from both radios. For this example, we'll set up synchronous RX streaming using the following code:

// create a receive streamer
uhd::stream_args_t stream_args("fc32", wire); // complex floats
stream_args.channels = "0,1,2,3";
uhd::rx_streamer::sptr rx_stream = usrp->get_rx_stream(stream_args);

// setup streaming
uhd::stream_cmd_t stream_cmd(uhd::stream_cmd_t::STREAM_MODE_START_CONTINUOUS);
stream_cmd.stream_now = false;
stream_cmd.time_spec = uhd::time_spec_t(usrp->get_time_now() + uhd::time_spec_t(1.0));
rx_stream->issue_stream_cmd(stream_cmd);

Our system will begin to stream data 1s after the time returned by <code>usrp->get_time_now()</code>. Data sent to the host will be phase coherent between the 4 RX channels in this system. This architecture allows a system with X310 + UBX daughterboards to maintain a known phase relationship between channels across runs of code and system power cycles.

For more detail, see [https://files.ettus.com/manual/page_sync.html USRP Manual: Device Synchronization]

==Clocking and Timekeeping in the USRP==

In this section, we will cover several key topics relating to USRP synchronization and the use of timed commands in UHD. This is the low level detail section of this application note.

===PPS (Pulse Per Second)===

PPS is a signal used by USRPs for time synchronization. With a shared PPS, the sense of time can be aligned across several USRPs, allowing for the synchronization of timed command execution on an arbitrary number of radio channels. Within the context of a USRP, a PPS signal is expected to have the following properties:

*1Hz
*TTL Signal Levels
*25% duty cycle

A USRP's PPS can be derived from a GPSDO automatically, from an externally supplied PPS signal, or via internal PPS synthesis (not supported in legacy USRPs).

A PPS trigger is used to coordinate time alignment events across multiple devices. For example, the USRPs internal sense of time (the <code>vita_time</code> counter) can be synchronously set/reset across multiple USRPs via UHD API calls such as:

set_time_next_pps

set_time_unknown_pps

Ettus Research recommends the [https://www.ettus.com/all-products/octoclock/ Octoclock] for distribution of PPS and 10MHz REF signals across multiple devices, and the [https://www.ettus.com/all-products/octoclock-g/ Octoclock-G] for this functionality as well as tight alignment with GPS time. For further information on PPS and other common reference signals, see the [https://files.ettus.com/manual/page_sync.html UHD Manual: Device Synchronization].

===CHDR Packet Types and Structure===

CHDR (pronounced "Cheddar", like the cheese) or "Compressed Header" packets are the packet type used to pass data and commands between a host computer and USRP. CHDR is a derivative of the VITA 49 (VRT) protocol which is proprietary to USRP devices. See [https://files.ettus.com/manual/page_rtp.html UHD Manual: Radio Transport Protocols] for more information.

There are 4 types of packets used in the USRP:
*Data
*Flow Control
*Command
*Command Response

The type of CHDR packet is determined by the value of bits 63 and 62 in the CHDR header:

[[File:packet breakdown.png|1200px|center]]
<center>Figure 2 - Expanded view of CHDR packet composition</center>

All of these packet types have a single bit (61) used to denote whether an optional timestamp is included. If present, a timestamp is a 64-bit value representing an absolute time value. In this application note, we’re concerned with the use and functionality of command packets with a timestamp present, also known as “timed commands”.

===Command Queue===
As commands are passed from host to USRP, they are added to a FIFO on the USRP's FPGA. This FIFO is called the command queue and all commands that are sent to the USRP must pass through a command queue. Each block in the FPGA that handles data also has its own command queue. The command queue FIFO is not to be confused with the data FIFOs used to buffer data between blocks (pictured in Figure 3).

Every command queue maintains a sense of time. The mechanism for acquiring this sense of time is different between the Radio Core and other IP cores (including custom RFNoC blocks) and will be explored later in this application note. When commands enter the command queue, their timestamp is compared against the command queue's sense of time and the commands are executed when Queue Time >= Command Time. Commands without timestamps are executed immediately when they're at the front of the queue. Command queues in the USRP do not support on-the-fly reordering, meaning a command at the front of the queue will block subsequent commands from executing even if their timestamp has passed.

Every IP core on a USRP, including the Radio Core, DDC, DUC, and custom blocks, includes one command queue per data stream (certain blocks are designed to pass multiple data streams). The depth of this command queue varies from device to device is determined at FPGA compilation time based on user settings and available resources. An overflow of the command queue will result in a system halt and often requires a physical reset of the FPGA. Here are the default command queue depths for various USRP models:

{| class="wikitable" style="margin:auto;"
!USRP
!FPGA
!Default CMD Queue Depth (Radio Core)
!Default CMD Queue Depth (IP Cores)
|-

|X300
|Xilinx Kintex-7 XC7K325T
|8
|5
|-

|X310
|Xilinx Kintex-7 XC7K410T
|8
|5
|-

|E310/E312/E313
|Xilinx Zynq 7020 SoC
|8
|5
|-

|E320
|Xilinx Zynq 7045 SoC
|8
|5
|-

|N300
|Xilinx Zynq-7035 SoC
|8
|5
|-

|N310/N320/N321
|Xilinx Zynq-7100 SoC
|8
|5
|-

|B200/B200mini
|Xilinx Spartan 6 XC6SLX75
|8
|5
|-

|B210/B205mini/B206mini
|Xilinx Spartan 6 XC6SLX150
|8
|5
|-

|N200
|Xilinx Spartan 3A-DSP XC3SD1800A
|64
|64
|-

|N210
|Xilinx Spartan 3A-DSP XC3SD3400A
|64
|64
|-

|}
<center>Table 1 - Default command queue depth of various USRPs</center>

===Radio Core Block Timing===

The Radio Core is the heart of the USRP's functionality. The radio core is responsible for controlling all TX and RX daughterboard components (synthesizer, signal path, gain and attenuation elements, etc.), GPIO, setting up data streaming to/from DACs and ADCs, and related error handling.

[[File:rfnoc with ubx.png|1200px|center]]
<center>Figure 3 - RFNoC Architecture with UBX daughterboard</center>

In addition to the functionality listed above, the Radio Core is also responsible for maintaining the USRP's sense of absolute time. This absolute time value is stored as a 64-bit counter called the "VITA time" or <code>vita_time</code> in UHD. The <code>vita_time</code> counter is incremented off of the FPGA's base clock and local to the Radio Core USRP, meaning that other RFNoC blocks can not reference this counter value directly. This sense of absolute time is a subtle yet important difference between the Radio Core and other RFNoC blocks, which can also execute timed commands but do so based on the timestamps (and sample rate) of packets which pass through these blocks.

===General IP Core Timing===
The next case to cover is the handling of timed commands within FPGA blocks that are not the Radio Core. The Digital Down Converter (DDC) and Digital Up Converter (DUC) are two default USRP FPGA blocks that fall into this category. These blocks are responsible for performing digital frequency shifts on IQ samples that are passed through them. Precise execution of these frequency shifts are essential to phase coherent operation of the USRP.

IP Cores like the DDC and DUC are reliant on the timestamp of packets (and the sample rate of the radio) to derive a sense of time. In the case of the receive chain, samples that are digitized by an ADC are then packaged into a CHDR Packet by the Radio Core (with an included timestamp equal to <code>vita_time</code>) and are then passed downstream to the DDC. The DDC will read the timestamps of the incoming samples and apply any queued frequency shift precisely on the first sample with a timestamp >= the command time.

With this method, a USRP can begin receiving data at absolute time <code>t0</code>, tune it's LO at an absolute time of <code>t1</code>, and then apply a frequency shift in the DDC <u>at the point in data</u> corresponding to <code>t1</code>, resulting in a physical and digital frequency change that begin on the exact same sample.

The reverse process holds true for the transmit chain. One often overlooked difference is that the host must pass along at least 1 sample with a timestamp included in the metadata. Without this timestamped packet, the DUC can not derive a sense of time and therefore will never execute timed commands that are in its queue. This will either result in a command queue overflow or a "No Response Packet" runtime error from <code>ctrl_iface.cpp</code>.

===Miscellaneous Timed Command Notes===

====Types of timed commands====
* The majority timing operations amount a sequence of peeks and pokes to FPGA registers. Examples include gain changes, tune requests, etc. The timestamp of a timed command corresponds to the beginning of this peek/poke sequence.
* The timing of data transmission (TX) is a bit more involved, requiring queueing of samples, and arming of the device for a timed transmission. This is handled by the FPGA when a timestamp is present in the first TX sample's metadata.
* A timed receive operation (RX) requires that a stream command with a timestamp be issued to the radio (see <code>stream_cmd.time_spec</code> in the "System Level Example"). This syntax is different than a TX operation and does not involve sample metadata.

====Timed commands on AD93xx-based devices====
*Timed commands are supported on AD93xx-based USRPs (E3xx, B2xx, N300/N310), with a few caveats:
**Timed commands do not allow for phase resync of the AD93xx internal LO.
**All functions that directly interact with the AD93xx (tuning, gain change, etc) are subject to the scheduling of the AD93xx. The determinism of these operations are not guaranteed.
*Timed commands for TX and RX on AD936x devices are supported, with caveats:
**There will be a delay between an absolute time passing and the AD936x actually beginning a streaming operation. This delay has been observed to be consistent ''for streaming'', but other operations like gain setting require SPI readback from the RFIC and are non-deterministic.
**This is to say that a timed streaming command to begin TX and RX at the same time, on an AD936x-based device (which is in external loopback) should result in a consistent delay between TX and RX down to the sample. Other RFIC operations like changing gain or tuning LO frequency will not have this consistency.

====Are timed commands blocking?====
*No. Timed commands are passed from host to USRP and are added to a queue while host code progresses.

===Summary===
Modern USRPs pass packets using the CHDR protocol. These packets can be used to issue commands to the USRP and may have an associated timestamp. A command with an included timestamp is called a timed command and it's important to understand how the USRP handles these timed commands. All blocks in a USRP's FPGA have a command queue and maintain a sense of time, however the Radio Core has the unique ability to store an absolute sense of time known as as the <code>vita_time</code>. When timed commands are issued to the USRP, they are added to a command FIFO of finite depth and are executed when the timestamp in the header of the command packet is >= the RFNoC block's sense of time. Utilizing these timed commands correctly allows for various USRP functionality to be executed with nanosecond precision, enabling time and phase coherent operation across multiple devices.

==UHD API for Event Timing==

===Overview of Relevant Methods===

In this section, we will list and briefly describe commands that are commonly used in USRP event timing. Some less common methods which require a more detailed explanation can be found in [https://files.ettus.com/manual/classuhd_1_1usrp_1_1multi__usrp.html The multi_usrp Class Reference].

====Get USRP Time====

Get the current time in the USRP time registers:

get_time_now()

Get the time when the last pps pulse occurred:

get_time_last_pps()

Get the currently set time source:

get_time_source()

====Set USRP Time====

Sets the time registers on the USRP immediately:

set_time_now()

Set the time registers on the usrp at the next pps tick:

set_time_next_pps()

Set the time source for the USRP device:

set_time_source()

====Timed Commands====

Clear the command time so future commands are sent ASAP.

clear_command_time()

Set the time at which the control commands will take effect.

set_command_time()

====USRP TX Metadata ([https://files.ettus.com/manual/structuhd_1_1tx__metadata__t.html tx_metadata_t Struct Reference])====

Default TX metadata constructor:

tx_metadata_t()

Indicates whether a TX packet has a timestamp included:

md.has_time_spec

Sets the timestamp that will be added to a TX packet

md.time_spec

====USRP Stream Cmd ([https://files.ettus.com/manual/structuhd_1_1rx__metadata__t.html rx_metadata_t Struct Reference])====

Default stream command constructor:

stream_cmd_t()

Member function indicating whether the stream will begin immediately:

stream_cmd.stream_now

Indicates the point in time for an RX stream to begin:

stream_cmd.time_spec

Issue a stream command to the USRP:

issue_stream_cmd(stream_cmd)

==Example: Using Timed Commands to Control GPIO==

The following code uses timed commands to vary a USRP's bottom 4 GPIO lines between high and low. This can be copy-pasted into existing USRP examples:

<pre>
/********************************************/
/*********** begin gpio operations **********/
/********************************************/

// set up some catch-all masks
uint32_t gpio_line = 0xF; // only the bottom 4 lines: 0xF = 00001111 = Pin 0, 1, 2, 3
uint32_t all_one = 0xFF;
uint32_t all_zero = 0x00;

// reset usrp time to 0.00
usrp->set_time_source("internal");
usrp->set_time_next_pps(uhd::time_spec_t(0.0));
std::this_thread::sleep_for(std::chrono::milliseconds(2000));

uhd::time_spec_t now_time = usrp->get_time_last_pps(); // define t=0

// set gpio pins up for output
usrp->set_gpio_attr("FP0", "DDR", all_one, gpio_line, 0);
usrp->set_gpio_attr("FP0", "CTRL", all_zero, gpio_line, 0);
usrp->set_gpio_attr("FP0", "OUT", all_one, gpio_line, 0); // reset HIGH (async)

// set all gpio lines to output 0
usrp->clear_command_time();
usrp->set_command_time(now_time + uhd::time_spec_t(2.0));
usrp->set_gpio_attr("FP0", "OUT", all_zero, gpio_line, 0); // set LOW @ t=2

// set all gpio lines to output 1
usrp->clear_command_time();
usrp->set_command_time(now_time + uhd::time_spec_t(4.0));
usrp->set_gpio_attr("FP0", "OUT", all_one, gpio_line, 0); // set HIGH @ t=4

// set all gpio lines to output 0
usrp->clear_command_time();
usrp->set_command_time(now_time + uhd::time_spec_t(6.0));
usrp->set_gpio_attr("FP0", "OUT", all_zero, gpio_line, 0); // set LOW @ t=6

usrp->clear_command_time();

/********************************************/
/*********** quit gpio operations ***********/
/********************************************/
</pre>

A low-cost logic analyzer can be used to monitor the GPIO line states:

[[File:gpio example.png|1000px|center]]
<center>Figure 4 - Logic analyzer readout from timed GPIO example</center>

[[Category:Application Notes]]

RFNoC Frequently Asked Questions

2025-10-09T13:53:02Z

JonathonPendlum: Add FAQ for Vivado build error when using custom SystemVerilog packages

== Configuring the Stream Endpoint Buffer Size in RFNoC ==

=== What is the SEP buffer size? ===

Each stream endpoint (SEP) has an ingress buffer to store data received from others stream endpoints. This size of this buffer affects the data transfer rate that can be achieved when streaming to that endpoint. A larger ingress buffer in the stream endpoint means that there is more space to put data, minimizing idle time on the network. Additionally, streamers can queue up data before it is needed, reducing the chance of a buffer underflow.

=== How do I set the SEP buffer size? ===

The stream endpoint buffer size is set by adding a parameter under the endpoint you want to configure in the RFNoC image core YAML file. There are two parameters you can use to set the stream endpoint ingress buffer size in your RFNoC image core YAML file.

* <code>buff_size</code>: Buffer size in CHDR words. The size in bytes depends on the CHDR width. For example, if the <code>chdr_width</code> parameter for the device is 64, then each CHDR word is 8 bytes. So a buff size of 32768 would be 262,144 bytes or 256 KiB. See [https://github.com/EttusResearch/uhd/blob/197cdc4f665cbd4e6394a7eeb44b405f67ab10b1/fpga/usrp3/top/x300/x310_rfnoc_image_core.yml#L20 here] for an example.
* <code>buff_size_bytes</code>: Buffer size in bytes. See [https://github.com/EttusResearch/uhd/blob/197cdc4f665cbd4e6394a7eeb44b405f67ab10b1/fpga/usrp3/top/x400/x410_200_rfnoc_image_core.yml#L21 here] for an example.

=== To what value should I set the SEP buffer size? ===

The buffer size should be a power of two in size to make optimal use of FPGA RAM resources. The default FPGA bitstreams typically set them to the largest size the FPGA can fit in order to maximize performance. Here are some general recommendations:

* Set to <code>0</code> if you don't need to send data to that SEP.
* Set to <code>8192</code> bytes (8 KiB = 1 MTU) minimum in order to stream data packets.
* Set to <code>32768</code> bytes (32 KiB = 4 MTU) in order to stream at maximum rates between SEPs on the same FPGA.
* Set to <code>262144</code> bytes (256 KiB = 32 MTU) or lager for high performance streaming between a host computer and the FPGA.

Note that the requirements are application-dependent, so optimal sizes for your application may be different. MTU refers to the maximum transmission unit, which is the largest CHDR packet supported by the FPGA.

If you need to free up FPGA resources (particularly block RAM) for your application, you can reduce the SEP buffer sizes. Just keep in mind that the maximum streaming rate may be affected.

== USRP DRAM ==

=== How much and what speed DRAM is available on each USRP? ===

The table below summarizes the DRAM that is connected to the USRP for use by RFNoC.

{| class="wikitable"
|+ USRP DRAM Summary
|-
! USRP Model !! DRAM Size !! Default DRAM Speed !! Default User Interface
|-
| E31x || 512 MiB || 16-bit @ 800 MT/s (1.6 GB/s) || 2 ch x 64-bit @ 100 MHz
|-
| E320 || 2 GiB || 32-bit @ 1333 MT/s (5.33 GB/s) || 4 ch x 64-bit @ 300 MHz
|-
| N3xx || 2 GiB || 32-bit @ 1300 MT/s (5.2 GB/s) || 4 ch x 64-bit @ 303.819 MHz
|-
| X3xx || 1 GiB || 32-bit @ 1200 MT/s (4.8 GB/s) || 2 ch x 64-bit @ 300 MHz
|-
| X410 (100 and 200 MHz BW) || 4 GiB || 64-bit @ 2.0 GT/s (16.0 GB/s) || 4 x 64-bit @ 250 MHz
|-
| X410 (400 MHz BW) || 4 GiB per bank<br>(8 GiB total) || 64-bit @ 2.0 GT/s (16.0 GB/s) per bank<br>(32.0 GB/s total) || 4 x 128-bit @ 250 MHz (using 2 banks)
|-
| X440 (400 MHz BW) || 4 GiB per bank<br>(8 GiB total) || 64-bit @ 2.4 GT/s (19.2 GB/s) per bank<br>(38.4 GB/s total) || 8 x 128-bit @ 300 MHz (using 2 banks)
|-
| X440 (1600 MHz BW) || 4 GiB per bank<br>(8 GiB total) || 64-bit @ 2.4 GT/s (19.2 GB/s) per bank<br>(38.4 GB/s total) || 2 x 512-bit @ 300 MHz (using 2 banks)
|}

=== What DRAM data rates can I expect on each USRP? ===

DRAM performance is highly application-specific. For example, reading vs. reading and writing simultaneously, one data stream vs. multiple data streams, random access vs. sequential access, etc., can give dramatically different performance. Below are some measurements taken on different USRPs where a Null-Source-Sink RFNoC block is directly connected to a DMA FIFO block to test maximum streaming rates through the DRAM. The DRAM is shared between channels, so throughput goes down as the number of channels going through the DRAM is increased.

{| class="wikitable"
|+ Example DRAM Throughput (Per Channel)
|-
! USRP Model !! BIST (MB/s) !! 1 Ch (MS/s) !! 2 Ch (MS/s) !! 3 Ch (MS/s) !! 4 Ch (MS/s)
|-
| E31x || 666 || 166 || 91 || N/A || N/A
|-
| E320 || 1361 || 340 || 299 || 191 || 148
|-
| N3xx || 1368 || 341 || 295 || 191 || 144
|-
| X3xx || 1347 || 336 || 274 || N/A || N/A
|-
| X410 (100 and 200 MHz BW) || 1288 || 321|| 316|| 314 || 303
|-
| X410 (400 MHz BW) || 2801 || 697 || 672 || 672 || 672
|-
| X440 (400 MHz BW) || 3360 || 798 || 784 || 616 || 461
|-
| X440 (1600 MHz BW) || 8118 || 2007 || 2007 || N/A || N/A
|}
Notes:
# E31x, N3xx, and X410 were tested using UHD 4.2. E320 and X3xx were tested using UHD 4.3.
# BIST refers to the built-in self test, which gives a measure of raw data throughput for a single channel.
# For MS/s, we assume 4 bytes per sample (sc16).
# X410 with 400 MHz bandwidth uses two independent memory banks, with channels 0-1 on Bank 0, and channels 2-3 on Bank 1 by default. The traffic flows on Bank 0 and Bank 1 are independent and do not affect each other. Therefore, a 4-channel configuration has the same performance as a 2-channel configuration.
# X440 uses two independent memory banks. For 400 MHz, channels 0-3 are on Bank 0 and channels 4-7 are on Bank 1 by default. For 1600 MHz, channel 0 is on Bank 0 and channel 1 is on bank 1 by default. The traffic flows on Bank 0 and Bank 1 are independent and do not affect each other. Therefore, a 2-channel configuration has the same performance as a 1-channel configuration.

=== What can the DRAM be used for? ===

* '''DMA FIFO Block:''' The DMA FIFO block is used in situations where you need a large buffer to store samples.

* '''Replay Block:''' The Replay block is used to record and play back RF data. For example, you can record data from a host computer, then play it back over the radio. Or, record data from the radio, then play it back later to the host for analysis, or play it back to a radio at a specific timestamp. See [[Using the RFNoC Replay Block in UHD 4]] for additional information. The Replay block also has a FIFO capability for situations in which the DMA FIFO block is not available in your FPGA image.

* '''Custom Blocks:''' You can also create your own RFNoC block that uses DRAM. Refer to the DMA FIFO and/or Replay blocks as examples.

=== How do I add the Replay/DMA FIFO block to my FPGA image? ===

If the block you want is not included by default in the FPGA image you are using, you can add it to the RFNoC image core YAML file and rebuild the FPGA image using Vivado. See [[Getting Started with RFNoC in UHD 4.0]] for additional information on customizing an RFNoC image.

'''Note:''' DRAM is not enabled by default on E31x FPGA builds because the FPGA is not large enough to fit the default image with DRAM. You will need to remove components from your RFNoC image's YAML file to make room, then build the E31x image with the variable DRAM=1 set, or modify the E31x Makefile to enable DRAM by default.

'''Note:''' The default DRAM configuration used for X410 and X440 changes depending on the configured bandwidth. The default parameters to use for each image type is shown in the table below.

When adding the blocks to your RFNoC image core YAML file, the parameters must be set correctly for the type of USRP you intend to use. The memory data width (<code>MEM_DATA_W</code>) and address width (<code>MEM_ADDR_W</code>) must match exactly. The number of ports (<code>NUM_PORTS</code>) must not exceed the maximum number available. You can use fewer ports to save resources if you don't need all the DRAM ports.

{| class="wikitable"
|+ RFNoC Block Memory Parameters
|-
! USRP Model !! MEM_DATA_W !! MEM_ADDR_W !! NUM_PORTS (Max)
|-
| E31x || 64 || 29 || 2
|-
| E320 || 64 || 31 || 4
|-
| N3xx || 64 || 31 || 4
|-
| X3xx || 64 || 30 || 2
|-
| X410 (100 and 200 MHz BW) || 64 || 32 || 4
|-
| X410 (400 MHz BW) || 128 || 32 || 4
|-
| X440 (400 MHz BW) || 128 || 32 || 8
|-
| X440 (1600 MHz BW) || 512 || 32 || 2
|}

The DMA FIFO has a few additional parameters that should be provided. The clock rate (<code>MEM_CLK_RATE</code>) must match the value below for the built-in self test (BIST) to work correctly. The base address (<code>FIFO_ADDR_BASE</code>) and address mask (<code>FIFO_ADDR_MASK</code>) are written as Verilog constants and can be changed depending on your application. The <code>FIFO_ADDR_BASE</code> parameter contains the byte address for the first byte of the memory region to use for each port. The <code>FIFO_ADDR_MASK</code> parameter contains the address mask for each port, which tells the FIFO how much memory to use for each port. For example, an address mask of <code>30'h1FFFFFFF</code> means that 0x1FFFFFFF+1 bytes (i.e., 0x20000000 bytes or 512 MiB) will be used by the corresponding port. The address mask must be 1 less than a power of 2.

The example values in the table below use the entire memory and divide it evenly between all available ports.

{| class="wikitable"
|+ DMA FIFO Parameters
|-
! USRP Model !! MEM_CLK_RATE !! FIFO_ADDR_BASE !! FIFO_ADDR_MASK
|-
| E31x || "200e6" || "{29'h10000000, 29'h00000000}" || "{29'h0FFFFFFF, 29'h0FFFFFFF}"
|-
| E320 || "300e6" || "{31'h60000000, 31'h40000000, 31'h20000000, 31'h00000000}" || "{31'h1FFFFFFF, 31'h1FFFFFFF, 31'h1FFFFFFF, 31'h1FFFFFFF}"
|-
| N3xx || "303819444" || "{31'h60000000, 31'h40000000, 31'h20000000, 31'h00000000}" || "{31'h1FFFFFFF, 31'h1FFFFFFF, 31'h1FFFFFFF, 31'h1FFFFFFF}"
|-
| X3xx || "300e6" || "{30'h20000000, 30'h00000000}" || "{30'h1FFFFFFF, 30'h1FFFFFFF}"
|-
| X410 (100 and 200 MHz BW) || "250e6" || "{32'hC0000000, 32'h80000000, 32'h40000000, 32'h00000000}" || "{32'h3FFFFFFF, 32'h3FFFFFFF, 32'h3FFFFFFF, 32'h3FFFFFFF}"
|-
| X410 (400 MHz BW) || "250e6" || "{32'h80000000, 32'h00000000, 32'h80000000, 32'h00000000}" || "{32'h7FFFFFFF, 32'h7FFFFFFF, 32'h7FFFFFFF, 32'h7FFFFFFF}"
|-
| X440 (400 MHz BW) || "300e6" || "{32'hC0000000, 32'h80000000, 32'h40000000, 32'h00000000, 32'hC0000000, 32'h80000000, 32'h40000000, 32'h00000000}" || "{32'h3FFFFFFF, 32'h3FFFFFFF, 32'h3FFFFFFF, 32'h3FFFFFFF, 32'h3FFFFFFF, 32'h3FFFFFFF, 32'h3FFFFFFF, 32'h3FFFFFFF}"
|-
| X440 (1600 MHz BW) || "300e6" || "{32'h00000000, 32'h00000000}" || "{32'hFFFFFFFF, 32'hFFFFFFFF}"
|}

==== Replay Example ====

See [https://github.com/EttusResearch/uhd/blob/197cdc4f665cbd4e6394a7eeb44b405f67ab10b1/fpga/usrp3/top/x300/x310_rfnoc_image_core.yml#L69 x310_rfnoc_image_core.yml] for an example of how to instantiate the Replay block in the RFNoC image core YAML description. The following is a generic example that can be used for any USRP:
<nowiki>
noc_blocks:
# Instantiate the replay block
replay0:
block_desc: 'replay.yml'
parameters:
NUM_PORTS: <see table>
MEM_DATA_W: <see table>
MEM_ADDR_W: <see table>

connections:
# Connect each port of the replay block to a stream endpoint
- { srcblk: <epN>, srcport: out0, dstblk: replay0, dstport: in_0 }
- { srcblk: replay0, srcport: out_0, dstblk: <epN>, dstport: in0 }
- { srcblk: <epN+1>, srcport: out0, dstblk: replay0, dstport: in_1 }
- { srcblk: replay0, srcport: out_1, dstblk: <epN+1>, dstport: in0 }
... repeat for each remaining Replay port
# Connect the replay block memory interface to the USRP DRAM
- { srcblk: replay0, srcport: axi_ram, dstblk: _device_, dstport: dram }

Connect the DRAM clock to the block:
clk_domains:
# Connect the DRAM clock to the replay block
- { srcblk: _device_, srcport: dram, dstblk: replay0, dstport: mem }</nowiki>

==== DMA FIFO Example ====

See [https://github.com/EttusResearch/uhd/blob/197cdc4f665cbd4e6394a7eeb44b405f67ab10b1/fpga/usrp3/top/e320/e320_rfnoc_image_core.yml#L49 e320_rfnoc_image_core.yml] for an example of how to instantiate the DMA FIFO block in the RFNoC image core YAML description. The following is a generic example that can be used for any USRP:
<nowiki>
noc_blocks:
# Instantiate the DMA FIFO block
fifo0:
block_desc: 'axi_ram_fifo.yml'
parameters:
NUM_PORTS: <see table>
MEM_DATA_W: <see table>
MEM_ADDR_W: <see table>
FIFO_ADDR_BASE: <see table>
FIFO_ADDR_MASK: <see table>
MEM_CLK_RATE: <see table>

connections:
# Connect each port of the DMA FIFO block to a stream endpoint, or insert it
# into the data path where desired. This examples uses stream endpoints.
- { srcblk: <epN>, srcport: out0, dstblk: fifo0, dstport: in_0 }
- { srcblk: replay0, srcport: out_0, dstblk: <epN>, dstport: in0 }
- { srcblk: <epN+1>, srcport: out0, dstblk: fifo0, dstport: in_1 }
- { srcblk: fifo0, srcport: out_1, dstblk: <epN+1>, dstport: in0 }
... repeat for each remaining FIFO port
# Connect the DMA FIFO block memory interface to the USRP DRAM
- { srcblk: fifo0, srcport: axi_ram, dstblk: _device_, dstport: dram }

clk_domains:
# Connect the DRAM clock to the replay block
- { srcblk: _device_, srcport: dram, dstblk: fifo0, dstport: mem }</nowiki>

== RFNoC Clocks ==

=== What clocks are available for me to use? ===

Each device has different clocks available. See below for a list of clocks exposed to RFNoC. Although they have intended purposes, you can use any of these clocks for any purpose. The <code>rfnoc_chdr_clock</code> is a good default choice. This clock is always available in your block, even if it is not explicitly connected in the RFNoC image YAML description.

=== What are the clock frequencies? ===

See the table below for the clock rates. The radio clock rate depends on the master clock rate.

====E31x====
{| class="wikitable"
! Clock Name !! Description !! Frequency
|-
| <code>rfnoc_chdr</code> || RFNoC CHDR clock || 100 MHz
|-
| <code>rfnoc_ctrl</code> || RFNoC Control clock || 40 MHz
|-
| <code>dram</code> || DRAM interface clock || 100 MHz
|-
| <code>radio</code> || Radio interface clock || Same as master clock rate
|}

====E320====
{| class="wikitable"
! Clock Name !! Description !! Frequency
|-
| <code>rfnoc_chdr</code> || RFNoC CHDR clock || 200 MHz
|-
| <code>rfnoc_ctrl</code> || RFNoC Control clock || 40 MHz
|-
| <code>dram</code> || DRAM interface clock || 166.667 MHz
|-
| <code>radio</code> || Radio interface clock || Same as master clock rate (200 kHz to 61.44 MHz)
|}

====N300/N310====
{| class="wikitable"
! Clock Name !! Description !! Frequency
|-
| <code>rfnoc_chdr</code> || RFNoC CHDR clock || 200 MHz
|-
| <code>rfnoc_ctrl</code> || RFNoC Control clock || 40 MHz
|-
| <code>ce</code> || Compute Engine clock || 266.667 MHz (available in UHD 4.6 and later)
|-
| <code>dram</code> || DRAM interface clock || 303.819 MHz
|-
| <code>radio</code> || Radio interface clock || Same as master clock rate (122.88 MHz, 125.0 MHz, or 153.6 MHz)
|}

====N32x====
{| class="wikitable"
! Clock Name !! Description !! Frequency
|-
| <code>rfnoc_chdr</code> || RFNoC CHDR clock || 200 MHz
|-
| <code>rfnoc_ctrl</code> || RFNoC Control clock || 40 MHz
|-
| <code>ce</code> || Compute Engine clock || 266.667 MHz (available in UHD 4.6 and later)
|-
| <code>dram</code> || DRAM interface clock || 303.819 MHz
|-
| <code>radio</code> || Radio interface clock || Same as master clock rate (200 MHz, 245.76 MHz, or 250 MHz)
|}

====X3xx====
{| class="wikitable"
! Clock Name !! Description !! Frequency
|-
| <code>rfnoc_chdr</code> || RFNoC CHDR clock || 187.5 MHz
|-
| <code>rfnoc_ctrl</code> || RFNoC Control clock || 93.75 MHz
|-
| <code>ce</code> || Compute Engine clock || 214.286 MHz
|-
| <code>dram</code> || DRAM interface clock || 300 MHz
|-
| <code>radio</code> || Radio interface clock || Same as master clock rate (184.32 MHz or 200 MHz)
|}

====X410====
{| class="wikitable"
! Clock Name !! Description !! Frequency
|-
| <code>rfnoc_chdr</code> || RFNoC CHDR clock || 200 MHz
|-
| <code>rfnoc_ctrl</code> || RFNoC Control clock || 40 MHz
|-
| <code>ce</code> || Compute Engine clock || 266.667 MHz (available in UHD 4.6 and later)
|-
| <code>dram</code> || DRAM interface clock || 250 MHz
|-
| <code>radio</code> || Radio interface clock || 122.88 MHz when master clock rate is 122.88, 245.76, or 491.52 MHz<br>125 MHz when master clock rate is 125, 250, or 500 MHz
|-
| <code>radio_2x</code> || Radio interface clock 2x || Twice the frequency of <code>radio</code>
|}

====X440====
{| class="wikitable"
! Clock Name !! Description !! Frequency
|-
| <code>rfnoc_chdr</code> || RFNoC CHDR clock || 200 MHz
|-
| <code>rfnoc_ctrl</code> || RFNoC Control clock || 40 MHz
|-
| <code>ce</code> || Compute Engine clock || 266.667 MHz (available in UHD 4.6 and later)
|-
| <code>dram</code> || DRAM interface clock || 300 MHz
|-
| <code>radio0</code> || Radio interface clock for daughterboard 0 || Daughterboard 0 master clock rate divided by 8 (e.g., 62.5 MHz if master clock rate is 500 MHz)
|-
| <code>radio1</code> || Radio interface clock for daughterboard 1 || Daughterboard 1 master clock rate divided by 8
|-
| <code>radio0_2x</code> || Radio interface clock 2x for daughterboard 0 || Twice the frequency of <code>radio0</code>
|-
| <code>radio1_2x</code> || Radio interface clock 2x for daughterboard 1 || Twice the frequency of <code>radio1</code>
|}

=== How do I add a clock with a different frequency? ===

If you only need the clock within your own RFNoC block, you can modify the HDL for your block to generate the clock that you need from one of the available clocks. To do this, add a new clock to your block's YAML description, connect the available clock to your block in the YAML description of your RFNoC image, then add a Xilinx MMCM IP instance to your block's HDL and connect the available clock to its input.

Starting with UHD 4.7, you can add clock generation modules that create new clocks based on the existing clocks. Note that you must create such a module as an HDL module: Describing clocks in the YAML files will not cause them to be generated for you.

Assuming you have such a module, describe the clocks in the module's YAML files as such:

clocks:
- name: ce
direction: in
- name: my_clk
direction: out

Now you will have a new clock called <code>my_clk</code>, which is derived from the <code>ce</code> clock.

In older versions of UHD, adding custom clocks is not directly supported. If you can't use any of the available clocks, you can modify the HDL code to generate a clock.

If the clock is needed by multiple RFNoC blocks, or if you want to change an existing clock, you can modify the HDL for the USRP you are using to add or change a clock. If you add a new clock to the RFNoC image core, you must also update the BSP YAML file (located in [https://github.com/EttusResearch/uhd/tree/master/host/include/uhd/rfnoc/core <repo>/host/include/uhd/rfnoc/core]) so that the <code>rfnoc_image_builder</code> knows that the clock exists. How and where the clocks are generated varies between USRPs. Please refer to the source code for that USRP ([https://github.com/EttusResearch/uhd/tree/master/fpga/usrp3/top <repo>/fpga/usrp3/top]).

== Xilinx Vivado ==

=== Do I need a Vivado license to build FPGA images? ===

All RFNoC-capable USRPs use Xilinx FPGAs that require a license to use Vivado, except for E31x USRPs, which can use the free Vivado HL WebPACK Edition. Vivado is required to build FPGAs for RFNoC.

=== Which version and edition of Vivado should I install? ===

You should always use the Vivado version specified in the UHD documentation for your UHD release, including any required patches. See the [https://files.ettus.com/manual/md_usrp3_build_instructions.html UHD User Manual] for the latest Vivado version requirements.

The exact version string can be found in the <code>setupenv.sh</code> script for the FPGA target you intend to build (e.g., <code>fpga/usrp3/top/x400/setupenv.sh</code>).

=== Do I need to install all components of Vivado? ===

No. You only need to install device support for the FPGA you intend to build. Other devices can be unchecked to save disk space. The following FPGA types are used by USRPs:

* '''SoCs > Zynq-7000:''' E31x, E320, N3xx
* '''SOCs > Zynq UltraScale+ RFSoC:''' X410
* '''7 Series > Kintex-7''': X3xx

The Software Development Kit (SDK) is typically not required, but can be installed if desired.

The Cable Drivers are needed if you plan to do JTAG download or debug. Note that on Linux, the cable drivers are copied to the install folder, but are not installed onto your system automatically. See Xilinx UG973 for instructions on installing the cable drivers on Linux.

=== How do I get Vivado 2021.1 to work on Ubuntu 22.04 and later? ===

Vivado needs the <code>libncurses5</code> and <code>libtinfo5</code>, which are no longer included by default in recent Ubuntu installations. To install them, run the following commands:

sudo apt update
wget http://security.ubuntu.com/ubuntu/pool/universe/n/ncurses/libtinfo5_6.3-2ubuntu0.1_amd64.deb
sudo apt install ./libtinfo5_6.3-2ubuntu0.1_amd64.deb
wget http://security.ubuntu.com/ubuntu/pool/universe/n/ncurses/libncurses5_6.3-2ubuntu0.1_amd64.deb
sudo apt install ./libncurses5_6.3-2ubuntu0.1_amd64.deb

=== Can I use a different Vivado version? ===

While it is technically possible to use a different Vivado version, doing so comes with significant risks. Vivado versions are not fully compatible with each other, and changing the version usually leads to FPGA build failures. Furthermore, the shipping FPGA images for each UHD release are tested and validated using the specified Vivado version. Other versions are untested. For these reasons, the build process checks the Vivado version and will raise an error if you run <code>setupenv.sh</code> with an unsupported version installed.

Because alternative versions are untested, using a different Vivado version is strongly discouraged. If you choose to proceed anyway, you must:

* Update the Vivado version string in the setupenv.sh script for your FPGA target.
* Update all IP blocks to versions compatible with the new Vivado release, and modify any connections in the USRP code to match the updated IP interfaces. Failure to update the IP blocks will result in errors about the IP being locked. Incorrect or incomplete updates to IP connections may cause build failures or result in a non-functional FPGA image.
* Additional changes may be required depending on the Vivado version and the specific USRP target you are building. Unfortunately, it's not possible to predict these changes in advance.

== Building FPGA Images ==

=== Why did my FPGA build fail to meet timing constraints? ===

FPGAs have clocks that trigger the transfer of data between internal registers. The Vivado tool does a timing check near the end of the build to ensure that the paths from each driving register or port to each receiving register or port are not too long for the specified clock period or delay constraints. When it says "The design did not satisfy timing constraints" it means that Vivado couldn't arrange the logic on the chip in a way that meets all requirements. There are several reasons this might happen:

* You added new logic to the design with too much logic between registers. In this case, you should modify your design to make meeting timing easier.
* You added new logic, but made a mistake in which you're trying to use the wrong clock or reset, which makes it difficult to meet timing. In this case you need to correct the mistake in your design.
* The design has become too crowded, making it difficult for the tools to meet the timing requirements. In this case you need to remove something to make more room.
* Bad luck. The tools use pseudorandom algorithms to find solutions to really hard problems, and sometimes it doesn't find a good solution even when one is possible. In this case you can make a minor change to the design and build again to see if it does better the second time. If you don't change anything, Vivado will normally give you identical results for each build. In UHD 4.4 and later you can add the <code>BUILD_SEED=1</code> option to the <code>make</code> arguments to change a build seed that will affect the build results. Using a different seed number for each build will ensure that you get a unique build result each time. 0 is the default seed if not specified. Random build failures occur occasionally for some FPGA targets, in which case you should retry the build with a different seed.

The FPGA tools produce a timing report that says exactly which path failed to meet timing. Sometimes that can point you in the right direction. But sometimes the path indicated only failed because of another path that's even more difficult. Open <code>post_route_timing_summary.rpt</code> in the build output folder and search for "(VIOLATED)" to find the path(s) that failed.

=== My design doesn't fit in the FPGA. What can I do to reduce the size? ===

Read the <code>post_synth_util.rpt</code> to determine what resource(s) you are running out of in order to know what kinds of changes are needed. Below are several easy ways to reduce the resource utilization of the FPGA.

* If you are not using all RF channels of your device, modify the FPGA YAML file to remove the DDC, DUC, and Radio blocks for the unused channels, then regenerate the FPGA code using <code>rfnoc_image_builder</code>. Note that you may need at least one Radio block for RFNoC to work properly. You may also remove the DDC and/or the DUC if your application uses full bandwidth for one or more channels and therefore doesn't require up or down conversion.
* If you are not using DRAM, remove the Replay or DMA FIFO blocks. Also, on X4xx, change the <code>DRAM_CH</code> variable to 0 in the Makefile for the FPGA target you are building.
* If you do not need all SFP ports, use a build target that matches your needs. For example, on X4xx, the "X1" option (one 10 Gbps lane) uses the least resources whereas "X4" (four 10 Gbps lanes) uses a lot more, and the "CG" option (four 25 Gbps lanes) uses the most.
* If you do not need the full bandwidth of the device, use a smaller bandwidth option. For example, on X410, the "_100" option (100 MHz bandwidth) uses less resources than the "_200" option (200 MHz bandwidth).
* Add the <code>crossbar_routes</code> definition to the FPGA YAML file to include only the crossbar paths required for your application. This is an advanced feature in UHD 4.5 and later. This must be done carefully to avoid removing essential paths. See the X440 YAML files for examples.

Other reductions are possible but require advanced knowledge of UHD and/or RFNoC to avoid breaking key functionality of the device.

=== How do I create a Vivado project for my FPGA build? ===

Vivado supports two modes of operation known as "project mode" and "non-project mode". Project mode is more user-friendly because it creates a project file that is managed by Vivado and works natively in the Vivado GUI. Non-project mode is generally used by more advanced users who want full control over the Vivado build process and is typically used in fully scripted or automated build flows. The USRP build flow in UHD uses non-project mode. As a result, there is no Vivado project file by default.

It is possible to create a project file from the USRP build flow with the following steps:

# Start the USRP FPGA build in the GUI. In UHD 4.7 and later, this can be done by adding the <code>-g</code> argument to the <code>rfnoc_image_builder</code> command. In UHD 4.6 and earlier, this can be done by adding <code>GUI=1</code> to the <code>make</code> arguments. Example: <code>make X410_X4_200 GUI=1</code>
# After the build completes, run the following command in the TCL Console of Vivado to create the project file and switch to project mode:<br/><code>save_project_as project_name project_dir</code><br/>In this example, "project_name" is the name you want to give the project file and "project_dir" is the directory in which you want to put the project.
# Set the compile order to automatic: <br/><code>set_property source_mgmt_mode All [current_project]</code>

In some cases, it may also be necessary to reset the output products for some of the IP. If you get an error message about a BD sub-design being not generated for the synthesis target, then navigate to the "IP Sources" tab in the Project Manager Sources window, then right-click on affected IP and select "Reset Output Products...", then click "Reset".

This project file can now be used independently of the normal FPGA build flow in UHD. It is up to the user to update this project file as the design changes since it will not be managed by the normal build flow in UHD.

=== My FPGA takes a long time to build. What can I do to make builds faster? ===

High-performance computers are recommended for FPGA builds since an FPGA build can take several hours.

The build process is divided into two steps, IP generation and the FPGA build.

==== IP Generation ====

This process can take several hours by default and is run automatically, if needed, when you build an FPGA target. Fortunately, this only needs to be done once for each USRP type and won't run again unless IP is changed.

You can speed up the IP generation by running this step with multiple jobs. For example:

$ make -j 4 X410_IP

This example will build four IP cores at a time. Note that this generally requires 4 times as much memory and needs at least 4 CPU cores. You can adjust the number of parallel jobs based on the amount of system memory and/or CPU cores you have available.

==== FPGA Build ====

Unfortunately, increasing the number of jobs does not speed up FPGA performance because there is only one Vivado instance for the FPGA build. Vivado, by default, will use multiple CPU cores, where possible, but this does not significantly improve build performance since many parts of the build are not easily parallelizable.

One way to shorten the build time is to reduce the size of the design. See above on how to reduce the size of your design.

In the case where you need to build multiple FPGA types, you can use the jobs option with <code>make</code> to build multiple FPGAs simultaneously, which can dramatically reduce the time required per build. Note that this requires a significant amount of memory and CPU cores and therefore is only recommended for systems that can handle such loads. An example is shown below for building two FPGA images in parallel:

$ make -j 2 X410_X4_200 X410_CG_400

It is also possible to open separate terminal instances and run one build in each instance to get the same effect. Do not build the same FPGA target in multiple instances, since multiple builds for the same target would conflict as they try to access and update the same files.

=== When I start an FPGA build or use rfnoc_image_builder, I get an error "setupenv.sh: source: not found" and the build fails. What happened? ===

In some Linux distributions (e.g. Ubuntu) <code>dash</code> is set as default shell which can cause FPGA builds to fail.

Below is an example of the error. Note, that your message may look somewhat different depending on UHD version and USRP target but the important lines are marked in bold.

rfnoc_image_builder -y e320_rfnoc_image_core_fft.yml -t E320_1G
Using FPGA directory /home/someuser/uhd/fpga
Selected device: e320
Build artifacts directory already exists (contents will be overwritten).
Launching build with the following settings:
* FPGA Directory: /home/someuser/uhd/fpga/usrp3/top/e320
* Build Artifacts Directory: /home/someuser/uhd/fpga/usrp3/top/e320/build-usrp_e320_fpga_1G
* Build Output Directory: /home/someuser/uhd/fpga/usrp3/top/e320/build
* Build IP Directory: /home/someuser/uhd/fpga/usrp3/top/e320/build-ip
Executing the following command: . ./setupenv.sh && make E320_1G BUILD_DIR=/home/someuser/uhd/fpga/usrp3/top/e320/build-usrp_e320_fpga_1G IMAGE_CORE_NAME=usrp_e320_fpga_1G
'''/bin/sh: 6: ./setupenv.sh: Bad substitution'''
'''/bin/sh: 8: ./setupenv.sh: declare: not found'''
/bin/sh: 9: ./setupenv.sh: PRODUCT_ID_MAP[E320]=zynq/xc7z045/ffg900/-3: not found
'''/bin/sh: 15: ./setupenv.sh: source: not found'''
Build finished with return code 127.

It is recommended to set the default shell to <code>bash</code> by running the following command in the terminal. When asked <code>Use dash as the default system shell (/bin/sh)?</code> choose <code><No></code>.

$ sudo dpkg-reconfigure dash

Confirm your default shell was changed to bash by running this command:

$ ll /bin/sh

You should see output similar to this:

lrwxrwxrwx 1 root root 4 Oct 10 2020 /bin/sh -> bash*

=== My FPGA build failed with a cryptic message or no message at all. How do I debug this? ===

When you build an FPGA target, a build directory is created in the FPGA's top directory that contains all the build outputs. Here you'll find the <code>build.log</code> file as well as report files and checkpoints. Not all log information is printed to the console during build, so make sure you check the <code>build.log</code> file for details. It may contain a useful error message that was not printed to the console.

Builds often fail when Vivado encounters an internal error or runs out of memory. For internal errors, the error message is typically not very helpful and is often due to a bug in Vivado. When Vivado runs out of memory, it may immediately terminate without giving any error message at all. Consider monitoring the memory usage during the FPGA build to see if you are approaching your system's limit.

If you have made changes to the design, try building an unmodified FPGA image from scratch to ensure the build process is working properly on your system. If this works, try adding your changes incrementally until the section of code causing the problem is identified.

Note that such errors are often beyond the control of Ettus Research and reaching out to Xilinx support is a better option if it is truly a Vivado issue.

=== I get a warning saying that an IP is locked, which results in errors later in the IP generation process. How do I resolve this? ===

Vivado "locks" IP, for example, when it needs to be updated for the running version of Vivado or FPGA device type. This is intended to force the user to fix the issue and to avoid building incompatible IP. Build failures related to IP being locked should never occur during a normal build. The IP version in the UHD repo always matches the Vivado version required for that release of UHD.

This can happen if you have used the wrong version of Vivado or do not have the correct Vivado patches installed. Refer to the <code>Generation 3 USRP Build Documentation</code> section of the [[UHD and USRP User Manual|UHD Manual] for the required version and patches. When you run the `source setenv.sh` step to setup your environment, the script will check to make sure you are using the correct version.

In some cases, reinstalling Vivado might be required.

Once the correct Vivado version and patches are installed, you will need to remove all build products (to remove any locked IP that was generated) and retry the build. For example:

$ source setupenv.sh # Setup environment and check the Vivado version
$ make cleanall # Remove any bad IP that was generated
$ make X410_X4_200 # Start the build process again

=== I see a "CRITICAL WARNING" in the build log. Is this expected? ===

There are many critical warnings that appear during the build process that can be safely ignored. For example, you may see the following:

CRITICAL WARNING: [Vivado 12-1790] Evaluation License Warning: This design contains one or more IP cores that use separately licensed features. If the design has been configured to make use of evaluation features, please note that these features will cease to function after a certain period of time. Please consult the core datasheet to determine whether the core which you have configured will be affected. Evaluation features should NOT be used in production systems.

The FPGA builds include IP for which the licenses are included with Vivado, but Vivado prints the warnings anyway. As long as you have a Vivado license and a bitstream was successfully generated, the IP should work as expected.

=== Why does my build fail when I use a custom SystemVerilog package with in my RFNoC block? ===

One potential cause is due to the order of files in your block's Makefile.srcs. The SystemVerilog file with the package definition must be listed ''before'' any other module that imports the package. Otherwise, Vivado will fail with a "X is not declared" error during synthesis.

Knowledge Base

2025-10-09T13:48:32Z

JonathonPendlum: Add RFNoC FAQ link

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].
__NOTOC__
<div class="row">
<div class="col-1-3">
== [[Getting Started Guides|<i class="fa fa-road"></i> Getting Started Guides]] ==

'''Motherboards'''
* [[B200/B210/B200mini/B205mini/B206mini Getting Started Guides|B200/B210/B200mini/B205mini/B206mini]]
* [[Ettus USRP E300 Embedded Family Getting Started Guides|E310/E312/E313]]
* [[E320 Getting Started Guide|E320]]
* [[N200/N210 Getting Started Guides|N200/N210]]
* [[USRP N300/N310/N320/N321 Getting Started Guide|N300/N310/N320/N321]]
* [[X300/X310 Getting Started Guides|X300/X310]]
* [[USRP-2974 Getting Started Guide|USRP-2974]]
* [[USRP X410/X440 Getting Started Guide|X410/X440]]

'''Daughterboards'''
* [[OBX Getting Started Guides|OBX]]
* [[BasicTX/BasicRX Getting Started Guides|BasicTX/BasicRX]]
* [[CBX Getting Started Guides|CBX]]
* [[LFTX/LFRX Getting Started Guides|LFTX/LFRX]]
* [[SBX Getting Started Guides|SBX]]
* [[TwinRX Getting Started Guides|TwinRX]]
* [[UBX Getting Started Guides|UBX]]
* [[WBX Getting Started Guides|WBX]]

'''Other'''
* [[Getting_Started_with_RFNoC_in_UHD_4.0|RFNoC Development (UHD 4.x)]]
* [[RFNoC_4_Migration_Guide|RFNoC Migration Guide (UHD 3.x to UHD 4.x)]]
* [[Getting_Started_with_RFNoC_Development|RFNoC Development (UHD 3.x)]]
* [[Live SDR Environment Getting Started Guides|Live SDR Environment]]
* [[OctoClock CDA-2990 Getting Started Guides|OctoClock CDA-2990]]
* [[Using Ethernet-Based Synchronization on the USRP™ N3xx Devices|White Rabbit]]
* [[Getting Started with DPDK and UHD|DPDK]]

</div>
<div class="col-1-3">

== [[Hardware Resources|<i class="fa fa-cogs"></i> Hardware Resources]] ==
'''Motherboards'''
* [[B200/B210/B200mini/B205mini/B206mini]]
* [[Ettus USRP E300 Embedded Family Hardware Resources|E310/E312/E313]]
* [[E320|E320]]
* [[N200/N210]]
* [[N300/N310]]
* [[N320/N321]]
* [[X300/X310]]
* [[USRP-2974]]
* [[X410]]
* [[X440]]

'''Daughterboards'''
* [[OBX]]
* [[BasicTX/BasicRX]]
* [[CBX]]
* [[LFTX/LFRX]]
* [[SBX]]
* [[TwinRX]]
* [[UBX]]
* [[WBX]]

'''Other'''
* [[OctoClock CDA-2990]]
* [[GPSDO]]
* [[Antennas]]

</div>
<div class="col-1-3">

== [[Software Resources|<i class="fa fa-desktop"></i> Software Resources]] ==
'''Ettus Products'''
* [[UHD]]
* [[UHD Python API]]
* [[RFNoC|RFNoC (UHD 4.x)]]
* [[RFNoC (UHD 3.0)|RFNoC (UHD 3.x)]]

'''Third Party'''
* [[GNU Radio]]
* [[LabVIEW]]
* [[Matlab/Simulink]]
* [[OpenBTS]]
* [[Eurecom OpenAirInterface (OAI)]]
* [[srsLTE/srsUE]]
* [[Gqrx]]
* [[Fosphor]]

'''Reference Architectures'''
* [[Multichannel RF Reference Architecture]]
* [[OAI Reference Architecture for 5G and 6G Research with USRP]]

</div>
</div>

<div class="row">
<div class="col-1-3">

== [[UHD and USRP User Manual|<i class="fa fa-flag"></i> UHD and USRP User Manual]] ==

'''Software'''
* [https://files.ettus.com/manual/ UHD Manual (master)]
* [https://files.ettus.com/manual_archive/ UHD Manual Archive (previous releases)]

'''Motherboards'''
* [https://files.ettus.com/manual/page_usrp_b200.html B200/B210/B200mini/B205mini/B206mini]
* [https://files.ettus.com/manual/page_usrp_x3x0.html X300/X310]
* [https://files.ettus.com/manual/page_usrp2.html N200/N210]
* [https://files.ettus.com/manual/page_usrp_n3xx.html N300/N310/N320/N321]
* [https://files.ettus.com/manual/page_usrp_e3xx.html E310/E312/E313/E320]
* [https://files.ettus.com/manual/page_usrp_x4xx.html X410/X440]

'''Daughterboards'''
* [https://files.ettus.com/manual/page_dboards.html#dboards_basictx BasicRX/LFRX]
* [https://files.ettus.com/manual/page_dboards.html#dboards_basicrx BasicTX/LFTX]
* [https://files.ettus.com/manual/page_dboards.html#dboards_cbx CBX]
* [https://files.ettus.com/manual/page_dboards.html#dboards_sbx SBX]
* [https://files.ettus.com/manual/page_dboards.html#dboards_wbx WBX]
* [https://files.ettus.com/manual/page_dboards.html#dboards_ubx UBX]
* [https://files.ettus.com/manual/page_dboards.html#dboards_twinrx TwinRX]

'''Other'''
* [https://files.ettus.com/manual/page_octoclock.html OctoClock]

</div>
<div class="col-1-3">

== [[Application Notes|<i class="fa fa-file-text-o"></i> Application Notes]] ==
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.
</div>
<div class="col-1-3">

== [[Additional Resources|<i class="fa fa-book"></i> Additional Resources]] ==
* [[Workshop_Tutorial|Workshop/Tutorial]]
* [[Suggested Reading|Suggested Reading]]
* [[Suggested Videos|Suggested Videos]]
* [[CGRAN]]
* [[SDR Events]]
* [[GNU Radio Conference]]
* [[NEWSDR]]
* [[FOSDEM]]
* [[Cyberspectrum]]
</div>
</div>

<div class="row">
<div class="col-1-3">

== [[Technical Support|<i class="fa fa-life-ring"></i> Technical Support]] ==
* [[Email|Email]]
* [[Mailing Lists|Mailing Lists]]
* [[Matrix|GNU Radio Matrix Chat Server]]
* [[SDR_Boston_Slack|SDR Boston Slack Chat Server]]
* [[StackExchange|StackExchange]]
* [[NI_SRM|NI Service Request Manager (SRM)]]

</div>
<div class="col-1-3">

== [[Faq|<i class="fa fa-info-circle"></i> FAQ]] ==
* [[Technical FAQ|Technical]]
* [[Licensing FAQ|Licensing]]
* [[RFNoC_Frequently_Asked_Questions|RFNoC]]

</div>
<div class="col-1-3">

== [[Legacy Products| <i class="fa fa-hourglass-end"></i> Legacy Products]] ==
'''Motherboards'''
* [[USRP1|USRP1]]
* [[USRP2|USRP2]]
* [[E100/E110|E100/E110]]
* [[B100]]

'''Daughterboards'''
* [[DBSRX2]]
* [[TVRX2]]
* [[XCVR2450]]

RFNoC Frequently Asked Questions

2025-07-23T07:00:32Z

JonathonPendlum: Add how to install libraries required for Vivado 2021.1 installation on Ubuntu

== Configuring the Stream Endpoint Buffer Size in RFNoC ==

=== What is the SEP buffer size? ===

Each stream endpoint (SEP) has an ingress buffer to store data received from others stream endpoints. This size of this buffer affects the data transfer rate that can be achieved when streaming to that endpoint. A larger ingress buffer in the stream endpoint means that there is more space to put data, minimizing idle time on the network. Additionally, streamers can queue up data before it is needed, reducing the chance of a buffer underflow.

=== How do I set the SEP buffer size? ===

The stream endpoint buffer size is set by adding a parameter under the endpoint you want to configure in the RFNoC image core YAML file. There are two parameters you can use to set the stream endpoint ingress buffer size in your RFNoC image core YAML file.

* <code>buff_size</code>: Buffer size in CHDR words. The size in bytes depends on the CHDR width. For example, if the <code>chdr_width</code> parameter for the device is 64, then each CHDR word is 8 bytes. So a buff size of 32768 would be 262,144 bytes or 256 KiB. See [https://github.com/EttusResearch/uhd/blob/197cdc4f665cbd4e6394a7eeb44b405f67ab10b1/fpga/usrp3/top/x300/x310_rfnoc_image_core.yml#L20 here] for an example.
* <code>buff_size_bytes</code>: Buffer size in bytes. See [https://github.com/EttusResearch/uhd/blob/197cdc4f665cbd4e6394a7eeb44b405f67ab10b1/fpga/usrp3/top/x400/x410_200_rfnoc_image_core.yml#L21 here] for an example.

=== To what value should I set the SEP buffer size? ===

The buffer size should be a power of two in size to make optimal use of FPGA RAM resources. The default FPGA bitstreams typically set them to the largest size the FPGA can fit in order to maximize performance. Here are some general recommendations:

* Set to <code>0</code> if you don't need to send data to that SEP.
* Set to <code>8192</code> bytes (8 KiB = 1 MTU) minimum in order to stream data packets.
* Set to <code>32768</code> bytes (32 KiB = 4 MTU) in order to stream at maximum rates between SEPs on the same FPGA.
* Set to <code>262144</code> bytes (256 KiB = 32 MTU) or lager for high performance streaming between a host computer and the FPGA.

Note that the requirements are application-dependent, so optimal sizes for your application may be different. MTU refers to the maximum transmission unit, which is the largest CHDR packet supported by the FPGA.

If you need to free up FPGA resources (particularly block RAM) for your application, you can reduce the SEP buffer sizes. Just keep in mind that the maximum streaming rate may be affected.

== USRP DRAM ==

=== How much and what speed DRAM is available on each USRP? ===

The table below summarizes the DRAM that is connected to the USRP for use by RFNoC.

{| class="wikitable"
|+ USRP DRAM Summary
|-
! USRP Model !! DRAM Size !! Default DRAM Speed !! Default User Interface
|-
| E31x || 512 MiB || 16-bit @ 800 MT/s (1.6 GB/s) || 2 ch x 64-bit @ 100 MHz
|-
| E320 || 2 GiB || 32-bit @ 1333 MT/s (5.33 GB/s) || 4 ch x 64-bit @ 300 MHz
|-
| N3xx || 2 GiB || 32-bit @ 1300 MT/s (5.2 GB/s) || 4 ch x 64-bit @ 303.819 MHz
|-
| X3xx || 1 GiB || 32-bit @ 1200 MT/s (4.8 GB/s) || 2 ch x 64-bit @ 300 MHz
|-
| X410 (100 and 200 MHz BW) || 4 GiB || 64-bit @ 2.0 GT/s (16.0 GB/s) || 4 x 64-bit @ 250 MHz
|-
| X410 (400 MHz BW) || 4 GiB per bank<br>(8 GiB total) || 64-bit @ 2.0 GT/s (16.0 GB/s) per bank<br>(32.0 GB/s total) || 4 x 128-bit @ 250 MHz (using 2 banks)
|-
| X440 (400 MHz BW) || 4 GiB per bank<br>(8 GiB total) || 64-bit @ 2.4 GT/s (19.2 GB/s) per bank<br>(38.4 GB/s total) || 8 x 128-bit @ 300 MHz (using 2 banks)
|-
| X440 (1600 MHz BW) || 4 GiB per bank<br>(8 GiB total) || 64-bit @ 2.4 GT/s (19.2 GB/s) per bank<br>(38.4 GB/s total) || 2 x 512-bit @ 300 MHz (using 2 banks)
|}

=== What DRAM data rates can I expect on each USRP? ===

DRAM performance is highly application-specific. For example, reading vs. reading and writing simultaneously, one data stream vs. multiple data streams, random access vs. sequential access, etc., can give dramatically different performance. Below are some measurements taken on different USRPs where a Null-Source-Sink RFNoC block is directly connected to a DMA FIFO block to test maximum streaming rates through the DRAM. The DRAM is shared between channels, so throughput goes down as the number of channels going through the DRAM is increased.

{| class="wikitable"
|+ Example DRAM Throughput (Per Channel)
|-
! USRP Model !! BIST (MB/s) !! 1 Ch (MS/s) !! 2 Ch (MS/s) !! 3 Ch (MS/s) !! 4 Ch (MS/s)
|-
| E31x || 666 || 166 || 91 || N/A || N/A
|-
| E320 || 1361 || 340 || 299 || 191 || 148
|-
| N3xx || 1368 || 341 || 295 || 191 || 144
|-
| X3xx || 1347 || 336 || 274 || N/A || N/A
|-
| X410 (100 and 200 MHz BW) || 1288 || 321|| 316|| 314 || 303
|-
| X410 (400 MHz BW) || 2801 || 697 || 672 || 672 || 672
|-
| X440 (400 MHz BW) || 3360 || 798 || 784 || 616 || 461
|-
| X440 (1600 MHz BW) || 8118 || 2007 || 2007 || N/A || N/A
|}
Notes:
# E31x, N3xx, and X410 were tested using UHD 4.2. E320 and X3xx were tested using UHD 4.3.
# BIST refers to the built-in self test, which gives a measure of raw data throughput for a single channel.
# For MS/s, we assume 4 bytes per sample (sc16).
# X410 with 400 MHz bandwidth uses two independent memory banks, with channels 0-1 on Bank 0, and channels 2-3 on Bank 1 by default. The traffic flows on Bank 0 and Bank 1 are independent and do not affect each other. Therefore, a 4-channel configuration has the same performance as a 2-channel configuration.
# X440 uses two independent memory banks. For 400 MHz, channels 0-3 are on Bank 0 and channels 4-7 are on Bank 1 by default. For 1600 MHz, channel 0 is on Bank 0 and channel 1 is on bank 1 by default. The traffic flows on Bank 0 and Bank 1 are independent and do not affect each other. Therefore, a 2-channel configuration has the same performance as a 1-channel configuration.

=== What can the DRAM be used for? ===

* '''DMA FIFO Block:''' The DMA FIFO block is used in situations where you need a large buffer to store samples.

* '''Replay Block:''' The Replay block is used to record and play back RF data. For example, you can record data from a host computer, then play it back over the radio. Or, record data from the radio, then play it back later to the host for analysis, or play it back to a radio at a specific timestamp. See [[Using the RFNoC Replay Block in UHD 4]] for additional information. The Replay block also has a FIFO capability for situations in which the DMA FIFO block is not available in your FPGA image.

* '''Custom Blocks:''' You can also create your own RFNoC block that uses DRAM. Refer to the DMA FIFO and/or Replay blocks as examples.

=== How do I add the Replay/DMA FIFO block to my FPGA image? ===

If the block you want is not included by default in the FPGA image you are using, you can add it to the RFNoC image core YAML file and rebuild the FPGA image using Vivado. See [[Getting Started with RFNoC in UHD 4.0]] for additional information on customizing an RFNoC image.

'''Note:''' DRAM is not enabled by default on E31x FPGA builds because the FPGA is not large enough to fit the default image with DRAM. You will need to remove components from your RFNoC image's YAML file to make room, then build the E31x image with the variable DRAM=1 set, or modify the E31x Makefile to enable DRAM by default.

'''Note:''' The default DRAM configuration used for X410 and X440 changes depending on the configured bandwidth. The default parameters to use for each image type is shown in the table below.

When adding the blocks to your RFNoC image core YAML file, the parameters must be set correctly for the type of USRP you intend to use. The memory data width (<code>MEM_DATA_W</code>) and address width (<code>MEM_ADDR_W</code>) must match exactly. The number of ports (<code>NUM_PORTS</code>) must not exceed the maximum number available. You can use fewer ports to save resources if you don't need all the DRAM ports.

{| class="wikitable"
|+ RFNoC Block Memory Parameters
|-
! USRP Model !! MEM_DATA_W !! MEM_ADDR_W !! NUM_PORTS (Max)
|-
| E31x || 64 || 29 || 2
|-
| E320 || 64 || 31 || 4
|-
| N3xx || 64 || 31 || 4
|-
| X3xx || 64 || 30 || 2
|-
| X410 (100 and 200 MHz BW) || 64 || 32 || 4
|-
| X410 (400 MHz BW) || 128 || 32 || 4
|-
| X440 (400 MHz BW) || 128 || 32 || 8
|-
| X440 (1600 MHz BW) || 512 || 32 || 2
|}

The DMA FIFO has a few additional parameters that should be provided. The clock rate (<code>MEM_CLK_RATE</code>) must match the value below for the built-in self test (BIST) to work correctly. The base address (<code>FIFO_ADDR_BASE</code>) and address mask (<code>FIFO_ADDR_MASK</code>) are written as Verilog constants and can be changed depending on your application. The <code>FIFO_ADDR_BASE</code> parameter contains the byte address for the first byte of the memory region to use for each port. The <code>FIFO_ADDR_MASK</code> parameter contains the address mask for each port, which tells the FIFO how much memory to use for each port. For example, an address mask of <code>30'h1FFFFFFF</code> means that 0x1FFFFFFF+1 bytes (i.e., 0x20000000 bytes or 512 MiB) will be used by the corresponding port. The address mask must be 1 less than a power of 2.

The example values in the table below use the entire memory and divide it evenly between all available ports.

{| class="wikitable"
|+ DMA FIFO Parameters
|-
! USRP Model !! MEM_CLK_RATE !! FIFO_ADDR_BASE !! FIFO_ADDR_MASK
|-
| E31x || "200e6" || "{29'h10000000, 29'h00000000}" || "{29'h0FFFFFFF, 29'h0FFFFFFF}"
|-
| E320 || "300e6" || "{31'h60000000, 31'h40000000, 31'h20000000, 31'h00000000}" || "{31'h1FFFFFFF, 31'h1FFFFFFF, 31'h1FFFFFFF, 31'h1FFFFFFF}"
|-
| N3xx || "303819444" || "{31'h60000000, 31'h40000000, 31'h20000000, 31'h00000000}" || "{31'h1FFFFFFF, 31'h1FFFFFFF, 31'h1FFFFFFF, 31'h1FFFFFFF}"
|-
| X3xx || "300e6" || "{30'h20000000, 30'h00000000}" || "{30'h1FFFFFFF, 30'h1FFFFFFF}"
|-
| X410 (100 and 200 MHz BW) || "250e6" || "{32'hC0000000, 32'h80000000, 32'h40000000, 32'h00000000}" || "{32'h3FFFFFFF, 32'h3FFFFFFF, 32'h3FFFFFFF, 32'h3FFFFFFF}"
|-
| X410 (400 MHz BW) || "250e6" || "{32'h80000000, 32'h00000000, 32'h80000000, 32'h00000000}" || "{32'h7FFFFFFF, 32'h7FFFFFFF, 32'h7FFFFFFF, 32'h7FFFFFFF}"
|-
| X440 (400 MHz BW) || "300e6" || "{32'hC0000000, 32'h80000000, 32'h40000000, 32'h00000000, 32'hC0000000, 32'h80000000, 32'h40000000, 32'h00000000}" || "{32'h3FFFFFFF, 32'h3FFFFFFF, 32'h3FFFFFFF, 32'h3FFFFFFF, 32'h3FFFFFFF, 32'h3FFFFFFF, 32'h3FFFFFFF, 32'h3FFFFFFF}"
|-
| X440 (1600 MHz BW) || "300e6" || "{32'h00000000, 32'h00000000}" || "{32'hFFFFFFFF, 32'hFFFFFFFF}"
|}

==== Replay Example ====

See [https://github.com/EttusResearch/uhd/blob/197cdc4f665cbd4e6394a7eeb44b405f67ab10b1/fpga/usrp3/top/x300/x310_rfnoc_image_core.yml#L69 x310_rfnoc_image_core.yml] for an example of how to instantiate the Replay block in the RFNoC image core YAML description. The following is a generic example that can be used for any USRP:
<nowiki>
noc_blocks:
# Instantiate the replay block
replay0:
block_desc: 'replay.yml'
parameters:
NUM_PORTS: <see table>
MEM_DATA_W: <see table>
MEM_ADDR_W: <see table>

connections:
# Connect each port of the replay block to a stream endpoint
- { srcblk: <epN>, srcport: out0, dstblk: replay0, dstport: in_0 }
- { srcblk: replay0, srcport: out_0, dstblk: <epN>, dstport: in0 }
- { srcblk: <epN+1>, srcport: out0, dstblk: replay0, dstport: in_1 }
- { srcblk: replay0, srcport: out_1, dstblk: <epN+1>, dstport: in0 }
... repeat for each remaining Replay port
# Connect the replay block memory interface to the USRP DRAM
- { srcblk: replay0, srcport: axi_ram, dstblk: _device_, dstport: dram }

Connect the DRAM clock to the block:
clk_domains:
# Connect the DRAM clock to the replay block
- { srcblk: _device_, srcport: dram, dstblk: replay0, dstport: mem }</nowiki>

==== DMA FIFO Example ====

See [https://github.com/EttusResearch/uhd/blob/197cdc4f665cbd4e6394a7eeb44b405f67ab10b1/fpga/usrp3/top/e320/e320_rfnoc_image_core.yml#L49 e320_rfnoc_image_core.yml] for an example of how to instantiate the DMA FIFO block in the RFNoC image core YAML description. The following is a generic example that can be used for any USRP:
<nowiki>
noc_blocks:
# Instantiate the DMA FIFO block
fifo0:
block_desc: 'axi_ram_fifo.yml'
parameters:
NUM_PORTS: <see table>
MEM_DATA_W: <see table>
MEM_ADDR_W: <see table>
FIFO_ADDR_BASE: <see table>
FIFO_ADDR_MASK: <see table>
MEM_CLK_RATE: <see table>

connections:
# Connect each port of the DMA FIFO block to a stream endpoint, or insert it
# into the data path where desired. This examples uses stream endpoints.
- { srcblk: <epN>, srcport: out0, dstblk: fifo0, dstport: in_0 }
- { srcblk: replay0, srcport: out_0, dstblk: <epN>, dstport: in0 }
- { srcblk: <epN+1>, srcport: out0, dstblk: fifo0, dstport: in_1 }
- { srcblk: fifo0, srcport: out_1, dstblk: <epN+1>, dstport: in0 }
... repeat for each remaining FIFO port
# Connect the DMA FIFO block memory interface to the USRP DRAM
- { srcblk: fifo0, srcport: axi_ram, dstblk: _device_, dstport: dram }

clk_domains:
# Connect the DRAM clock to the replay block
- { srcblk: _device_, srcport: dram, dstblk: fifo0, dstport: mem }</nowiki>

== RFNoC Clocks ==

=== What clocks are available for me to use? ===

Each device has different clocks available. See below for a list of clocks exposed to RFNoC. Although they have intended purposes, you can use any of these clocks for any purpose. The <code>rfnoc_chdr_clock</code> is a good default choice. This clock is always available in your block, even if it is not explicitly connected in the RFNoC image YAML description.

=== What are the clock frequencies? ===

See the table below for the clock rates. The radio clock rate depends on the master clock rate.

====E31x====
{| class="wikitable"
! Clock Name !! Description !! Frequency
|-
| <code>rfnoc_chdr</code> || RFNoC CHDR clock || 100 MHz
|-
| <code>rfnoc_ctrl</code> || RFNoC Control clock || 40 MHz
|-
| <code>dram</code> || DRAM interface clock || 100 MHz
|-
| <code>radio</code> || Radio interface clock || Same as master clock rate
|}

====E320====
{| class="wikitable"
! Clock Name !! Description !! Frequency
|-
| <code>rfnoc_chdr</code> || RFNoC CHDR clock || 200 MHz
|-
| <code>rfnoc_ctrl</code> || RFNoC Control clock || 40 MHz
|-
| <code>dram</code> || DRAM interface clock || 166.667 MHz
|-
| <code>radio</code> || Radio interface clock || Same as master clock rate (200 kHz to 61.44 MHz)
|}

====N300/N310====
{| class="wikitable"
! Clock Name !! Description !! Frequency
|-
| <code>rfnoc_chdr</code> || RFNoC CHDR clock || 200 MHz
|-
| <code>rfnoc_ctrl</code> || RFNoC Control clock || 40 MHz
|-
| <code>ce</code> || Compute Engine clock || 266.667 MHz (available in UHD 4.6 and later)
|-
| <code>dram</code> || DRAM interface clock || 303.819 MHz
|-
| <code>radio</code> || Radio interface clock || Same as master clock rate (122.88 MHz, 125.0 MHz, or 153.6 MHz)
|}

====N32x====
{| class="wikitable"
! Clock Name !! Description !! Frequency
|-
| <code>rfnoc_chdr</code> || RFNoC CHDR clock || 200 MHz
|-
| <code>rfnoc_ctrl</code> || RFNoC Control clock || 40 MHz
|-
| <code>ce</code> || Compute Engine clock || 266.667 MHz (available in UHD 4.6 and later)
|-
| <code>dram</code> || DRAM interface clock || 303.819 MHz
|-
| <code>radio</code> || Radio interface clock || Same as master clock rate (200 MHz, 245.76 MHz, or 250 MHz)
|}

====X3xx====
{| class="wikitable"
! Clock Name !! Description !! Frequency
|-
| <code>rfnoc_chdr</code> || RFNoC CHDR clock || 187.5 MHz
|-
| <code>rfnoc_ctrl</code> || RFNoC Control clock || 93.75 MHz
|-
| <code>ce</code> || Compute Engine clock || 214.286 MHz
|-
| <code>dram</code> || DRAM interface clock || 300 MHz
|-
| <code>radio</code> || Radio interface clock || Same as master clock rate (184.32 MHz or 200 MHz)
|}

====X410====
{| class="wikitable"
! Clock Name !! Description !! Frequency
|-
| <code>rfnoc_chdr</code> || RFNoC CHDR clock || 200 MHz
|-
| <code>rfnoc_ctrl</code> || RFNoC Control clock || 40 MHz
|-
| <code>ce</code> || Compute Engine clock || 266.667 MHz (available in UHD 4.6 and later)
|-
| <code>dram</code> || DRAM interface clock || 250 MHz
|-
| <code>radio</code> || Radio interface clock || 122.88 MHz when master clock rate is 122.88, 245.76, or 491.52 MHz<br>125 MHz when master clock rate is 125, 250, or 500 MHz
|-
| <code>radio_2x</code> || Radio interface clock 2x || Twice the frequency of <code>radio</code>
|}

====X440====
{| class="wikitable"
! Clock Name !! Description !! Frequency
|-
| <code>rfnoc_chdr</code> || RFNoC CHDR clock || 200 MHz
|-
| <code>rfnoc_ctrl</code> || RFNoC Control clock || 40 MHz
|-
| <code>ce</code> || Compute Engine clock || 266.667 MHz (available in UHD 4.6 and later)
|-
| <code>dram</code> || DRAM interface clock || 300 MHz
|-
| <code>radio0</code> || Radio interface clock for daughterboard 0 || Daughterboard 0 master clock rate divided by 8 (e.g., 62.5 MHz if master clock rate is 500 MHz)
|-
| <code>radio1</code> || Radio interface clock for daughterboard 1 || Daughterboard 1 master clock rate divided by 8
|-
| <code>radio0_2x</code> || Radio interface clock 2x for daughterboard 0 || Twice the frequency of <code>radio0</code>
|-
| <code>radio1_2x</code> || Radio interface clock 2x for daughterboard 1 || Twice the frequency of <code>radio1</code>
|}

=== How do I add a clock with a different frequency? ===

If you only need the clock within your own RFNoC block, you can modify the HDL for your block to generate the clock that you need from one of the available clocks. To do this, add a new clock to your block's YAML description, connect the available clock to your block in the YAML description of your RFNoC image, then add a Xilinx MMCM IP instance to your block's HDL and connect the available clock to its input.

Starting with UHD 4.7, you can add clock generation modules that create new clocks based on the existing clocks. Note that you must create such a module as an HDL module: Describing clocks in the YAML files will not cause them to be generated for you.

Assuming you have such a module, describe the clocks in the module's YAML files as such:

clocks:
- name: ce
direction: in
- name: my_clk
direction: out

Now you will have a new clock called <code>my_clk</code>, which is derived from the <code>ce</code> clock.

In older versions of UHD, adding custom clocks is not directly supported. If you can't use any of the available clocks, you can modify the HDL code to generate a clock.

If the clock is needed by multiple RFNoC blocks, or if you want to change an existing clock, you can modify the HDL for the USRP you are using to add or change a clock. If you add a new clock to the RFNoC image core, you must also update the BSP YAML file (located in [https://github.com/EttusResearch/uhd/tree/master/host/include/uhd/rfnoc/core <repo>/host/include/uhd/rfnoc/core]) so that the <code>rfnoc_image_builder</code> knows that the clock exists. How and where the clocks are generated varies between USRPs. Please refer to the source code for that USRP ([https://github.com/EttusResearch/uhd/tree/master/fpga/usrp3/top <repo>/fpga/usrp3/top]).

== Xilinx Vivado ==

=== Do I need a Vivado license to build custom RFNoC FPGA images? ===

All RFNoC-capable USRPs use Xilinx FPGAs that require a license to use Vivado, except for E31x USRPs, which can use the free Vivado HL WebPACK Edition. Vivado is required to build FPGAs for RFNoC.

=== Which version and edition of Vivado do I need? ===

See the [https://files.ettus.com/manual/md_usrp3_build_instructions.html UHD User Manual] for the latest Vivado version requirements. UHD versions 4.0 through 4.2 require Vivado 2019.1.

For E31x devices, you can use the free Vivado HL Webpack. For all other USRPs, you can use Design Edition or System Edition. We recommend Design Edition, unless you plan to use System Generator for DSP. System Generator is not required by RFNoC.

=== Can I use a different Vivado version from the one required by my UHD version? ===

This is technically possible, but it can be a lot of work to convert and adapt all of the IP to a new Vivado version, and your custom combination of UHD and Vivado versions will not have been tested or validated by Ettus Research. Therefore, this is not recommended or supported.

=== Do I need to install all components of Vivado? ===

No. You only need to install device support for the FPGA you intend to build. Other devices can be unchecked to save disk space. The following FPGA types are used by USRPs:

* '''SoCs > Zynq-7000:''' E31x, E320, N3xx
* '''SOCs > Zynq UltraScale+ RFSoC:''' X410
* '''7 Series > Kintex-7''': X3xx

The Software Development Kit (SDK) is typically not required, but can be installed if desired.

The Cable Drivers are needed if you plan to do JTAG download or debug. Note that on Linux, the cable drivers are copied to the install folder, but are not installed onto your system automatically. See Xilinx UG973 for instructions on installing the cable drivers on Linux.

=== Why does the Vivado 2021.1 installer get stuck or not start on Ubuntu? ===

The Vivado installer needs the libncurses5 and libtinfo5 libraries to run correctly. They can be installed by running the following commands:

sudo apt update
wget http://security.ubuntu.com/ubuntu/pool/universe/n/ncurses/libtinfo5_6.3-2ubuntu0.1_amd64.deb
sudo apt install ./libtinfo5_6.3-2ubuntu0.1_amd64.deb
wget http://security.ubuntu.com/ubuntu/pool/universe/n/ncurses/libncurses5_6.3-2ubuntu0.1_amd64.deb
sudo apt install ./libncurses5_6.3-2ubuntu0.1_amd64.deb

== Building FPGA Images ==

=== Why did my FPGA build fail to meet timing constraints? ===

FPGAs have clocks that trigger the transfer of data between internal registers. The Vivado tool does a timing check near the end of the build to ensure that the paths from each driving register or port to each receiving register or port are not too long for the specified clock period or delay constraints. When it says "The design did not satisfy timing constraints" it means that Vivado couldn't arrange the logic on the chip in a way that meets all requirements. There are several reasons this might happen:

* You added new logic to the design with too much logic between registers. In this case, you should modify your design to make meeting timing easier.
* You added new logic, but made a mistake in which you're trying to use the wrong clock or reset, which makes it difficult to meet timing. In this case you need to correct the mistake in your design.
* The design has become too crowded, making it difficult for the tools to meet the timing requirements. In this case you need to remove something to make more room.
* Bad luck. The tools use pseudorandom algorithms to find solutions to really hard problems, and sometimes it doesn't find a good solution even when one is possible. In this case you can make a minor change to the design and build again to see if it does better the second time. If you don't change anything, Vivado will normally give you identical results for each build. In UHD 4.4 and later you can add the <code>BUILD_SEED=1</code> option to the <code>make</code> arguments to change a build seed that will affect the build results. Using a different seed number for each build will ensure that you get a unique build result each time. 0 is the default seed if not specified. Random build failures occur occasionally for some FPGA targets, in which case you should retry the build with a different seed.

The FPGA tools produce a timing report that says exactly which path failed to meet timing. Sometimes that can point you in the right direction. But sometimes the path indicated only failed because of another path that's even more difficult. Open <code>post_route_timing_summary.rpt</code> in the build output folder and search for "(VIOLATED)" to find the path(s) that failed.

=== My design doesn't fit in the FPGA. What can I do to reduce the size? ===

Read the <code>post_synth_util.rpt</code> to determine what resource(s) you are running out of in order to know what kinds of changes are needed. Below are several easy ways to reduce the resource utilization of the FPGA.

* If you are not using all RF channels of your device, modify the FPGA YAML file to remove the DDC, DUC, and Radio blocks for the unused channels, then regenerate the FPGA code using <code>rfnoc_image_builder</code>. Note that you may need at least one Radio block for RFNoC to work properly. You may also remove the DDC and/or the DUC if your application uses full bandwidth for one or more channels and therefore doesn't require up or down conversion.
* If you are not using DRAM, remove the Replay or DMA FIFO blocks. Also, on X4xx, change the <code>DRAM_CH</code> variable to 0 in the Makefile for the FPGA target you are building.
* If you do not need all SFP ports, use a build target that matches your needs. For example, on X4xx, the "X1" option (one 10 Gbps lane) uses the least resources whereas "X4" (four 10 Gbps lanes) uses a lot more, and the "CG" option (four 25 Gbps lanes) uses the most.
* If you do not need the full bandwidth of the device, use a smaller bandwidth option. For example, on X410, the "_100" option (100 MHz bandwidth) uses less resources than the "_200" option (200 MHz bandwidth).
* Add the <code>crossbar_routes</code> definition to the FPGA YAML file to include only the crossbar paths required for your application. This is an advanced feature in UHD 4.5 and later. This must be done carefully to avoid removing essential paths. See the X440 YAML files for examples.

Other reductions are possible but require advanced knowledge of UHD and/or RFNoC to avoid breaking key functionality of the device.

=== How do I create a Vivado project for my FPGA build? ===

Vivado supports two modes of operation known as "project mode" and "non-project mode". Project mode is more user-friendly because it creates a project file that is managed by Vivado and works natively in the Vivado GUI. Non-project mode is generally used by more advanced users who want full control over the Vivado build process and is typically used in fully scripted or automated build flows. The USRP build flow in UHD uses non-project mode. As a result, there is no Vivado project file by default.

It is possible to create a project file from the USRP build flow with the following steps:

# Start the USRP FPGA build in the GUI. In UHD 4.7 and later, this can be done by adding the <code>-g</code> argument to the <code>rfnoc_image_builder</code> command. In UHD 4.6 and earlier, this can be done by adding <code>GUI=1</code> to the <code>make</code> arguments. Example: <code>make X410_X4_200 GUI=1</code>
# After the build completes, run the following command in the TCL Console of Vivado to create the project file and switch to project mode:<br/><code>save_project_as project_name project_dir</code><br/>In this example, "project_name" is the name you want to give the project file and "project_dir" is the directory in which you want to put the project.
# Set the compile order to automatic: <br/><code>set_property source_mgmt_mode All [current_project]</code>

In some cases, it may also be necessary to reset the output products for some of the IP. If you get an error message about a BD sub-design being not generated for the synthesis target, then navigate to the "IP Sources" tab in the Project Manager Sources window, then right-click on affected IP and select "Reset Output Products...", then click "Reset".

This project file can now be used independently of the normal FPGA build flow in UHD. It is up to the user to update this project file as the design changes since it will not be managed by the normal build flow in UHD.

=== My FPGA takes a long time to build. What can I do to make builds faster? ===

High-performance computers are recommended for FPGA builds since an FPGA build can take several hours.

The build process is divided into two steps, IP generation and the FPGA build.

==== IP Generation ====

This process can take several hours by default and is run automatically, if needed, when you build an FPGA target. Fortunately, this only needs to be done once for each USRP type and won't run again unless IP is changed.

You can speed up the IP generation by running this step with multiple jobs. For example:

$ make -j 4 X410_IP

This example will build four IP cores at a time. Note that this generally requires 4 times as much memory and needs at least 4 CPU cores. You can adjust the number of parallel jobs based on the amount of system memory and/or CPU cores you have available.

==== FPGA Build ====

Unfortunately, increasing the number of jobs does not speed up FPGA performance because there is only one Vivado instance for the FPGA build. Vivado, by default, will use multiple CPU cores, where possible, but this does not significantly improve build performance since many parts of the build are not easily parallelizable.

One way to shorten the build time is to reduce the size of the design. See above on how to reduce the size of your design.

In the case where you need to build multiple FPGA types, you can use the jobs option with <code>make</code> to build multiple FPGAs simultaneously, which can dramatically reduce the time required per build. Note that this requires a significant amount of memory and CPU cores and therefore is only recommended for systems that can handle such loads. An example is shown below for building two FPGA images in parallel:

$ make -j 2 X410_X4_200 X410_CG_400

It is also possible to open separate terminal instances and run one build in each instance to get the same effect. Do not build the same FPGA target in multiple instances, since multiple builds for the same target would conflict as they try to access and update the same files.

=== When I start an FPGA build or use rfnoc_image_builder, I get an error "setupenv.sh: source: not found" and the build fails. What happened? ===

In some Linux distributions (e.g. Ubuntu) <code>dash</code> is set as default shell which can cause FPGA builds to fail.

Below is an example of the error. Note, that your message may look somewhat different depending on UHD version and USRP target but the important lines are marked in bold.

rfnoc_image_builder -y e320_rfnoc_image_core_fft.yml -t E320_1G
Using FPGA directory /home/someuser/uhd/fpga
Selected device: e320
Build artifacts directory already exists (contents will be overwritten).
Launching build with the following settings:
* FPGA Directory: /home/someuser/uhd/fpga/usrp3/top/e320
* Build Artifacts Directory: /home/someuser/uhd/fpga/usrp3/top/e320/build-usrp_e320_fpga_1G
* Build Output Directory: /home/someuser/uhd/fpga/usrp3/top/e320/build
* Build IP Directory: /home/someuser/uhd/fpga/usrp3/top/e320/build-ip
Executing the following command: . ./setupenv.sh && make E320_1G BUILD_DIR=/home/someuser/uhd/fpga/usrp3/top/e320/build-usrp_e320_fpga_1G IMAGE_CORE_NAME=usrp_e320_fpga_1G
'''/bin/sh: 6: ./setupenv.sh: Bad substitution'''
'''/bin/sh: 8: ./setupenv.sh: declare: not found'''
/bin/sh: 9: ./setupenv.sh: PRODUCT_ID_MAP[E320]=zynq/xc7z045/ffg900/-3: not found
'''/bin/sh: 15: ./setupenv.sh: source: not found'''
Build finished with return code 127.

It is recommended to set the default shell to <code>bash</code> by running the following command in the terminal. When asked <code>Use dash as the default system shell (/bin/sh)?</code> choose <code><No></code>.

$ sudo dpkg-reconfigure dash

Confirm your default shell was changed to bash by running this command:

$ ll /bin/sh

You should see output similar to this:

lrwxrwxrwx 1 root root 4 Oct 10 2020 /bin/sh -> bash*

=== My FPGA build failed with a cryptic message or no message at all. How do I debug this? ===

When you build an FPGA target, a build directory is created in the FPGA's top directory that contains all the build outputs. Here you'll find the <code>build.log</code> file as well as report files and checkpoints. Not all log information is printed to the console during build, so make sure you check the <code>build.log</code> file for details. It may contain a useful error message that was not printed to the console.

Builds often fail when Vivado encounters an internal error or runs out of memory. For internal errors, the error message is typically not very helpful and is often due to a bug in Vivado. When Vivado runs out of memory, it may immediately terminate without giving any error message at all. Consider monitoring the memory usage during the FPGA build to see if you are approaching your system's limit.

If you have made changes to the design, try building an unmodified FPGA image from scratch to ensure the build process is working properly on your system. If this works, try adding your changes incrementally until the section of code causing the problem is identified.

Note that such errors are often beyond the control of Ettus Research and reaching out to Xilinx support is a better option if it is truly a Vivado issue.

=== I get a warning saying that an IP is locked, which results in errors later in the IP generation process. How do I resolve this? ===

Vivado "locks" IP, for example, when it needs to be updated for the running version of Vivado or FPGA device type. This is intended to force the user to fix the issue and to avoid building incompatible IP. Build failures related to IP being locked should never occur during a normal build. The IP version in the UHD repo always matches the Vivado version required for that release of UHD.

This can happen if you have used the wrong version of Vivado or do not have the correct Vivado patches installed. Refer to the <code>Generation 3 USRP Build Documentation</code> section of the [[UHD and USRP User Manual|UHD Manual] for the required version and patches. When you run the `source setenv.sh` step to setup your environment, the script will check to make sure you are using the correct version.

In some cases, reinstalling Vivado might be required.

Once the correct Vivado version and patches are installed, you will need to remove all build products (to remove any locked IP that was generated) and retry the build. For example:

$ source setupenv.sh # Setup environment and check the Vivado version
$ make cleanall # Remove any bad IP that was generated
$ make X410_X4_200 # Start the build process again

=== I see a "CRITICAL WARNING" in the build log. Is this expected? ===

There are many critical warnings that appear during the build process that can be safely ignored. For example, you may see the following:

CRITICAL WARNING: [Vivado 12-1790] Evaluation License Warning: This design contains one or more IP cores that use separately licensed features. If the design has been configured to make use of evaluation features, please note that these features will cease to function after a certain period of time. Please consult the core datasheet to determine whether the core which you have configured will be affected. Evaluation features should NOT be used in production systems.

The FPGA builds include IP for which the licenses are included with Vivado, but Vivado prints the warnings anyway. As long as you have a Vivado license and a bitstream was successfully generated, the IP should work as expected.

USRP Host Performance Tuning Tips and Tricks

2025-05-22T19:28:20Z

JonathonPendlum: Add instructions on how to make adjusting the network buffer sizes persistent after reboot

==Application Note Number==
'''AN-088'''

==Overview==
This application note provides various tips and tricks for tuning your host computer for best performance when working with USRP devices.

==CPU Governor==
Ensure your CPU governor is set to <code>performance</code>. This can be done with the Linux utility <code>cpufrequtils</code>.

Install <code>cpufrequtils</code> with the command below:

sudo apt install cpufrequtils

You can then set the CPU governor to <code>performance</code> per core by issuing the command:

sudo cpufreq-set -c $core_number -g performance

To set the CPU governor to <code>performance</code> for all cores:

for ((i=0;i<$(nproc --all);i++)); do sudo cpufreq-set -c $i -r -g performance; done

You can then verify that the CPU governor has been set by running the command:

cpufreq-info

==Thread Priority Scheduling==

When UHD spawns a new thread, it may try to boost the thread's scheduling priority. If setting the new priority fails, the UHD software prints a warning to the console, as shown below. This warning is harmless; it simply means that the thread will retain a normal or default scheduling priority.

<pre>
UHD Warning:
Unable to set the thread priority. Performance may be negatively affected.
Please see the general application notes in the manual for instructions.
EnvironmentError: OSError: error in pthread_setschedparam
</pre>

To address this issue, non-privileged (non-root) users need to be given special permission to change the scheduling priority. This can be enabled by creating a group <code>usrp</code>, adding your user to it, and then appending the line <code>@usrp - rtprio 99</code> to the file <code>/etc/security/limits.conf</code>.

sudo groupadd usrp
sudo usermod -aG usrp $USER

Then add the line below to end of the file <code>/etc/security/limits.conf</code>:

@usrp - rtprio 99

You must log out and log back into the account for the settings to take effect. In most Linux distributions, a list of groups and group members can be found in the <code>/etc/group</code> file.

There is further documentation about this in the User Manual at the link below.

* [http://files.ettus.com/manual/page_general.html#general_threading_prio Threading Notes section of the User Manual]

==Adjust Network Buffers==
This applies to USRP devices connected via Ethernet, such as the N200, N210, N300, N310, N320, N321, X300, X310, E320, X410, X440.

Note that these settings will not persist across a reboot.

sudo sysctl -w net.core.wmem_max=33554432
sudo sysctl -w net.core.rmem_max=33554432
sudo sysctl -w net.core.wmem_default=33554432
sudo sysctl -w net.core.rmem_default=33554432

To make these settings persistent, set or add the following in <code>/etc/sysctl.conf</code>:

net.core.wmem_max=33554432
net.core.rmem_max=33554432
net.core.wmem_default=33554432
net.core.rmem_default=33554432

==Adjust Ethernet MTU==
This applies to Ethernet connected USRPs (N2xx, N3xx, X3xx, E320).

For 1 Gigabit connections, the MTU should be set to <code>1500</code>.

For 10 Gigabit connections, the MTU should be set to <code>9000</code>.

It is important to set the value and '''not''' leave it is <code>automatic</code>

==Increasing Ring Buffers==
This applies to Ethernet connected USRPs using a 10 Gb interface (X3xx, N3xx, E320).

Increasing the Ring Buffers on the NIC may help prevent flow control errors at higher rates.

sudo ethtool -G <interface> tx 4096 rx 4096

== DPDK ==
DPDK is supported on N3xx, X3xx and E320 USRPs. DPDK replaces the traditional Linux networking stack with a low overhead user-land based driver. Additional details of using DPDK can be found in the UHD Manual located at the following link: https://files.ettus.com/manual/page_dpdk.html

== Disable Hyper-threading ==

In some applications which require the highest possible CPU performance per core, disabling hyper-threading can provide roughly a 10% increase in core performance, at the cost of having fewer core threads. Hyper-threading is disabled within the BIOS and how to do this varies by motherboard manufacturer. With other techniques listed here, disabling hyper-threading should only be done as a last resort to eek absolute maximum performance from the CPU.

== Disable KPTI Protections for Spectre/Meltdown==
In some cases, disabling the KPTI protections for the Linux Kernel can increase performance by 10-15%. It is important to note the ramification making this modification can have. This modification is only recommended for systems that absolutely require the best performance and are not connected to the internet.

* https://en.wikipedia.org/wiki/Meltdown_(security_vulnerability)
* https://en.wikipedia.org/wiki/Spectre_(security_vulnerability)

Disabling KPTI protections can be done by adding the lines below to your <code>/etc/default/grub</code> file at <code>GRUB_CMDLINE_LINUX_DEFAULT=""</code>

pti=off spectre_v2=off l1tf=off nospec_store_bypass_disable no_stf_barrier

After modifying the <code>grub</code> file, run the following command to update your configuration and reboot:

sudo update-grub

[[Category:Application Notes]]

RFNoC Frequently Asked Questions

2025-05-22T18:41:19Z

JonathonPendlum: Added FAQ about FPGA build failures due to dash being the default shell instead of bash

== Configuring the Stream Endpoint Buffer Size in RFNoC ==

=== What is the SEP buffer size? ===

Each stream endpoint (SEP) has an ingress buffer to store data received from others stream endpoints. This size of this buffer affects the data transfer rate that can be achieved when streaming to that endpoint. A larger ingress buffer in the stream endpoint means that there is more space to put data, minimizing idle time on the network. Additionally, streamers can queue up data before it is needed, reducing the chance of a buffer underflow.

=== How do I set the SEP buffer size? ===

The stream endpoint buffer size is set by adding a parameter under the endpoint you want to configure in the RFNoC image core YAML file. There are two parameters you can use to set the stream endpoint ingress buffer size in your RFNoC image core YAML file.

* <code>buff_size</code>: Buffer size in CHDR words. The size in bytes depends on the CHDR width. For example, if the <code>chdr_width</code> parameter for the device is 64, then each CHDR word is 8 bytes. So a buff size of 32768 would be 262,144 bytes or 256 KiB. See [https://github.com/EttusResearch/uhd/blob/197cdc4f665cbd4e6394a7eeb44b405f67ab10b1/fpga/usrp3/top/x300/x310_rfnoc_image_core.yml#L20 here] for an example.
* <code>buff_size_bytes</code>: Buffer size in bytes. See [https://github.com/EttusResearch/uhd/blob/197cdc4f665cbd4e6394a7eeb44b405f67ab10b1/fpga/usrp3/top/x400/x410_200_rfnoc_image_core.yml#L21 here] for an example.

=== To what value should I set the SEP buffer size? ===

The buffer size should be a power of two in size to make optimal use of FPGA RAM resources. The default FPGA bitstreams typically set them to the largest size the FPGA can fit in order to maximize performance. Here are some general recommendations:

* Set to <code>0</code> if you don't need to send data to that SEP.
* Set to <code>8192</code> bytes (8 KiB = 1 MTU) minimum in order to stream data packets.
* Set to <code>32768</code> bytes (32 KiB = 4 MTU) in order to stream at maximum rates between SEPs on the same FPGA.
* Set to <code>262144</code> bytes (256 KiB = 32 MTU) or lager for high performance streaming between a host computer and the FPGA.

Note that the requirements are application-dependent, so optimal sizes for your application may be different. MTU refers to the maximum transmission unit, which is the largest CHDR packet supported by the FPGA.

If you need to free up FPGA resources (particularly block RAM) for your application, you can reduce the SEP buffer sizes. Just keep in mind that the maximum streaming rate may be affected.

== USRP DRAM ==

=== How much and what speed DRAM is available on each USRP? ===

The table below summarizes the DRAM that is connected to the USRP for use by RFNoC.

{| class="wikitable"
|+ USRP DRAM Summary
|-
! USRP Model !! DRAM Size !! Default DRAM Speed !! Default User Interface
|-
| E31x || 512 MiB || 16-bit @ 800 MT/s (1.6 GB/s) || 2 ch x 64-bit @ 100 MHz
|-
| E320 || 2 GiB || 32-bit @ 1333 MT/s (5.33 GB/s) || 4 ch x 64-bit @ 300 MHz
|-
| N3xx || 2 GiB || 32-bit @ 1300 MT/s (5.2 GB/s) || 4 ch x 64-bit @ 303.819 MHz
|-
| X3xx || 1 GiB || 32-bit @ 1200 MT/s (4.8 GB/s) || 2 ch x 64-bit @ 300 MHz
|-
| X410 (100 and 200 MHz BW) || 4 GiB || 64-bit @ 2.0 GT/s (16.0 GB/s) || 4 x 64-bit @ 250 MHz
|-
| X410 (400 MHz BW) || 4 GiB per bank<br>(8 GiB total) || 64-bit @ 2.0 GT/s (16.0 GB/s) per bank<br>(32.0 GB/s total) || 4 x 128-bit @ 250 MHz (using 2 banks)
|-
| X440 (400 MHz BW) || 4 GiB per bank<br>(8 GiB total) || 64-bit @ 2.4 GT/s (19.2 GB/s) per bank<br>(38.4 GB/s total) || 8 x 128-bit @ 300 MHz (using 2 banks)
|-
| X440 (1600 MHz BW) || 4 GiB per bank<br>(8 GiB total) || 64-bit @ 2.4 GT/s (19.2 GB/s) per bank<br>(38.4 GB/s total) || 2 x 512-bit @ 300 MHz (using 2 banks)
|}

=== What DRAM data rates can I expect on each USRP? ===

DRAM performance is highly application-specific. For example, reading vs. reading and writing simultaneously, one data stream vs. multiple data streams, random access vs. sequential access, etc., can give dramatically different performance. Below are some measurements taken on different USRPs where a Null-Source-Sink RFNoC block is directly connected to a DMA FIFO block to test maximum streaming rates through the DRAM. The DRAM is shared between channels, so throughput goes down as the number of channels going through the DRAM is increased.

{| class="wikitable"
|+ Example DRAM Throughput (Per Channel)
|-
! USRP Model !! BIST (MB/s) !! 1 Ch (MS/s) !! 2 Ch (MS/s) !! 3 Ch (MS/s) !! 4 Ch (MS/s)
|-
| E31x || 666 || 166 || 91 || N/A || N/A
|-
| E320 || 1361 || 340 || 299 || 191 || 148
|-
| N3xx || 1368 || 341 || 295 || 191 || 144
|-
| X3xx || 1347 || 336 || 274 || N/A || N/A
|-
| X410 (100 and 200 MHz BW) || 1288 || 321|| 316|| 314 || 303
|-
| X410 (400 MHz BW) || 2801 || 697 || 672 || 672 || 672
|-
| X440 (400 MHz BW) || 3360 || 798 || 784 || 616 || 461
|-
| X440 (1600 MHz BW) || 8118 || 2007 || 2007 || N/A || N/A
|}
Notes:
# E31x, N3xx, and X410 were tested using UHD 4.2. E320 and X3xx were tested using UHD 4.3.
# BIST refers to the built-in self test, which gives a measure of raw data throughput for a single channel.
# For MS/s, we assume 4 bytes per sample (sc16).
# X410 with 400 MHz bandwidth uses two independent memory banks, with channels 0-1 on Bank 0, and channels 2-3 on Bank 1 by default. The traffic flows on Bank 0 and Bank 1 are independent and do not affect each other. Therefore, a 4-channel configuration has the same performance as a 2-channel configuration.
# X440 uses two independent memory banks. For 400 MHz, channels 0-3 are on Bank 0 and channels 4-7 are on Bank 1 by default. For 1600 MHz, channel 0 is on Bank 0 and channel 1 is on bank 1 by default. The traffic flows on Bank 0 and Bank 1 are independent and do not affect each other. Therefore, a 2-channel configuration has the same performance as a 1-channel configuration.

=== What can the DRAM be used for? ===

* '''DMA FIFO Block:''' The DMA FIFO block is used in situations where you need a large buffer to store samples.

* '''Replay Block:''' The Replay block is used to record and play back RF data. For example, you can record data from a host computer, then play it back over the radio. Or, record data from the radio, then play it back later to the host for analysis, or play it back to a radio at a specific timestamp. See [[Using the RFNoC Replay Block in UHD 4]] for additional information. The Replay block also has a FIFO capability for situations in which the DMA FIFO block is not available in your FPGA image.

* '''Custom Blocks:''' You can also create your own RFNoC block that uses DRAM. Refer to the DMA FIFO and/or Replay blocks as examples.

=== How do I add the Replay/DMA FIFO block to my FPGA image? ===

If the block you want is not included by default in the FPGA image you are using, you can add it to the RFNoC image core YAML file and rebuild the FPGA image using Vivado. See [[Getting Started with RFNoC in UHD 4.0]] for additional information on customizing an RFNoC image.

'''Note:''' DRAM is not enabled by default on E31x FPGA builds because the FPGA is not large enough to fit the default image with DRAM. You will need to remove components from your RFNoC image's YAML file to make room, then build the E31x image with the variable DRAM=1 set, or modify the E31x Makefile to enable DRAM by default.

'''Note:''' The default DRAM configuration used for X410 and X440 changes depending on the configured bandwidth. The default parameters to use for each image type is shown in the table below.

When adding the blocks to your RFNoC image core YAML file, the parameters must be set correctly for the type of USRP you intend to use. The memory data width (<code>MEM_DATA_W</code>) and address width (<code>MEM_ADDR_W</code>) must match exactly. The number of ports (<code>NUM_PORTS</code>) must not exceed the maximum number available. You can use fewer ports to save resources if you don't need all the DRAM ports.

{| class="wikitable"
|+ RFNoC Block Memory Parameters
|-
! USRP Model !! MEM_DATA_W !! MEM_ADDR_W !! NUM_PORTS (Max)
|-
| E31x || 64 || 29 || 2
|-
| E320 || 64 || 31 || 4
|-
| N3xx || 64 || 31 || 4
|-
| X3xx || 64 || 30 || 2
|-
| X410 (100 and 200 MHz BW) || 64 || 32 || 4
|-
| X410 (400 MHz BW) || 128 || 32 || 4
|-
| X440 (400 MHz BW) || 128 || 32 || 8
|-
| X440 (1600 MHz BW) || 512 || 32 || 2
|}

The DMA FIFO has a few additional parameters that should be provided. The clock rate (<code>MEM_CLK_RATE</code>) must match the value below for the built-in self test (BIST) to work correctly. The base address (<code>FIFO_ADDR_BASE</code>) and address mask (<code>FIFO_ADDR_MASK</code>) are written as Verilog constants and can be changed depending on your application. The <code>FIFO_ADDR_BASE</code> parameter contains the byte address for the first byte of the memory region to use for each port. The <code>FIFO_ADDR_MASK</code> parameter contains the address mask for each port, which tells the FIFO how much memory to use for each port. For example, an address mask of <code>30'h1FFFFFFF</code> means that 0x1FFFFFFF+1 bytes (i.e., 0x20000000 bytes or 512 MiB) will be used by the corresponding port. The address mask must be 1 less than a power of 2.

The example values in the table below use the entire memory and divide it evenly between all available ports.

{| class="wikitable"
|+ DMA FIFO Parameters
|-
! USRP Model !! MEM_CLK_RATE !! FIFO_ADDR_BASE !! FIFO_ADDR_MASK
|-
| E31x || "200e6" || "{29'h10000000, 29'h00000000}" || "{29'h0FFFFFFF, 29'h0FFFFFFF}"
|-
| E320 || "300e6" || "{31'h60000000, 31'h40000000, 31'h20000000, 31'h00000000}" || "{31'h1FFFFFFF, 31'h1FFFFFFF, 31'h1FFFFFFF, 31'h1FFFFFFF}"
|-
| N3xx || "303819444" || "{31'h60000000, 31'h40000000, 31'h20000000, 31'h00000000}" || "{31'h1FFFFFFF, 31'h1FFFFFFF, 31'h1FFFFFFF, 31'h1FFFFFFF}"
|-
| X3xx || "300e6" || "{30'h20000000, 30'h00000000}" || "{30'h1FFFFFFF, 30'h1FFFFFFF}"
|-
| X410 (100 and 200 MHz BW) || "250e6" || "{32'hC0000000, 32'h80000000, 32'h40000000, 32'h00000000}" || "{32'h3FFFFFFF, 32'h3FFFFFFF, 32'h3FFFFFFF, 32'h3FFFFFFF}"
|-
| X410 (400 MHz BW) || "250e6" || "{32'h80000000, 32'h00000000, 32'h80000000, 32'h00000000}" || "{32'h7FFFFFFF, 32'h7FFFFFFF, 32'h7FFFFFFF, 32'h7FFFFFFF}"
|-
| X440 (400 MHz BW) || "300e6" || "{32'hC0000000, 32'h80000000, 32'h40000000, 32'h00000000, 32'hC0000000, 32'h80000000, 32'h40000000, 32'h00000000}" || "{32'h3FFFFFFF, 32'h3FFFFFFF, 32'h3FFFFFFF, 32'h3FFFFFFF, 32'h3FFFFFFF, 32'h3FFFFFFF, 32'h3FFFFFFF, 32'h3FFFFFFF}"
|-
| X440 (1600 MHz BW) || "300e6" || "{32'h00000000, 32'h00000000}" || "{32'hFFFFFFFF, 32'hFFFFFFFF}"
|}

==== Replay Example ====

See [https://github.com/EttusResearch/uhd/blob/197cdc4f665cbd4e6394a7eeb44b405f67ab10b1/fpga/usrp3/top/x300/x310_rfnoc_image_core.yml#L69 x310_rfnoc_image_core.yml] for an example of how to instantiate the Replay block in the RFNoC image core YAML description. The following is a generic example that can be used for any USRP:
<nowiki>
noc_blocks:
# Instantiate the replay block
replay0:
block_desc: 'replay.yml'
parameters:
NUM_PORTS: <see table>
MEM_DATA_W: <see table>
MEM_ADDR_W: <see table>

connections:
# Connect each port of the replay block to a stream endpoint
- { srcblk: <epN>, srcport: out0, dstblk: replay0, dstport: in_0 }
- { srcblk: replay0, srcport: out_0, dstblk: <epN>, dstport: in0 }
- { srcblk: <epN+1>, srcport: out0, dstblk: replay0, dstport: in_1 }
- { srcblk: replay0, srcport: out_1, dstblk: <epN+1>, dstport: in0 }
... repeat for each remaining Replay port
# Connect the replay block memory interface to the USRP DRAM
- { srcblk: replay0, srcport: axi_ram, dstblk: _device_, dstport: dram }

Connect the DRAM clock to the block:
clk_domains:
# Connect the DRAM clock to the replay block
- { srcblk: _device_, srcport: dram, dstblk: replay0, dstport: mem }</nowiki>

==== DMA FIFO Example ====

See [https://github.com/EttusResearch/uhd/blob/197cdc4f665cbd4e6394a7eeb44b405f67ab10b1/fpga/usrp3/top/e320/e320_rfnoc_image_core.yml#L49 e320_rfnoc_image_core.yml] for an example of how to instantiate the DMA FIFO block in the RFNoC image core YAML description. The following is a generic example that can be used for any USRP:
<nowiki>
noc_blocks:
# Instantiate the DMA FIFO block
fifo0:
block_desc: 'axi_ram_fifo.yml'
parameters:
NUM_PORTS: <see table>
MEM_DATA_W: <see table>
MEM_ADDR_W: <see table>
FIFO_ADDR_BASE: <see table>
FIFO_ADDR_MASK: <see table>
MEM_CLK_RATE: <see table>

connections:
# Connect each port of the DMA FIFO block to a stream endpoint, or insert it
# into the data path where desired. This examples uses stream endpoints.
- { srcblk: <epN>, srcport: out0, dstblk: fifo0, dstport: in_0 }
- { srcblk: replay0, srcport: out_0, dstblk: <epN>, dstport: in0 }
- { srcblk: <epN+1>, srcport: out0, dstblk: fifo0, dstport: in_1 }
- { srcblk: fifo0, srcport: out_1, dstblk: <epN+1>, dstport: in0 }
... repeat for each remaining FIFO port
# Connect the DMA FIFO block memory interface to the USRP DRAM
- { srcblk: fifo0, srcport: axi_ram, dstblk: _device_, dstport: dram }

clk_domains:
# Connect the DRAM clock to the replay block
- { srcblk: _device_, srcport: dram, dstblk: fifo0, dstport: mem }</nowiki>

== RFNoC Clocks ==

=== What clocks are available for me to use? ===

Each device has different clocks available. See below for a list of clocks exposed to RFNoC. Although they have intended purposes, you can use any of these clocks for any purpose. The <code>rfnoc_chdr_clock</code> is a good default choice. This clock is always available in your block, even if it is not explicitly connected in the RFNoC image YAML description.

=== What are the clock frequencies? ===

See the table below for the clock rates. The radio clock rate depends on the master clock rate.

====E31x====
{| class="wikitable"
! Clock Name !! Description !! Frequency
|-
| <code>rfnoc_chdr</code> || RFNoC CHDR clock || 100 MHz
|-
| <code>rfnoc_ctrl</code> || RFNoC Control clock || 40 MHz
|-
| <code>dram</code> || DRAM interface clock || 100 MHz
|-
| <code>radio</code> || Radio interface clock || Same as master clock rate
|}

====E320====
{| class="wikitable"
! Clock Name !! Description !! Frequency
|-
| <code>rfnoc_chdr</code> || RFNoC CHDR clock || 200 MHz
|-
| <code>rfnoc_ctrl</code> || RFNoC Control clock || 40 MHz
|-
| <code>dram</code> || DRAM interface clock || 166.667 MHz
|-
| <code>radio</code> || Radio interface clock || Same as master clock rate (200 kHz to 61.44 MHz)
|}

====N300/N310====
{| class="wikitable"
! Clock Name !! Description !! Frequency
|-
| <code>rfnoc_chdr</code> || RFNoC CHDR clock || 200 MHz
|-
| <code>rfnoc_ctrl</code> || RFNoC Control clock || 40 MHz
|-
| <code>ce</code> || Compute Engine clock || 266.667 MHz (available in UHD 4.6 and later)
|-
| <code>dram</code> || DRAM interface clock || 303.819 MHz
|-
| <code>radio</code> || Radio interface clock || Same as master clock rate (122.88 MHz, 125.0 MHz, or 153.6 MHz)
|}

====N32x====
{| class="wikitable"
! Clock Name !! Description !! Frequency
|-
| <code>rfnoc_chdr</code> || RFNoC CHDR clock || 200 MHz
|-
| <code>rfnoc_ctrl</code> || RFNoC Control clock || 40 MHz
|-
| <code>ce</code> || Compute Engine clock || 266.667 MHz (available in UHD 4.6 and later)
|-
| <code>dram</code> || DRAM interface clock || 303.819 MHz
|-
| <code>radio</code> || Radio interface clock || Same as master clock rate (200 MHz, 245.76 MHz, or 250 MHz)
|}

====X3xx====
{| class="wikitable"
! Clock Name !! Description !! Frequency
|-
| <code>rfnoc_chdr</code> || RFNoC CHDR clock || 187.5 MHz
|-
| <code>rfnoc_ctrl</code> || RFNoC Control clock || 93.75 MHz
|-
| <code>ce</code> || Compute Engine clock || 214.286 MHz
|-
| <code>dram</code> || DRAM interface clock || 300 MHz
|-
| <code>radio</code> || Radio interface clock || Same as master clock rate (184.32 MHz or 200 MHz)
|}

====X410====
{| class="wikitable"
! Clock Name !! Description !! Frequency
|-
| <code>rfnoc_chdr</code> || RFNoC CHDR clock || 200 MHz
|-
| <code>rfnoc_ctrl</code> || RFNoC Control clock || 40 MHz
|-
| <code>ce</code> || Compute Engine clock || 266.667 MHz (available in UHD 4.6 and later)
|-
| <code>dram</code> || DRAM interface clock || 250 MHz
|-
| <code>radio</code> || Radio interface clock || 122.88 MHz when master clock rate is 122.88, 245.76, or 491.52 MHz<br>125 MHz when master clock rate is 125, 250, or 500 MHz
|-
| <code>radio_2x</code> || Radio interface clock 2x || Twice the frequency of <code>radio</code>
|}

====X440====
{| class="wikitable"
! Clock Name !! Description !! Frequency
|-
| <code>rfnoc_chdr</code> || RFNoC CHDR clock || 200 MHz
|-
| <code>rfnoc_ctrl</code> || RFNoC Control clock || 40 MHz
|-
| <code>ce</code> || Compute Engine clock || 266.667 MHz (available in UHD 4.6 and later)
|-
| <code>dram</code> || DRAM interface clock || 300 MHz
|-
| <code>radio0</code> || Radio interface clock for daughterboard 0 || Daughterboard 0 master clock rate divided by 8 (e.g., 62.5 MHz if master clock rate is 500 MHz)
|-
| <code>radio1</code> || Radio interface clock for daughterboard 1 || Daughterboard 1 master clock rate divided by 8
|-
| <code>radio0_2x</code> || Radio interface clock 2x for daughterboard 0 || Twice the frequency of <code>radio0</code>
|-
| <code>radio1_2x</code> || Radio interface clock 2x for daughterboard 1 || Twice the frequency of <code>radio1</code>
|}

=== How do I add a clock with a different frequency? ===

If you only need the clock within your own RFNoC block, you can modify the HDL for your block to generate the clock that you need from one of the available clocks. To do this, add a new clock to your block's YAML description, connect the available clock to your block in the YAML description of your RFNoC image, then add a Xilinx MMCM IP instance to your block's HDL and connect the available clock to its input.

Starting with UHD 4.7, you can add clock generation modules that create new clocks based on the existing clocks. Note that you must create such a module as an HDL module: Describing clocks in the YAML files will not cause them to be generated for you.

Assuming you have such a module, describe the clocks in the module's YAML files as such:

clocks:
- name: ce
direction: in
- name: my_clk
direction: out

Now you will have a new clock called <code>my_clk</code>, which is derived from the <code>ce</code> clock.

In older versions of UHD, adding custom clocks is not directly supported. If you can't use any of the available clocks, you can modify the HDL code to generate a clock.

If the clock is needed by multiple RFNoC blocks, or if you want to change an existing clock, you can modify the HDL for the USRP you are using to add or change a clock. If you add a new clock to the RFNoC image core, you must also update the BSP YAML file (located in [https://github.com/EttusResearch/uhd/tree/master/host/include/uhd/rfnoc/core <repo>/host/include/uhd/rfnoc/core]) so that the <code>rfnoc_image_builder</code> knows that the clock exists. How and where the clocks are generated varies between USRPs. Please refer to the source code for that USRP ([https://github.com/EttusResearch/uhd/tree/master/fpga/usrp3/top <repo>/fpga/usrp3/top]).

== Xilinx Vivado ==

=== Do I need a Vivado license to build custom RFNoC FPGA images? ===

All RFNoC-capable USRPs use Xilinx FPGAs that require a license to use Vivado, except for E31x USRPs, which can use the free Vivado HL WebPACK Edition. Vivado is required to build FPGAs for RFNoC.

=== Which version and edition of Vivado do I need? ===

See the [https://files.ettus.com/manual/md_usrp3_build_instructions.html UHD User Manual] for the latest Vivado version requirements. UHD versions 4.0 through 4.2 require Vivado 2019.1.

For E31x devices, you can use the free Vivado HL Webpack. For all other USRPs, you can use Design Edition or System Edition. We recommend Design Edition, unless you plan to use System Generator for DSP. System Generator is not required by RFNoC.

=== Can I use a different Vivado version from the one required by my UHD version? ===

This is technically possible, but it can be a lot of work to convert and adapt all of the IP to a new Vivado version, and your custom combination of UHD and Vivado versions will not have been tested or validated by Ettus Research. Therefore, this is not recommended or supported.

=== Do I need to install all components of Vivado? ===

No. You only need to install device support for the FPGA you intend to build. Other devices can be unchecked to save disk space. The following FPGA types are used by USRPs:

* '''SoCs > Zynq-7000:''' E31x, E320, N3xx
* '''SOCs > Zynq UltraScale+ RFSoC:''' X410
* '''7 Series > Kintex-7''': X3xx

The Software Development Kit (SDK) is typically not required, but can be installed if desired.

The Cable Drivers are needed if you plan to do JTAG download or debug. Note that on Linux, the cable drivers are copied to the install folder, but are not installed onto your system automatically. See Xilinx UG973 for instructions on installing the cable drivers on Linux.

== Building FPGA Images ==

=== Why did my FPGA build fail to meet timing constraints? ===

FPGAs have clocks that trigger the transfer of data between internal registers. The Vivado tool does a timing check near the end of the build to ensure that the paths from each driving register or port to each receiving register or port are not too long for the specified clock period or delay constraints. When it says "The design did not satisfy timing constraints" it means that Vivado couldn't arrange the logic on the chip in a way that meets all requirements. There are several reasons this might happen:

* You added new logic to the design with too much logic between registers. In this case, you should modify your design to make meeting timing easier.
* You added new logic, but made a mistake in which you're trying to use the wrong clock or reset, which makes it difficult to meet timing. In this case you need to correct the mistake in your design.
* The design has become too crowded, making it difficult for the tools to meet the timing requirements. In this case you need to remove something to make more room.
* Bad luck. The tools use pseudorandom algorithms to find solutions to really hard problems, and sometimes it doesn't find a good solution even when one is possible. In this case you can make a minor change to the design and build again to see if it does better the second time. If you don't change anything, Vivado will normally give you identical results for each build. In UHD 4.4 and later you can add the <code>BUILD_SEED=1</code> option to the <code>make</code> arguments to change a build seed that will affect the build results. Using a different seed number for each build will ensure that you get a unique build result each time. 0 is the default seed if not specified. Random build failures occur occasionally for some FPGA targets, in which case you should retry the build with a different seed.

The FPGA tools produce a timing report that says exactly which path failed to meet timing. Sometimes that can point you in the right direction. But sometimes the path indicated only failed because of another path that's even more difficult. Open <code>post_route_timing_summary.rpt</code> in the build output folder and search for "(VIOLATED)" to find the path(s) that failed.

=== My design doesn't fit in the FPGA. What can I do to reduce the size? ===

Read the <code>post_synth_util.rpt</code> to determine what resource(s) you are running out of in order to know what kinds of changes are needed. Below are several easy ways to reduce the resource utilization of the FPGA.

* If you are not using all RF channels of your device, modify the FPGA YAML file to remove the DDC, DUC, and Radio blocks for the unused channels, then regenerate the FPGA code using <code>rfnoc_image_builder</code>. Note that you may need at least one Radio block for RFNoC to work properly. You may also remove the DDC and/or the DUC if your application uses full bandwidth for one or more channels and therefore doesn't require up or down conversion.
* If you are not using DRAM, remove the Replay or DMA FIFO blocks. Also, on X4xx, change the <code>DRAM_CH</code> variable to 0 in the Makefile for the FPGA target you are building.
* If you do not need all SFP ports, use a build target that matches your needs. For example, on X4xx, the "X1" option (one 10 Gbps lane) uses the least resources whereas "X4" (four 10 Gbps lanes) uses a lot more, and the "CG" option (four 25 Gbps lanes) uses the most.
* If you do not need the full bandwidth of the device, use a smaller bandwidth option. For example, on X410, the "_100" option (100 MHz bandwidth) uses less resources than the "_200" option (200 MHz bandwidth).
* Add the <code>crossbar_routes</code> definition to the FPGA YAML file to include only the crossbar paths required for your application. This is an advanced feature in UHD 4.5 and later. This must be done carefully to avoid removing essential paths. See the X440 YAML files for examples.

Other reductions are possible but require advanced knowledge of UHD and/or RFNoC to avoid breaking key functionality of the device.

=== How do I create a Vivado project for my FPGA build? ===

Vivado supports two modes of operation known as "project mode" and "non-project mode". Project mode is more user-friendly because it creates a project file that is managed by Vivado and works natively in the Vivado GUI. Non-project mode is generally used by more advanced users who want full control over the Vivado build process and is typically used in fully scripted or automated build flows. The USRP build flow in UHD uses non-project mode. As a result, there is no Vivado project file by default.

It is possible to create a project file from the USRP build flow with the following steps:

# Start the USRP FPGA build in the GUI. In UHD 4.7 and later, this can be done by adding the <code>-g</code> argument to the <code>rfnoc_image_builder</code> command. In UHD 4.6 and earlier, this can be done by adding <code>GUI=1</code> to the <code>make</code> arguments. Example: <code>make X410_X4_200 GUI=1</code>
# After the build completes, run the following command in the TCL Console of Vivado to create the project file and switch to project mode:<br/><code>save_project_as project_name project_dir</code><br/>In this example, "project_name" is the name you want to give the project file and "project_dir" is the directory in which you want to put the project.
# Set the compile order to automatic: <br/><code>set_property source_mgmt_mode All [current_project]</code>

In some cases, it may also be necessary to reset the output products for some of the IP. If you get an error message about a BD sub-design being not generated for the synthesis target, then navigate to the "IP Sources" tab in the Project Manager Sources window, then right-click on affected IP and select "Reset Output Products...", then click "Reset".

This project file can now be used independently of the normal FPGA build flow in UHD. It is up to the user to update this project file as the design changes since it will not be managed by the normal build flow in UHD.

=== My FPGA takes a long time to build. What can I do to make builds faster? ===

High-performance computers are recommended for FPGA builds since an FPGA build can take several hours.

The build process is divided into two steps, IP generation and the FPGA build.

==== IP Generation ====

This process can take several hours by default and is run automatically, if needed, when you build an FPGA target. Fortunately, this only needs to be done once for each USRP type and won't run again unless IP is changed.

You can speed up the IP generation by running this step with multiple jobs. For example:

$ make -j 4 X410_IP

This example will build four IP cores at a time. Note that this generally requires 4 times as much memory and needs at least 4 CPU cores. You can adjust the number of parallel jobs based on the amount of system memory and/or CPU cores you have available.

==== FPGA Build ====

Unfortunately, increasing the number of jobs does not speed up FPGA performance because there is only one Vivado instance for the FPGA build. Vivado, by default, will use multiple CPU cores, where possible, but this does not significantly improve build performance since many parts of the build are not easily parallelizable.

One way to shorten the build time is to reduce the size of the design. See above on how to reduce the size of your design.

In the case where you need to build multiple FPGA types, you can use the jobs option with <code>make</code> to build multiple FPGAs simultaneously, which can dramatically reduce the time required per build. Note that this requires a significant amount of memory and CPU cores and therefore is only recommended for systems that can handle such loads. An example is shown below for building two FPGA images in parallel:

$ make -j 2 X410_X4_200 X410_CG_400

It is also possible to open separate terminal instances and run one build in each instance to get the same effect. Do not build the same FPGA target in multiple instances, since multiple builds for the same target would conflict as they try to access and update the same files.

=== When I start an FPGA build or use rfnoc_image_builder, I get an error "setupenv.sh: source: not found" and the build fails. What happened? ===

In some Linux distributions (e.g. Ubuntu) <code>dash</code> is set as default shell which can cause FPGA builds to fail.

Below is an example of the error. Note, that your message may look somewhat different depending on UHD version and USRP target but the important lines are marked in bold.

rfnoc_image_builder -y e320_rfnoc_image_core_fft.yml -t E320_1G
Using FPGA directory /home/someuser/uhd/fpga
Selected device: e320
Build artifacts directory already exists (contents will be overwritten).
Launching build with the following settings:
* FPGA Directory: /home/someuser/uhd/fpga/usrp3/top/e320
* Build Artifacts Directory: /home/someuser/uhd/fpga/usrp3/top/e320/build-usrp_e320_fpga_1G
* Build Output Directory: /home/someuser/uhd/fpga/usrp3/top/e320/build
* Build IP Directory: /home/someuser/uhd/fpga/usrp3/top/e320/build-ip
Executing the following command: . ./setupenv.sh && make E320_1G BUILD_DIR=/home/someuser/uhd/fpga/usrp3/top/e320/build-usrp_e320_fpga_1G IMAGE_CORE_NAME=usrp_e320_fpga_1G
'''/bin/sh: 6: ./setupenv.sh: Bad substitution'''
'''/bin/sh: 8: ./setupenv.sh: declare: not found'''
/bin/sh: 9: ./setupenv.sh: PRODUCT_ID_MAP[E320]=zynq/xc7z045/ffg900/-3: not found
'''/bin/sh: 15: ./setupenv.sh: source: not found'''
Build finished with return code 127.

It is recommended to set the default shell to <code>bash</code> by running the following command in the terminal. When asked <code>Use dash as the default system shell (/bin/sh)?</code> choose <code><No></code>.

$ sudo dpkg-reconfigure dash

Confirm your default shell was changed to bash by running this command:

$ ll /bin/sh

You should see output similar to this:

lrwxrwxrwx 1 root root 4 Oct 10 2020 /bin/sh -> bash*

=== My FPGA build failed with a cryptic message or no message at all. How do I debug this? ===

When you build an FPGA target, a build directory is created in the FPGA's top directory that contains all the build outputs. Here you'll find the <code>build.log</code> file as well as report files and checkpoints. Not all log information is printed to the console during build, so make sure you check the <code>build.log</code> file for details. It may contain a useful error message that was not printed to the console.

Builds often fail when Vivado encounters an internal error or runs out of memory. For internal errors, the error message is typically not very helpful and is often due to a bug in Vivado. When Vivado runs out of memory, it may immediately terminate without giving any error message at all. Consider monitoring the memory usage during the FPGA build to see if you are approaching your system's limit.

If you have made changes to the design, try building an unmodified FPGA image from scratch to ensure the build process is working properly on your system. If this works, try adding your changes incrementally until the section of code causing the problem is identified.

Note that such errors are often beyond the control of Ettus Research and reaching out to Xilinx support is a better option if it is truly a Vivado issue.

=== I get a warning saying that an IP is locked, which results in errors later in the IP generation process. How do I resolve this? ===

Vivado "locks" IP, for example, when it needs to be updated for the running version of Vivado or FPGA device type. This is intended to force the user to fix the issue and to avoid building incompatible IP. Build failures related to IP being locked should never occur during a normal build. The IP version in the UHD repo always matches the Vivado version required for that release of UHD.

This can happen if you have used the wrong version of Vivado or do not have the correct Vivado patches installed. Refer to the <code>Generation 3 USRP Build Documentation</code> section of the [[UHD and USRP User Manual|UHD Manual] for the required version and patches. When you run the `source setenv.sh` step to setup your environment, the script will check to make sure you are using the correct version.

In some cases, reinstalling Vivado might be required.

Once the correct Vivado version and patches are installed, you will need to remove all build products (to remove any locked IP that was generated) and retry the build. For example:

$ source setupenv.sh # Setup environment and check the Vivado version
$ make cleanall # Remove any bad IP that was generated
$ make X410_X4_200 # Start the build process again

=== I see a "CRITICAL WARNING" in the build log. Is this expected? ===

There are many critical warnings that appear during the build process that can be safely ignored. For example, you may see the following:

CRITICAL WARNING: [Vivado 12-1790] Evaluation License Warning: This design contains one or more IP cores that use separately licensed features. If the design has been configured to make use of evaluation features, please note that these features will cease to function after a certain period of time. Please consult the core datasheet to determine whether the core which you have configured will be affected. Evaluation features should NOT be used in production systems.

The FPGA builds include IP for which the licenses are included with Vivado, but Vivado prints the warnings anyway. As long as you have a Vivado license and a bitstream was successfully generated, the IP should work as expected.

Writing the USRP File System Disk Image to a SD Card

2025-05-18T19:28:22Z

JonathonPendlum: Update dd flags to remove the need to run "sync" after the command completes

==Application Note Number==
'''AN-630'''


==Abstract==
This application note will provide step-by-step instructions on writing a file system disk image to a SD card using Linux.

==Required Tools==
* Computer with USB2/3 Interface
* UHD Installation
* microSD card to USB Adapter

==Downloading the File System Image==
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.

===N3xx===

$ sudo uhd_images_downloader -t sdimg -t n3xx

Example Output for UHD 3.15.0.0:

$ sudo uhd_images_downloader -t sdimg -t n3xx
[INFO] Images destination: /usr/local/share/uhd/images
[INFO] No inventory file found at /usr/local/share/uhd/images/inventory.json. Creating an empty one.
845962 kB / 845962 kB (100%) n3xx_common_sdimg_default-v3.15.0.0.zip
[INFO] Images download complete.

===E31x===

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]

$ sudo uhd_images_downloader -t sdimg -t e310 -t sg1

or
$ sudo uhd_images_downloader -t sdimg -t e310 -t sg3

Example Output for UHD 3.15.0.0 for E310 SG3:

$ sudo uhd_images_downloader -t sdimg -t e310 -t sg3
[INFO] Images destination: /usr/local/share/uhd/images
[INFO] No inventory file found at /usr/local/share/uhd/images/inventory.json. Creating an empty one.
561236 kB / 561236 kB (100%) e3xx_e310_sg3_sdimg_default-v3.15.0.0.zip
[INFO] Images download complete.

===E320===

$ sudo uhd_images_downloader -t sdimg -t e320

Example Output for UHD 3.15.0.0:

$ sudo uhd_images_downloader -t sdimg -t e320
[INFO] Images destination: /usr/local/share/uhd/images
[INFO] No inventory file found at /usr/local/share/uhd/images/inventory.json. Creating an empty one.
795674 kB / 795674 kB (100%) e3xx_e320_sdimg_default-v3.15.0.0.zip
[INFO] Images download complete.

==Identifying UHD Installation Prefix==

In the output of the <code>uhd_images_downloader</code> command above, the folder destination where the images are saved is printed out.

An alternative method to identify your installation prefix is to run the command:

$ uhd_config_info --install-prefix

Example Output:

Install prefix: /usr/local

The default folder location for FPGA and SD card images is:

<UHD_INSTALL_PREFIX>/share/uhd/images/

==Writing the File System Image with Linux==

===Identifying SD Card Mount Location===

Insert the microSD card into the host computer.

To identify the device where the microSD card is, run the command:

dmesg | tail

Example Output (partially truncated for readability):

[21265.575488] usb-storage 1-2:1.0: USB Mass Storage device detected
[21266.586983] scsi 0:0:0:0: Direct-Access Generic Mass-Storage 1.11 PQ: 0 ANSI: 2
[21266.588024] sd 0:0:0:0: Attached scsi generic sg0 type 0
[21267.299812] sd 0:0:0:0: [sdb] 31116288 512-byte logical blocks: (15.9 Gb/14.8 GiB)
[21267.302687] sdb: sdb1 sdb2 sdb3 sdb4

NOTE: In this specific example configuration, the SD card has been attached to <code>sdb</code>.

Another method to finding the device node the disk is attached at is to use the Linux utility <code>lsblk</code>:

Example Output:

$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sdb 8:16 1 14.9G 0 disk
├─sdb1 8:17 1 16M 0 part /media/user/boot
├─sdb2 8:18 1 1.9G 0 part /media/user/primary
├─sdb3 8:19 1 1.9G 0 part /media/user/secondary
└─sdb4 8:20 1 11G 0 part /media/user/data

===Unmount Auto-mounted Partitions===

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:

$ sudo umount /media/user/data
$ sudo umount /media/user/primary
$ sudo umount /media/user/secondary
$ sudo umount /media/user/boot

Running the command <code>lsblk</code> again will show these partitions have been unmounted:

Example Output:

$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sdb 8:16 1 14.9G 0 disk
├─sdb1 8:17 1 16M 0 part
├─sdb2 8:18 1 1.9G 0 part
├─sdb3 8:19 1 1.9G 0 part
└─sdb4 8:20 1 11G 0 part

===Writing the SD Card Image===

====Using dd to write the disk image====

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

NOTE: You must use a 16 Gb or larger SD card for the N3xx and E320 file system images.

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

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:

'''N3xx'''
<IMAGE>=/usr/local/share/uhd/images/usrp_n3xx_fs.sdimg

'''E320'''
<IMAGE>=/usr/local/share/uhd/images/usrp_e320_fs.sdimg

Write the disk image with the command:

$ sudo dd if=<IMAGE> of=<SD_CARD_DEV_NAME> bs=1M

This step of writing the disk image to the SD card can take several minutes to complete.

Example Output:

$ sudo dd if=/usr/local/share/uhd/images/usrp_<deivce>_fs.sdimg of=/dev/sdb bs=1M status=progress oflag=direct conv=fsync
15160+0 records in
15160+0 records out
15896412160 bytes (16 Gb, 15 GiB) copied, 1160.93 s, 13.7 MB/s

You can now remove the microSD card from your host computer and insert it into the USRP.

[[Category:Application Notes]]

Getting Started with DPDK and UHD

2025-03-17T14:02:42Z

JonathonPendlum: /* Dependencies */

== Application Note Number and Authors ==

'''AN-500''' by Nate Temple, Alex Williams, Wade Fife, Matt Prost, and Michael Dickens


==Overview==

This application note walks through the process to get started with the Data Plane Development Kit (DPDK) driver within UHD.

==Abstract==

Up until now, UHD's only support for networked devices was backed by the kernel's sockets implementation. Every call to <code>send()</code> or <code>recv()</code> would cause a context switch and invite the kernel's scheduler to replace our thread with something else. Because the typical scheduler is optimized to distribute CPU time fairly across multiple loads, the timing-critical threads might sporadically be hit with sleeping time, and the thread might be migrated off its current CPU and forced to run on another. The overhead and random latency spikes make it difficult to enable reliable real-time streaming at higher rates.

DPDK is a high-speed packet processing framework that enables a kernel bypass for network drivers. By putting the entire driver in user space, avoiding context switches, and pinning I/O threads to cores, UHD and DPDK combine to largely prevent the latency spikes induced by the scheduler. In addition, the overall overhead for packet processing lowers.

== Supported Devices ==

=== USRPs ===

DPDK is supported on the following USRP devices:

* E320
* N300 / N310
* N320 / N321
* X300 / X310
* X410
* X440

=== Host Network Cards ===

DPDK is supported on many Intel and Mellanox based 10Gb and 100Gb NICs and lots of other NICs. Below is a list of NICs Ettus Research has tested. For a full list of NICs supported by DPDK, please see the DPDK manual.

* Intel X520-DA1 (1x10Gb)
* Intel X520-DA2 (2x10Gb)
* Intel X710-DA2 (2x10Gb)
* Intel X710-DA4 (4x10Gb)
* Intel XL710-QDA2 (2x40Gb breakout to 4x10Gb)
* Intel E810-CQDA1 (1x100Gb and 1x4x10Gb)
* Intel E810-CQDA2 (1x100Gb and 2x4x10Gb; [https://edc.intel.com/content/www/us/en/design/products/ethernet/perf-tuning-guide-800-series-linux/%E2%80%8Bcheck-system-hardware-capabilities/ note that this NIC does not support 2x100Gb])
* Intel E810-2CQDA2 (1x100Gb and 2x4x10Gb; 2x100Gb with some work)
* Mellanox MCX4121A-ACAT ConnectX-4 Lx (2x10Gb)
* Mellanox MCX515A-CCAT ConnectX-5 EN (2x100Gb or 2x10Gb)
* Mellanox MCX516A-CCAT ConnectX-5 EN (2x100Gb or 2x10Gb)
* Mellanox MCX516A-CDAT ConnectX-5 Ex EN (2x100Gb or 2x10Gb)
* Mellanox MCX623106AN-CDAT ConnectX-6 Dx EN (2x100Gb or 2x10Gb)
* [https://www.ni.com/en-us/support/model.100-gb-ethernet-connectivity-kit.html NI Dual 100 Gigabit Ethernet PCIe Interface Kit (PN 788216-01)]

== References ==

* DPDK: https://www.dpdk.org/
** https://doc.dpdk.org/guides-17.11
** https://doc.dpdk.org/guides-18.11
** https://doc.dpdk.org/guides-19.11
** https://doc.dpdk.org/guides-20.11
** https://doc.dpdk.org/guides-21.11
** https://doc.dpdk.org/guides-22.11
** https://doc.dpdk.org/guides-23.11
** https://doc.dpdk.org/guides-24.11
* UHD Manual: https://files.ettus.com/manual/page_dpdk.html

== Dependencies ==

* UHD 3.x requires DPDK 17.11

* UHD 4.0 and 4.1 require DPDK 18.11

* UHD 4.2 to 4.7 can use any version of DPDK from 18.11 to 21.11

* UHD 4.8 can use any version of DPDK from 18.11 to 24.11

== Installing DPDK ==

We recommend installing DPDK via the system-provided installer; for example with Ubuntu:

sudo apt install dpdk dpdk-dev

While it is possible to install DPDK from source, we recommend using the system-provided install unless there is a very good reason to not do so. DPDK can be challenging to ''correctly'' build from source. If you require installing DPDK from source, the install guide for various versions is noted below:

* [https://doc.dpdk.org/guides-17.11/linux_gsg/build_dpdk.html DPDK 17.11]
* [https://doc.dpdk.org/guides-18.11/linux_gsg/build_dpdk.html DPDK 18.11]
* [https://doc.dpdk.org/guides-19.11/linux_gsg/build_dpdk.html DPDK 19.11]
* [https://doc.dpdk.org/guides-20.11/linux_gsg/build_dpdk.html DPDK 20.11]
* [https://doc.dpdk.org/guides-21.11/linux_gsg/build_dpdk.html DPDK 21.11]
* [https://doc.dpdk.org/guides-22.11/linux_gsg/build_dpdk.html DPDK 22.11]
* [https://doc.dpdk.org/guides-23.11/linux_gsg/build_dpdk.html DPDK 23.11]

DPDK releases come twice per year in April (version X.04) and November (version X.11). The first release is more of a beta while the second is more of a formal release. While either ''can'' be used with UHD, we recommend just the formal releases with version ending in 11.

== Installing UHD ==

Once the <code>dpdk</code> and <code>dpdk-dev</code> packages are installed, UHD will locate them during a build and you should see DPDK in the enabled components lists when running <code>cmake</code>.

NOTE that in general UHD installed from PPA or system packages ''does not'' include support for DPDK, and even if DPDK is installed alongside these UHD it will not be used. In order to get UHD with DPDK support, [https://kb.ettus.com/Building_and_Installing_the_USRP_Open-Source_Toolchain_(UHD_and_GNU_Radio)_on_Linux UHD generally has to be built from source].

== Enable hugepages ==

Edit your grub configuration file, <code>/etc/default/grub</code> and add the follow parameters to <code>GRUB_CMDLINE_LINUX_DEFAULT</code>:

iommu=pt intel_iommu=on hugepages=2048

On a vanilla Ubuntu system it should look like this:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash iommu=pt intel_iommu=on hugepages=2048"

Close <code>/etc/default/grub</code> and at the command prompt, update your grub configuration with the command:

sudo update-grub

For these settings to take effect, reboot your host machine.

== Preparing your UHD Configuration File ==

You must note the MAC addresses for your NICs before proceeding.

The MAC addresses for your NICs can be found by running the command:

ip a

You must then create a UHD configuration file.

For UHD 3 the location is <code>/root/.uhd/uhd.conf</code>.

sudo su
mkdir -p /root/.uhd
nano /root/.uhd/uhd.conf

For UHD 4 the location is <code>/root/.config/uhd.conf</code>.

sudo su
mkdir -p /root/.config
nano /root/.config/uhd.conf

=== UHD 3.x ===

An example <code>uhd.conf</code> file is listed below. Note that field names in UHD 3.x are slightly different from UHD 4.0.

You should update the following fields for your configuration from this example:

* Update the MAC address variables, <code>dpdk-mac</code>, to match your NIC

* Update the <code>dpdk-driver</code> if the location is different on your system. <code>/usr/lib/x86_64-linux-gnu/dpdk-17.11-drivers/</code> is the default location on Ubuntu 18.04.x when <code>dpdk</code> is installed via <code>apt</code>.

* Update the <code>dpdk-corelist</code> and <code>dpdk-io-cpu</code> fields. In this example, a two port NIC is used. There should be one core for the main <code>dpdk</code> thread (in this example <code>core #2</code>), and then separate cores assigned to each NIC (in this example <code>core #3</code> for the first port on the NIC, <code>core #4</code> for the second port on the NIC)

* Update the <code>dpdk-ipv4</code> fields to your desired IP range.
** <code>192.168.30.2</code>, <code>192.168.40.2</code> on a default X3xx system
** <code>192.168.10.2</code>, <code>192.168.20.2</code> on a default N3xx system
** <code>192.168.10.2</code> on a default E320 system

[use_dpdk=1]
dpdk-mtu=9000
dpdk-driver=/usr/lib/x86_64-linux-gnu/dpdk-17.11-drivers/
dpdk-corelist=2,3,4
dpdk-num-mbufs=4095
dpdk-mbufs-cache-size=315

[dpdk-mac=aa:bb:cc:dd:ee:f1]
dpdk-io-cpu = 3
dpdk-ipv4 = 192.168.10.1/24

[dpdk-mac=aa:bb:cc:dd:ee:f2]
dpdk-io-cpu = 4
dpdk-ipv4 = 192.168.20.1/24

'''Note:''' Additional information on the UHD configuration file can be found here: https://files.ettus.com/manual_archive/v3.15.0.0/html/page_dpdk.html#dpdk_nic_config

=== UHD 4.x ===

An example <code>uhd.conf</code> file is listed below. Note that the field names in UHD 4.x are slightly different from UHD 3.x.

You must verify and/or update the following fields for your configuration from this example:

* The MAC address variables, <code>dpdk_mac</code>, to match your NIC(s) link(s); note that the MAC address info ''must be lowercase''

* The <code>dpdk_driver</code> if the location is different on your system. <code>/usr/local/lib/</code> is the default location on when DPDK is built and installed from source.

* The <code>dpdk_corelist</code> and <code>dpdk_lcore</code> fields. In this example, a two port NIC and both links are used. There must be one core for the main <code>dpdk</code> thread (in this example <code>core #2</code> because it is not otherwise used in the file) and then separate cores assigned to each NIC link (in this example <code>core #3</code> for the one of the NIC links and <code>core #4</code> for the other NIC link).

* The <code>dpdk_ipv4</code> fields to your desired IP range(s).
** <code>192.168.30.2</code>, <code>192.168.40.2</code> on a default X3xx system
** <code>192.168.10.2</code>, <code>192.168.20.2</code> on a default N3xx system
** <code>192.168.10.2</code> on a default E320 system
** <code>192.168.10.2</code> and <code>192.168.20.2</code> on a default X4xx systems

[use_dpdk=1]
dpdk_mtu=9000
dpdk_driver=/usr/lib/x86_64-linux-gnu/dpdk/pmds-20.0/
dpdk_corelist=2,3,4
dpdk_num_mbufs=4096
dpdk_num_desc=4096
dpdk_mbuf_cache_size=315

[dpdk_mac=aa:bb:cc:dd:ee:f1]
dpdk_lcore=3
dpdk_ipv4=192.168.10.1/24

[dpdk_mac=aa:bb:cc:dd:ee:f2]
dpdk_lcore=4
dpdk_ipv4=192.168.20.1/24

'''Notes:'''
* Additional information on the [https://files.ettus.com/manual/page_dpdk.html#dpdk_nic_config UHD DPDK configuration file is in the UHD manual].
* The number of cores listed must be used exactly within the file.
* The number of NIC link(s) listed must exactly match those specified in the UHD instantiation args.
* A simple way to move between different DPDK configurations is to create different files and then symlink from the desired file to <code>uhd.conf</code>

== Additional Host Configuration for NIC Vendors ==

The process for this step is different for Intel and Mellanox NICs and is detailed in individual sections below.

=== Intel X520 / X710 ===

The Intel based NICs will use the <code>vfio-pci</code> driver which must be loaded:

sudo modprobe vfio-pci

Next, you will need to rebind the NIC to the <code>vfio-pci</code> drivers.

First, identify the PCI address your NIC is at:

dpdk-devbind --status

Note the PCI address that your NIC is connected to for the next step.

Before the next step, you will need to turn off the NIC first before doing the rebind.

In Ubuntu under <code>System</code> -> <code>Network</code> -> click the switches to <code>off</code> for the 10Gb ports, then run the <code>dpdk-devbind</code> commands:

'''Note:''' Your PCI address will likely be different than <code>02:00.0</code> as shown in the example below.

sudo dpdk-devbind --bind=vfio-pci 02:00.0
sudo dpdk-devbind --bind=vfio-pci 02:00.1

Now if you run <code>dpdk-devbind --status</code> again, you should see the NICs listed under DPDK devices

# dpdk-devbind --status

Network devices using DPDK-compatible driver
============================================
0000:02:00.0 '82599ES 10-Gigabit SFI/SFP+ Network Connection 10fb' drv=vfio-pci unused=ixgbe
0000:02:00.1 '82599ES 10-Gigabit SFI/SFP+ Network Connection 10fb' drv=vfio-pci unused=ixgbe

'''Note:''' More info can be found here on the rebinding process: https://doc.dpdk.org/guides-17.11/linux_gsg/linux_drivers.html#binding-and-unbinding-network-ports-to-from-the-kernel-modules

=== Mellanox NICs ===

The Mellanox NICs do not require rebinding using the <code>vfio-pci</code> driver. Mellanox provides additional drivers for DPDK.

Install and activate the Mellanox drivers:

sudo apt install librte-pmd-mlx5-17.11
sudo modprobe -a ib_uverbs mlx5_core mlx5_ib

For 18.11 you can download and install the latest Mellanox drivers from the mellanox website (https://www.mellanox.com/products/infiniband-drivers/linux/mlnx_ofed).

The MLX5 poll mode driver library (librte_pmd_mlx5) in DPDK provides support for Mellanox ConnextX-4 and ConnectX-5 cards. This driver must be enabled manually with the build option <code>CONFIG_RTE_LIBRTE_MLX5_PMD=y</code> when building DPDK.

== Running UHD Applications with DPDK ==

UHD based application (including GNU Radio flowgraphs) can now be ran using a DPDK transport by passing in the Device Argument: <code>use_dpdk=1</code>.

'''Important Note:''' In order for UHD to use DPDK, the UHD application *must* be ran as the <code>root</code> user. Using <code>sudo</code> will not work, you should switch to the <code>root</code> user by running <code>sudo su</code>.

For example, running the <code>benchmark_rate</code> utility:

<pre>
# cd /usr/local/lib/uhd/examples

# ./benchmark_rate --rx_rate 125e6 --rx_subdev "A:0 B:0" --rx_channels 0,1 --tx_rate 125e6 --tx_subdev "A:0 B:0" --tx_channels 0,1 --args "addr=192.168.10.2,second_addr=192.168.20.2,mgmt_addr=10.2.1.19,master_clock_rate=125e6,use_dpdk=1"

[INFO] [UHD] linux; GNU C++ version 7.3.0; Boost_106501; UHD_3.14.0.HEAD-0-gabf0db4e
EAL: Detected 8 lcore(s)
EAL: Some devices want iova as va but pa will be used because.. EAL: IOMMU does not support IOVA as VA
EAL: No free hugepages reported in hugepages-1048576kB
EAL: Probing VFIO support...
EAL: VFIO support initialized
EAL: PCI device 0000:02:00.0 on NUMA socket -1
EAL: Invalid NUMA socket, default to 0
EAL: probe driver: 8086:10fb net_ixgbe
EAL: using IOMMU type 1 (Type 1)
EAL: Ignore mapping IO port bar(2)
EAL: PCI device 0000:02:00.1 on NUMA socket -1
EAL: Invalid NUMA socket, default to 0
EAL: probe driver: 8086:10fb net_ixgbe
EAL: Ignore mapping IO port bar(2)
PMD: ixgbe_dev_link_status_print(): Port 0: Link Down
EAL: Port 0 MAC: aa bb cc dd ee f1
EAL: Port 0 UP: 1
PMD: ixgbe_dev_link_status_print(): Port 1: Link Down
EAL: Port 1 MAC: aa bb cc dd ee f2
EAL: Port 1 UP: 1
EAL: Init DONE!
EAL: Starting I/O threads!
USER2: Thread 1 started
[00:00:00.000003] Creating the usrp device with: addr=192.168.10.2,second_addr=192.168.20.2,mgmt_addr=10.2.1.19,master_clock_rate=125e6,use_dpdk=1...
[INFO] [MPMD] Initializing 1 device(s) in parallel with args: mgmt_addr=10.2.1.19,type=n3xx,product=n310,serial=313ABDA,claimed=False,addr=192.168.10.2,second_addr=192.168.20.2,master_clock_rate=125e6,use_dpdk=1
[INFO] [MPM.PeriphManager] init() called with device args 'product=n310,time_source=internal,master_clock_rate=125e6,clock_source=internal,use_dpdk=1,second_addr=192.168.20.2,mgmt_addr=10.2.1.19'.
[INFO] [0/DmaFIFO_0] Initializing block control (NOC ID: 0xF1F0D00000000004)
[INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1344 MB/s)
[INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1341 MB/s)
[INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1348 MB/s)
[INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1347 MB/s)
[INFO] [0/Radio_0] Initializing block control (NOC ID: 0x12AD100000011312)
[INFO] [0/Radio_1] Initializing block control (NOC ID: 0x12AD100000011312)
[INFO] [0/DDC_0] Initializing block control (NOC ID: 0xDDC0000000000000)
[INFO] [0/DDC_1] Initializing block control (NOC ID: 0xDDC0000000000000)
[INFO] [0/DUC_0] Initializing block control (NOC ID: 0xD0C0000000000002)
[INFO] [0/DUC_1] Initializing block control (NOC ID: 0xD0C0000000000002)
Using Device: Single USRP:
Device: N300-Series Device
Mboard 0: ni-n3xx-313ABDA
RX Channel: 0
RX DSP: 0
RX Dboard: A
RX Subdev: Magnesium
RX Channel: 1
RX DSP: 0
RX Dboard: B
RX Subdev: Magnesium
TX Channel: 0
TX DSP: 0
TX Dboard: A
TX Subdev: Magnesium
TX Channel: 1
TX DSP: 0
TX Dboard: B
TX Subdev: Magnesium

[00:00:03.728707] Setting device timestamp to 0...
[INFO] [MULTI_USRP] 1) catch time transition at pps edge
[INFO] [MULTI_USRP] 2) set times next pps (synchronously)
[00:00:05.331920] Testing receive rate 125.000000 Msps on 2 channels
[00:00:05.610789] Testing transmit rate 125.000000 Msps on 2 channels
[00:00:15.878071] Benchmark complete.

Benchmark rate summary:
Num received samples: 2557247854
Num dropped samples: 0
Num overruns detected: 0
Num transmitted samples: 2504266704
Num sequence errors (Tx): 0
Num sequence errors (Rx): 0
Num underruns detected: 0
Num late commands: 0
Num timeouts (Tx): 0
Num timeouts (Rx): 0

Done!
</pre>

== Tuning Notes ==

=== General Host Performance Tuning App Note ===

Perform the [https://kb.ettus.com/USRP_Host_Performance_Tuning_Tips_and_Tricks general host performance tuning tips and tricks].

=== Increasing <code>num_recv_frames</code> ===

If you experience <code>Overflows</code> at higher data rates, adding the device argument <code>num_recv_frames=512</code> can help.

=== Full Rate Streaming (UHD 3.x only) ===

If you're streaming data at the full master clock rate, and there is no interpolation or decimation being performed on the FPGA, you can skip the DUC and DDC blocks within the FPGA with the following parameters:

skip_ddc=1
skip_duc=1

=== Full Rate on X3xx ===

If you're streaming two transmit channels at full rate (200e6) on the X3xx platform, you should additionally set the following device arg:

enable_tx_dual_eth=1

=== Isolate Cores/CPUs ===

Isolating the cores that are used for DPDK can improve performance. This can be done by adding the <code>isolcpus</code> parameter to your <code>/etc/default/grub</code> file in the <code>GRUB_CMDLINE_LINUX_DEFAULT=""</code> (the "<code>GRUB_CONFIG</code>"). For example, to isolate cores 2 through and including 4, add this entry:

isolcpus=2-4

NOTE: After saving the <code>GRUB_CONFIG</code> file, execute <code>sudo update-grub</code> and then reboot the computer for the changes to take effect. It is OK to isolate core used by DPDK via this method.

=== Disable System Interrupts on Cores/CPUs ===

Disabling system interrupts can improve the jitter and performance generally by 1-3%. This can be done by adding the parameters <code>nohz_full</code> and <code>rcu_nocbs</code> to your <code>GRUB_CONFIG</code>. For example, to disable system interrupts on cores 2 through and including 4, add this entry:

nohz_full=2-4 rcu_nocbs=2-4

NOTE: After saving the <code>GRUB_CONFIG</code> file, execute <code>sudo update-grub</code> and then reboot the computer for the changes to take effect. It is OK to isolate core used by DPDK via this method.

=== Streaming on Multiple Channels using 1 Thread Per Stream ===

If you're streaming on multiple channels simultaneously, you can create multiple streamer objects on separate threads. This can be accomplished with the <code>benchmark_rate</code> example by using the parameter <code>--multi_streamer</code>.

=== Elevated Streaming Thread Priority ===

In UHD 4, streaming thread priorities can be elevated with the <code>uhd::set_thread_priority_safe()</code> function call. This can be accomplished with the <code>benchmark_rate</code> example by using parameter <code>--priority high</code>. Note that if the [https://kb.ettus.com/USRP_Host_Performance_Tuning_Tips_and_Tricks#Thread_Priority_Scheduling Thread Schedule Priority] has not been enabled for the current user then this parameter requires <code>sudo</code> to work.

=== Extra <code>nice</code> Priority ===

Beyond elevating streaming thread priority, one can also increase the [https://www.man7.org/linux/man-pages/man1/nice.1.html <code>nice</code> priority level] to maximum to increase the amount of CPU time for the process and its thread by prepending the following to the command being issued:

sudo nice -n -20

=== Limit Execution CPUs/Cores ===

With Linux one can limit the cores being used by the threads in a process via a [https://man7.org/linux/man-pages/man1/taskset.1.html <code>taskset</code>] prepended to a command being executed. When combining with the other techniques listed here, one can fairly well constrain a process and its thread to specific cores and give them maximum CPU time. Note that when using DPDK the MAC cores specified in <code>uhd.conf</code> will already be included as part of the <code>taskset</code> (but those cores will not be isolated nor have system interrupts disabled on them unless using that setting as noted above); it generally won't hurt to include the DPDK cores as part of the overall <code>taskset</code> but it's not required. For example, to limit process/thread execution to cores 2 through and including 4, one would prepend the following (note that <code>sudo</code> is ''not'' required):

taskset -c "2-4"

NOTE: For best performance do ''not'' include the cores used by DPDK in the <code>dpdk_corelist</code> argument in the <code>taskset</code>.

=== Stopping Extraneous Processes ===

The Linux kernel spawns a number of processes and threads that spend most of their time sleeping; one cannot stop these processes/threads. That said, in a typical Linux install (for example Ubuntu) there will be a graphical desktop (e.g., <code>gdm</code>) and various daemons started up by user request (e.g., <code>containerd</code>, <code>docker</code>, <code>snapd</code>). Most of these daemons can be controlled by <code>systemctl</code>; some must be manually quit. Any process that runs regularly stands a chance of interrupting the UHD and DPDK threads, and thus stopping, quitting, or disabling those processes can increase performance. For example, the following commands stop various daemons that execute regularly on Ubuntu; these need to be executed with <code>sudo</code> and some might not exist on your specific system and for these the command will do nothing so it's OK to run it:

systemctl stop containerd containerd.socket
systemctl stop docker docker.socket
systemctl stop dbus dbus.socket
systemctl stop snapd snapd.socket
systemctl stop udev systemd-udevd-control.socket systemd-udevd-kernel.socket

The following command stops the main Ubuntu desktop GUI, so running it will render the system accessible only via networking (e.g., <code>ssh</code>), so make sure network access is enabled before executing this command:

systemctl stop gdm

=== Disable Hyper-threading ===

In some applications which require the highest possible CPU performance per core, disabling hyper-threading can provide roughly a 10% increase in core performance, at the cost of having fewer core threads. Hyper-threading is disabled within the BIOS and how to do this varies by motherboard manufacturer. With other techniques listed here, disabling hyper-threading should only be done as a last resort to eek absolute maximum performance from the CPU.

=== Additional Tuning Notes from Intel ===

* Performance report from Intel on DPDK 17.11: https://fast.dpdk.org/doc/perf/DPDK_17_11_Intel_NIC_performance_report.pdf
* How to get best performance with NICs on Intel platforms: https://doc.dpdk.org/guides/linux_gsg/nic_perf_intel_platform.html

== Known Issues / Troubleshooting ==

=== Regular Overflows on multi-CPU Systems ===

On Multi-CPU systems each CPU is a NUMA node. The NUMA node contains all of the cores on the CPU. For best performance when using CPU/core isolation ("isocpus" per AAA above) make sure that all of the cores are in the same NUMA node.

=== Underruns Every Second with DPDK + Ubuntu ===

With Linux kernels 5.10 and beyond, we have observed periodic underruns on systems that otherwise have no issues. These Linux kernel versions are the default for Ubuntu 20.04.3 LTS and later. The underrun issue is due to the <code>RT_RUNTIME_SHARE</code> feature being disabled by default in these versions of the Linux kernel (shown as <code>NO_RT_RUNTIME_SHARE</code>). The following procedure can be used to enable this feature. This process was tested on Linux kernel version 5.13; the procedure may be slightly different on other kernel versions. To determine the Linux kernel version of your system, in a terminal issue the command <code>uname -r</code>.

<pre>
$ sudo -s
$ cd /sys/kernel/debug/sched
$ cat features | tr ' ' '\n' | grep RUNTIME_SHARE
NO_RT_RUNTIME_SHARE
$ echo RT_RUNTIME_SHARE > features
$ cat features | tr ' ' '\n' | grep RUNTIME_SHARE
RT_RUNTIME_SHARE
</pre>

[[Category:Application Notes]]

RFNoC 4 Migration Guide

2024-10-28T15:02:40Z

JonathonPendlum: Update Prerequisites section to UHD 4.6

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

=Prerequisites=

===Dependencies (Ubuntu 20.04 & 22.04)===
sudo apt-get install autoconf automake build-essential cmake cpufrequtils doxygen ethtool \
g++ git inetutils-tools libboost-all-dev libusb-1.0-0 libusb-1.0-0-dev libudev-dev \
libspdlog-dev doxygen swig python3-docutils python3-mako python3-numpy python3-requests \
python3-ruamel.yaml python3-setuptools cmake build-essential git g++ libgmp-dev swig \
python3-sphinx python3-lxml doxygen libfftw3-dev libsdl1.2-dev libgsl-dev libqwt-qt5-dev \
libqt5opengl5-dev python3-pyqt5 liblog4cpp5-dev libzmq3-dev python3-yaml python3-click \
python3-click-plugins python3-zmq python3-scipy python3-gi python3-gi-cairo \
gir1.2-gtk-3.0 libcodec2-dev libgsm1-dev pybind11-dev python3-matplotlib libsndfile1-dev \
python3-jsonschema python3-pygccxml libtinfo5 libncurses5

===Vivado 2021.1 Design Edition===

Please refer to the dependencies section on the [https://files.ettus.com/manual_archive/v4.6.0.0/html/md_usrp3_build_instructions.html FPGA build page] in UHD's manual.

''Note 1: Make sure to install [https://support.xilinx.com/s/article/76780?language=en_US AR76780 Patch for Vivado 2021.1]''

''Note 2: The dependencies step above includes installing libtinfo5 libncurses5, which is a workaround for getting Vivado 2021.1 to run on Ubuntu 20.04 & 22.04''

===UHD 4.6===
git clone --branch UHD-4.6 https://github.com/ettusresearch/uhd.git uhd
mkdir uhd/host/build; cd uhd/host/build
cmake ..
make
sudo make install

===GNU Radio 3.8===
'' Note: If your design does not use GNU Radio, then installing GNU Radio and gr-ettus is not required ''

git clone --branch maint-3.8 --recursive https://github.com/gnuradio/gnuradio.git gnuradio
mkdir gnuradio/build; cd gnuradio/build;
cmake ..
make
sudo make install

You can also reference the [https://wiki.gnuradio.org/index.php/UbuntuInstall GNU Radio Build Instructions] for more detailed information.

===gr-ettus===
git clone --branch maint-3.8-uhd4.0 https://github.com/ettusresearch/gr-ettus.git gr-ettus
mkdir gr-ettus/build; cd gr-ettus/build;
cmake -DENABLE_QT=True ..
make
sudo make install

=RFNoC Block Development Environment=

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.

===Migrating a GNU Radio Out-of-Tree Module===

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.

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.

====Creating a RFNoC Block with rfnocmodtool====

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.

rfnocmodtool newmod
Name of the new module: '''example'''

cd rfnoc-tutorial
rfnocmodtool add
Enter name of block/code (without module name prefix): '''gain'''
Enter valid argument list, including default arguments: ''(leave blank)''
Add Python QA code? [y/N] '''N'''
Add C++ QA code? [y/N] '''N'''
Block NoC ID (Hexadecimal): ''(Enter Noc ID of your block)''
Skip Block Controllers Generation? [UHD block ctrl files] [y/N] '''N'''
Skip Block interface files Generation? [GRC block ctrl files] [y/N] '''N'''

''Note: Noc IDs have been reduced from 64-bits in RFNoC 3 to 32-bits in RFNoC 4''

The following are the relevant files that need to be updated when migrating your RFNoC Block.

rfnoc-example/
grc/
example_gain.block.yml – RFNoC Block GNU Radio Companion YAML file
examples/
gain.grc – Example flowgraph using gain RFNoC Block
include/tutorial/
gain.h – GNU Radio block C++ header
gain_block_ctrl.hpp – RFNoC Block Controller C++ header
lib/
gain_impl.cc – GNU Radio block C++ source
gain_impl.h – GNU Radio block C++ header
gain_block_ctrl_impl.cpp – RFNoC Block Controller C++ source
rfnoc/blocks/
gain.yml – RFNoC Block Description YAML file
rfnoc/fpga/rfnoc_block_gain
noc_shell_gain.v – RFNoC Block Noc Shell Verilog Source
rfnoc_block_gain.v – RFNoC Block Verilog Source
rfnoc_block_gain_tb.v – RFNoC Block Testbench
rfnoc/icores
gain_x310_rfnoc_image_core.yml – Image Core YAML file with gain block

====Building OOT module====

cd rfnoc-tutorial
mkdir build; cd build
cmake -DUHD_FPGA_DIR=''(path to uhd/fpga directory)'' ..
make
sudo make install

====Running a testbench====
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:

cd rfnoc-tutorial/build
make rfnoc_block_gain_tb

====Building a FPGA image====
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:

cd rfnoc-tutorial/build
make gain_x310_rfnoc_image_core

===Migrating a Standalone UHD C++ Application===

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.

The following are the relevant files that need to be updated when migrating your RFNoC Block.

rfnoc-example/
apps/
init_gain_block.cpp – Example C++ application testing gain block
blocks/
gain.yml – RFNoC Block Description YAML file
fpga/rfnoc_block_gain
noc_shell_gain.v – RFNoC Block Noc Shell Verilog Source
rfnoc_block_gain.v – RFNoC Block Verilog Source
rfnoc_block_gain_tb.v – RFNoC Block Testbench
icores/
x310_rfnoc_image_core.yml – Example Image Core YAML file
include/rfnoc/example
gain_block_control.hpp – RFNoC Block Controller C++ header
lib/
gain_block_control.cpp – RFNoC Block Controller C++ source

====Building rfnoc-example====

cd rfnoc-example
mkdir build; cd build
cmake ..
make
sudo make install

====Running a testbench====
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:

cd rfnoc-example/build
make rfnoc_block_gain_tb

====Building a FPGA image====
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:

cd rfnoc-tutorial/build
make gain_x310_rfnoc_image_core

=Example RFNoC 3 to RFNoC 4 Block Migration=

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.

=UHD Software Migration=

Migration reference files for this section from the Gain RFNoC Block example:

{| class="wikitable"
! Description || RFNoC 3 Files || RFNoC 4 Files
|-
| Block Description || rfnoc/blocks/gain.xml || lib/gain_block_ctrl_impl.cpp <br>include/example/gain_block_ctrl.hpp
|-
| Block Controller || rfnoc/blocks/gain.yml || lib/gain_block_ctrl_impl.cpp <br>include/example/gain_block_ctrl.hpp
|}

''Note: Files are relative to the rfnoc-example directory in the respective rfnoc3 and rfnoc4 directories''

===Noc Script XML Replaced by Block Description YAML===

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.

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:

{| class="wikitable"
! Item || Noc Script XML || Block Descript YAML || RFNoC 4 Notes
|-
| Block Name
||
<name>gain</name>
||
module_name: gain
||
|-
| Noc ID
||
<id>B160000000000000</id>
||
noc_id: 0xB16
||
Noc ID are limited to 32-bits
|-
| Registers
||
<registers>
<setreg>
<name>GAIN</name>
<address>128</address>
</setreg>
</registers>
||
N/A
||
Registers must be defined in the Block Controller
|-
| Arguments
||
<args>
<arg>
<name>gain</name>
<type>int</type>
...
</arg>
</args>
||
N/A
||
Args are implemented with properties in the Block Controller
|-
| Data Ports
||
<ports>
<sink>
<name>in</name>
</sink>
<source>
<name>out</name>
</source>
</ports>
||
data:
fpga_iface: axis_pyld_ctxt
clk_domain: rfnoc_chdr
inputs:
in:
...
outputs:
out:
...
||
|-
| Control Ports
||
N/A
||
control:
sw_iface: nocscript
fpga_iface: ctrlport
interface_direction: slave
...
||
|-
| Clocking
||
N/A
||
clocks:
- name: rfnoc_chdr
freq: "[]"
- name: rfnoc_ctrl
freq: "[]"
||
|}

''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].''

===RFNoC API Changes===

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:

{| class="wikitable"
! RFNoC 3 || RFNoC 4 || RFNoC 4 Notes
|-
|
usrp = uhd::device3::make(...)
||
graph = uhd::rfnoc::rfnoc_graph::make()
||
No longer need to create a device3 object
|-
|
usrp->get_block_ctrl(...)
||
graph->get_block(...)
||
Rename
|-
|
N/A
||
graph->enumerate_static_connections()
||
Used to check static connections, for example the DDC and DUC blocks are usually statically connected to the radio block
|-
|
usrp->get_tx_streamer(...)
||
graph->create_tx_streamer(...)
||
Rename
|-
|
usrp->get_rx_streamer(...)
||
graph->create_rx_streamer(...)
||
Rename
|-
|
N/A
||
graph->commit()
||
Commit graph and run initial checks
|-
|
sr_write(...)
||
regs().poke32(...)
||
Address increments by 4
|-
|
sr_read32(...)
||
regs().peek32(...)
||
Address increments by 4
|-
|
sr_read64(...)
||
regs().poke64(...)
||
Address increments by 8
|-
|
set_arg(...)
||
set_property(...)
||
Block args replaced with block properties concept
|-
|
get_arg(...)
||
get_property(...)
||
Block args replaced with block properties concept
|}

===Block Properties===

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.

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.

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:

====RFNoC 3 Noc Script XML snippet====
<registers>
<setreg>
<name>GAIN</name>
<address>128</address>
</setreg>
</registers>

<args>
<arg>
<name>gain</name>
<type>int</type>
<value>1</value>
<check>GE($gain, 0) AND LE($gain, 32767)</check>
<check_message>Gain must be in the range [0, 32767]</check_message>
<action>SR_WRITE("GAIN", $gain)</action>
</arg>
</args>

====RFNoC 4 Block Controller Class====

// <registers>
// <setreg>
// <name>GAIN</name>
// <address>128</address>
// </setreg>
// </registers>
// Note: In RFNoC 4, register addresses can start at address 0 instead of address 128 as in RFNoC 3.
const uint32_t gain_block_ctrl::REG_GAIN_ADDR = 0;
const uint32_t gain_block_ctrl::REG_GAIN_DEFAULT = 1;

class gain_block_ctrl_impl : public gain_block_ctrl
{
public:
RFNOC_BLOCK_CONSTRUCTOR(gain_block_ctrl)
{
_register_props();
}
private:
void _register_props()
{
register_property(&_user_reg, [this]() {
int user_reg = this->_user_reg.get();
// <check>GE($gain, 0) AND LE($gain, 32767)</check>
// <check_message>Gain must be in the range [0, 32767]</check_message>
if (user_reg < 0 || user_reg > 32767) {
throw uhd::value_error("Size value must be in [0,32767]");
}
// <action>SR_WRITE("GAIN", $gain)</action>
this->regs().poke32(REG_USER_ADDR, user_reg);
});
}

// <name>gain</name>
// <type>int</type>
// <value>1</value>
property_t<int> _user_reg{"gain", REG_USER_DEFAULT, {res_source_info::USER}};
}

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

=FPGA Migration=

Migration reference files for this section from the Gain RFNoC Block example:

{| class="wikitable"
! Description || RFNoC 3 Files || RFNoC 4 Files
|-
| Block Verilog Code || rfnoc/fpga-src/noc_block_gain.v || rfnoc/fpga/rfnoc_block_gain/rfnoc_block_gain.v
|-
| Block Noc Shell || N/A || rfnoc/fpga/rfnoc_block_gain/noc_shell_gain.v
|-
| Block Testbnech || rfnoc/testbench/noc_block_gain/noc_block_gain_tb.sv || rfnoc/fpga/rfnoc_block_gain/rfnoc_block_gain_tb.sv
|-
| Image Core || N/A || rfnoc/icores/gain_x310_rfnoc_image_core.yml
|}

''Note: Files are relative to the rfnoc-example directory in the respective rfnoc3 and rfnoc4 directories''

===Noc Shell Changes===

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.

====Generating a Custom Noc Shell====

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.

The argument “-c” is used to provide the YAML file location. “-d” provides the output destination directory.

''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!''

Example usage:
rfnoc_create_verilog.py -c ./rfnoc-example/rfnoc/blocks/gain.yml -d ./output/

====Changing Noc ID without using rfnoc_create_verilog====

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.

====Goodbye AXI Wrapper====

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.

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.

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

===Settings Bus replaced by CtrlPort===

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

{| class="wikitable"
! Settings Bus (RFNoC 3) || CtrlPort (RFNoC 4) || RFNoC 4 Notes
|-
| set_stb || ctrlport_reg_wr || Write strobe
|-
| 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)
|-
| set_data || ctrlport_req_data || Write data
|-
| N/A || ctrlport_req_rd || Read strobe equivalent of ctrlport_req_wr
|-
| rb_addr || N/A || CtrlPort uses ctrlport_req_addr for both '''read and write''' addresses
|-
| rb_data || ctrlport_resp_data || Read data, 32-bits instead of 64-bits
|-
| rb_stb || N/A || CtrlPort requires ack strobe for '''reads and writes'''
|}

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:

// Note: Register addresses increment by 4
localparam REG_USER_ADDR = 0; // Address for example user register
localparam REG_USER_DEFAULT = 0; // Default value for user register

reg [31:0] reg_user = REG_USER_DEFAULT;

always @(posedge ctrlport_clk) begin
if (ctrlport_rst) begin
reg_user = REG_USER_DEFAULT;
end else begin
// Default assignment
m_ctrlport_resp_ack <= 0;

// Read user register
if (m_ctrlport_req_rd) begin // Read request
case (m_ctrlport_req_addr)
REG_USER_ADDR: begin
m_ctrlport_resp_ack <= 1;
m_ctrlport_resp_data <= reg_user;
end
endcase
end

// Write user register
if (m_ctrlport_req_wr) begin // Write requst
case (m_ctrlport_req_addr)
REG_USER_ADDR: begin
m_ctrlport_resp_ack <= 1;
reg_user <= m_ctrlport_req_data[31:0];
end
endcase
end
end
end

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

===Testbench Infrastructure===

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.

{| class="wikitable"
! Operation || RFNoC 3 || RFNoC 4
|-
| Setup RFNoC
||
`RFNOC_SIM_INIT(...)
`RFNOC_ADD_BLOCK(...)
`RFNOC_CONNECT(...)
||
RfnocBlockCtrlBfm #(...) blk_ctrl = new(...);
blk_ctrl.connect_master_data_port(...)
blk_ctrl.connect_slave_data_port(...)
''Note: Instantiate one Block Controller BFM per RFNoC Block''
|-
| Setup Test Cases
||
`TEST_CASE_START(...)
`TEST_CASE_DONE(...)
||
test.start_test(...)
test.end_test()
|-
| Register Read
||
tb_streamer.read_reg(...)
||
blk_ctrl.reg_read(...)
|-
| Register Write
||
tb_streamer.write_reg(...)
||
blk_ctrl.reg_write(...)
|-
| Send Data / Samples
||
tb_streamer.send(...)
||
blk_ctrl.send_items(...)
|-
| Receive Data / Samples
||
tb_streamer.recv(...)
||
blk_ctrl.recv_items(...)
|}

===Building FPGA images using Image Core YAML Files===

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.

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

=GNU Radio Software Migration=

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.

Migration reference files for this section from the Gain RFNoC Block example:

{| class="wikitable"
! Description || RFNoC 3 Files || RFNoC 4 Files
|-
| 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
|-
| GRC Block Description || grc/gain.xml || grc/gain.yml
|-
| Example GRC Flowgraph || examples/gain.grc || examples/gain.grc
|}

''Note: Files are relative to the rfnoc-example directory in the respective rfnoc3 and rfnoc4 directories''

===RX & TX Streamer Blocks===

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.

[[File:rx_tx_streamer.png|border]]

===Setting RFNoC Block Properties Directly in GNU Radio===

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.

{| class="wikitable"
! Property Type || Set Property || Get Property
|-
| Integer || set_int_property(...) || get_int_property(...)
|-
| Double || set_double_property(...) || get_double_property(...)
|-
| Bool || set_bool_property(...) || get_bool_property(...)
|-
| String || set_string_property(...) || get_string_property(...)
|-
|}

'''Example code for GNU Radio Companion YAML Block Description file'''
templates:
imports: |-
import example
make: |-
example.gain(
self.rfnoc_graph,
uhd.device_addr(${block_args}),
${device_select},
${instance_select})
self.${id}.set_int_property('gain', ${gain})
callbacks:
- set_int_property('gain', ${gain})

B200/B210/B200mini/B205mini/B206mini

2024-04-24T16:09:29Z

JonathonPendlum: Fix incorrect input power level

== Device Overview ==
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.

== Key Features==
=== B200===
{|
|style="vertical-align:top"|
* Xilinx Spartan 6 XC6SLX75 FPGA
* Analog Devices AD9364 RFIC direct-conversion transceiver
* Frequency range: 70 MHz - 6 GHz
* Up to 56 MHz of instantaneous bandwidth
* Full duplex, SISO (1 Tx & 1 Rx)
* Fast and convenient bus-powered USB 3.0 connectivity
* Optional Board Mounted GPSDO
|[[File:Product b200.png|250px|center]]
|}

=== B210===
{|
|style="vertical-align:top"|
* Xilinx Spartan 6 XC6SLX150 FPGA
* Analog Devices AD9361 RFIC direct-conversion transceiver
* Frequency range: 70 MHz - 6 GHz
* Up to 56 MHz of instantaneous bandwidth (61.44MS/s quadrature)
* Full duplex, MIMO (2 Tx & 2 Rx)
* Fast and convenient bus-powered USB 3.0 connectivity
* Optional Board Mounted GPSDO
|[[File:Product b210.png|250px|center]]
|}

=== B200mini===
{|
|style="vertical-align:top"|
* Xilinx Spartan-6 XC6SLX75 FPGA
* Analog Devices AD9364 RFIC direct-conversion transceiver
* Frequency range: 70 MHz - 6 GHz
* Up to 56 MHz of instantaneous bandwidth
* Full duplex, SISO (1 Tx & 1 Rx)
* Fast and convenient bus-powered USB 3.0 connectivity
|[[File:Product b200 mini.png|250px|center]]
|}

=== B200mini-i===
{|
|style="vertical-align:top"|
* Industrial-grade Xilinx Spartan-6 XC6SLX75 FPGA
* Analog Devices AD9364 RFIC direct-conversion transceiver
* Frequency range: 70 MHz - 6 GHz
* Up to 56 MHz of instantaneous bandwidth
* Full duplex, SISO (1 Tx & 1 Rx)
* Fast and convenient bus-powered USB 3.0 connectivity
|[[File:Product b200 mini i.png|250px|center]]
|}

=== B205mini-i===
{|
|style="vertical-align:top"|
* Industrial-grade Xilinx Spartan-6 XC6SLX150 FPGA
* Analog Devices AD9364 RFIC direct-conversion transceiver
* Frequency range: 70 MHz - 6 GHz
* Up to 56 MHz of instantaneous bandwidth
* Full duplex, SISO (1 Tx & 1 Rx)
* Fast and convenient bus-powered USB 3.0 connectivity
|[[File:Product b200 mini i.png|250px|center]]
|}

==Frontend Specifications==
===Tuning===

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.

===Gains===
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.

===Bandwidths===
The analog frontend has a seamlessly adjustable bandwidth of 200 kHz to 56 MHz.

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.

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

The property to control the analog RX bandwidth is bandwidth/value.

UHD will not allow you to set bandwidths larger than your current master clock rate.

==RF Specifications==
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.

===RF Performance===
* SSB/LO Suppression -35/50 dBc
* Phase Noise 3.5 GHz 1.0 deg RMS
* Phase Noise 6 GHz 1.5 deg RMS
* Power Output >10dBm
* IIP3 (@ typ NF) -20dBm
* Typical Noise Figure <8dB
* Maximum Input Power: -15 dBm

===Input/Output Impedance===
All RF Ports are matched to 50 Ohm with -10dB or better return loss generally. Detailed test is pending.

===Input Power Levels===
* The maximum input power for the B200/B210/B200mini/B205mini is -15 dBm.

===RF Performance Data===
====B200mini / B205mini====
* [[Media:B200mini B205 RF Performance Data 20160119.pdf]]

====B200 / B210====
* [[Media:B200 RF Performance.pdf]]

==Hardware Specifications==
* Ettus Research recommends to always use the latest stable version of UHD

=== B200===
* Current Hardware Revision: 6
* Minimum version of UHD required: 3.8.4
* B200 Rev 5 (AD9364-based board) requires minimum UHD 3.8.4

=== B210===
* Current Hardware Revision: 5
* Minimum version of UHD required: 3.6.0

=== B200mini===
* Current Hardware Revision: 2
* Minimum version of UHD required: 3.9.0

=== B200mini-i===
* Current Hardware Revision: 2
* Minimum version of UHD required: 3.9.0

=== B205mini-i===
* Current Hardware Revision: 1
* Minimum version of UHD required: 3.9.2

==Physical Specifications==
===Dimensions===
* B200mini/B205mini 5.0 x 8.4 cm
* B200/B210 9.7 x 15.5 x 1.5 cm

===Weight===
* B200mini 24.0 g
* B200/B210 350 g

===Drawings===
====B200mini====
* [[Media:B200mini_drawing.png| Board only]]
* [[Media:cu usrp-b200mini.pdf| B20xmini Enclosure]]

====B200====
* [[Media:cu ettus b200 cca.pdf| Board only]]

====B210====
* [[Media:cu ettus b210 cca.pdf| Board only]]

====B200/B210 Enclosure====
* [[Media:cu ettus-b2xx-full-enclosure.pdf|Enclosure]]

===CAD/STP Models===
====B200mini====
* [[Media:B200mini.stp.tar.gz| B200mini with Enclosure]]
* [[Media:B200mini enclosure-only.stp.tar.gz| Enclosure only]]
* [[Media:cu ettus b200mini cca.stp.tar.gz| Board only ]]

====B20xmini-i====
* [[Media:b20xmini-i._thermal_insert.stp.tar.gz| B20xmini-i Thermal Insert]]

====B200====
* [[Media:cu ettus b200 cca.stp.tar.gz| Board only]]

====B210====
* [[Media:cu ettus b210 cca.stp.gz| Board only]]

====B200/B210 Enclosure====
* [[Media:cu ettus-b200-b210-case.zip|Enclosure]]

==Environmental Specifications==
===Operating Temperature Range===
* B200 / B210: 25 °C
* B200mini - Board Only: 0 - 40 °C
* B200mini - With Enclosure: -20 - 60°C
* B200mini-i / B205mini-i - Board Only: 0 - 45 °C
* B200mini-i / B205mini-i - With I-Grade Enclosure: -40 - 75°C

===Operating Humidity Range===
* 10% to 90% non-condensing

==Schematics==
===B200mini/B200mini-i/B205mini-i===
[http://files.ettus.com/schematics/b200mini/b200mini.pdf B200mini/B200mini-i/B205mini-i Schematics]

===B200/B210===
[http://files.ettus.com/schematics/b200/b210.pdf B200/B210 Schematics]

==Key Component Datasheets==
{| class="wikitable" style="width:80%"
!Part Number
!Description
!Schematic ID (Page)

|-
|[https://www.minicircuits.com/pdfs/TCM1-63AX+.pdf Mini-Circuits TCM1-63AX+]
|Transformer
|T1 (1,3); T2 (1,3)
|-

|-
|[http://www.analog.com/en/products/rf-microwave/integrated-transceivers-transmitters-receivers/wideband-transceivers-ic/ad9364.html#product-overview Analog Devices AD9364]
|RF Transceiver
|U1 (2)
|-
|[http://www.analog.com/en/products/rf-microwave/integrated-transceivers-transmitters-receivers/wideband-transceivers-ic/ad9361.html#product-overview Analog Devices AD9361]
|RF Transceiver
|U2 (2,8)
|-

|[http://www.analog.com/en/design-center/landing-pages/001/ad9361-ad9364-integ-rf-agile-transceiver-design-res.html AD9361/AD9364 Product Page]
|RF Transceiver
| -
|-
|[http://www.xilinx.com/products/silicon-devices/fpga/spartan-6.html Xilinx Spartan-6 Product Page]
|FPGA
|rowspan="2"|U1 (2,3,4,6); PG1 (6); U18B, U18C (7); U18D (8); U18E, U18F (9); U18G, U18H (10)
|-
|[http://www.xilinx.com/support/documentation/data_sheets/ds160.pdf XC6SLX75 / XC6SLX150]
|FPGA
|-
|[http://www.analog.com/media/en/technical-documentation/data-sheets/ADF4001.pdf ADF4001]
|Frequency Synthesizer
|U101 (1)
|-

|[http://www.cypress.com/file/140296/download CYUSB3014]
|rowspan="2"|FX3: SuperSpeed USB Controller
|rowspan="2"|U3 (5,6); U13 (5)
|-

|[http://www.cypress.com/applications/ez-usb-fx3-superspeed-usb-30-peripheral-controller-collateral-guide EZ-USB FX3™ Product Page]
|-

|[http://www.skyworksinc.com/uploads/documents/SKY13317_373LF_200914K.pdf SKY13317]
|Antenna Switch
|U801, U810 (8)
|-
|[http://www.anaren.com/sites/default/files/BD3150L50100A00%20Data%20sheet%20Rev%20C.pdf BD3150L50100A00]
|Balun
|U802, U808, U809, U815 (8)
|-
|[https://www.minicircuits.com/pdfs/PGA-102+.pdf PGA−102+]
|Amplifier
|U804, U817 (8)
|-

|[http://www.ctscorp.com/wp-content/uploads/2015/11/008-0371-0.pdf VCTCXO]
|VCTCXO (B200mini only)
| -
|-

|[https://www.ctscorp.com/wp-content/uploads/2015/11/008-0334-0.pdf 525L20DA40M0000]
|VCTCXO (B200/B210 only)
| X100 (1)
|-

|[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]
|Optional GPSDO (B200/B210 only)
|U100 (1)
|-
|}

==Enclosures==

* SMA connectors should be torqued to 4 inch-pounds

===B200mini===
* [https://www.ettus.com/all-products/usrp-b200mini-enclosure/ B200mini C-Grade Enclosure]
* [https://www.ettus.com/all-products/usrp-b200mini-i-enclosure/ B200mini I-Grade Enclosure]

===B205mini===
* [https://www.ettus.com/all-products/usrp-b205mini-i-enclosure/ B205mini I-Grade Enclosure]

===B200/B210===
* [https://www.ettus.com/product/details/USRP-B200-Enclosure USRP B200/B210 Enclosure]
** Full Steel Enclosure
** Compatible with green USRP B200 and B210 devices (revision 6 or later)
** Front and rear K-Slots for anti-theft protection

==FPGA==
* Utilization statistics are subject to change between UHD releases. This information is current as of UHD 3.9.4.
===B200===
<pre>
Device utilization summary:
---------------------------

Selected Device : 6slx75fgg484-3

Slice Logic Utilization:
Number of Slice Registers: 15781 out of 93296 16%
Number of Slice LUTs: 19987 out of 46648 42%
Number used as Logic: 15983 out of 46648 34%
Number used as Memory: 4004 out of 11072 36%
Number used as RAM: 972
Number used as SRL: 3032

Slice Logic Distribution:
Number of LUT Flip Flop pairs used: 24062
Number with an unused Flip Flop: 8281 out of 24062 34%
Number with an unused LUT: 4075 out of 24062 16%
Number of fully used LUT-FF pairs: 11706 out of 24062 48%
Number of unique control sets: 434

IO Utilization:
Number of IOs: 172
Number of bonded IOBs: 155 out of 280 55%
IOB Flip Flops/Latches: 124

Specific Feature Utilization:
Number of Block RAM/FIFO: 144 out of 172 83%
Number using Block RAM only: 144
Number of BUFG/BUFGCTRLs: 4 out of 16 25%
Number of DSP48A1s: 76 out of 132 57%
</pre>

===B210===
<pre>
Device utilization summary:
---------------------------

Selected Device : 6slx150fgg484-3

Slice Logic Utilization:
Number of Slice Registers: 29310 out of 184304 15%
Number of Slice LUTs: 36486 out of 92152 39%
Number used as Logic: 29279 out of 92152 31%
Number used as Memory: 7207 out of 21680 33%
Number used as RAM: 1752
Number used as SRL: 5455

Slice Logic Distribution:
Number of LUT Flip Flop pairs used: 43635
Number with an unused Flip Flop: 14325 out of 43635 32%
Number with an unused LUT: 7149 out of 43635 16%
Number of fully used LUT-FF pairs: 22161 out of 43635 50%
Number of unique control sets: 723

IO Utilization:
Number of IOs: 180
Number of bonded IOBs: 163 out of 338 48%
IOB Flip Flops/Latches: 148

Specific Feature Utilization:
Number of Block RAM/FIFO: 186 out of 268 69%
Number using Block RAM only: 186
Number of BUFG/BUFGCTRLs: 4 out of 16 25%
Number of DSP48A1s: 152 out of 180 84%
</pre>

===B200mini===
<pre>
Device utilization summary:
---------------------------

Selected Device : 6slx75csg484-3

Slice Logic Utilization:
Number of Slice Registers: 15949 out of 93296 17%
Number of Slice LUTs: 19963 out of 46648 42%
Number used as Logic: 16140 out of 46648 34%
Number used as Memory: 3823 out of 11072 34%
Number used as RAM: 972
Number used as SRL: 2851

Slice Logic Distribution:
Number of LUT Flip Flop pairs used: 23859
Number with an unused Flip Flop: 7910 out of 23859 33%
Number with an unused LUT: 3896 out of 23859 16%
Number of fully used LUT-FF pairs: 12053 out of 23859 50%
Number of unique control sets: 429

IO Utilization:
Number of IOs: 123
Number of bonded IOBs: 114 out of 328 34%
IOB Flip Flops/Latches: 147

Specific Feature Utilization:
Number of Block RAM/FIFO: 110 out of 172 63%
Number using Block RAM only: 110
Number of BUFG/BUFGCTRLs: 6 out of 16 37%
Number of DSP48A1s: 76 out of 132 57%
Number of PLL_ADVs: 1 out of 6 16%
</pre>

===B205mini===
<pre>
Device utilization summary:
---------------------------

Selected Device : 6slx150csg484-3

Slice Logic Utilization:
Number of Slice Registers: 15949 out of 184304 8%
Number of Slice LUTs: 19963 out of 92152 21%
Number used as Logic: 16140 out of 92152 17%
Number used as Memory: 3823 out of 21680 17%
Number used as RAM: 972
Number used as SRL: 2851

Slice Logic Distribution:
Number of LUT Flip Flop pairs used: 23859
Number with an unused Flip Flop: 7910 out of 23859 33%
Number with an unused LUT: 3896 out of 23859 16%
Number of fully used LUT-FF pairs: 12053 out of 23859 50%
Number of unique control sets: 429

IO Utilization:
Number of IOs: 123
Number of bonded IOBs: 114 out of 338 33%
IOB Flip Flops/Latches: 147

Specific Feature Utilization:
Number of Block RAM/FIFO: 110 out of 268 41%
Number using Block RAM only: 110
Number of BUFG/BUFGCTRLs: 6 out of 16 37%
Number of DSP48A1s: 76 out of 180 42%
Number of PLL_ADVs: 1 out of 6 16%
</pre>

==Interfaces and Connectivity==
B200/B210/B200mini - USB 3.0

===GPIO===
====Power on state====
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.

====Output Current====
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.

===Timing Reference Input===
====B200mini/B200mini-i/B205mini-i====
* 1-PPS or 10 MHz input

=====1-PPS=====
* Maximum: -5V / +5V
* Minimum: 0V / +2.5V

=====10 MHz=====
* Maximum: 0V / +5V
* Minimum: 0V / +1.8V
'''OR'''
* +10dBm ~ +27dBm

====B200/B210====
=====1-PPS=====
* Maximum: 5V
=====10 MHz=====
* Maximum: 15dBm (3.5Vpp into 50 ohms)

==Certifications==
===RoHS===
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]

===China RoHS===
'''Management Methods for Controlling Pollution Caused by Electronic Information Products Regulation'''

'''Chinese Customers'''

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

===Certifications for European Union===
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).

In addition to the part numbers listed above, these ferrite beads can be sourced through Fair-Rite using part number 0443164251.

==Certificate of Volatility==

Found on the [https://www.ni.com/en/support/documentation/product-certifications.html NI Product Certifications lookup tool] [https://www.ni.com/pdf/manuals/377354a.pdf here].

==Downloads==

[http://files.ettus.com/manual/md_fpga.html FPGA Resources]

[http://files.ettus.com/binaries/uhd_stable/ UHD Stable Binaries]

[https://github.com/EttusResearch/uhd UHD Source Code on Github]

==FAQ==
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].

'''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?'''

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.

'''What samples rates should I expect with USB 3.0? USB 2.0?'''

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.

'''When can I power the USRP B200/B210/B200mini off USB?'''

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

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.

'''How much power does the USRP consume?'''

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.

{| class="wikitable"
!
!5 Msps
!15.36 Msps
!30.72 Msps
!56 Msps
!61.44 Msps
|-
|1 RX
|1.92
|2.112
|2.184
|2.508
|
|-
|2 RX
|2.148
|2.436
|2.508
|2.64
|
|-
|1 TX
|2.184
|2.34
|2.352
|2.22
|
|-
|2 TX
|2.76
|2.88
|2.904
|2.64
|
|-
|Full Duplex (1x1)
|2.508
|2.736
|2.796
|3.168
|
|-
|2x2 MIMO
|3.252
|3.588
|3.672
|4.11
|4.092
|-
|}

'''Can I build a multi-unit system with the USRP B200/B210?'''

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.

'''Can I access the source code for the USRP B200/B210?'''

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:

http://files.ettus.com/manual/page_build_guide.html

'''What operating systems does the USRP B200/B210 work on?'''

The USRP B200/B210 is supported on [http://files.ettus.com/manual/page_install.html Linux, OSX (MacOSX / macOS) and Windows].

'''Does the USRP B200/B210 work with GNU Radio?'''

Yes. The USRP B200/B210 work with our GNU Radio plugin - gr-uhd.

'''Does the USRP B200/B210 work with MATLAB and Simulink?'''

Yes. You need to install the [http://www.mathworks.com/hardware-support/usrp.html Communications System Toolbox Support Package for USRP Radio].

'''Does the USRP B200/B210 work with OpenBTS?'''

Yes. This is a third-party application and you can find instructions here: [http://wush.net/trac/rangepublic/wiki/BuildInstallRun OpenBTS - Build, Install, Run.]

For support, please sign up and contact the [https://lists.sourceforge.net/lists/listinfo/openbts-discuss OpenBTS mailing list].

'''What tools do I need to program the FPGA?'''

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.

'''Can I use a GPSDO with the USRP B200/B210?'''

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.

[[Category:Hardware Resources]]

Getting Started with RFNoC Development

2023-12-01T05:04:07Z

JonathonPendlum: Emphasize that this application is deprecated

==Application Note Number==

'''AN-823'''


==Abstract==
'''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]].'''

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.

==Overview==
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.

==Licensing==
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].

==Prerequisites==
RFNoC is only supported on 3rd generation USRP hardware as noted in the Abstract.

In order to build custom USRP FPGA images and RFNoC blocks the following hardware and software are needed.

* '''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.

* '''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].

* '''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).

* Any 3rd generation USRP hardware as noted in the Abstract.

'''NOTE:'''
* The edition of Xilinx Vivado that is required will depend on which USRP device is being used.
** X3xx series devices: Design Edition or System Edition.
** E3xx series devices: Design Edition, System Edition, or the free WebPack Edition.
* Other operating systems can be used, but the exact steps on how to proceed are not given in this Application Note.
* 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.

$ sudo dpkg-reconfigure dash
$ ll /bin/sh

==Creating a development environment==
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].

The following software packages are required in order to setup a development environment/sandbox:

* UHD
* GNU Radio
* gr-ettus

===Create development environment using PyBOMBS===
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:

$ sudo apt-get install git
$ sudo apt-get install python-setuptools python-dev python-pip build-essential

$ sudo pip install git+https://github.com/gnuradio/pybombs.git
$ pybombs recipes add gr-recipes git+https://github.com/gnuradio/gr-recipes.git
$ pybombs recipes add ettus git+https://github.com/EttusResearch/ettus-pybombs.git

These commands will do the following:
* Install <code>Git</code>
* Install <code>pip</code> and other Python dependencies
* Install the latest <code>PyBOMBS</code> from its Git repository
* Add the <code>gr-recipes</code> recipes which are used to install GNU Radio specific software
* Add the <code>ettus</code> recipes which are used to install Ettus Research specific software

From here, PyBOMBS can be used to setup and install the development environment/sandbox by running the following command:

$ pybombs prefix init ~/rfnoc -R rfnoc -a rfnoc

This will do the following:

* Create a directory in the user’s home directory called <code>rfnoc</code> (any valid directory name will work)

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

* 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

'''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:

$ pybombs config makewidth 3

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:

$ pybombs --config makewidth=3 prefix init ~/rfnoc -R rfnoc -a rfnoc
$ pybombs --config makewidth=7 prefix init ~/rfnoc -R rfnoc -a rfnoc

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:

$ cd ~/rfnoc
$ source ./setup_env.sh

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.

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

===Create the development environment manually===
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.

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

To manually download the software, use these <code>git clone</code> commands, which will select the correct branches:

$ git clone --recursive -b rfnoc-devel https://github.com/EttusResearch/uhd.git
$ git clone --recursive -b maint https://github.com/gnuradio/gnuradio.git # master branch is also fine instead of maint
$ git clone -b master https://github.com/EttusResearch/gr-ettus.git
$ git clone -b rfnoc-devel https://github.com/EttusResearch/fpga.git

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

===Verify Environment===
Running the command “<code>uhd_config_info</code>” with the “<code>--version</code>” flag will verify that the installation has been completed successfully.

'''NOTE:''' The version string output from this command may differ, however it should be similar to the output below.

$ uhd_config_info --version
linux; GNU C++ version 5.4.0 20160609; Boost_105800; UHD_4.0.0.rfnoc-devel-161- g83150fdd

4.0.0.rfnoc-devel-161-g83150fdd

===Testing the default FPGA image and building from existing blocks===

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:

$ uhd_images_downloader

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.

The following images have the corresponding RFNoC blocks (Computation Engines):

{| class="wikitable"
!Image Name
!Included Blocks
|-

|<code>usrp_x300_fpga_HG.bit</code>
<code>usrp_x300_fpga_XG.bit</code>

<code>usrp_x310_fpga_HG.bit</code>

<code>usrp_x310_fpga_XG.bit</code>
|<code>2x DDC, 2x DUC</code>
|-

|<code>usrp_x300_fpga_RFNOC_HG.bit</code>
<code>usrp_x300_fpga_RFNOC_XG.bit</code>
|<code>DUC, DDC (one channel), fosphor, window, fft, 2x AXI FIFOs</code>
|-

|<code>usrp_x310_fpga_RFNOC_HG.bit</code>
<code>usrp_x310_fpga_RFNOC_XG.bit</code>
|<code>DUC, DDC (one channel), fosphor, window, fft, 2x AXI FIFOs, Keep One in N, FIR, Siggen</code>
|-

|<code>usrp_e310_fpga.bit</code>
<code>usrp_e310_fpga_sg3.bit</code>
|<code>1x DDC, 1x DUC</code>
|-

|<code>usrp_e310_fpga_RFNOC.bit (sg1 version)</code>
<code>usrp_e310_fpga_RFNOC_sg3.bit</code>
|<code>fosphor, window, fft, 2x AXI FIFOs, FIR</code>
|-

|}

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.

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

By following the steps above the following should now be available:
* UHD/RFNoC code downloaded and installed
* FPGA code available
* A valid RFNoC image on your X3xx or E3xx series device

====Inspect default images====
Run the following command, with a USRP connected to your PC, to verify current image on the USRP.

$ uhd_usrp_probe

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> ):

| | _____________________________________________________
| | /
| | | RFNoC blocks on this device:
| | |
| | | * DmaFIFO_0
| | | * Radio_0
| | | * Radio_1
| | | * DDC_0
| | | * DDC_1
| | | * DUC_0
| | | * DUC_1

Final output for <code>usrp_x310_fpga_RFNOC_HG.bit</code> image:

| | _____________________________________________________
| | /
| | | RFNoC blocks on this device:
| | |
| | | * DmaFIFO_0
| | | * Radio_0
| | | * Radio_1
| | | * DDC_0
| | | * DUC_0
| | | * FFT_0
| | | * Window_0
| | | * FIR_0
| | | * SigGen_0
| | | * KeepOneInN_0
| | | * fosphor_0
| | | * FIFO_0
| | | * FIFO_1

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

====Build custom image with pre-built RFNoC blocks====
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.

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

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:

$ cd {USER_PREFIX}/src/uhd-fpga/usrp3/tools/scripts
$ ./uhd_image_builder.py --help

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.

Example for an X310 USRP:

$ ./uhd_image_builder.py window fft -d x310 -t X310_RFNOC_HG -m 5 --fill-with-fifos

Example for an E310 USRP with Speed Grade 3 (sg3) FPGA:

$ ./uhd_image_builder.py window fft -d e310 -t E310_RFNOC_sg3 -m 5 --fill-with-fifos

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.

$ 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

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

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.

$ uhd_usrp_probe

The final lines of output for the image built for the X310 is as follows:

| | _____________________________________________________
| | /
| | | RFNoC blocks on this device:
| | |
| | | * DmaFIFO_0
| | | * Radio_0
| | | * Radio_1
| | | * Window_0
| | | * FFT_0
| | | * FIFO_0
| | | * FIFO_1
| | | * FIFO_2

===Getting started with UHD + RFNoC===
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.

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.

rfnoc_rx_to_file.cpp

This next example chains a null source to another block and streams the data to the host.

rfnoc_nullsource_ce_rx.cpp

These examples demonstrate the core features and flexibility of RFNoC.

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

===Getting started with GNU Radio + RFNoC===
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.

'''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>).

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.

A couple of rules for building GNU Radio flowgraphs with RFNoC blocks:

* You always need a <code>Device3</code> object in your flow graph (it does not get connected, see screenshot below).
* 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).

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.

[[File:rfnoc gsg an 1.png|center|800px|]]

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

[[File:rfnoc gsg an 2.png|center|800px|]]

For more information on GNURadio development please refer to the [http://gnuradio.org/doc/doxygen/ GNURadio user's manual and API].

==Starting a custom RFNoC block using RFNoC Modtool==
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>.

[[File:rfnoc gsg an 3.png|center|800px|]]

===RFNoC Modtool Utilization===
'''NOTE:''' Console outputs may vary depending on the version of UHD the user is running. However, functionality should be the same or similar.

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.

To check the usage of the tool, run the following:

$ rfnocmodtool help
linux; GNU C++ version 5.4.0 20160609; Boost_105800; UHD_4.0.0.rfnoc-devel-162-g335a1317

Usage:
rfnocmodtool <command> [options] -- Run <command> with the given options.
rfnocmodtool help -- Show a list of commands.
rfnocmodtool help <command> -- Shows the help for a given command.

List of possible commands:

Name Aliases Description
=====================================================================
disable dis Disable block (comments out CMake entries for files)
info getinfo,inf Return information about a given module
remove rm,del Remove block (delete files and remove Makefile entries)
makexml mx Make XML file for GRC block bindings
add insert Add block to the out-of-tree module.
newmod nm,create Create a new out-of-tree module
rename mv Rename a block in the out-of-tree module.

===Creating an RFNoC OOT Module===

To start generating an RFNoC OOT module navigate to the source location ( i.e. <code>cd ~/{USER_PREFIX}/src</code> ) and type:
$ rfnocmodtool newmod [NAME OF THE MODULE]

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.

$ rfnocmodtool newmod tutorial
linux; GNU C++ version 5.4.0 20160609; Boost_105800; UHD_4.0.0.rfnoc-devel-162-g335a1317

Creating out-of-tree module in ./rfnoc-tutorial... Done.
Use 'rfnocmodtool add' to add a new block to this currently empty module.

To see what files and directories were created run:

$ ls rfnoc-tutorial/
apps cmake CMakeLists.txt docs examples grc include lib MANIFEST.md python README.md rfnoc swig

In contrast with <code>gr_modtool</code>, this includes a folder called <code>rfnoc</code>, which is where the UHD/FPGA files are located.

===Adding custom blocks to OOT Module===
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:

$ cd rfnoc-tutorial
$ rfnocmodtool add [NAME OF THE BLOCK]

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:

$ rfnocmodtool add gain
linux; GNU C++ version 5.4.0 20160609; Boost_105800; UHD_4.0.0.rfnoc-devel-162-g335a1317

RFNoC module name identified: tutorial
Block/code identifier: gain
Enter valid argument list, including default arguments:
Block NoC ID (Hexadecimal): 1111222233334444
Skip Block Controllers Generation? [UHD block ctrl files] [y/N] N
Skip Block interface files Generation? [GRC block ctrl files] [y/N] N

Hitting <code>enter</code> on each one of the options will take the default values.

The following is a description of the valid argument list items:

* '''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.

* '''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.

* '''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.

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

After finishing the parsing, the following files will be generated/edited:

Adding file 'lib/gain_impl.h'...
Adding file 'lib/gain_impl.cc'...
Adding file 'include/tutorial/gain.h'...
Adding file 'include/tutorial/gain_block_ctrl.hpp'...
Adding file 'lib/gain_block_ctrl_impl.cpp'...
Editing swig/tutorial_swig.i...
Adding file 'python/qa_gain.py'...
Editing python/CMakeLists.txt...
Adding file 'grc/tutorial_gain.xml'...
Adding file 'rfnoc/blocks/gain.xml'...
Adding file 'rfnoc/fpga-src/noc_block_gain.v'...
rfnoc/testbenches/noc_block_gain_tb folder created
Adding file 'rfnoc/testbenches/noc_block_gain_tb/noc_block_gain_tb.sv'...
Adding file 'rfnoc/testbenches/noc_block_gain_tb/Makefile'...
Adding file 'rfnoc/testbenches/noc_block_gain_tb/CMakeLists.txt'...

==Creating FPGA portion of custom RFNoC Block==
===RFNoC FPGA User Interface (API)===
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].

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

[[File:rfnoc gsg an 4.png|center|800px|]]

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.

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

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

{|
|
AXI Stream signals:
* '''m_axis_data_tdata:''' Input sample data packets
** Data coming from host or another CE
* '''s_axis_data_tdata:''' Output sample data packets
** Data going to another CE or host
* '''m_axis_data_tready:''' Input signal to CE
** Used to notify CE that downstream CE is ready for data
* '''s_axis_data_tready:''' Output signal to CE
** Used to notify upstream CE that CE is ready for data
* '''m_axis_data_tvalid:''' Input signal to CE
** Used to indicate upstream CE has valid data
* '''s_axis_data_tvalid:''' Output signal to CE
** Used to indicate to downstream CE that CE has valid data
* '''m_axis_data_tlast:''' Input signal to CE
** Used to delimit packets from upstream CE
* '''s_axis_data_tlast:''' Output signal to CE
** Used to delimit packets to downstream CE
| style="vertical-align:top" |[[File:rfnoc gsg an 5.png|right|500px|]]
|-
|}

[[File:rfnoc gsg an 6.png|center|800px|]]

{|
|
Settings Bus signals:
* '''set_stb:''' Assert to write '''set_data''' to register at '''set_addr'''ess
* '''set_addr:''' Register address to set
* '''set_data:''' Data to set
* '''rb_data:''' Data to read back
* '''rb_strobe:''' Assert to read '''rb_data''' from register at '''set_addr'''ess

| style="vertical-align:top" |[[File:rfnoc gsg an 7.png|right|500px|]]
|-
|}
For the <code>gain</code> example block the following architecture is desired:

[[File:rfnoc gsg an 8.png|center|800px|]]

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

'''localparam [7:0] SR_GAIN = SR_USER_REG_BASE;'''
localparam [7:0] SR_TEST_REG_1 = SR_USER_REG_BASE + 8'd1;

'''wire [15:0] gain;'''
'''setting_reg #('''
'''.my_addr(SR_GAIN), .awidth(8), .width(16))'''
'''sr_gain ('''
'''.clk(ce_clk), .rst(ce_rst),'''
'''.strobe(set_stb), .addr(set_addr), .in(set_data), .out(gain), .changed());'''

always @(posedge ce_clk) begin
case(rb_addr)
'''8'd0 : rb_data <= {48'd0, gain};'''
8'd1 : rb_data <= {32'd0, test_reg_1};
default : rb_data <= 64'h0BADC0DE0BADC0DE;
endcase
end

'''wire [31:0] pipe_in_tdata;'''
'''wire pipe_in_tvalid, pipe_in_tlast;'''
'''wire pipe_in_tready;'''

'''wire [31:0] pipe_out_tdata;'''
'''wire pipe_out_tvalid, pipe_out_tlast;'''
'''wire pipe_out_tready;'''

'''// Adding FIFO to ensure Pipeline'''
'''axi_fifo_flop #(.WIDTH(32+1))'''
'''pipeline0_axi_fifo_flop ('''
'''.clk(ce_clk),'''
'''.reset(ce_rst),'''
'''.clear(clear_tx_seqnum),'''
'''.i_tdata({m_axis_data_tlast,m_axis_data_tdata}),'''
'''.i_tvalid(m_axis_data_tvalid),'''
'''.i_tready(m_axis_data_tready),'''
'''.o_tdata({pipe_in_tlast,pipe_in_tdata}),'''
'''.o_tvalid(pipe_in_tvalid),'''
'''.o_tready(pipe_in_tready));'''

'''wire [15:0] i = pipe_in_tdata[31:16];'''
'''wire [15:0] q = pipe_in_tdata[15:0];'''

'''wire [31:0] i_mult_gain = i*gain;'''
'''wire [31:0] q_mult_gain = q*gain;'''

'''wire [31:0] mult_gain = {i_mult_gain[15:0], q_mult_gain[15:0]};'''
'''axi_fifo_flop #(.WIDTH(32+1))'''
'''pipeline1_axi_fifo_flop ('''
'''.clk(ce_clk),'''
'''.reset(ce_rst),'''
'''.clear(clear_tx_seqnum),'''
'''.i_tdata({pipe_in_tlast,mult_gain}),'''
'''.i_tvalid(pipe_in_tvalid),'''
'''.i_tready(pipe_in_tready),'''
'''.o_tdata({pipe_out_tlast,pipe_out_tdata}),'''
'''.o_tvalid(pipe_out_tvalid),'''
'''.o_tready(pipe_out_tready));'''

'''/* Output Signals */'''
'''assign pipe_out_tready = s_axis_data_tready;'''
'''assign s_axis_data_tvalid = pipe_out_tvalid;'''
'''assign s_axis_data_tlast = pipe_out_tlast;'''
'''assign s_axis_data_tdata = pipe_out_tdata;'''

The following is a block diagram of the code created by the above Verilog:

[[File:gain_block_diagram_v01.png|center|800px|]]

'''NOTE:''' In order to meet timing, FIFO blocks were added to either side of the Multiplication process.

===Creating and running HDL testbenches===
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.

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:
* Testing through multiple blocks (e.g. FILTER -> FFT -> AVE)
* 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)
* 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)

[[File:rfnoc gsg an 9.png|center|800px|]]

'''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)

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:

rfnoc/testbenches/noc_block_gain_tb folder created
Adding file 'rfnoc/testbenches/noc_block_gain_tb/noc_block_gain_tb.sv'...
Adding file 'rfnoc/testbenches/noc_block_gain_tb/Makefile'...
Adding file 'rfnoc/testbenches/noc_block_gain_tb/CMakeLists.txt'...

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.

Inside of this folder are the following three files:

* <code>CMakeLists.txt:</code> this is an empty file used, so far, only to increase the scope of the compilers.
* <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.
* <code>Makefile:</code> This file determines the directives that run the simulation.

The <code>noc_block_gain_tb.sv</code> testbench skeleton code creates the following architecture:

[[File:testbench_arch_gain_v01.png|center|800px|]]

Open the file <code>rfnoc-tutorial/rfnoc/testbenches/noc_block_gain_tb/noc_block_gain_tb.sv</code> and modify the following lines:

Right under the “Verification” section:

initial begin : tb_main
string s;
logic [31:0] random_word;
logic [63:0] readback;
'''logic [15:0] gain;'''

In the “Test 4 -- Write / readback user registers” section:

`TEST_CASE_START("Write / readback user registers");
random_word = $random();
'''tb_streamer.write_user_reg(sid_noc_block_gain, noc_block_gain.SR_GAIN, random_word[15:0]);'''
'''tb_streamer.read_user_reg(sid_noc_block_gain, 0, readback);'''
'''$sformat(s, "User register 0 incorrect readback! Expected: %0d, Actual %0d", readback[15:0], random_word[15:0]);'''
'''`ASSERT_ERROR(readback[15:0] == random_word[15:0], s);'''

In the “Test 5 -- Test sequence” section:

`TEST_CASE_START("Test sequence");
'''gain = 100;'''
'''tb_streamer.write_user_reg(sid_noc_block_gain, noc_block_gain.SR_GAIN, gain);'''
fork
begin
cvita_payload_t send_payload;
for (int i = 0; i < SPP/2; i++) begin
send_payload.push_back(64'(i));
end
tb_streamer.send(send_payload);
end
begin
cvita_payload_t recv_payload;
cvita_metadata_t md;
logic [63:0] expected_value;
tb_streamer.recv(recv_payload,md);
for (int i = 0; i < SPP/2; i++) begin
'''expected_value = i*gain;'''

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.

From within the <code>rfnoc-tutorial</code> directory, create a <code>build</code> directory and enter it by running:

$ mkdir build && cd build/

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.

If PyBOMBS used, run:

$ cmake ../

If PyBOMBS not used, run:

$ cmake [-DUHD_FPGA_DIR=/PATH/TO/FPGA/REPOSITORY] ../

Final output from the <code>$ cmake ../</code> command:

-- Configuring done
-- Generating done
-- Build files have been written to: /home/widow/rfnoc/src/rfnoc-tutorial/build

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:

$ make test_tb
Scanning dependencies of target test_tb
Built target test_tb

Testbenches can be executed by running the command:

$ make noc_block_[name_of_your_block]_tb

The gain block testbench can be run by running the following command:

$ make noc_block_gain_tb

The simulation will start. Final output should look like this:

========================================================
TESTBENCH STARTED: noc_block_gain
========================================================
[TEST CASE 1] (t=000000000) BEGIN: Wait for Reset...
[TEST CASE 1] (t=000001002) DONE... Passed
[TEST CASE 2] (t=000001002) BEGIN: Check NoC ID...
Read GAIN NOC ID: 1111222233334444
[TEST CASE 2] (t=000001238) DONE... Passed
[TEST CASE 3] (t=000001238) BEGIN: Connect RFNoC blocks...
Connecting noc_block_tb (SID: 1:0) to noc_block_gain (SID: 0:0)
Connecting noc_block_gain (SID: 0:0) to noc_block_tb (SID: 1:0)
[TEST CASE 3] (t=000005457) DONE... Passed
[TEST CASE 4] (t=000005457) BEGIN: Write / readback user registers...
[TEST CASE 4] (t=000006888) DONE... Passed
[TEST CASE 5] (t=000006888) BEGIN: Test sequence...
[TEST CASE 5] (t=000007633) DONE... Passed
========================================================
'''TESTBENCH FINISHED: noc_block_gain'''
''' - Time elapsed: 7700 ns'''
''' - Tests Expected: 5'''
''' - Tests Run: 5'''
''' - Tests Passed: 5'''
'''Result: PASSED'''
========================================================
$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
INFO: [USF-XSim-96] XSim completed. Design snapshot 'noc_block_gain_tb_behav' loaded.
INFO: [USF-XSim-97] XSim simulation ran for 1000000000us
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
# if [string equal $vivado_mode "batch"] {
# puts "BUILDER: Closing project"
# close_project
# } else {
# puts "BUILDER: In GUI mode. Leaving project open."
# }
BUILDER: Closing project
****** Webtalk v2015.4 (64-bit)
**** SW Build 1412921 on Wed Nov 18 09:44:32 MST 2015
**** IP Build 1412160 on Tue Nov 17 13:47:24 MST 2015
** Copyright 1986-2015 Xilinx, Inc. All Rights Reserved.

source /home/widow/rfnoc/src/rfnoc-tutorial/rfnoc/testbenches/noc_block_gain_tb/xsim_proj/xsim_proj.hw/webtalk/labtool_webtalk.tcl -notrace
INFO: [Common 17-206] Exiting Webtalk at Tue Jan 10 23:26:20 2017...
INFO: [Common 17-206] Exiting Vivado at Tue Jan 10 23:26:22 2017...
Built target noc_block_gain_tb

With every custom block created, a <code>make</code> directive will be available to run the simulation from the <code>build</code> directory.

===Building the FPGA image with a custom user block===
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.

====Discussion on number of blocks in an FPGA image====
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.

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.

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.

'''NOTE:''' Blocks with higher resource utilization may fill up the FPGA and force the user to include less blocks.

Verify the current maximum values by running the <code>uhd_images_builder.py</code> utility from the scripts directory.

$ cd {USER_PREFIX}/src/uhd-fpga/usrp3/tools/scripts
$ uhd_image_builder.py --help

====Discussion on FPGA image targets====
RFNoC target names follow the pattern <code>{DEVICE}_RFNOC_{BUILD_TYPE}</code> with the following build types:

* <code>HG:</code> 1GigE on SFP+ Port0, 10Gig on SFP+ Port
* <code>XG:</code> 10GigE on both SFP+ ports
* <code>HLS:</code> Vivado High Level Synthesis enabled
* <code>sgX:</code> Speed grade for E300 devices (1 or 3)

Some examples are:
* <code>X310_RFNOC_HG</code>
* <code>X300_RFNOC_HG</code>
* <code>X310_RFNOC_XG</code>
* <code>X300_RFNOC_XG</code>
* <code>X310_RFNOC_HLS_HG</code>
* <code>X300_RFNOC_HLS_HG</code>
* <code>E310_RFNOC</code> (this is for the speed grade 1 FPGA version of E310, append <code>_sg3</code> for speed grade 3)

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

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

====Image building using the command line====
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:

$ cd {USER_PREFIX}/src/uhd-fpga/usrp3/tools/scripts
$ ./uhd_image_builder.py --help

usage: uhd_image_builder.py [-h] [-I INCLUDE_DIR [INCLUDE_DIR ...]]
[-m MAX_NUM_BLOCKS] [--fill-with-fifos]
[-o OUTFILE] [-d DEVICE] [-t TARGET] [-g] [-c]
[blocks [blocks ...]]

Generate the NoC block instantiation file

positional arguments:
blocks List block names to instantiate.

optional arguments:
-h, --help show this help message and exit
-I INCLUDE_DIR [INCLUDE_DIR ...], --include-dir INCLUDE_DIR [INCLUDE_DIR ...]
Path directory of the RFNoC Out-of-Tree module
-m MAX_NUM_BLOCKS, --max-num-blocks MAX_NUM_BLOCKS
Maximum number of blocks (Max. Allowed for x310|x300:
10, for e300: 6)
--fill-with-fifos If the number of blocks provided was smaller than the
max number, fill the rest with FIFOs
-o OUTFILE, --outfile OUTFILE
Output /path/filename - By running this directive, you
won't build your IP
-d DEVICE, --device DEVICE
Device to be programmed [x300, x310, e310]
-t TARGET, --target TARGET
Build target - image type [X3X0_RFNOC_HG,
X3X0_RFNOC_XG, E310_RFNOC_sg3...]
-g, --GUI Open Vivado GUI during the FPGA building process
-c, --clean-all Cleans the IP before a new build

Here are details on the usage of the script which is followed by an example:

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

These blocks can be identified by the following pattern:

noc_block_{NAME}.v

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:

Incorrect method:

$ ./uhd_image_builder.py noc_block_null_source_sink noc_block_siggen ...

Correct method:

$ ./uhd_image_builder.py null_source_sink siggen ...

'''NOTE:''' Blocks generated by the RFNoC Modtool follow the same naming convention.

There is an increasing list of pre-built blocks. Here is a sample:

* <code>axi_fifo_loopback</code>
* <code>axi_dma_fifo</code>
* <code>fir_filter</code>
* <code>fft</code>
* <code>null_source_sink</code>
* <code>schmidl_cox</code>
* <code>packet_resizer</code>
* <code>split_stream</code>
* <code>vector_iir</code>
* <code>addsub</code>
* <code>window</code>
* <code>keep_one_in_n</code>
* <code>pfb</code>
* <code>export_io</code>
* <code>conv_encoder_qpsk</code>
* <code>siggen</code>
* <code>logpwr</code>
* <code>fosphor</code>
* <code>moving_avg</code>
* <code>ddc</code>
* <code>duc</code>

RFNoC related blocks generally reside in <code>fpga/usrp3/lib/rfnoc/</code>.

{| class="wikitable" style="margin:auto;"

!Block
!Filename
!Description
|-

|FIFO
|[https://github.com/EttusResearch/fpga/blob/maint/usrp3/lib/rfnoc/noc_block_axi_fifo_loopback.v noc_block_axi_fifo_loopback.v]
|Simple FIFO loopback / passthrough block.
|-

|FFT
|[https://github.com/EttusResearch/fpga/blob/maint/usrp3/lib/rfnoc/noc_block_fft.v noc_block_fft.v]
|Xilinx coregen based Fast Fourier Transform up to length 4096.
|-

|FIR
|[https://github.com/EttusResearch/fpga/blob/maint/usrp3/lib/rfnoc/noc_block_fir_filter.v noc_block_fir_filter.v]
|Xilinx coregen based Finite Impulse Response Filter, 41 taps, reconfigurable tap coefficients.
|-

|Window
|[https://github.com/EttusResearch/fpga/blob/maint/usrp3/lib/rfnoc/noc_block_window.v noc_block_window.v]
|Windowing block for use with FFT block.
|-

|Vector IIR
|[https://github.com/EttusResearch/fpga/blob/maint/usrp3/lib/rfnoc/noc_block_vector_iir.v noc_block_vector_iir.v]
|Single pole IIR with configurable coefficients that filters data along vectors (i.e. parallel streams of samples). Useful with FFT output.
|-

|Keep One in N
|[https://github.com/EttusResearch/fpga/blob/maint/usrp3/lib/rfnoc/noc_block_keep_one_in_n.v noc_block_keep_one_in_n.v]
|Keeps one packet every N packets.
|-

|AddSub
|[https://github.com/EttusResearch/fpga/blob/maint/usrp3/lib/rfnoc/noc_block_addsub.v noc_block_addsub.v]
|Example of using multiple block ports in a single RFNoC block to add and subtract streams.
|-

|Null Source Sink
|[https://github.com/EttusResearch/fpga/blob/maint/usrp3/lib/rfnoc/noc_block_null_source_sink.v noc_block_null_source_sink.v]
|Generates dummy packets and can consume packets at a configurable rate. Useful for testing.
|-

|Packet Resizer
|[https://github.com/EttusResearch/fpga/blob/maint/usrp3/lib/rfnoc/noc_block_packet_resizer.v noc_block_packet_resizer.v]
|Resizes input packets to a configurable size (larger or smaller than source packets).
|-

|Split Stream
|[https://github.com/EttusResearch/fpga/blob/maint/usrp3/lib/rfnoc/noc_block_split_stream.v noc_block_split_stream.v]
|Replicates an input stream to a configurable number of output streams.
|-

|}

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

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

'''IMPORTANT:''' Please be sure to terminate the path of your OOT with the "/" character. Otherwise the path might not be recognized.

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

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

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

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

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

<code>-g, --GUI:</code> Open Vivado GUI during the FPGA building process

<code>-c, --clean-all:</code> Cleans the IP before a new build

Here is how to create an X310 FPGA image incorporating the <code>gain</code> block that was created earlier in this Application Note:

$ cd {USER_PREFIX}/src/uhd-fpga/usrp3/tools/scripts
$ ./uhd_image_builder.py gain ddc fft -I {USER_PREFIX}/src/rfnoc-tutorial/ -d x310 -t X310_RFNOC_HG -m 6 --fill-with-fifos

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.

$ 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

'''NOTE:'''
* The FPGA image building process may take over an hour.

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

* [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>

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.

[[File:rfnoc gsg an 10.png|center|800px|]]

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

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:

$ uhd_usrp_probe

| | _____________________________________________________
| | /
| | | RFNoC blocks on this device:
| | |
| | | * DmaFIFO_0
| | | * Radio_0
| | | * Radio_1
| | | * '''Block_0'''
| | | * DDC_0
| | | * FFT_0
| | | * FIFO_0
| | | * FIFO_1
| | | * FIFO_2

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

====Using a graphical interface====
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.

This utility is located in the same <code>scripts</code> directory as <code>uhd_image_builder.py</code>.

To run it, enter the following commands:

$ cd {USER_PREFIX}/src/uhd-fpga/usrp3/tools/scripts/
$ ./uhd_image_builder_gui

The application will then be launched:

[[File:rfnoc gsg an 11.png|center|800px|]]

'''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:

* <code>HG:</code> 1GigE on SFP+ Port0, 10Gig on SFP+ Port1
* <code>XG:</code> 10GigE on both SFP+ ports
* <code>HLS:</code> Vivado High Level Synthesis enabled
* <code>sgX:</code> Speed grade for E300 devices (1 or 3)

'''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>).

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

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

'''5. Add button (>>):''' Manually add the blocks from the central panel into your design.

'''6. Remove button (<<):''' Remove blocks from the current design (far-left panel)

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

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

'''9. Clean IP:''' Cleans the IP before a new build (recompiles all IP).

'''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>”

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

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

'''13. Generate .bit file:''' Start the build by clicking this button.

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

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

==Creating Software/Host portion of custom RFNoC Block==
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.

[[File:rfnoc gsg an 12.png|center|800px|]]

===UHD integration===
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.

The list of things declared by the block declaration file includes:

* Block name and Noc-ID
* Registers
* Inputs and outputs (including types)

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

Skeleton code for both the block declaration and the block controller (if required) can be generated through RFNoC Modtool.

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.

Open the <code>gain.xml</code> file located in the <code>/rfnoc-tutorial/rfnoc/blocks</code> directory and add the following:

<?xml version="1.0"?>
<nowiki></nowiki>
<nocblock>
<name>gain</name>
<blockname>gain</blockname>
<ids>
<id revision="0">1111222233334444</id>
</ids>
'''<nowiki></nowiki>'''
'''<registers>'''
'''<setreg>'''
'''<name>GAIN</name>'''
'''<address>128</address>'''
'''</setreg>'''
'''</registers>'''
'''<nowiki></nowiki>'''
'''<args>'''
'''<arg>'''
'''<name>gain</name>'''
'''<type>double</type>'''
'''<value>1.0</value>'''
'''<check>GE($gain, 0.0) AND LE($gain, 32767.0)</check>'''
'''<check_message>Invalid gain.</check_message>'''
'''<action>'''
'''SR_WRITE("GAIN", IROUND($gain))'''
'''</action>'''
'''</arg>'''
'''</args>'''
<nowiki></nowiki>
<ports>
<sink>
'''<name>in0</name>'''
'''<type>sc16</type>'''
</sink>
<nowiki><source></nowiki>
'''<name>out0</name>'''
'''<type>sc16</type>'''
<nowiki></source></nowiki>
</ports>
</nocblock>

===GNU Radio Integration===
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.

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.

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

====GNU Radio Block Code====

* C++ or Python, although RFNoC blocks need to be written in C++ (if at all)
* How does GNU Radio interface to RFNoC?
** via C++ infrastructure code in <code>gr-ettus</code>
** <code>gr-ettus</code> provides a base RFNoC block class
** Users extend base class for their RFNoC blocks
** Many blocks can use base class “as is”
** No C++ or Python code!
* <code>rfnoc-tutorial/lib/gain_impl.cc</code>
** The gain block does not need anything additional

====GNU Radio Companion Bindings====
* XML
* Describes GNU Radio blocks to GRC
* No recompilation
* Requirement of GNU Radio Companion
* Not strictly necessary for GNU Radio
* Tutorial on how to write them:
** [http://gnuradio.org/redmine/projects/gnuradio/wiki/GNURadioCompanion http://gnuradio.org/redmine/projects/gnuradio/wiki/GNURadioCompanion ]
* Skeleton file generated by RFNoC Modtool

Open the <code>tutorial-gain.xml</code> file located in the <code>rfnoc-tutorial/grc</code> directory and edit as follows:

<nowiki><?xml version="1.0"?></nowiki>
<block>
<name>RFNoC: gain</name>
<key>tutorial_gain</key>
<category>tutorial</category>
<import>import tutorial</import>
<make>tutorial.gain(
self.device3,
uhd.stream_args( \# TX Stream Args
cpu_format="'''fc32'''",
otw_format="'''sc16'''",
args="gr_vlen={0},{1}".format(${grvlen}, "" if $grvlen == 1 else "spp={0}".format($grvlen)),
),
uhd.stream_args( \# RX Stream Args
cpu_format="'''fc32'''",
otw_format="'''sc16'''",
args="gr_vlen={0},{1}".format(${grvlen}, "" if $grvlen == 1 else "spp={0}".format($grvlen)),
),
$block_index, $device_index,
)
'''self.$(id).set_arg("gain", $gain)'''
'''</make>'''
'''<callback>set_arg("gain", $gain)</callback>'''
<nowiki></nowiki>

.
.
.

<option>
<name>Byte</name>
<key>u8</key>
</option>
</param>
<param>
<name>'''Gain'''</name>
<key>'''gain'''</key>
'''<value>1.0</value>'''
<type>'''real'''</type>
</param>

<nowiki></nowiki>
<sink>
<name>in</name>
<type>'''complex'''</type>
<vlen>$grvlen</vlen>
<domain>rfnoc</domain>
</sink>

<nowiki></nowiki>
<nowiki><source></nowiki>
<name>out</name>
<type>'''complex'''</type>
<vlen>$grvlen</vlen>
<domain>rfnoc</domain>
<nowiki></source></nowiki>
</block>

'''NOTE:''' Indentation spacing is important in the <code><make></code> section.

===Compile, Install and Verify===

$ cd {USER_PREFIX}/src/rfnoc-tutorial/build
$ make install

$ uhd_usrp_probe

| | _____________________________________________________
| | /
| | | RFNoC blocks on this device:
| | |
| | | * DmaFIFO_0
| | | * Radio_0
| | | * Radio_1
| | | * '''gain_0'''
| | | * DDC_0
| | | * FFT_0
| | | * FIFO_0
| | | * FIFO_1
| | | * FIFO_2

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

==Testing out the custom block==
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.

[[File:rfnoc gsg an 13.png|center|800px|]]

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

[[File:rfnoc gsg an 14.png|center|800px|]]

==Troubleshooting==
===Xilinx Vivado===
====Compile issues====
=====Synthesis is failing=====
Verify all the correct Xilinx [[Getting Started with RFNoC Development#Prerequisites|prerequisite software]] is installed.

Additional helpful information can be found in the following Xilinx forum posts:
* https://forums.xilinx.com/t5/Synthesis/Synthesis-failed-without-reporting-any-error/td-p/686000
* https://forums.xilinx.com/t5/Installation-and-Licensing/Vivado-on-Linux-synthesis-fails-with-no-error-message/td-p/732143

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

==Reference Files==
The following reference files are included within the gain_src.tar.gz archive linked below:

* gain.xml
* noc_block_gain.v
* noc_block_gain_tb.sv
* tutorial_gain.xml
* rfnoc_gain.grc

[[Media:gain src.tar.gz]]

==Links and Additional Resources==
===RFNoC additional resources===
* [https://youtube.com/watch?v=j-EfyPVpaJ8 Video: RFNoC Getting Started Video Tutorial]
* [https://kb.ettus.com/Mailing_Lists USRP Mailing List]
* [https://kb.ettus.com/RFNoC RFNoC Software Resources Page]
* [https://www.ettus.com/content/files/RFNoC_Wireless_at_VT_Intro.pdf RFNoC Introduction]
* [https://www.ettus.com/content/files/RFNoC_Wireless_at_VT_FPGA.pdf RFNoC Deep Dive: FPGA]
* [https://www.ettus.com/content/files/RFNoC_Wireless_at_VT_Host.pdf RFNoC Deep Dive: Host side]
* [https://www.youtube.com/watch?v=8cPd3t88djE Video: RFNoC presented at Wireless @ Virginia Tech, 2015 ]
** Explaining the slides of Intro, FPGA and Host presentations above (in that order).
* [https://www.youtube.com/watch?v=51rpjJ2W0Qs Video: It's the RFNoC Life for Us by Martin Braun at GRCon16, 2016]

===GNU Radio resources===
* [http://gnuradio.org/redmine/projects/gnuradio/wiki/OutOfTreeModules GNU Radio OutOfTree Modules tutorial]
* [http://gnuradio.org/redmine/projects/gnuradio/wiki/InstallingGRFromSource GNU Radio Installation]
* [http://gnuradio.org/redmine/projects/gnuradio/wiki/Tutorials GNU Radio Tutorials]

===UHD resources===
* [http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com USRP Mailing List]
* [https://kb.ettus.com/UHD UHD Software Resources Page]
* [http://files.ettus.com/manual/md_usrp3_build_instructions.html USRP3 build instructions]
* [http://files.ettus.com/manual/ UHD Manual]

===Other resources===
* [https://www.xilinx.com/support/documentation/ip_documentation/ug761_axi_reference_guide.pdf Xilinx - AXI reference guide]
* [https://kb.ettus.com/Building_and_Installing_the_USRP_Open-Source_Toolchain_(UHD_and_GNU_Radio)_on_Linux UHD + GNU Radio Application Note (Linux)]
* [http://gnuradio.org/redmine/projects/pybombs/wiki PyBOMBS]

[[Category:Application Notes]]

X300/X310

2023-10-27T21:01:14Z

JonathonPendlum: Fix missing link in FAQ for programming FPGA

== Device Overview ==
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.

== Key Features==
===X300===
{|
|style="vertical-align:top"|
* Xilinx Kintex-7 XC7K325T FPGA
* 14 bit 200 MS/s ADC
* 16 bit 800 MS/s DAC
* Frequency range: DC - 6 GHz with suitable daughterboard
* Up 160MHz bandwidth per channel
* Two wide-bandwidth RF daughterboard slots
* Optional GPSDO
* Multiple high-speed interfaces (Dual 10G, PCIe Express, ExpressCard, Dual 1G)
|[[File:Product x300.jpg|250px|center]]
|}

===X310===
{|
|style="vertical-align:top"|
* Xilinx Kintex-7 XC7K410T FPGA
* 14 bit 200 MS/s ADC
* 16 bit 800 MS/s DAC
* Frequency range: DC - 6 GHz with suitable daughterboard
* Up 160MHz bandwidth per channel
* Two wide-bandwidth RF daughterboard slots
* Optional GPSDO
* Multiple high-speed interfaces (Dual 10G, PCIe Express, ExpressCard, Dual 1G)
|[[File:Product x310.jpg|250px|center]]
|}

==Compatible Daughterboards==
* WBX-120 / WBX-40
* SBX-120 / SBX-40
* CBX-120 / CBX-40
* UBX-160 / UBX-40
* BasicTX / BasicRX
* LFRX / LFTX
* TwinRX
* DBSRX2 (EOL)
* RFX Series (EOL)
* TVRX2 (EOL)

==RF Specifications==
===RF Performance Data (with SBX-120)===
* SSB/LO Suppression -35/50 dBc
* Phase Noise 3.5 GHz 1.0 deg RMS
* Phase Noise 6 GHz 1.5 deg RMS
* Power Output >10dBm
* IIP3 (@ typ NF) 0dBm
* Typical Noise Figure 8dB

==Hardware Specifications==
* Ettus Research recommends to always use the latest stable version of UHD

===X300===
* Current Hardware Revision: 8
* Minimum version of UHD required: 3.9.0

===X310===
* Current Hardware Revision: 8
* Minimum version of UHD required: 3.9.0

===Clocking and Sampling Rates===
There are two master clock rates (MCR) supported on the X300 and X310: 200.0 MHz and 184.32 MHz.

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.

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.

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.

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.

==Physical Specifications==

===Dimensions===
27.7 x 21.8 x 3.9 cm

===Weight===
With 2x SBX-120: 1.7kg

===Drawings===
* [[Media:cu ettus-x3xx.pdf| Enclosure]]
* [[Media:cu x3xx motherboard cca.pdf| Motherboard]]
* [[Media:cu Rackmount Ettus-X3xx.pdf| Rackmount kit]]

===CAD/STP Models===
====X3xx====
* [[Media:cu x3xx motherboard cca.stp.gz| Motherboard]]

====X3xx Enclosure====
* [[Media:cu ettus x3xx.stp.gz|Enclosure]]

==Environmental Specifications==
===Operating Temperature Range===
* X300/X310: 25 °C

===Operating Humidity Range===
* 10% to 90% non-condensing

==Schematics==
===X300/X310===
[http://files.ettus.com/schematics/x300/x3xx.pdf X300/X310 Schematics]

==Key Component Datasheets==
{| class="wikitable" style="width:80%"
!Part Number
!Description
!Schematic ID (Page)
|-

|[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]
|FPGA
|U23 (3,5,8,9,10,18)
|-

|[http://www.analog.com/media/en/technical-documentation/data-sheets/AD9146.PDF AD9146]
|Dual Channel, 16-Bit, 1230 MSPS DAC
|U12, U36 (7)
|-

|[http://www.ti.com/lit/ds/slas635b/slas635b.pdf ADS62P48]
|Dual Channel, 14-Bit 210 MSPS ADC
|U11, U35 (6)
|-

|[https://www.fairchildsemi.com/datasheets/FI/FIN1002.pdf FIN1002]
|High Speed Differential Receiver
|U3, U5, U31, U32 (4)
|-

|[http://ww1.microchip.com/downloads/en/DeviceDoc/20001203U.pdf 24LC256T]
|EEPROM
|U530 (11)
|-

|[http://www.ti.com/lit/ds/symlink/lmk04816.pdf LMK04816BISQ/NOPB_1/3]
|Jitter Cleaner With Dual Loop PLLs
|U531 (11)
|-

|[http://www.micrel.com/_PDF/HBW/sy89547l.pdf SY89547LMGTR]
|Multiplexer
|U506 (12)
|-

|[http://www.ti.com/lit/ds/symlink/sn74aup1t17.pdf SN74AUP1T17]
|Single Schmitt-Trigger Buffer Gate
|U6, U519 (12)
|-

|[http://www.ti.com/lit/ds/symlink/tps54620.pdf TPS54620RGYT]
|Synchronous Step Down SWIFT™ Converter
|U515 (21); U516 (26)
|-

|[http://cds.linear.com/docs/en/datasheet/1764fb.pdf LT1764EQ-3.3]
|Voltage Regulator
|U27 (21); U516 (26)
|-

|[http://www.ti.com/lit/ds/symlink/tps7a47.pdf TPS7A47]
|Voltage Regulator
|U28, U532 (21)
|-

|[http://cds.linear.com/docs/en/datasheet/3603fc.pdf LTC3603EUF_TRPBF]
|Monolithic Synchronous Step-Down Regulator
|U517 (23); U500 (25); U514, U513 (27)
|-

|[http://www.ti.com/lit/ds/symlink/tps77625.pdf TPS77625_SM]
|Low-Dropout Voltage Regulators
|U30 (23)
|-

|[http://www.ti.com/lit/ds/symlink/tps79318-ep.pdf TPS79318_SM]
|Low-Dropout Voltage Regulators
|U510 (27)
|-

|[[Media:agile9598503.pdf|OSC-96MHZ-724821-01]]
|Voltage Controlled Crystal Oscillator
|U25 (11)
|-

|}

==GPSDO==
* Support GPSDO NMEA Strings
* [http://www.jackson-labs.com/assets/uploads/main/LC_XO_specsheet.pdf JacksonLabs LC_XO]

===Sensors===
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.

==FPGA==
* 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.

===X300===
<pre>
1. Slice Logic
--------------

+----------------------------+-------+-----------+-------+
| Site Type | Used | Available | Util% |
+----------------------------+-------+-----------+-------+
| Slice LUTs | 61622 | 203800 | 30.23 |
| LUT as Logic | 52887 | 203800 | 25.95 |
| LUT as Memory | 8735 | 64000 | 13.64 |
| LUT as Distributed RAM | 1878 | | |
| LUT as Shift Register | 6857 | | |
| Slice Registers | 62961 | 407600 | 15.44 |
| Register as Flip Flop | 62961 | 407600 | 15.44 |
| Register as Latch | 0 | 407600 | 0.00 |
| F7 Muxes | 1209 | 101900 | 1.18 |
| F8 Muxes | 150 | 50950 | 0.29 |
+----------------------------+-------+-----------+-------+

3. Memory
---------

+-------------------+------+-----------+-------+
| Site Type | Used | Available | Util% |
+-------------------+------+-----------+-------+
| Block RAM Tile | 409 | 445 | 91.91 |
| RAMB36/FIFO* | 398 | 445 | 89.43 |
| RAMB36E1 only | 398 | | |
| RAMB18 | 22 | 890 | 2.47 |
| RAMB18E1 only | 22 | | |
+-------------------+------+-----------+-------+
* 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

4. DSP
------

+----------------+------+-----------+-------+
| Site Type | Used | Available | Util% |
+----------------+------+-----------+-------+
| DSPs | 123 | 840 | 14.64 |
| DSP48E1 only | 123 | | |
+----------------+------+-----------+-------+

</pre>

===X310===
<pre>
1. Slice Logic
--------------

+----------------------------+-------+-----------+-------+
| Site Type | Used | Available | Util% |
+----------------------------+-------+-----------+-------+
| Slice LUTs | 61616 | 254200 | 24.23 |
| LUT as Logic | 52885 | 254200 | 20.80 |
| LUT as Memory | 8731 | 90600 | 9.63 |
| LUT as Distributed RAM | 1878 | | |
| LUT as Shift Register | 6853 | | |
| Slice Registers | 62958 | 508400 | 12.38 |
| Register as Flip Flop | 62958 | 508400 | 12.38 |
| Register as Latch | 0 | 508400 | 0.00 |
| F7 Muxes | 1209 | 127100 | 0.95 |
| F8 Muxes | 150 | 63550 | 0.23 |
+----------------------------+-------+-----------+-------+

3. Memory
---------

+-------------------+------+-----------+-------+
| Site Type | Used | Available | Util% |
+-------------------+------+-----------+-------+
| Block RAM Tile | 409 | 795 | 51.44 |
| RAMB36/FIFO* | 398 | 795 | 50.06 |
| RAMB36E1 only | 398 | | |
| RAMB18 | 22 | 1590 | 1.38 |
| RAMB18E1 only | 22 | | |
+-------------------+------+-----------+-------+
* 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

4. DSP
------

+----------------+------+-----------+-------+
| Site Type | Used | Available | Util% |
+----------------+------+-----------+-------+
| DSPs | 123 | 1540 | 7.98 |
| DSP48E1 only | 123 | | |
+----------------+------+-----------+-------+

</pre>

===FPGA User Modifications===
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.

==Firmware==

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.

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:
* Create and enter a build directory: <code>mkdir build && cd build</code>
* Run cmake: <code>cmake /path/to/firmware/usrp3/</code>
** If all is correctly configured, and the ZPU compiler can be found, this will pass without errors.
* Build the firmware: <code>make</code>
** This should yield output similar to this:

<pre>
Scanning dependencies of target x300
[ 79%] Generating x300_main.map
[ 83%] Generating x300_main.bin
[ 87%] Generating x300_main.ihx
[ 91%] Generating x300_main.dump
[ 95%] Generating x300_main.rom
[100%] Generating x300_main.coe
[100%] Built target x300
</pre>

* These files will be copied into the <code>build/x310</code> directory.
* 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:

UHD_IMAGES_DIR=/path/to/build/x300 uhd_usrp_probe --args type=x300,fw=x300_main.bin

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

==Interfaces and Connectivity==
Follow the links below for additional information on configuring each interface for the USRP X300 or X310 SDRs.

*[http://files.ettus.com/manual/page_usrp_x3x0.html#x3x0_hw_10gige Dual 10 Gigabit Ethernet] - 200 MS/s Full Duplex @ 16-bit
*[http://files.ettus.com/manual/page_usrp_x3x0.html#x3x0_hw_pcie PCIe Express (Desktop)] - 200 MS/s Full Duplex @ 16-bit
*[http://files.ettus.com/manual/page_usrp_x3x0.html#x3x0_hw_pcie_laptop ExpressCard (Laptop)] - 50 MS/s Full Duplex @ 16-bit
*[http://files.ettus.com/manual/page_usrp_x3x0.html#x3x0_hw_1gige Dual 1 Gigabit Ethernet] - 25 MS/s Full Duplex @ 16-bit

===Front Panel===
{|
| style="width:50%" |

* '''JTAG''': USB connector for the on-board USB-JTAG programmer
* '''RF A Group'''
** '''TX/RX LED''': Indicates that data is streaming on the TX/RX channel on daughterboard A
** '''RX2 LED''': Indicates that data is streaming on the RX2 channel on daughterboard A
* '''REF''': Indicates that the external Reference Clock is locked
* '''PPS''': Indicates a valid PPS signal by pulsing once per second
* '''AUX I/O''': Front panel GPIO connector.
* '''GPS''': Indicates that GPS reference is locked
* '''LINK''': Indicates that the host computer is communicating with the device (Activity)
* '''RF B Group'''
** '''TX/RX LED''': Indicates that data is streaming on the TX/RX channel on daughterboard B
** '''RX2 LED''': Indicates that data is streaming on the RX2 channel on daughterboard B
* '''PWR''': Power switch

| style="vertical-align:top" | [[File:x3x0 fp overlay.png]]
|}

===Rear Panel===
{|
| style="width:50%" |
* '''PWR''': Connector for the USRP-X Series power supply
* '''1G/10G ETH''': SFP+ ports for Ethernet interfaces
* '''REF OUT''': Output port for the exported reference clock
* '''REF IN''': Reference clock input
* '''PCIe x4''': Connector for Cabled PCI Express link
* '''PPS/TRIG OUT''': Output port for the PPS signal
* '''PPS/TRIG IN''': Input port for the PPS signal
* '''GPS''': Connection for the GPS antenna

| style="vertical-align:top" | [[File:x3x0 rp overlay.png]]
|}

===Ref Clock - 10 MHz===
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.

===PPS - Pulse Per Second===
Using a PPS signal for timestamp synchronization requires a square wave signal with the following a 5Vpp amplitude.

To test the PPS input, you can use the following tool from the UHD examples:

* <code><args></code> are device address arguments (optional if only one USRP device is on your machine)

cd <install-path>/lib/uhd/examples ./test_pps_input –args=<args>

===Front Panel GPIO===
{|
| style="width:50%" |
The GPIO port is not meant to drive big loads. You should not try to source more than 5mA per pin.

The +3.3V is for ESD clamping purposes only and not designed to deliver high currents.

The switching speed is below 10 MHz.

| style="vertical-align:top" | [[File:x3x0 gpio conn.png]]
|}

====Power on state====
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.

====Pin Mapping====
* Pin 1: +3.3V
* Pin 2: Data[0]
* Pin 3: Data[1]
* Pin 4: Data[2]
* Pin 5: Data[3]
* Pin 6: Data[4]
* Pin 7: Data[5]
* Pin 8: Data[6]
* Pin 9: Data[7]
* Pin 10: Data[8]
* Pin 11: Data[9]
* Pin 12: Data[10]
* Pin 13: Data[11]
* Pin 14: 0V
* Pin 15: 0V

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

===On-Board LEDs===
{| class="wikitable"

!LED
!Detail
!Description
|-

| DS1
| 1.2V
| Power
|-

| DS2
| TXRX1
| Red: TX, Green: RX
|-

| DS3
| RX1
| Green: RX
|-

| DS4
| REF
| Reference Lock
|-

| DS5
| PPS
| Flashes on Edge
|-

| DS6
| GPS
| GPS Lock
|-

| DS7
| SFP0
| Link, Right, Green
|-

| DS8
| SFP0
| Link Activity, Left, Yellow
|-

| DS10
| TXRX2
| Red: TX Green: RX
|-

| DS11
| RX2
| Green: RX
|-

| DS12
| 6V
| Daughterboard Power
|-

| DS13
| 3.8V
| Power
|-

| DS14
| 3.3V
| Management Power
|-

| DS15
| 3.3V
| Auxiliary Management Power
|-

| DS16
| 3.3V
| FPGA Power
|-

| DS19
| SFP1
| Link Active, Left, Yellow
|-

| DS20
| SFP1
| Link, Right, Green
|-

| DS21
| LINK
| Link Activity
|-

|}

===Power Connector===
Model: PDP-40 by CUI Inc.

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

Assembly instructions: [[Media:pdp-40.pdf]]

====Pin Detail====
* Pins #1 / #2: 12v
* Pins #3 / #4: Ground

[[File:pdp 40 power detail.png]]

==Certifications==
===RoHS===
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]

===China RoHS===
'''Management Methods for Controlling Pollution Caused by Electronic Information Products Regulation'''

'''Chinese Customers'''

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

==Certificate of Volatility==

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

==Downloads==
[http://files.ettus.com/manual/md_fpga.html FPGA Resources]

[http://files.ettus.com/binaries/uhd_stable/ UHD Stable Binaries]

[https://github.com/EttusResearch/uhd UHD Source Code on Github]

==Choosing USRP X310 vs USRP X300==
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.

{| class="wikitable" style="margin: auto;"
!colspan="3"|USRP X300 and X310 FPGA Resource Summary
|-
|rowspan="2"|Resource Type
|USRP X300 (XC7K325T)
|USRP X310 (XC7K410T)
|-
|Count
|Count
|-
|DSP48 Blocks
|840
|1540
|-
|Block Rams (18kB)
|890
|1590
|-
|Logic Cells
|326,080
|406,720
|-
|Slices (logic)
|50,950
|63,550
|-
|}

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

==Choosing an RF Daughterboard==
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.

{| class="wikitable" style="margin: auto;"
!Daughterboard
!Frequency Range
!Bandwidth
|-

|WBX-120
|50 MHz - 2200 MHz
|120 MHz
|-

|SBX-120
|400 MHz - 4400 MHz
|120 MHz
|-

|CBX-120
|1200 MHz - 6000 MHz
|120 MHz
|-

|UBX-160
|10 MHz - 6000 MHz
|160 MHz
|-

|TwinRX
|10 MHz - 6000 MHz
|80 MHz per channel, 160 MHz total
|-

|}

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.

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.

If you plan to transmit or receive over the air, you should also purchase an antenna.

==Choosing a Host Interface==

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.

{| class="wikitable" style="margin: auto;"
!colspan="4"|Table 3 - Interface Performance Summary
|-
!Interface
!Throughput (MS/s @ 16-bit)
!Target
!Recommended Kit
|-
|1 Gigabit
|25 MS/s
|Desktop/Laptop
|Components provided with USRP X300/X310 kit.
For additional connections, purchase the following:
[https://www.ettus.com/product/details/1GIGE-KIT SFP Adapter + GigE Cable]
|-
|10 Gigabit
|200 MS/s
|Desktop
|[https://www.ettus.com/product/details/10GIGE-KIT 10 GigE Interface Kit]
|-
|PCI-Express
(PCIe, 4 lane)
|200 MS/S
|Desktop
|[https://www.ettus.com/product/details/PCIE-KIT PCI-Express Desktop Kit]
|-
|Express Card
(PCIe, 1 lane)
|50 MS/s
|Laptop
|[https://www.ettus.com/product/details/ECARD-KIT ExpressCard Kit]
|-
|}

[[File:Connectivity 2.png|700px|center]]

<center>Figure 2 - Host Interface Options</center>

===10 Gigabit Ethernet===
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.

'''Recommended 10 Gigabit Ethernet Cards'''
* Intel X520-DA2
** [http://ark.intel.com/products/39776/Intel-Ethernet-Converged-Network-Adapter-X520-DA2 Intel® Ethernet Converged Network Adapter X520-DA2]
* Intel X520-DA1
** [http://ark.intel.com/products/68669/Intel-Ethernet-Converged-Network-Adapter-X520-DA1 Intel® Ethernet Converged Network Adapter X520-DA1 ]
* Intel X710-DA2
** [http://ark.intel.com/products/83964/Intel-Ethernet-Converged-Network-Adapter-X710-DA2 Intel® Ethernet Converged Network Adapter X710-DA2 ]
* Intel X710-DA4
** [http://ark.intel.com/products/83965/Intel-Ethernet-Converged-Network-Adapter-X710-DA4 Intel® Ethernet Converged Network Adapter X710-DA4 ]
* Mellanox MCX4121A-ACAT
** [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 ]

==International Power Supply Options==
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.

==Option: GPS Disciplined, Oven-Controlled Oscillator (GPSDO)==
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.

{| class="wikitable" style="margin: auto;"
|
!Internal TCXO
!GPS-Disciplined Clock
|-
|Frequency Reference
|TCXO
|OCXO
|-
|Frequency Accuracy (unlocked)
|± 2.5ppm
± 2,500 Hz @ 1 GHz
|± 25 ppb
± 25 Hz @ 1 GHz
|-
|Frequency Accuracy
|
|± 0.01ppb
|-
|(GPS-Disciplined)
|
|~ ± 0.01 Hz @ 1 GHz
|-
|GPS Time Sync Accuracy
|
|±50ns to UTC Time**
|-
|10 MHz Reference Phase Drift with GPS Sync
|
|<±20ns After 1 Hour**
|-
|}

==Option: Antenna Kit for GPSDO==
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.

==Option: General Purpose Input/Output (GPIO) Kit==
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.

==Option: Cables for MIMO Expansion==
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.

For more information about MIMO operation, please see the MIMO and Synchronization Application Note.
[[File:8mimo.png|700px|center]]
<center>Figure 4 - Star-Distribution of 10 MHz/PPS Signals with OctoClock</center>

==Option: USRP X300/X310 Rackmount==

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.

==Guidance on SFP+ Adapters for Fiber Connectivity on USRP X300/X310==

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.

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.

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.

Ettus Research has only tested multi-mode fiber accessories.

===Known-Good Adapters===
* [https://approvedoptics.com/blade-networks-bn-ckm-sp-sr/ Approved Optics Blade Networks BN-CKM-SP-SR-A]

===Known-Good Cables===
* [https://www.colfaxdirect.com/store/pc/viewPrd.asp?idproduct=995&idcategory=2 Myricom Fiber Cables for 10GBase-SR, 3 Meters 10G-SR-3M]

==Guidance on 10Gb SFP+ to RJ45 Adapters==

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.

Ettus Research has tested the adapters linked below.

===Known-Good Adapters===
* [https://www.amazon.com/10Gtek-SFP-10G-T-S-Compatible-10GBase-T-Transceiver/dp/B01KFBFL16/ 10Gtek SFP+ to RJ45 Copper Module]
* [https://www.prolabs.com/products/transceivers/brocade/sfpplus/100-1000-10000base/10g-sfpp-t-c ProLabs 10G-SFPP-T-C]

==FAQ==
USRP™ X300 and USRP™ X310 SDRs Frequently Asked Questions

* '''What is the bandwidth of the USRP X300/X310'''

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.

RF Daughterboard Bandwidths: See the daughterboard specifications [link]

FPGA Processing Bandwidth: Up to 200 MS/s quadrature.

Host Bandwidth: Up to 200 MS/s quadrature, dependent on selected interface

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.

* '''How can I program the USRP X300/X310'''

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:

http://files.ettus.com/manual/

* '''How do I update the FPGA images and firmware with the latest from UHD'''

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

* '''How can I modify the FPGA of the USRP X300/X310'''

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.

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.

* '''How much free space is available in the USRP X300/X310 FPGA'''

Please see the USRP X300/X310 FPGA resources page for more information.

* '''What type of PC setup is recommended for use with the USRP X300/X310'''

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.

* '''What frequency range does the USRP X300/X310 cover'''

The frequency range depends on the daughterboard select by the users. For more information, please see the USRP X300/X310 Configuration Guide.

* '''What components do I need to purchase for a complete USRP X300/X310 system'''

For a more comprehensive guide, please see the USRP X300/X310 Configuration Guide.

* '''What is the difference between the USRP X300/X310'''

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.

* '''What is the part number of the X300/X310 power connector'''
Model: PDP-40 by CUI Inc.
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

[[Category:Hardware Resources]]

Writing the USRP File System Disk Image to a SD Card

2023-09-25T21:28:12Z

JonathonPendlum: Removed reference to bmaptool as it is not recommended for UHD 4.x images

==Application Note Number==
'''AN-630'''


==Abstract==
This application note will provide step-by-step instructions on writing a file system disk image to a SD card using Linux.

==Required Tools==
* Computer with USB2/3 Interface
* UHD Installation
* microSD card to USB Adapter

==Downloading the File System Image==
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.

===N3xx===

$ sudo uhd_images_downloader -t sdimg -t n3xx

Example Output for UHD 3.15.0.0:

$ sudo uhd_images_downloader -t sdimg -t n3xx
[INFO] Images destination: /usr/local/share/uhd/images
[INFO] No inventory file found at /usr/local/share/uhd/images/inventory.json. Creating an empty one.
845962 kB / 845962 kB (100%) n3xx_common_sdimg_default-v3.15.0.0.zip
[INFO] Images download complete.

===E31x===

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]

$ sudo uhd_images_downloader -t sdimg -t e310 -t sg1

or
$ sudo uhd_images_downloader -t sdimg -t e310 -t sg3

Example Output for UHD 3.15.0.0 for E310 SG3:

$ sudo uhd_images_downloader -t sdimg -t e310 -t sg3
[INFO] Images destination: /usr/local/share/uhd/images
[INFO] No inventory file found at /usr/local/share/uhd/images/inventory.json. Creating an empty one.
561236 kB / 561236 kB (100%) e3xx_e310_sg3_sdimg_default-v3.15.0.0.zip
[INFO] Images download complete.

===E320===

$ sudo uhd_images_downloader -t sdimg -t e320

Example Output for UHD 3.15.0.0:

$ sudo uhd_images_downloader -t sdimg -t e320
[INFO] Images destination: /usr/local/share/uhd/images
[INFO] No inventory file found at /usr/local/share/uhd/images/inventory.json. Creating an empty one.
795674 kB / 795674 kB (100%) e3xx_e320_sdimg_default-v3.15.0.0.zip
[INFO] Images download complete.

==Identifying UHD Installation Prefix==

In the output of the <code>uhd_images_downloader</code> command above, the folder destination where the images are saved is printed out.

An alternative method to identify your installation prefix is to run the command:

$ uhd_config_info --install-prefix

Example Output:

Install prefix: /usr/local

The default folder location for FPGA and SD card images is:

<UHD_INSTALL_PREFIX>/share/uhd/images/

==Writing the File System Image with Linux==

===Identifying SD Card Mount Location===

Insert the microSD card into the host computer.

To identify the device where the microSD card is, run the command:

dmesg | tail

Example Output (partially truncated for readability):

[21265.575488] usb-storage 1-2:1.0: USB Mass Storage device detected
[21266.586983] scsi 0:0:0:0: Direct-Access Generic Mass-Storage 1.11 PQ: 0 ANSI: 2
[21266.588024] sd 0:0:0:0: Attached scsi generic sg0 type 0
[21267.299812] sd 0:0:0:0: [sdb] 31116288 512-byte logical blocks: (15.9 Gb/14.8 GiB)
[21267.302687] sdb: sdb1 sdb2 sdb3 sdb4

NOTE: In this specific example configuration, the SD card has been attached to <code>sdb</code>.

Another method to finding the device node the disk is attached at is to use the Linux utility <code>lsblk</code>:

Example Output:

$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sdb 8:16 1 14.9G 0 disk
├─sdb1 8:17 1 16M 0 part /media/user/boot
├─sdb2 8:18 1 1.9G 0 part /media/user/primary
├─sdb3 8:19 1 1.9G 0 part /media/user/secondary
└─sdb4 8:20 1 11G 0 part /media/user/data

===Unmount Auto-mounted Partitions===

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:

$ sudo umount /media/user/data
$ sudo umount /media/user/primary
$ sudo umount /media/user/secondary
$ sudo umount /media/user/boot

Running the command <code>lsblk</code> again will show these partitions have been unmounted:

Example Output:

$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sdb 8:16 1 14.9G 0 disk
├─sdb1 8:17 1 16M 0 part
├─sdb2 8:18 1 1.9G 0 part
├─sdb3 8:19 1 1.9G 0 part
└─sdb4 8:20 1 11G 0 part

===Writing the SD Card Image===

====Using dd to write the disk image====

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

NOTE: You must use a 16 Gb or larger SD card for the N3xx and E320 file system images.

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

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:

'''N3xx'''
<IMAGE>=/usr/local/share/uhd/images/usrp_n3xx_fs.sdimg

'''E320'''
<IMAGE>=/usr/local/share/uhd/images/usrp_e320_fs.sdimg

Write the disk image with the command:

$ sudo dd if=<IMAGE> of=<SD_CARD_DEV_NAME> bs=1M

This step of writing the disk image to the SD card can take several minutes to complete.

Example Output:

$ sudo dd if=/usr/local/share/uhd/images/usrp_<deivce>_fs.sdimg of=/dev/sdb bs=1M
15160+0 records in
15160+0 records out
15896412160 bytes (16 Gb, 15 GiB) copied, 1160.93 s, 13.7 MB/s

To ensure the disk is synchronized, run the <code>sync</code> command:

$ sync

You can now remove the microSD card from your host computer and insert it into the USRP.

[[Category:Application Notes]]

Ettus USRP E300 Embedded Family Getting Started Guides

2023-09-25T20:38:31Z

JonathonPendlum: Fix mendor update commands

==Kit Contents==

===E310===

{|
|style="vertical-align:top"|
* E310 USRP
* Power supply
* 2x SMB-to-SMA adapter
* 1 Gigabit Ethernet cable
* USB2-to-microUSB cable
* Imaged microSD card
* Getting started guide
|[[File:Product e310.png|250px|center]]
|}

===E312===

{|
|style="vertical-align:top"|
* E312 USRP
* Power supply
* 2x SMB-to-SMA adapter
* 1 Gigabit Ethernet cable
* USB2-to-microUSB cable
* Imaged microSD card
* Getting started guide
|[[File:Product e312.png|250px|center]]
|}

===E313===

{|
|style="vertical-align:top"|
* Protective caps for input ports
* Surface mounting accessory
* Pole mounting accessory
* End conduit interface for USB devices
* Waterproof sleeve for DC power connector
* Waterproof sleeve for PoE (RJ45) connector
* Torx T-20 key
* Mounting accessory assembly guide
* Imaged microSD card
|[[File:E313.png|250px|center]]
''The USRP E313 is a fully assembled device that includes an USRP E310.''
|}

==Verify the Contents of Your Kit==

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.

==You Will Need==

* A host computer with an available USB 2.0 or 3.0 port

==Proper Care and Handling==

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:

*Never allow metal objects to touch the circuit board while powered.
*Always properly terminate the transmit port with an antenna or 50Ω load.
*Always handle the board with proper anti-static methods.
*Never allow the board to directly or indirectly come into contact with any voltage spikes.
*Never allow any water, or condensing moisture, to come into contact with the boards.
*Always use caution with FPGA, firmware, or software modifications.
{|
|style="padding-left:10px; padding-right:10px; padding-bottom:10px;" |[[File:Caution.png|24px|center]]
|style="padding-left:10px; padding-right:10px; padding-bottom:10px;" |Never apply more than 0 dBm of power into any RF input.
|-
|style="padding-left:10px; padding-right:10px; padding-bottom:10px;" |[[File:Caution.png|24px|center]]
|style="padding-left:10px; padding-right:10px; padding-bottom:10px;" |Always use at least 30dB attenuation if operating in loopback configuration
|-
|}

==Install and Setup the Software Tools on Your Host Computer==

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.

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.

== USRP E31x Device Specific Operations ==

=== Powering On the Hardware ===

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

$ dmesg | grep -i "firmware version"

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.

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)!

=== Turning the Device Off/On ===

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.

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:

$ shutdown -h now

=== Autoboot ===

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.

To control autoboot on the USRP E31x, first determine the version of UHD, for example by running

$ uhd_config_info --version

on the device. The UHD version determines the filesystem location where the <code>autoboot</code> file is located.

* For UHD 4 and newer

To enable autoboot:

$ echo 1 > /sys/devices/soc0/fpga-full/fpga-full:pmu/autoboot

To disable autoboot:

$ echo 0 > /sys/devices/soc0/fpga-full/fpga-full:pmu/autoboot

* For UHD 3.15 and older:

To enable autoboot:

$ echo 1 > /sys/devices/axi_pmu.3/autoboot

To disable autoboot:

$ echo 0 > /sys/devices/axi_pmu.3/autoboot

Settings take place immediately; no reboot is required.

=== Default Password ===

The default user is <code>root</code> and the password is empty (no password).

It is recommended to update the <code>root</code> password, which can be done with the command <code>passwd</code>:

Example Output:

root@ni-e3x0-SERIAL:~# passwd
Changing password for root
New password:
Re-enter new password:
passwd: password changed.

==Serial Console Connectivity==

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.

On Linux, the following command will typically handle the serial connection:

sudo screen /dev/ttyUSB0 115200

You may have to change the device name.

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

==Network Connectivity==

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.

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.

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

==Updating the Linux File System==

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.

There are two ways to update the file system for the E310 USRP:

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.

2. Physically remove microSD card from device and write a new file system to the microSD card.

NOTE: File System Partition Layout

The SD Card is divided into four partitions. There are two root file system partitions, a "boot" partition and a "data" partition.

Any data you would like to preserve through Mender updates should be saved to the "data" partition, which is mounted at <code>/data</code>.

===1. Updating the file system with Mender===

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.

====Mender Update Process====

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.

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.

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.

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.

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.

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:

$ sudo uhd_images_downloader -t mender -t e310 -t sg# --yes

where "sg#" is the correct file type as found above, with "#" being either 1 or 3. Example Output:

$ sudo uhd_images_downloader -t mender -t e310 -t sg3 --yes
[INFO] Using base URL: https://files.ettus.com/binaries/cache/
[INFO] Images destination: /usr/local/share/uhd/images
292014 kB / 292014 kB (100%) e3xx_e310_sg3_mender_default-v4.0.0.0.zip
[INFO] Images download complete.

NOTE: In the output of the command, the folder destination where the images are saved is printed out.

NOTE: Regardless of which file type is specified, the extracted mender file will have the same name: <code>usrp_e310_fs.mender</code>.

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

Example code to execute:

$ scp /usr/local/share/uhd/images/usrp_e310_fs.mender root@192.168.1.51:~/.

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

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.

On the E310, run <code>mender install /path/to/latest.mender</code> to update the file system:

root@ni-e310-serial:~# mender install /home/root/usrp_e310_fs.mender

Example Output:

<pre>
root@ni-e310-serial:~# mender install /home/root/usrp_e310_fs.mender
INFO[0000] Start updating from local image file: [/home/root/usrp_e310_fs.mender] module=rootfs
Installing update from the artifact of size 399640064
INFO[0000] opening device /dev/mmcblk0p3 for writing module=block_device
INFO[0000] partition /dev/mmcblk0p3 size: 2046820352 module=block_device
................................ 0% 1024 KiB
................................ 0% 2048 KiB
................................ 0% 3072 KiB
[truncated for readability]
................................ 99% 389120 KiB
................................ 99% 390144 KiB
................................ 100% 390273 KiB
INFO[0740] wrote 2046820352/2046820352 bytes of update to device /dev/mmcblk0p3 module=device
INFO[0744] Enabling partition with new image installed to be a boot candidate: 3 module=device
</pre>

The artifact can also be stored on a remote server:
$ mender install <http://server.name/path/to/latest.mender>

This procedure will take a few minutes to complete. After mender has logged a successful update, reboot the device:
$ reboot

If the reboot worked, and the device seems functional, commit the changes so that the boot loader knows to permanently boot into this partition:
$ mender -commit

To identify the currently installed Mender artifact from the command line, the following file can be queried on the E310:
$ cat /etc/mender/artifact_info

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.

For more information on updating the file-system, refer to the [https://files.ettus.com/manual/page_usrp_e3xx.html UHD Manual].

=====Troubleshooting Mender Update=====

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:

A. Reimage SD card with full sdimg using dd or bmaptool

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.

B. Manually reconfigure bootloader

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.

1) Connect to the [[E310/E312_Getting_Started_Guides#Serial_Console_Connectivity|E31x via serial]]

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:

Automatic boot in 3s...
Enter 'noautoboot' to enter prompt without timeout
ni-e31x-uboot>

If you don't get this prompt, restart the device and try again.

3) Configure the bootargs to support mender updates

setenv bootargs 'root=${mender_kernel_root} rw rootwait uio_pdrv_genirq.of_id=usrp-uio'
saveenv

4) Reboot device and apply mender image

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.

===2. Updating the files system by writing the disk image===

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.

NOTE: This method will overwrite all data saved on the microSD card, including any data saved to the <code>/data</code> partition.

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.

==Subdevice Specification Mapping==

===E310/E312/E313===

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

====UHD <3.15.x.x====
* TRX-A / RX2-A = A:0
* TRX-B / RX2-B = B:0

====UHD 3.15.x.x+====
* TRX-A / RX2-A = A:0
* TRX-B / RX2-B = A:1

Additional details of UHD Subdevice Specifications can be found here in the UHD Manual: http://files.ettus.com/manual/page_configuration.html#config_subdev

==Example Programs==
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

==Test and Verify the Operation of the USRP==
You can quickly verify the operation of your USRP E31x by running the <code>rx_ascii_art_dft</code> UHD example program.
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.

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.

1. Attach an antenna to the RX2A antenna port of the E31x.

2. Log into the E31x from an external host computer over Ethernet using an SSH client.

3. At a terminal prompt running on the E31x, run:

/usr/lib/uhd/examples/rx_ascii_art_dft --freq 88.1e6 --rate 400e3 --gain 30 --ref-lvl -30

4. Modify the commandline argument "<code>freq</code>" above to specify a tuning frequency for a strong local FM radio station.

5. You should see a realtime FFT display of 400 KHz of spectrum, centered at the specified tuning frequency.

6. Type "<code>Q</code>" or <code>Ctrl-C</code> to stop the program and to return to the Linux command line.

7. You can adjust the size of your terminal window and then rerun the command to enlarge or shrink the FFT display.

8. You can run with the "help"option to see a description of all available commandline options.

Additional information is available at the [[Verifying the Operation of the USRP Using UHD and GNU Radio]] Application Note.

==Battery (E312 Only)==
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.

The status LED in the power button indicates the power and charge status of the battery:

Off: Indicates device is off and not charging.
*Slow Blinking Green: Indicates device is off and charging.
*Fast Blinking Green: Indicates device is on and charging.
*Solid Green: Indicates device is on and not charging (Battery is finished charging).
*Solid Orange: Indicates device is on and discharging.
*Fast Blinking Orange: Indicates device is on, discharging, and charge is below 10% charge.
*Fast Blinking Red: Indicates an error code:

#Low Voltage Error
#Regulator Low Voltage Error
#FPGA Power Error
#DRAM Power Error
#1.8V Power Rail Error
#3.3V Power Rail Error
#Daughterboard / TX Power Error
#Charger Error
#Charger Temperature Error
#Battery Low Error
#Fuel Gauge Temperature Error
#Global (Enclosure) Temperature Error

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.

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.

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.

If error codes persist after cooling down and/or recharging the USRP E312, please contact [mailto:support@ettus.com support@ettus.com].

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

An Application Note covering the replacement of the E312 battery can be found at [[USRP E312 Battery Replacement Instructions]].

==Battery Calibration Procedure==
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:

#Completely charge the battery.
#Type: <code>echo 3200000 >/sys/class/power_supply/BAT/charge_now</code>
#Unplug AC power.
#Replug AC power, and wait until charging completes.

==Battery Safety Information==
To ensure proper use of the battery, please read the the battery specification sheet. This document is available at: [[Media:34118 datasheet.pdf]]

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.

===Handling===
*Do not expose the battery to flame or dispose of it in a fire.
*Do not put the battery in a charger or equipment with the wrong terminals connected.
*Do not short circuit the battery.
*Avoid excessive physical shock or vibration.
*Do not disassemble or deform the battery.
*Do not immerse in water.
*Do not use the battery mixed with other different make, type, or model batteries.
*Keep out of the reach of children.
*Do not use the battery if it appears damaged.

===Charge and Discharge===
*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.
*Do not leave the battery charging for longer than 24 hours.
*Never use a modified or damaged USRP E312 DC power supply to charge the battery.

===Storage===
*Store the battery in a cool, dry, and well-ventilated area.

===Disposal===
*Regulations vary for different countries. Dispose of the battery in accordance with local regulations.

==Technical Support and Community Knowledge Base==
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.

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.

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

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

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

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

==Legal Considerations==
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.

*NOTE: This USRP product is a piece of test equipment.

==Sales and Ordering Support==
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.

==Terms and Conditions of Sale==
Terms and conditions of sale can be accessed online at the following link: http://www.ettus.com/legal/terms-and-conditions-of-sale

[[Category:Getting Started Guides]]
[[Category:E310]]
[[Category:E312]]
[[Category:E313]]

E320 Getting Started Guide

2023-09-25T20:33:08Z

JonathonPendlum: Fix commands for mender update -- missed a command to fix

==Kit Contents==

===E320 Board-only===
{|
|style="vertical-align:top"|
* USRP E320
* Power connector (assembly required)
* 4 M3x0.5, M3x5 Standoffs
* 1 Gb Ethernet Cat-5e Cable (3m)
* USB-A to Micro USB-B Cable (1m)
* 1 Gb SFP+ to RJ45 Adapter
* Getting Started Guide
* Ettus Research Sticker
|[[File:e320 board only.jpg|500px|center]]
|}

===E320 Full Enclosure===
{|
|style="vertical-align:top"|
* USRP E320 in enclosure
* DC Power Supply (12V, 7A)
* 1 Gb Ethernet Cat-5e Cable (3m)
* USB-A to Micro USB-B Cable (1m)
* 1 Gb SFP+ to RJ45 Adapter
* Getting Started Guide
* Ettus Research Sticker
* T8 Torx Wrench
|[[File:e320 enclosure kit.jpg|500px|center]]
|}

==Verify the Contents of Your Kit==
Ensure that your kit contains all the items listed above. If any items are missing, please contact sales@ettus.com immediately.

==You Will Need==

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

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

* 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

==Proper Care and Handling==
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.

* Never allow anything especially metal objects to touch the board while it is powered on.
* Always properly terminate the transmit port with an antenna or 50Ω load.
* Always handle the board with proper anti-static methods.
* Never allow the board to directly or indirectly come into contact with any voltage spikes.
* Never allow any water or condensing moisture to come into contact with the device.
* Always use caution with FPGA, firmware, or software modifications.
* Never touch the circuit board or heatsink while the device is powered on.
* All connections should be made/removed while is device is powered off.

{|
|style="padding-left:10px; padding-right:10px; padding-bottom:10px;" |[[File:Caution.png|24px|center]]
|style="padding-left:10px; padding-right:10px; padding-bottom:10px;" |Never apply more than -15 dBm of power into any RF input.
|-
|style="padding-left:10px; padding-right:10px; padding-bottom:10px;" |[[File:Caution.png|24px|center]]
|style="padding-left:10px; padding-right:10px; padding-bottom:10px;" |Always use at least 30dB attenuation if operating in loopback configuration
|-
|}

==Install and Setup the Software Tools on Your Host Computer==

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

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.

==Connecting the Device==
===Interfaces Overview===
Listed below are the interfaces to connect to the USRP E320. Each interface has specific functionality, limitations and purpose.

'''Serial Console'''

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.

'''1 Gb RJ45 Connection'''

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.

'''SFP+ Connection'''

The SFP+ Connection supports multiple interfaces for streaming high-speed, low-latency data, depending upon which FPGA image is loaded.

===Setting up a Serial Console Connection===
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.

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:

sudo apt install screen

The default Baud Rate for the Serial Console is: <code>115200</code>

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>:

$ ls /dev/serial/by-id
usb-FTDI_Dual_RS232-HS-if00-port0
usb-FTDI_Dual_RS232-HS-if01-port0
usb-Silicon_Labs_CP2105_Dual_USB_to_UART_Bridge_Controller_007F6A69-if00-port0
usb-Silicon_Labs_CP2105_Dual_USB_to_UART_Bridge_Controller_007F6A69-if01-port0

NOTE: Exact names depend on the host operating system version and may differ.

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

If you have multiple E320 Serial Consoles connected to a single host, you may have to empirically test nodes.

Connecting to the ARM CPU can be performed with the command:

$ sudo screen /dev/serial/by-id/usb-Silicon_Labs_CP2105_Dual_USB_to_UART_Bridge_Controller_007F6A69-if01-port0 115200

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:

Alchemy 2018.04 ni-e320-serial ttyPS0
ni-e320-serial login:

Enter the username: <code>root</code>

By default, the <code>root</code> user's password is left blank. Press the <code>Enter</code> key when prompted for a password.

You should now be presented with a shell prompt similar to the following:

root@ni-e320-<motherboard serial #>:~#

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.

===Connecting to the microcontroller===

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.

$ sudo screen /dev/serial/by-id/usb-Silicon_Labs_CP2105_Dual_USB_to_UART_Bridge_Controller_007F6A69-if00-port0 115200

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.

===Connecting to the ARM via SSH===
By default, the RJ45 1 Gb management interface is configured to be assigned a DHCP IP address.

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.

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>:

Example Output:

<pre>
# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.151/24 brd 192.168.1.255 scope global dynamic eth0
valid_lft 42865sec preferred_lft 42865sec
3: sfp0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8000 qdisc pfifo_fast qlen 1000
link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
inet 192.168.10.2/24 brd 192.168.10.255 scope global sfp0
valid_lft forever preferred_lft forever
</pre>

If you do not have access to a network with a DHCP server, you can create one using the Linux utility <code>dnsmasq</code>:

$ sudo dnsmasq -i <ETHERNET_ADAPTER_NAME> --dhcp-range=192.168.1.50,192.168.1.100 --except-interface=lo --bind-dynamic --no-daemon

NOTE: Modify the value <code><ETHERNET_ADAPTER_NAME></code> to match the interface you would like to create a DHCP server on.

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:

$ ssh root@192.168.1.51

NOTE: The IP address may vary depending on your network setup.

NOTE: The <code>root</code> password is empty/blank.

On Microsoft Windows, the SSH connection can be established using the third-party program, such as PuTTY.

After logging in, you should be presented with a shell prompt like the following:

root@ni-e320-<motherboard serial #>:~#

==Updating the Linux File System==
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.

There is two ways to update the file system for the E320 USRP:

1. Mender

2. Physically remove microSD card from device and write a new file system to the microSD card.

===File System Partition Layout===
The SD Card is divided into four partitions. There are two root file system partitions, a "boot" partition and a "data" partition.

Any data you would like to preserve through Mender updates should be saved to the "data" partition, which is mounted at <code>/data</code>.

===Updating the file system with Mender===
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.

====Mender Update Process====
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.

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.

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:

$ sudo uhd_images_downloader -t mender -t e320 --yes

Example Output:
[INFO] Using base URL: https://files.ettus.com/binaries/cache/
[INFO] Images destination: /usr/local/share/uhd/images
[INFO] No inventory file found at /usr/local/share/uhd/images/inventory.json. Creating an empty one.
301483 kB / 301483 kB (100%) e3xx_e320_mender_default-v4.4.0.0.zip
[INFO] Images download complete.

NOTE: In the output of the command, the folder destination where the images are saved is printed out.

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

$ scp /usr/local/share/uhd/images/usrp_e320_fs.mender root@192.168.1.51:~/.

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

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.

On the E320, run <code>mender install /path/to/latest.mender</code> to update the file system:

root@ni-e320-serial:~# mender install /home/root/usrp_e320_fs.mender

Example Output:

<pre>
root@ni-e320-316E375:~# mender install /home/root/usrp_e320_fs.mender
INFO[0000] Start updating from local image file: [/home/root/usrp_e320_fs.mender] module=rootfs
Installing update from the artifact of size 399640064
INFO[0000] opening device /dev/mmcblk0p3 for writing module=block_device
INFO[0000] partition /dev/mmcblk0p3 size: 2046820352 module=block_device
................................ 0% 1024 KiB
................................ 0% 2048 KiB
................................ 0% 3072 KiB
[truncated for readability]
................................ 99% 389120 KiB
................................ 99% 390144 KiB
................................ 100% 390273 KiB
INFO[0740] wrote 2046820352/2046820352 bytes of update to device /dev/mmcblk0p3 module=device
INFO[0744] Enabling partition with new image installed to be a boot candidate: 3 module=device

</pre>

The artifact can also be stored on a remote server:
$ mender install <http://server.name/path/to/latest.mender>

This procedure will take a few minutes to complete. After mender has logged a successful update, reboot the device:
$ reboot

If the reboot worked, and the device seems functional, commit the changes so that the boot loader knows to permanently boot into this partition:
$ mender -commit

To identify the currently installed Mender artifact from the command line, the following file can be queried on the E320:
$ cat /etc/mender/artifact_info

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.

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.

===Updating the files system by writing the disk image===
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.

NOTE: This method will overwrite all data saved on the microSD card, including any data saved to the <code>/data</code> partition.

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.

==Updating the Network Configurations==
The USRP E320 systemd network configuration files are located either at: <code>/etc/systemd/network/</code>

# ls /etc/systemd/network/
eth0.network sfp0.network

or for newer versions of the file system: <code>/data/network/</code>

# ls /data/network/
eth0.network int0.network sfp0.network

For details on configuration please refer to the [https://www.freedesktop.org/software/systemd/man/systemd.network.html systemd-networkd manual pages].

The factory settings are as follows:
<pre>
eth0 (DHCP):

[Match]
Name=eth0

[Network]
DHCP=v4

[DHCPv4]
UseHostname=false

sfp0 (static):

[Match]
Name=sfp0

[Network]
Address=192.168.10.2/24

[Link]
MTUBytes=8000
</pre>

Additional notes on networking:

* 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.
* 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.
* If the MTU of the device and host computers differ, streaming issues can occur.
* Streaming via SFP0 at 1 Gb rates requires a MTU of <code>1500</code>
* Streaming via SFP0 at 10 Gb rates requires a MTU of <code>8000</code>

For addition details on network configuration here: https://files.ettus.com/manual/page_usrp_e320.html#e320_network_configuration

==Updating the FPGA Image==

===Network mode FPGA Image Update===
The FPGA image should match the version of UHD installed on the host computer when operated in Network mode.

Network mode FPGA image updates must be made through the RJ45 management interface.

To obtain all the FPGA images for your installed version of UHD, run the following command on the host computer with internet access:

$ sudo uhd_images_downloader -t e320 -t fpga

Example Output:

$ uhd_images_downloader -t e320 -t fpga
[INFO] Images destination: /usr/local/share/uhd/images
[INFO] No inventory file found at /usr/local/share/uhd/images/inventory.json. Creating an empty one.
05920 kB / 05920 kB (100%) e3xx_e320_fpga_default-g494ae8bb.zip
[INFO] Images download complete.

There is two versions of the E320 FPGA images shipped with UHD:

- <code>1G</code> for 1 Gb rates on the SFP+ port (default image)

- <code>XG</code> for 10 Gb rates on the SFP+ port

In this example, we load the <code>XG</code> variant of the FPGA image.

$ uhd_image_loader --args "type=e3xx,mgmt_addr=<E320_RJ45_IP_ADDR>,fpga=XG"

Example Output:

$ uhd_image_loader --args "mgmt_addr=192.168.1.51,type=e3xx,fpga=XG"
[INFO] [UHD] linux; GNU C++ version 5.4.0 20160609; Boost_105800; UHD_3.13.1.0-1-gd3b7e90a
[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
[INFO] [MPMD] Claimed device without full initialization.
[INFO] [MPMD IMAGE LOADER] Starting update. This may take a while.
[INFO] [MPM.PeriphManager] Updating component `fpga'
[INFO] [MPM.PeriphManager] Updating component `dts'
[INFO] [MPM.RPCServer] Resetting peripheral manager.
[INFO] [MPM.PeriphManager] Device serial number: 316E375
[INFO] [MPMD IMAGE LOADER] Update component function succeeded.
[INFO] [MPM.PeriphManager] Found 1 daughterboard(s).

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.

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

To specify the path to a custom FPGA image, use the <code>--fpga-path</code> argument.

$ uhd_image_loader --args "type=e3xx,mgmt_addr=<E320_RJ45_IP_ADDR>" --fpga-path=/path/to/custom/fpga.bit

{|
|style="padding-left:10px; padding-right:10px; padding-bottom:10px;" |[[File:Caution.png|24px|center]]
|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.
|-
|}

===Embedded Mode FPGA Image Update===

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.

Run the command <code>uhd_images_downloader</code> to download the FPGA images to the device's file system:

NOTE: The 1 Gb RJ45 management interface will require Internet access for this next step.

<pre>
root@ni-e320-serial:~# python3 /usr/bin/uhd_images_downloader -t e320 -t fpga
[INFO] Images destination: /usr/share/uhd/images
[INFO] No inventory file found at /usr/share/uhd/images/inventory.json. Creating an empty one.
05920 kB / 05920 kB (100%) e3xx_e320_fpga_default-g494ae8bb.zip
[INFO] Images download complete.
</pre>

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

Updating the FPGA image from the ARM CPU is the same as detailed above for a Network mode update:

<pre>
root@ni-e320-serial:~# uhd_image_loader --args "type=e3xx,fpga=1G"
[INFO] [UHD] linux; GNU C++ version 7.3.0; Boost_106600; UHD_3.13.1.0-0-unknown
[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
[INFO] [MPM.PeriphManager.UDP] No CHDR interfaces found!
[INFO] [MPM.PeriphManager.UDP] No CHDR interfaces found!
[INFO] [MPMD] Claimed device without full initialization.
[INFO] [MPMD IMAGE LOADER] Starting update. This may take a while.
[INFO] [MPM.PeriphManager] Updating component `fpga'
[INFO] [MPM.PeriphManager] Updating component `dts'
[INFO] [MPM.RPCServer] Resetting peripheral manager.
[INFO] [MPM.PeriphManager] Device serial number: 316E375
[INFO] [MPMD IMAGE LOADER] Update component function succeeded.
[INFO] [MPM.PeriphManager] Found 1 daughterboard(s).

</pre>

For more information on updating the FPGA image, refer to the UHD Manual at http://uhd.ettus.com.

==Setting Up a Streaming Connection==
The device supports multiple high-speed, low-latency interfaces on the SFP+ port for streaming samples to the host computer.

===1 Gb Streaming via SFP+ Port ===
Complete the steps below to set up a streaming connection over the 1 Gb Ethernet interface on the <code>SFP+ Port</code>.

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.

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.

IP Address: 192.168.10.1
Subnet Mask: 255.255.255.0
Gateway: 0.0.0.0
MTU: 1500

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.

2. Insert the RJ45-to-SFP+ adapter into the <code>SFP+ Port</code>.

3. Connect the SFP+ adapter on the device to an Ethernet port on the host computer using a standard Ethernet cable.

The Green LED above the <code>SFP+ Port</code> should illuminate.

4. To test the connection, <code>ping</code> the device at address <code>192.168.10.2</code> from the host, as shown below:

$ ping 192.168.10.2
PING 192.168.10.2 (192.168.10.2) 56(84) bytes of data.
64 bytes from 192.168.10.2: icmp_seq=1 ttl=64 time=1.06 ms
^C
--- 192.168.10.2 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 1.065/1.065/1.065/0.000 ms

Press <code>CTRL+C</code> to stop the ping program.

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.

Proceed to the next section [[E320_Getting_Started_Guide#Verifying_Device_Operation|Verifying Device Operation]].

===10 Gb Streaming via SFP+ Port===
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.

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.

1. Configure your Host's 10 Gb Ethernet interface as shown below.

IP Address: 192.168.10.1
Subnet Mask: 255.255.255.0
Gateway: 0.0.0.0
MTU: 8000

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.

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.

The Green LED above the <code>SFP+ Port</code> should illuminate.

4. To test the connection, <code>ping</code> the device at address <code>192.168.10.2</code> from the host, as shown below:

$ ping 192.168.10.2
PING 192.168.10.2 (192.168.10.2) 56(84) bytes of data.
64 bytes from 192.168.10.2: icmp_seq=1 ttl=64 time=1.06 ms
^C
--- 192.168.10.2 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 1.065/1.065/1.065/0.000 ms

Press <code>CTRL+C</code> to stop the ping program.

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.

Proceed to the next section [[E320_Getting_Started_Guide#Verifying_Device_Operation|Verifying Device Operation]].

==Verifying Device Operation==
Once you have successfully setup a management interface and streaming interface, you can now verify the devices operation using the include UHD utilities.

===Subdevice Specification Mapping===
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.

'''E320'''
* RF A = A:0
* RF B = A:1

Additional details of UHD Subdevice Specifications can be found here in the UHD Manual: http://files.ettus.com/manual/page_configuration.html#config_subdev

===Supported Sample Rates===

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.

Sample rates as delivered to/from the host computer for USRP devices are constrained to follow several important rules.

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.

Additional information on Sample Rates can be found here in the UHD Manual: http://files.ettus.com/manual/page_general.html#general_sampleratenotes

===Probe the USRP E320===
The UHD utility <code>uhd_usrp_probe</code> provides detailed information of the USRP device.

From your host computer, run the command <code>uhd_usrp_probe</code>:

<pre>
$ uhd_usrp_probe --args "addr=192.168.10.2"
[INFO] [UHD] linux; GNU C++ version 5.4.0 20160609; Boost_105800; UHD_3.13.1.0-1-gd3b7e90a
[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
[INFO] [MPM.PeriphManager] init() called with device args `product=e320,mgmt_addr=192.168.10.2'.
[INFO] [0/DmaFIFO_0] Initializing block control (NOC ID: 0xF1F0D00000000000)
[INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1343 MB/s)
[INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1335 MB/s)
[INFO] [0/Radio_0] Initializing block control (NOC ID: 0x12AD100000003320)
[INFO] [0/DDC_0] Initializing block control (NOC ID: 0xDDC0000000000000)
[INFO] [0/DUC_0] Initializing block control (NOC ID: 0xD0C0000000000002)
[INFO] [0/Radio_0] Performing CODEC loopback test...
[INFO] [0/Radio_0] CODEC loopback test passed
[INFO] [0/Radio_0] Performing CODEC loopback test...
[INFO] [0/Radio_0] CODEC loopback test passed
_____________________________________________________
/
| Device: E300-Series Device
| _____________________________________________________
| /
| | Mboard: ni-e320-316E375
| | eeprom_version: 2
| | mpm_version: 3.13.1.0-gd3b7e90a
| | pid: 58144
| | product: e320
| | rev: 2
| | rpc_connection: remote
| | serial: 316E375
| | type: e3xx
| | MPM Version: 1.2
| | FPGA Version: 3.0
| | RFNoC capable: Yes
| |
| | Time sources: internal, external, gpsdo
| | Clock sources: external, internal, gpsdo
| | 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
| | _____________________________________________________
| | /
| | | RX Dboard: A
| | | _____________________________________________________
| | | /
| | | | RX Frontend: 0
| | | | Name: Neon
| | | | Antennas: RX2, TX/RX
| | | | Sensors: lo_locked, ad9361_temperature, rssi, lo_lock
| | | | Freq range: 70.000 to 6000.000 MHz
| | | | Gain range PGA: 0.0 to 76.0 step 1.0 dB
| | | | Bandwidth range: 20000000.0 to 40000000.0 step 0.0 Hz
| | | | Connection Type: IQ
| | | | Uses LO offset: No
| | | _____________________________________________________
| | | /
| | | | RX Frontend: 1
| | | | Name: Neon
| | | | Antennas: RX2, TX/RX
| | | | Sensors: lo_locked, ad9361_temperature, rssi, lo_lock
| | | | Freq range: 70.000 to 6000.000 MHz
| | | | Gain range PGA: 0.0 to 76.0 step 1.0 dB
| | | | Bandwidth range: 20000000.0 to 40000000.0 step 0.0 Hz
| | | | Connection Type: IQ
| | | | Uses LO offset: No
| | | _____________________________________________________
| | | /
| | | | RX Codec: A
| | | | Name: AD9361 Dual ADC
| | | | Gain Elements: None
| | _____________________________________________________
| | /
| | | TX Dboard: A
| | | _____________________________________________________
| | | /
| | | | TX Frontend: 0
| | | | Name: Neon
| | | | Antennas: TX/RX
| | | | Sensors: lo_locked, ad9361_temperature
| | | | Freq range: 47.000 to 6000.000 MHz
| | | | Gain range PGA: 0.0 to 89.8 step 0.2 dB
| | | | Bandwidth range: 20000000.0 to 40000000.0 step 0.0 Hz
| | | | Connection Type: IQ
| | | | Uses LO offset: No
| | | _____________________________________________________
| | | /
| | | | TX Frontend: 1
| | | | Name: Neon
| | | | Antennas: TX/RX
| | | | Sensors: lo_locked, ad9361_temperature
| | | | Freq range: 47.000 to 6000.000 MHz
| | | | Gain range PGA: 0.0 to 89.8 step 0.2 dB
| | | | Bandwidth range: 20000000.0 to 40000000.0 step 0.0 Hz
| | | | Connection Type: IQ
| | | | Uses LO offset: No
| | | _____________________________________________________
| | | /
| | | | TX Codec: A
| | | | Name: AD9361 Dual DAC
| | | | Gain Elements: None
| | _____________________________________________________
| | /
| | | RFNoC blocks on this device:
| | |
| | | * DmaFIFO_0
| | | * Radio_0
| | | * DDC_0
| | | * DUC_0

</pre>

===ASCII Art Example===
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

You can quickly verify the operation of your USRP E320 by running the <code>rx_ascii_art_dft</code> UHD example program.

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.

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:

1. Attach an antenna to the <code>RF A / RX2</code> antenna port of the E320.

2. From your host computer, run the command:

$ /usr/local/lib/uhd/examples/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"

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.

3. You should see a real-time FFT display of 2 MHz of spectrum, centered at the specified tuning frequency.

4. Type "<code>Q</code>" to stop the program and to return to the Linux command line.

5. You can run with the <code>--help</code> argument to see a description of all available command-line options.

Example Output:

<pre>
$ ./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"

Creating the usrp device with: addr=192.168.10.2...
[INFO] [UHD] linux; GNU C++ version 5.4.0 20160609; Boost_105800; UHD_3.13.1.0-1-gd3b7e90a
[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
[INFO] [0/DmaFIFO_0] Initializing block control (NOC ID: 0xF1F0D00000000000)
[INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1334 MB/s)
[INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1325 MB/s)
[INFO] [0/Radio_0] Initializing block control (NOC ID: 0x12AD100000003320)
[INFO] [0/DDC_0] Initializing block control (NOC ID: 0xDDC0000000000000)
[INFO] [0/DUC_0] Initializing block control (NOC ID: 0xD0C0000000000002)
[INFO] [MPM.PeriphManager] init() called with device args `product=e320,mgmt_addr=192.168.10.2'.
[INFO] [0/Radio_0] Performing CODEC loopback test...
[INFO] [0/Radio_0] CODEC loopback test passed
[INFO] [0/Radio_0] Performing CODEC loopback test...
[INFO] [0/Radio_0] CODEC loopback test passed
Using Device: Single USRP:
Device: E300-Series Device
Mboard 0: ni-e320-316E375
RX Channel: 0
RX DSP: 0
RX Dboard: A
RX Subdev: Neon
TX Channel: 0
TX DSP: 0
TX Dboard: A
TX Subdev: Neon
TX Channel: 1
TX DSP: 1
TX Dboard: A
TX Subdev: Neon

Setting RX Rate: 2.000000 Msps...
Actual RX Rate: 2.000000 Msps...

Setting RX Freq: 98.500000 MHz...
Actual RX Freq: 98.500000 MHz...

Setting RX Gain: 40.000000 dB...
Actual RX Gain: 40.000000 dB...

Checking RX: all_los: locked ...

Done!
</pre>

===Benchmarking your system===
Included with the UHD driver example programs is a utility, <code>benchmark_rate</code> to benchmark the transport link of the system.

A system's maximum performance is dependent upon many factors. <code>benchmark_rate</code> will exercise the transport link and CPU of the system.

====1 Gb Interface====
NOTE: This example requires the <code>1G</code> FPGA image to be loaded.

This example will test one full-duplex stream using "RFA/A:0", at a rate of 2 MS/s, for 60 seconds:

/usr/local/lib/uhd/examples/benchmark_rate \
--args "addr=192.168.10.2" \
--duration 60 \
--channels "0" \
--rx_rate 2e6 \
--rx_subdev "A:0" \
--tx_rate 2e6 \
--tx_subdev "A:0"

This example will test two full-duplex streams at 2 MS/s, for 60 seconds:

/usr/local/lib/uhd/examples/benchmark_rate \
--args "addr=192.168.10.2" \
--duration 60 \
--channels "0,1" \
--rx_rate 2e6 \
--rx_subdev "A:0 A:1" \
--tx_rate 2e6 \
--tx_subdev "A:0 A:1"

This example will test two full-duplex streams at 12.5 MS/s, for 60 seconds:

/usr/local/lib/uhd/examples/benchmark_rate \
--args "addr=192.168.10.2,master_clock_rate=25e6" \
--duration 60 \
--channels "0,1" \
--rx_rate 12.5e6 \
--rx_subdev "A:0 A:1" \
--tx_rate 12.5e6 \
--tx_subdev "A:0 A:1"

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.

====10 Gb Interface ====
NOTE: These examples require the <code>XG</code> FPGA image to be loaded.

This example will test one full-duplex stream using "RFA/A:0", at a rate of 61.44 MS/s, for 60 seconds:

/usr/local/lib/uhd/examples/benchmark_rate \
--args "addr=192.168.10.2,master_clock_rate=61.44e6" \
--duration 60 \
--channels "0" \
--rx_rate 61.44e6 \
--rx_subdev "A:0" \
--tx_rate 61.44e6 \
--tx_subdev "A:0"

This example will test two full-duplex stream, at a rate of 30.72 MS/s, for 60 seconds:

/usr/local/lib/uhd/examples/benchmark_rate \
--args "addr=192.168.10.2,master_clock_rate=61.44e6" \
--duration 60 \
--channels "0,1" \
--rx_rate 30.72e6 \
--rx_subdev "A:0 A:1" \
--tx_rate 30.72e6 \
--tx_subdev "A:0 A:1"

==USRP E320 Device Specific Operations==

===Turning the Device Off/On===
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:

shutdown -h now

=== Autoboot ===

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.

For example
<pre>
root@ni-e320-XXXXXXX:~# eeprom-dump
-- PID/REV: e320 0002
-- MCU_FLAGS[0]: 00000008
-- MCU_FLAGS[1]: 00000000
-- MCU_FLAGS[2]: 00000000
-- MCU_FLAGS[3]: 00000000
-- Serial: XXXXXXX
-- eth_addr0: XX:XX:XX:XX:XX:XX
-- eth_addr1: XX:XX:XX:XX:XX:XX
-- eth_addr2: XX:XX:XX:XX:XX:XX
-- DT-Compat/MCU-Compat: 0000 0002
-- CRC: cbd79a61 (matches)
</pre>
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).

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:

* Disable autoboot on USRP E320 (sets least significant bit to 0), regardless of whether currently enabled or disabled:
<pre>
root@ni-e320-XXXXXXX:~# eeprom-set-flags $((0x<MCU_FLAGS[0]> & ~0x1))
</pre>
Thus, for the value noted above (autoboot is already disabled, so this command doesn't actually change anything):
<pre>
root@ni-e320-XXXXXXX:~# eeprom-set-flags $((0x00000008 & ~0x1))
-- PID/REV: e320 0002
-- MCU_FLAGS[0]: 00000008
-- MCU_FLAGS[1]: 00000000
-- MCU_FLAGS[2]: 00000000
-- MCU_FLAGS[3]: 00000000
-- Serial: XXXXXXX
-- eth_addr0: XX:XX:XX:XX:XX:XX
-- eth_addr1: XX:XX:XX:XX:XX:XX
-- eth_addr2: XX:XX:XX:XX:XX:XX
-- DT-Compat/MCU-Compat: 0000 0002
-- CRC: cbd79a61 (matches)
-- Reading back
-- PID/REV: e320 0002
-- MCU_FLAGS[0]: 00000008
-- MCU_FLAGS[1]: 00000000
-- MCU_FLAGS[2]: 00000000
-- MCU_FLAGS[3]: 00000000
-- Serial: XXXXXXX
-- eth_addr0: XX:XX:XX:XX:XX:XX
-- eth_addr1: XX:XX:XX:XX:XX:XX
-- eth_addr2: XX:XX:XX:XX:XX:XX
-- DT-Compat/MCU-Compat: 0000 0002
-- CRC: 448fb572 (matches)
</pre>

* 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:
<pre>
root@ni-e320-XXXXXXX:~# eeprom-set-flags $((0x<MCU_FLAGS[0]> | 0x1))
</pre>
Thus, for the value noted above:
<pre>
root@ni-e320-XXXXXXX:~# eeprom-set-flags $((0x00000008 | 0x1))
-- PID/REV: e320 0002
-- MCU_FLAGS[0]: 00000008
-- MCU_FLAGS[1]: 00000000
-- MCU_FLAGS[2]: 00000000
-- MCU_FLAGS[3]: 00000000
-- Serial: XXXXXXX
-- eth_addr0: XX:XX:XX:XX:XX:XX
-- eth_addr1: XX:XX:XX:XX:XX:XX
-- eth_addr2: XX:XX:XX:XX:XX:XX
-- DT-Compat/MCU-Compat: 0000 0002
-- CRC: cbd79a61 (matches)
-- Reading back
-- PID/REV: e320 0002
-- MCU_FLAGS[0]: 00000009
-- MCU_FLAGS[1]: 00000000
-- MCU_FLAGS[2]: 00000000
-- MCU_FLAGS[3]: 00000000
-- Serial: XXXXXXX
-- eth_addr0: XX:XX:XX:XX:XX:XX
-- eth_addr1: XX:XX:XX:XX:XX:XX
-- eth_addr2: XX:XX:XX:XX:XX:XX
-- DT-Compat/MCU-Compat: 0000 0002
-- CRC: 448fb572 (matches)
</pre>

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.

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:
<pre>
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 -
</pre>
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:
<pre>
root@ni-e320-XXXXXXX:~# cd upgrade_mcu_neon_v1.1.7358-a190641-musl-glibc-rev3-6
root@ni-e320-XXXXXXX:~/upgrade_mcu_neon_v1.1.7358-a190641-musl-glibc-rev3-6# ./flash-firmware.sh
This script updates the microcontroller firmware (RO part). The change is
persistent across power cycles. Incorrect updates can only fixed be a manual
process which requires opening the enclosure.

Updating the microcontroller firmware (RO part) is only required if the Ettus
Research support told you to do so.

Press "y" to continue
</pre>
At the prompt, press the <code>y</code> key to continue. Pressing any other key aborts the procedure:
<pre>
Press "y" to continue n

aborting
root@ni-e320-317F9BF:~/upgrade_mcu_neon_v1.1.7358-a190641-musl-glibc-rev3-6#
</pre>
Pressing the <code>y</code> key:
<pre>
Press "y" to continue y

This script will flash ec-neon-rev3.RO.flat to the device
old RO version: neon_vX.X.XXXX-XXXXXXX
new RO version: neon_v1.1.7358-a190641

Press "y" to continue
</pre>
At the prompt, press the <code>y</code> key ''again'' to continue. Pressing any other key aborts the procedure as before.
<pre>
Press "y" to continue y

./ectool --interface=dev reboot_ec RW
./ectool --interface=dev flashread 0x0 65536 ec-neon-rev3.RO.flat.old
Reading 65536 bytes at offset 0...
done.
./ectool --interface=dev flasherase 0x0 65536
Erasing 65536 bytes at offset 0...
done.
./ectool --interface=dev flashwrite 0x0 ec-neon-rev3.RO.flat
Reading 49592 bytes from ec-neon-rev3.RO.flat...
Writing to offset 0...
Write size 112...
done.

copying new firmware files
'ec-neon-rev3.bin' -> '/lib/firmware/ni/ec-neon-rev3.bin'
'ec-neon-rev3.RW.bin' -> '/lib/firmware/ni/ec-neon-rev3.RW.bin'
root@ni-e320-317F9BF:~/upgrade_mcu_neon_v1.1.7358-a190641-musl-glibc-rev3-6#
</pre>

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.

===Default Password===
The default user is <code>root</code> and the password is empty (no password).

It is recommended to update the <code>root</code> password, which can be done with the command <code>passwd</code>:

Example Output:

root@ni-e320-serial:~# passwd
Changing password for root
New password:
Re-enter new password:
passwd: password changed.

==Known Issues==
===Problematic NICs===
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.

==Technical Support and Community Knowledge Base==
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.

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.

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

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

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

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

==Legal Considerations==
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.

*NOTE: This USRP product is a piece of test equipment.

==Sales and Ordering Support==
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.

==Terms and Conditions of Sale==
Terms and conditions of sale can be accessed online at the following link: http://www.ettus.com/legal/terms-and-conditions-of-sale

[[Category:Getting Started Guides]]
[[Category:E320]]

E320 Getting Started Guide

2023-09-25T20:31:07Z

JonathonPendlum: Fix commands for mender update

==Kit Contents==

===E320 Board-only===
{|
|style="vertical-align:top"|
* USRP E320
* Power connector (assembly required)
* 4 M3x0.5, M3x5 Standoffs
* 1 Gb Ethernet Cat-5e Cable (3m)
* USB-A to Micro USB-B Cable (1m)
* 1 Gb SFP+ to RJ45 Adapter
* Getting Started Guide
* Ettus Research Sticker
|[[File:e320 board only.jpg|500px|center]]
|}

===E320 Full Enclosure===
{|
|style="vertical-align:top"|
* USRP E320 in enclosure
* DC Power Supply (12V, 7A)
* 1 Gb Ethernet Cat-5e Cable (3m)
* USB-A to Micro USB-B Cable (1m)
* 1 Gb SFP+ to RJ45 Adapter
* Getting Started Guide
* Ettus Research Sticker
* T8 Torx Wrench
|[[File:e320 enclosure kit.jpg|500px|center]]
|}

==Verify the Contents of Your Kit==
Ensure that your kit contains all the items listed above. If any items are missing, please contact sales@ettus.com immediately.

==You Will Need==

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

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

* 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

==Proper Care and Handling==
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.

* Never allow anything especially metal objects to touch the board while it is powered on.
* Always properly terminate the transmit port with an antenna or 50Ω load.
* Always handle the board with proper anti-static methods.
* Never allow the board to directly or indirectly come into contact with any voltage spikes.
* Never allow any water or condensing moisture to come into contact with the device.
* Always use caution with FPGA, firmware, or software modifications.
* Never touch the circuit board or heatsink while the device is powered on.
* All connections should be made/removed while is device is powered off.

{|
|style="padding-left:10px; padding-right:10px; padding-bottom:10px;" |[[File:Caution.png|24px|center]]
|style="padding-left:10px; padding-right:10px; padding-bottom:10px;" |Never apply more than -15 dBm of power into any RF input.
|-
|style="padding-left:10px; padding-right:10px; padding-bottom:10px;" |[[File:Caution.png|24px|center]]
|style="padding-left:10px; padding-right:10px; padding-bottom:10px;" |Always use at least 30dB attenuation if operating in loopback configuration
|-
|}

==Install and Setup the Software Tools on Your Host Computer==

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

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.

==Connecting the Device==
===Interfaces Overview===
Listed below are the interfaces to connect to the USRP E320. Each interface has specific functionality, limitations and purpose.

'''Serial Console'''

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.

'''1 Gb RJ45 Connection'''

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.

'''SFP+ Connection'''

The SFP+ Connection supports multiple interfaces for streaming high-speed, low-latency data, depending upon which FPGA image is loaded.

===Setting up a Serial Console Connection===
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.

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:

sudo apt install screen

The default Baud Rate for the Serial Console is: <code>115200</code>

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>:

$ ls /dev/serial/by-id
usb-FTDI_Dual_RS232-HS-if00-port0
usb-FTDI_Dual_RS232-HS-if01-port0
usb-Silicon_Labs_CP2105_Dual_USB_to_UART_Bridge_Controller_007F6A69-if00-port0
usb-Silicon_Labs_CP2105_Dual_USB_to_UART_Bridge_Controller_007F6A69-if01-port0

NOTE: Exact names depend on the host operating system version and may differ.

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

If you have multiple E320 Serial Consoles connected to a single host, you may have to empirically test nodes.

Connecting to the ARM CPU can be performed with the command:

$ sudo screen /dev/serial/by-id/usb-Silicon_Labs_CP2105_Dual_USB_to_UART_Bridge_Controller_007F6A69-if01-port0 115200

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:

Alchemy 2018.04 ni-e320-serial ttyPS0
ni-e320-serial login:

Enter the username: <code>root</code>

By default, the <code>root</code> user's password is left blank. Press the <code>Enter</code> key when prompted for a password.

You should now be presented with a shell prompt similar to the following:

root@ni-e320-<motherboard serial #>:~#

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.

===Connecting to the microcontroller===

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.

$ sudo screen /dev/serial/by-id/usb-Silicon_Labs_CP2105_Dual_USB_to_UART_Bridge_Controller_007F6A69-if00-port0 115200

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.

===Connecting to the ARM via SSH===
By default, the RJ45 1 Gb management interface is configured to be assigned a DHCP IP address.

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.

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>:

Example Output:

<pre>
# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.151/24 brd 192.168.1.255 scope global dynamic eth0
valid_lft 42865sec preferred_lft 42865sec
3: sfp0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8000 qdisc pfifo_fast qlen 1000
link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
inet 192.168.10.2/24 brd 192.168.10.255 scope global sfp0
valid_lft forever preferred_lft forever
</pre>

If you do not have access to a network with a DHCP server, you can create one using the Linux utility <code>dnsmasq</code>:

$ sudo dnsmasq -i <ETHERNET_ADAPTER_NAME> --dhcp-range=192.168.1.50,192.168.1.100 --except-interface=lo --bind-dynamic --no-daemon

NOTE: Modify the value <code><ETHERNET_ADAPTER_NAME></code> to match the interface you would like to create a DHCP server on.

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:

$ ssh root@192.168.1.51

NOTE: The IP address may vary depending on your network setup.

NOTE: The <code>root</code> password is empty/blank.

On Microsoft Windows, the SSH connection can be established using the third-party program, such as PuTTY.

After logging in, you should be presented with a shell prompt like the following:

root@ni-e320-<motherboard serial #>:~#

==Updating the Linux File System==
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.

There is two ways to update the file system for the E320 USRP:

1. Mender

2. Physically remove microSD card from device and write a new file system to the microSD card.

===File System Partition Layout===
The SD Card is divided into four partitions. There are two root file system partitions, a "boot" partition and a "data" partition.

Any data you would like to preserve through Mender updates should be saved to the "data" partition, which is mounted at <code>/data</code>.

===Updating the file system with Mender===
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.

====Mender Update Process====
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.

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.

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:

$ sudo uhd_images_downloader -t mender -t e320 --yes

Example Output:
[INFO] Using base URL: https://files.ettus.com/binaries/cache/
[INFO] Images destination: /usr/local/share/uhd/images
[INFO] No inventory file found at /usr/local/share/uhd/images/inventory.json. Creating an empty one.
301483 kB / 301483 kB (100%) e3xx_e320_mender_default-v4.4.0.0.zip
[INFO] Images download complete.

NOTE: In the output of the command, the folder destination where the images are saved is printed out.

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

$ scp /usr/local/share/uhd/images/usrp_e320_fs.mender root@192.168.1.51:~/.

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

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.

On the E320, run <code>mender install /path/to/latest.mender</code> to update the file system:

root@ni-e320-serial:~# mender install /home/root/usrp_e320_fs.mender

Example Output:

<pre>
root@ni-e320-316E375:~# mender -rootfs /home/root/usrp_e320_fs.mender
INFO[0000] Start updating from local image file: [/home/root/usrp_e320_fs.mender] module=rootfs
Installing update from the artifact of size 399640064
INFO[0000] opening device /dev/mmcblk0p3 for writing module=block_device
INFO[0000] partition /dev/mmcblk0p3 size: 2046820352 module=block_device
................................ 0% 1024 KiB
................................ 0% 2048 KiB
................................ 0% 3072 KiB
[truncated for readability]
................................ 99% 389120 KiB
................................ 99% 390144 KiB
................................ 100% 390273 KiB
INFO[0740] wrote 2046820352/2046820352 bytes of update to device /dev/mmcblk0p3 module=device
INFO[0744] Enabling partition with new image installed to be a boot candidate: 3 module=device

</pre>

The artifact can also be stored on a remote server:
$ mender install <http://server.name/path/to/latest.mender>

This procedure will take a few minutes to complete. After mender has logged a successful update, reboot the device:
$ reboot

If the reboot worked, and the device seems functional, commit the changes so that the boot loader knows to permanently boot into this partition:
$ mender -commit

To identify the currently installed Mender artifact from the command line, the following file can be queried on the E320:
$ cat /etc/mender/artifact_info

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.

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.

===Updating the files system by writing the disk image===
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.

NOTE: This method will overwrite all data saved on the microSD card, including any data saved to the <code>/data</code> partition.

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.

==Updating the Network Configurations==
The USRP E320 systemd network configuration files are located either at: <code>/etc/systemd/network/</code>

# ls /etc/systemd/network/
eth0.network sfp0.network

or for newer versions of the file system: <code>/data/network/</code>

# ls /data/network/
eth0.network int0.network sfp0.network

For details on configuration please refer to the [https://www.freedesktop.org/software/systemd/man/systemd.network.html systemd-networkd manual pages].

The factory settings are as follows:
<pre>
eth0 (DHCP):

[Match]
Name=eth0

[Network]
DHCP=v4

[DHCPv4]
UseHostname=false

sfp0 (static):

[Match]
Name=sfp0

[Network]
Address=192.168.10.2/24

[Link]
MTUBytes=8000
</pre>

Additional notes on networking:

* 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.
* 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.
* If the MTU of the device and host computers differ, streaming issues can occur.
* Streaming via SFP0 at 1 Gb rates requires a MTU of <code>1500</code>
* Streaming via SFP0 at 10 Gb rates requires a MTU of <code>8000</code>

For addition details on network configuration here: https://files.ettus.com/manual/page_usrp_e320.html#e320_network_configuration

==Updating the FPGA Image==

===Network mode FPGA Image Update===
The FPGA image should match the version of UHD installed on the host computer when operated in Network mode.

Network mode FPGA image updates must be made through the RJ45 management interface.

To obtain all the FPGA images for your installed version of UHD, run the following command on the host computer with internet access:

$ sudo uhd_images_downloader -t e320 -t fpga

Example Output:

$ uhd_images_downloader -t e320 -t fpga
[INFO] Images destination: /usr/local/share/uhd/images
[INFO] No inventory file found at /usr/local/share/uhd/images/inventory.json. Creating an empty one.
05920 kB / 05920 kB (100%) e3xx_e320_fpga_default-g494ae8bb.zip
[INFO] Images download complete.

There is two versions of the E320 FPGA images shipped with UHD:

- <code>1G</code> for 1 Gb rates on the SFP+ port (default image)

- <code>XG</code> for 10 Gb rates on the SFP+ port

In this example, we load the <code>XG</code> variant of the FPGA image.

$ uhd_image_loader --args "type=e3xx,mgmt_addr=<E320_RJ45_IP_ADDR>,fpga=XG"

Example Output:

$ uhd_image_loader --args "mgmt_addr=192.168.1.51,type=e3xx,fpga=XG"
[INFO] [UHD] linux; GNU C++ version 5.4.0 20160609; Boost_105800; UHD_3.13.1.0-1-gd3b7e90a
[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
[INFO] [MPMD] Claimed device without full initialization.
[INFO] [MPMD IMAGE LOADER] Starting update. This may take a while.
[INFO] [MPM.PeriphManager] Updating component `fpga'
[INFO] [MPM.PeriphManager] Updating component `dts'
[INFO] [MPM.RPCServer] Resetting peripheral manager.
[INFO] [MPM.PeriphManager] Device serial number: 316E375
[INFO] [MPMD IMAGE LOADER] Update component function succeeded.
[INFO] [MPM.PeriphManager] Found 1 daughterboard(s).

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.

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

To specify the path to a custom FPGA image, use the <code>--fpga-path</code> argument.

$ uhd_image_loader --args "type=e3xx,mgmt_addr=<E320_RJ45_IP_ADDR>" --fpga-path=/path/to/custom/fpga.bit

{|
|style="padding-left:10px; padding-right:10px; padding-bottom:10px;" |[[File:Caution.png|24px|center]]
|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.
|-
|}

===Embedded Mode FPGA Image Update===

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.

Run the command <code>uhd_images_downloader</code> to download the FPGA images to the device's file system:

NOTE: The 1 Gb RJ45 management interface will require Internet access for this next step.

<pre>
root@ni-e320-serial:~# python3 /usr/bin/uhd_images_downloader -t e320 -t fpga
[INFO] Images destination: /usr/share/uhd/images
[INFO] No inventory file found at /usr/share/uhd/images/inventory.json. Creating an empty one.
05920 kB / 05920 kB (100%) e3xx_e320_fpga_default-g494ae8bb.zip
[INFO] Images download complete.
</pre>

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

Updating the FPGA image from the ARM CPU is the same as detailed above for a Network mode update:

<pre>
root@ni-e320-serial:~# uhd_image_loader --args "type=e3xx,fpga=1G"
[INFO] [UHD] linux; GNU C++ version 7.3.0; Boost_106600; UHD_3.13.1.0-0-unknown
[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
[INFO] [MPM.PeriphManager.UDP] No CHDR interfaces found!
[INFO] [MPM.PeriphManager.UDP] No CHDR interfaces found!
[INFO] [MPMD] Claimed device without full initialization.
[INFO] [MPMD IMAGE LOADER] Starting update. This may take a while.
[INFO] [MPM.PeriphManager] Updating component `fpga'
[INFO] [MPM.PeriphManager] Updating component `dts'
[INFO] [MPM.RPCServer] Resetting peripheral manager.
[INFO] [MPM.PeriphManager] Device serial number: 316E375
[INFO] [MPMD IMAGE LOADER] Update component function succeeded.
[INFO] [MPM.PeriphManager] Found 1 daughterboard(s).

</pre>

For more information on updating the FPGA image, refer to the UHD Manual at http://uhd.ettus.com.

==Setting Up a Streaming Connection==
The device supports multiple high-speed, low-latency interfaces on the SFP+ port for streaming samples to the host computer.

===1 Gb Streaming via SFP+ Port ===
Complete the steps below to set up a streaming connection over the 1 Gb Ethernet interface on the <code>SFP+ Port</code>.

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.

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.

IP Address: 192.168.10.1
Subnet Mask: 255.255.255.0
Gateway: 0.0.0.0
MTU: 1500

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.

2. Insert the RJ45-to-SFP+ adapter into the <code>SFP+ Port</code>.

3. Connect the SFP+ adapter on the device to an Ethernet port on the host computer using a standard Ethernet cable.

The Green LED above the <code>SFP+ Port</code> should illuminate.

4. To test the connection, <code>ping</code> the device at address <code>192.168.10.2</code> from the host, as shown below:

$ ping 192.168.10.2
PING 192.168.10.2 (192.168.10.2) 56(84) bytes of data.
64 bytes from 192.168.10.2: icmp_seq=1 ttl=64 time=1.06 ms
^C
--- 192.168.10.2 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 1.065/1.065/1.065/0.000 ms

Press <code>CTRL+C</code> to stop the ping program.

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.

Proceed to the next section [[E320_Getting_Started_Guide#Verifying_Device_Operation|Verifying Device Operation]].

===10 Gb Streaming via SFP+ Port===
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.

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.

1. Configure your Host's 10 Gb Ethernet interface as shown below.

IP Address: 192.168.10.1
Subnet Mask: 255.255.255.0
Gateway: 0.0.0.0
MTU: 8000

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.

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.

The Green LED above the <code>SFP+ Port</code> should illuminate.

4. To test the connection, <code>ping</code> the device at address <code>192.168.10.2</code> from the host, as shown below:

$ ping 192.168.10.2
PING 192.168.10.2 (192.168.10.2) 56(84) bytes of data.
64 bytes from 192.168.10.2: icmp_seq=1 ttl=64 time=1.06 ms
^C
--- 192.168.10.2 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 1.065/1.065/1.065/0.000 ms

Press <code>CTRL+C</code> to stop the ping program.

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.

Proceed to the next section [[E320_Getting_Started_Guide#Verifying_Device_Operation|Verifying Device Operation]].

==Verifying Device Operation==
Once you have successfully setup a management interface and streaming interface, you can now verify the devices operation using the include UHD utilities.

===Subdevice Specification Mapping===
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.

'''E320'''
* RF A = A:0
* RF B = A:1

Additional details of UHD Subdevice Specifications can be found here in the UHD Manual: http://files.ettus.com/manual/page_configuration.html#config_subdev

===Supported Sample Rates===

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.

Sample rates as delivered to/from the host computer for USRP devices are constrained to follow several important rules.

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.

Additional information on Sample Rates can be found here in the UHD Manual: http://files.ettus.com/manual/page_general.html#general_sampleratenotes

===Probe the USRP E320===
The UHD utility <code>uhd_usrp_probe</code> provides detailed information of the USRP device.

From your host computer, run the command <code>uhd_usrp_probe</code>:

<pre>
$ uhd_usrp_probe --args "addr=192.168.10.2"
[INFO] [UHD] linux; GNU C++ version 5.4.0 20160609; Boost_105800; UHD_3.13.1.0-1-gd3b7e90a
[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
[INFO] [MPM.PeriphManager] init() called with device args `product=e320,mgmt_addr=192.168.10.2'.
[INFO] [0/DmaFIFO_0] Initializing block control (NOC ID: 0xF1F0D00000000000)
[INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1343 MB/s)
[INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1335 MB/s)
[INFO] [0/Radio_0] Initializing block control (NOC ID: 0x12AD100000003320)
[INFO] [0/DDC_0] Initializing block control (NOC ID: 0xDDC0000000000000)
[INFO] [0/DUC_0] Initializing block control (NOC ID: 0xD0C0000000000002)
[INFO] [0/Radio_0] Performing CODEC loopback test...
[INFO] [0/Radio_0] CODEC loopback test passed
[INFO] [0/Radio_0] Performing CODEC loopback test...
[INFO] [0/Radio_0] CODEC loopback test passed
_____________________________________________________
/
| Device: E300-Series Device
| _____________________________________________________
| /
| | Mboard: ni-e320-316E375
| | eeprom_version: 2
| | mpm_version: 3.13.1.0-gd3b7e90a
| | pid: 58144
| | product: e320
| | rev: 2
| | rpc_connection: remote
| | serial: 316E375
| | type: e3xx
| | MPM Version: 1.2
| | FPGA Version: 3.0
| | RFNoC capable: Yes
| |
| | Time sources: internal, external, gpsdo
| | Clock sources: external, internal, gpsdo
| | 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
| | _____________________________________________________
| | /
| | | RX Dboard: A
| | | _____________________________________________________
| | | /
| | | | RX Frontend: 0
| | | | Name: Neon
| | | | Antennas: RX2, TX/RX
| | | | Sensors: lo_locked, ad9361_temperature, rssi, lo_lock
| | | | Freq range: 70.000 to 6000.000 MHz
| | | | Gain range PGA: 0.0 to 76.0 step 1.0 dB
| | | | Bandwidth range: 20000000.0 to 40000000.0 step 0.0 Hz
| | | | Connection Type: IQ
| | | | Uses LO offset: No
| | | _____________________________________________________
| | | /
| | | | RX Frontend: 1
| | | | Name: Neon
| | | | Antennas: RX2, TX/RX
| | | | Sensors: lo_locked, ad9361_temperature, rssi, lo_lock
| | | | Freq range: 70.000 to 6000.000 MHz
| | | | Gain range PGA: 0.0 to 76.0 step 1.0 dB
| | | | Bandwidth range: 20000000.0 to 40000000.0 step 0.0 Hz
| | | | Connection Type: IQ
| | | | Uses LO offset: No
| | | _____________________________________________________
| | | /
| | | | RX Codec: A
| | | | Name: AD9361 Dual ADC
| | | | Gain Elements: None
| | _____________________________________________________
| | /
| | | TX Dboard: A
| | | _____________________________________________________
| | | /
| | | | TX Frontend: 0
| | | | Name: Neon
| | | | Antennas: TX/RX
| | | | Sensors: lo_locked, ad9361_temperature
| | | | Freq range: 47.000 to 6000.000 MHz
| | | | Gain range PGA: 0.0 to 89.8 step 0.2 dB
| | | | Bandwidth range: 20000000.0 to 40000000.0 step 0.0 Hz
| | | | Connection Type: IQ
| | | | Uses LO offset: No
| | | _____________________________________________________
| | | /
| | | | TX Frontend: 1
| | | | Name: Neon
| | | | Antennas: TX/RX
| | | | Sensors: lo_locked, ad9361_temperature
| | | | Freq range: 47.000 to 6000.000 MHz
| | | | Gain range PGA: 0.0 to 89.8 step 0.2 dB
| | | | Bandwidth range: 20000000.0 to 40000000.0 step 0.0 Hz
| | | | Connection Type: IQ
| | | | Uses LO offset: No
| | | _____________________________________________________
| | | /
| | | | TX Codec: A
| | | | Name: AD9361 Dual DAC
| | | | Gain Elements: None
| | _____________________________________________________
| | /
| | | RFNoC blocks on this device:
| | |
| | | * DmaFIFO_0
| | | * Radio_0
| | | * DDC_0
| | | * DUC_0

</pre>

===ASCII Art Example===
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

You can quickly verify the operation of your USRP E320 by running the <code>rx_ascii_art_dft</code> UHD example program.

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.

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:

1. Attach an antenna to the <code>RF A / RX2</code> antenna port of the E320.

2. From your host computer, run the command:

$ /usr/local/lib/uhd/examples/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"

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.

3. You should see a real-time FFT display of 2 MHz of spectrum, centered at the specified tuning frequency.

4. Type "<code>Q</code>" to stop the program and to return to the Linux command line.

5. You can run with the <code>--help</code> argument to see a description of all available command-line options.

Example Output:

<pre>
$ ./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"

Creating the usrp device with: addr=192.168.10.2...
[INFO] [UHD] linux; GNU C++ version 5.4.0 20160609; Boost_105800; UHD_3.13.1.0-1-gd3b7e90a
[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
[INFO] [0/DmaFIFO_0] Initializing block control (NOC ID: 0xF1F0D00000000000)
[INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1334 MB/s)
[INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1325 MB/s)
[INFO] [0/Radio_0] Initializing block control (NOC ID: 0x12AD100000003320)
[INFO] [0/DDC_0] Initializing block control (NOC ID: 0xDDC0000000000000)
[INFO] [0/DUC_0] Initializing block control (NOC ID: 0xD0C0000000000002)
[INFO] [MPM.PeriphManager] init() called with device args `product=e320,mgmt_addr=192.168.10.2'.
[INFO] [0/Radio_0] Performing CODEC loopback test...
[INFO] [0/Radio_0] CODEC loopback test passed
[INFO] [0/Radio_0] Performing CODEC loopback test...
[INFO] [0/Radio_0] CODEC loopback test passed
Using Device: Single USRP:
Device: E300-Series Device
Mboard 0: ni-e320-316E375
RX Channel: 0
RX DSP: 0
RX Dboard: A
RX Subdev: Neon
TX Channel: 0
TX DSP: 0
TX Dboard: A
TX Subdev: Neon
TX Channel: 1
TX DSP: 1
TX Dboard: A
TX Subdev: Neon

Setting RX Rate: 2.000000 Msps...
Actual RX Rate: 2.000000 Msps...

Setting RX Freq: 98.500000 MHz...
Actual RX Freq: 98.500000 MHz...

Setting RX Gain: 40.000000 dB...
Actual RX Gain: 40.000000 dB...

Checking RX: all_los: locked ...

Done!
</pre>

===Benchmarking your system===
Included with the UHD driver example programs is a utility, <code>benchmark_rate</code> to benchmark the transport link of the system.

A system's maximum performance is dependent upon many factors. <code>benchmark_rate</code> will exercise the transport link and CPU of the system.

====1 Gb Interface====
NOTE: This example requires the <code>1G</code> FPGA image to be loaded.

This example will test one full-duplex stream using "RFA/A:0", at a rate of 2 MS/s, for 60 seconds:

/usr/local/lib/uhd/examples/benchmark_rate \
--args "addr=192.168.10.2" \
--duration 60 \
--channels "0" \
--rx_rate 2e6 \
--rx_subdev "A:0" \
--tx_rate 2e6 \
--tx_subdev "A:0"

This example will test two full-duplex streams at 2 MS/s, for 60 seconds:

/usr/local/lib/uhd/examples/benchmark_rate \
--args "addr=192.168.10.2" \
--duration 60 \
--channels "0,1" \
--rx_rate 2e6 \
--rx_subdev "A:0 A:1" \
--tx_rate 2e6 \
--tx_subdev "A:0 A:1"

This example will test two full-duplex streams at 12.5 MS/s, for 60 seconds:

/usr/local/lib/uhd/examples/benchmark_rate \
--args "addr=192.168.10.2,master_clock_rate=25e6" \
--duration 60 \
--channels "0,1" \
--rx_rate 12.5e6 \
--rx_subdev "A:0 A:1" \
--tx_rate 12.5e6 \
--tx_subdev "A:0 A:1"

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.

====10 Gb Interface ====
NOTE: These examples require the <code>XG</code> FPGA image to be loaded.

This example will test one full-duplex stream using "RFA/A:0", at a rate of 61.44 MS/s, for 60 seconds:

/usr/local/lib/uhd/examples/benchmark_rate \
--args "addr=192.168.10.2,master_clock_rate=61.44e6" \
--duration 60 \
--channels "0" \
--rx_rate 61.44e6 \
--rx_subdev "A:0" \
--tx_rate 61.44e6 \
--tx_subdev "A:0"

This example will test two full-duplex stream, at a rate of 30.72 MS/s, for 60 seconds:

/usr/local/lib/uhd/examples/benchmark_rate \
--args "addr=192.168.10.2,master_clock_rate=61.44e6" \
--duration 60 \
--channels "0,1" \
--rx_rate 30.72e6 \
--rx_subdev "A:0 A:1" \
--tx_rate 30.72e6 \
--tx_subdev "A:0 A:1"

==USRP E320 Device Specific Operations==

===Turning the Device Off/On===
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:

shutdown -h now

=== Autoboot ===

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.

For example
<pre>
root@ni-e320-XXXXXXX:~# eeprom-dump
-- PID/REV: e320 0002
-- MCU_FLAGS[0]: 00000008
-- MCU_FLAGS[1]: 00000000
-- MCU_FLAGS[2]: 00000000
-- MCU_FLAGS[3]: 00000000
-- Serial: XXXXXXX
-- eth_addr0: XX:XX:XX:XX:XX:XX
-- eth_addr1: XX:XX:XX:XX:XX:XX
-- eth_addr2: XX:XX:XX:XX:XX:XX
-- DT-Compat/MCU-Compat: 0000 0002
-- CRC: cbd79a61 (matches)
</pre>
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).

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:

* Disable autoboot on USRP E320 (sets least significant bit to 0), regardless of whether currently enabled or disabled:
<pre>
root@ni-e320-XXXXXXX:~# eeprom-set-flags $((0x<MCU_FLAGS[0]> & ~0x1))
</pre>
Thus, for the value noted above (autoboot is already disabled, so this command doesn't actually change anything):
<pre>
root@ni-e320-XXXXXXX:~# eeprom-set-flags $((0x00000008 & ~0x1))
-- PID/REV: e320 0002
-- MCU_FLAGS[0]: 00000008
-- MCU_FLAGS[1]: 00000000
-- MCU_FLAGS[2]: 00000000
-- MCU_FLAGS[3]: 00000000
-- Serial: XXXXXXX
-- eth_addr0: XX:XX:XX:XX:XX:XX
-- eth_addr1: XX:XX:XX:XX:XX:XX
-- eth_addr2: XX:XX:XX:XX:XX:XX
-- DT-Compat/MCU-Compat: 0000 0002
-- CRC: cbd79a61 (matches)
-- Reading back
-- PID/REV: e320 0002
-- MCU_FLAGS[0]: 00000008
-- MCU_FLAGS[1]: 00000000
-- MCU_FLAGS[2]: 00000000
-- MCU_FLAGS[3]: 00000000
-- Serial: XXXXXXX
-- eth_addr0: XX:XX:XX:XX:XX:XX
-- eth_addr1: XX:XX:XX:XX:XX:XX
-- eth_addr2: XX:XX:XX:XX:XX:XX
-- DT-Compat/MCU-Compat: 0000 0002
-- CRC: 448fb572 (matches)
</pre>

* 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:
<pre>
root@ni-e320-XXXXXXX:~# eeprom-set-flags $((0x<MCU_FLAGS[0]> | 0x1))
</pre>
Thus, for the value noted above:
<pre>
root@ni-e320-XXXXXXX:~# eeprom-set-flags $((0x00000008 | 0x1))
-- PID/REV: e320 0002
-- MCU_FLAGS[0]: 00000008
-- MCU_FLAGS[1]: 00000000
-- MCU_FLAGS[2]: 00000000
-- MCU_FLAGS[3]: 00000000
-- Serial: XXXXXXX
-- eth_addr0: XX:XX:XX:XX:XX:XX
-- eth_addr1: XX:XX:XX:XX:XX:XX
-- eth_addr2: XX:XX:XX:XX:XX:XX
-- DT-Compat/MCU-Compat: 0000 0002
-- CRC: cbd79a61 (matches)
-- Reading back
-- PID/REV: e320 0002
-- MCU_FLAGS[0]: 00000009
-- MCU_FLAGS[1]: 00000000
-- MCU_FLAGS[2]: 00000000
-- MCU_FLAGS[3]: 00000000
-- Serial: XXXXXXX
-- eth_addr0: XX:XX:XX:XX:XX:XX
-- eth_addr1: XX:XX:XX:XX:XX:XX
-- eth_addr2: XX:XX:XX:XX:XX:XX
-- DT-Compat/MCU-Compat: 0000 0002
-- CRC: 448fb572 (matches)
</pre>

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.

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:
<pre>
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 -
</pre>
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:
<pre>
root@ni-e320-XXXXXXX:~# cd upgrade_mcu_neon_v1.1.7358-a190641-musl-glibc-rev3-6
root@ni-e320-XXXXXXX:~/upgrade_mcu_neon_v1.1.7358-a190641-musl-glibc-rev3-6# ./flash-firmware.sh
This script updates the microcontroller firmware (RO part). The change is
persistent across power cycles. Incorrect updates can only fixed be a manual
process which requires opening the enclosure.

Updating the microcontroller firmware (RO part) is only required if the Ettus
Research support told you to do so.

Press "y" to continue
</pre>
At the prompt, press the <code>y</code> key to continue. Pressing any other key aborts the procedure:
<pre>
Press "y" to continue n

aborting
root@ni-e320-317F9BF:~/upgrade_mcu_neon_v1.1.7358-a190641-musl-glibc-rev3-6#
</pre>
Pressing the <code>y</code> key:
<pre>
Press "y" to continue y

This script will flash ec-neon-rev3.RO.flat to the device
old RO version: neon_vX.X.XXXX-XXXXXXX
new RO version: neon_v1.1.7358-a190641

Press "y" to continue
</pre>
At the prompt, press the <code>y</code> key ''again'' to continue. Pressing any other key aborts the procedure as before.
<pre>
Press "y" to continue y

./ectool --interface=dev reboot_ec RW
./ectool --interface=dev flashread 0x0 65536 ec-neon-rev3.RO.flat.old
Reading 65536 bytes at offset 0...
done.
./ectool --interface=dev flasherase 0x0 65536
Erasing 65536 bytes at offset 0...
done.
./ectool --interface=dev flashwrite 0x0 ec-neon-rev3.RO.flat
Reading 49592 bytes from ec-neon-rev3.RO.flat...
Writing to offset 0...
Write size 112...
done.

copying new firmware files
'ec-neon-rev3.bin' -> '/lib/firmware/ni/ec-neon-rev3.bin'
'ec-neon-rev3.RW.bin' -> '/lib/firmware/ni/ec-neon-rev3.RW.bin'
root@ni-e320-317F9BF:~/upgrade_mcu_neon_v1.1.7358-a190641-musl-glibc-rev3-6#
</pre>

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.

===Default Password===
The default user is <code>root</code> and the password is empty (no password).

It is recommended to update the <code>root</code> password, which can be done with the command <code>passwd</code>:

Example Output:

root@ni-e320-serial:~# passwd
Changing password for root
New password:
Re-enter new password:
passwd: password changed.

==Known Issues==
===Problematic NICs===
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.

==Technical Support and Community Knowledge Base==
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.

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.

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

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

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

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

==Legal Considerations==
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.

*NOTE: This USRP product is a piece of test equipment.

==Sales and Ordering Support==
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.

==Terms and Conditions of Sale==
Terms and conditions of sale can be accessed online at the following link: http://www.ettus.com/legal/terms-and-conditions-of-sale

[[Category:Getting Started Guides]]
[[Category:E320]]

E310/E312

2023-09-18T23:36:11Z

JonathonPendlum: Remove old information and update content to be consistent with UHD 4.x releases

== Device Overview ==
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.

== Key Features==
===E310===
{|
|style="vertical-align:top"|
*Xilinx Zynq 7020 SoC: 7 Series FPGA with ARM Cortex A9 667 MHz dual-core processor
*Analog Devices AD9361 RFIC direct-conversion transceiver
*Frequency range: 70 MHz - 6 GHz
*Up to 56 MHz of instantaneous bandwidth
*2x2 MIMO transceiver
*Up to 10 MS/s sample data transfer rate to ARM processor
*RX, TX filter banks
*Integrated GPS receiver
*9-axis inertial measurement unit
*RF Network on Chip (RFNoC™) FPGA development framework support
|[[File:Product e310.png|250px|center]]
|}

===E312===
{|
|style="vertical-align:top"|
*Battery Operated
*Xilinx Zynq 7020 SoC: 7 Series FPGA with ARM Cortex A9 866 MHz dual-core processor
*Analog Devices AD9361 RFIC direct-conversion transceiver
*Frequency range: 70 MHz - 6 GHz
*Up to 56 MHz of instantaneous bandwidth
*2x2 MIMO transceiver
*Up to 10 MS/s sample data transfer rate to ARM processor
*RX, TX filter banks
*Integrated GPS receiver
*9-axis inertial measurement unit
*RF Network on Chip (RFNoC™) FPGA development framework support
|[[File:Product e312.png|250px|center]]
|}

== Daughterboard Specifications==
===E310 MIMO XCVR board===
The USRP E310 MIMO XCVR daughterboard features an integrated MIMO capable RF frontend.

===Tuning===
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.

===Gains===
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.

===LO lock status===
The frontends provide a lo-locked sensor that can be queried through the UHD API.

<syntaxhighlight lang="c++">
// assumes 'usrp' is a valid uhd::usrp::multi_usrp::sptr instance
// get status for rx frontend
usrp->get_rx_sensor("lo-locked");
// get status for tx frontend
usrp->get_tx_sensor("lo-locked");
</syntaxhighlight>

===Filter and Antenna Switches===
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.

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.

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.

===Side A Filter and Antenna Switches===
''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.''

'''Receive'''

{| class="wikitable"
!RX Port
!RX Filter (MHz)
!VCTXRX2_V1,V2
!VCRX2_V1,V2
!RX2_BANDSEL[2:0]
!RX2B_BANDSEL[1:0]
!RX2C_BANDSEL[1:0]
|-

| style="text-align: center" | TRX-A
| style="text-align: center" | < 450
| style="text-align: center" | 01
| style="text-align: center" | 10
| style="text-align: center" | 101
| style="text-align: center" | XX
| style="text-align: center" | 01
|-

| style="text-align: center" | TRX-A
| style="text-align: center" | 450 – 700
| style="text-align: center" | 01
| style="text-align: center" | 10
| style="text-align: center" | 011
| style="text-align: center" | XX
| style="text-align: center" | 11
|-

| style="text-align: center" | TRX-A
| style="text-align: center" | 700 – 1200
| style="text-align: center" | 01
| style="text-align: center" | 10
| style="text-align: center" | 001
| style="text-align: center" | XX
| style="text-align: center" | 10
|-

| style="text-align: center" | TRX-A
| style="text-align: center" | 1200 – 1800
| style="text-align: center" | 01
| style="text-align: center" | 10
| style="text-align: center" | 000
| style="text-align: center" | 01
| style="text-align: center" | XX
|-

| style="text-align: center" | TRX-A
| style="text-align: center" | 1800 – 2350
| style="text-align: center" | 01
| style="text-align: center" | 10
| style="text-align: center" | 010
| style="text-align: center" | 11
| style="text-align: center" | XX
|-

| style="text-align: center" | TRX-A
| style="text-align: center" | 2350 – 2600
| style="text-align: center" | 01
| style="text-align: center" | 10
| style="text-align: center" | 100
| style="text-align: center" | 10
| style="text-align: center" | XX
|-

| style="text-align: center" | TRX-A
| style="text-align: center" | 2600 – 6000
| style="text-align: center" | 01
| style="text-align: center" | 01
| style="text-align: center" | XXX
| style="text-align: center" | XX
| style="text-align: center" | XX
|-

| style="text-align: center" | RX2-A
| style="text-align: center" | 70 – 450
| style="text-align: center" | TT
| style="text-align: center" | 01
| style="text-align: center" | 101
| style="text-align: center" | XX
| style="text-align: center" | 01
|-

| style="text-align: center" | RX2-A
| style="text-align: center" | 450 – 700
| style="text-align: center" | TT
| style="text-align: center" | 01
| style="text-align: center" | 011
| style="text-align: center" | XX
| style="text-align: center" | 11
|-

| style="text-align: center" | RX2-A
| style="text-align: center" | 700 – 1200
| style="text-align: center" | TT
| style="text-align: center" | 01
| style="text-align: center" | 001
| style="text-align: center" | XX
| style="text-align: center" | 10
|-

| style="text-align: center" | RX2-A
| style="text-align: center" | 1200 – 1800
| style="text-align: center" | TT
| style="text-align: center" | 01
| style="text-align: center" | 000
| style="text-align: center" | 01
| style="text-align: center" | XX
|-

| style="text-align: center" | RX2-A
| style="text-align: center" | 1800 – 2350
| style="text-align: center" | TT
| style="text-align: center" | 01
| style="text-align: center" | 010
| style="text-align: center" | 11
| style="text-align: center" | XX
|-

| style="text-align: center" | RX2-A
| style="text-align: center" | 2350 – 2600
| style="text-align: center" | TT
| style="text-align: center" | 01
| style="text-align: center" | 100
| style="text-align: center" | 10
| style="text-align: center" | XX
|-

| style="text-align: center" | RX2-A
| style="text-align: center" | >= 2600
| style="text-align: center" | TT
| style="text-align: center" | 10
| style="text-align: center" | XXX
| style="text-align: center" | XX
| style="text-align: center" | XX
|-
|}

'''Transmit'''
{| class="wikitable"

! TX Port
! TX Filter (MHz)
! VCTXRX2_V1,V2
! TX_ENABLE2A,2B
! TX_BANDSEL[2:0]
|-

| style="text-align:center;" | TRX-A
| style="text-align:center;" | < 117.7
| style="text-align:center;" | 10
| style="text-align:center;" | 01
| style="text-align:center;" | 111
|-

| style="text-align:center;" | TRX-A
| style="text-align:center;" | 117.7 – 178.2
| style="text-align:center;" | 10
| style="text-align:center;" | 01
| style="text-align:center;" | 110
|-

| style="text-align:center;" | TRX-A
| style="text-align:center;" | 178.2 – 284.3
| style="text-align:center;" | 10
| style="text-align:center;" | 01
| style="text-align:center;" | 101
|-

| style="text-align:center;" | TRX-A
| style="text-align:center;" | 284.3 – 453.7
| style="text-align:center;" | 10
| style="text-align:center;" | 01
| style="text-align:center;" | 100
|-

| style="text-align:center;" | TRX-A
| style="text-align:center;" | 453.7 – 723.8
| style="text-align:center;" | 10
| style="text-align:center;" | 01
| style="text-align:center;" | 011
|-

| style="text-align:center;" | TRX-A
| style="text-align:center;" | 723.8 – 1154.9
| style="text-align:center;" | 10
| style="text-align:center;" | 01
| style="text-align:center;" | 010
|-

| style="text-align:center;" | TRX-A
| style="text-align:center;" | 1154.9 – 1842.6
| style="text-align:center;" | 10
| style="text-align:center;" | 01
| style="text-align:center;" | 001
|-

| style="text-align:center;" | TRX-A
| style="text-align:center;" | 1842.6 – 2940.0
| style="text-align:center;" | 10
| style="text-align:center;" | 01
| style="text-align:center;" | 000
|-

| style="text-align:center;" | TRX-A
| style="text-align:center;" | >= 2940.0
| style="text-align:center;" | 11
| style="text-align:center;" | 10
| style="text-align:center;" | XXX
|-

|}

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

===Side B Filter and Antenna Switches===
''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.''

'''Receive'''
{| class="wikitable"
! RX Port
! RX Filter (MHz)
! VCTXRX1_V1,V2
! VCRX1_V1,V2
! RX1_BANDSEL[2:0]
! RX1B_BANDSEL[1:0]
! RX1C_BANDSEL[1:0]
|-

| style="text-align:center;" | TRX-B
| style="text-align:center;" | < 450
| style="text-align:center;" | 10
| style="text-align:center;" | 01
| style="text-align:center;" | 100
| style="text-align:center;" | XX
| style="text-align:center;" | 10
|-

| style="text-align:center;" | TRX-B
| style="text-align:center;" | 450 – 700
| style="text-align:center;" | 10
| style="text-align:center;" | 01
| style="text-align:center;" | 010
| style="text-align:center;" | XX
| style="text-align:center;" | 11
|-

| style="text-align:center;" | TRX-B
| style="text-align:center;" | 700 – 1200
| style="text-align:center;" | 10
| style="text-align:center;" | 01
| style="text-align:center;" | 000
| style="text-align:center;" | XX
| style="text-align:center;" | 01
|-

| style="text-align:center;" | TRX-B
| style="text-align:center;" | 1200 – 1800
| style="text-align:center;" | 10
| style="text-align:center;" | 01
| style="text-align:center;" | 001
| style="text-align:center;" | 10
| style="text-align:center;" | XX
|-

| style="text-align:center;" | TRX-B
| style="text-align:center;" | 1800 – 2350
| style="text-align:center;" | 10
| style="text-align:center;" | 01
| style="text-align:center;" | 011
| style="text-align:center;" | 11
| style="text-align:center;" | XX
|-

| style="text-align:center;" | TRX-B
| style="text-align:center;" | 2350 – 2600
| style="text-align:center;" | 10
| style="text-align:center;" | 01
| style="text-align:center;" | 101
| style="text-align:center;" | 01
| style="text-align:center;" | XX
|-

| style="text-align:center;" | TRX-B
| style="text-align:center;" | 2600 – 6000
| style="text-align:center;" | 10
| style="text-align:center;" | 10
| style="text-align:center;" | XXX
| style="text-align:center;" | XX
| style="text-align:center;" | XX
|-

| style="text-align:center;" | RX2-B
| style="text-align:center;" | 70 – 450
| style="text-align:center;" | TT
| style="text-align:center;" | 10
| style="text-align:center;" | 100
| style="text-align:center;" | XX
| style="text-align:center;" | 10
|-

| style="text-align:center;" | RX2-B
| style="text-align:center;" | 450 – 700
| style="text-align:center;" | TT
| style="text-align:center;" | 10
| style="text-align:center;" | 010
| style="text-align:center;" | XX
| style="text-align:center;" | 11
|-

| style="text-align:center;" | RX2-B
| style="text-align:center;" | 700 – 1200
| style="text-align:center;" | TT
| style="text-align:center;" | 10
| style="text-align:center;" | 000
| style="text-align:center;" | XX
| style="text-align:center;" | 01
|-

| style="text-align:center;" | RX2-B
| style="text-align:center;" | 1200 – 1800
| style="text-align:center;" | TT
| style="text-align:center;" | 10
| style="text-align:center;" | 001
| style="text-align:center;" | 10
| style="text-align:center;" | XX
|-

| style="text-align:center;" | RX2-B
| style="text-align:center;" | 1800 – 2350
| style="text-align:center;" | TT
| style="text-align:center;" | 10
| style="text-align:center;" | 011
| style="text-align:center;" | 11
| style="text-align:center;" | XX
|-

| style="text-align:center;" | RX2-B
| style="text-align:center;" | 2350 – 2600
| style="text-align:center;" | TT
| style="text-align:center;" | 10
| style="text-align:center;" | 101
| style="text-align:center;" | 01
| style="text-align:center;" | XX
|-

| style="text-align:center;" | RX2-B
| style="text-align:center;" | >= 2600
| style="text-align:center;" | TT
| style="text-align:center;" | 01
| style="text-align:center;" | XXX
| style="text-align:center;" | XX
| style="text-align:center;" | XX
|-

|}

'''Transmit'''
{| class="wikitable"

! TX Port
! TX Filter (MHz)
! VCTXRX1_V1,V2
! TX_ENABLE1A,1B
! TX1_BANDSEL[2:0]
|-

| style="text-align:center;" | TRX-B
| style="text-align:center;" | < 117.7
| style="text-align:center;" | 00
| style="text-align:center;" | 01
| style="text-align:center;" | 111
|-

| style="text-align:center;" | TRX-B
| style="text-align:center;" | 117.7 – 178.2
| style="text-align:center;" | 00
| style="text-align:center;" | 01
| style="text-align:center;" | 110
|-

| style="text-align:center;" | TRX-B
| style="text-align:center;" | 178.2 – 284.3
| style="text-align:center;" | 00
| style="text-align:center;" | 01
| style="text-align:center;" | 101
|-

| style="text-align:center;" | TRX-B
| style="text-align:center;" | 284.3 – 453.7
| style="text-align:center;" | 00
| style="text-align:center;" | 01
| style="text-align:center;" | 100
|-

| style="text-align:center;" | TRX-B
| style="text-align:center;" | 453.7 – 723.8
| style="text-align:center;" | 00
| style="text-align:center;" | 01
| style="text-align:center;" | 011
|-

| style="text-align:center;" | TRX-B
| style="text-align:center;" | 723.8 – 1154.9
| style="text-align:center;" | 00
| style="text-align:center;" | 01
| style="text-align:center;" | 010
|-

| style="text-align:center;" | TRX-B
| style="text-align:center;" | 1154.9 – 1842.6
| style="text-align:center;" | 00
| style="text-align:center;" | 01
| style="text-align:center;" | 001
|-

| style="text-align:center;" | TRX-B
| style="text-align:center;" | 1842.6 – 2940.0
| style="text-align:center;" | 00
| style="text-align:center;" | 01
| style="text-align:center;" | 000
|-

| style="text-align:center;" | TRX-B
| style="text-align:center;" | >= 2940.0
| style="text-align:center;" | 11
| style="text-align:center;" | 10
| style="text-align:center;" | XXX
|-

|}

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

==RF Specifications==
===RF Performance===
* SSB/LO Suppression -35/50 dBc
* Phase Noise 3.5 GHz 1.0 deg RMS
* Phase Noise 6 GHz 1.5 deg RMS
* Power Output >10dBm
* IIP3 (@ typ NF) -20dBm
* Typical Noise Figure <8dB

===Input/Output Impedance===
* All RF Ports are matched to 50 Ohm with -10dB or better return loss generally. Detailed test is pending.

==Hardware Specifications==
* Ettus Research recommends to always use the latest stable version of UHD

===E310===
* Current Hardware Revision: 1
* Minimum version of UHD required: 3.8.0
* Required version on the host computer must match what is running on the E310

===E312===
* Current Hardware Revision: 1
* Minimum version of UHD required: 3.8.5
* Required version on the host computer must match what is running on the E312

==Physical Specifications==

===Dimensions===
* 133 x 68 x 26.4 mm

==Environmental Specifications==
===Operating Temperature Range===
* E310 0-40 °C
* E312 0-40 °C

===Operating Humidity Range===
* 10% to 90% non-condensing

==Schematics==
===E310===
[http://files.ettus.com/schematics/e310/e310.pdf E310 Schematics]

[http://files.ettus.com/schematics/e310/e310_db.pdf E310 DB]

[[Media: E310_System_Diagram.png|E310 Architecture]]

==Key Component Datasheets==
{| class="wikitable" style="width:80%"
!Part Number
!Description
!Schematic ID (Page)
|-
! colspan="3" | Motherboard
|-
|[http://www.ti.com.cn/cn/lit/ds/symlink/txs02612.pdf TXS02612RTWR]
|SDIO PORT EXPANDER
|U23 (2)
|-
|[http://www.xilinx.com/support/documentation/data_sheets/ds187-XC7Z010-XC7Z020-Data-Sheet.pdf XC7Z020-1CLG484CES9919]
|FPGA
|U11 (2,3,4,8,11,13)
|-

|[http://www.xilinx.com/products/silicon-devices/soc/zynq-7000.html Xilinx Zynq Product Page ]
|FPGA
| -
|-

|[http://ww1.microchip.com/downloads/en/DeviceDoc/00001678A.pdf USB3340-EZK-TR]
|ULPI Transceiver
|U33 (5)
|-
|[http://www.akm.com/akm/en/file/datasheet/AK4571VQ.pdf AK4571VQP]
|Audio CODEC
|U30 (6)
|-
|[http://www.ftdichip.com/Support/Documents/DataSheets/ICs/DS_FT230X.pdf FT230XQ-R]
|UART Interface
|U32 (6)
|-
|[http://www.marvell.com/transceivers/assets/Alaska_88E1512-001_product_brief.pdf 88E1512]
|Gigabit Ethernet Transceiver
|U13 (7)
|-
|[http://ww1.microchip.com/downloads/en/DeviceDoc/21210N.pdf 24LC024/SN]
|EEPROM
|U5 (9)
|-
|[http://datasheets.maximintegrated.com/en/ds/DS1339-DS1339U.pdf DS1339,SM]
|Real-Time Clock
|U6 (9)
|-
|[http://www.analog.com/media/en/technical-documentation/data-sheets/ADT7408.pdf ADT7408]
|Temperature Sensor
|U8 (9)
|-
|[https://www.invensense.com/wp-content/uploads/2015/02/MPU-9150-Datasheet.pdf MPU-9150]
|Motion Processing Unit
|U3 (9)
|-

|[http://www.invensense.com/products/motion-tracking/9-axis/mpu-9150/ InvenSense MPU-9150 Product Page]
| Motion Processing Unit
|U3 (9)
|-

|[https://ae-bst.resource.bosch.com/media/_tech/media/datasheets/BST-BMP180-DS000-121.pdf BMP180]
|Digital pressure sensor
|U4 (9)
|-
|[http://www.ti.com/lit/ds/symlink/bq24192.pdf BQ24192]
|Adapter Charger
|U1 (10)
|-
|[http://www.ti.com/lit/ds/symlink/tps54478.pdf TPS54478]
|Step-Down Switcher
|U20 (10)
|-
|[https://datasheets.maximintegrated.com/en/ds/MAX6509-MAX6510.pdf MAX6510HAUT-T]
|Temperature Switches
|U35 (10)
|-
|[http://www.atmel.com/images/doc8008.pdf ATTINY88-MU]
|Microcontroller
|U18 (10)
|-
|[http://www.ti.com/lit/ds/symlink/tps61253.pdf TPS61253YFF]
|Step-Up Converter
|U19 (10)
|-

|[https://www.u-blox.com/sites/default/files/products/documents/AMY-6_ProductSummary_%28GPS.G6-HW-10039%29.pdf AMY-6M]
|GPS Module
|U12 (6)
|-

! colspan="3" | Daughterboard
|-
!Part Number
!Description
!Schematic ID (Page)
|-

|[http://www.analog.com/en/products/rf-microwave/integrated-transceivers-transmitters-receivers/wideband-transceivers-ic/ad9361.html#product-overview AD9361 Product Page]
|2 x 2 RF Agile Transceiver
| U8 (3)
|-

|[http://ww1.microchip.com/downloads/en/devicedoc/21203m.pdf 24AA256]
|EEPROM
|U15 (2)
|-

|[https://www.minicircuits.com/pdfs/TC1-1-43A+.pdf TC-1-43A+]
|RF Transformer
|T6 (3); T5 (3); T4 (3)
|-

|[https://www.minicircuits.com/pdfs/TC1-1-13M+.pdf TC1-1-13M+]
|RF Transformer
|T7 (3); T10 (3); T1 (3)
|-

|[http://www.ti.com/lit/ds/symlink/tps62140.pdf TPS62140]
|Step-Down Converter
|U19 (4)
|-

|[http://www.analog.com/media/en/technical-documentation/data-sheets/ADP1752_1753.pdf ADP1753ACPZ-R7]
|Linear Regulator
|U17 (4); U18 (4)
|-

|[http://www.rfmd.com/store/downloads/dl/file/id/28671/sga4563z_data_sheet.pdf SGA-4563Z]
|MMIC AMPLIFIER
|U12 (5); U4 (5)
|-

|[http://www.skyworksinc.com/uploads/documents/SKY13418_485LF_201712D.pdf SKY13418-485LF]
|Antenna Switch
|U13 (5); U3 (5); U16 (5); U2 (5); U10 (6); U5 (6)
|-

|[http://www.skyworksinc.com/uploads/documents/SKY13373_460LF_201264N.pdf SKY13373-460LF]
|SP3T Switch
|U11 (6); U9 (6); U6 (6); U7 (6); SW4 (7); SW1 (7)
|-

|[http://www.avagotech.com/docs/AV02-0966EN MGA-81563]
|Amplifier
|U14 (5); U1 (5)
|-

|[https://www.minicircuits.com/pdfs/LFCN-5850+.pdf LFCN-5850+]
|Low Pass Filter
|FL32 (5); FL1 (5)
|-

|[https://www.minicircuits.com/pdfs/LFCN-2750.pdf LFCN-2750+]
|Low Pass Filter
|FL37 (5); FL4 (5)
|-

|[https://www.minicircuits.com/pdfs/LFCN-2250.pdf LFCN-2250+]
|Low Pass Filter
|FL23 (6); FL20 (6)
|-

|[https://www.minicircuits.com/pdfs/LFCN-1700.pdf LFCN-1700+]
|Low Pass Filter
|FL40 (5); FL2 (5)
|-

|[https://www.minicircuits.com/pdfs/LFCN-1575.pdf LFCN-1575+]
|Low Pass Filter
|FL25 (6); FL17 (6)
|-

|[https://www.minicircuits.com/pdfs/LFCN-1000.pdf LFCN-1000+]
|Low Pass Filter
|FL33 (5); FL9 (5); FL27 (6); FL15 (6)
|-

|[https://www.minicircuits.com/pdfs/LFCN-575.pdf LFCN-575+]
|Low Pass Filter
|FL36 (5); FL5 (5)
|-

|[https://www.minicircuits.com/pdfs/LFCN-530.pdf LFCN-530+]
|Low Pass Filter
|FL29 (6); FL13 (6)
|-

|[https://www.minicircuits.com/pdfs/LFCN-400.pdf LFCN-400+]
|Low Pass Filter
|FL38 (5); FL3 (5); FL30 (6); FL11 (6)
|-

|[https://www.minicircuits.com/pdfs/LFCN-225.pdf LFCN-225]
|Low Pass Filter
|FL39 (5); FL6 (5)
|-

|[https://www.minicircuits.com/pdfs/LFCN-160+.pdf LFCN-160+]
|Low Pass Filter
|FL34 (5); FL8 (5)
|-

|[https://www.minicircuits.com/pdfs/LFCN-80.pdf LFCN-80+]
|Low Pass Filter
|FL35 (5); FL7 (5)
|-

|[https://www.minicircuits.com/pdfs/HFCN-1600.pdf HFCN-1600+]
|High Pass Filter
|FL22 (6); FL19 (6)
|-

|[https://www.minicircuits.com/pdfs/HFCN-1100+.pdf HFCN-1100+]
|High Pass Filter
|FL24 (6); FL16 (6)
|-

|[https://www.minicircuits.com/pdfs/HFCN-650.pdf HFCN-650+]
|High Pass Filter
|FL26 (6); FL14 (6)
|-

|[https://www.minicircuits.com/pdfs/HFCN-440+.pdf HFCN-440+]
|High Pass Filter
|FL28 (6); FL12 (6)
|-

|[https://www.minicircuits.com/pdfs/BFCN-2435+.pdf BFCN-2435+]
|Bandpass Filter
|FL21 (6); FL18 (6)
|-

|[https://www.fairchildsemi.com/datasheets/FD/FDG6301N.pdf FDG6301N]
|Dual N-Channel, Digital FET
|Q8 (7); Q5 (7)
|-

|[http://www.farnell.com/datasheets/461118.pdf HSMS-8202]
|Mixer Diodes
|CR1 (7); CR2 (7); CR3 (7); CR4 (7)
|-

|[http://www.ti.com.cn/cn/lit/ds/symlink/lp5900.pdf LP5900TL]
|Linear Regulator
|U25 (8)
|-

|[http://www.analog.com/media/en/technical-documentation/data-sheets/ADP150.pdf ADP150AUJZ-3.0]
|Linear Regulator
|U22 (8)
|-

|[http://www.analog.com/media/en/technical-documentation/data-sheets/AD5662.pdf AD5662RBJ]
|16-Bit nanoDAC
|U21 (8)
|-

|[http://www.ti.com/lit/ds/symlink/sn74aup1t57.pdf SN74AUP1T57]
|Voltage Translator
|U27 (8); U28 (8); U29 (8)
|-

|}

Request a detailed whitepaper covering features and components from [mailto:info@ettus.com info@ettus.com]

==Mechanical Information==

===Weight===
* Partial Enclosure 225 g
* Full Enclosure 375 g

===Drawings===
====E310====
* [[File:E310_Dimensional_Sketches.pdf]]
* [[File:cu e310 motherboard cca.pdf]]
* [[File:cu E310 daughtercard cca.pdf]]
* [[File:cu usrp-e310.pdf]]
====E312====
* [[File:cu e312 motherboard cca.pdf]]
* [[File:cu e312 daughtercard cca.pdf]]
* [[File:cu ettus-e312.pdf]]

==FPGA==
* 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.

===E310/E312===
<pre>
1. Slice Logic
--------------

+----------------------------+-------+-----------+-------+
| Site Type | Used | Available | Util% |
+----------------------------+-------+-----------+-------+
| Slice LUTs | 36203 | 53200 | 68.05 |
| LUT as Logic | 28108 | 53200 | 52.83 |
| LUT as Memory | 8095 | 17400 | 46.52 |
| LUT as Distributed RAM | 870 | | |
| LUT as Shift Register | 7225 | | |
| Slice Registers | 36562 | 106400 | 34.36 |
| Register as Flip Flop | 36562 | 106400 | 34.36 |
| Register as Latch | 0 | 106400 | 0.00 |
| F7 Muxes | 376 | 26600 | 1.41 |
| F8 Muxes | 125 | 13300 | 0.93 |
+----------------------------+-------+-----------+-------+

3. Memory
---------

+-------------------+------+-----------+-------+
| Site Type | Used | Available | Util% |
+-------------------+------+-----------+-------+
| Block RAM Tile | 97 | 140 | 69.28 |
| RAMB36/FIFO* | 90 | 140 | 64.28 |
| RAMB36E1 only | 90 | | |
| RAMB18 | 14 | 280 | 5.00 |
| RAMB18E1 only | 14 | | |
+-------------------+------+-----------+-------+
* 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

4. DSP
------

+----------------+------+-----------+-------+
| Site Type | Used | Available | Util% |
+----------------+------+-----------+-------+
| DSPs | 120 | 220 | 54.54 |
| DSP48E1 only | 120 | | |
+----------------+------+-----------+-------+

</pre>

==Interfaces and Connectivity==
*10/100/1000 BASE-T Ethernet
*Stereo audio out, mono mic in
*Integrated GPS receiver
*Host USB support
*9-axis IMU

===Front Panel===
{|
| style="width:50%" |
*'''RF A Group'''
**'''TX/RX LED:''' Indicates that data is streaming on the TX/RX channel on frontend side A
**'''RX2 LED:''' Indicates that data is streaming on the RX2 channel on frontend side A
*'''RF B Group'''
**'''TX/RX LED:''' Indicates that data is streaming on the TX/RX channel on frontend B
**'''RX2 LED:''' Indicates that data is streaming on the RX2 channel on frontend B
*'''PWR:''' Power switch with integrated status LED, for status description see below.
*'''SYNC:''' Input port for external PPS signal
*'''GPS:''' Connection for the GPS antenna
*'''AUDIO:''' Audio input / output

The status LED in the power switch indicates the power and charge status. It's behavior is firmware version dependent.

*'''Version 1''' (original E310)
**'''Off:''' Indicates device is off and not charging
**'''Solid Red:''' Indicates device is charging
**'''Solid Green:''' Indicates device is on
**'''Fast Blinking Red:''' Indicates an error code
***1 - Low voltage error
***2 - Regulator low voltage error
***3 - FPGA power error
***4 - DRAM power error
***5 - 1.8V rail power error
***6 - 3.3V rail power error
***7 - Daughterboard / TX power error
***9 - Temperature error

*'''Version 2''' (E312 and upgraded E310)
**'''Off:''' Indicates device is off and not charging
**'''Slow Blinking Green:''' Indicates device is off and charging
**'''Fast Blinking Green:''' Indicates device is on and charging
**'''Solid Green:''' Indicates device is on (and not charging, if E312)
**'''Solid Orange:''' Indicates device is on and discharging
**'''Fast Blinking Orange:''' Indicates device is on, discharging, and charge is below 10% charge
**'''Fast Blinking Red:''' Indicates an error code
***1 - Low voltage error
***2 - Regulator low voltage error
***3 - FPGA power error
***4 - DRAM power error
***5 - 1.8V rail power error
***6 - 3.3V rail power error
***7 - Daughterboard / TX power error
***8 - Charger error
***9 - Charger temperature error
***10 - Battery low error
***11 - Fuel Gauge temperature error
***12 - Global (case) temperature error

| style="vertical-align:top" | [[File:e3x0 fp overlay.png]]
|}

===Rear Panel===
{|
| style="width:50%" |
*'''PWR:''' Locking connector (Kycon KLDHCX-0202-A-LT) for the USRP-E Series power supply
*'''1G ETH:''' RJ45 port for Ethernet interfaces
*'''USB:''' USB 2.0 Port
*'''SERIAL:''' Micro USB connection for serial uart console

| style="vertical-align:top" | [[File:e3x0 rp overlay.png]]

|}

===GPIO===
{|

| style="width:60%" |
'''Pin Mapping'''
* Pin 1: +3.3V
* Pin 2: Reserved
* Pin 3: Data[5]
* Pin 4: Reserved
* Pin 5: Data[4]
* Pin 6: Data[0]
* Pin 7: Data[3]
* Pin 8: Data[1]
* Pin 9: 0V
* Pin 10: Data[2]
|[[File:e3x0 gpio conn.png]]
|}
* 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.

===Audio===
{|
| style="width:60%" |
* The E3x0 2.5 mm Audio Jack TRRS pins are assigned as follows: Tip=Mic, Ring1=Right, Ring2=Left, Sleeve=GND.
* 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.

|[[File:TRRS.png]]

|}

==E312 Battery==
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.

The status LED in the power button indicates the power and charge status of the battery:

Off: Indicates device is off and not charging.
*Slow Blinking Green: Indicates device is off and charging.
*Fast Blinking Green: Indicates device is on and charging.
*Solid Green: Indicates device is on and not charging (Battery is finished charging).
*Solid Orange: Indicates device is on and discharging.
*Fast Blinking Orange: Indicates device is on, discharging, and charge is below 10% charge.
*Fast Blinking Red: Indicates an error code:

#Low Voltage Error
#Regulator Low Voltage Error
#FPGA Power Error
#DRAM Power Error
#1.8V Power Rail Error
#3.3V Power Rail Error
#Daughterboard / TX Power Error
#Charger Error
#Charger Temperature Error
#Battery Low Error
#Fuel Gauge Temperature Error
#Global (Enclosure) Temperature Error

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.

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.

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.

If error codes persist after cooling down and/or recharging the USRP E312, please contact [mailto:support@ettus.com support@ettus.com].

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

An Application Note covering the replacement of the E312 battery can be found at [[USRP E312 Battery Replacement Instructions]].

==Certifications==
===RoHS===
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]

==Certificate of Volatility==
===E310===
* [[Media:volatility USRP E310 r1.pdf]]

===E312===
* [[Media:USRP E31x CoV.pdf]]

==SD Card Images==

The E31x SD card images can be obtained two ways:

* Using uhd_images_downloader. See these instructions: https://files.ettus.com/manual/page_usrp_e3xx.html#update_sdcard
* Direct download from [https://files.ettus.com/binaries/cache/e3xx/ https://files.ettus.com/binaries/cache/e3xx/]

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

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.

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.

The UHD 4.5+ release images include UHD 4.5 (or later), GNU Radio 3.8, Python 3, and the corresponding FPGA image file.

'''Note:''' An 8 GB SD card is required for the Release 4 image.

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.

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.

{| class="wikitable"
| rowspan="2" | E310 (15633'''X'''-01L)
|X= A, B, C, D
|e3xx_e310_sg1
|-
|X= E or later
|e3xx_e310_sg3
|-
|E312 (140605'''X'''-01L)
|X = All
|e3xx_e310_sg3
|}

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.

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.

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:

* https://files.ettus.com/manual/page_usrp_e3xx.html#e3xx_sdcard

* https://kb.ettus.com/Writing_the_USRP_File_System_Disk_Image_to_a_SD_Card

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.

'''7-Zip'''
* http://www.7-zip.org/
* https://en.wikipedia.org/wiki/7-Zip

==Security Notes==
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.

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

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:

* Use non-confidential path names (i.e., don’t include confidential customer or project names in build paths).
* 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>.
* Use a "build user" who does not have network credentials to access sensitive machines during the build process.

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

==Additional Resources==
* [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]

==Downloads==

[http://files.ettus.com/e3xx_images/ FPGA Images]

[http://files.ettus.com/e3xx_images/README FPGA Images Read Me]

[http://files.ettus.com/manual/md_fpga.html FPGA Resources]

[http://files.ettus.com/binaries/uhd_stable/ UHD Stable Binaries]

[https://github.com/EttusResearch/uhd UHD Source Code on Github]

[[Category:Hardware Resources]]

B200/B210/B200mini/B205mini/B206mini

2023-03-22T01:21:09Z

JonathonPendlum: Correct maximum input power

== Device Overview ==
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.

== Key Features==
=== B200===
{|
|style="vertical-align:top"|
* Xilinx Spartan 6 XC6SLX75 FPGA
* Analog Devices AD9364 RFIC direct-conversion transceiver
* Frequency range: 70 MHz - 6 GHz
* Up to 56 MHz of instantaneous bandwidth
* Full duplex, SISO (1 Tx & 1 Rx)
* Fast and convenient bus-powered USB 3.0 connectivity
* Optional Board Mounted GPSDO
|[[File:Product b200.png|250px|center]]
|}

=== B210===
{|
|style="vertical-align:top"|
* Xilinx Spartan 6 XC6SLX150 FPGA
* Analog Devices AD9361 RFIC direct-conversion transceiver
* Frequency range: 70 MHz - 6 GHz
* Up to 56 MHz of instantaneous bandwidth (61.44MS/s quadrature)
* Full duplex, MIMO (2 Tx & 2 Rx)
* Fast and convenient bus-powered USB 3.0 connectivity
* Optional Board Mounted GPSDO
|[[File:Product b210.png|250px|center]]
|}

=== B200mini===
{|
|style="vertical-align:top"|
* Xilinx Spartan-6 XC6SLX75 FPGA
* Analog Devices AD9364 RFIC direct-conversion transceiver
* Frequency range: 70 MHz - 6 GHz
* Up to 56 MHz of instantaneous bandwidth
* Full duplex, SISO (1 Tx & 1 Rx)
* Fast and convenient bus-powered USB 3.0 connectivity
|[[File:Product b200 mini.png|250px|center]]
|}

=== B200mini-i===
{|
|style="vertical-align:top"|
* Industrial-grade Xilinx Spartan-6 XC6SLX75 FPGA
* Analog Devices AD9364 RFIC direct-conversion transceiver
* Frequency range: 70 MHz - 6 GHz
* Up to 56 MHz of instantaneous bandwidth
* Full duplex, SISO (1 Tx & 1 Rx)
* Fast and convenient bus-powered USB 3.0 connectivity
|[[File:Product b200 mini i.png|250px|center]]
|}

=== B205mini-i===
{|
|style="vertical-align:top"|
* Industrial-grade Xilinx Spartan-6 XC6SLX150 FPGA
* Analog Devices AD9364 RFIC direct-conversion transceiver
* Frequency range: 70 MHz - 6 GHz
* Up to 56 MHz of instantaneous bandwidth
* Full duplex, SISO (1 Tx & 1 Rx)
* Fast and convenient bus-powered USB 3.0 connectivity
|[[File:Product b200 mini i.png|250px|center]]
|}

==Frontend Specifications==
===Tuning===

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.

===Gains===
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.

===Bandwidths===
The analog frontend has a seamlessly adjustable bandwidth of 200 kHz to 56 MHz.

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.

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

The property to control the analog RX bandwidth is bandwidth/value.

UHD will not allow you to set bandwidths larger than your current master clock rate.

==RF Specifications==
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.

===RF Performance===
* SSB/LO Suppression -35/50 dBc
* Phase Noise 3.5 GHz 1.0 deg RMS
* Phase Noise 6 GHz 1.5 deg RMS
* Power Output >10dBm
* IIP3 (@ typ NF) -20dBm
* Typical Noise Figure <8dB
* Maximum Input Power: -15 dBm

===Input/Output Impedance===
All RF Ports are matched to 50 Ohm with -10dB or better return loss generally. Detailed test is pending.

===Input Power Levels===
* The maximum input power for the B200/B210/B200mini/B205mini is 0 dBm.

===RF Performance Data===
====B200mini / B205mini====
* [[Media:B200mini B205 RF Performance Data 20160119.pdf]]

====B200 / B210====
* [[Media:B200 RF Performance.pdf]]

==Hardware Specifications==
* Ettus Research recommends to always use the latest stable version of UHD

=== B200===
* Current Hardware Revision: 6
* Minimum version of UHD required: 3.8.4
* B200 Rev 5 (AD9364-based board) requires minimum UHD 3.8.4

=== B210===
* Current Hardware Revision: 5
* Minimum version of UHD required: 3.6.0

=== B200mini===
* Current Hardware Revision: 2
* Minimum version of UHD required: 3.9.0

=== B200mini-i===
* Current Hardware Revision: 2
* Minimum version of UHD required: 3.9.0

=== B205mini-i===
* Current Hardware Revision: 1
* Minimum version of UHD required: 3.9.2

==Physical Specifications==
===Dimensions===
* B200mini/B205mini 5.0 x 8.4 cm
* B200/B210 9.7 x 15.5 x 1.5 cm

===Weight===
* B200mini 24.0 g
* B200/B210 350 g

===Drawings===
====B200mini====
* [[Media:B200mini_drawing.png| Board only]]
* [[Media:cu usrp-b200mini.pdf| B20xmini Enclosure]]

====B200====
* [[Media:cu ettus b200 cca.pdf| Board only]]

====B210====
* [[Media:cu ettus b210 cca.pdf| Board only]]

====B200/B210 Enclosure====
* [[Media:cu ettus-b2xx-full-enclosure.pdf|Enclosure]]

===CAD/STP Models===
====B200mini====
* [[Media:B200mini.stp.tar.gz| B200mini with Enclosure]]
* [[Media:B200mini enclosure-only.stp.tar.gz| Enclosure only]]
* [[Media:cu ettus b200mini cca.stp.tar.gz| Board only ]]

====B20xmini-i====
* [[Media:b20xmini-i._thermal_insert.stp.tar.gz| B20xmini-i Thermal Insert]]

====B200====
* [[Media:cu ettus b200 cca.stp.tar.gz| Board only]]

====B210====
* [[Media:cu ettus b210 cca.stp.gz| Board only]]

====B200/B210 Enclosure====
* [[Media:cu ettus-b200-b210-case.zip|Enclosure]]

==Environmental Specifications==
===Operating Temperature Range===
* B200 / B210: 25 °C
* B200mini - Board Only: 0 - 40 °C
* B200mini - With Enclosure: -20 - 60°C
* B200mini-i / B205mini-i - Board Only: 0 - 45 °C
* B200mini-i / B205mini-i - With I-Grade Enclosure: -40 - 75°C

===Operating Humidity Range===
* 10% to 90% non-condensing

==Schematics==
===B200mini/B200mini-i/B205mini-i===
[http://files.ettus.com/schematics/b200mini/b200mini.pdf B200mini/B200mini-i/B205mini-i Schematics]

===B200/B210===
[http://files.ettus.com/schematics/b200/b210.pdf B200/B210 Schematics]

==Key Component Datasheets==
{| class="wikitable" style="width:80%"
!Part Number
!Description
!Schematic ID (Page)

|-
|[https://www.minicircuits.com/pdfs/TCM1-63AX+.pdf Mini-Circuits TCM1-63AX+]
|Transformer
|T1 (1,3); T2 (1,3)
|-

|-
|[http://www.analog.com/en/products/rf-microwave/integrated-transceivers-transmitters-receivers/wideband-transceivers-ic/ad9364.html#product-overview Analog Devices AD9364]
|RF Transceiver
|U1 (2)
|-
|[http://www.analog.com/en/products/rf-microwave/integrated-transceivers-transmitters-receivers/wideband-transceivers-ic/ad9361.html#product-overview Analog Devices AD9361]
|RF Transceiver
|U2 (2,8)
|-

|[http://www.analog.com/en/design-center/landing-pages/001/ad9361-ad9364-integ-rf-agile-transceiver-design-res.html AD9361/AD9364 Product Page]
|RF Transceiver
| -
|-
|[http://www.xilinx.com/products/silicon-devices/fpga/spartan-6.html Xilinx Spartan-6 Product Page]
|FPGA
|rowspan="2"|U1 (2,3,4,6); PG1 (6); U18B, U18C (7); U18D (8); U18E, U18F (9); U18G, U18H (10)
|-
|[http://www.xilinx.com/support/documentation/data_sheets/ds160.pdf XC6SLX75 / XC6SLX150]
|FPGA
|-
|[http://www.analog.com/media/en/technical-documentation/data-sheets/ADF4001.pdf ADF4001]
|Frequency Synthesizer
|U101 (1)
|-

|[http://www.cypress.com/file/140296/download CYUSB3014]
|rowspan="2"|FX3: SuperSpeed USB Controller
|rowspan="2"|U3 (5,6); U13 (5)
|-

|[http://www.cypress.com/applications/ez-usb-fx3-superspeed-usb-30-peripheral-controller-collateral-guide EZ-USB FX3™ Product Page]
|-

|[http://www.skyworksinc.com/uploads/documents/SKY13317_373LF_200914K.pdf SKY13317]
|Antenna Switch
|U801, U810 (8)
|-
|[http://www.anaren.com/sites/default/files/BD3150L50100A00%20Data%20sheet%20Rev%20C.pdf BD3150L50100A00]
|Balun
|U802, U808, U809, U815 (8)
|-
|[https://www.minicircuits.com/pdfs/PGA-102+.pdf PGA−102+]
|Amplifier
|U804, U817 (8)
|-

|[http://www.ctscorp.com/wp-content/uploads/2015/11/008-0371-0.pdf VCTCXO]
|VCTCXO (B200mini only)
| -
|-

|[https://www.ctscorp.com/wp-content/uploads/2015/11/008-0334-0.pdf 525L20DA40M0000]
|VCTCXO (B200/B210 only)
| X100 (1)
|-

|[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]
|Optional GPSDO (B200/B210 only)
|U100 (1)
|-
|}

==Enclosures==

* SMA connectors should be torqued to 4 inch-pounds

===B200mini===
* [https://www.ettus.com/all-products/usrp-b200mini-enclosure/ B200mini C-Grade Enclosure]
* [https://www.ettus.com/all-products/usrp-b200mini-i-enclosure/ B200mini I-Grade Enclosure]

===B205mini===
* [https://www.ettus.com/all-products/usrp-b205mini-i-enclosure/ B205mini I-Grade Enclosure]

===B200/B210===
* [https://www.ettus.com/product/details/USRP-B200-Enclosure USRP B200/B210 Enclosure]
** Full Steel Enclosure
** Compatible with green USRP B200 and B210 devices (revision 6 or later)
** Front and rear K-Slots for anti-theft protection

==FPGA==
* Utilization statistics are subject to change between UHD releases. This information is current as of UHD 3.9.4.
===B200===
<pre>
Device utilization summary:
---------------------------

Selected Device : 6slx75fgg484-3

Slice Logic Utilization:
Number of Slice Registers: 15781 out of 93296 16%
Number of Slice LUTs: 19987 out of 46648 42%
Number used as Logic: 15983 out of 46648 34%
Number used as Memory: 4004 out of 11072 36%
Number used as RAM: 972
Number used as SRL: 3032

Slice Logic Distribution:
Number of LUT Flip Flop pairs used: 24062
Number with an unused Flip Flop: 8281 out of 24062 34%
Number with an unused LUT: 4075 out of 24062 16%
Number of fully used LUT-FF pairs: 11706 out of 24062 48%
Number of unique control sets: 434

IO Utilization:
Number of IOs: 172
Number of bonded IOBs: 155 out of 280 55%
IOB Flip Flops/Latches: 124

Specific Feature Utilization:
Number of Block RAM/FIFO: 144 out of 172 83%
Number using Block RAM only: 144
Number of BUFG/BUFGCTRLs: 4 out of 16 25%
Number of DSP48A1s: 76 out of 132 57%
</pre>

===B210===
<pre>
Device utilization summary:
---------------------------

Selected Device : 6slx150fgg484-3

Slice Logic Utilization:
Number of Slice Registers: 29310 out of 184304 15%
Number of Slice LUTs: 36486 out of 92152 39%
Number used as Logic: 29279 out of 92152 31%
Number used as Memory: 7207 out of 21680 33%
Number used as RAM: 1752
Number used as SRL: 5455

Slice Logic Distribution:
Number of LUT Flip Flop pairs used: 43635
Number with an unused Flip Flop: 14325 out of 43635 32%
Number with an unused LUT: 7149 out of 43635 16%
Number of fully used LUT-FF pairs: 22161 out of 43635 50%
Number of unique control sets: 723

IO Utilization:
Number of IOs: 180
Number of bonded IOBs: 163 out of 338 48%
IOB Flip Flops/Latches: 148

Specific Feature Utilization:
Number of Block RAM/FIFO: 186 out of 268 69%
Number using Block RAM only: 186
Number of BUFG/BUFGCTRLs: 4 out of 16 25%
Number of DSP48A1s: 152 out of 180 84%
</pre>

===B200mini===
<pre>
Device utilization summary:
---------------------------

Selected Device : 6slx75csg484-3

Slice Logic Utilization:
Number of Slice Registers: 15949 out of 93296 17%
Number of Slice LUTs: 19963 out of 46648 42%
Number used as Logic: 16140 out of 46648 34%
Number used as Memory: 3823 out of 11072 34%
Number used as RAM: 972
Number used as SRL: 2851

Slice Logic Distribution:
Number of LUT Flip Flop pairs used: 23859
Number with an unused Flip Flop: 7910 out of 23859 33%
Number with an unused LUT: 3896 out of 23859 16%
Number of fully used LUT-FF pairs: 12053 out of 23859 50%
Number of unique control sets: 429

IO Utilization:
Number of IOs: 123
Number of bonded IOBs: 114 out of 328 34%
IOB Flip Flops/Latches: 147

Specific Feature Utilization:
Number of Block RAM/FIFO: 110 out of 172 63%
Number using Block RAM only: 110
Number of BUFG/BUFGCTRLs: 6 out of 16 37%
Number of DSP48A1s: 76 out of 132 57%
Number of PLL_ADVs: 1 out of 6 16%
</pre>

===B205mini===
<pre>
Device utilization summary:
---------------------------

Selected Device : 6slx150csg484-3

Slice Logic Utilization:
Number of Slice Registers: 15949 out of 184304 8%
Number of Slice LUTs: 19963 out of 92152 21%
Number used as Logic: 16140 out of 92152 17%
Number used as Memory: 3823 out of 21680 17%
Number used as RAM: 972
Number used as SRL: 2851

Slice Logic Distribution:
Number of LUT Flip Flop pairs used: 23859
Number with an unused Flip Flop: 7910 out of 23859 33%
Number with an unused LUT: 3896 out of 23859 16%
Number of fully used LUT-FF pairs: 12053 out of 23859 50%
Number of unique control sets: 429

IO Utilization:
Number of IOs: 123
Number of bonded IOBs: 114 out of 338 33%
IOB Flip Flops/Latches: 147

Specific Feature Utilization:
Number of Block RAM/FIFO: 110 out of 268 41%
Number using Block RAM only: 110
Number of BUFG/BUFGCTRLs: 6 out of 16 37%
Number of DSP48A1s: 76 out of 180 42%
Number of PLL_ADVs: 1 out of 6 16%
</pre>

==Interfaces and Connectivity==
B200/B210/B200mini - USB 3.0

===GPIO===
====Power on state====
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.

====Output Current====
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.

===Timing Reference Input===
====B200mini/B200mini-i/B205mini-i====
* 1-PPS or 10 MHz input

=====1-PPS=====
* Maximum: -5V / +5V
* Minimum: 0V / +2.5V

=====10 MHz=====
* Maximum: 0V / +5V
* Minimum: 0V / +1.8V
'''OR'''
* +10dBm ~ +27dBm

====B200/B210====
=====1-PPS=====
* Maximum: 5V
=====10 MHz=====
* Maximum: 15dBm (3.5Vpp into 50 ohms)

==Certifications==
===RoHS===
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]

===China RoHS===
'''Management Methods for Controlling Pollution Caused by Electronic Information Products Regulation'''

'''Chinese Customers'''

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

===Certifications for European Union===
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).

In addition to the part numbers listed above, these ferrite beads can be sourced through Fair-Rite using part number 0443164251.

==Certificate of Volatility==
===B200/B210===
* [[Media:volatility USRP B200 B210 r1.pdf]]

==Downloads==

[http://files.ettus.com/manual/md_fpga.html FPGA Resources]

[http://files.ettus.com/binaries/uhd_stable/ UHD Stable Binaries]

[https://github.com/EttusResearch/uhd UHD Source Code on Github]

==FAQ==
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].

'''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?'''

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.

'''What samples rates should I expect with USB 3.0? USB 2.0?'''

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.

'''When can I power the USRP B200/B210/B200mini off USB?'''

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

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.

'''How much power does the USRP consume?'''

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.

{| class="wikitable"
!
!5 Msps
!15.36 Msps
!30.72 Msps
!56 Msps
!61.44 Msps
|-
|1 RX
|1.92
|2.112
|2.184
|2.508
|
|-
|2 RX
|2.148
|2.436
|2.508
|2.64
|
|-
|1 TX
|2.184
|2.34
|2.352
|2.22
|
|-
|2 TX
|2.76
|2.88
|2.904
|2.64
|
|-
|Full Duplex (1x1)
|2.508
|2.736
|2.796
|3.168
|
|-
|2x2 MIMO
|3.252
|3.588
|3.672
|4.11
|4.092
|-
|}

'''Can I build a multi-unit system with the USRP B200/B210?'''

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.

'''Can I access the source code for the USRP B200/B210?'''

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:

http://files.ettus.com/manual/page_build_guide.html

'''What operating systems does the USRP B200/B210 work on?'''

The USRP B200/B210 is supported on [http://files.ettus.com/manual/page_install.html Linux, OSX (MacOSX / macOS) and Windows].

'''Does the USRP B200/B210 work with GNU Radio?'''

Yes. The USRP B200/B210 work with our GNU Radio plugin - gr-uhd.

'''Does the USRP B200/B210 work with MATLAB and Simulink?'''

Yes. You need to install the [http://www.mathworks.com/hardware-support/usrp.html Communications System Toolbox Support Package for USRP Radio].

'''Does the USRP B200/B210 work with OpenBTS?'''

Yes. This is a third-party application and you can find instructions here: [http://wush.net/trac/rangepublic/wiki/BuildInstallRun OpenBTS - Build, Install, Run.]

For support, please sign up and contact the [https://lists.sourceforge.net/lists/listinfo/openbts-discuss OpenBTS mailing list].

'''What tools do I need to program the FPGA?'''

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.

'''Can I use a GPSDO with the USRP B200/B210?'''

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.

[[Category:Hardware Resources]]

B200/B210/B200mini/B205mini/B206mini Getting Started Guides

2022-05-20T22:08:46Z

JonathonPendlum: Correct wrong RX max input power

==Kit Contents==
* USRP B200 / B210 / B200mini / B205mini
* USB 3.0 Cable
* Universal power supply (B210 only)

{|
|style="vertical-align:top"|
||[[File:Product b200.png|250px|center]]
||[[File:Product b210.png|250px|center]]
||[[File:Product b200 mini.png|250px|center]]
|}

==Verify the Contents of Your Kit==
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.

==You Will Need==
* A host computer with an available USB 2.0 or 3.0 port

==Proper Care and Handling==
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:

*Never allow metal objects to touch the circuit board while powered.
*Always properly terminate the transmit port with an antenna or 50Ω load.
*Always handle the board with proper anti-static methods.
*Never allow the board to directly or indirectly come into contact with any voltage spikes.
*Never allow any water, or condensing moisture, to come into contact with the boards.
*Always use caution with FPGA, firmware, or software modifications.
{|
|style="padding-left:10px; padding-right:10px; padding-bottom:10px;" |[[File:Caution.png|24px|center]]
|style="padding-left:10px; padding-right:10px; padding-bottom:10px;" |Never apply more than -15 dBm of power into any RF input.
|-
|style="padding-left:10px; padding-right:10px; padding-bottom:10px;" |[[File:Caution.png|24px|center]]
|style="padding-left:10px; padding-right:10px; padding-bottom:10px;" |Always use at least 30dB attenuation if operating in loopback configuration
|-
|}

==Install and Setup the Software Tools on Your Host Computer==
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.

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.

==Connect the USRP to the Host Computer==
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).

==Test and Verify the Operation of the USRP==
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.

==Technical Support and Community Knowledge Base==
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.

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.

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

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

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

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

==Legal Considerations==
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.

*NOTE: This USRP product is a piece of test equipment.

==Sales and Ordering Support==
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.

==Terms and Conditions of Sale==
Terms and conditions of sale can be accessed online at the following link: http://www.ettus.com/legal/terms-and-conditions-of-sale

[[Category:Getting Started Guides]]

RFNoC 4 Migration Guide

2022-02-16T19:32:39Z

JonathonPendlum: Updates for UHD 4.1 and fixing typos

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

=Prerequisites=

===Dependencies (Ubuntu 20.04)===
sudo apt-get install autoconf automake build-essential ccache cmake cpufrequtils doxygen ethtool \
g++ git inetutils-tools libboost-all-dev libncurses5 libncurses5-dev libusb-1.0-0 libusb-1.0-0-dev \
libusb-dev python3-dev python3-mako python3-numpy python3-requests python3-scipy python3-setuptools \
python3-ruamel.yaml libtinfo5 libncurses5

===Vivado 2019.1 Design Edition===

Please reference to Xilinx (xilinx.com) for installation instructions.

''Note: The dependencies step above included installing libtinfo5 libncurses5, which is a workaround for getting Vivado 2019.1 to run on Ubuntu 20.04''

===UHD 4.1===
git clone --branch UHD-4.1 https://github.com/ettusresearch/uhd.git uhd
mkdir uhd/host/build; cd uhd/host/build
cmake ..
make
sudo make install

===GNU Radio 3.8===
'' Note: If your design does not use GNU Radio, then installing GNU Radio and gr-ettus is not required ''

git clone --branch maint-3.8 --recursive https://github.com/gnuradio/gnuradio.git gnuradio
mkdir gnuradio/build; cd gnuradio/build;
cmake ..
make
sudo make install

Please refer to the [https://wiki.gnuradio.org/index.php/UbuntuInstall GNU Radio Build Instructions] for dependencies and a more detailed description.

===gr-ettus===
git clone --branch maint-3.8-uhd4.0 https://github.com/ettusresearch/gr-ettus.git gr-ettus
mkdir gr-ettus/build; cd gr-ettus/build;
cmake -DENABLE_QT=True ..
make
sudo make install

=RFNoC Block Development Environment=

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.

===Migrating a GNU Radio Out-of-Tree Module===

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.

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.

====Creating a RFNoC Block with rfnocmodtool====

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.

rfnocmodtool newmod
Name of the new module: '''example'''

cd rfnoc-tutorial
rfnocmodtool add
Enter name of block/code (without module name prefix): '''gain'''
Enter valid argument list, including default arguments: ''(leave blank)''
Add Python QA code? [y/N] '''N'''
Add C++ QA code? [y/N] '''N'''
Block NoC ID (Hexadecimal): ''(Enter Noc ID of your block)''
Skip Block Controllers Generation? [UHD block ctrl files] [y/N] '''N'''
Skip Block interface files Generation? [GRC block ctrl files] [y/N] '''N'''

''Note: Noc IDs have been reduced from 64-bits in RFNoC 3 to 32-bits in RFNoC 4''

The following are the relevant files that need to be updated when migrating your RFNoC Block.

rfnoc-example/
grc/
example_gain.block.yml – RFNoC Block GNU Radio Companion YAML file
examples/
gain.grc – Example flowgraph using gain RFNoC Block
include/tutorial/
gain.h – GNU Radio block C++ header
gain_block_ctrl.hpp – RFNoC Block Controller C++ header
lib/
gain_impl.cc – GNU Radio block C++ source
gain_impl.h – GNU Radio block C++ header
gain_block_ctrl_impl.cpp – RFNoC Block Controller C++ source
rfnoc/blocks/
gain.yml – RFNoC Block Description YAML file
rfnoc/fpga/rfnoc_block_gain
noc_shell_gain.v – RFNoC Block Noc Shell Verilog Source
rfnoc_block_gain.v – RFNoC Block Verilog Source
rfnoc_block_gain_tb.v – RFNoC Block Testbench
rfnoc/icores
gain_x310_rfnoc_image_core.yml – Image Core YAML file with gain block

====Building OOT module====

cd rfnoc-tutorial
mkdir build; cd build
cmake -DUHD_FPGA_DIR=''(path to uhd/fpga directory)'' ..
make
sudo make install

====Running a testbench====
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:

cd rfnoc-tutorial/build
make rfnoc_block_gain_tb

====Building a FPGA image====
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:

cd rfnoc-tutorial/build
make gain_x310_rfnoc_image_core

===Migrating a Standalone UHD C++ Application===

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.

The following are the relevant files that need to be updated when migrating your RFNoC Block.

rfnoc-example/
apps/
init_gain_block.cpp – Example C++ application testing gain block
blocks/
gain.yml – RFNoC Block Description YAML file
fpga/rfnoc_block_gain
noc_shell_gain.v – RFNoC Block Noc Shell Verilog Source
rfnoc_block_gain.v – RFNoC Block Verilog Source
rfnoc_block_gain_tb.v – RFNoC Block Testbench
icores/
x310_rfnoc_image_core.yml – Example Image Core YAML file
include/rfnoc/example
gain_block_control.hpp – RFNoC Block Controller C++ header
lib/
gain_block_control.cpp – RFNoC Block Controller C++ source

====Building rfnoc-example====

cd rfnoc-example
mkdir build; cd build
cmake ..
make
sudo make install

====Running a testbench====
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:

cd rfnoc-example/build
make rfnoc_block_gain_tb

====Building a FPGA image====
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:

cd rfnoc-tutorial/build
make gain_x310_rfnoc_image_core

=Example RFNoC 3 to RFNoC 4 Block Migration=

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.

=UHD Software Migration=

Migration reference files for this section from the Gain RFNoC Block example:

{| class="wikitable"
! Description || RFNoC 3 Files || RFNoC 4 Files
|-
| Block Description || rfnoc/blocks/gain.xml || lib/gain_block_ctrl_impl.cpp <br>include/example/gain_block_ctrl.hpp
|-
| Block Controller || rfnoc/blocks/gain.yml || lib/gain_block_ctrl_impl.cpp <br>include/example/gain_block_ctrl.hpp
|}

''Note: Files are relative to the rfnoc-example directory in the respective rfnoc3 and rfnoc4 directories''

===Noc Script XML Replaced by Block Description YAML===

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.

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:

{| class="wikitable"
! Item || Noc Script XML || Block Descript YAML || RFNoC 4 Notes
|-
| Block Name
||
<name>gain</name>
||
module_name: gain
||
|-
| Noc ID
||
<id>B160000000000000</id>
||
noc_id: 0xB16
||
Noc ID are limited to 32-bits
|-
| Registers
||
<registers>
<setreg>
<name>GAIN</name>
<address>128</address>
</setreg>
</registers>
||
N/A
||
Registers must be defined in the Block Controller
|-
| Arguments
||
<args>
<arg>
<name>gain</name>
<type>int</type>
...
</arg>
</args>
||
N/A
||
Args are implemented with properties in the Block Controller
|-
| Data Ports
||
<ports>
<sink>
<name>in</name>
</sink>
<source>
<name>out</name>
</source>
</ports>
||
data:
fpga_iface: axis_pyld_ctxt
clk_domain: rfnoc_chdr
inputs:
in:
...
outputs:
out:
...
||
|-
| Control Ports
||
N/A
||
control:
sw_iface: nocscript
fpga_iface: ctrlport
interface_direction: slave
...
||
|-
| Clocking
||
N/A
||
clocks:
- name: rfnoc_chdr
freq: "[]"
- name: rfnoc_ctrl
freq: "[]"
||
|}

''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].''

===RFNoC API Changes===

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:

{| class="wikitable"
! RFNoC 3 || RFNoC 4 || RFNoC 4 Notes
|-
|
usrp = uhd::device3::make(...)
||
graph = uhd::rfnoc::rfnoc_graph::make()
||
No longer need to create a device3 object
|-
|
usrp->get_block_ctrl(...)
||
graph->get_block(...)
||
Rename
|-
|
N/A
||
graph->enumerate_static_connections()
||
Used to check static connections, for example the DDC and DUC blocks are usually statically connected to the radio block
|-
|
usrp->get_tx_streamer(...)
||
graph->create_tx_streamer(...)
||
Rename
|-
|
usrp->get_rx_streamer(...)
||
graph->create_rx_streamer(...)
||
Rename
|-
|
N/A
||
graph->commit()
||
Commit graph and run initial checks
|-
|
sr_write(...)
||
regs().poke32(...)
||
Address increments by 4
|-
|
sr_read32(...)
||
regs().peek32(...)
||
Address increments by 4
|-
|
sr_read64(...)
||
regs().poke64(...)
||
Address increments by 8
|-
|
set_arg(...)
||
set_property(...)
||
Block args replaced with block properties concept
|-
|
get_arg(...)
||
get_property(...)
||
Block args replaced with block properties concept
|}

===Block Properties===

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.

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.

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:

====RFNoC 3 Noc Script XML snippet====
<registers>
<setreg>
<name>GAIN</name>
<address>128</address>
</setreg>
</registers>

<args>
<arg>
<name>gain</name>
<type>int</type>
<value>1</value>
<check>GE($gain, 0) AND LE($gain, 32767)</check>
<check_message>Gain must be in the range [0, 32767]</check_message>
<action>SR_WRITE("GAIN", $gain)</action>
</arg>
</args>

====RFNoC 4 Block Controller Class====

// <registers>
// <setreg>
// <name>GAIN</name>
// <address>128</address>
// </setreg>
// </registers>
// Note: In RFNoC 4, register addresses can start at address 0 instead of address 128 as in RFNoC 3.
const uint32_t gain_block_ctrl::REG_GAIN_ADDR = 0;
const uint32_t gain_block_ctrl::REG_GAIN_DEFAULT = 1;

class gain_block_ctrl_impl : public gain_block_ctrl
{
public:
RFNOC_BLOCK_CONSTRUCTOR(gain_block_ctrl)
{
_register_props();
}
private:
void _register_props()
{
register_property(&_user_reg, [this]() {
int user_reg = this->_user_reg.get();
// <check>GE($gain, 0) AND LE($gain, 32767)</check>
// <check_message>Gain must be in the range [0, 32767]</check_message>
if (user_reg < 0 || user_reg > 32767) {
throw uhd::value_error("Size value must be in [0,32767]");
}
// <action>SR_WRITE("GAIN", $gain)</action>
this->regs().poke32(REG_USER_ADDR, user_reg);
});
}

// <name>gain</name>
// <type>int</type>
// <value>1</value>
property_t<int> _user_reg{"gain", REG_USER_DEFAULT, {res_source_info::USER}};
}

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

=FPGA Migration=

Migration reference files for this section from the Gain RFNoC Block example:

{| class="wikitable"
! Description || RFNoC 3 Files || RFNoC 4 Files
|-
| Block Verilog Code || rfnoc/fpga-src/noc_block_gain.v || rfnoc/fpga/rfnoc_block_gain/rfnoc_block_gain.v
|-
| Block Noc Shell || N/A || rfnoc/fpga/rfnoc_block_gain/noc_shell_gain.v
|-
| Block Testbnech || rfnoc/testbench/noc_block_gain/noc_block_gain_tb.sv || rfnoc/fpga/rfnoc_block_gain/rfnoc_block_gain_tb.sv
|-
| Image Core || N/A || rfnoc/icores/gain_x310_rfnoc_image_core.yml
|}

''Note: Files are relative to the rfnoc-example directory in the respective rfnoc3 and rfnoc4 directories''

===Noc Shell Changes===

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.

====Generating a Custom Noc Shell====

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.

The argument “-c” is used to provide the YAML file location. “-d” provides the output destination directory.

''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!''

Example usage:
rfnoc_create_verilog.py -c ./rfnoc-example/rfnoc/blocks/gain.yml -d ./output/

====Changing Noc ID without using rfnoc_create_verilog====

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.

====Goodbye AXI Wrapper====

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.

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.

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

===Settings Bus replaced by CtrlPort===

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

{| class="wikitable"
! Settings Bus (RFNoC 3) || CtrlPort (RFNoC 4) || RFNoC 4 Notes
|-
| set_stb || ctrlport_reg_wr || Write strobe
|-
| 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)
|-
| set_data || ctrlport_req_data || Write data
|-
| N/A || ctrlport_req_rd || Read strobe equivalent of ctrlport_req_wr
|-
| rb_addr || N/A || CtrlPort uses ctrlport_req_addr for both '''read and write''' addresses
|-
| rb_data || ctrlport_resp_data || Read data, 32-bits instead of 64-bits
|-
| rb_stb || N/A || CtrlPort requires ack strobe for '''reads and writes'''
|}

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:

// Note: Register addresses increment by 4
localparam REG_USER_ADDR = 0; // Address for example user register
localparam REG_USER_DEFAULT = 0; // Default value for user register

reg [31:0] reg_user = REG_USER_DEFAULT;

always @(posedge ctrlport_clk) begin
if (ctrlport_rst) begin
reg_user = REG_USER_DEFAULT;
end else begin
// Default assignment
m_ctrlport_resp_ack <= 0;

// Read user register
if (m_ctrlport_req_rd) begin // Read request
case (m_ctrlport_req_addr)
REG_USER_ADDR: begin
m_ctrlport_resp_ack <= 1;
m_ctrlport_resp_data <= reg_user;
end
endcase
end

// Write user register
if (m_ctrlport_req_wr) begin // Write requst
case (m_ctrlport_req_addr)
REG_USER_ADDR: begin
m_ctrlport_resp_ack <= 1;
reg_user <= m_ctrlport_req_data[31:0];
end
endcase
end
end
end

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

===Testbench Infrastructure===

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.

{| class="wikitable"
! Operation || RFNoC 3 || RFNoC 4
|-
| Setup RFNoC
||
`RFNOC_SIM_INIT(...)
`RFNOC_ADD_BLOCK(...)
`RFNOC_CONNECT(...)
||
RfnocBlockCtrlBfm #(...) blk_ctrl = new(...);
blk_ctrl.connect_master_data_port(...)
blk_ctrl.connect_slave_data_port(...)
''Note: Instantiate one Block Controller BFM per RFNoC Block''
|-
| Setup Test Cases
||
`TEST_CASE_START(...)
`TEST_CASE_DONE(...)
||
test.start_test(...)
test.end_test()
|-
| Register Read
||
tb_streamer.read_reg(...)
||
blk_ctrl.reg_read(...)
|-
| Register Write
||
tb_streamer.write_reg(...)
||
blk_ctrl.reg_write(...)
|-
| Send Data / Samples
||
tb_streamer.send(...)
||
blk_ctrl.send_items(...)
|-
| Receive Data / Samples
||
tb_streamer.recv(...)
||
blk_ctrl.recv_items(...)
|}

===Building FPGA images using Image Core YAML Files===

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.

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

=GNU Radio Software Migration=

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.

Migration reference files for this section from the Gain RFNoC Block example:

{| class="wikitable"
! Description || RFNoC 3 Files || RFNoC 4 Files
|-
| 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
|-
| GRC Block Description || grc/gain.xml || grc/gain.yml
|-
| Example GRC Flowgraph || examples/gain.grc || examples/gain.grc
|}

''Note: Files are relative to the rfnoc-example directory in the respective rfnoc3 and rfnoc4 directories''

===RX & TX Streamer Blocks===

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.

[[File:rx_tx_streamer.png|border]]

===Setting RFNoC Block Properties Directly in GNU Radio===

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.

{| class="wikitable"
! Property Type || Set Property || Get Property
|-
| Integer || set_int_property(...) || get_int_property(...)
|-
| Double || set_double_property(...) || get_double_property(...)
|-
| Bool || set_bool_property(...) || get_bool_property(...)
|-
| String || set_string_property(...) || get_string_property(...)
|-
|}

'''Example code for GNU Radio Companion YAML Block Description file'''
templates:
imports: |-
import example
make: |-
example.gain(
self.rfnoc_graph,
uhd.device_addr(${block_args}),
${device_select},
${instance_select})
self.${id}.set_int_property('gain', ${gain})
callbacks:
- set_int_property('gain', ${gain})

File:migration example.zip

2022-02-16T19:32:12Z

JonathonPendlum: JonathonPendlum uploaded a new version of File:migration example.zip

Example designs for RFNoC 4 Migration Guide

Knowledge Base

2022-02-16T18:47:13Z

JonathonPendlum: /* Getting Started Guides */

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].
__NOTOC__
<div class="row">
<div class="col-1-3">
== [[Getting Started Guides|<i class="fa fa-road"></i> Getting Started Guides]] ==

'''Motherboards'''
* [[B200/B210/B200mini/B205mini Getting Started Guides|B200/B210/B200mini/B205mini]]
* [[Ettus USRP E300 Embedded Family Getting Started Guides|E310/E312/E313]]
* [[E320 Getting Started Guide|E320]]
* [[N200/N210 Getting Started Guides|N200/N210]]
* [[USRP N300/N310/N320/N321 Getting Started Guide|N300/N310/N320/N321]]
* [[X300/X310 Getting Started Guides|X300/X310]]
* [[USRP-2974 Getting Started Guide|USRP-2974]]
* [[USRP X410 Getting Started Guide|X410]]

'''Daughterboards'''
* [[BasicTX/BasicRX Getting Started Guides|BasicTX/BasicRX]]
* [[CBX Getting Started Guides|CBX]]
* [[LFTX/LFRX Getting Started Guides|LFTX/LFRX]]
* [[SBX Getting Started Guides|SBX]]
* [[TwinRX Getting Started Guides|TwinRX]]
* [[UBX Getting Started Guides|UBX]]
* [[WBX Getting Started Guides|WBX]]

'''Other'''
* [[Getting_Started_with_RFNoC_in_UHD_4.0|RFNoC Development (UHD 4.x)]]
* [[RFNoC_4_Migration_Guide|RFNoC Migration Guide (UHD 3.x to UHD 4.x)]]
* [[Getting_Started_with_RFNoC_Development|RFNoC Development (UHD 3.x)]]
* [[Live SDR Environment Getting Started Guides|Live SDR Environment]]
* [[OctoClock CDA-2990 Getting Started Guides|OctoClock CDA-2990]]
* [[Using Ethernet-Based Synchronization on the USRP™ N3xx Devices|White Rabbit]]
* [[Getting Started with DPDK and UHD|DPDK]]

</div>
<div class="col-1-3">

== [[Hardware Resources|<i class="fa fa-cogs"></i> Hardware Resources]] ==
'''Motherboards'''
* [[B200/B210/B200mini/B205mini]]
* [[Ettus USRP E300 Embedded Family Hardware Resources|E310/E312/E313]]
* [[E320|E320]]
* [[N200/N210]]
* [[N300/N310]]
* [[N320/N321]]
* [[X300/X310]]
* [[USRP-2974]]

'''Daughterboards'''
* [[BasicTX/BasicRX]]
* [[CBX]]
* [[LFTX/LFRX]]
* [[SBX]]
* [[TwinRX]]
* [[UBX]]
* [[WBX]]

'''Other'''
* [[OctoClock CDA-2990]]
* [[GPSDO]]
* [[Antennas]]

</div>
<div class="col-1-3">

== [[Software Resources|<i class="fa fa-desktop"></i> Software Resources]] ==
'''Ettus Products'''
* [[UHD]]
* [[UHD Python API]]
* [[Getting_Started_with_RFNoC_in_UHD_4.0|RFNoC (UHD 4.x)]]
* [[RFNoC]] (UHD 3.x)

'''Third Party'''
* [[GNU Radio]]
* [[LabVIEW]]
* [[Matlab/Simulink]]
* [[OpenBTS]]
* [[Eurecom OpenAirInterface (OAI)]]
* [[srsLTE/srsUE]]
* [[Gqrx]]
* [[Fosphor]]

'''Reference Architectures'''
* [[Open Architecture For Radar and EW Research]]

</div>
</div>

<div class="row">
<div class="col-1-3">

== [[UHD and USRP User Manual|<i class="fa fa-flag"></i> UHD and USRP User Manual]] ==
'''Software'''
* [http://files.ettus.com/manual/ UHD Manual (master)]
* [https://files.ettus.com/manual_archive/ UHD Manual Archive (previous releases)]

'''Motherboards'''
* [http://files.ettus.com/manual/page_usrp_b200.html B200/B210/B200mini/B205mini]
* [http://files.ettus.com/manual/page_usrp_x3x0.html X300/X310]
* [http://files.ettus.com/manual/page_usrp2.html N200/N210]
* [http://files.ettus.com/manual/page_usrp_n3xx.html N300/N310/N320/N321]
* [http://files.ettus.com/manual/page_usrp_e3xx.html E310/E312/E313/E320]

'''Daughterboards'''
* [http://files.ettus.com/manual/page_dboards.html#dboards_basictx BasicRX/LFRX]
* [http://files.ettus.com/manual/page_dboards.html#dboards_basicrx BasicTX/LFTX]
* [http://files.ettus.com/manual/page_dboards.html#dboards_cbx CBX]
* [http://files.ettus.com/manual/page_dboards.html#dboards_sbx SBX]
* [http://files.ettus.com/manual/page_dboards.html#dboards_wbx WBX]
* [http://files.ettus.com/manual/page_dboards.html#dboards_ubx UBX]
* [http://files.ettus.com/manual/page_dboards.html#dboards_twinrx TwinRX]

'''Other'''
* [http://files.ettus.com/manual/page_octoclock.html OctoClock]

</div>
<div class="col-1-3">

== [[Application Notes|<i class="fa fa-file-text-o"></i> Application Notes]] ==
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.
</div>
<div class="col-1-3">

== [[Additional Resources|<i class="fa fa-book"></i> Additional Resources]] ==
* [[Suggested Reading|Suggested Reading]]
* [[Suggested Videos|Suggested Videos]]
* [[SDR Events]]
* [[CGRAN]]
</div>
</div>

<div class="row">
<div class="col-1-3">

== [[Technical Support|<i class="fa fa-life-ring"></i> Technical Support]] ==
* [[Email|Email]]
* [[Mailing Lists|Mailing Lists]]
* [[Slack|Slack]]
* [[Internet Relay Chat (IRC)|Internet Relay Chat (IRC)]]
* [[StackExchange|StackExchange]]
* [[Ordering and Fulfillment Help | Ordering and Fulfillment Help]]

</div>
<div class="col-1-3">

== [[Faq|<i class="fa fa-info-circle"></i> FAQ]] ==
* [[Technical FAQ|Technical]]
* [[Licensing FAQ|Licensing]]

</div>
<div class="col-1-3">

== [[Legacy Products| <i class="fa fa-hourglass-end"></i> Legacy Products]] ==
'''Motherboards'''
* [[USRP1|USRP1]]
* [[USRP2|USRP2]]
* [[E100/E110|E100/E110]]
* [[B100]]

'''Daughterboards'''
* [[DBSRX2]]
* [[TVRX2]]
* [[XCVR2450]]

Mailing Lists

2021-03-18T18:30:59Z

JonathonPendlum: Updated usrp mailing list URLs

== usrp-users ==
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/>
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].

== discuss-gnuradio ==

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/>
The list archives can be found at [http://lists.gnu.org/archive/html/discuss-gnuradio/ http://lists.gnu.org/archive/html/discuss-gnuradio/].

== openbts-discuss ==

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/>
The list archives can be found at [https://sourceforge.net/p/openbts/mailman/openbts-discuss/ https://sourceforge.net/p/openbts/mailman/openbts-discuss/].

== srslte-users ==

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/>
The list archives can be found at [https://www.softwareradiosystems.com/pipermail/srslte-users/ https://www.softwareradiosystems.com/pipermail/srslte-users/].

== Open Air Interface (OAI) Mailing Lists ==

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:
*[https://gitlab.eurecom.fr/oai/openairinterface5g/wikis/AskQuestions https://gitlab.eurecom.fr/oai/openairinterface5g/wikis/AskQuestions]
* [https://gitlab.eurecom.fr/oai/openairinterface5g/wikis/MailingList https://gitlab.eurecom.fr/oai/openairinterface5g/wikis/MailingList].

The list archives can be found at the following links:
* [http://lists.eurecom.fr/sympa/arc/openair5g-user http://lists.eurecom.fr/sympa/arc/openair5g-user]
* [http://lists.eurecom.fr/sympa/arc/openair5g-devel http://lists.eurecom.fr/sympa/arc/openair5g-devel]
* [http://lists.eurecom.fr/sympa/arc/openaircn-user http://lists.eurecom.fr/sympa/arc/openaircn-user]
* [http://lists.eurecom.fr/sympa/arc/openaircn-devel http://lists.eurecom.fr/sympa/arc/openaircn-devel]

[[Category:Technical Support]]

Application Notes

2020-12-29T21:35:45Z

JonathonPendlum:

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.

{| class="wikitable"
!colspan="4"|Application Notes
|-

! style="text-align:center;"| Number
! style="text-align:center;"| Title
! style="text-align:center;"| Abstract
! style="text-align:center;"| Author
|-

|style="width: 10%; text-align: center;"| AN-445
|style="width: 30%;"| [[Building and Installing the USRP Open-Source Toolchain (UHD and GNU Radio) on Linux]]
|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.
|style="width: 10%; text-align: center;"| Neel Pandeya
|-

|style="width: 10%; text-align: center;"| AN-788
|style="width: 30%;"| [[Building and Installing the USRP Open-Source Toolchain (UHD and GNU Radio) on OS X]]
|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.
|style="width: 10%; text-align: center;"|Michael Dickens
|-

|style="width: 10%; text-align: center;"| AN-666
|style="width: 30%;"| [[Mean Time Between Failure (MTBF) of USRPs and Daughterboards]]
|style="width: 50%;"| This AN provides information about the MTBF for USRPs and daughterboards
|style="width: 10%; text-align: center;"|Michael Dickens
|-

|style="width: 10%; text-align: center;"| AN-111
|style="width: 30%;"| [[UHD Device Eraser and Certificates of Volatility]]
|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.
|style="width: 10%; text-align: center;"|Michael Dickens
|-

|style="width: 10%; text-align: center;"| AN-611
|style="width: 30%;"| [[Building and Installing the USRP Open Source Toolchain (UHD and GNU Radio) on Windows]]
|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.
|style="width: 10%; text-align: center;"|Derek Kozel
|-

|style="width: 10%; text-align: center;"| AN-936
|style="width: 30%;"| [[Verifying the Operation of the USRP Using UHD and GNU Radio]]
|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.
|style="width: 10%; text-align: center;"|Neel Pandeya
|-

|style="width: 10%; text-align: center;"| AN-561
|style="width: 30%;"| [[Implementation of a Simple FM Receiver in GNU Radio]]
|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.
|style="width: 10%; text-align: center;"|Neel Pandeya
|-

|style="width: 10%; text-align: center;"| AN-188
|style="width: 30%;"| [[Interrogating Passive Wireless SAW Sensors with the USRP]]
|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.
|style="width: 10%; text-align: center;"|Trip Humphries
|-

|style="width: 10%; text-align: center;"| AN-322
|style="width: 30%;"| [[Experiments with the UBX Daughterboard in the HF Band]]
|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.
|style="width: 10%; text-align: center;"|Marcus Leech
|-

|style="width: 10%; text-align: center;"| AN-363
|style="width: 30%;"| [[Implementation of an ADS-B/Mode-S Receiver in GNU Radio]]
|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.
|style="width: 10%; text-align: center;"|Nate Temple
|-

|style="width: 10%; text-align: center;"| AN-177
|style="width: 30%;"| [[About USRP Bandwidths and Sampling Rates]]
|style="width: 50%;"| This AN provides insight into the topics of USRP architecture, system bandwidth, host interface throughput, and available sampling rates.
|style="width: 10%; text-align: center;"|Neel Pandeya <br> Nate Temple
|-

|style="width: 10%; text-align: center;"| AN-881
|style="width: 30%;"| [[Selecting a USRP Device]]
|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.
|style="width: 10%; text-align: center;"|Neel Pandeya <br> Nate Temple
|-

|style="width: 10%; text-align: center;"| AN-492
|style="width: 30%;"| [[Selecting a RF Daughterboard]]
|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.
|style="width: 10%; text-align: center;"|Neel Pandeya <br> Nate Temple
|-

|style="width: 10%; text-align: center;"| AN-204
|style="width: 30%;"| [[Getting Started with UHD and C++]]
|style="width: 50%;"| This AN explains how to write and build C++ programs that use the UHD API and introduces
|style="width: 10%; text-align: center;"|Neel Pandeya <br> Nate Temple
|-

|style="width: 10%; text-align: center;"| AN-117
|style="width: 30%;"| [[GPSDO Selection Guide]]
|style="width: 50%;"| This AN explains how to select and use a GPSDO with the USRP B-, N-, and X-series devices.
|style="width: 10%; text-align: center;"|Neel Pandeya <br> Nate Temple
|-

|style="width: 10%; text-align: center;"| AN-503
|style="width: 30%;"| [[Converting an X310 into an NI-USRP Rio]]
|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.
|style="width: 10%; text-align: center;"|Tim Fountain
|-

|style="width: 10%; text-align: center;"| AN-638
|style="width: 30%;"| [[Running UHD and GNU Radio on NI-USRP RIO]]
|style="width: 50%;"| This AN explains the process to updating your USRP-Rio to run UHD and GNU Radio.
|style="width: 10%; text-align: center;"|Neel Pandeya <br> Nate Temple
|-

|style="width: 10%; text-align: center;"| AN-882
|style="width: 30%;"| [[Synchronization and MIMO Capability with USRP Devices]]
|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.
|style="width: 10%; text-align: center;"|Neel Pandeya <br> Nate Temple
|-

|style="width: 10%; text-align: center;"| AN-309
|style="width: 30%;"| [[About the Motherboard and Daughtercard EEPROM on USRP Devices]]
|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.
|style="width: 10%; text-align: center;"|Trip Humphries
|-

|style="width: 10%; text-align: center;"| AN-325
|style="width: 30%;"| [[N200/N210 Device Recovery]]
|style="width: 50%;"| This application note covers the details of recovering your N200/N210.
|style="width: 10%; text-align: center;"|Neel Pandeya <br> Nate Temple
|-

|style="width: 10%; text-align: center;"| AN-504
|style="width: 30%;"| [[USRP N Series Quick Start (Daughterboard Installation)]]
|style="width: 50%;"| This application note is a detailed step-by-step guide to install a daughterboard into the USRP N200/N210.
|style="width: 10%; text-align: center;"|Neel Pandeya <br> Nate Temple
|-

|style="width: 10%; text-align: center;"| AN-904
|style="width: 30%;"| [[USRP X Series Quick Start (Daughterboard Installation)]]
|style="width: 50%;"| This application note is a detailed step-by-step guide to install a daughterboard into the USRP X300/X310.
|style="width: 10%; text-align: center;"|Neel Pandeya <br> Nate Temple
|-

|style="width: 10%; text-align: center;"| AN-311
|style="width: 30%;"| [[Software Development on the E310 and E312]]
|style="width: 50%;"| This application note covers the software development process on the USRP E310 and E312.
|style="width: 10%; text-align: center;"|Martin Braun<br>Nicolas Cuervo
|-

|style="width: 10%; text-align: center;"| AN-296
|style="width: 30%;"| [[Using Dual 10 Gigabit Ethernet on the USRP X300/X310]]
|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.
|style="width: 10%; text-align: center;"|Paul David
|-

|style="width: 10%; text-align: center;"| AN-823
|style="width: 30%;"| [[Getting Started with RFNoC Development]]
|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.
|style="width: 10%; text-align: center;"|Martin Braun<br>Nicolas Cuervo
|-

|style="width: 10%; text-align: center;"| AN-178
|style="width: 30%;"| [[Resolving Audio Codec Enumeration Issues On The E31x]]
|style="width: 50%;"| This application note covers Resolving Audio Codec Enumeration Issues On The E31x.
|style="width: 10%; text-align: center;"|Logan Fagg
|-

|style="width: 10%; text-align: center;"| AN-244
|style="width: 30%;"| [[Direction Finding with the USRP™ X-Series and TwinRX™]]
|style="width: 50%;"| This application note covers using the USRP™ TwinRX™ daughterboard in a direction find application using the MUSIC algorithm.
|style="width: 10%; text-align: center;"|Srikanth Pagadarai<br>Travis Collins<br>Alexander M. Wyglinski
|-

|style="width: 10%; text-align: center;"| AN-335
|style="width: 30%;"| [[Streaming processed data from the E31x with GNU Radio and ZMQ]]
|style="width: 50%;"| This application note will demonstrate using the USRP E310 to remotely stream processed data to a host machine.
|style="width: 10%; text-align: center;"| Nate Temple
|-

|style="width: 10%; text-align: center;"| AN-121
|style="width: 30%;"| [[Debugging FPGA images]]
|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.
|style="width: 10%; text-align: center;"|Nicolas Cuervo<br>Sugandha Gupta
|-

|style="width: 10%; text-align: center;"| AN-732
|style="width: 30%;"| [[USRP E312 Battery Replacement Instructions]]
|style="width: 50%;"| This application note covers replacing the battery cell inside the USRP E312.
|style="width: 10%; text-align: center;"| Robin Coxe
|-

|style="width: 10%; text-align: center;"| AN-305
|style="width: 30%;"| [[X300/X310 Device Recovery]]
|style="width: 50%;"| This application note covers the details of recovering the USRP X300/X310 via JTAG.
|style="width: 10%; text-align: center;"| Nate Temple
|-

|style="width: 10%; text-align: center;"| AN-832
|style="width: 30%;"| [[Mapping Between ER-USRP and NI-USRP Product Numbers]]
|style="width: 50%;"| This application note covers the details of the mapping between Ettus Research USRP and National Instruments USRP product numbers.
|style="width: 10%; text-align: center;"| Nate Temple
|-

|style="width: 10%; text-align: center;"| AN-315
|style="width: 30%;"| [[Software Development on the E3xx USRP - Building RFNoC UHD / GNU Radio / gr-ettus from Source]]
|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.
|style="width: 10%; text-align: center;"| Nate Temple
|-

|style="width: 10%; text-align: center;"| AN-142
|style="width: 30%;"| [[Transmitting DVB-S2 with GNU Radio and an USRP B210]]
|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.
|style="width: 10%; text-align: center;"| Nate Temple
|-

|style="width: 10%; text-align: center;"| AN-158
|style="width: 30%;"| [[Using Ethernet-Based Synchronization on the USRP™ N3xx Devices]]
|style="width: 50%;"| This application note provides instructions for synchronizing multiple USRP N3xx devices using White Rabbit Ethernet-based synchronization.
|style="width: 10%; text-align: center;"| Dan Baker
Wan Liu
|-

|style="width: 10%; text-align: center;"| AN-642
|style="width: 30%;"| [[Using the RFNoC Replay Block]]
|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.
|style="width: 10%; text-align: center;"| Wade Fife
|-

|style="width: 10%; text-align: center;"| AN-630
|style="width: 30%;"| [[Writing the USRP File System Disk Image to a SD Card]]
|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.
|style="width: 10%; text-align: center;"| Nate Temple
|-

|style="width: 10%; text-align: center;"| AN-524
|style="width: 30%;"| [[Building and Installing UHD and GNU Radio in an Offline Environment]]
|style="width: 50%;"| This application note will provide step-by-step instructions on building and installing UHD and GNU Radio in an offline environment.
|style="width: 10%; text-align: center;"| Nate Temple
|-

|style="width: 10%; text-align: center;"| AN-525
|style="width: 30%;"| [[Building and Installing UHD and GNU Radio to a Custom Prefix]]
|style="width: 50%;"| This application note provides step-by-step instructions on building and installing UHD and GNU Radio to a local directory.
|style="width: 10%; text-align: center;"| Nate Temple
|-

|style="width: 10%; text-align: center;"| AN-725
|style="width: 30%;"| [[USRP N320/N321 LO Distribution]]
|style="width: 50%;"| This application note provides an overview of using the LO Distribution of the N320/N321 USRPs.

|style="width: 10%; text-align: center;"| Brian Avenell
|-

|style="width: 10%; text-align: center;"| AN-452
|style="width: 30%;"| [[5G NR EVM Measurements with the USRP N320/N321]]
|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.
|style="width: 10%; text-align: center;"| Drew Fischer
|-

|style="width: 10%; text-align: center;"| AN-620
|style="width: 30%;"| [[Troubleshooting X300/X310 Device Discovery Issues]]
|style="width: 50%;"| Troubleshooting guide to intended to cover some of the most commonly recommended steps to enable USRP connectivity.
|style="width: 10%; text-align: center;"| Sam Reiter
|-

|style="width: 10%; text-align: center;"| AN-088
|style="width: 30%;"| [[USRP Host Performance Tuning Tips and Tricks]]
|style="width: 50%;"| This application note provides various tips and tricks for tuning your host computer for best performance when working with USRP devices.
|style="width: 10%; text-align: center;"| Nate Temple
|-

|style="width: 10%; text-align: center;"| AN-355
|style="width: 30%;"| [[Modifying an X310 Chassis for External LO Sharing]]
|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.
|style="width: 10%; text-align: center;"| Sam Reiter
|-

|style="width: 10%; text-align: center;"| AN-500
|style="width: 30%;"| [[Getting Started with DPDK and UHD]]
|style="width: 50%;"| This application note walks through the process to get started with the Data Plane Development Kit (DPDK) driver within UHD.
|style="width: 10%; text-align: center;"| Nate Temple
Alex Williams
|-

|style="width: 10%; text-align: center;"| AN-800
|style="width: 30%;"| [[Enabling Ethernet Connectivity on Octoclock and Octoclock-G]]
|style="width: 50%;"| This document supplements the UHD Manual's guide for updating the Octoclock bootloader to allow for Ethernet communications with the device.
|style="width: 10%; text-align: center;"| Sam Reiter
|-

|style="width: 10%; text-align: center;"| AN-621
|style="width: 30%;"| [[Troubleshooting N310/N320 Device Discovery Issues]]
|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.
|style="width: 10%; text-align: center;"| Sam Reiter
|-

|style="width: 10%; text-align: center;"| AN-883
|style="width: 30%;"| [[Synchronizing USRP Events Using Timed Commands in UHD]]
|style="width: 50%;"| Guide to cover common USRP synchronization scenarios and deep-dive into the use of timed commands within USRPs.
|style="width: 10%; text-align: center;"| Sam Reiter
|-

|style="width: 10%; text-align: center;"| AN-400
|style="width: 30%;"| [[Getting Started with RFNoC in UHD 4.0]]
|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.
|style="width: 10%; text-align: center;"| Sugandha Gupta<br>Brent Stapleton<br>Wade Fife
|-

|style="width: 10%; text-align: center;"| AN-401
|style="width: 30%;"| [[RFNoC 4 Migration Guide]]
|style="width: 50%;"| Guide on how to migrate RFNoC blocks written for RFNoC 3 to RFNoC 4.
|style="width: 10%; text-align: center;"| Jonathon Pendlum
|-

|}

RFNoC 4 Migration Guide

2020-12-29T08:39:02Z

JonathonPendlum:

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

=Prerequisites=

===Dependencies (Ubuntu 20.04)===
git cmake g++ libboost-all-dev libgmp-dev swig \
python3-numpy python3-mako python3-sphinx python3-lxml \
doxygen libfftw3-dev libsdl1.2-dev libgsl-dev libqwt-qt5-dev \
libqt5opengl5-dev python3-pyqt5 liblog4cpp5-dev libzmq3-dev \
python3-yaml python3-click python3-click-plugins python3-zmq \
python3-scipy python3-gi python3-gi-cairo gobject-introspection \
gir1.2-gtk-3.0 build-essential libusb-1.0-0-dev python3-docutils \
python3-setuptools python3-ruamel.yaml python-is-python3 \
libtinfo5 libncurses5

===Vivado 2019.1 Design Edition===

Please reference to Xilinx (xilinx.com) for installation instructions.

''Note: The dependencies step above included installing libtinfo5 libncurses5, which is a workaround for getting Vivado 2019.1 to run on Ubunbtu 20.04''

===UHD 4.0===
git clone --branch UHD-4.0 https://github.com/ettusresearch/uhd.git uhd
mkdir uhd/host/build; cd uhd/host/build
cmake ..
make
sudo make install

===GNU Radio 3.8===
'' Note: If your design does not use GNU Radio, then installing GNU Radio and gr-ettus is not required ''

git clone --branch maint-3.8 --recursive https://github.com/gnuradio/gnuradio.git gnuradio
mkdir gnuradio/build; cd gnuradio/build;
cmake ..
make
sudo make install

===gr-ettus===
git clone --branch maint-3.8-uhd4.0 https://github.com/ettusresearch/gr-ettus.git gr-ettus
mkdir gr-ettus/build; cd gr-ettus/build;
cmake -DENABLE_QT=True ..
make
sudo make install

=RFNoC Block Development Environment=

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.

===Migrating a GNU Radio Out-of-Tree Module===

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.

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.

====Creating a RFNoC Block with rfnocmodtool====

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.

rfnocmodtool newmod
Name of the new module: '''example'''

cd rfnoc-tutorial
rfnocmodtool add
Enter name of block/code (without module name prefix): '''gain'''
Enter valid argument list, including default arguments: ''(leave blank)''
Add Python QA code? [y/N] '''N'''
Add C++ QA code? [y/N] '''N'''
Block NoC ID (Hexadecimal): ''(Enter Noc ID of your block)''
Skip Block Controllers Generation? [UHD block ctrl files] [y/N] '''N'''
Skip Block interface files Generation? [GRC block ctrl files] [y/N] '''N'''

''Note: Noc IDs have been reduced from 64-bits in RFNoC 3 to 32-bits in RFNoC 4''

The following are the relevant files that need to be updated when migrating your RFNoC Block.

rfnoc-example/
grc/
example_gain.block.yml – RFNoC Block GNU Radio Companion YAML file
examples/
gain.grc – Example flowgraph using gain RFNoC Block
include/tutorial/
gain.h – GNU Radio block C++ header
gain_block_ctrl.hpp – RFNoC Block Controller C++ header
lib/
gain_impl.cc – GNU Radio block C++ source
gain_impl.h – GNU Radio block C++ header
gain_block_ctrl_impl.cpp – RFNoC Block Controller C++ source
rfnoc/blocks/
gain.yml – RFNoC Block Description YAML file
rfnoc/fpga/rfnoc_block_gain
noc_shell_gain.v – RFNoC Block Noc Shell Verilog Source
rfnoc_block_gain.v – RFNoC Block Verilog Source
rfnoc_block_gain_tb.v – RFNoC Block Testbench
rfnoc/icores
gain_x310_rfnoc_image_core.yml – Image Core YAML file with gain block

====Building OOT module====

cd rfnoc-tutorial
mkdir build; cd build
cmake -DUHD_FPGA_DIR=''(path to uhd/fpga directory)'' ..
make
sudo make install

====Running a testbench====
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:

cd rfnoc-tutorial/build
make rfnoc_block_gain_tb

====Building a FPGA image====
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:

cd rfnoc-tutorial/build
make gain_x310_rfnoc_image_core

===Migrating a Standalone UHD C++ Application===

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.

The following are the relevant files that need to be updated when migrating your RFNoC Block.

rfnoc-example/
apps/
init_gain_block.cpp – Example C++ application testing gain block
blocks/
gain.yml – RFNoC Block Description YAML file
fpga/rfnoc_block_gain
noc_shell_gain.v – RFNoC Block Noc Shell Verilog Source
rfnoc_block_gain.v – RFNoC Block Verilog Source
rfnoc_block_gain_tb.v – RFNoC Block Testbench
icores/
x310_rfnoc_image_core.yml – Example Image Core YAML file
include/rfnoc/example
gain_block_control.hpp – RFNoC Block Controller C++ header
lib/
gain_block_control.cpp – RFNoC Block Controller C++ source

====Building rfnoc-example====

cd rfnoc-example
mkdir build; cd build
cmake ..
make
sudo make install

====Running a testbench====
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:

cd rfnoc-example/build
make rfnoc_block_gain_tb

====Building a FPGA image====
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:

cd rfnoc-tutorial/build
make gain_x310_rfnoc_image_core

=Example RFNoC 3 to RFNoC 4 Block Migration=

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.

=UHD Software Migration=

Migration reference files for this section from Gain RFNoC Block example:

{| class="wikitable"
! Description || RFNoC 3 Files || RFNoC 4 Files
|-
| Block Description || rfnoc/blocks/gain.xml || lib/gain_block_ctrl_impl.cpp <br>include/example/gain_block_ctrl.hpp
|-
| Block Controller || rfnoc/blocks/gain.yml || lib/gain_block_ctrl_impl.cpp <br>include/example/gain_block_ctrl.hpp
|}

''Note: Files are relative to the rfnoc-example directory in the respective rfnoc3 and rfnoc4 directories''

===Noc Script XML Replaced by Block Description YAML===

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.

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:

{| class="wikitable"
! Item || Noc Script XML || Block Descript YAML || RFNoC 4 Notes
|-
| Block Name
||
<name>gain</name>
||
module_name: gain
||
|-
| Noc ID
||
<id>B160000000000000</id>
||
noc_id: 0xB16
||
Noc ID are limited to 32-bits
|-
| Registers
||
<registers>
<setreg>
<name>GAIN</name>
<address>128</address>
</setreg>
</registers>
||
N/A
||
Registers must be defined in the Block Controller
|-
| Arguments
||
<args>
<arg>
<name>gain</name>
<type>int</type>
...
</arg>
</args>
||
N/A
||
Args are implemented with properties in the Block Controller
|-
| Data Ports
||
<ports>
<sink>
<name>in</name>
</sink>
<source>
<name>out</name>
</source>
</ports>
||
data:
fpga_iface: axis_pyld_ctxt
clk_domain: rfnoc_chdr
inputs:
in:
...
outputs:
out:
...
||
|-
| Control Ports
||
N/A
||
control:
sw_iface: nocscript
fpga_iface: ctrlport
interface_direction: slave
...
||
|-
| Clocking
||
N/A
||
clocks:
- name: rfnoc_chdr
freq: "[]"
- name: rfnoc_ctrl
freq: "[]"
||
|}

''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].''

===RFNoC API Changes===

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:

{| class="wikitable"
! RFNoC 3 || RFNoC 4 || RFNoC 4 Notes
|-
|
usrp = uhd::device3::make(...)
||
graph = uhd::rfnoc::rfnoc_graph::make()
||
No longer need to create a device3 object
|-
|
usrp->get_block_ctrl(...)
||
graph->get_block(...)
||
Rename
|-
|
N/A
||
graph->enumerate_static_connections()
||
Used to check static connections, usually for detecting hwen a DDC or DUC is statically connected to the radio and requires setting the sample
|-
|
usrp->get_tx_streamer(...)
||
graph->create_tx_streamer(...)
||
Rename
|-
|
usrp->get_rx_streamer(...)
||
graph->create_rx_streamer(...)
||
Rename
|-
|
N/A
||
graph->commit()
||
Commit graph and run initial checks
|-
|
sr_write(...)
||
regs().poke32(...)
||
Address increments by 4
|-
|
sr_read32(...)
||
regs().peek32(...)
||
Address increments by 4
|-
|
sr_read64(...)
||
regs().poke64(...)
||
Address increments by 8
|-
|
set_arg(...)
||
set_property(...)
||
Block args replaced with block properties concept
|-
|
get_arg(...)
||
get_property(...)
||
Block args replaced with block properties concept
|}

===Block Properties===

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.

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.

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:

====RFNoC 3 Noc Script XML snippet====
<registers>
<setreg>
<name>GAIN</name>
<address>128</address>
</setreg>
</registers>

<args>
<arg>
<name>gain</name>
<type>int</type>
<value>1</value>
<check>GE($gain, 0) AND LE($gain, 32767)</check>
<check_message>Gain must be in the range [0, 32767]</check_message>
<action>SR_WRITE("GAIN", $gain)</action>
</arg>
</args>

====RFNoC 4 Block Controller Class====

// <registers>
// <setreg>
// <name>GAIN</name>
// <address>128</address>
// </setreg>
// </registers>
// Note: In RFNoC 4, register addresses can start at address 0 instead of address 128 as in RFNoC 3.
const uint32_t gain_block_ctrl::REG_GAIN_ADDR = 128;
const uint32_t gain_block_ctrl::REG_GAIN_DEFAULT = 1;

class gain_block_ctrl_impl : public gain_block_ctrl
{
public:
RFNOC_BLOCK_CONSTRUCTOR(gain_block_ctrl)
{
_register_props();
}
private:
void _register_props()
{
register_property(&_user_reg, [this]() {
int user_reg = this->_user_reg.get();
// <check>GE($gain, 0) AND LE($gain, 32767)</check>
// <check_message>Gain must be in the range [0, 32767]</check_message>
if (user_reg < 0 || user_reg > 32767) {
throw uhd::value_error("Size value must be in [0,32767]");
}
// <action>SR_WRITE("GAIN", $gain)</action>
this->regs().poke32(REG_USER_ADDR, user_reg);
});
}

// <name>gain</name>
// <type>int</type>
// <value>1</value>
property_t<int> _user_reg{"gain", REG_USER_DEFAULT, {res_source_info::USER}};
}

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.

=FPGA Migration=

Migration reference files for this section from Gain RFNoC Block example:

{| class="wikitable"
! Description || RFNoC 3 Files || RFNoC 4 Files
|-
| Block Verilog Code || rfnoc/fpga-src/noc_block_gain.v || rfnoc/fpga/rfnoc_block_gain/rfnoc_block_gain.v
|-
| Block Noc Shell || N/A || rfnoc/fpga/rfnoc_block_gain/noc_shell_gain.v
|-
| Block Testbnech || rfnoc/testbench/noc_block_gain/noc_block_gain_tb.sv || rfnoc/fpga/rfnoc_block_gain/rfnoc_block_gain_tb.sv
|-
| Image Core || N/A || rfnoc/icores/gain_x310_rfnoc_image_core.yml
|}

''Note: Files are relative to the rfnoc-example directory in the respective rfnoc3 and rfnoc4 directories''

===Noc Shell Changes===

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.

====Generating a Custom Noc Shell====

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.

The argument “-c” is used to provide the YAML file location. “-d” provides the output destination directory.

''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!''

Example usage:
rfnoc_create_verilog.py -c ./rfnoc-example/rfnoc/blocks/gain.yml -d ./output/

====Changing Noc ID without using rfnoc_create_verilog====

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.

====Goodbye AXI Wrapper====

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.

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.

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

===Settings Bus replaced by CtrlPort===

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

{| class="wikitable"
! Settings Bus (RFNoC 3) || CtrlPort (RFNoC 4) || RFNoC 4 Notes
|-
| set_stb || ctrlport_reg_wr || Write strobe
|-
| 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)
|-
| set_data || ctrlport_req_data || Write data
|-
| N/A || ctrlport_req_rd || Read strobe equivalent of ctrlport_req_wr
|-
| rb_addr || N/A || CtrlPort uses ctrlport_req_addr for both '''read and write''' addresses
|-
| rb_data || ctrlport_resp_data || Read data, 32-bits instead of 64-bits
|-
| rb_stb || N/A || CtrlPort requires ack strobe for '''reads and writes'''
|}

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:

// Note: Register addresses increment by 4
localparam REG_USER_ADDR = 0; // Address for example user register
localparam REG_USER_DEFAULT = 0; // Default value for user register

reg [31:0] reg_user = REG_USER_DEFAULT;

always @(posedge ctrlport_clk) begin
if (ctrlport_rst) begin
reg_user = REG_USER_DEFAULT;
end else begin
// Default assignment
m_ctrlport_resp_ack <= 0;

// Read user register
if (m_ctrlport_req_rd) begin // Read request
case (m_ctrlport_req_addr)
REG_USER_ADDR: begin
m_ctrlport_resp_ack <= 1;
m_ctrlport_resp_data <= reg_user;
end
endcase
end

// Write user register
if (m_ctrlport_req_wr) begin // Write requst
case (m_ctrlport_req_addr)
REG_USER_ADDR: begin
m_ctrlport_resp_ack <= 1;
reg_user <= m_ctrlport_req_data[31:0];
end
endcase
end
end
end

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

===Testbench Infrastructure===

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.

{| class="wikitable"
! Operation || RFNoC 3 || RFNoC 4
|-
| Setup RFNoC
||
`RFNOC_SIM_INIT(...)
`RFNOC_ADD_BLOCK(...)
`RFNOC_CONNECT(...)
||
RfnocBlockCtrlBfm #(...) blk_ctrl = new(...);
blk_ctrl.connect_master_data_port(...)
blk_ctrl.connect_slave_data_port(...)
''Note: Instantiate one Block Controller BFM per RFNoC Block''
|-
| Setup Test Cases
||
`TEST_CASE_START(...)
`TEST_CASE_DONE(...)
||
test.start_test(...)
test.end_test()
|-
| Register Read
||
tb_streamer.read_reg(...)
||
blk_ctrl.reg_read(...)
|-
| Register Write
||
tb_streamer.write_reg(...)
||
blk_ctrl.reg_write(...)
|-
| Send Data / Samples
||
tb_streamer.send(...)
||
blk_ctrl.send_items(...)
|-
| Receive Data / Samples
||
tb_streamer.recv(...)
||
blk_ctrl.recv_items(...)
|}

===Building FPGA images using Image Core YAML Files===

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.

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

=GNU Radio Software Migration=

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.

Migration reference files for this section from Gain RFNoC Block example:

{| class="wikitable"
! Description || RFNoC 3 Files || RFNoC 4 Files
|-
| 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
|-
| GRC Block Description || grc/gain.xml || grc/gain.yml
|-
| Example GRC Flowgraph || examples/gain.grc || examples/gain.grc
|}

''Note: Files are relative to the rfnoc-example directory in the respective rfnoc3 and rfnoc4 directories''

===RX & TX Streamer Blocks===

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.

[[File:rx_tx_streamer.png|border]]

===Setting RFNoC Block Properties Directly in GNU Radio===

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.

{| class="wikitable"
! Property Type || Set Property || Get Property
|-
| Integer || set_int_property(...) || get_int_property(...)
|-
| Double || set_double_property(...) || get_double_property(...)
|-
| Bool || set_bool_property(...) || get_bool_property(...)
|-
| String || set_string_property(...) || get_string_property(...)
|-
|}

'''Example code for GNU Radio Companion YAML Block Description file'''
templates:
imports: |-
import example
make: |-
example.gain(
self.rfnoc_graph,
uhd.device_addr(${block_args}),
${device_select},
${instance_select})
self.${id}.set_int_property('gain', ${gain})
callbacks:
- set_int_property('gain', ${gain})

File:migration example.zip

2020-12-29T08:19:59Z

JonathonPendlum: Example designs for RFNoC 4 Migration Guide

Example designs for RFNoC 4 Migration Guide

RFNoC 4 Migration Guide

2020-12-29T08:06:04Z

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

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

=Prerequisites=

===Dependencies (Ubuntu 20.04)===
git cmake g++ libboost-all-dev libgmp-dev swig \
python3-numpy python3-mako python3-sphinx python3-lxml \
doxygen libfftw3-dev libsdl1.2-dev libgsl-dev libqwt-qt5-dev \
libqt5opengl5-dev python3-pyqt5 liblog4cpp5-dev libzmq3-dev \
python3-yaml python3-click python3-click-plugins python3-zmq \
python3-scipy python3-gi python3-gi-cairo gobject-introspection \
gir1.2-gtk-3.0 build-essential libusb-1.0-0-dev python3-docutils \
python3-setuptools python3-ruamel.yaml python-is-python3 \
libtinfo5 libncurses5

===Vivado 2019.1 Design Edition===

Please reference to Xilinx (xilinx.com) for installation instructions.

''Note: The dependencies step above included installing libtinfo5 libncurses5, which is a workaround for getting Vivado 2019.1 to run on Ubunbtu 20.04''

===UHD 4.0===
git clone --branch UHD-4.0 https://github.com/ettusresearch/uhd.git uhd
mkdir uhd/host/build; cd uhd/host/build
cmake ..
make
sudo make install

===GNU Radio 3.8===
'' Note: If your design does not use GNU Radio, then installing GNU Radio and gr-ettus is not required ''

git clone --branch maint-3.8 --recursive https://github.com/gnuradio/gnuradio.git gnuradio
mkdir gnuradio/build; cd gnuradio/build;
cmake ..
make
sudo make install

===gr-ettus===
git clone --branch maint-3.8-uhd4.0 https://github.com/ettusresearch/gr-ettus.git gr-ettus
mkdir gr-ettus/build; cd gr-ettus/build;
cmake -DENABLE_QT=True ..
make
sudo make install

=RFNoC Block Development Environment=

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.

===Migrating a GNU Radio Out-of-Tree Module===

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.

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.

====Creating a RFNoC Block with rfnocmodtool====

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.

rfnocmodtool newmod
Name of the new module: '''example'''

cd rfnoc-tutorial
rfnocmodtool add
Enter name of block/code (without module name prefix): '''gain'''
Enter valid argument list, including default arguments: ''(leave blank)''
Add Python QA code? [y/N] '''N'''
Add C++ QA code? [y/N] '''N'''
Block NoC ID (Hexadecimal): ''(Enter Noc ID of your block)''
Skip Block Controllers Generation? [UHD block ctrl files] [y/N] '''N'''
Skip Block interface files Generation? [GRC block ctrl files] [y/N] '''N'''

''Note: Noc IDs have been reduced from 64-bits in RFNoC 3 to 32-bits in RFNoC 4''

The following are the relevant files that need to be updated when migrating your RFNoC Block.

rfnoc-example/
grc/
example_gain.block.yml – RFNoC Block GNU Radio Companion YAML file
examples/
gain.grc – Example flowgraph using gain RFNoC Block
include/tutorial/
gain.h – GNU Radio block C++ header
gain_block_ctrl.hpp – RFNoC Block Controller C++ header
lib/
gain_impl.cc – GNU Radio block C++ source
gain_impl.h – GNU Radio block C++ header
gain_block_ctrl_impl.cpp – RFNoC Block Controller C++ source
rfnoc/blocks/
gain.yml – RFNoC Block Description YAML file
rfnoc/fpga/rfnoc_block_gain
noc_shell_gain.v – RFNoC Block Noc Shell Verilog Source
rfnoc_block_gain.v – RFNoC Block Verilog Source
rfnoc_block_gain_tb.v – RFNoC Block Testbench
rfnoc/icores
gain_x310_rfnoc_image_core.yml – Image Core YAML file with gain block

====Building OOT module====

cd rfnoc-tutorial
mkdir build; cd build
cmake -DUHD_FPGA_DIR=''(path to uhd/fpga directory)'' ..
make
sudo make install

====Running a testbench====
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:

cd rfnoc-tutorial/build
make rfnoc_block_gain_tb

====Building a FPGA image====
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:

cd rfnoc-tutorial/build
make gain_x310_rfnoc_image_core

===Migrating a Standalone UHD C++ Application===

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.

The following are the relevant files that need to be updated when migrating your RFNoC Block.

rfnoc-example/
apps/
init_gain_block.cpp – Example C++ application testing gain block
blocks/
gain.yml – RFNoC Block Description YAML file
fpga/rfnoc_block_gain
noc_shell_gain.v – RFNoC Block Noc Shell Verilog Source
rfnoc_block_gain.v – RFNoC Block Verilog Source
rfnoc_block_gain_tb.v – RFNoC Block Testbench
icores/
x310_rfnoc_image_core.yml – Example Image Core YAML file
include/rfnoc/example
gain_block_control.hpp – RFNoC Block Controller C++ header
lib/
gain_block_control.cpp – RFNoC Block Controller C++ source

====Building rfnoc-example====

cd rfnoc-example
mkdir build; cd build
cmake ..
make
sudo make install

====Running a testbench====
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:

cd rfnoc-example/build
make rfnoc_block_gain_tb

====Building a FPGA image====
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:

cd rfnoc-tutorial/build
make gain_x310_rfnoc_image_core

=Example RFNoC 3 to RFNoC 4 Block Migration=

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.

=UHD Software Migration=

Migration reference files for this section from Gain RFNoC Block example:

{| class="wikitable"
! Description || RFNoC 3 Files || RFNoC 4 Files
|-
| Block Description || rfnoc/blocks/gain.xml || lib/gain_block_ctrl_impl.cpp <br>include/example/gain_block_ctrl.hpp
|-
| Block Controller || rfnoc/blocks/gain.yml || lib/gain_block_ctrl_impl.cpp <br>include/example/gain_block_ctrl.hpp
|}

''Note: Files are relative to the rfnoc-example directory in the respective rfnoc3 and rfnoc4 directories''

===Noc Script XML Replaced by Block Description YAML===

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.

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:

{| class="wikitable"
! Item || Noc Script XML || Block Descript YAML || RFNoC 4 Notes
|-
| Block Name
||
<name>gain</name>
||
module_name: gain
||
|-
| Noc ID
||
<id>B160000000000000</id>
||
noc_id: 0xB16
||
Noc ID are limited to 32-bits
|-
| Registers
||
<registers>
<setreg>
<name>GAIN</name>
<address>128</address>
</setreg>
</registers>
||
N/A
||
Registers must be defined in the Block Controller
|-
| Arguments
||
<args>
<arg>
<name>gain</name>
<type>int</type>
...
</arg>
</args>
||
N/A
||
Args are implemented with properties in the Block Controller
|-
| Data Ports
||
<ports>
<sink>
<name>in</name>
</sink>
<source>
<name>out</name>
</source>
</ports>
||
data:
fpga_iface: axis_pyld_ctxt
clk_domain: rfnoc_chdr
inputs:
in:
...
outputs:
out:
...
||
|-
| Control Ports
||
N/A
||
control:
sw_iface: nocscript
fpga_iface: ctrlport
interface_direction: slave
...
||
|-
| Clocking
||
N/A
||
clocks:
- name: rfnoc_chdr
freq: "[]"
- name: rfnoc_ctrl
freq: "[]"
||
|}

''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].''

===RFNoC API Changes===

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:

{| class="wikitable"
! RFNoC 3 || RFNoC 4 || RFNoC 4 Notes
|-
|
usrp = uhd::device3::make(...)
||
graph = uhd::rfnoc::rfnoc_graph::make()
||
No longer need to create a device3 object
|-
|
usrp->get_block_ctrl(...)
||
graph->get_block(...)
||
Rename
|-
|
N/A
||
graph->enumerate_static_connections()
||
Used to check static connections, usually for detecting hwen a DDC or DUC is statically connected to the radio and requires setting the sample
|-
|
usrp->get_tx_streamer(...)
||
graph->create_tx_streamer(...)
||
Rename
|-
|
usrp->get_rx_streamer(...)
||
graph->create_rx_streamer(...)
||
Rename
|-
|
N/A
||
graph->commit()
||
Commit graph and run initial checks
|-
|
sr_write(...)
||
regs().poke32(...)
||
Address increments by 4
|-
|
sr_read32(...)
||
regs().peek32(...)
||
Address increments by 4
|-
|
sr_read64(...)
||
regs().poke64(...)
||
Address increments by 8
|-
|
set_arg(...)
||
set_property(...)
||
Block args replaced with block properties concept
|-
|
get_arg(...)
||
get_property(...)
||
Block args replaced with block properties concept
|}

===Block Properties===

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.

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.

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:

====RFNoC 3 Noc Script XML snippet====
<registers>
<setreg>
<name>GAIN</name>
<address>128</address>
</setreg>
</registers>

<args>
<arg>
<name>gain</name>
<type>int</type>
<value>1</value>
<check>GE($gain, 0) AND LE($gain, 32767)</check>
<check_message>Gain must be in the range [0, 32767]</check_message>
<action>SR_WRITE("GAIN", $gain)</action>
</arg>
</args>

====RFNoC 4 Block Controller Class====

// <registers>
// <setreg>
// <name>GAIN</name>
// <address>128</address>
// </setreg>
// </registers>
// Note: In RFNoC 4, register addresses can start at address 0 instead of address 128 as in RFNoC 3.
const uint32_t gain_block_ctrl::REG_GAIN_ADDR = 128;
const uint32_t gain_block_ctrl::REG_GAIN_DEFAULT = 1;

class gain_block_ctrl_impl : public gain_block_ctrl
{
public:
RFNOC_BLOCK_CONSTRUCTOR(gain_block_ctrl)
{
_register_props();
}
private:
void _register_props()
{
register_property(&_user_reg, [this]() {
int user_reg = this->_user_reg.get();
// <check>GE($gain, 0) AND LE($gain, 32767)</check>
// <check_message>Gain must be in the range [0, 32767]</check_message>
if (user_reg < 0 || user_reg > 32767) {
throw uhd::value_error("Size value must be in [0,32767]");
}
// <action>SR_WRITE("GAIN", $gain)</action>
this->regs().poke32(REG_USER_ADDR, user_reg);
});
}

// <name>gain</name>
// <type>int</type>
// <value>1</value>
property_t<int> _user_reg{"gain", REG_USER_DEFAULT, {res_source_info::USER}};
}

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.

=FPGA Migration=

Migration reference files for this section from Gain RFNoC Block example:

{| class="wikitable"
! Description || RFNoC 3 Files || RFNoC 4 Files
|-
| Block Verilog Code || rfnoc/fpga-src/noc_block_gain.v || rfnoc/fpga/rfnoc_block_gain/rfnoc_block_gain.v
|-
| Block Noc Shell || N/A || rfnoc/fpga/rfnoc_block_gain/noc_shell_gain.v
|-
| Block Testbnech || rfnoc/testbench/noc_block_gain/noc_block_gain_tb.sv || rfnoc/fpga/rfnoc_block_gain/rfnoc_block_gain_tb.sv
|-
| Image Core || N/A || rfnoc/icores/gain_x310_rfnoc_image_core.yml
|}

''Note: Files are relative to the rfnoc-example directory in the respective rfnoc3 and rfnoc4 directories''

===Noc Shell Changes===

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.

====Generating a Custom Noc Shell====

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.

The argument “-c” is used to provide the YAML file location. “-d” provides the output destination directory.

''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!''

Example usage:
rfnoc_create_verilog.py -c ./rfnoc-example/rfnoc/blocks/gain.yml -d ./output/

====Changing Noc ID without using rfnoc_create_verilog====

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.

====Goodbye AXI Wrapper====

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.

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.

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

===Settings Bus replaced by CtrlPort===

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

{| class="wikitable"
! Settings Bus (RFNoC 3) || CtrlPort (RFNoC 4) || RFNoC 4 Notes
|-
| set_stb || ctrlport_reg_wr || Write strobe
|-
| 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)
|-
| set_data || ctrlport_req_data || Write data
|-
| N/A || ctrlport_req_rd || Read strobe equivalent of ctrlport_req_wr
|-
| rb_addr || N/A || CtrlPort uses ctrlport_req_addr for both '''read and write''' addresses
|-
| rb_data || ctrlport_resp_data || Read data, 32-bits instead of 64-bits
|-
| rb_stb || N/A || CtrlPort requires ack strobe for '''reads and writes'''
|}

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:

// Note: Register addresses increment by 4
localparam REG_USER_ADDR = 0; // Address for example user register
localparam REG_USER_DEFAULT = 0; // Default value for user register

reg [31:0] reg_user = REG_USER_DEFAULT;

always @(posedge ctrlport_clk) begin
if (ctrlport_rst) begin
reg_user = REG_USER_DEFAULT;
end else begin
// Default assignment
m_ctrlport_resp_ack <= 0;

// Read user register
if (m_ctrlport_req_rd) begin // Read request
case (m_ctrlport_req_addr)
REG_USER_ADDR: begin
m_ctrlport_resp_ack <= 1;
m_ctrlport_resp_data <= reg_user;
end
endcase
end

// Write user register
if (m_ctrlport_req_wr) begin // Write requst
case (m_ctrlport_req_addr)
REG_USER_ADDR: begin
m_ctrlport_resp_ack <= 1;
reg_user <= m_ctrlport_req_data[31:0];
end
endcase
end
end
end

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

===Testbench Infrastructure===

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.

{| class="wikitable"
! Operation || RFNoC 3 || RFNoC 4
|-
| Setup RFNoC
||
`RFNOC_SIM_INIT(...)
`RFNOC_ADD_BLOCK(...)
`RFNOC_CONNECT(...)
||
RfnocBlockCtrlBfm #(...) blk_ctrl = new(...);
blk_ctrl.connect_master_data_port(...)
blk_ctrl.connect_slave_data_port(...)
''Note: Instantiate one Block Controller BFM per RFNoC Block''
|-
| Setup Test Cases
||
`TEST_CASE_START(...)
`TEST_CASE_DONE(...)
||
test.start_test(...)
test.end_test()
|-
| Register Read
||
tb_streamer.read_reg(...)
||
blk_ctrl.reg_read(...)
|-
| Register Write
||
tb_streamer.write_reg(...)
||
blk_ctrl.reg_write(...)
|-
| Send Data / Samples
||
tb_streamer.send(...)
||
blk_ctrl.send_items(...)
|-
| Receive Data / Samples
||
tb_streamer.recv(...)
||
blk_ctrl.recv_items(...)
|}

===Building FPGA images using Image Core YAML Files===

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.

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

=GNU Radio Software Migration=

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.

Migration reference files for this section from Gain RFNoC Block example:

{| class="wikitable"
! Description || RFNoC 3 Files || RFNoC 4 Files
|-
| 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
|-
| GRC Block Description || grc/gain.xml || grc/gain.yml
|-
| Example GRC Flowgraph || examples/gain.grc || examples/gain.grc
|}

''Note: Files are relative to the rfnoc-example directory in the respective rfnoc3 and rfnoc4 directories''

===RX & TX Streamer Blocks===

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.

[[File:rx_tx_streamer.png|border]]

===Setting RFNoC Block Properties Directly in GNU Radio===

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.

{| class="wikitable"
! Property Type || Set Property || Get Property
|-
| Integer || set_int_property(...) || get_int_property(...)
|-
| Double || set_double_property(...) || get_double_property(...)
|-
| Bool || set_bool_property(...) || get_bool_property(...)
|-
| String || set_string_property(...) || get_string_property(...)
|-
|}

'''Example code for GNU Radio Companion YAML Block Description file'''
templates:
imports: |-
import example
make: |-
example.gain(
self.rfnoc_graph,
uhd.device_addr(${block_args}),
${device_select},
${instance_select})
self.${id}.set_int_property('gain', ${gain})
callbacks:
- set_int_property('gain', ${gain})

File:rx tx streamer.png

2020-12-29T07:59:55Z

JonathonPendlum: Diagram for RFNoC 4 Migration Guide

Diagram for RFNoC 4 Migration Guide

File:rfnoc4 workshop slides 2020 part 2.pdf

2020-12-16T05:17:16Z

JonathonPendlum: RFNoC4 slides presented at GRCon 2020. Part 2 of 2.

RFNoC4 slides presented at GRCon 2020. Part 2 of 2.

File:rfnoc4 workshop slides 2020 part 1.pdf

2020-12-16T05:13:05Z

JonathonPendlum: RFNoC4 slides presented at GRCon 2020. Part 1 of 2.

RFNoC4 slides presented at GRCon 2020. Part 1 of 2.

File:rfnoc3 workshop slides 202008 part 2.pdf

2020-12-16T05:05:21Z

JonathonPendlum: RFNoC3 slides presented at NEWSDR 2020. This is the final revision of these slides as RFNoC4 has been released. Part 2 of 2.

RFNoC3 slides presented at NEWSDR 2020. This is the final revision of these slides as RFNoC4 has been released. Part 2 of 2.

File:rfnoc3 workshop slides 202008 part 1.pdf

2020-12-16T05:03:37Z

JonathonPendlum: RFNoC3 slides presented at NEWSDR 2020. This is the final revision of these slides as RFNoC4 has been released. Part 1 of 2.

RFNoC3 slides presented at NEWSDR 2020. This is the final revision of these slides as RFNoC4 has been released. Part 1 of 2.