<div dir="ltr">From Neel, here's a table on FPGA resources for the USRPs.<br></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div dir="ltr">-Michelle W5NYV<br><br><div dir="ltr">"Potestatem obscuri lateris nescis."<br></div><div><br></div></div></div></div></div></div></div></div></div>
<br><div class="gmail_quote">On Wed, Jun 27, 2018 at 9:49 AM, Michelle Thompson <span dir="ltr"><<a href="mailto:mountain.michelle@gmail.com" target="_blank">mountain.michelle@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div class="m_-4329593881637908602gmail_signature"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>RFNoC Update</div><div><br></div><div>Here's some notes from a phone call last night with Neel Pandeya about our RFNoC strategy. Thank you Neel!<br><br>RFNoC is RF Network on a Chip. It allows blocks in GNU radio to be assigned directly to the FPGA. <br><br>Here's an intro: <br><a href="https://www.ettus.com/sdr-software/detail/rf-network-on-chip" target="_blank">https://www.ettus.com/sdr-<wbr>software/detail/rf-network-on-<wbr>chip</a><br></div><div><br></div><div>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. </div><div><br></div><div>SDSoC is from Xilinx. It provides hardware acceleration to c functions, making it possible to run those functions on FPGA fabric. <br><br>Here's a one-sheet about SDSoC.<br><br><a href="https://www.xilinx.com/publications/prod_mktg/sdnet/sdsoc-development-environment-backgrounder.pdf" target="_blank">https://www.xilinx.com/<wbr>publications/prod_mktg/sdnet/<wbr>sdsoc-development-environment-<wbr>backgrounder.pdf</a></div><div><br></div><div>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. <br></div><div><br></div><div>RFNoC relies entirely (at this time) on AXI crossbars. </div><div><br></div><div>RFNoC will be *the* way to communicate with the FPGA in USRPs going forward. RFNoC isn't going anywhere. </div><div><br></div><div>RFNoC is indeed tied to USRPs. There are hooks everywhere to take full advantage of the USRP platform. </div><div><br></div><div>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.</div><div><br></div><div>UHD and RFNoC is licensed under GPLv3 (<a href="https://www.ettus.com/sdr-software/detail/licenses" target="_blank">https://www.ettus.com/sdr-<wbr>software/detail/licenses</a>). There are at least two entities that have forked their own version of UHD and maintain their own version of UHD. </div><div><br></div><div>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. </div><div><br></div><div>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. </div><div><br></div><div>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. </div><div><br></div><div>I'd like to pick a function from Charles Brain's GPU code - something that would be a good representation of the work. </div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Charles, would you make a prototype GPU program to test out the workflow? </div><div><br></div><div>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. </div><div><br></div><div>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. <br><br><span style="font-size:small;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">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. <br></span><br>Porting the code for RFNoC through Vivado is yet another (more labor intensive) way, if the SDSoC doesn't work for us. </div><div><br></div><div>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.</div><div><br></div><div>I think we can do this. Who's  in?</div></div></div></div></div></div></div>
</div>
</blockquote></div><br></div>