Hey Jonathon, I had a chance to debug this a little further (On an N300) and have observed the following behavior:
The command packets are getting through to the radio block but are being buffered somewhere along the line so that the first command is either not received or not processed until exactly 16 have been sent. So if I am sending commands in a loop, there is a 16 command delay before the settings bus writes and a rx command is triggered in the radio. This seems to indicate that there is a buffer somewhere that doesn’t pass the commands until it is full. Any thoughts on what the culprit could be? Sam On Oct 23, 2018, 11:17 PM -0700, Jon Pendlum <jon.pend...@gmail.com>, wrote: > Hey Sam, > > There have been some changes to noc_shell, maybe they are related to your > issue. If you want to try to debug this on the FPGA, I suggest using > chipscope on the file cmd_pkt_proc.v. That is the state machine that receives > command packets and issues settings bus writes. You should be able to see > your command packets come in and get processed by the state machine. You can > double check the command packet / timed command vita time versus the radio > core's vita time. You can also see if the state machine gets stuck in a > certain state. > > Jonathon > > > On Wed, Oct 24, 2018 at 9:44 AM Samuel Prager <spra...@usc.edu> wrote: > > > Hi Jonathan, > > > > > > Just following up on this. I have switched to the UHD 3.13 release + FPGA > > > version 5.2. This issue still persists. > > > > > > Is it possible that a change to UHD could be causing this to not work? > > > > > > If anyone can confirm that they are able to send commands to the radio > > > block from an rfnoc block in recent versions of UHD it would help a lot. > > > > > > Thanks, > > > > > > Sam > > > > > > On Oct 22, 2018, 1:06 PM -0700, Samuel Prager <spra...@usc.edu>, wrote: > > > > 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
