Has anyone had any ideas on how to address this issue?
I'm not sure if my issue is the same as Paolo is seeing or not, but after debugging some more, I did have an additional question I was hoping someone could help me with. As I mentioned, the data stream I'm sending to the AXI_Wrapper seems to work for a while, but at some point I start getting the following error in GNU Radio: overrun on chan 0 D That persists for a while, then I get the error: timeout on chan 0 Once I get that timeout, data_tready from AXI_Wrapper is stuck low, and I have to power-cycle or reprogram the FGPA to recover. Does anyone know what exactly would cause these error messages, and what that means within the context of the FGPA datapath? Any assistance or insights would be greatly appreciated. Thank you, Michael H. Rich Electronic Systems Laboratory Georgia Tech Research InstituteR Phone: (404) 407-8358 E-mail: <mailto:michael.r...@gtri.gatech.edu> michael.r...@gtri.gatech.edu From: Paolo Palana <p.pal...@itsystems.it> Sent: Tuesday, April 13, 2021 3:06 AM To: usrp-users@lists.ettus.com Subject: [USRP-users] Re: AXI Stream Issue Cheers to all the mailing list. I have similar problem too (the device is an X310 with TwinRx, UHD-3.15 on ubuntu 20.04). My NoC Block too has 2 input and 2 output at a different data rate. The start streaming goes smootly and it seems to work for a while, but when I stop the streaming (during my tests I streamed for a very short time, say 10 secs) I had the following error from UHD. [ERROR] [UHD] Exception caught in safe-call. in ctrl_iface_impl<_endianness>::~ctrl_iface_impl() [with uhd::endianness_t _endianness = uhd::ENDIANNESS_BIG] at ~/host/lib/rfnoc/ctrl_iface.cpp:50 this->send_cmd_pkt(0, 0, true); -> EnvironmentError: IOError: Block ctrl (CE_03_Port_61) 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_BIG; uint64_t = long unsigned int] at ~/host/lib/rfnoc/ctrl_iface.cpp:151 It seems too me that the internal FPGA bus for some reason is stuck. In fact when I see the signals with ILA after the stop streaming I can see that the i_tready signal for the second input in my Noc Block is low, while the the i_tvalid is high. In my implementation I'm not using the axi_wrapper, but directly the chdr_deframer_2clk and chdr_framer_2clk. I'm pretty shure that the logic of my NoC Block is (almost) correct because I have the same one running with UHD-3.10.3 without any problem. Up to now I'm unable to pinpoint the problem, What can be the problem? Any suggestion Thank you for your attention Paolo From: Rich, Michael via USRP-users <usrp-users@lists.ettus.com> Sent: Monday, April 12, 2021 2:54 PM To: usrp-users@lists.ettus.com Subject: [USRP-users] AXI Stream Issue I am having issues getting data out of a custom block NoC Block (on an X310 using UHD3.15) and I'm not quite sure what would be causing what I'm seeing. When everything starts up, it seems to work just fine for a bit, but then output stops. Checking the data bus using an ILA, it appears as though data_tready from the AXI_Wrapper goes low at some point and just stays there. My output is at a different rate than the input, so I've set SIMPLE_MODE=0 for AXI_WRAPPER. I'm fairly sure I'm driving the AMBA bus properly. I'm setting s_axis_data_tuser as follows: Bit 127-126 = 00 (data) Bit 125 = 0 (timestamp not used) Bit 124 = 0 or 1 (depending upon if end-of-burst or not) Bit 123-112 = sequence number (monotonically increasing for each packet starting at 0) Bit 111-96 = packet length (total number of data bytes + 8 header bytes) Bit 95-80 = src_sid (from noc_shell) Bit 79-64 = next_dst_sid (from noc_shell) Bit 63-0 = 0 What might cause data_tready to remain low? Is there anything else I should be looking at that might explain this behavior? Thank you, Michael H. Rich Electronic Systems Laboratory Georgia Tech Research InstituteR Phone: (404) 407-8358 E-mail: <mailto:michael.r...@gtri.gatech.edu> michael.r...@gtri.gatech.edu
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
