Hi Jonathan, Yes I add my block and the radio block, connect them and tell my block to send commands to radio block. I have confirmed today that the simulation still works correctly in Vivado 2017.4 — the settings registers are written as expected, an rx command is generated in the radio and the correct number of samples are streamed back into the tb_streamer.
Sam On Oct 21, 2018, 9:20 AM -0700, Jon Pendlum <jon.pend...@gmail.com>, wrote: > How does your testbench work? Do you add the radio core block, send timed > commands to it, and see the outputs toggle? > > > On Sat, Oct 20, 2018 at 1:05 PM Samuel Prager <spra...@usc.edu> wrote: > > > Hi Jonathon, > > > > > > Thanks for the response! Yes I’m using ce_clk and ce_rst. Thanks for > > > sharing your code — the only real difference I see is that you increment > > > the seq_num. I am leaving it as 12’b0 — could this be causing an issue? > > > > > > I should also say that In my case, the command packets are being sent to > > > the radio block to trigger timed receive commands in order to reduce the > > > number of software sr_writes. > > > > > > Here’s my code just in case: https://pastebin.com/Asgj7Jw2. > > > > > > This is something that was simulated/verified and worked in the past, but > > > perhaps a change has been made that prevents this from working? > > > > > > I will try a release tag as soon as possible — however this is something > > > I’ve been seeing for a couple of months now that has kept me on > > > pre-2017.4 releases. > > > > > > Sam > > > On Oct 19, 2018, 8:17 PM -0700, Jon Pendlum <jon.pend...@gmail.com>, > > > wrote: > > > > Hi Sam, > > > > > > > > I am using command packets to tune the DDC block's DSP frequency. Are > > > > you using ce_clk and ce_rst for clock and reset? Here is my code if you > > > > want to take a look: https://pastebin.com/1AeHFb0J. Also, it might be > > > > worth trying your code on a release tag like v3.13.0.2 in case master > > > > has a regression. > > > > > > > > Jonathon > > > > > > > > > On Sat, Oct 20, 2018 at 8:11 AM Samuel Prager via USRP-users > > > > > <usrp-users@lists.ettus.com> wrote: > > > > > > Hello, > > > > > > > > > > > > I have an RFNoC block that generates command packets to write > > > > > > settings registers of the downstream connected block using the > > > > > > Control Source (cmdout_tdata) of the noc_shell . Previously this > > > > > > had worked perfectly (prior to approximately d6b2283 on > > > > > > rfnoc-devel), for both the X300 and E310, but this functionality > > > > > > appears to perhaps be broken in the more recent FPGA releases — > > > > > > since around the switch to Vivado 2017.4 and the move of the noc > > > > > > block clock domain crossing to axi_wrapper.v). I have tried the > > > > > > latest master branch (4f25ed1) with no success. > > > > > > > > > > > > Is this a known issue? Can anyone shed light on what might have > > > > > > caused this? > > > > > > > > > > > > The control packets are generated in my block as follows: > > > > > > > > > > > > wire eob = 1’b0; > > > > > > wire [1:0] pkt_type = 2'b10; > > > > > > wire [11:0] seqnum = 12'd0; // don't care > > > > > > wire [15:0] payload_length = 16'd16; //don't care (payload length > > > > > > in bytes) > > > > > > assign cmd_tdata = {24’d0,set_bus_addr[7:0], set_bus_val[31:0]}; > > > > > > > > > > > > cvita_hdr_encoder cvita_hdr_encoder( > > > > > > .pkt_type(pkt_type),.eob(eob), .has_time(1'b0), > > > > > > .seqnum(seqnum), > > > > > > .payload_length(payload_length), > > > > > > .src_sid(src_sid), .dst_sid(dst_sid), > > > > > > .vita_time(vita_time), > > > > > > .header(cmd_tuser) > > > > > > ); > > > > > > > > > > > > chdr_framer #(.SIZE(FIFO_SIZE), .WIDTH(64)) chdr_framer ( > > > > > > .clk(clk), .reset(reset), .clear(clear), > > > > > > .i_tdata(cmd_tdata), .i_tuser(cmd_tuser), .i_tlast(cmd_tlast), > > > > > > .i_tvalid(cmd_tvalid), .i_tready(cmd_tready), > > > > > > .o_tdata(cmdout_tdata), .o_tlast(cmdout_tlast), > > > > > > .o_tvalid(cmdout_tvalid), .o_tready(cmdout_tready)); > > > > > > > > > > > > The command packets appear to never reach the destination rfnoc > > > > > > block, but I am at a loss for the cause. > > > > > > > > > > > > Is anyone currently using the control source functionality of the > > > > > > noc_shell? I would really appreciate any pointers on how to fix > > > > > > this. > > > > > > > > > > > > Thank you, > > > > > > > > > > > > Sam > > > > > > > > > > > > _______________________________________________ > > > > > > USRP-users mailing list > > > > > > USRP-users@lists.ettus.com > > > > > > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
_______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
