[Discuss-gnuradio] GNURadio on Zynq: radiomodem and fast ADC sources, processing on the PL

[jmfriedt]

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 and 
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
and its application to RADAR measurements is illustrated at 
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