[USRP-users] RFNoC FFT size > 1024

Rob Kossler rkossler at nd.edu
Sat Mar 2 11:16:19 EST 2019

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:

> 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.

> On Sat, Mar 2, 2019 at 2:41 AM Rob Kossler via USRP-users <usrp-users at 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 <jason at 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-bounces at lists.ettus.com> on behalf of Rob Kossler via USRP-users <usrp-users at 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 at lists.ettus.com
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

More information about the USRP-users mailing list