[USRP-users] RFNoC FFT size > 1024

Jonathon Pendlum jonathon.pendlum at ettus.com
Fri Mar 1 19:26:31 EST 2019

Hi Rob,

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


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20190302/5f171ef8/attachment.html>

More information about the USRP-users mailing list