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
