[USRP-users] Issues with RFNoC and GNU Radio / throttling

Michael Wentz mchlwntz at gmail.com
Mon Mar 21 18:23:17 EDT 2016


Martin,

Makes sense that the FIFO would help out in that way.

While I was trying to capture the data coming back from my block, I created
a second flowgraph that was:

(file source) --> (throttle) --> (RFNoC block) --> (file sink)

Once I did that I found that the data coming back exactly matched RTL
simulations, which I ran for about 1M samples. This led me to put another
throttle right before my RFNoC block, which solved the problems in the
larger flowgraph - it just wasn't clear why the second throttle (or FIFO)
was necessary. Without it the data was somehow being corrupted. It looked
like samples were being dropped before making it back to GNU Radio, since I
saw my frame headers, just not in the positions I expected them (e.g. every
10k bits). I wasn't able to determine exactly what was happening or if
there was a pattern to it. I may spend some time investigating, but for now
the FIFO seems to make my CE usable.

-Michael

On Mon, Mar 21, 2016 at 5:17 PM, Martin Braun via USRP-users <
usrp-users at lists.ettus.com> wrote:

> Michael,
>
> On 03/21/2016 01:01 PM, Michael Wentz via USRP-users wrote:
> > "You should have at least two RFNoC blocks connected together, going GNU
> > Radio Block-> RFNoC Block -> GNU Radio Block is not recommended (it will
> > work, but with suboptimal performance)."
> >
> > What is "suboptimal" performance? Dropping samples? Lower throughput?
> > Can someone from Ettus Research comment on this? The fact that it works
> > with the FIFO or throttle makes me think my original configuration
> > caused some sort of flow control problem, but I have not put ILA in the
> > design to see what is really happening.
>
> it means the GNU Radio block itself will not consume/produce at the max
> possible rate. It will throttle the data flow. You can still do this for
> testing though -- it won't corrupt your data.
> If you have a FIFO, the consume/produce operations happen in separate
> threads, which works much better.
>
> > My tlast is being asserted every N valid output samples (default N =
> > 364). The decoder needs to observe many thousands of bits before it has
> > valid data to send out. I've tried bypassing this feature and sending
> > valid data out immediately, but still see the same behavior in GNU Radio.
> >
> > My block does use the AXI wrapper to go from the NoC shell to an AXI
> > stream. Not sure why a rate change would cause a problem that I am not
> > seeing in simulation.
>
> We're currently working on some changes to make rate changes easier in
> RFNoC, but I don't think this is it.
>
> What about the data coming out of the block? Other than your downstream
> block not syncing, have you taken a look at it?
>
> Cheers,
> Martin
>
>
> >
> > -Michael
> >
> > On Mon, Mar 21, 2016 at 3:06 PM, Anselm Karl
> > <world.best.usrp.user at gmail.com <mailto:world.best.usrp.user at gmail.com>>
> > wrote:
> >
> >     It is in the getting started Guide, i just looked.
> >
> >     Do you still have a Problem when using fifo plus Decoder? If not
> >     everything is fine, i guess. You can replace the fifo, when the next
> >     block goes from Host to rfnoc.
> >
> >     About the clock: I myself didn't change anything about the clock in
> >     rfnoc_auto_inst...v so far, but as far as I know from what I read as
> >     long as all block run on the same clock and timing is met it should
> >     work.
> >
> >     What are you doing with tlast in your ce? The large Delay on the
> >     start sounds like you are doing something frame based. I would not
> >     delay the output so long but put out some zeros instead. But I don't
> >     think this causes your Problem.
> >
> >     A typical decoder has lower output rate than input rate. This rate
> >     change might cause your problems. What did you use as a starting
> >     point for noc_block_your_fec_Decoder.v ? Axi Wrapper in simple Mode?
> >
> >     Anselm
> >
> >     Am 21.03.2016 17:40 schrieb "Michael Wentz" <mchlwntz at gmail.com
> >     <mailto:mchlwntz at gmail.com>>:
> >
> >         Anselm,
> >
> >         Yes, my demodulator and deframer are both running in software
> >         (using GNU Radio). Which document are you referring to? I looked
> >         through the getting started guide as well as specification on
> >         github and didn't see a reference to this.
> >
> >         I've tried running some of the example RFNoC blocks by
> >         themselves, which seemed to work, although many of them are not
> >         exactly sensitive to losing data every so often. For example,
> >         last week I tried putting the FIR filter before my demodulator
> >         and didn't have any problems, but maybe I just got lucky. If it
> >         was actually dropping one sample out of every million, I'm not
> >         sure I would notice - odds are my timing recovery loop would
> >         just track through it. I was trying to see if this was happening
> >         with my decoder when I noticed that after setting up the test
> >         bench below, everything worked as expected.
> >
> >         (file source) --> (throttle) --> (RFNoC decoder) --> (file sink)
> >
> >         Two other things I thought of that could be problematic: (1) I'm
> >         running all CEs in the design off bus_clk and (2) depending on
> >         the configuration, my decoder may take a long time (> 100k clock
> >         cycles) before producing the first valid sample. Could either of
> >         these be an issue?
> >
> >         -Michael
> >
> >         On Mon, Mar 21, 2016 at 3:09 AM, Anselm Karl
> >         <world.best.usrp.user at gmail.com
> >         <mailto:world.best.usrp.user at gmail.com>> wrote:
> >
> >             Hi Michael,
> >
> >             your demodulator and your deframer are software-blocks,
> >             right? Some rfnoc-document says you always should put
> >             minimum two rfnoc-blocks in a chain before jumping (back) to
> >             the host. One works, but with poor performance. I tried and
> >             experienced it myself. Put a fifo as second if you only need
> >             one block.
> >
> >             I think the rfnoc-crossbar does some switching based on the
> >             packages marked by tlast. One single block might have a
> >             little too little buffer and the tlast might get "stuck".
> >             (This is just my theory and doesn't matter anyway.)
> >
> >
> >             Anselm
> >
> >             On 17 March 2016 at 23:47, Michael Wentz via USRP-users
> >             <usrp-users at lists.ettus.com
> >             <mailto:usrp-users at lists.ettus.com>> wrote:
> >
> >                 Hi,
> >
> >                 I recently finished a FEC decoder CE in RFNoC and
> >                 deployed it to an X310. This is something that I have a
> >                 C++ version of in GNU Radio, so my test to make sure
> >                 things were working in hardware was to replace the
> >                 software version of the block with the RFNoC version of
> >                 the block in a GRC flowgraph, which looks something like
> >                 this:
> >
> >                 Source --> throttle --> demodulator --> decoder (RFNoC)
> >                 --> deframer
> >
> >                 If the deframer synchronizes, I know the RFNoC version
> >                 is working correctly. My first attempt at this was
> >                 somewhat successful - the framer would get lock, then
> >                 lose it, and repeat forever. So I thought that either
> >                 invalid data is making it into my CE, or samples are
> >                 being dropped coming back to GNU Radio. Before we point
> >                 fingers at my CE, I just want to say that it's been
> >                 extensively verified with RTL simulations (including the
> >                 RFNoC test bench) and proven on another FPGA target
> >                 between an AXI compliant source and sink.
> >
> >                 My first step debugging was to run test vectors through
> >                 hardware and RTL simulation. While doing this I found
> >                 out that if I put a throttle block before my CE, the
> >                 problem goes away and things work as expected - but
> >                 after about a minute of running at 1 Msps, everything
> >                 starts grinding to a halt. The slow down appears both
> >                 before and after my CE; for example, I have a
> >                 constellation sink hooked up to the demodulator which
> >                 stops updating. So my question here is: why did the
> >                 throttle make this work, given that I already had a
> >                 throttle in my flowgraph at the source? Any ideas why it
> >                 would slow down after running for a minute or so?
> >
> >                 The next thing I tried was putting a FIFO in the RFNoC
> >                 domain right before my CE and removing the second
> >                 throttle. This seems to have solved my issues
> >                 altogether, but I don't understand why the FIFO is
> >                 necessary. I've deployed this same design to another
> >                 FPGA, and did not require a FIFO between the
> >                 demodulator/decoder in that case. Is it recommended to
> >                 always use a FIFO between the host and a CE? Has anyone
> >                 run into issues similar to this?
> >
> >                 -Michael
> >
> >                 _______________________________________________
> >                 USRP-users mailing list
> >                 USRP-users at lists.ettus.com
> >                 <mailto: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/20160321/86043826/attachment-0002.html>


More information about the USRP-users mailing list