Thanks Jonathon! On Thu, Mar 28, 2019 at 5:24 AM Jonathon Pendlum <jonathon.pend...@ettus.com> wrote:
> 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
