usrp-users@lists.ettus.com

Discussion and technical support related to USRP, UHD, RFNoC

View all threads

RFNoC -- Making FPGA design easy from GNU Radio

ME
Matt Ettus
Thu, Dec 4, 2014 6:52 PM

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

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
PK
Piotr Krysik
Thu, Dec 4, 2014 8:35 PM

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

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
JC
Johnathan Corgan
Thu, Dec 4, 2014 9:42 PM

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

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
JG
Jacob Gilbert
Mon, Dec 8, 2014 3:13 PM

Matt,

Congratulations on the release of this - this is very exciting! I have a
few questions:

  1. 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?

  2. 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?

  3. 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

Matt, Congratulations on the release of this - this is very exciting! I have a few questions: 1) 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? 2) 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? 3) 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 > >
MB
Martin Braun
Mon, Dec 8, 2014 7:16 PM

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:

  1. 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?

Development is pretty far. It's already possible to do some RFNoC tasks,
we're still ironing out some kinks though.

  1. 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?

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).

  1. 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?

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

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: > > 1) 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? Development is pretty far. It's already possible to do some RFNoC tasks, we're still ironing out some kinks though. > 2) 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? 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). > 3) 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? 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
JG
Jacob Gilbert
Tue, Dec 9, 2014 9:09 PM

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:

  1. 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?

Development is pretty far. It's already possible to do some RFNoC tasks,
we're still ironing out some kinks though.

  1. 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?

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).

  1. 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?

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

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: > > > > 1) 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? > > Development is pretty far. It's already possible to do some RFNoC tasks, > we're still ironing out some kinks though. > > > 2) 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? > > 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). > > > 3) 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? > > 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 >
ME
Matt Ettus
Tue, Dec 9, 2014 9:36 PM

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:

  1. 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?

Development is pretty far. It's already possible to do some RFNoC tasks,
we're still ironing out some kinks though.

  1. 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?

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).

  1. 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?

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: >> > >> > 1) 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? >> >> Development is pretty far. It's already possible to do some RFNoC tasks, >> we're still ironing out some kinks though. >> >> > 2) 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? >> >> 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). >> >> > 3) 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? >> >> 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 > >