Hi, I'll add a few thoughts since I've looked into this a bit...
> Although rfnoc supports different number of inputs and outputs uhd does not and you'll get all sorts of issues trying to address this. To clarify what I've seen in behavior and in the code, there are some places in UHD software that assume rfnoc ports perform "pass-through" operations, ie, that input port 0 is connected to output port 0, input port 1 to output port 1, etc. In most cases supported by "legacy mode" with RFNoC, the pass-through operation makes sense (Radio -> DDC -> FIFO -> Processor), but it does not seem to translate well into the fully arbitrary / more advanced scenarios possible with low-level RFNoC control... Specifically, the original crash on this email thread appears to originate from this sr_write operation in the device3_io_impl.cpp: ( https://github.com/EttusResearch/uhd/blob/master/host/lib/usrp/device3/device3_io_impl.cpp#L569 ) ``` std::vector<boost::shared_ptr<uhd::rfnoc::radio_ctrl> > upstream_radio_nodes = blk_ctrl->find_upstream_node<uhd::rfnoc::radio_ctrl>(); UHD_RX_STREAMER_LOG() << "Number of upstream radio nodes: " << upstream_radio_nodes.size(); for(const boost::shared_ptr<uhd::rfnoc::radio_ctrl> &node: upstream_radio_nodes) { node->sr_write(uhd::rfnoc::SR_RESP_OUT_DST_SID, xport.send_sid.get_src(), block_port); } ``` Clearly, it does not make sense to use block_port in the sr_write call above because block_port is defined earlier as the output port of the *downstream block* (in this case, the splitstream). Assuming this line is changed (I have not tried a fix yet), it may also expose other issues in UHD that assume pass-through block ports. In fact, just this one example brings up another architectural questions. If the SR_RESP_OUT_DST_SID of the radio block can only be assigned to ONE rx_streamer, then where are the messages routed if you have multiple rx_streamers downstream from the same radio output port (e.g. after a splitstream)? Does only one rx_streamer get the benefit of receiving messages from the radio block? Is this even a problem? I have not investigated far enough to find out. EJ On Tue, Jul 24, 2018 at 8:30 AM Dario Pennisi via USRP-users < usrp-users@lists.ettus.com> wrote: > Hi guys, > Although rfnoc supports different number of inputs and outputs uhd does > not and you'll get all sorts of issues trying to address this. > This is the reason why adder block also has a subtract output... > Another issue is that loopback within fpga does not work. This means that > signals in a chain have to originate or terminate on the host. If you have > paths completely contained in rfnoc domain some streamers will not be > enabled and you'll have to enable them manually. > Finally remember that ports share the bandwidth of a single axi port so > make sure total bandwidth is below it. For x310 axi bw is around 300 msps > > > Dario Pennisi > > > > > On Tue, Jul 24, 2018 at 1:56 PM +0200, "Carlos Alberto Ruiz Naranjo via > USRP-users" <usrp-users@lists.ettus.com> wrote: > > Please, any help?? :( :( :( >> >> 2018-07-12 19:13 GMT+02:00 Brassard, Sean M. <sean.brass...@jhuapl.edu>: >> >>> We never received any help from Ettus on this and never got past the >>> problem. >>> >>> >>> >>> Sean >>> >>> >>> >>> *From:* Carlos Alberto Ruiz Naranjo [mailto:carlosruiznara...@gmail.com] >>> >>> *Sent:* Thursday, July 12, 2018 2:42 AM >>> *To:* Barker, Douglas W. >>> *Cc:* Jonathon Pendlum; Yim, Kaun J.; usrp-users@lists.ettus.com; >>> Brassard, Sean M. >>> >>> *Subject:* Re: [USRP-users] Error with multiple block output ports >>> >>> >>> >>> I have the same problem, any help? ^^ >>> >>> >>> >>> 2017-06-06 13:45 GMT+02:00 Barker, Douglas W. via USRP-users < >>> usrp-users@lists.ettus.com>: >>> >>> Hello, >>> >>> >>> >>> Is there any update on our issue? >>> >>> >>> >>> Thanks >>> >>> Doug >>> >>> >>> >>> *From:* Jonathon Pendlum [mailto:jonathon.pend...@ettus.com] >>> *Sent:* Monday, May 29, 2017 2:16 AM >>> >>> *To:* Barker, Douglas W. >>> *Cc:* usrp-users@lists.ettus.com >>> *Subject:* Re: [USRP-users] Error with multiple block output ports >>> >>> >>> >>> Try fixing these issues, especially the first one, and see if that helps: >>> >>> >>> >>> - In uhd_rfnoc_split_stream.xml, the RX stream args defines 2 channels >>> instead of 3. >>> >>> - In noc_block_split_stream.v, the ACTIVE_MASK on split_stream_fifo is >>> set to have only two active outputs. >>> >>> >>> >>> On Fri, May 26, 2017 at 8:03 AM, Barker, Douglas W. < >>> douglas.bar...@jhuapl.edu> wrote: >>> >>> Jonathon, >>> >>> >>> >>> I’ve attached the XML files that I was using. >>> >>> >>> >>> >>> >>> Thanks! >>> >>> Doug >>> >>> >>> >>> *From:* Jonathon Pendlum [mailto:jonathon.pend...@ettus.com] >>> *Sent:* Thursday, May 25, 2017 3:46 PM >>> *To:* Barker, Douglas W. >>> *Cc:* usrp-users@lists.ettus.com >>> *Subject:* Re: [USRP-users] Error with multiple block output ports >>> >>> >>> >>> Hi Doug, >>> >>> >>> >>> Can you share your Noc Script XML file? >>> >>> >>> >>> >>> >>> >>> >>> Jonathon >>> >>> >>> >>> On Fri, May 19, 2017 at 2:17 PM, Barker, Douglas W. via USRP-users < >>> usrp-users@lists.ettus.com> wrote: >>> >>> Hello, >>> >>> >>> >>> I’m starting a new thread for this problem. I get an error when trying >>> to use more than 2 output ports on a RFNoC block. I’ve designed a CE that >>> has 9 output ports and when starting the gnuradio flowgraph it errors out. >>> When I reduce the ports to 2 it works. If I increase the ports to 3 it >>> errors out. >>> >>> >>> >>> I then made a simple modification to the ‘noc_block_split_stream’ block >>> that is provided to have three output ports (also modified the associated >>> XML files). It error out as well, in the same way. This test has >>> Radio->DDC-SplitStream->host. Below are the messages produced by gnuradio >>> when starting. Can the folks at Ettus please take a look as it appears to >>> be a bug in UHD. I’ve attached the modified ‘noc_block_split_stream.v’ >>> file so you can easily reproduce the error. >>> >>> >>> >>> Thanks >>> >>> Doug >>> >>> >>> >>> >>> >>> Generating: '/home/dm/Documents/doug_rfnoc/top_block.py' >>> >>> >>> >>> Executing: /usr/bin/python2 -u /home/dm/Documents/doug_rfnoc/top_block.py >>> >>> >>> >>> [32;1m[INFO] [UHD] [39;0mlinux; GNU C++ version 5.4.0 20160609; >>> Boost_106300; UHD_4.0.0.rfnoc-devel-316-g24b98579 >>> >>> [32;1m[INFO] [X300] [39;0mX300 initialization sequence... >>> >>> [32;1m[INFO] [X300] [39;0mDetermining maximum frame size... >>> >>> [32;1m[INFO] [X300] [39;0mMaximum frame size: 1472 bytes. >>> >>> [32;1m[INFO] [X300] [39;0mSetup basic communication... >>> >>> [32;1m[INFO] [X300] [39;0mLoading values from EEPROM... >>> >>> [32;1m[INFO] [X300] [39;0mSetup RF frontend clocking... >>> >>> [32;1m[INFO] [X300] [39;0mRadio 1x clock:200 >>> >>> [32;1m[INFO] [RFNOC] [39;0m[DMA FIFO] Running BIST for FIFO 0... >>> >>> [32;1m[INFO] [RFNOC] [39;0mpass (Throughput: 1305.2MB/s) >>> >>> [32;1m[INFO] [RFNOC] [39;0m[DMA FIFO] Running BIST for FIFO 1... >>> >>> [32;1m[INFO] [RFNOC] [39;0mpass (Throughput: 1302.5MB/s) >>> >>> [32;1m[INFO] [RFNOC RADIO] [39;0mRegister loopback test passed >>> >>> [32;1m[INFO] [RFNOC RADIO] [39;0mRegister loopback test passed >>> >>> [32;1m[INFO] [RFNOC RADIO] [39;0mRegister loopback test passed >>> >>> [32;1m[INFO] [RFNOC RADIO] [39;0mRegister loopback test passed >>> >>> [33;1m[WARNING] [RFNOC] [39;0m[0/SplitStream_0] defines 3 input buffer >>> sizes, but 1 input ports >>> >>> [32;1m[INFO] [CORES] [39;0mPerforming timer loopback test... >>> >>> [32;1m[INFO] [CORES] [39;0mTimer loopback test passed >>> >>> [32;1m[INFO] [CORES] [39;0mPerforming timer loopback test... >>> >>> [32;1m[INFO] [CORES] [39;0mTimer loopback test passed >>> >>> DEBUG: output item size: 8 >>> >>> [33;1m[WARNING] [X300 RADIO] [39;0mset_rx_gain: could not apply gain for >>> this daughterboard. >>> >>> INFO: Setting args on 0/DDC_0 >>> (input_rate=200000000,output_rate=1000000,fullscale=1.0,freq=1000000.0) >>> >>> DEBUG: output item size: 8 >>> >>> INFO: Setting args on 0/SplitStream_0 (gr_vlen=1) >>> >>> DEBUG: output item size: 8 >>> >>> [32;1m[INFO] [RFNOC] [39;0mAssuming max packet size for 0/DDC_0 >>> >>> [32;1m[INFO] [RFNOC] [39;0mAssuming max packet size for 0/Radio_0 >>> >>> DEBUG: check_topology() >>> >>> DEBUG: RFNoC blocks with streaming ports: 1 >>> >>> DEBUG: start(): ninputs == 0 noutputs == 3 >>> >>> DEBUG: creating rx streamer with: >>> gr_vlen=1,block_id=0/SplitStream_0,block_port0=0,block_port1=1,block_port=0 >>> >>> DEBUG: creating rx streamer with: >>> gr_vlen=1,block_id=0/SplitStream_0,block_port0=0,block_port1=1,block_port=1 >>> >>> DEBUG: creating rx streamer with: >>> gr_vlen=1,block_id=0/SplitStream_0,block_port0=0,block_port1=1,block_port=2 >>> >>> thread[thread-per-block[0]: <block uhd_rfnoc_SplitStream (3)>]: >>> LookupError: KeyError: [0/Radio_0] sr_write(): No such port: 2 >>> >>> >>> >>> >>> _______________________________________________ >>> 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 >
_______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
