Hey Rob, Regarding overflows or dropped packets, is this something that might > occur inside the FPGA (CE to CE) or is it just a concern on the > transfer to the host CPU (which is my only experience with overflows > or dropped packets)? If on the FPGA, what would be the cause of > overflows / dropped packets in the following scenario: > rx_radio->DDC->FFT->host?
Overflow generally only occurs due to the host being unable to consume samples quickly enough. It is possible for overflows to occur due to a RFNoC block not consuming samples quickly enough, but all in-tree blocks are designed to avoid that situation. Drops only occur between the device and host. Regarding the header, is the concern the following? Assume packet size > of 1024 and FFT size of 4096 such that there would be 4 packets for > each FFT; Now assume that EOB occurs on the 3rd packet such that the > FFT is 3/4 filled. Thus, on the next start-of-stream, the FFT will be > in a bad state. Is this the issue? If not, please explain. If so, > is the fix to reset the FFT on any incoming EOB? Without any fix, does > this issue correct itself in some way during the subsequent stream or > is the input frame mismatch issue going to remain until the FFT is > manually reset? Correct, resetting the FFT on EOB is a possible solution. If you reset on EOB though, you'll need to figure out a way to still send that final packet with EOB set to the host. Maybe zero fill the missing samples to complete the FFT? The issue will also fix itself on the next burst assuming you don't care that the first FFT might be corrupt. Jonathon On Sun, Mar 3, 2019 at 1:16 AM Rob Kossler <rkoss...@nd.edu> wrote: > Thanks Jonathon, > > > I'm glad you found those options useful. Unfortunately, there are a > number of corner cases that those options do not handle. You can run into > synchronization issues when overflows and dropped packets occur. In the > overflow case, if one occurs while the FFT is being filled then the next > FFT output will be incorrect. In the dropped packet case, the received FFT > frames could end up shifted between two FFT frames. The dropped packet case > is by the far worse of the two. > > Regarding overflows or dropped packets, is this something that might > occur inside the FPGA (CE to CE) or is it just a concern on the > transfer to the host CPU (which is my only experience with overflows > or dropped packets)? If on the FPGA, what would be the cause of > overflows / dropped packets in the following scenario: > rx_radio->DDC->FFT->host? > > > The block also does not handle the packet header correctly when FFTs are > split between multiple packets. For example, EOBs will not cause the FFT > core to reset, so the next burst could have an incorrect FFT output at the > beginning. Most of these issues can be worked around or even ignored, but I > think for general usage the block will need to be updated to handle them > properly. > > Regarding the header, is the concern the following? Assume packet size > of 1024 and FFT size of 4096 such that there would be 4 packets for > each FFT; Now assume that EOB occurs on the 3rd packet such that the > FFT is 3/4 filled. Thus, on the next start-of-stream, the FFT will be > in a bad state. Is this the issue? If not, please explain. If so, > is the fix to reset the FFT on any incoming EOB? Without any fix, does > this issue correct itself in some way during the subsequent stream or > is the input frame mismatch issue going to remain until the FFT is > manually reset? > > Thanks for your help. > Rob > > > > On Sat, Mar 2, 2019 at 2:41 AM Rob Kossler via USRP-users < > usrp-users@lists.ettus.com> wrote: > >> > >> Turns out there was a surprisingly simple modification to allow FFTs > longer than 1024. The axi_wrapper will automatically resize packets for > you if you configure it to do so. All I had to do was set > RESIZE_OUTPUT_PACKET(1) (and keep SIMPLE_MODE(1)) which caused the output > packets to be resized to match the input packet size. I was able to then > run 2048 and 4096 pt FFTs successfully (& producing the expected results) > and I could use any packet size I wanted going in and out of the overall > noc block. > >> > >> I did not even have to resize the packets going into the FFT because > the FFT doesn't care about input packet size with the caveat that it > generates various "bad size" events if it detects mismatches. Since I am > not monitoring such events, it doesn't really matter. And, if I did care > about these bad size events, the fix is simply to add > RESIZE_INPUT_PACKET(1) and set the desired resize value (i.e., the FFT > length) using the axi_wrapper "m_axis_pkt_len_t*" inputs. > >> > >> With such a simple fix, it seems that Ettus should permanently change > noc_block_fft.v to incorporate this. Another change would be to modify > this block so that MAX_FFT_SIZE_LOG2 is 12 rather than its current setting > of 11 in order to match the axi_fft IP core set for a max FFT of 4096. > >> > >> Rob > >> > >> On Fri, Mar 1, 2019 at 11:24 AM Jason Matusiak < > ja...@gardettoengineering.com> wrote: > >>> > >>> Probably not the approved way, but I made an FFT 2048 block a while > back. I didn't much with packet sizes or anything, I just sucked in two > 1024 packets, did the FFT, and then sent two 1024 packets back out. It > seemed to work fine. The only issue is that you have to remember > downstream that you need 2 vectors in a row to get your data. > >>> > >>> ________________________________ > >>> From: USRP-users <usrp-users-boun...@lists.ettus.com> on behalf of > Rob Kossler via USRP-users <usrp-users@lists.ettus.com> > >>> Sent: Thursday, February 28, 2019 4:08 PM > >>> To: usrp-users > >>> Subject: [USRP-users] RFNoC FFT size > 1024 > >>> > >>> Hi, > >>> I would like to implement an RFNoC FFT that can work for lengths > > 1024. Here's what I think I know: > >>> > >>> Current size for CE-to-CE packets is restricted to 8000 bytes (2000 > samples) > >>> Current RFNoC FFT size is tied to packet size and thus 1024 is the max > FFT size that can fit in a packet > >>> > >>> After reviewing previous posts and Xilinx FFT IP core documentation, > it seems that all I need to do is add packet resize logic at the input and > output of the block. Specifically, I am thinking of using > "packet_resizer.v" at both input and output (but only modifying tuser in > the output instance). > >>> > >>> Questions > >>> > >>> Is this a good approach? > >>> Anything special that I need to take care of? > >>> Does the selection of FFT architecture (pipelined, radix-4, etc) have > any relevance concerning this issue? > >>> > >>> 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
