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

Martin Braun martin.braun at ettus.com
Mon Mar 21 17:17:11 EDT 2016


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?


> -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

More information about the USRP-users mailing list