[USRP-users] e310, RFNOC, GNURadio Full Duplex, Custom RFNOC Block

Andrew Payne wandrewp at gmail.com
Thu Jul 9 12:22:36 EDT 2020

Thank you, I will try this tweak first.

But in noc_block_keep_one_in_n.v, they have set the reset input of the
instantiated keep_one_in_n.v module to (ce_rst | tx_seqnum) with a
commented explanation for why.  I have my own custom code module
instantiated in my top noc block, and within there is a chain of
modules that are connected via the AXI stream interface, to include
keep_one_in_n.v as the last module in the chain.  What I can't
understand is whether I should I tie that (ce_rst | tx_seqnum) to the
reset input of every module including keep_one_in_n or just to the
reset input of keep_one_in_n?

On Wed, Jul 8, 2020 at 10:47 PM Jonathon Pendlum
<jonathon.pendlum at ettus.com> wrote:
> Hi Andrew,
> AXI Wrapper's SIMPLE_MODE can only be used with blocks that do not perform a rate change. Since you are using keep_one_in_n, your block is performing a decimation of sorts, so you cannot use SIMPLE_MODE. You should manually set up the header on tuser using noc_block_keep_one_in_n.v as an example. This may be the cause of your problem.
> Jonathon
> On Wed, Jul 8, 2020 at 7:26 PM Andrew Payne via USRP-users <usrp-users at lists.ettus.com> wrote:
>> Actually I have found a clue! In
>> usrp3/lib/rfnoc/noc_block_keep_one_in_n.v, axi_wrapper simple_mode is
>> set to off, instead opting to use cvita_hdr_modify.  I opted to use
>> keep_one_in_n.v in my custom noc_block, BUT, I have set simple mode to
>> 1.  And if I go into usrp3/lib/rfnoc/axi_wrapper.v, at the top the
>> comments for SIMPLE_MODE say "Automatically handle header
>> (s_axis_data_tuser), packets must be consumed / produced 1-to-1".
>> What does this mean?  That the CEs installed at the crossbar are all
>> beholden to the rate of this CE?  Because remember with my issue, my
>> custom RFNOC block (which incorporates keep_one_in_n.v with simple
>> mode enabled) works well, the TX with DUC alone works well, but TX
>> with DUC and FIFO plus my custom RFNOC block seems to greatly
>> attenuate TX.  Could the TX stream be slowed down by my custom RFNOC
>> CE?
>> On Wed, Jul 8, 2020 at 4:37 PM Andrew Payne <wandrewp at gmail.com> wrote:
>> >
>> > I have an issue with my setup I'm hoping to solve.
>> >
>> > I have an e310 running the UHD 3.15 LTS image.
>> >
>> > I have created one custom RFNOC block, which has 2 RX streams, and it
>> > is composed of the following chain: complex to magnitude ---> moving
>> > sum ---> keep one in n (n=2048) ---> FIFO with input parameter SIZE=5,
>> > so then I don't need the RFNOC FIFO block to save space when
>> > generating the FPGA image file.  The moving sum block generates a sum
>> > from a power of 2 samples, then I feed the keep one in n block with a
>> > resulting sum whose LSBs are truncated, effectively dividing by a
>> > power of 2 to effectively generate a moving average. I am using the
>> > AXI Wrapper with Simple Mode, noc shell, etc, all generated from the
>> > rfnoc mod tool.
>> >
>> > It works great, but I also have a TX output signal, just a sine wave,
>> > in my gnuradio flowgraph.  Its output, depending on the RF center
>> > frequency, is greatly attenuated (the greatest I can get it is like
>> > -39dBm, but it falls off to -55).  But if I just have the TX output
>> > alone without my RX RFNOC block, I can get the output over 0dBm or
>> > more, haven't tried going higher than that.
>> >
>> > My question is, how can I get the TX signal higher with my full duplex
>> > RFNOC setup?  Could anything about the RX chain be affecting my TX
>> > samples, like could it be somehow deleting samples?  Do I need to tag
>> > the streams in GNURadio so they don't interfere or something?
>> >
>> > Thanks,
>> > Andrew
>> _______________________________________________
>> 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