Nick, I was wondering if you ever posted anything about your workaround to the
limitation you talked about below from back in June?
In my flowgraph, I have both RFNoC radio's receiving and each stream has a
split_stream in it. I am concerned that the split stream might be causing some
of my issues that you commented on below.
A single stream (the 2 are the same are) looks like:
Radio -----> DDC (200M to 100M) -----> split -----> keepMinN (custom noc block
to keep m vectors of n vectors) -----> GR host processing
|
---------> DDC (100M to 100K) -------> GR host processing
(then a repeat of that for the second radio)
I need the split, but I am only doing the drop from 200M to 100M because it
seems to be the best way to get things to run without //too// many "overrun on
chan 0" or 'D' from UHD. I can ignore the overruns/D if I can keep them to a
reasonable amount, but I was curious if there was something I could do to run
without that very first DDC that is halving things.
TIA!
________________________________
From: USRP-users <usrp-users-boun...@lists.ettus.com> on behalf of Nick Foster
via USRP-users <usrp-users@lists.ettus.com>
Sent: Saturday, June 9, 2018 1:12 PM
To: usrp-users
Subject: Re: [USRP-users] RFNoC Overrun Using Split Stream
It's not necessarily a limitation in RFNoC, or at least it seems to be a
reasonable one; if the bus is to support 2 full-rate streams on a single
block, why not 3, or even 4? To allow multiple streams at full rate you'd
have to either increase the speed of bus_clk relative to ce_clk, or you'd
have to increase the width of the RFNoC bus itself. Both solutions have
pretty severe consequences in terms of resource usage, and both would
increase resource use for every RFNoC application, even those that don't
require full-rate streaming from two ports.
The limitation comes from the fact that all ports in a RFNoC block are
muxed onto the same 64-bit-wide RFNoC bus, and so the bandwidth of that
connection to the main NoC router is shared by all the ports in a
block. If bus_clk
== ce_clk, then you could theoretically get two ports on a single block
streaming at full rate (since each port is 32 bits wide), but overhead will
prevent that from succeeding in the real world. Maybe there's some
reasonable increase to bus_clk that would allow this and still meet timing,
but I haven't played with that and bus_clk already seems to be near the
hairy edge of meeting timing in my builds.
I've worked around this in the past by instantiating multiple RFNoC blocks
(not ports!) in my block and bringing them out to the top level. You'll
then have to connect both blocks to the NoC bus in
rfnoc_ce_auto_inst_x310.v. It's a bit messy especially if you want to use
gr-uhd, because you have to write a separate host descriptor and GRC block
for each additional input/output, but it does work. I can stream four
full-rate streams from a single processing block this way. I suppose I
should update my "Stupid NoC Tricks" guide to include this one, but it
probably won't happen soon.
The error you're currently seeing looks like another issue. What happens if
you stream to a single FFT sink with two inputs?
Nick
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com<mailto: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
