Thanks Wade, So, I get what you are saying in general but I'm still not clear on specifics.
My custom block is a multi-port pulse detector with an equal number of input and output ports. The idea is that the radios stream Rx samples on multiple ports to my block in a single continuous burst. My block then uses multi-port logic to decide when energy is present such that it can discard samples (on all ports identically) that occur in between pulses. The problem I'm having is that the Rx radios don't all stop at the same time. They all start synchronously, but stop asynchronously (in previous UHD versions, it was not possible to stop them using a time spec - I'm not sure if this is still the case in UHD 4). So, since my block wants to process samples from all streams simultaneously (using an "axi_join" of all streams at the input), it has a problem when one stream stops before the rest. So, with that in mind, what should my block do to properly clear data? Here are my ideas but I'm hoping you can comment. - Implement "flushing logic" at my block input such that once I receive EOB on any stream, I discard data on the other streams until I receive EOB for all streams. I am presently building a version with this logic which I just implemented a few minutes ago. - Implement a "clear" register that will allow me to clear data pipes using register writes. I have already implemented this and it works to some degree but not perfectly. I'm still getting the UHD WARNING at startup even though my block controller constructor asserts & then de-asserts this clear which is wired to all of the FIFOs and other logic that need cleared. If I start UHD 2 or 3 times, eventually it starts up without the WARNING but I don't understand why it takes 2 or 3 times and would like to fix this. And, I have confirmed that every time it starts up with the WARNING, the output of my block is sample mis-aligned such that I know there is still data in some pipe. Is there something my block should be doing during the UHD "flushing" step to make sure that the flush succeeds? I'm looking for any ideas, best-practices, etc., on how to make my custom block robust. Thanks. Rob On Tue, Jan 26, 2021 at 11:37 AM Wade Fife <wade.f...@ettus.com> wrote: > I believe RFNoC tries to flush any partially transmitted packets out of > blocks during initialization before resetting them. The idea is to get rid > of any leftover data that might still be in the data pipes. I think a > timeout means the noc_shell never saw the end of the last packet before the > timeout. I usually see this warning if I stopped the previous session > abruptly without properly stopping the data transfer. > > I think you'll see this warning if your block stops data transfer > mid-packet. Then, on the next session, it can't finish the packet it > started on the previous session. Or something like that. It's probably OK > to ignore if your block uses the resets coming out of the noc_shell to > reset everything. > > Wade > > On Mon, Jan 25, 2021 at 7:28 PM Rob Kossler via USRP-users < > usrp-users@lists.ettus.com> wrote: > >> Hi, >> Using RFNOC 4.0 with a few of my custom blocks, I get the following >> warning at UHD startup (after having run it at least once before): >> >> [WARNING] [RFNOC::GRAPH] One or more blocks timed out during flush! >> >> I'm confident it is something that I'm doing incorrectly with my block, >> but I'm wondering if anyone can comment on what causes this and / or what >> my block should be doing to avoid it. >> >> Rob >> _______________________________________________ >> 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
