Discussion and technical support related to USRP, UHD, RFNoC
View all threadsEttus Research is very excited to announce the release of RFNoC!
Modern FPGAs, like the Xilinx Kintex-7 and ZYNQ used in third generation
USRPs have incredible computational capability, but taking advantage of
that capability is difficult at best when using traditional FPGA design
flows.
RFNoC (which stands for RF Network on Chip) provides the capability to
create FPGA applications as easily as you create GNU Radio flowgraphs. This
includes the ability to seamlessly transfer data to & from an FPGA in your
application, dramatically improving the ease of FPGA off-loading.
Here is an example of an RFNoC flowgraph built using the GNU Radio
Companion. With four blocks, data is being generated on the host,
off-loaded to the FPGA for filtering, and then brought back to the host for
plotting:
[image: Inline image 1]
Signal processing algorithms are encapsulated in easy-to-use wrappers which
allow them to be dynamically connected and used as needed. Fixed routing
is eliminated. Mixing and matching host-based and FPGA-based processing is
transparent to the user, and that processing can scale across multiple
FPGAs and devices across a network. You can now make custom FPGA designs
without ever needing to write Verilog or VHDL!
RFNoC has been integrated into UHD for our third generation USRPs
(X300-series, E300-series, and future devices), enabling you to share FPGA
designs across devices easily. Additionally, we have integrated support
for RFNoC into GNU Radio and GRC, so you can now graphically design mixed
host- and FPGA-based flowgraphs.
Watch an RFNoC presentation and demo from GRCon14: (long, but HIGHLY
recommended as an intro)
https://www.youtube.com/watch?v=9oPxIFtwyb8
All documentation and links to the source code can be found here:
https://github.com/EttusResearch/uhd/wiki/RFNoC:-Getting-Started
A paper from ACM SIGCOMM with more background:
http://conferences.sigcomm.org/sigcomm/2013/papers/srif/p45.pdf
If you have any questions, please don't hesitate to ask. We plan to hold
most of the RFNoC-related discussion on the usrp-users mailing list.
Matt Ettus
President, Ettus Research
W dniu 04.12.2014 o 19:52, Matt Ettus via USRP-users pisze:
Ettus Research is very excited to announce the release of RFNoC!
Modern FPGAs, like the Xilinx Kintex-7 and ZYNQ used in third
generation USRPs have incredible computational capability, but taking
advantage of that capability is difficult at best when using
traditional FPGA design flows.
Hello Matt,
It's great news. We are even more excited to try out the new feature!
--
Best Regards,
Piotr
On 12/04/2014 10:52 AM, Matt Ettus via USRP-users wrote:
Ettus Research is very excited to announce the release of RFNoC!
[...]
All documentation and links to the source code can be found here:
https://github.com/EttusResearch/uhd/wiki/RFNoC:-Getting-Started
RFNoC is an exciting development, one we plan to take full advantage of
in our custom application services and training classes.
However, I want to add that at present, using the above capabilities
requires an Ettus Research-specific development branch of GNU Radio
(specifically, the GNU Radio Companion.)
The GNU Radio Project team is working closely with Ettus Research to
bring the needed GRC modifications into GNU Radio in a vendor-neutral
way. This would allow other interested parties to develop their own
blocks that provide specialized ports, and have them displayed and
configured through GRC.
--
Johnathan Corgan, Corgan Labs
SDR/DSP Training and Consulting Services
http://corganlabs.com
Matt,
Congratulations on the release of this - this is very exciting! I have a
few questions:
This looks targeted at the X3xx series for now; I understand the new
E310 SDR will have RFNoC support also - is there a timeline for this?
If I understand the wiki, the current RFNoC FPGA build has a few example
signal processing FPGA blocks (FIR, FFT, window, add/sub) and several
utility blocks (null source/sink, loopback) as well as ‘radio’ blocks. How
does the standard USRP FPGA functionality (DDC/DUC chains, timed commands,
etc) fit into this? Is all of that packaged in the ‘radio’ block or can,
for example, a radio block be programmatically connected to multiple DDC
chains that are independently controlled?
What is the FPGA resource utilization of the example X3xx images? Is
there an idea if the same functionality would fit on the E310 FPGA?
Looking forward to where this is going…
Jacob
On Thu, Dec 4, 2014 at 1:52 PM, Matt Ettus via USRP-users <
usrp-users@lists.ettus.com> wrote:
Ettus Research is very excited to announce the release of RFNoC!
Modern FPGAs, like the Xilinx Kintex-7 and ZYNQ used in third generation
USRPs have incredible computational capability, but taking advantage of
that capability is difficult at best when using traditional FPGA design
flows.
RFNoC (which stands for RF Network on Chip) provides the capability to
create FPGA applications as easily as you create GNU Radio flowgraphs. This
includes the ability to seamlessly transfer data to & from an FPGA in your
application, dramatically improving the ease of FPGA off-loading.
Here is an example of an RFNoC flowgraph built using the GNU Radio
Companion. With four blocks, data is being generated on the host,
off-loaded to the FPGA for filtering, and then brought back to the host for
plotting:
[image: Inline image 1]
Signal processing algorithms are encapsulated in easy-to-use wrappers
which allow them to be dynamically connected and used as needed. Fixed
routing is eliminated. Mixing and matching host-based and FPGA-based
processing is transparent to the user, and that processing can scale across
multiple FPGAs and devices across a network. You can now make custom FPGA
designs without ever needing to write Verilog or VHDL!
RFNoC has been integrated into UHD for our third generation USRPs
(X300-series, E300-series, and future devices), enabling you to share FPGA
designs across devices easily. Additionally, we have integrated support
for RFNoC into GNU Radio and GRC, so you can now graphically design mixed
host- and FPGA-based flowgraphs.
Watch an RFNoC presentation and demo from GRCon14: (long, but HIGHLY
recommended as an intro)
https://www.youtube.com/watch?v=9oPxIFtwyb8
All documentation and links to the source code can be found here:
https://github.com/EttusResearch/uhd/wiki/RFNoC:-Getting-Started
A paper from ACM SIGCOMM with more background:
http://conferences.sigcomm.org/sigcomm/2013/papers/srif/p45.pdf
If you have any questions, please don't hesitate to ask. We plan to hold
most of the RFNoC-related discussion on the usrp-users mailing list.
Matt Ettus
President, Ettus Research
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Jacob,
I hope you don't mind if I give you some of the answers for now:
On 12/08/2014 04:13 PM, Jacob Gilbert via USRP-users wrote:
Matt,
Congratulations on the release of this - this is very exciting! I have a
few questions:
Development is pretty far. It's already possible to do some RFNoC tasks,
we're still ironing out some kinks though.
Currently, all the radio stuff is part of the radio block. If you want
full bandwidth, you can simply set the decimation to 1 and process the
sample stream in the next block (which could have its own DDC stage, if
that's what you need).
On X300, it's pretty full. We currently distribute the same example
image for X300 and X310, so the latter has free space accordingly.
E310 FPGA space is much smaller, though. We can't fit all the blocks
from the X-Series' image in there. It'll be a while before we know for
sure how much people can get in there (it also depends on one's FPGA
skills, of course).
However, we are using the identical blocks on both devices (X and E), so
it's not like you have to re-write them for E310 or anything. It's just
a subset of what we're currently distributing for X-Series.
Cheers,
Martin
Martin,
Thank you for the information - this gives me a rough idea of what I was
looking for.
With regard to my question #2, has there been any thought to separating
radio and DDC chains logically in the FPGA to enable the use case
discussed? It seems like something that would be useful, particularly given
the newfound FPGA flexibility.
Jacob
On Mon, Dec 8, 2014 at 2:16 PM, Martin Braun via USRP-users <
usrp-users@lists.ettus.com> wrote:
Jacob,
I hope you don't mind if I give you some of the answers for now:
On 12/08/2014 04:13 PM, Jacob Gilbert via USRP-users wrote:
Matt,
Congratulations on the release of this - this is very exciting! I have a
few questions:
Development is pretty far. It's already possible to do some RFNoC tasks,
we're still ironing out some kinks though.
Currently, all the radio stuff is part of the radio block. If you want
full bandwidth, you can simply set the decimation to 1 and process the
sample stream in the next block (which could have its own DDC stage, if
that's what you need).
On X300, it's pretty full. We currently distribute the same example
image for X300 and X310, so the latter has free space accordingly.
E310 FPGA space is much smaller, though. We can't fit all the blocks
from the X-Series' image in there. It'll be a while before we know for
sure how much people can get in there (it also depends on one's FPGA
skills, of course).
However, we are using the identical blocks on both devices (X and E), so
it's not like you have to re-write them for E310 or anything. It's just
a subset of what we're currently distributing for X-Series.
Cheers,
Martin
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
We have thought about that. The reason we haven't done it so far is that
it is a big change to the expected behavior, and forces the use of RFNoC in
all apps. We are considering it along with other future changes to the
radio block, but in the mean time you can effectively get that same
behavior by making DDC RFNoC blocks, and using the main one with a
decimation/interpolation factor of 1.
Matt
On Tue, Dec 9, 2014 at 1:09 PM, Jacob Gilbert via USRP-users <
usrp-users@lists.ettus.com> wrote:
Martin,
Thank you for the information - this gives me a rough idea of what I was
looking for.
With regard to my question #2, has there been any thought to separating
radio and DDC chains logically in the FPGA to enable the use case
discussed? It seems like something that would be useful, particularly given
the newfound FPGA flexibility.
Jacob
On Mon, Dec 8, 2014 at 2:16 PM, Martin Braun via USRP-users <
usrp-users@lists.ettus.com> wrote:
Jacob,
I hope you don't mind if I give you some of the answers for now:
On 12/08/2014 04:13 PM, Jacob Gilbert via USRP-users wrote:
Matt,
Congratulations on the release of this - this is very exciting! I have a
few questions:
Development is pretty far. It's already possible to do some RFNoC tasks,
we're still ironing out some kinks though.
Currently, all the radio stuff is part of the radio block. If you want
full bandwidth, you can simply set the decimation to 1 and process the
sample stream in the next block (which could have its own DDC stage, if
that's what you need).
On X300, it's pretty full. We currently distribute the same example
image for X300 and X310, so the latter has free space accordingly.
E310 FPGA space is much smaller, though. We can't fit all the blocks
from the X-Series' image in there. It'll be a while before we know for
sure how much people can get in there (it also depends on one's FPGA
skills, of course).
However, we are using the identical blocks on both devices (X and E), so
it's not like you have to re-write them for E310 or anything. It's just
a subset of what we're currently distributing for X-Series.
Cheers,
Martin
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com