I know this is an older thread, but I too am struggling to bring a block that someone else designed for us in 2015.4 to work in 2017.4. I dug around but I don't see any of our custom blocks using clear_tx_seqnum in their sub-modules or their config registers. They do use the config registers quite a bit to set things up, so I am thinking that it might be related to this.
Is there a list of other changes that might have happened in RFNoC so I can comb through it? I am guessing I am getting tripped up on something like this, but it would help to narrow down the places to look. I did try to change .control to 1'b0 in axi_wrapper.v on line 203 (as recommended in this thread), but that didn't seem to help anything. TIA On Wed, May 2, 2018 at 4:15 PM, Brian Padalino <bpadalino at gmail.com> wrote: > Hey Ashish, >> On Wed, May 2, 2018 at 7:02 PM Ashish Chaudhari <ashish.chaudhari at >> ettus.com> > wrote: >>>> Hi Brian, >>>> >> > Moreover, it seems like axi_wrapper.v uses clear_tx_seqnum to pass >> >> > out >> >> > config bus messages, so now that clear_tx_seqnum is set I am not able >> >> > to >> >> > use >> >> > the config bus from the axi_wrapper. >> >> >> >> I think this is a side effect of the assumption that data cannot flow >> >> through the block when it is not in a graph. The AXI-Stream config bus >> >> uses clear_tx_seqnum to hold itself in reset to you cannot use that >> >> either when the data-path is disabled. Do you need to use the config >> >> bus before you connect your block downstream? If so, you can try (as a >> >> debugging step) to tied the clear signal to 0 here: >> >> >> >> >> >> https://github.com/EttusResearch/fpga/blob/rfnoc-devel/usrp3/lib/rfnoc/axi_wrapper.v#L200. >> >> If that makes your block work then it would confirm that the >> >> aforementioned assumption is breaking your block. If so, we will go >> >> back re-evaluate if we need to apply the clear_tx_seqnum to just the >> >> data path and leave the control path alone. >> > >> > >> > I re-created the old strobe methodology and fed that version into >> > axi_wrapper and it fixed my issue, so it's definitely the thing that was >> > gating me. >>>> OK, so I looked though the code and clear_tx_seqnum should not be >> clearing the the config FIFO. That is the only place where it bleeds >> into the control path. The primary purpose of that signal was to clear >> the data path only. We will push the following patch into master (and >> rfnoc-devel) to remedy that issue. In the meanwhile can you check if >> that fixes your issue? You should not need to revert back to the >> strobe approach or change anything in software. >>>> diff --git a/usrp3/lib/rfnoc/axi_wrapper.v b/usrp3/lib/rfnoc/axi_wrapper.v >> index f438587..1193692 100755 >> --- a/usrp3/lib/rfnoc/axi_wrapper.v >> +++ b/usrp3/lib/rfnoc/axi_wrapper.v >> @@ -197,7 +197,7 @@ module axi_wrapper >> generate >> for (k = 0; k < NUM_AXI_CONFIG_BUS; k = k + 1) begin >> axi_fifo #(.WIDTH(33), .SIZE(CONFIG_BUS_FIFO_DEPTH)) >> config_stream >> - (.clk(clk), .reset(reset), .clear(clear_tx_seqnum), >> + (.clk(clk), .reset(reset), .clear(1'b0), >> .i_tdata({(set_addr == >> (SR_AXI_CONFIG_BASE+2*k+1)),set_data}), >> .i_tvalid(set_stb & ((set_addr == >> (SR_AXI_CONFIG_BASE+2*k))|(set_addr == (SR_AXI_CONFIG_BASE+2*k+1)))), >> .i_tready(), >>>> It bleeds over in some other places too. I had an old simple TX graph that > I was using that would write from DmaFIFO -> Radio, and that stopped > working. No little red LED to show I was transmitting and no output power. >> Looking at radio_datapath_core.v, there is an input for clear_tx and > clear_tx which both feed clear signals in the tx_control_gen3. >> Feeding the strobed version of the clear fixed the issue of no transmission > from my simple TX or my siggen block. >>>>>>> >> > The most frustrating part is that simulation does not exhibit this >> >> > behavior, >> >> > so I can't trust my simulation and have to rely on the ILA to give me >> >> > insight into these issues. >> >> >> >> The RFNOC_CONNECT macro in the simulation infrastructure is emulating >> >> the software initialization and graph connect operations atomically so >> >> you unfortunately don't see similar behavior as software. This is one >> >> of those things where we are trying to emulate software as much as >> >> possible while still trying to keep the simulation stuff lightweight, >> >> which leads to some disparity in behavior. >> > >> > >> > But it isn't doing it as much as possible, or at least not in the same >> > way >> > the C++ has it exposed. >> > >> > Is the preferred flow then: >> > >> > - Get the appropriate control and blockid's of the blocks to connect >> > - Connect all the blocks in the way they are expected to be connected >> > - Apply any argument calls to the blocks after the connect() calls >> > have >> > been made >> > - Send issue_stream_cmd() in the case of RX blocks >> > Can you write a simple C++ program which uses the Radio -> Window -> FFT >> > -> >> > Host, and uses the default window and attach it to a reply? >> > >> > In cases of TX blocks like the siggen where all setting and enabling is >> > done >> > through settings registers, is there anything special that needs to be >> > done >> > to transmit samples? >>>> As I mentioned above, you don't need to change software if you apply the >> patch. >>>> >> > Can someone tell me how clear_tx_seqnum should be working and how it >> >> > should >> >> > be used? Should it be a single strobe? Should it be a long lasting >> >> > signal? >> >> > Can I use it to indicate to my block that it should be in reset? >> >> >> >> clear_tx_seqnum used to be a single cycle strobe in the ce_clk domain >> >> but it is now a long lasting signal in the ce_clk domain. >> >> clear_tx_seqnum will be asserted for at least one clock cycle, with no >> >> upper-bound on the deassertion time. You can use it hold your control >> >> and data-path logic in a quiescent state without having to change the >> >> software-configured settings like settings reg values, etc. >> > >> > >> > I'm not sure the helpfulness of this change at all, in all honesty. >> > >> > If no packets are flowing through the block, why does the signal need to >> > be >> > asserted at all? It seems like it was used as a reset/clear in the >> > past, >> > and now it's meant as a hold? >>>> By quiescent I meant "idle between applications". It's still a >> reset/clear signal that tells noc_shell, axi_wrapper and the client >> logic to move its state machines (and any relevant registers) to the >> idle state to await packets from a new stream. In noc_shell, this >> signal resets all flow control information. In axi_wrapper it resets >> the CHDR framer and deframer. Depending on what's in the client logic >> in the noc_block, you may or may not care about this signal. For >> example, if you have a simple multiply-by-const block as the client >> logic, then the clear_tx_seqnum signal can pretty much be ignored >> because you don't care if a the next packet/sample is from a new >> stream. For an FIR filter, you do care because you need to zero out >> your accumulators when a stream is restarted. In rfnoc, we make a >> distinction between reset and clear. A "reset" is meant to reset >> everything in a module to the power-up state. A "clear" only resets >> things that are not software controlled, like settings regs. The >> expectation is that you can configure your block, clear it to re-arm >> packet processing engines, etc and still preserve the settings you >> configured. >>> Thanks for the explanation. Can you give a use case when this might happen? > Can you time division multiplex blocks in the FPGA for processing with > multiple, different streams without reconfiguring the whole flowgraph? > Under what circumstances does clear_tx_seqnum get deasserted, and where in > the stream lifecycle does that happen? I've been putting my own reset > register to strobe at the beginning of the constructor for my block. Is > this best practice? >> I'm really curious what the lifecycle of the block is supposed to be both > from a hardware/stream point of view as well as well as the concept of host > software and flowgraph lifecycle. If clear_tx_seqnum is high, should > configuration and settings changes be disallowed or allowed? >> Thanks, > Brian
_______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
