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 <[email protected]> on behalf of Rob Kossler via USRP-users <[email protected]> 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 [email protected] http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
