<div dir="ltr"><div>Greetings Nick and EJ,</div><div><br></div><div>Yes you are correct, the split stream does require a FIFO after the output if I want to port to the arm or ZMQ. That resolved the run error.</div><div><br></div><div>EJ,</div><div><br></div><div>Currently I am just modifying the default installation example that comes with UHD for the fosphor GNR files, and by default Ettus has it set to 56 MHz, which does appear to be a valid sample rate for the E312 SG3. I haven't seen any odd behavior with the default example, albeit I am still playing with the split stream so I may run into issues still. <br></div><div><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 Thu, Nov 14, 2019 at 6:11 PM EJ Kreinar <<a href="mailto:ejkreinar@gmail.com">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="ltr">Cool! <br><br>I'll point out that your new build actually got past the old failure point you noted before, which was immediately after attempting to interact with the SplitStream RFNOC block!<br><br>```<br>[INFO] [0/SplitStream_0] Initializing block control (NOC ID: 0x5757000000000000)<br>[ERROR] [UHD] Exception caught in safe-call.<br>[...etc...]<br>```<div><br><div>I second Nick's thought. Try adding a FIFO after the second split-stream port.</div><div><br></div><div>Though on further inspection, I actually doubt this particular application would work at all, since it looks like you're trying to push 56 MHz through the RFNoC FPGA->ARM transport and then through ZMQ. The E310 definitely cannot handle that sort of load, and you might get undefined behavior in RFNOC fosphor because the underflow will propagate back to the RFNoC Radio and momentarily stop the RF stream before restarting...<br></div></div><div><br></div><div>EJ</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Nov 14, 2019 at 6:05 PM Nick Foster <<a href="mailto:bistromath@gmail.com" 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">I also haven't tested to see if this is a gr-ettus limitation or a UHD limitation.<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Nov 14, 2019 at 3:04 PM Nick Foster <<a href="mailto:bistromath@gmail.com" 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>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" 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"><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>
</blockquote></div>
</blockquote></div>
</blockquote></div>