[Ground-station] RFNoC update and test proposal

[Michelle Thompson]

>From Neel, here's a table on FPGA resources for the USRPs.

-Michelle W5NYV

"Potestatem obscuri lateris nescis."


On Wed, Jun 27, 2018 at 9:49 AM, Michelle Thompson <
mountain.michelle at gmail.com> wrote:

> 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/20180628/a9a106f4/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: usrp-fpga.png
Type: image/png
Size: 97440 bytes
Desc: not available
URL: <http://lists.openresearch.institute/pipermail/ground-station-openresearch.institute/attachments/20180628/a9a106f4/attachment.png>