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
