[Ground-station] RFNoC update and test proposal

[Michelle Thompson]

RFNoC Update

Here's some notes from a phone call last night with Neel Pandeya about our
RFNoC strategy. Thank you Neel!

RFNoC is RF Network on a Chip. It allows blocks in GNU radio to be assigned
directly to the FPGA.

Here's an intro:
https://www.ettus.com/sdr-software/detail/rf-network-on-chip

What we're trying to do is take codebases written in high-level languages,
like C, and transform them into bitstreams using SDSoC, and then get those
functions working in RFNoC.

SDSoC is from Xilinx. It provides hardware acceleration to c functions,
making it possible to run those functions on FPGA fabric.

Here's a one-sheet about SDSoC.

https://www.xilinx.com/publications/prod_mktg/sdnet/sdsoc-development-environment-backgrounder.pdf

Neel thinks our strategy to then take those accelerated functions to RFNoC
will work provided we ensure the hardware accelerated functions use AXI
streams to communicate in and out, so that RFNoC is getting what it
expects.

RFNoC relies entirely (at this time) on AXI crossbars.

RFNoC will be *the* way to communicate with the FPGA in USRPs going
forward. RFNoC isn't going anywhere.

RFNoC is indeed tied to USRPs. There are hooks everywhere to take full
advantage of the USRP platform.

RFNoC is open source and there is no reason that "someone" couldn't port it
to another platform. It would be a lot of work, but things worth doing are
rarely easy.

UHD and RFNoC is licensed under GPLv3 (
https://www.ettus.com/sdr-software/detail/licenses). There are at least two
entities that have forked their own version of UHD and maintain their own
version of UHD.

RFNoC is powerful and awesome and all that. However, it takes up a lot of
resources. On the X310, RFNoC consumes about half the FPGA just getting
itself off the ground. This assumes you let it use the 6 modules (and
therefore 6 out of 16 ports) available.

If you just need receive, or just need transmit, then you can reduce that
usage. But half is a lot. Going forward, with larger FPGAs, this overhead
will decrease.

I think we need to prove out the workflow by picking one function. Taking
that function through SDSoC on Ultra96 (or snickerdoodle). And then getting
it to work in RFNoC.

I'd like to pick a function from Charles Brain's GPU code - something that
would be a good representation of the work.

Proving out the workflow with one of the core target functions would be a
big step forward. If it works then we package other functions.

With 10 ports available (assuming RFNoC uses 6 of 16), that means there's a
limit of 10 submodules in RFNoC. If there's more than 10 accelerated blobs,
then we have to package them up to use one port. I don't think that's too
difficult.

Charles, would you make a prototype GPU program to test out the workflow?

I'll get RFNoC working (again) here on the X310. I think we have a couple
more boards on the team that are capable of running RFNoC.

If it doesn't work, we have options. The SDSoC is still extremely useful
for proving things out for space and timing requirements, and general
education and advancement of the radio art and all that.

There is a method for getting GPU code to run in GNU Radio. My
understanding is that the GPU appears as a co-processor. It seems like this
would work and is one of the reasons I built up two GPU machines for the
lab and an external GPU system. Trying this in parallel is one of the goals
so if you want to give it a shot, then I have hardware ready to go, get in
touch.

Porting the code for RFNoC through Vivado is yet another (more labor
intensive) way, if the SDSoC doesn't work for us.

OK that's the lay of the land. We need some code to test, we need SDSoC to
produce something that "speaks" AXI streams, and we need to package it for
RFNoC and test. Tests need to be defined so that it's clear all phases pass.

I think we can do this. Who's  in?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openresearch.institute/pipermail/ground-station-openresearch.institute/attachments/20180627/05ecd9d4/attachment.html>