# GNURadio on Zynq: radiomodem and fast ADC sources, processing on the PL

**URL:** <https://www.ruby-forum.com/t/gnuradio-on-zynq-radiomodem-and-fast-adc-sources-processing-on-the-pl/230986>\
**Category:** GNU Radio\
**Created:** [July 16, 2014, 9:55am UTC](https://www.ruby-forum.com/t/gnuradio-on-zynq-radiomodem-and-fast-adc-sources-processing-on-the-pl/230986 "2014-07-16T09:55:48Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![addis\_a](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/c4cdca/32.png) [@addis\_a](https://www.ruby-forum.com/u/addis_a)\
**Post date:** [July 16, 2014, 9:55am UTC](https://www.ruby-forum.com/t/gnuradio-on-zynq-radiomodem-and-fast-adc-sources-processing-on-the-pl/230986/1 "2014-07-16T09:55:48Z")

</div>

I wish to inform the GNURadio community on some of the latest results on  
the use of the Xilinx Zynq platform  
for real time radiofrequency signal processing aimed at making the best  
use of the PS/PL architecture.  
Let me emphasize that although I am writing this email, all the  
technical work has been achieved by Guillaume Bres-Saix,  
in Cc of this email, who has been working full time on this topic since  
the beginning of the year, with the help  
of Gwenhael Goavec-Merou (also in Cc) who attended FOSDEM this year with  
me.

As discussed during the FOSDEM meeting in Brussels last february, we are  
interested in interfacing custom  
hardware for radiofrequency signal processing, in which the Zynq  
platform seems most appropriate. The two  
targeted hardware interfaces are an RF frontend (Semtech SX1255,  
operating in the 400-500 MHz range, providing  
separate frequency sources for the output and input signals), and fast  
A/D converters (mostly for RADAR  
applications). In this context, I believe that sending the datastream to  
the CPU before using the FPGA as  
a coprocessor is inefficient, and I consider and architecture made of  
two separate processing blocks, one  
including the data source and fast pre-processing steps using basic  
functions such as decimation, FIR or  
auto/cross-correlation to be implemented in the PL, followed by more  
complex processing steps best handled by the  
CPU (PS), in our case WFM demodulation and graphical display (through  
the exported X client). In such an  
architeture, only one data transfer occurs between PL and PS, namely the  
pre-processed data leave the  
FPGA memory when fetched by the linux kernel before being transfered to  
userspace when the GNURadio source  
scheduler requests data. At the moment this data transfer is performed  
in polling mode, although DMA  
transfer has been demonstrated in another context.

Guillaume has documented these applications: I believe the most  
impressive result is shown in the video at  
[http://guillaumebres.wix.com/eportfolio#!zedboard1/c171q](http://guillaumebres.wix.com/eportfolio#!zedboard1/c171q) and  
[- YouTube](https://www.youtube.com/watch?v=P-XzTaRDNxg)  
In this example, the I/Q stream from the RF frontend is decimated,  
transfered to the GNURadio source and  
processed by displaying the Fourier transform of the recorded signal,  
demonstrating that the data  
transfer is sound and the data processing is consistent with  
expectations. The modulated signal source  
is a sine wave modulating a FM-modulated radiomodem, and the Fourier  
transform indeed exhibits the  
sidebands at a frequency offset from the carrier equal to the emitted  
sine wave frequency. The continuity  
of the datastream and no loss of data is demonstrated in the second half  
of the video in which an audio  
signal modulates the radiomodem, and the WFM demodulation block of  
GNURadio feeding the sound card output  
generates a proper _continuous_ signal, hence demonstrating that no  
sample has been lost in the transfer process.

The second demonstration of a radiofrequency source made of fast A/D  
converters is presented at  
[http://guillaumebres.wix.com/eportfolio#!zynqadc/c3pa](http://guillaumebres.wix.com/eportfolio#!zynqadc/c3pa)  
and its application to RADAR measurements is illustrated at  
[http://guillaumebres.wix.com/eportfolio#!zynqradar/coj3](http://guillaumebres.wix.com/eportfolio#!zynqradar/coj3)

I believe these are fascinating demonstrations of the flexibility of the  
Zynq based SDR platform with  
minimal money investment but huge technical and scientific opportunities  
with the close ties of the PS/PL  
architecture. Beyond these technical demonstrations, one issue we are  
now facing is the integration of  
the PL in the GNURadio(-companion) framework. I believe the solution is  
easier since I have decided to  
keep all the FPGA part in the initial (fast) processing steps and high  
level software processing once  
the datastream has been decimated. At the moment, one /dev/ entry is  
needed for each functionality  
in the FPGA so a GNURadio-companion block allows for the reconfiguration  
of the associated functionality.  
How the gnuradio processing stream is kept consistent with the bitstream  
configuring the FPGA remains  
an open question and at the moment the developer must provide this  
consistency.

All this work must still be properly documented and shared with the  
community with a properly accessible  
repository: if interested in getting preliminary access to these source  
codes while all the files  
are being organized, let me know by email and we will try to make a  
usable archive.

JM

–  
JM Friedt, FEMTO-ST Time & Frequency/SENSeOR, 32 av. observatoire, 25044  
Besancon, France
