[USRP-users] Live rate changes within an RFNOC block

Jonathon Pendlum jonathon.pendlum at ettus.com
Mon Feb 4 22:30:23 EST 2019


Hi Andrew,

One thing the testbench infrastucture does not simulate is packet latency
variation. I have seen this happen in the past where custom code has a
subtle AXI stream implementation bug that only comes up in hardware since
the offending tvalid / tready pattern does not occur in simulation. One
thing to try in simulation is to randomly force the deassertion of the
tvalid / tready signals on the AXI stream buses of your block. This can be
implemented as some temporary shim logic between axi_rate_change and your
block. For instance, on the input side of your block, randomly deassert the
tvalid from axi_rate_change and the tready from your block. Make sure to do
them together so axi_rate_change sees tready deasserted at the same time
that your block sees the tvalid deasserted.

I would also suggest chipscoping the signal 'error_extra_outputs' output
from axi_rate_change. Knowing if that signal is asserted during the
timeouts is really useful information.

Jonathon

On Tue, Feb 5, 2019 at 9:30 AM Andrew Danowitz <andrew at whitefoxdefense.com>
wrote:

> Thanks for the feedback. I've simulated the block and got it working with
> no errors over a few million samples as long as I assert axi_rate_change's
> clear when I change N (I've been swapping rates once every 200
> transmissions in the testbench). I still get the timeout error in hardware,
> though. Could clearing be messing up some stored packet header information
> that simulation wouldn't catch?
>
> Thanks,
> Andrew
>
> On Mon, Jan 28, 2019 at 4:34 PM Jonathon Pendlum <
> jonathon.pendlum at ettus.com> wrote:
>
>> Hi Andrew,
>>
>> Have you simulated or used chipscope on your block? There is an output
>> from axi rate change called "error_extra_outputs" that can be useful. Does
>> it assert ever assert? If so, that means your user code has output more
>> samples than axi rate change was expecting. If any extra samples come out,
>> that breaks axi rate change's tracking of the input sample to output sample
>> ratio, which can eventually lead to a lock up.
>>
>> Jonathon
>>
>> On Tue, Jan 29, 2019 at 3:11 AM Andrew Danowitz via USRP-users <
>> usrp-users at lists.ettus.com> wrote:
>>
>>> I have an RFNOC block that, based on a control register can either
>>> decimate the signal it's working on or leave the output rate the same as
>>> the input rate. If I set the control register to an initial value (either
>>> decimate, or not decimate) and let the system run, it works fine in either
>>> mode. If I try to change the decimation mode while the block is running, I
>>> start getting timeout errors. I currently use the axi_rate_change block to
>>> help handle the rate change, and have tried to synchronize changing the
>>> block's mode (decimate or not) with the axi_rate_change's clear_user flag.
>>> Any thoughts?
>>>
>>> Thanks,
>>> Andrew
>>>
>>> ------------------------------
>>> Information contained, linked, or attached to this email and all verbal
>>> communications from WhiteFox Defense to your entity in the prior 30 days
>>> constitute proprietary and confidential information unless otherwise
>>> indicated and is therefore subject to obligations in any executed
>>> confidentiality agreements. Further, this email is intended solely for the
>>> use of the individual or entity to whom they are addressed. If you are not
>>> the intended recipient and this message has been addressed to you in error,
>>> please promptly notify info at whitefoxdefense.com and destroy all copies
>>> of the message and any attachments. This email and attachments may contain
>>> technical data as defined in the International Traffic In Arms Regulations
>>> (ITAR) 22 CFR 120.10 or the Export Administration Regulations (EAR) 15 CFR
>>> Parts 730 – 780.  Export of this material may be controlled by these
>>> regulations and may not be exported or transferred to non-U.S. persons
>>> without prior written approval from the U.S. government.
>>> _______________________________________________
>>> USRP-users mailing list
>>> USRP-users at lists.ettus.com
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>
> ------------------------------
> Information contained, linked, or attached to this email and all verbal
> communications from WhiteFox Defense to your entity in the prior 30 days
> constitute proprietary and confidential information unless otherwise
> indicated and is therefore subject to obligations in any executed
> confidentiality agreements. Further, this email is intended solely for the
> use of the individual or entity to whom they are addressed. If you are not
> the intended recipient and this message has been addressed to you in error,
> please promptly notify info at whitefoxdefense.com and destroy all copies of
> the message and any attachments. This email and attachments may contain
> technical data as defined in the International Traffic In Arms Regulations
> (ITAR) 22 CFR 120.10 or the Export Administration Regulations (EAR) 15 CFR
> Parts 730 – 780.  Export of this material may be controlled by these
> regulations and may not be exported or transferred to non-U.S. persons
> without prior written approval from the U.S. government.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20190205/f830476e/attachment.html>


More information about the USRP-users mailing list