Hi EJ, On Thu, May 3, 2018 at 5:06 AM, EJ Kreinar <ejkrei...@gmail.com> wrote: > Hi Ashish, > > Thanks for the info about rfnoc changes. Quick question: > >> 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. > > Can you elaborate a little more? I understand that we want reset signal to > reset everything. But in your "cear" example, I expect that settings regs > *are* software controlled (configured via block constructor, for example), > and therefore we would not want them cleared. > > ... As I type this, I realize that is probably what you intended from the > original sentence. Is that correct??
Yes, that is correct. > Thanks! Also very interested in hearing updates from Brian's questions... I just responded. Feel free to chime in if you have any follow ups. > > EJ > > On Wed, May 2, 2018 at 7:15 PM, Brian Padalino via USRP-users > <usrp-users@lists.ettus.com> wrote: >> >> Hey Ashish, >> >> On Wed, May 2, 2018 at 7:02 PM Ashish Chaudhari >> <ashish.chaudh...@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 >> > _______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
