[USRP-users] RFNoC FFT size > 1024
rkossler at nd.edu
Fri Mar 1 12:39:58 EST 2019
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
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.
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
> 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
> - 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...
More information about the USRP-users