Porting GNU Radio Blocks to The Epiphany

In this post I’m going to give a quick introduction to GNU Radio, and how the GNU Radio blocks are scheduled by the Thread Per Block (TPB) Scheduler. I will then discuss the basics of GNU Radio blocks, the potential impact that porting the blocks to the Epiphany would have, and the shortcomings of a project that hoped to accomplish a similar port.

GNU Radio is a Software Defined Radio (SDR) framework. SDR allows a software developer to write Digital Signal Processing (DSP) code to run on a general purpose PC. A Universal Software Radio Peripheral (USRP) is connected to the PC via USB or Ethernet and handles the tuning, filtering and sampling (TX and RX). The samples are then processed by the PC. This gives the developer the power to implement virtually any radio system with the same peripheral. It also allows for rapid prototyping and dynamic reconfigurability (see cognitive radio).

GNU Radio applications are written as Flowgraphs. A Flowgraph is an acyclic, one-directional graph of DSP blocks that stream data from an input (the source), to an output (the sink). The source block does not have any inputs, as it serves as the data source of the Flowgraph, and the Sink Block does not have any outputs, as it serves as the output for the data in your Flowgraph. In the case of a simple radio application, you can consider the Source Block to represent your input device, usually a TV Tuner or USRP. The output device would then represent your audio output or file.

Every basic block in a GNU Radio Flowgraph is represented by a thread which executes on that that block’s behalf. This thread is scheduled by the Operating System’s Scheduler, but the GNU Radio Scheduler determines when the thread calls its ‘work’ function on the input data. The thread reads from an input buffer, does its calculations and writes the resulting values to an output buffer.

Data between adjacent blocks is shared with shared memory pointers to a common memory location, and the first block in the Flowgraph writes to the shared memory buffer before the second reads it. In the case of a synch block (or a block that has the same number of input items as output items), the number of items in the shared buffer is indicated by the noutput_items variable, which is passed to the work function. There are several good tutorials on writing blocks and applications in C++ and Python.

I have shown in a blog post that it is possible to run GNU Radio applications on the ARM processor on the Parallella, but with very low performance. This is expected given the relatively low computational power this processor has when compared to modern x86 processor. One way to get around this problem is to off-load some of the high throughput calculations on the Ephiphany accelerator. There are two ways to accomplish this: 1. Rewrite or alter the scheduler to offload some threads to the Epiphany; 2. Rewrite some of the GNU Radio blocks to transfer data to the Epiphany and execute the computation on the accelerator, before transferring the data back to the RAM. As far as I am aware, option 1 would be very complicated. Option 2 would require a lot of porting, but could be sustainable with large enough programmer effort.

When it comes to porting GNU Radio blocks to Parallella, there are several immediate challenges. The epiphany chip does not have direct access to the Parallella’s memory, and therefore would need to copy the shared data. This introduces high latency overhead, and would require rewriting blocks to account for this.

Of course the General Purpose CPU is not optimized for DSP, and at least one other group has tried to capitalize on this. A few students out of UC Berkley headed by William Plishker tried to extend GNU Radio onto GPUs. You can read their presentation at the following link:

http://gnuradio.org/redmine/attachments/download/257/06-plishker-grc-grgpu.pdf

Although they were able to see a speedup, at least in throughput, ultimately their code has vanished from the Internet, and it is not being used (that I’m aware of). There are several reasons for this, but two are the significant increase in latency, and a high cost of porting. We need to learn from this project and avoid the same errors.

If you have any related questions ask me via the forum. The GNU Radio mailing list is also a great resource.

For those looking to port GNU Radio to Parallella, I would recommend knowledge of the following technologies:

  • Python
  • C++
  • CMake/make

Tom Tracy II

Leave a Reply