Hi Jonathon, I have identified the cause of this problem as being chdr_framer.v. It appears to not be adhering to the axi_stream protocol and is holding onto packets until the fifo is full even when o_tready is asserted, causing the described behavior.
The root cause is the switch to axi_fifo_flop2 for the header fifo (changed with commit that eb0ae36). The problem is fixed completely by switching this back to an axi_fifo_short. Thanks, Sam On Oct 25, 2018, 7:36 PM -0700, Samuel Prager <spra...@usc.edu>, wrote: > 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
