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(),


>> > 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.

-- Ashish

_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Reply via email to