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
<ja...@gardettoengineering.com <mailto:ja...@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
<ja...@gardettoengineering.com
<mailto:ja...@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?
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
