Porting new hardware to GNURadio

GNU Radio
1

Hi.

Sorry for what might appear as a commercial at first - but I do have
some real
questions at the end - I’ll try to the description short.

We have developed a new RF learning platform [1] on a standard FMC card
[2]
(meets the electrical requirements, not the mechanical - it’s too long)

which can connect to nearly any recent Xilinx development system, that
we
started showing at X-Fest[3] yesterday.

The advantage of this, vs some existing platforms is bandwidth. The DAC
is a
16-Bit, 1200 MSPS (limited on this platform to 1GSPS, due to the clock
chip
we used), and the ADC is 14-Bit, 250 MSPS. The RF side includes a 400
MHz to
6 GHz Quadrature Modulator/Demodulator, separate Tx and Rx LO
Synthesisers
(35MHz to 4400MHz), and fixed gain on the Tx side, and a Variable Gain
on the
Rx Side. It’s clocking can handle multiple boards attached to the same
FPGA
(for MIMO), and can sync to a 1 pps (from GPS, or IEEE 1588) to sync
many,
many, many boards together.

The demo we are showing at X-Fest is the FMComms board, attached to a
Xilinx
ML605 FPGA, which runs Linux on Microblaze - playing a tone (Xilinx DDS)
out
the DAC, modulating that up to 2.4 GHz, sending it out the antenna,
receiving
it on the same board, demodulating it (at 2.4GHz), passing it through
the
VGA, to the ADC, were we capture the samples (into DDR), passing the
data to
GNU plot to create a png, and then passing the png to a web server, so
it can
be displayed on an external client across the network.

We have ported this to the Series 7 platforms - KC705, and others, and
are in
process finishing the port to Zynq[4] - for the standard Xilinx ZC702
platform [5] and the newly announced Zed[6]. This (I think) is where
things
get a little interesting. Microblaze running Linux is a little pokey -
Zynq
on the otherhand - is a dual ARM Cortex A9, running at 800MHz each, plus
FPGA
fabric - which allows some serious horsepower. This is a kit
(Zynq+FMComms)
that Avnet plans on selling [7].

Which brings me to the question:

We already have Linux IIO drivers[8] for all the parts on the board
(including
the ADCs[9] and DACs[10]), and are just trying to determine how (if at
all)
this fits within the GNU Radio framework.

When I looked at things (which wasn’t very long) - I didn’t see much in
terms
of native / real time connections to a platform which was running Linux
(PCIe, other other bus). Did I miss something?

Thanks in advance

-Robin

Just to be fair - others have done the same type of FMC Card [11] - the
advantage we have is gobs of channel bandwidth - enough to sample all of
bluetooth without doing any hopping at all.

[1] AD-FMCOMMS1-EBZ HDL Reference Design [Analog Devices Wiki]
[2] http://www.vita.com/fmc.html
[3] https://www.weboom.com/avnet2012/
[4]
Zynq 7000 SoC
[5] Boards
[6] http://www.zedboard.org/
[7]
http://www.em.avnet.com/en-us/design/drc/Pages/Analog-Devices-Zynq-Software-Defined-Radio-Kit.aspx
[8] Linux Industrial I/O Subsystem [Analog Devices Wiki]
[9]
https://github.com/mhennerich/linux/blob/fa8fc592243c82c0ddaa43f51be10e2123e1fa9b/drivers/staging/iio/adc/cf_ad9467_core.c
[10]
https://github.com/mhennerich/linux/blob/fa8fc592243c82c0ddaa43f51be10e2123e1fa9b/drivers/staging/iio/frequency/ad9122.c
[11] http://www.4dsp.com/FMC30RF.php

2

On Wed, Apr 25, 2012 at 05:37:16PM -0400, Getz, Robin wrote:

Which brings me to the question:

We already have Linux IIO drivers[8] for all the parts on the board (including
the ADCs[9] and DACs[10]), and are just trying to determine how (if at all)
this fits within the GNU Radio framework.

Hi Robin,

if you have the drivers, it should be a cakewalk to add sink/source
blocks.

When I looked at things (which wasn’t very long) - I didn’t see much in terms
of native / real time connections to a platform which was running Linux
(PCIe, other other bus). Did I miss something?

What exactly do you mean? The standard GNU Radio source comes with (real
time capable) drivers for all the Ettus stuff (via UHD), Funcube Dongle,
soundcards and more (see also
http://gnuradio.org/redmine/projects/gnuradio/wiki/Hardware), plus
there’s
3rd-party stuff like Balint’s drivers for RTL2832 TV tuners available on
the
webs. These things connect to the PC via USB or GigE.

I’m not sure if that’s what you were looking for, though.

MB

–
Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)

Dipl.-Ing. Martin B.
Research Associate

Kaiserstraße 12
Building 05.01
76131 Karlsruhe

Phone: +49 721 608-43790
Fax: +49 721 608-46071
www.cel.kit.edu

KIT – University of the State of Baden-Württemberg and
National Laboratory of the Helmholtz Association

3

On Thu 26 Apr 2012 03:19, Martin B. pondered:

blocks.
Are there pointers for doing that?
Looks like:
http://gnuradio.org/redmine/projects/gnuradio/wiki/BlocksCodingGuide
?
Is there a “golden” reference to look at? (I assume
gr-howto-write-a-block-3.6.0.tar.gz
should have everything we need?)

When I looked at things (which wasn’t very long) - I didn’t see much in
terms of native / real time connections to a platform which was running
Linux (PCIe, other other bus). Did I miss something?

What exactly do you mean? The standard GNU Radio source comes with (real
time capable) drivers for all the Ettus stuff (via UHD), Funcube Dongle,
soundcards and more (see also
http://gnuradio.org/redmine/projects/gnuradio/wiki/Hardware),

Yeah, that’s what I was missing. If it supports Comedi - it should
support IIO
without many issues.

SLOC Directory SLOC-by-Language (Sorted)
387 gr-comedi cpp=376,python=11

If that’s all that’s necessary - it shouldn’t take much time at all…

plus there’s
3rd-party stuff like Balint’s drivers for RTL2832 TV tuners available on
the webs. These things connect to the PC via USB or GigE.

I’m not sure if that’s what you were looking for, though.

Close - although it appears we need to extend our FSF copyright
assignments
before we get too busy.

Thanks
-Robin

4

On Thu 26 Apr 2012 10:58, Johnathan C. pondered:

On Thu, Apr 26, 2012 at 07:38, Getz, Robin [email protected] wrote:

Is there a “golden” reference to look at? (I assume
gr-howto-write-a-block-3.6.0.tar.gz
should have everything we need?)

This will give you the “canonical” format for writing your own
out-of-tree installable GNU Radio blocks.

And what is preferred? I always think in-tree is better - but that’s
just me.

A hardware source block would have no input ports, one or more output
ports for whatever streams your device generates, and a work function
that wraps calls to your existing sample-based I/O library for your
device. The main purpose of the work function would be to retrieve
samples from the device and put them into the block output buffer, and
some housekeeping to tell the GNU Radio runtime what you’ve done.

What is the widest band device (MSPS) that GNURadio can keep up with in
real
time? With this card - we are limited in memory bandwidth (vs a
desktop), and
Cortex A9 isn’t bad - but it’s no Intel CPU in terms of floating point
performance…

Who actually manages the location of the buffer? If GNURadio mmaps the
location (rather than malloc), it will save a memcpy in the work
function.

What’s the format that GNURadio wants (16-bit fixed? float? other?) We
can
make the format converter in the HDL, to decrease the load on the
processor.

You’d also need write any needed setter/getter functions to perform
configuration of your source block either at initialization or during
runtime.

There are lots of potential settings (Tx/Rx modulator frequencies,
ADC/DAC
sample rates, sync, MIMO config, etc) - I’m assuming some of those
configuration knobs are exposed to the python interface in a standard
manner
across hardware?

…although it appears we need to extend our FSF copyright assignments
before we get too busy.

This isn’t needed to develop your own distributed GNU Radio blocks;
you only need comply with the GPLv3 license terms of GNU Radio.

Right - but I would think that it would be better to have things in
tree?

With all the FSF packages that we have contributed to in the past (gcc,
binutils, gdb, etc) without a FSF copyright assignment - the package
maintainer would not accept patches. I believe that is what is indicated
here:
http://gnuradio.org/redmine/projects/gnuradio/wiki/Development#Whats-this-Copyright-Assignment

Thanks
-Robin

5

On Thu, Apr 26, 2012 at 08:31, Getz, Robin [email protected]
wrote:

On Thu 26 Apr 2012 10:58, Johnathan C. pondered:

This will give you the “canonical” format for writing your own
out-of-tree installable GNU Radio blocks.

And what is preferred? I always think in-tree is better - but that’s just me.

If you are not planning to contribute your code to the GNU Radio
project, the out-of-tree build system allows you to maintain your
source code independently of GNU Radio, in its own version control
system, and allows you to distribute said code in an optimal fashion.
In addition, the build process is much faster. You can even use OS
supplied binary development packages in lieu of compiling GNU Radio.

If you are planning to offer your code for inclusion into GNU Radio
proper, it’s still much easier to get it written and debugged on its
own, then convert it to the in-tree, top-level component form.

One thing to consider, though is that in order for the code
maintainers (Tom and I) to be able to manage inclusion of new hardware
support into the project, we need to be able to test locally in our
labs. This involves providing the hardware either on a long-term loan
or donating it to the project.

performance…
There are way too many variables here to answer your question
accurately. GNU Radio routinely handles 25 Msps I/Q plus DSP with
mid-range desktop x86 systems. The greatest variable is not so much
the sample rate but what you’re doing with it. Others on the list may
chime in with their own unique applications and the performance they
are achieving.

Who actually manages the location of the buffer? If GNURadio mmaps the
location (rather than malloc), it will save a memcpy in the work function.

Yes, the work function is provided a mmaped buffer which you can
directly DMA into if your hardware supports that.

What’s the format that GNURadio wants (16-bit fixed? float? other?) We can
make the format converter in the HDL, to decrease the load on the processor.

Inside GNU Radio, the majority of the blocks are designed to operate
on single-precision, floating-point samples. Usually, the
over-the-wire format is optimized the bandwidth of the transport in
use, which means fixed-point samples and conversion on the host. You
can instead transport floats to gain CPU performance at the expense of
transport bandwidth/sample rate.

There are lots of potential settings (Tx/Rx modulator frequencies, ADC/DAC
sample rates, sync, MIMO config, etc) - I’m assuming some of those
configuration knobs are exposed to the python interface in a standard manner
across hardware?

No, we don’t have a device abstraction layer at this level. It’s a
nice idea and many have suggested it, but it’s been an open issue for
SDR in general for a long time. So you are free to implement whatever
function calls are needed to twiddle the hardware the right way, and
there is a standard way (via SWIG) that these functions get exported
to the Python API.

This isn’t needed to develop your own distributed GNU Radio blocks;
you only need comply with the GPLv3 license terms of GNU Radio.

Right - but I would think that it would be better to have things in tree?

For the reasons above, we have to think about how generally available
the hardware is, whether we ourselves can test with that hardware,
etc. But in-tree is definitely better for your users, as they get the
drivers “for free” when they install GNU Radio.

Johnathan

6

On Thu, Apr 26, 2012 at 11:31:40AM -0400, Getz, Robin wrote:

On Thu 26 Apr 2012 10:58, Johnathan C. pondered:

On Thu, Apr 26, 2012 at 07:38, Getz, Robin [email protected] wrote:

Is there a “golden” reference to look at? (I assume
gr-howto-write-a-block-3.6.0.tar.gz
should have everything we need?)

This will give you the “canonical” format for writing your own
out-of-tree installable GNU Radio blocks.

And what is preferred? I always think in-tree is better - but that’s just me.

Just adding to what Johnathan said:

out-of-tree is easier to start with. You can use gr_modtool[1] to create
all the skeleton code, chuck in your driver hooks and be running within
the hour.

Just do something like (change this to whatever you need)

$ gr_modtool.py create fmccomms
$ cd gr-fmccomms/
$ gr_modtool.py add -t sink sink_c
$ gr_modtool.py add -t source source_c

Then, fill in the blanks (i.e. edit lib/fmccomms_sink_c.cc and so on).

MB

[1] https://cgran.org/wiki/devtools

–
Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)

Dipl.-Ing. Martin B.
Research Associate

Kaiserstraße 12
Building 05.01
76131 Karlsruhe

Phone: +49 721 608-43790
Fax: +49 721 608-46071
www.cel.kit.edu

KIT – University of the State of Baden-Württemberg and
National Laboratory of the Helmholtz Association

7

Hi Robin,

Did you finish porting GnuRadio to the Xilinx Zedboard?
If so, would you please share the information with me?

Thanks very much!

Andy

8

On Thu, Apr 26, 2012 at 07:38, Getz, Robin [email protected]
wrote:

Is there a “golden” reference to look at? (I assume
gr-howto-write-a-block-3.6.0.tar.gz
should have everything we need?)

This will give you the “canonical” format for writing your own
out-of-tree installable GNU Radio blocks.

A hardware source block would have no input ports, one or more output
ports for whatever streams your device generates, and a work function
that wraps calls to your existing sample-based I/O library for your
device. The main purpose of the work function would be to retrieve
samples from the device and put them into the block output buffer, and
some housekeeping to tell the GNU Radio runtime what you’ve done.

You’d also need write any needed setter/getter functions to perform
configuration of your source block either at initialization or during
runtime.

…although it appears we need to extend our FSF copyright assignments
before we get too busy.

This isn’t needed to develop your own distributed GNU Radio blocks;
you only need comply with the GPLv3 license terms of GNU Radio.

Johnathan

9

Andy,
If you’re only interested in GnuRadio on the Zedboard, one method
would be to build it using OpenEmbedded. There’s a little bit of a
learning curve, but Phil Balister has done work on this:

I can only confirm that it works on the zc702 dev board, but there is
apparently a fork of his repo to add support that is specific to the
Zedboard at:

https://github.com/milosoftware/meta-zynq

Doug

On Sun, Mar 17, 2013 at 12:49 PM, Andy F. [email protected]
wrote:

Discuss-gnuradio mailing list
[email protected]
Discuss-gnuradio Info Page

–
Doug G.
[email protected]