Re: [USRP-users] RFNoC block fpga control source issues

[Samuel Prager via USRP-users]

Hi Jonathon,

Yes I don’t really see how this what about the fifo flop vs fifo would be 
causing the issue either so it would make sense if there is something more 
complex going on...

I am using chdr framer to generate my command packet headers, which is where it 
was causing problems. I haven’t had any problems using it with data packets.

Yes the commands go out shortly before I start streaming TX data to the radio 
from my block.

What’s interesting is the correct number of settings bus writes were always 
being initiated in the radio at the right time. The commands actually coming 
out of the chdr_framer were oddly just from previous bursts.

I’m not sure how helpful this is, but I took some screenshots of the ila probes 
showing the complete transaction:

https://drive.google.com/open?id=1FwQe2ky0vsU_jjAa24U-_oTGhtvI3jK8

The signals are ordered from top to bottom as - 1-4 : command body going in to 
chdr_framer: tdata, tvalid, tready, state of my block
- 5-7 : cmd packets leaving chdr_framer : tdata, tvalid, tready
- 8-10 : cmd in port packets received by the radio : tdata, tvalid, tready
- 11-12 : settings bus of radio set data, set addr, set stb

There are some additional screenshots of the transactions here, that attempt to 
show the described behavior by the chdr_framer.
https://drive.google.com/open?id=1JRdzt27e2uyEs9DIDSTNHhRk_qB9W897

One other interesting behavior, is that when I kill my software application and 
restart it, the first command that comes out of chdr framer is a command sent 
while the previous instance of my application was running.

This can be seen for example in the image by my command to write radio SR 0x99 
(rx cmd time hi). My block to sends 0x0, but the cmd out of chdr framer and the 
ultimate settings bus write is 0xa

Sam
On Oct 31, 2018, 1:23 AM -0700, Jon Pendlum , wrote:
> Hi Sam,
>
> Interesting find. Fundamentally, chdr_frame was designed to buffer and 
> release on packet boundaries. This is due to the crossbar being packet 
> switched and ensures packets flow through the crossbar at full rate. 
> Generally, that is only important for sample data, which could have large 
> packets generated slowly due to a low sample rate.
>
> All that said, I am not seeing why switching to axi_fifo_flop2 is causing an 
> issue. chdr_framer is not used anywhere in the settings bus data path. I 
> wonder if there is a more complex interaction going on here. The 
> flow_control_responder in noc_shell does use chdr_framer and its output does 
> eventually mux with response packets generated from setting bus writes.
>
> Do you send these commands only while streaming? If so, can you try to send 
> them when not streaming and see if you have the same issue?
>
> Jonathon
>
> > On Wed, Oct 31, 2018 at 5:19 AM Samuel Prager  wrote:
> > > 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 , 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 , 
> > > > 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  
> > > 

Re: [USRP-users] RFNoC block fpga control source issues

[Samuel Prager via USRP-users]

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 , 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 , 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  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 , 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 , 
> > > > > 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  
> > > > > > > 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 
> > > > > > > > , 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 

Re: [USRP-users] RFNoC block fpga control source issues

[Samuel Prager via USRP-users]

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 , 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  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 , 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 , 
> > > > 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  
> > > > > > 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 
> > > > > > > , 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 
> > > > > > > > >  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 

Re: [USRP-users] RFNoC block fpga control source issues

[Jon Pendlum via USRP-users]

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  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 , 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 ,
> 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  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 ,
>> 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),

Re: [USRP-users] RFNoC block fpga control source issues

[Samuel Prager via USRP-users]

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 , 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 , 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  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 , 
> > > > 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 
> > > > > >  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
> 

Re: [USRP-users] RFNoC block fpga control source issues

[Samuel Prager via USRP-users]

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 , 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  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 , 
> > > 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 
> > > > >  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

Re: [USRP-users] RFNoC block fpga control source issues

[Jon Pendlum via USRP-users]

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  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 ,
> 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

Re: [USRP-users] RFNoC block fpga control source issues

[Samuel Prager via USRP-users]

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 , 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 
> >  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

Re: [USRP-users] RFNoC block fpga control source issues

[Jon Pendlum via USRP-users]

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

[USRP-users] RFNoC block fpga control source issues

[Samuel Prager via USRP-users]

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