[USRP-users] RFNoC FFT size > 1024

Rob Kossler rkossler at nd.edu
Thu Mar 28 14:26:38 EDT 2019


Thanks Jonathon!

On Thu, Mar 28, 2019 at 5:24 AM Jonathon Pendlum <jonathon.pendlum at ettus.com>
wrote:

> Hey Rob,
>
> Regarding overflows or dropped packets, is this something that might
>> occur inside the FPGA (CE to CE) or is it just a concern on the
>> transfer to the host CPU (which is my only experience with overflows
>> or dropped packets)?  If on the FPGA, what would be the cause of
>> overflows / dropped packets in the following scenario:
>> rx_radio->DDC->FFT->host?
>
>
> Overflow generally only occurs due to the host being unable to consume
> samples quickly enough. It is possible for overflows to occur due to a
> RFNoC block not consuming samples quickly enough, but all in-tree blocks
> are designed to avoid that situation. Drops only occur between the device
> and host.
>
> Regarding the header, is the concern the following? Assume packet size
>> of 1024 and FFT size of 4096 such that there would be 4 packets for
>> each FFT; Now assume that EOB occurs on the 3rd packet such that the
>> FFT is 3/4 filled.  Thus, on the next start-of-stream, the FFT will be
>> in a bad state.  Is this the issue?  If not, please explain.  If so,
>> is the fix to reset the FFT on any incoming EOB? Without any fix, does
>> this issue correct itself in some way during the subsequent stream or
>> is the input frame mismatch issue going to remain until the FFT is
>> manually reset?
>
>
> Correct, resetting the FFT on EOB is a possible solution. If you reset on
> EOB though, you'll need to figure out a way to still send that final packet
> with EOB set to the host. Maybe zero fill the missing samples to complete
> the FFT? The issue will also fix itself on the next burst assuming you
> don't care that the first FFT might be corrupt.
>
> Jonathon
>
> On Sun, Mar 3, 2019 at 1:16 AM Rob Kossler <rkossler at nd.edu> wrote:
>
>> Thanks Jonathon,
>>
>> > 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.
>>
>> Regarding overflows or dropped packets, is this something that might
>> occur inside the FPGA (CE to CE) or is it just a concern on the
>> transfer to the host CPU (which is my only experience with overflows
>> or dropped packets)?  If on the FPGA, what would be the cause of
>> overflows / dropped packets in the following scenario:
>> rx_radio->DDC->FFT->host?
>>
>> > 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.
>>
>> Regarding the header, is the concern the following? Assume packet size
>> of 1024 and FFT size of 4096 such that there would be 4 packets for
>> each FFT; Now assume that EOB occurs on the 3rd packet such that the
>> FFT is 3/4 filled.  Thus, on the next start-of-stream, the FFT will be
>> in a bad state.  Is this the issue?  If not, please explain.  If so,
>> is the fix to reset the FFT on any incoming EOB? Without any fix, does
>> this issue correct itself in some way during the subsequent stream or
>> is the input frame mismatch issue going to remain until the FFT is
>> manually reset?
>>
>> Thanks for your help.
>> Rob
>>
>>
>> > 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/20190328/3ea08074/attachment.html>


More information about the USRP-users mailing list