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 <[email protected]> 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 > <[email protected]> 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 <[email protected]> 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 >> [email protected] >> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com _______________________________________________ USRP-users mailing list [email protected] http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
