<div dir="ltr"><div>You can't have heterogenous output destinations on RFNoC blocks -- i.e., you can't send one output to the host and one output to another RFNoC block.</div><div><br></div><div>I'm not sure why this limitation exists as there is no architectural reason I can see.<br></div><div><br></div><div>Nick<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Nov 14, 2019 at 12:35 PM Jonathan Lockhart <<a href="mailto:jlockhartrt@gmail.com">jlockhartrt@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Greetings EJ,</div><div><br></div><div>So went and dug out the E312 b/c I couldn't wait and unfortunately that didn't resolve the issue I was experiencing. I cherry picked the new split_stream block, I am using the same flow graph as provided before, but when it goes to run on the E312 I get the following error. <br></div><div><br></div><div>Traceback (most recent call last):<br>  File "rfnoc_fosphor_radio_network_usrp.py", line 281, in <module><br>    main()<br>  File "rfnoc_fosphor_radio_network_usrp.py", line 271, in main<br>    tb.start()<br>  File "/home/root/localinstall/usr/lib/python2.7/site-packages/gnuradio/gr/top_block.py", line 109, in start<br>    top_block_start_unlocked(self._impl, max_noutput_items)<br>  File "/home/root/localinstall/usr/lib/python2.7/site-packages/gnuradio/gr/runtime_swig.py", line 3671, in top_block_start_unlocked<br>    return _runtime_swig.top_block_start_unlocked(*args, **kwargs)<br>RuntimeError: uhd_rfnoc_SplitStream(9): missing connection from output port 0</div><div><br></div><div>Looks like something is missing from the split stream. I assume it needs to be fixed in the verilog. <br></div><div><br></div><div>I attached a screenshot of the new, cleaned up GNU radio file. I had to remove a FIFO and switch to using a throttle b/c I wasn't able to get it all to fit in the bit file. <br></div><div><br></div><div>Regards,</div><div>Jon<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Nov 13, 2019 at 10:46 AM Jonathan Lockhart <<a href="mailto:jlockhartrt@gmail.com" target="_blank">jlockhartrt@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Greetings EJ,<div><br></div><div>Thanks for the info. I haven't had time to grab the new block as my dev box is packed for moving this weekend. I will get it downloaded and try it as soon as I can. </div><div><br></div><div>Regards,</div><div>Jon</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Nov 9, 2019 at 9:48 AM EJ Kreinar <<a href="mailto:ejkreinar@gmail.com" target="_blank">ejkreinar@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto">Hi there,<div dir="auto"><br></div><div dir="auto">Just want to chime in since I recently went through the upgrade process to UHD-3.14...</div><div dir="auto"><br></div><div dir="auto"><span style="font-family:sans-serif">Can you confirm you're using uhd-3.14? If</span><span style="font-family:sans-serif"> so, this is actually a split stream fpga bug caused by the commit Jon referred to, not the "not enough bandwidth" problem.</span></div><div dir="auto"><span style="font-family:sans-serif"><br></span></div><div dir="auto"><span style="font-family:sans-serif">Fortunately, rather than referring the old commit, the bug seems to have been fixed in October on the master branch: https</span><font face="sans-serif">://<a href="http://github.com/EttusResearch/fpga/commit/1102779f49d44c9e8b88ce7251d203eb62ae26c9" target="_blank">github.com/EttusResearch/fpga/commit/1102779f49d44c9e8b88ce7251d203eb62ae26c9</a> (but not yet ported onto 3.14)</font></div><div dir="auto"><font face="sans-serif"><br></font></div><div dir="auto"><font face="sans-serif">I just cherry-picked 1102779f onto my UHD-3.14 and it cleaned it up for me.</font></div><div dir="auto"><font face="sans-serif"><br></font></div><div dir="auto"><font face="sans-serif">I assume this will eventually make it to the UHD-3.14 branch? But if not the cherry pick works fine</font></div><div dir="auto"><font face="sans-serif"><br></font></div><div dir="auto"><font face="sans-serif">EJ</font></div><div dir="auto"><font face="sans-serif"><br></font></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Nov 8, 2019, 2:43 PM Jonathan Lockhart via USRP-users <<a href="mailto:usrp-users@lists.ettus.com" rel="noreferrer" target="_blank">usrp-users@lists.ettus.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Jonathon,<div><br></div><div>I will give that a try and see if it works.</div><div><br></div><div><br></div><div>Nick,</div><div><br></div><div>If the revert on Split_Stream fails, I will try switching from ce_clk to bus_clk and give that a try. </div><div><br></div><div><br></div><div>Regards,</div><div>Jon</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Nov 8, 2019 at 1:52 PM Nick Foster <<a href="mailto:bistromath@gmail.com" rel="noreferrer noreferrer" target="_blank">bistromath@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Jonathon (Pendlum), correct me if I'm wrong, but I think this is the usual split-stream-demands-more-bandwidth-than-RFNoC-bus-allows problem.<br></div><div><br></div><div>Jonathan (Lockhart), if I'm right, then in your rfnoc_ce_auto_inst_e310.v, if you change the ce_clk/ce_rst in the noc_block_split_stream instantiation to bus_clk/bus_rst, this may fix the problem.</div><div><br></div><div>Nick<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Nov 8, 2019 at 10:20 AM Jonathon Pendlum <<a href="mailto:jonathon.pendlum@ettus.com" rel="noreferrer noreferrer" target="_blank">jonathon.pendlum@ettus.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi Jon,<div><br></div><div>Can you try reverting commit e39334fe on the fpga repo and rebuilding your bitstream? Let me know if that makes a difference or not.</div><div><br></div><div>Jonathon</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Nov 9, 2019 at 12:13 AM Jonathan Lockhart via USRP-users <<a href="mailto:usrp-users@lists.ettus.com" rel="noreferrer noreferrer" target="_blank">usrp-users@lists.ettus.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Greetings Nick,</div><div><br></div><div>Here is the screenshot of my GR flow graph, though it shouldn't matter as the Split_Stream RFNoC Block I believe is a failure of the python or Verilog but the solutions in the link I sent in my previous email did not resolve the issue. <br></div><div><br></div><div><div><img src="https://mail.google.com/mail/?ui=2&ik=1ae818862e&attid=0.1&th=16e50a0101adc4f2&view=fimg&rm=16e50a0101adc4f2&sz=w1600-h1000&attbid=ANGjdJ99ZIcYsSIzDc4CWbFXICEswBw_zKbYxEPrUUzifdVbwxV4DA5-2ZfQVUkIJkApVRObYcGTjPk7XNPRZOpXERJ0z1KQjoXiW9JBGPgI82fhvoAzlecorcyXTfU&disp=emb&realattid=ii_k2qa0bd70&zw" alt="Screenshot from 2019-11-08 10-06-50.png" width="566" height="243"><br></div></div><div><br></div><div>Regards,</div><div>Jon<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Nov 7, 2019 at 5:33 PM Nick Foster <<a href="mailto:bistromath@gmail.com" rel="noreferrer noreferrer" target="_blank">bistromath@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Can you be more specific about what your flowgraph looks like?<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Nov 7, 2019 at 2:22 PM Jonathan Lockhart via USRP-users <<a href="mailto:usrp-users@lists.ettus.com" rel="noreferrer noreferrer" target="_blank">usrp-users@lists.ettus.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Greetings,</div><div><br></div><div>I was wondering if anyone had encountered the following error and had a way to fix it?</div><div><br></div><div>[INFO] [UHD] linux; GNU C++ version 4.9.2; Boost_105700; UHD_3.14.1.HEAD-0-g0347a6d8<br>[INFO] [E300] Loading FPGA image: /home/root/localinstall/e300.bit...<br>[INFO] [E300] FPGA image loaded<br>[INFO] [E300] Detecting internal GPS <br>.... [INFO] [E300] GPSDO found<br>[INFO] [E300] Initializing core control (global registers)...<br><br>[INFO] [E300] Performing register loopback test... <br>[INFO] [E300] Register loopback test passed<br>[INFO] [0/Radio_0] Initializing block control (NOC ID: 0x12AD100000000000)<br>[WARNING] [RFNOC] Can't find a block controller for key SplitStream, using default block controller!<br>[INFO] [0/SplitStream_0] Initializing block control (NOC ID: 0x5757000000000000)<br>[ERROR] [UHD] Exception caught in safe-call.<br>  in ctrl_iface_impl<_endianness>::~ctrl_iface_impl() [with uhd::endianness_t _endianness = (uhd::endianness_t)1u]<br>  at /home/jon/rfnoc_3.14.1.1/src/uhd/host/lib/rfnoc/ctrl_iface.cpp:52<br>this->send_cmd_pkt(0, 0, true); -> EnvironmentError: IOError: Block ctrl (CE_01_Port_21) no response packet - AssertionError: bool(buff)<br>  in uint64_t ctrl_iface_impl<_endianness>::wait_for_ack(bool, double) [with uhd::endianness_t _endianness = (uhd::endianness_t)1u; uint64_t = long long unsigned int]<br>  at /home/jon/rfnoc_3.14.1.1/src/uhd/host/lib/rfnoc/ctrl_iface.cpp:142<br><br>Traceback (most recent call last):<br>  File "rfnoc_fosphor_network_usrp.py", line 283, in <module><br>    main()<br>  File "rfnoc_fosphor_network_usrp.py", line 272, in main<br>    tb = top_block_cls(fft_size=options.fft_size, fpga_path=options.fpga_path, freq=options.freq, gain=options.gain, host_ip_addr=options.host_ip_addr, samp_rate=options.samp_rate, tdecay=options.tdecay, trise=options.trise)<br>  File "rfnoc_fosphor_network_usrp.py", line 43, in __init__<br>    self.device3 = variable_uhd_device3_0 = ettus.device3(uhd.device_addr_t( ",".join(('type=e3x0', "master_clock_rate=%d,fpga=%s" % (samp_rate,fpga_path))) ))<br>  File "/home/root/localinstall/usr/lib/python2.7/site-packages/ettus/ettus_swig.py", line 1307, in make<br>    return _ettus_swig.device3_make(*args, **kwargs)<br>RuntimeError: EnvironmentError: IOError: [0/SplitStream_0] sr_read64() failed: EnvironmentError: IOError: Block ctrl (CE_01_Port_21) no response packet - AssertionError: bool(buff)<br>  in uint64_t ctrl_iface_impl<_endianness>::wait_for_ack(bool, double) [with uhd::endianness_t _endianness = (uhd::endianness_t)1u; uint64_t = long long unsigned int]<br>  at /home/jon/rfnoc_3.14.1.1/src/uhd/host/lib/rfnoc/ctrl_iface.cpp:142</div><div><br></div><div>This is only occurring when I use the split stream block in RFNoC. I have tried the fixes in [1] but unfortunately they have not helped. Also, fix 1, I can't seem to before b/c I am missing the file <code>rfnoc_ce_auto_inst_<device>.v</code>  as shown from the output when attempting a "find" command in Ubuntu. </div><div><br></div><div>find: ‘rfnoc_ce_auto_inst_e310.v’: No such file or directory</div><div><br></div><div>I ran it on both ~/* and /* with no luck. <br></div><div><br></div><div>Regards,</div><div>Jon Lockhart</div><div><br></div><div>[1] <a href="https://kb.ettus.com/RFNoC#Why_do_I_have_a_command_timeout_error.3F" rel="noreferrer noreferrer" target="_blank">https://kb.ettus.com/RFNoC#Why_do_I_have_a_command_timeout_error.3F</a></div><div><br></div></div>
_______________________________________________<br>
USRP-users mailing list<br>
<a href="mailto:USRP-users@lists.ettus.com" rel="noreferrer noreferrer" target="_blank">USRP-users@lists.ettus.com</a><br>
<a href="http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com" rel="noreferrer noreferrer noreferrer" target="_blank">http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com</a><br>
</blockquote></div>
</blockquote></div>
_______________________________________________<br>
USRP-users mailing list<br>
<a href="mailto:USRP-users@lists.ettus.com" rel="noreferrer noreferrer" target="_blank">USRP-users@lists.ettus.com</a><br>
<a href="http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com" rel="noreferrer noreferrer noreferrer" target="_blank">http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com</a><br>
</blockquote></div>
</blockquote></div>
</blockquote></div>
_______________________________________________<br>
USRP-users mailing list<br>
<a href="mailto:USRP-users@lists.ettus.com" rel="noreferrer noreferrer" target="_blank">USRP-users@lists.ettus.com</a><br>
<a href="http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com" rel="noreferrer noreferrer noreferrer" target="_blank">http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com</a><br>
</blockquote></div>
</blockquote></div>
</blockquote></div>
</blockquote></div>