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