ream isn't getting reset properly) and I have to reboot.
>
> After making the mod, I am working pretty well (small sample size though).
>
>
>
> ----- Original Message -----
>
> Subject: RE: Re: Re: [USRP-users] RFNoC FPGA clear_tx_seqnum behavior
>
> From:
t.
After making the mod, I am working pretty well (small sample size though).
- Original Message - Subject: RE: Re: Re: [USRP-users] RFNoC
FPGA clear_tx_seqnum behavior
From: "Jason Matusiak"
Date: 7/2/18 12:03 pm
To: "Brian Padalino"
Cc: "USRP-us
),
.pkt_rst(bus_rst),
+ .samp_clk(ce_clk), .samp_rst(ce_rst | clear_tx_seqnum[i]), .pkt_clk(bus_clk),
.pkt_rst(bus_rst | clear_tx_seqnum_bclk[i]),
~Jason
- Original Message - Subject: RE: Re: Re: [USRP-users] RFNoC
FPGA clear_tx_seqnum behavior
Date: 7/2/18 6:54 am
To:
Thanks Brian, that seemed to be the trick, at least for the initial flowgraph I
was trying to use (I think I must have missed a block in my second flowgraph).
Sadly, I can only run it once and then it doesn't work on the second run, so I
need to investigate that next. I feel like I remember so
On Fri, Jun 29, 2018 at 9:57 AM Jason Matusiak <
ja...@gardettoengineering.com> wrote:
> I missed that, thanks for the heads up. I replaced the
> two chdr_deframer_2clk functions with the old chdr_deframer, but that
> didn't seem to fix things for me. Guess I will have to do a deep dive into
> t
ssage - Subject: Re: [USRP-users] RFNoC FPGA
clear_tx_seqnum behavior
From: "Brian Padalino"
Date: 6/28/18 3:35 pm
Cc: "USRP-users@lists.ettus.com"
Hey Jason,
On Thu, Jun 28, 2018 at 3:31 PM Jason Matusiak via USRP-users
wrote:
I know this is an older thread, b
Hey Jason,
On Thu, Jun 28, 2018 at 3:31 PM Jason Matusiak via USRP-users <
usrp-users@lists.ettus.com> wrote:
> I know this is an older thread, but I too am struggling to bring a block that
> someone else designed for us in 2015.4 to work in 2017.4. I dug around but I
> don't see any of our cu
I know this is an older thread, but I too am struggling to bring a block that
someone else designed for us in 2015.4 to work in 2017.4. I dug around but I
don't see any of our custom blocks using clear_tx_seqnum in their sub-modules
or their config registers. They do use the config registers qu
Hi EJ,
Sorry for the delay here. From the FPGA's perspective if you have
something streaming between one set of blocks and then you start
streaming a different application on another set of previously unused
blocks, then the current clear implementation should still work as
long as the new applica
Hi Ashish,
Awesome! Thanks for clarifying.
Just a thought here...
>If you download an FPGA image, run flow
>graph A, then without reloading the image you want to run flow graph B
>with a different topology then the clear signal will ensure that
>things are cleaned up properly between A and B. Do
Hi EJ,
On Thu, May 3, 2018 at 5:06 AM, EJ Kreinar wrote:
> Hi Ashish,
>
> Thanks for the info about rfnoc changes. Quick question:
>
>> In rfnoc, we make a
>> distinction between reset and clear. A "reset" is meant to reset
>> everything in a module to the power-up state. A "clear" only resets
>>
Hi Brian,
I finally got a chance to look at that change in a bit more detail. I
need to test out this theory out but we may have added a regression
with the throttle commit I pointed out earlier. The issue would apply
to "sink" blocks only. We assert the clear_tx_seqnum signal when the
block is in
Hi Ashish,
Thanks for the info about rfnoc changes. Quick question:
> In rfnoc, we make a
> distinction between reset and clear. A "reset" is meant to reset
> everything in a module to the power-up state. A "clear" only resets
> things that are not software controlled, like settings regs. The
> e
Hey Ashish,
On Wed, May 2, 2018 at 7:02 PM Ashish Chaudhari
wrote:
> Hi Brian,
>
> >> > Moreover, it seems like axi_wrapper.v uses clear_tx_seqnum to pass out
> >> > config bus messages, so now that clear_tx_seqnum is set I am not able
> to
> >> > use
> >> > the config bus from the axi_wrapper.
Hi Brian,
>> > Moreover, it seems like axi_wrapper.v uses clear_tx_seqnum to pass out
>> > config bus messages, so now that clear_tx_seqnum is set I am not able to
>> > use
>> > the config bus from the axi_wrapper.
>>
>> I think this is a side effect of the assumption that data cannot flow
>> thro
Hi Ashish,
On Wed, May 2, 2018 at 2:45 PM Ashish Chaudhari
wrote:
> On Wed, May 2, 2018 at 8:20 AM, Brian Padalino via USRP-users
> wrote:
> > I had some blocks that worked just fine with the old rfnoc-devel branch
> > using 2015.4, but when this latest change to 2017.4 came in, my blocks
> > s
On Wed, May 2, 2018 at 8:20 AM, Brian Padalino via USRP-users
wrote:
> I had some blocks that worked just fine with the old rfnoc-devel branch
> using 2015.4, but when this latest change to 2017.4 came in, my blocks
> stopped working.
>
> I've found that a significant change was how clear_tx_seqnu
I had some blocks that worked just fine with the old rfnoc-devel branch
using 2015.4, but when this latest change to 2017.4 came in, my blocks
stopped working.
I've found that a significant change was how clear_tx_seqnum seems to now
work. I've noticed that clear_tx_seqnum will be set while setti
18 matches
Mail list logo
