[USRP-users] Receiving IO Block Error when Using RFNoC Split Stream

EJ Kreinar ejkreinar at gmail.com
Sat Nov 9 09:48:11 EST 2019


Hi there,

Just want to chime in since I recently went through the upgrade process to
UHD-3.14...

Can you confirm you're using uhd-3.14? If so, this is actually a split
stream fpga bug caused by the commit Jon referred to, not the "not enough
bandwidth" problem.

Fortunately, rather than referring the old commit, the bug seems to have
been fixed in October on the master branch: https://
github.com/EttusResearch/fpga/commit/1102779f49d44c9e8b88ce7251d203eb62ae26c9
(but not yet ported onto 3.14)

I just cherry-picked 1102779f onto my UHD-3.14 and it cleaned it up for me.

I assume this will eventually make it to the UHD-3.14 branch? But if not
the cherry pick works fine

EJ


On Fri, Nov 8, 2019, 2:43 PM Jonathan Lockhart via USRP-users <
usrp-users at lists.ettus.com> wrote:

> Jonathon,
>
> I will give that a try and see if it works.
>
>
> Nick,
>
> If the revert on Split_Stream fails, I will try switching from ce_clk to
> bus_clk and give that a try.
>
>
> Regards,
> Jon
>
> On Fri, Nov 8, 2019 at 1:52 PM Nick Foster <bistromath at gmail.com> wrote:
>
>> 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.
>>
>> 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.
>>
>> Nick
>>
>> On Fri, Nov 8, 2019 at 10:20 AM Jonathon Pendlum <
>> jonathon.pendlum at ettus.com> wrote:
>>
>>> Hi Jon,
>>>
>>> Can you try reverting commit e39334fe on the fpga repo and rebuilding
>>> your bitstream? Let me know if that makes a difference or not.
>>>
>>> Jonathon
>>>
>>> On Sat, Nov 9, 2019 at 12:13 AM Jonathan Lockhart via USRP-users <
>>> usrp-users at lists.ettus.com> wrote:
>>>
>>>> Greetings Nick,
>>>>
>>>> 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.
>>>>
>>>> [image: Screenshot from 2019-11-08 10-06-50.png]
>>>>
>>>> Regards,
>>>> Jon
>>>>
>>>> On Thu, Nov 7, 2019 at 5:33 PM Nick Foster <bistromath at gmail.com>
>>>> wrote:
>>>>
>>>>> Can you be more specific about what your flowgraph looks like?
>>>>>
>>>>> On Thu, Nov 7, 2019 at 2:22 PM Jonathan Lockhart via USRP-users <
>>>>> usrp-users at lists.ettus.com> wrote:
>>>>>
>>>>>> Greetings,
>>>>>>
>>>>>> I was wondering if anyone had encountered the following error and had
>>>>>> a way to fix it?
>>>>>>
>>>>>> [INFO] [UHD] linux; GNU C++ version 4.9.2; Boost_105700;
>>>>>> UHD_3.14.1.HEAD-0-g0347a6d8
>>>>>> [INFO] [E300] Loading FPGA image: /home/root/localinstall/e300.bit...
>>>>>> [INFO] [E300] FPGA image loaded
>>>>>> [INFO] [E300] Detecting internal GPS
>>>>>> .... [INFO] [E300] GPSDO found
>>>>>> [INFO] [E300] Initializing core control (global registers)...
>>>>>>
>>>>>> [INFO] [E300] Performing register loopback test...
>>>>>> [INFO] [E300] Register loopback test passed
>>>>>> [INFO] [0/Radio_0] Initializing block control (NOC ID:
>>>>>> 0x12AD100000000000)
>>>>>> [WARNING] [RFNOC] Can't find a block controller for key SplitStream,
>>>>>> using default block controller!
>>>>>> [INFO] [0/SplitStream_0] Initializing block control (NOC ID:
>>>>>> 0x5757000000000000)
>>>>>> [ERROR] [UHD] Exception caught in safe-call.
>>>>>>   in ctrl_iface_impl<_endianness>::~ctrl_iface_impl() [with
>>>>>> uhd::endianness_t _endianness = (uhd::endianness_t)1u]
>>>>>>   at /home/jon/rfnoc_3.14.1.1/src/uhd/host/lib/rfnoc/ctrl_iface.cpp:52
>>>>>> this->send_cmd_pkt(0, 0, true); -> EnvironmentError: IOError: Block
>>>>>> ctrl (CE_01_Port_21) no response packet - AssertionError: bool(buff)
>>>>>>   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]
>>>>>>   at
>>>>>> /home/jon/rfnoc_3.14.1.1/src/uhd/host/lib/rfnoc/ctrl_iface.cpp:142
>>>>>>
>>>>>> Traceback (most recent call last):
>>>>>>   File "rfnoc_fosphor_network_usrp.py", line 283, in <module>
>>>>>>     main()
>>>>>>   File "rfnoc_fosphor_network_usrp.py", line 272, in main
>>>>>>     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)
>>>>>>   File "rfnoc_fosphor_network_usrp.py", line 43, in __init__
>>>>>>     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))) ))
>>>>>>   File
>>>>>> "/home/root/localinstall/usr/lib/python2.7/site-packages/ettus/ettus_swig.py",
>>>>>> line 1307, in make
>>>>>>     return _ettus_swig.device3_make(*args, **kwargs)
>>>>>> RuntimeError: EnvironmentError: IOError: [0/SplitStream_0]
>>>>>> sr_read64() failed: EnvironmentError: IOError: Block ctrl (CE_01_Port_21)
>>>>>> no response packet - AssertionError: bool(buff)
>>>>>>   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]
>>>>>>   at
>>>>>> /home/jon/rfnoc_3.14.1.1/src/uhd/host/lib/rfnoc/ctrl_iface.cpp:142
>>>>>>
>>>>>> 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
>>>>>> rfnoc_ce_auto_inst_<device>.v  as shown from the output when
>>>>>> attempting a "find" command in Ubuntu.
>>>>>>
>>>>>> find: ‘rfnoc_ce_auto_inst_e310.v’: No such file or directory
>>>>>>
>>>>>> I ran it on both ~/* and /* with no luck.
>>>>>>
>>>>>> Regards,
>>>>>> Jon Lockhart
>>>>>>
>>>>>> [1]
>>>>>> https://kb.ettus.com/RFNoC#Why_do_I_have_a_command_timeout_error.3F
>>>>>>
>>>>>> _______________________________________________
>>>>>> USRP-users mailing list
>>>>>> USRP-users at lists.ettus.com
>>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>>>
>>>>> _______________________________________________
>>>> USRP-users mailing list
>>>> USRP-users at lists.ettus.com
>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>
>>> _______________________________________________
> USRP-users mailing list
> USRP-users at lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20191109/44278f5b/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screenshot from 2019-11-08 10-06-50.png
Type: image/png
Size: 138368 bytes
Desc: not available
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20191109/44278f5b/attachment.png>


More information about the USRP-users mailing list