Thanks Brian. I think the core gets generated in a way which respects
back-pressure, so unless a TREADY is seen the core does not generate output
samples. I have observed this by simulating the core in isolation.
On 14 Sep 2022, 17:49 +0200, Brian Padalino <bpadal...@gmail.com>, wrote:
> I believe the AXI spec says that data should be presented when valid, and the
> tready signal just accepts that data. You can't rely on tready to be
> asserted before asserting tvalid.
>
> With that being said, I have no idea if this is the source of any of your
> issues.
>
> Brian
>
> > On Wed, Sep 14, 2022 at 11:28 AM Kevin Williams <zs1...@gmail.com> wrote:
> > > Hi, I don't seem to be able to get TREADY's asserted for my core in a
> > > testbench. (See the "XXXXX's" in the testbench below. The symptom is that
> > > the "recv_items" blocks until the test times out.)
> > >
> > > Without that check the "send_items" call is fine, and I can see the
> > > transaction progressing on that interface.
> > >
> > > I'm sure this is a case of me missing something?
> > >
> > > //
> > > // Copyright 2022 Ettus Research, a National Instruments Brand
> > > //
> > > // SPDX-License-Identifier: LGPL-3.0-or-later
> > > //
> > > // Module: rfnoc_block_multiddc_tb
> > > //
> > > // Description: Testbench for the multiddc RFNoC block.
> > > //
> > >
> > > `default_nettype none
> > >
> > >
> > > module rfnoc_block_multiddc_tb;
> > >
> > > `include "test_exec.svh"
> > >
> > > import PkgTestExec::*;
> > > import PkgChdrUtils::*;
> > > import PkgRfnocBlockCtrlBfm::*;
> > > import PkgRfnocItemUtils::*;
> > >
> > >
> > > //---------------------------------------------------------------------------
> > > // Testbench Configuration
> > >
> > > //---------------------------------------------------------------------------
> > >
> > > localparam [31:0] NOC_ID = 32'h951E399F;
> > > localparam [ 9:0] THIS_PORTID = 10'h123;
> > > localparam int CHDR_W = 64; // CHDR size in bits
> > > localparam int MTU = 10; // Log2 of max transmission
> > > unit in CHDR words
> > > localparam int NUM_PORTS = 1;
> > > localparam int NUM_PORTS_I = 1;
> > > localparam int NUM_PORTS_O = 5;
> > > localparam int ITEM_W = 32; // Sample size in bits
> > > localparam int SPP = 64; // Samples per packet
> > > localparam int PKT_SIZE_BYTES = SPP * (ITEM_W/8);
> > > localparam int STALL_PROB = 25; // Default BFM stall
> > > probability
> > > localparam real CHDR_CLK_PER = 5.0; // 200 MHz
> > > localparam real CTRL_CLK_PER = 8.0; // 125 MHz
> > > localparam real CE_CLK_PER = 4.0; // 250 MHz
> > >
> > >
> > > //---------------------------------------------------------------------------
> > > // Clocks and Resets
> > >
> > > //---------------------------------------------------------------------------
> > >
> > > bit rfnoc_chdr_clk;
> > > bit rfnoc_ctrl_clk;
> > > bit ce_clk;
> > >
> > > sim_clock_gen #(CHDR_CLK_PER) rfnoc_chdr_clk_gen (.clk(rfnoc_chdr_clk),
> > > .rst());
> > > sim_clock_gen #(CTRL_CLK_PER) rfnoc_ctrl_clk_gen (.clk(rfnoc_ctrl_clk),
> > > .rst());
> > > sim_clock_gen #(CE_CLK_PER) ce_clk_gen (.clk(ce_clk), .rst());
> > >
> > >
> > > //---------------------------------------------------------------------------
> > > // Bus Functional Models
> > >
> > > //---------------------------------------------------------------------------
> > >
> > > // Backend Interface
> > > RfnocBackendIf backend (rfnoc_chdr_clk, rfnoc_ctrl_clk);
> > >
> > > // AXIS-Ctrl Interface
> > > AxiStreamIf #(32) m_ctrl (rfnoc_ctrl_clk, 1'b0);
> > > AxiStreamIf #(32) s_ctrl (rfnoc_ctrl_clk, 1'b0);
> > >
> > > // AXIS-CHDR Interfaces
> > > AxiStreamIf #(CHDR_W) m_chdr [NUM_PORTS_I] (rfnoc_chdr_clk, 1'b0);
> > > AxiStreamIf #(CHDR_W) s_chdr [NUM_PORTS_O] (rfnoc_chdr_clk, 1'b0);
> > >
> > > // Block Controller BFM
> > > RfnocBlockCtrlBfm #(CHDR_W, ITEM_W) blk_ctrl = new(backend, m_ctrl,
> > > s_ctrl);
> > >
> > > // CHDR word and item/sample data types
> > > typedef ChdrData #(CHDR_W, ITEM_W)::chdr_word_t chdr_word_t;
> > > typedef ChdrData #(CHDR_W, ITEM_W)::item_t item_t;
> > >
> > > // Connect block controller to BFMs
> > > for (genvar i = 0; i < NUM_PORTS_I; i++) begin :
> > > gen_bfm_input_connections
> > > initial begin
> > > blk_ctrl.connect_master_data_port(i, m_chdr[i], PKT_SIZE_BYTES);
> > > blk_ctrl.set_master_stall_prob(i, STALL_PROB);
> > > end
> > > end
> > > for (genvar i = 0; i < NUM_PORTS_O; i++) begin :
> > > gen_bfm_output_connections
> > > initial begin
> > > blk_ctrl.connect_slave_data_port(i, s_chdr[i]);
> > > blk_ctrl.set_slave_stall_prob(i, STALL_PROB);
> > > end
> > > end
> > >
> > >
> > > //---------------------------------------------------------------------------
> > > // Device Under Test (DUT)
> > >
> > > //---------------------------------------------------------------------------
> > >
> > > // DUT Slave (Input) Port Signals
> > > logic [CHDR_W*NUM_PORTS_I-1:0] s_rfnoc_chdr_tdata;
> > > logic [ NUM_PORTS_I-1:0] s_rfnoc_chdr_tlast;
> > > logic [ NUM_PORTS_I-1:0] s_rfnoc_chdr_tvalid;
> > > logic [ NUM_PORTS_I-1:0] s_rfnoc_chdr_tready;
> > >
> > > // DUT Master (Output) Port Signals
> > > logic [CHDR_W*NUM_PORTS_O-1:0] m_rfnoc_chdr_tdata;
> > > logic [ NUM_PORTS_O-1:0] m_rfnoc_chdr_tlast;
> > > logic [ NUM_PORTS_O-1:0] m_rfnoc_chdr_tvalid;
> > > logic [ NUM_PORTS_O-1:0] m_rfnoc_chdr_tready;
> > >
> > > // Map the array of BFMs to a flat vector for the DUT connections
> > > for (genvar i = 0; i < NUM_PORTS_I; i++) begin :
> > > gen_dut_input_connections
> > > // Connect BFM master to DUT slave port
> > > assign s_rfnoc_chdr_tdata[CHDR_W*i+:CHDR_W] = m_chdr[i].tdata;
> > > assign s_rfnoc_chdr_tlast[i] = m_chdr[i].tlast;
> > > assign s_rfnoc_chdr_tvalid[i] = m_chdr[i].tvalid;
> > > assign m_chdr[i].tready = s_rfnoc_chdr_tready[i];
> > > end
> > > for (genvar i = 0; i < NUM_PORTS_O; i++) begin :
> > > gen_dut_output_connections
> > > // Connect BFM slave to DUT master port
> > > assign s_chdr[i].tdata = m_rfnoc_chdr_tdata[CHDR_W*i+:CHDR_W];
> > > assign s_chdr[i].tlast = m_rfnoc_chdr_tlast[i];
> > > assign s_chdr[i].tvalid = m_rfnoc_chdr_tvalid[i];
> > > assign m_rfnoc_chdr_tready[i] = s_chdr[i].tready;
> > > end
> > >
> > > rfnoc_block_multiddc #(
> > > .THIS_PORTID (THIS_PORTID),
> > > .CHDR_W (CHDR_W),
> > > .MTU (MTU),
> > > .NUM_PORTS (NUM_PORTS)
> > > ) dut (
> > > // .rfnoc_chdr_clk (rfnoc_chdr_clk),
> > > // .rfnoc_ctrl_clk (rfnoc_ctrl_clk),
> > > .rfnoc_chdr_clk (backend.chdr_clk),
> > > .rfnoc_ctrl_clk (backend.ctrl_clk),
> > > .ce_clk (ce_clk),
> > > .rfnoc_core_config (backend.cfg),
> > > .rfnoc_core_status (backend.sts),
> > > .s_rfnoc_chdr_tdata (s_rfnoc_chdr_tdata),
> > > .s_rfnoc_chdr_tlast (s_rfnoc_chdr_tlast),
> > > .s_rfnoc_chdr_tvalid (s_rfnoc_chdr_tvalid),
> > > .s_rfnoc_chdr_tready (s_rfnoc_chdr_tready),
> > > .m_rfnoc_chdr_tdata (m_rfnoc_chdr_tdata),
> > > .m_rfnoc_chdr_tlast (m_rfnoc_chdr_tlast),
> > > .m_rfnoc_chdr_tvalid (m_rfnoc_chdr_tvalid),
> > > .m_rfnoc_chdr_tready (m_rfnoc_chdr_tready),
> > > .s_rfnoc_ctrl_tdata (m_ctrl.tdata),
> > > .s_rfnoc_ctrl_tlast (m_ctrl.tlast),
> > > .s_rfnoc_ctrl_tvalid (m_ctrl.tvalid),
> > > .s_rfnoc_ctrl_tready (m_ctrl.tready),
> > > .m_rfnoc_ctrl_tdata (s_ctrl.tdata),
> > > .m_rfnoc_ctrl_tlast (s_ctrl.tlast),
> > > .m_rfnoc_ctrl_tvalid (s_ctrl.tvalid),
> > > .m_rfnoc_ctrl_tready (s_ctrl.tready)
> > > );
> > >
> > > // Generate a random signed 16-bit integer in the range [a, b]
> > > function shortint rand_shortint(int a, int b);
> > > return signed'($urandom_range(b - a)) + a;
> > > endfunction : rand_shortint
> > >
> > >
> > > //---------------------------------------------------------------------------
> > > // Main Test Process
> > >
> > > //---------------------------------------------------------------------------
> > >
> > > initial begin : tb_main
> > >
> > > $monitor($time, " s_rfnoc_chdr_tdata='b%b", s_rfnoc_chdr_tdata);
> > > $monitor($time, " s_rfnoc_chdr_tvalid='%d", s_rfnoc_chdr_tvalid);
> > > $monitor($time, " s_rfnoc_chdr_tready='%d", s_rfnoc_chdr_tready);
> > > $monitor($time, " s_rfnoc_chdr_tlast='%d", s_rfnoc_chdr_tlast);
> > >
> > > $monitor($time, " m_rfnoc_chdr_tdata='b%b", m_rfnoc_chdr_tdata);
> > > $monitor($time, " m_rfnoc_chdr_tvalid='b%b", m_rfnoc_chdr_tvalid);
> > > $monitor($time, " m_rfnoc_chdr_tready='b%b", m_rfnoc_chdr_tready);
> > >
> > > // Initialize the test exec object for this testbench
> > > test.start_tb("rfnoc_block_multiddc_tb");
> > >
> > > // Start the BFMs running
> > > blk_ctrl.run();
> > >
> > > //--------------------------------
> > > // Reset
> > > //--------------------------------
> > >
> > > test.start_test("Flush block then reset it", 10us);
> > > blk_ctrl.flush_and_reset();
> > > test.end_test();
> > >
> > > // Start the clocks running. We wait to start them until this
> > > testbench
> > > // runs because we don't want to waste the simulator's CPU time by
> > > // simulating idle clock cycles.
> > > rfnoc_chdr_clk_gen.start();
> > > rfnoc_ctrl_clk_gen.start();
> > > ce_clk_gen.start();
> > >
> > > //--------------------------------
> > > // Verify Block Info
> > > //--------------------------------
> > >
> > > test.start_test("Verify Block Info", 2us);
> > > `ASSERT_ERROR(blk_ctrl.get_noc_id() == NOC_ID, "Incorrect NOC_ID
> > > Value");
> > > `ASSERT_ERROR(blk_ctrl.get_num_data_i() == NUM_PORTS_I, "Incorrect
> > > NUM_DATA_I Value");
> > > `ASSERT_ERROR(blk_ctrl.get_num_data_o() == NUM_PORTS_O, "Incorrect
> > > NUM_DATA_O Value");
> > > `ASSERT_ERROR(blk_ctrl.get_mtu() == MTU, "Incorrect MTU Value");
> > > test.end_test();
> > >
> > > test.start_test("Verify Slave TREADY", 2us);
> > > `ASSERT_ERROR(s_rfnoc_chdr_tready == 1'b1, "Slave TREADY is not 1");
> > > test.end_test();
> > >
> > > //--------------------------------
> > > // Test Sequences
> > > //--------------------------------
> > >
> > > // begin
> > > // // Read and write the gain register to make sure it updates
> > > correctly.
> > > // logic [31:0] val32;
> > > // test.start_test("Verify a register", 5us);
> > >
> > > // blk_ctrl.reg_read(256, val32);
> > > // `ASSERT_ERROR(
> > > // val32 == 0, "Initial value for 0x100 is not 0");
> > >
> > > // // Write a value wider than the register to verify the width
> > > // blk_ctrl.reg_write(256, 32'h12348765);
> > > // blk_ctrl.reg_read(256, val32);
> > > // `ASSERT_ERROR(
> > > // val32 == 32'h8765, "Readback value for 0x100 is not correct");
> > >
> > > // test.end_test();
> > > // end
> > >
> > > // <Add your test code here>
> > > // test.start_test("<Name your first test>", 100us);
> > > // `ASSERT_WARNING(0, "This testbench doesn't test anything yet!");
> > > // test.end_test();
> > >
> > > begin
> > > localparam shortint MAX_TEST_VAL = 255;
> > > localparam shortint MIN_TEST_VAL = -255;
> > >
> > > packet_info_t pkt_info;
> > >
> > > item_t send_samples[$]; // Sample words
> > > item_t recv_samples[$]; // Sample words
> > >
> > > // Read and write the gain register to make sure it updates
> > > correctly.
> > > test.start_test("Check data flows through multiddc", 40us);
> > >
> > > // Generate a payload of random samples in the range [-255, 255],
> > > two
> > > // samples per CHDR word.
> > > send_samples = {};
> > > for (int i = 0; i < SPP; i++) begin
> > > send_samples.push_back({
> > > // rand_shortint(MIN_TEST_VAL, MAX_TEST_VAL), // I
> > > // rand_shortint(MIN_TEST_VAL, MAX_TEST_VAL) // Q
> > > 16'hff,
> > > 16'hff
> > > });
> > > end
> > >
> > > // check that dut is ready to receive
> > > `ASSERT_ERROR(s_rfnoc_chdr_tready == 1'b1, "Slave TREADY is not
> > > 1");
> > >
> > > // wait for slaves to assert TREADY
> > > //
> > > XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
> > > $display("Waiting for TREADY on the BFM slave...");
> > > wait(m_rfnoc_chdr_tready != 5'b00000) $display($time, "
> > > m_rfnoc_chdr_tready='b%b", m_rfnoc_chdr_tready);
> > > //
> > > XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
> > >
> > > // check sinks are asserting TREADY
> > > $display($time, " m_rfnoc_chdr_tready='b%b", m_rfnoc_chdr_tready);
> > >
> > > // model some back-pressure if needed
> > > blk_ctrl.set_slave_stall_prob(0, 0);
> > >
> > > // Queue a packet for transfer
> > > // pkt_info = 0;
> > > // pkt_info.eob = 1;
> > > // blk_ctrl.send_items(0, send_samples, , pkt_info);
> > > blk_ctrl.send_items(0, send_samples);
> > > blk_ctrl.wait_complete(0);
> > >
> > > $display($time, "Send complete");
> > >
> > > $display($time, " TX Size='%d", send_samples.size());
> > >
> > > // Receive the output packet
> > > blk_ctrl.recv_items(0, recv_samples);
> > >
> > > // Check the resulting payload size
> > > `ASSERT_ERROR(recv_samples.size() == SPP,
> > > "Received payload didn't match size of payload sent");
> > >
> > > test.end_test();
> > > end
> > >
> > > //--------------------------------
> > > // Finish Up
> > > //--------------------------------
> > >
> > > // Display final statistics and results
> > > test.end_tb();
> > > end : tb_main
> > >
> > > endmodule : rfnoc_block_multiddc_tb
> > >
> > >
> > > `default_nettype wire
> > >
> > > > On Wed, 14 Sept 2022 at 12:30, Kevin Williams <zs1...@gmail.com> wrote:
> > > > > Hi Rob, thanks for that testbench advice.
> > > > >
> > > > > My core will not provide output if it does not see TREADY on its
> > > > > master interfaces. (Which I have verified by simulating the core on
> > > > > its own.)
> > > > >
> > > > > I have used the rfnoc-example testbench for reference, and issue a
> > > > > "blk_ctrl.send_items(0, send_samples)".
> > > > >
> > > > > Monitoring the rfnoc signal "m_rfnoc_chdr_tready" in the testbench
> > > > > shows that it never transitions from zero's at the beginning of the
> > > > > simulation.
> > > > >
> > > > > Should I see the BFM slave asserting these signals? (I cannot drive
> > > > > them from my testbench - I get a warning about multiple drivers.)
> > > > >
> > > > > > On Tue, 13 Sept 2022 at 15:49, Rob Kossler <rkoss...@nd.edu> wrote:
> > > > > > > Have you tried to run an rfnoc-style testbench such as in the
> > > > > > > rfnoc-example? If not, this may be useful. If you try this, it
> > > > > > > may be easier to follow the example if you change your output
> > > > > > > number of ports to be 1 so that it is a simple 1-to-1 block.
> > > > > > > Rob
> > > > > > >
> > > > > > > > On Tue, Sep 13, 2022 at 6:36 AM Kevin Williams
> > > > > > > > <zs1...@gmail.com> wrote:
> > > > > > > > > Hi Rob,
> > > > > > > > >
> > > > > > > > > I can confirm the radio streams correctly.
> > > > > > > > >
> > > > > > > > > I have also tried tx_streamer => multiDDC => rx_streamer
> > > > > > > > > which successfully sends a number of samples, but none are
> > > > > > > > > received. (The script is below.)
> > > > > > > > >
> > > > > > > > > Just to summarize, the IP core seems to be behaving correctly
> > > > > > > > > when simulated in Vivado where I apply AXI handshaking, reset
> > > > > > > > > the core, and clock it.
> > > > > > > > >
> > > > > > > > > I have set all endpoints in the design as follows:
> > > > > > > > >
> > > > > > > > > ep0: # Stream endpoint name
> > > > > > > > > ctrl: True # Endpoint passes control
> > > > > > > > > traffic
> > > > > > > > > data: True # Endpoint passes data
> > > > > > > > > traffic
> > > > > > > > > buff_size: 32768 # Ingress buffer size for
> > > > > > > > > data
> > > > > > > > >
> > > > > > > > > Regards, Kevin
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > graph = uhd.rfnoc.RfnocGraph("type=x300,addr=192.168.30.2")
> > > > > > > > >
> > > > > > > > > tx_streamer = graph.create_tx_streamer(1,
> > > > > > > > > uhd.usrp.StreamArgs("sc16", "sc16"))
> > > > > > > > > rx_streamer = graph.create_rx_streamer(1,
> > > > > > > > > uhd.usrp.StreamArgs("sc16", "sc16"))
> > > > > > > > >
> > > > > > > > > gb = graph.get_block("0/multiddc#0")
> > > > > > > > > graph.connect(tx_streamer, 0, gb.get_unique_id(), 0)
> > > > > > > > > graph.connect(gb.get_unique_id(), 0, rx_streamer, 0)
> > > > > > > > > graph.commit()
> > > > > > > > >
> > > > > > > > > num_samps = 4 * tx_streamer.get_max_num_samps()
> > > > > > > > > send_samps = np.array([[0x40004000] * num_samps],
> > > > > > > > > dtype="int32")
> > > > > > > > >
> > > > > > > > > tx_md = uhd.types.TXMetadata()
> > > > > > > > > tx_md.start_of_burst = True
> > > > > > > > > tx_md.end_of_burst = True
> > > > > > > > >
> > > > > > > > > recv_samps = np.zeros((1, num_samps), dtype="int32")
> > > > > > > > >
> > > > > > > > > rx_md = uhd.types.RXMetadata()
> > > > > > > > >
> > > > > > > > > num_sent = tx_streamer.send(send_samps,
> > > > > > > > > uhd.types.TXMetadata())
> > > > > > > > > num_recv = rx_streamer.recv(recv_samps, rx_md, 0.1)
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > > On Tue, 13 Sept 2022 at 00:36, Rob Kossler
> > > > > > > > > > <rkoss...@nd.edu> wrote:
> > > > > > > > > > > One more thought. If the FPGA version that you built with
> > > > > > > > > > > dynamic linking, you should be able to create an RFNoC
> > > > > > > > > > > Graph as follows:
> > > > > > > > > > > tx_streamer => multiDDC => rx_streamer(s)
> > > > > > > > > > > This way you can eliminate the radio from the equation
> > > > > > > > > > > and test in a very similar fashion to the way it is
> > > > > > > > > > > tested in a testbench.
> > > > > > > > > > >
> > > > > > > > > > > Rob
> > > > > > > > > > >
> > > > > > > > > > > > On Mon, Sep 12, 2022 at 6:33 PM Rob Kossler
> > > > > > > > > > > > <rkoss...@nd.edu> wrote:
> > > > > > > > > > > > > Oops. Ignore what I said. I now realize you stated
> > > > > > > > > > > > > you were getting an Overflow which of course you
> > > > > > > > > > > > > would never get if streaming hadn't started.
> > > > > > > > > > > > > Rob
> > > > > > > > > > > > >
> > > > > > > > > > > > > > On Mon, Sep 12, 2022 at 6:32 PM Rob Kossler
> > > > > > > > > > > > > > <rkoss...@nd.edu> wrote:
> > > > > > > > > > > > > > > Are you sure that the radio is even streaming?
> > > > > > > > > > > > > > > The typical method for starting streaming is to
> > > > > > > > > > > > > > > tell the rx_streamer to start streaming. Then,
> > > > > > > > > > > > > > > in UHD-land, the rx_streamer ctrl tells the next
> > > > > > > > > > > > > > > upstring block to start streaming such that this
> > > > > > > > > > > > > > > streaming command propagates up the chain until
> > > > > > > > > > > > > > > the radio receives it and starts streaming. So,
> > > > > > > > > > > > > > > if your custom block does not forward the
> > > > > > > > > > > > > > > streaming command from the rx_streamer to the
> > > > > > > > > > > > > > > radio, then the radio never even starts
> > > > > > > > > > > > > > > streaming. You can verify by simply monitoring
> > > > > > > > > > > > > > > the LEDs.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > If this is the problem, you can go-around the
> > > > > > > > > > > > > > > intended use by simply telling the radio to start
> > > > > > > > > > > > > > > streaming rather than the rx_streamer. Or, of
> > > > > > > > > > > > > > > course, you can modify your custom block
> > > > > > > > > > > > > > > controller to propagate the streaming command.
> > > > > > > > > > > > > > > Rob
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > On Mon, Sep 12, 2022 at 4:18 PM Kevin Williams
> > > > > > > > > > > > > > > > <zs1...@gmail.com> wrote:
> > > > > > > > > > > > > > > > > Yes, of course. But I don't get 1 sample from
> > > > > > > > > > > > > > > > > the ddc's, even with just one channel of a
> > > > > > > > > > > > > > > > > 2:1 decimated channel connected to the rx
> > > > > > > > > > > > > > > > > streamer.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > On Mon, 12 Sept 2022 at 22:13, Jonathon
> > > > > > > > > > > > > > > > > > Pendlum <jonathon.pend...@ettus.com> wrote:
> > > > > > > > > > > > > > > > > > > The aggregate output rate of the 5
> > > > > > > > > > > > > > > > > > > streams could require more bandwidth than
> > > > > > > > > > > > > > > > > > > the 10 GigE interface can sustain. What
> > > > > > > > > > > > > > > > > > > are the exact output rates?
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > On Mon, Sep 12, 2022 at 3:53 PM Kevin
> > > > > > > > > > > > > > > > > > > > Williams <zs1...@gmail.com> wrote:
> > > > > > > > > > > > > > > > > > > > > Those rates vary from a 2:1
> > > > > > > > > > > > > > > > > > > > > decimation down to other rates.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > The host has 10 Gbe interfaces to the
> > > > > > > > > > > > > > > > > > > > > USRP.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > I get samples if i connect the radio
> > > > > > > > > > > > > > > > > > > > > to the rx streamer, just nothing from
> > > > > > > > > > > > > > > > > > > > > the ddc's.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > On Mon, 12 Sept 2022 at 21:48,
> > > > > > > > > > > > > > > > > > > > > > Jonathon Pendlum
> > > > > > > > > > > > > > > > > > > > > > <jonathon.pend...@ettus.com> wrote:
> > > > > > > > > > > > > > > > > > > > > > > Hi Kevin,
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > What are the sample rates for the
> > > > > > > > > > > > > > > > > > > > > > > 5 outputs? What connection are
> > > > > > > > > > > > > > > > > > > > > > > you using to your host PC, 1 GigE
> > > > > > > > > > > > > > > > > > > > > > > or 10 GigE?
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > Jonathon
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > On Mon, Sep 12, 2022 at 3:38 PM
> > > > > > > > > > > > > > > > > > > > > > > > Kevin Williams
> > > > > > > > > > > > > > > > > > > > > > > > <zs1...@gmail.com> wrote:
> > > > > > > > > > > > > > > > > > > > > > > > > Hi Jonathon,
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > I've got an x310. The
> > > > > > > > > > > > > > > > > > > > > > > > > flowgraph is a simple
> > > > > > > > > > > > > > > > > > > > > > > > > radio->multiddc->(to 5x
> > > > > > > > > > > > > > > > > > > > > > > > > outputs). I've tried both
> > > > > > > > > > > > > > > > > > > > > > > > > static and dynamic routing
> > > > > > > > > > > > > > > > > > > > > > > > > from the radio block. I.e.
> > > > > > > > > > > > > > > > > > > > > > > > > the static route version:
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > | /
> > > > > > > > > > > > > > > > > > > > > > > > > | | Static
> > > > > > > > > > > > > > > > > > > > > > > > > connections on this device:
> > > > > > > > > > > > > > > > > > > > > > > > > | |
> > > > > > > > > > > > > > > > > > > > > > > > > | | *
> > > > > > > > > > > > > > > > > > > > > > > > > 0/Radio#0:0==>0/multiddc#0:0
> > > > > > > > > > > > > > > > > > > > > > > > > | | *
> > > > > > > > > > > > > > > > > > > > > > > > > 0/multiddc#0:0==>0/SEP#2:0
> > > > > > > > > > > > > > > > > > > > > > > > > | | *
> > > > > > > > > > > > > > > > > > > > > > > > > 0/multiddc#0:1==>0/SEP#3:0
> > > > > > > > > > > > > > > > > > > > > > > > > | | *
> > > > > > > > > > > > > > > > > > > > > > > > > 0/multiddc#0:2==>0/SEP#4:0
> > > > > > > > > > > > > > > > > > > > > > > > > | | *
> > > > > > > > > > > > > > > > > > > > > > > > > 0/multiddc#0:3==>0/SEP#5:0
> > > > > > > > > > > > > > > > > > > > > > > > > | | *
> > > > > > > > > > > > > > > > > > > > > > > > > 0/multiddc#0:4==>0/SEP#6:0
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > On the input side it is all
> > > > > > > > > > > > > > > > > > > > > > > > > at the radio rate, but I hope
> > > > > > > > > > > > > > > > > > > > > > > > > my core is being clocked at
> > > > > > > > > > > > > > > > > > > > > > > > > 214 MHz.
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > When I simulate my IP core
> > > > > > > > > > > > > > > > > > > > > > > > > (which includes the AXI
> > > > > > > > > > > > > > > > > > > > > > > > > streaming interfaces) it
> > > > > > > > > > > > > > > > > > > > > > > > > looks ok.
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > Regards, Kevin
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > On Mon, 12 Sept 2022 at
> > > > > > > > > > > > > > > > > > > > > > > > > > 21:29, Jonathon Pendlum
> > > > > > > > > > > > > > > > > > > > > > > > > > <jonathon.pend...@ettus.com>
> > > > > > > > > > > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > > > > > > > > > > Hello Kevin,
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > What device are you using
> > > > > > > > > > > > > > > > > > > > > > > > > > > and what does your
> > > > > > > > > > > > > > > > > > > > > > > > > > > flowgraph look like? What
> > > > > > > > > > > > > > > > > > > > > > > > > > > sample rate are you
> > > > > > > > > > > > > > > > > > > > > > > > > > > running at? If your block
> > > > > > > > > > > > > > > > > > > > > > > > > > > is running at the radio
> > > > > > > > > > > > > > > > > > > > > > > > > > > sample rate (e.g. 200
> > > > > > > > > > > > > > > > > > > > > > > > > > > MSPS on a X310), your
> > > > > > > > > > > > > > > > > > > > > > > > > > > block will need to
> > > > > > > > > > > > > > > > > > > > > > > > > > > process one input sample
> > > > > > > > > > > > > > > > > > > > > > > > > > > every clock cycle on
> > > > > > > > > > > > > > > > > > > > > > > > > > > average.
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > Jonathon
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > On Mon, Sep 12, 2022 at
> > > > > > > > > > > > > > > > > > > > > > > > > > > > 9:09 AM Kevin Williams
> > > > > > > > > > > > > > > > > > > > > > > > > > > > <zs1...@gmail.com>
> > > > > > > > > > > > > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi All,
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > I've got an IP core
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > that is causing an
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > "ERROR_CODE_OVERFLOW"
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > when used in an RFNoC
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > project.
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > The core responds
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > correctly when
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > simulated outside the
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > RFNoC environment. (I
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > can see correct
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > output, the AXI
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > streaming signalling,
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > back-pressure when
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > required, etc.)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > I'm not sure how to
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > go about debugging
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > this, and am not yet
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > familiar enough with
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > RFNoC to know what to
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > ask.
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > I have been thinking
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > it was the core not
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > being reset or
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > clocked correctly,
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > but this is how it
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > gets instantiated:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > multiddc multiddc_i
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > (
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > // - Using
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > different clocks for
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > the IP core and the
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > AXI interface. The
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > IPCore_Clk and
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > AXILite_ACLK must be
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > //
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > synchronous and
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > connected to the same
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > clock source. The
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > IPCore_RESETN and
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > AXILite_ARESETN must
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > be
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > // connected
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > to the same reset
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > source. See
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > Synchronization of
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > Global Reset Signal
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > to IP Core Clock
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > Domain.
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > .IPCORE_CLK
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > (axis_data_clk),
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > .IPCORE_RESETN
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > (~axis_data_rst),
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > .AXI4_Lite_ACLK
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > (axis_data_clk),
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > .AXI4_Lite_ARESETN
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > (~axis_data_rst),
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > The core YAML file
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > describes the clock
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > as:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > data:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > fpga_iface:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > axis_chdr
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > clk_domain: ce
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > In the project YAML
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > file:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > clk_domains:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > - { srcblk:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > _device_, srcport:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > radio, dstblk:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > radio0, dstport:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > radio }
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > - { srcblk:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > _device_, srcport:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > ce, dstblk:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > multiddc0, dstport:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > ce }
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > Is there something
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > that might be an
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > obvious first place
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > to check?
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > Many thanks, Kevin
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > --
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > Kevin Williams
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > USRP-users mailing
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > list --
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > usrp-users@lists.ettus.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > To unsubscribe send
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > an email to
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > usrp-users-le...@lists.ettus.com
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > --
> > > > > > > > > > > > > > > > > > > > > > > > > Kevin Williams
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > --
> > > > > > > > > > > > > > > > > > > > > Kevin Williams
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > --
> > > > > > > > > > > > > > > > > Kevin Williams
> > > > > > > > > > > > > > > > > _______________________________________________
> > > > > > > > > > > > > > > > > USRP-users mailing list --
> > > > > > > > > > > > > > > > > usrp-users@lists.ettus.com
> > > > > > > > > > > > > > > > > To unsubscribe send an email to
> > > > > > > > > > > > > > > > > usrp-users-le...@lists.ettus.com
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > > Kevin Williams
> > > > >
> > > > >
> > > > > --
> > > > > Kevin Williams
> > >
> > >
> > > --
> > > Kevin Williams
> > > _______________________________________________
> > > USRP-users mailing list -- usrp-users@lists.ettus.com
> > > To unsubscribe send an email to usrp-users-le...@lists.ettus.com
_______________________________________________
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com
