RFNoC (UHD 3.0)

From Ettus Knowledge Base
Revision as of 00:26, 29 January 2017 by JoseLoera (Talk | contribs) (added FAQ section and added FAQ under GR)

Jump to: navigation, search

Overview

RFNoC is a network-distributed heterogeneous processing tool with a focus on enabling FPGA processing in USRP devices. It allows you to move data on and off of an FPGA in a transparent way, thus enabling seamless use of both host-based and FPGA-based processing in an application. The result is a much simpler way to leverage FPGA processing capabilities and IP in your application which can scale across multiple FPGAs and devices across a network.

Signal processing algorithms are contained modules known as "Computation Engines" or "RFNoC Blocks", and an interface wrapper is provided to encapsulate existing or external IP to use with RFNoC. This allows you to import Xilinx™ CoreGen™ IP blocks, for example, and use them immediately in your RFNoC application. The internals of a RFNoC block are wholly independent from any other block, and can be designed with any tool that supports AXI stream interfaces, including VHDL, Verilog, and Xilinx™ Vivado™ HLS.

We are quickly building out the library of ready-to-use RFNoC blocks and already have many available, including the blocks necessary for an OFDM stack (e.g., detection, synchronization, equalizer, packet demodulator).

RFNoC is integrated with the UHD™ software, and all USRP devices from the third-generation on (X300 Series, E300 Series) are supported by RFNoC out-of-the-box. Like UHD, RFNoC is also Free and Open Source Software, and the full source code can be found in our public code repositories.

rfnoc.png

Framework and Data Flow Example

Below is a figure of the RFNoC stack.

rfnoc stack.png

The example below shows basic data flow of an RFNoC application. While this shows one possible data flow, there are many possible combinations from Host block to FPGA block, FPGA block to Host block, Host to Host, FPGA to FPGA, etc.

gr rfnoc ex1.png

Supported Devices

  • E310/E312
  • X300/X310

Sample of Available Blocks

  • FIFO
  • FFT
  • FIR
  • fosphor (real-time spectrum analyzer)
  • Decimator (Keep 1 in N)
  • Log Power Calculator
  • Radio Interface
  • Vector IIR (moving average)
  • Window multiplier (for FFT)
  • OFDM: Burst detection + synchronization, equalizer, packet demodulator
  • and more...

Blocks Included with Default FPGA Images

The following images have the corresponding RFNoC blocks (Computation Engines):

Image Name Included Blocks
usrp_x300_fpga_HG.bit

usrp_x300_fpga_XG.bit

usrp_x310_fpga_HG.bit

usrp_x310_fpga_XG.bit

2x DDC, 2x DUC
usrp_x300_fpga_RFNOC_HG.bit

usrp_x300_fpga_RFNOC_XG.bit

DUC, DDC (one channel), fosphor, window, fft, 2x AXI FIFOs
usrp_x310_fpga_RFNOC_HG.bit

usrp_x310_fpga_RFNOC_XG.bit

DUC, DDC (one channel), fosphor, window, fft, 2x AXI FIFOs, Keep One in N, FIR, Siggen
usrp_e310_fpga.bit

usrp_e310_fpga_sg3.bit

1x DDC, 1x DUC
usrp_e310_fpga_RFNOC.bit (sg1 version)

usrp_e310_fpga_RFNOC_sg3.bit

fosphor, window, fft, 2x AXI FIFOs, FIR

RFNoC FAQs

FPGA

Coming soon...

UHD

Coming soon...

GNU Radio

When do I use an RFNoC FIFO in my flowgraph and which kind if any?

An RFNoC FIFO is needed in your flowgraph in the following 2 conditions:

First, if you are running a GNU Radio flowgraph that is structured as follows:

Host block -> RFNoC block -> Host block

In this case, you need to do either:

Host block -> RFNoC FIFO -> RFNoC Block -> Host block

-OR-

Host block -> RFNoC Block -> RFNoC FIFO -> Host block

The order doesn't matter. This structure also benefits from having the GNU Radio Throttle block in the sequence.The reason behind the need to add the FIFO is because of performance inside of GNU Radio, so that the RX/TX work functions in the GNU Radio RFNoC block implementations run in separate threads.

Use RFNoC: FIFO (AXI_FIFO_LOOPBACK) in this case. See the following figure as an example.

fifo v01.png

Second, in the case where you are transmitting out to the antenna on the X3xx series devices, i.e.

Host -> DmaFIFO -> Radio

-OR-

Host -> DmaFIFO -> DUC -> Radio

Ethernet introduces a latency in flow control from the X3x0 back to the host. The latency will cause underruns unless a large buffer, i.e. DMA_FIFO, is added to the flowgraph.

Use RFNoC: DmaFIFO (AXI_DMA_FIFO) in this case. See the following figures as examples.

dma fifo v01.png

-OR-

dma fifo v02.png


RFNoC Resources