Hi Ashish, Awesome! Thanks for clarifying.
Just a thought here... >If you download an FPGA image, run flow >graph A, then without reloading the image you want to run flow graph B >with a different topology then the clear signal will ensure that >things are cleaned up properly between A and B. Do you really have to >switch applications to reconfigure the topology? In theory, no, but we >have some work to do on the graph resolution side in software to allow >changing the topology on the fly. That feature isn't as high a >priority because it is simple enough to just tear down and recreate >the graph/device3 in UHD. I'm not "here" yet, but I (eventually) have a requirement to run rfnoc applications independently and simultaneously on an N310-like device. For example: initialize one gnuradio application attached to one of the noc_block_radios (basically tb.start()) , and then reconfigure a few of the unused rfnoc blocks to bring up and down *different* gnuradio applications using the second noc_block_radio and likely other noc_blocks, while the first application is still streaming. It looks to me like the fundamental fpga architecture should be able to run this sort of application, but are you saying the current "clear" operations in software will get in the way as-is? If so, I will be happy to help work on this feature in the next 1-6 months. Thanks!! EJ On Thu, May 3, 2018, 7:28 PM Ashish Chaudhari <ashish.chaudh...@ettus.com> wrote: > 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
