[USRP-users] RFNoC FFT size > 1024

Jason Matusiak jason at gardettoengineering.com
Fri Mar 1 11:24:05 EST 2019

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

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


  *   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?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20190301/1ffb595c/attachment.html>

More information about the USRP-users mailing list