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
