Dario,
Glad simulation appears to be working.
Since you aren't using simple mode in the AXI wrapper (I assume because
you're rate-changing inside the block, or some such) can you post the
section of your code which handles the VITA headers?
Nick
On Tue, Sep 26, 2017 at 5:15 AM Dario Pennisi <da...@iptronix.com> wrote:
> Hi,
>
> I managed to get a good simulation for the two inputs. I did it by
> modifying default test bench this way:
>
> - localparam NUM_STREAMS = 2; // Number of test bench streams
> - modified RFNOC_CONNECT to two RFNOC_CONNECT_BLOCK_PORT calls each
> with a different port. Port 0 of TB connected to port 0 of DUT and port 1
> of TB connected to port 1 of DUT
> - modified data streaming part with two calls to tb_streamer.send each
> with a different channel
>
>
>
> this way I can see data being pumped in on both ports, at least in
> simulation. IP does what it should so at this point I tend to think there
> is no issue on the FPGA side.
>
>
>
> Since I am connecting to two radio blocks and since internal bus is 166
> MHz/64 bit I modified the device3 arguments to "master_clock_rate=120e6",
> this way I would have 120MSPS at 32 bit x 2 muxed on the input bus of the
> IP. This should leave enough room for overhead.
>
>
>
> Now. In these conditions I still don’t see data coming from the second
> channel so am thinking that the issue must be on the software side.
>
>
>
> Any help would be greatly appreciated.
>
> Thanks,
>
>
>
> Dario Pennisi
>
> *From:* Dario Pennisi
> *Sent:* Tuesday, September 26, 2017 12:00 PM
>
>
> *To:* usrp-users@lists.ettus.com; Nick Foster <bistrom...@gmail.com>
>
> *Subject:* RE: [USRP-users] rfnoc block with two inputs
>
>
>
> Hi,
>
> I moved forward a bit but didn’t really come up to a solution.
>
> In my block I doublechecked the signals which are replicated for each
> input and made sure they are connected at top level. This turned out to be
> apparently useless because I only have one output so src_sid and dst_sid
> for the second input channel are basically not going anywhere as there is
> no second output.
>
> Is it at all possible to have 2 inputs and 1 output or there is a strict
> need to have the same number of inputs and outputs?
>
> On the host side which are the points I can tap into to check what’s going
> on?
>
>
>
> I also would be interested in trying simulation but didn’t find any
> example of simulation with 2 inputs.
>
> Thanks,
>
>
>
> Dario Pennisi
>
> *From:* Dario Pennisi
> *Sent:* Monday, September 25, 2017 11:11 PM
> *To:* usrp-users@lists.ettus.com; Nick Foster <bistrom...@gmail.com>
> *Subject:* Re: [USRP-users] rfnoc block with two inputs
>
>
>
> Hi Nick,
>
> Thank you for your feedback. I didn't notice src and data Sid are per
> input however looking at code I don't think this is the problem. My
> understanding is that src Sid is used to form cvita packet going out of the
> block. In simple mode axis wrapper doesn't seem to use while it is used by
> cvita encoder used for tuser. In my case I have 2 inputs and 1 output. I am
> using Sid form channel 0 to create cvita header for the output.
>
> Since I don't have a second output it seems to me src and day Sid for 2nd
> input are not used anyway...
>
> For the rest there doesn't seem to be any other connection.
>
> Am I missing something?
>
> Btw is there any example of a block with 2 in and 1 out? I found only
> addsub which has 2 out and is not even using axis wrapper...
>
> Thanks
>
> Dario Pennisi
>
>
>
>
>
>
>
> On Mon, Sep 25, 2017 at 9:28 PM +0200, "Nick Foster" <bistrom...@gmail.com>
> wrote:
>
> Couple of problems just offhand.
>
>
>
> * src_sid is a one-per-input signal. See noc_shell.v for details.
>
> * Settings buses and readback buses are one-per (max(input, output)).
> Again, see noc_shell.v. I don't think this is a problem for you, though.
>
>
>
> You should be getting errors in simulation (or warnings in synthesis)
> right now. Look very carefully through these warnings to see which signals
> are undriven. My guess is src_sid is undriven on the top 16 bits and so you
> can't set src_sid correctly for input 1.
>
>
>
> Nick
>
>
>
> On Mon, Sep 25, 2017 at 12:00 PM Dario Pennisi <da...@iptronix.com> wrote:
>
> Hi,
>
> It’s quite complex and long… posting the initial part with shell and
> wrappers
>
>
>
> module noc_block_demod #(
>
> parameter NOC_ID = 64'h1408E12980FDE75E,
>
> parameter MAX_PACKET_SIZE = 64)
>
> (
>
> input bus_clk, input bus_rst,
>
> input ce_clk, input ce_rst,
>
> input [63:0] i_tdata, input i_tlast, input i_tvalid, output i_tready,
>
> output [63:0] o_tdata, output o_tlast, output o_tvalid, input o_tready,
>
> output [63:0] debug
>
> );
>
>
>
> ////////////////////////////////////////////////////////////
>
> //
>
> // RFNoC Shell
>
> //
>
> ////////////////////////////////////////////////////////////
>
> wire [31:0] set_data;
>
> wire [7:0] set_addr;
>
> wire set_stb;
>
> reg rb_stb;
>
> reg [63:0] rb_data;
>
> wire [7:0] rb_addr;
>
>
>
> wire [63:0] cmdout_tdata, ackin_tdata;
>
> wire cmdout_tlast, cmdout_tvalid, cmdout_tready, ackin_tlast,
> ackin_tvalid, ackin_tready;
>
>
>
> wire [2*64-1:0] str_sink_tdata;
>
> wire [1:0] str_sink_tlast, str_sink_tvalid, str_sink_tready;
>
>
>
> wire [63:0] str_src_tdata;
>
> wire str_src_tlast, str_src_tvalid, str_src_tready;
>
>
>
> wire [15:0] src_sid;
>
> wire [15:0] next_dst_sid, resp_out_dst_sid;
>
> wire [15:0] resp_in_dst_sid;
>
>
>
> wire clear_tx_seqnum;
>
>
>
> noc_shell #(
>
> .NOC_ID(NOC_ID),
>
> .INPUT_PORTS(2)
>
> )
>
> noc_shell (
>
> .bus_clk(bus_clk), .bus_rst(bus_rst),
>
> .i_tdata(i_tdata), .i_tlast(i_tlast), .i_tvalid(i_tvalid),
> .i_tready(i_tready),
>
> .o_tdata(o_tdata), .o_tlast(o_tlast), .o_tvalid(o_tvalid),
> .o_tready(o_tready),
>
> // Computer Engine Clock Domain
>
> .clk(ce_clk), .reset(ce_rst),
>
> // Control Sink
>
> .set_data(set_data), .set_addr(set_addr), .set_stb(set_stb),
>
> .rb_stb(rb_stb), .rb_data(rb_data), .rb_addr(rb_addr),
>
> // Control Source
>
> .cmdout_tdata(cmdout_tdata), .cmdout_tlast(cmdout_tlast),
> .cmdout_tvalid(cmdout_tvalid), .cmdout_tready(cmdout_tready),
>
> .ackin_tdata(ackin_tdata), .ackin_tlast(ackin_tlast),
> .ackin_tvalid(ackin_tvalid), .ackin_tready(ackin_tready),
>
> // Stream Sink
>
> .str_sink_tdata(str_sink_tdata), .str_sink_tlast(str_sink_tlast),
> .str_sink_tvalid(str_sink_tvalid), .str_sink_tready(str_sink_tready),
>
> // Stream Source
>
> .str_src_tdata(str_src_tdata), .str_src_tlast(str_src_tlast),
> .str_src_tvalid(str_src_tvalid), .str_src_tready(str_src_tready),
>
> // Stream IDs set by host
>
> .src_sid(src_sid), // SID of this block
>
> .next_dst_sid(next_dst_sid), // Next destination SID
>
> .resp_in_dst_sid(resp_in_dst_sid), // Response destination SID for
> input stream responses / errors
>
> .resp_out_dst_sid(resp_out_dst_sid), // Response destination SID for
> output stream responses / errors
>
> // Misc
>
> .vita_time('d0), .clear_tx_seqnum(clear_tx_seqnum),
>
> .debug(debug));
>
>
>
> ////////////////////////////////////////////////////////////
>
> //
>
> // AXI Wrapper
>
> // Convert RFNoC Shell interface into AXI stream interface
>
> //
>
> ////////////////////////////////////////////////////////////
>
> wire [31:0] m_axis0_data_tdata;
>
> wire m_axis0_data_tlast;
>
> wire m_axis0_data_tvalid;
>
> wire m_axis0_data_tready;
>
> wire [127:0] m_axis0_data_tuser;
>
>
>
> wire [31:0] m_axis1_data_tdata;
>
> wire m_axis1_data_tlast;
>
> wire m_axis1_data_tvalid;
>
> wire m_axis1_data_tready;
>
> wire [127:0] m_axis1_data_tuser;
>
>
>
> wire [31:0] s_axis0_data_tdata;
>
> wire s_axis0_data_tlast;
>
> wire s_axis0_data_tvalid;
>
> wire s_axis0_data_tready;
>
> wire [127:0] s_axis0_data_tuser;
>
>
>
> wire [31:0] s_axis1_data_tdata;
>
> wire s_axis1_data_tlast;
>
> wire s_axis1_data_tvalid;
>
> wire s_axis1_data_tready;
>
> wire [127:0] s_axis1_data_tuser;
>
> wire [63:0] vita_time_in;
>
> wire [63:0] vita_time_out;
>
> // reg [11:0] seq_num;
>
>
>
> axi_wrapper #(
>
> .SIMPLE_MODE(0))
>
> axi_wrapper0 (
>
> .clk(ce_clk), .reset(ce_rst),
>
> .clear_tx_seqnum(clear_tx_seqnum),
>
> .next_dst(next_dst_sid),
>
> .set_stb(set_stb), .set_addr(set_addr), .set_data(set_data),
>
> .i_tdata(str_sink_tdata[63:0]), .i_tlast(str_sink_tlast[0]),
> .i_tvalid(str_sink_tvalid[0]), .i_tready(str_sink_tready[0]),
>
> .o_tdata(str_src_tdata), .o_tlast(str_src_tlast),
> .o_tvalid(str_src_tvalid), .o_tready(str_src_tready),
>
> .m_axis_data_tdata(m_axis0_data_tdata),
>
> .m_axis_data_tlast(m_axis0_data_tlast),
>
> .m_axis_data_tvalid(m_axis0_data_tvalid),
>
> .m_axis_data_tready(m_axis0_data_tready),
>
> .m_axis_data_tuser(m_axis0_data_tuser),
>
> .s_axis_data_tdata(s_axis0_data_tdata),
>
> .s_axis_data_tlast(s_axis0_data_tlast),
>
> .s_axis_data_tvalid(s_axis0_data_tvalid),
>
> .s_axis_data_tready(s_axis0_data_tready),
>
> .s_axis_data_tuser(s_axis0_data_tuser),
>
> .m_axis_config_tdata(),
>
> .m_axis_config_tlast(),
>
> .m_axis_config_tvalid(),
>
> .m_axis_config_tready(),
>
> .m_axis_pkt_len_tdata(),
>
> .m_axis_pkt_len_tvalid(),
>
> .m_axis_pkt_len_tready());
>
>
>
> axi_wrapper #(
>
> .SIMPLE_MODE(0))
>
> axi_wrapper1 (
>
> .clk(ce_clk), .reset(ce_rst),
>
> .clear_tx_seqnum(clear_tx_seqnum),
>
> .next_dst(next_dst_sid),
>
> .set_stb(set_stb), .set_addr(set_addr), .set_data(set_data),
>
> .i_tdata(str_sink_tdata[127:64]), .i_tlast(str_sink_tlast[1]),
> .i_tvalid(str_sink_tvalid[1]), .i_tready(str_sink_tready[1]),
>
> // .o_tdata(str_src_tdata), .o_tlast(str_src_tlast),
> .o_tvalid(str_src_tvalid), .o_tready(str_src_tready),
>
> .m_axis_data_tdata(m_axis1_data_tdata),
>
> .m_axis_data_tlast(m_axis1_data_tlast),
>
> .m_axis_data_tvalid(m_axis1_data_tvalid),
>
> .m_axis_data_tready(m_axis1_data_tready),
>
> .m_axis_data_tuser(),
>
> .s_axis_data_tdata(),
>
> .s_axis_data_tlast(),
>
> .s_axis_data_tvalid(),
>
> .s_axis_data_tready(),
>
> .s_axis_data_tuser(),
>
> .m_axis_config_tdata(),
>
> .m_axis_config_tlast(),
>
> .m_axis_config_tvalid(),
>
> .m_axis_config_tready(),
>
> .m_axis_pkt_len_tdata(),
>
> .m_axis_pkt_len_tvalid(),
>
> .m_axis_pkt_len_tready());
>
> …
>
>
>
> As I mentioned I checked with ILA and ready is high for str_sink_tready so
> input is ready to accept data but I never see the valid go high.
>
> Thanks,
>
>
>
> Dario Pennisi
>
>
>
>
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
