<div dir="ltr">Hi Rob,<div><br></div><div>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.</div><div><br></div><div>Jonathon</div><div><br></div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Mar 2, 2019 at 2:41 AM Rob Kossler via USRP-users <<a href="mailto:usrp-users@lists.ettus.com">usrp-users@lists.ettus.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">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.<div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Rob</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Mar 1, 2019 at 11:24 AM Jason Matusiak <<a href="mailto:jason@gardettoengineering.com" target="_blank">jason@gardettoengineering.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">




<div dir="ltr">
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
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.</div>
<div id="gmail-m_7471020899678882659gmail-m_7967593250746967756signature">
<div>
<div id="gmail-m_7471020899678882659gmail-m_7967593250746967756appendonsend"></div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<br>
</div>
<hr style="display:inline-block;width:98%">
<div id="gmail-m_7471020899678882659gmail-m_7967593250746967756divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>From:</b> USRP-users <<a href="mailto:usrp-users-bounces@lists.ettus.com" target="_blank">usrp-users-bounces@lists.ettus.com</a>> on behalf of Rob Kossler via USRP-users <<a href="mailto:usrp-users@lists.ettus.com" target="_blank">usrp-users@lists.ettus.com</a>><br>
<b>Sent:</b> Thursday, February 28, 2019 4:08 PM<br>
<b>To:</b> usrp-users<br>
<b>Subject:</b> [USRP-users] RFNoC FFT size > 1024</font>
<div> </div>
</div>
<div>
<div dir="ltr">Hi,
<div>I would like to implement an RFNoC FFT that can work for lengths > 1024.  Here's what I think I know:</div>
<div>
<ul>
<li>Current size for CE-to-CE packets is restricted to 8000 bytes (2000 samples)</li><li>Current RFNoC FFT size is tied to packet size and thus 1024 is the max FFT size that can fit in a packet</li></ul>
<div>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).  </div>
<div><br>
</div>
<div>Questions</div>
<div>
<ul>
<li>Is this a good approach?  </li><li>Anything special that I need to take care of?</li><li>Does the selection of FFT architecture (pipelined, radix-4, etc) have any relevance concerning this issue?</li></ul>
</div>
</div>
<div>Rob</div>
</div>
</div>
</div>
</div>
</div>

</blockquote></div></div>
_______________________________________________<br>
USRP-users mailing list<br>
<a href="mailto:USRP-users@lists.ettus.com" target="_blank">USRP-users@lists.ettus.com</a><br>
<a href="http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com" rel="noreferrer" target="_blank">http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com</a><br>
</blockquote></div>