[USRP-users] timout issue on RFNoC output

Jason Matusiak jason at gardettoengineering.com
Mon Jul 24 14:09:17 EDT 2017


What I did was instead of creating an enable flag, I used the PKT_SIZE 
value I write when I execute a flowgraph to be my enable:
assign enabled = (PKT_SIZE > 0) ? 1'b1 : 1'b0;
assign o_tvalid = enabled;

That should work, right?  If not, how do I know that initialization is done?

I didn't write any C++ code for this block, is there an example for what 
you want me to do (I haven't done that to a block before)?  I can't seem 
to find any C++ code for the RFNoC:siggen block.


On 07/24/2017 01:57 PM, Jonathon Pendlum wrote:
> In the first screenshot you captured your block sending out a command 
> response packet. That is normal.
>
> In the second screenshot, I couldn't see the full value of the header 
> / first word, so I cannot say if it had any issues.
>
> Did you add an explicit enable for your block that turns it on after 
> initialization? It would also be a good idea to add a sr_write to turn 
> off the enable in your block's destructor code too.
>
> On Mon, Jul 24, 2017 at 10:29 AM, Jason Matusiak 
> <jason at gardettoengineering.com <mailto:jason at gardettoengineering.com>> 
> wrote:
>
>     One last piece of oddball info I've discovered.
>
>     RFNoC:dataGenerator -> RFNoC:FIFO -> throttle -> QT GUI Time Sink
>
>     1 - If I program the X310 and run it, I get timeouts streaming
>     immediately and nothing shows up on the timesink.  If I then stop
>     it and run it again, I get some data through, and then the timeout
>     stream.  If I run it a third time, I get:
>     RuntimeError: EnvironmentError: IOError: Block ctrl
>     (CE_00_Port_30) no response packet - AssertionError: bool(buff)
>       in uint64_t ctrl_iface_impl::wait_for_ack(bool)
>       at /home/jmat/rfnoc/src/uhd/host/lib/rfnoc/ctrl_iface.cpp:197
>
>     2 - If I remove the throttle (leave everything else the same), I
>     get different results.  The first time through is the same,
>     immediate stream of timeouts.  The second time I run it I get one
>     "overrun on chan 0 D", but then the data streams through
>     successfully.  If I run it a third time, I get the Block ctrl
>     errors again.
>
>     3 - a fresh download of the image and then a uhd_usrp_probe returns a:
>     [ERROR] [UHD] Exception caught in safe-call.
>       in virtual ctrl_iface_impl::~ctrl_iface_impl()
>       at /home/jmat/rfnoc/src/uhd/host/lib/rfnoc/ctrl_iface.cpp:76
>     this->peek32(0); -> EnvironmentError: IOError: Block ctrl
>     (CE_00_Port_30) packet parse error - EnvironmentError: IOError:
>     Expected SID: 02:30>00:00 Received SID: 02:60>00:00
>
>     And then running my flowgraph after getting that error only give
>     me the error.
>
>     I cannot for the life of me figure out why removing the throttle
>     helps, and what is special about running it the second time. 
>     Also, why will it "run" on a fresh boot, but when I probe it first
>     it gets into a weird state?
>
>
>
>     On 07/24/2017 12:32 PM, Jason Matusiak wrote:
>>     OK, in my original email I said that nothing was coming out of
>>     o_tdata at the top level, but for some reason I see it working
>>     now.  That said, I am still not seeing anything come out of the
>>     block even though the o_tdata seems to be working.
>>
>>     I attached a screenshot of what the data looks like in the middle
>>     of running.  I see the data go valid, then it waits on o_tready
>>     to go high, then data streams out until o_tlast goes high.  That
>>     all seems legitimate to me, but when I put that output of the
>>     block through a throttle and then a file sink, there is no data
>>     (which is probably why I see the timeouts streaming across the
>>     debug screen).
>>
>>     Any thoughts?
>>
>>
>>     On 07/24/2017 08:08 AM, Jason Matusiak wrote:
>>>     OK, attached is a screenshot of what you wanted.  i triggered on
>>>     when o_tvalid when high and monitored o_tdata, o_tlast,
>>>     o_tready, and o_tvalid.  I need to look at a working block, but
>>>     I am surprised to see o_tlast go high so quickly..
>>>
>>>     I would love to hear what you think is going on because I am
>>>     stuck on this and have been for a few days.
>>>
>>>     On 07/21/2017 04:00 PM, Jonathon Pendlum wrote:
>>>>     Yep
>>>>
>>>>     On Fri, Jul 21, 2017 at 11:54 AM, Jason Matusiak
>>>>     <jason at gardettoengineering.com
>>>>     <mailto:jason at gardettoengineering.com>> wrote:
>>>>
>>>>         I need to re-setup my debug messages to check.  To be
>>>>         clear, you are talking about the o_tdata (etc) up in my
>>>>         upper level noc_block_dataGenerator, right?
>>>>
>>>>
>>>>
>>>>         On 07/21/2017 02:52 PM, Jonathon Pendlum wrote:
>>>>
>>>>             Here is what should happen on the axi stream bus to the
>>>>             crossbar. You should first see the header on o_tdata
>>>>             with o_tvalid asserted. After a few clock cycles,
>>>>             depending on how long arbitration takes, you should see
>>>>             o_tready assert. Are you seeing that sequence?
>>>>
>>>>
>>>>
>>>
>>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170724/9e9d2f55/attachment-0002.html>


More information about the USRP-users mailing list