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 <and...@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.pend...@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@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 i...@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@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 i...@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@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
