On Thu, 24 Feb 2022 at 05:05, 'Ross Martin' via [email protected] < [email protected]> wrote:
> Hi Jack, > > Yes, the Xilinx SSR FFT is good, but there are some caveats. In my > testing, its performance degrades severely if the FFT size is greater than > 8192 or if the SSR is greater than 8. It’s very good on both DSP and BRAM > utilization, but it’s mediocre on LUT usage and power consumption. It > takes longer to synthesize than other FFTs, and simulation is incredibly > slow: it takes about 10 times longer to complete an RTL simulation with the > Xilinx SSR FFT than with any other FFT that I tested. It’s also missing > some features, like any form of synchronization or even a reset. Thus it > takes some work to make sure it starts taking the FFT at the desired time, > and that might cause some problems synchronizing multiple FFTs for > beamforming or cross-channel correlations. > > So it’s good if its high points are what matters to you and you can get > around its low points. > > What FFT size and SSR are you looking for? What type of application? > Hi Ross, Thanks for sharing your experience. The lack of reset I find particularly perplexing and potentially troublesome. I did dig a little into the HDL which is under the block, only to find the source files littered with "Xilinx doesn't support this code, contact the author directly", which made me smile. At the moment I'm just sizing up options for a potential DSA2000 channelizer. Notionally (subject to occasional wild spec changes) my use case is a few parallel 2048-point FFTs with an SSR factor of either 16 or 32, depending on where other specs land and how much I can be bothered to fight with timing closure. But 2 weeks ago the spec was for a 32k point FFT, and based on an email thread I'm on it could be about to change to lots of parallel 512-point transforms. So.... :shrug:. Currently I'm mostly just sizing up resource use and getting some data points for power consumption on real hardware (iwave zu11 SoM, for the interested) -- the block builds fine (with a bunch of other peripheral CASPER FIRs / other logic) fine at 300 MHz with SSR 32, and simulates plausibly (using Jenny Smith's sim scripts) which is all I need for now. Performance I'm sure will ultimately be important, but requires better system requirements than I have to be in any way meaningful. For now, I'm really just using the block as a baseline for what's possible -- the CASPER block has some pretty significant deficits for large SSR factors which mean I don't really even want to use it as a place holder for benchmarking. I suspect I'll be revisiting implementation choice down the road (at which point I'd imagine there will be a good chance I'll be hitting you up asking to try out your latest offerings!) Cheers Jack PS: Thanks also to Talon, who pointed me off-list to ASTRONs complex->dual-real descrambler, which I think could probably be plugged straight into the Xilinx SSR FFT if necessary https://github.com/talonmyburgh/casper_dspdevel/blob/master/casper_wb_fft/fft_sepa_wide.vhd > Regards, > > Ross > > > > On Feb 23, 2022, at 5:14 AM, Jack Hickish <[email protected]> wrote: > > Hi All, > > As others have reported ( > https://www.mail-archive.com/[email protected]/msg08238.html) the > Xilinx SSR FFT is pretty good. > > However, I want to do two real transforms instead of one complex -- does > anyone happen to have an unscrambler already made which I can steal? > Otherwise I suppose I'll have to make my own, which would be terribly > tedious :) > > Cheers > Jack > > -- > You received this message because you are subscribed to the Google Groups " > [email protected]" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CAG1GKSk0A7zP%2BgGwOo_VWW3QZv8cFOKtggiNqEqfdfCTRF72pQ%40mail.gmail.com > <https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CAG1GKSk0A7zP%2BgGwOo_VWW3QZv8cFOKtggiNqEqfdfCTRF72pQ%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > > -- > You received this message because you are subscribed to the Google Groups " > [email protected]" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/3598CB06-4E6F-4060-A76F-31451029DD37%40ieee.org > <https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/3598CB06-4E6F-4060-A76F-31451029DD37%40ieee.org?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "[email protected]" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CAG1GKSmkZ-_%2BV%2BmXO9k7pE-GdSJJSKcBSnKLW2z6OPipdVZzrg%40mail.gmail.com.
