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 > <https://urldefense.proofpoint.com/v2/url?u=https-3A__pastebin.com_1AeHFb0J&d=DwMFaQ&c=clK7kQUTWtAVEOVIgvi0NU5BOUHhpN0H8p7CSfnc_gI&r=opIuWAKmywF059tAs2i3Pg&m=B6iFCsmZGjca1mKRVOeoNySiRpWdnEvZLexmRrNkccY&s=w9EL2OW3X1pPPPLi6NV6LmKod124rKXsVKTtakVbZh4&e=>. > 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 >> <https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.ettus.com_mailman_listinfo_usrp-2Dusers-5Flists.ettus.com&d=DwMFaQ&c=clK7kQUTWtAVEOVIgvi0NU5BOUHhpN0H8p7CSfnc_gI&r=opIuWAKmywF059tAs2i3Pg&m=B6iFCsmZGjca1mKRVOeoNySiRpWdnEvZLexmRrNkccY&s=P6_QXK6P9imdGBTvBybF4IrCojJ2jvCDT8CwfAAFlD0&e=> >> >
_______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
