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 On Thu, Jun 7, 2018 at 8:39 PM Peter Sanchez <petersand...@gmail.com> wrote: > Thanks Juan and Nick. Do you know if this is something RFNoC plans to > address in the future? > > I put a DDC in front of the Split Stream block and now I don't see anymore > overrun errors, but I have 2 new problems. First, I can only run the flow > graph one time like Juan described. If I stop it and try to run it again I > don't get anything in my GUI FFT Sink windows, and the terminal prints > timeout on chan 0 errors. > Second, I have 2 FFT Sink windows (one for each steam) and they seem to > update slowly and one at a time. The top one will show live data for 1 > second while the bottom looks like it has paused, then the bottom will show > live data for 1 second and the top looks paused and so on. CPU usage is low > and data from the X310 is only at 40MB/s. > > On Thu, Jun 7, 2018 at 12:12 AM, Nick Foster <bistrom...@gmail.com> wrote: > >> The same solution that works for E310 won't work for X310. The easiest >> fix will be to use a DDC block to reduce the sample rate ahead of the Split >> Stream block. The RFNoC bus cannot handle two full-rate streams on a single >> NoC port. >> >> Nick >> >> >> On Thu, Jun 7, 2018, 2:44 AM Juan Francisco via USRP-users < >> usrp-users@lists.ettus.com> wrote: >> >>> Unfortunately I don't have a fix for this, but I have seen similar >>> behavior. I have only been able to get the SplitStream block on the first >>> run after an FPGA reconfiguration (or X310 power cycle). If you try >>> running the flowgraph a second time, it hangs and nothing gets through the >>> SplitStream. >>> >>> On Wed, Jun 6, 2018 at 7:05 PM, Peter Sanchez via USRP-users < >>> usrp-users@lists.ettus.com> wrote: >>> >>>> Hi All, >>>> >>>> I have a RFNoC Receiver --> Split stream --> x2 DDC blocks on the X310. >>>> I see a ton of overrun on chan 0 errors after adding the Split Stream >>>> block and GNU Radio Companion eventually crashes all together. >>>> >>>> >>>> I read about a similar problem on the E310 and the fix was to change >>>> the ce_clk to bus_clk in the rfnoc_ce_auto_inst ( >>>> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2017-February/023539.html >>>> ). >>>> I tried changing that in the rfnoc_ce_auto_inst_x310.v code and >>>> reflashed the FPGA but this didn't change the overrun errors. >>>> >>>> Any thoughts? >>>> Thanks! >>>> >>>> _______________________________________________ >>>> 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 >>> >> >
_______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
