I forgot to say that the power estimates are for a 600MHz clock. They’re also just for the FFT, and don’t include static power or any other logic. At 300MHz, the power for the FFT should be half these numbers.
Regards, Ross > On Feb 24, 2022, at 8:18 AM, Ross Martin <ross.mar...@ieee.org> wrote: > > Hi Jack, > > Almost all FFTs will make 300MHz these days, regardless of how good they are. > You may not need a good FFT. :-) > > Here are the results I found for 18-bit 2048-point complex FFTs at SSR 16 and > 32 in a ZCU111: > > 2048SSR16 Synth_Minutes Frequency LUTs REGs DSPs 36kb > BRAMs Watts Sim_Minutes > Astron FFT: 119.84 385.8 50310 37558 576 > 540.0 16.415 0.53 > BxBFFT: 23.78 669.8 18806 25846 142 > 26.5 5.125 0.21 > Spiral FFT: 37.71 595.2 39206 39887 252 > 0.0 8.064 0.49 > Xilinx FFT: 38.70 585.1 33153 36137 126 > 0.0 7.847 5.56 > > 2048SSR32 Synth_Minutes Frequency LUTs REGs DSPs 36kb > BRAMs Watts Sim_Minutes > Astron FFT: 198.50 382.8 89001 69444 1088 > 648.0 25.547 0.56 > BxBFFT: 32.52 669.3 34410 62105 316 > 16.0 9.000 0.35 > Spiral FFT: 54.74 603.9 62073 68091 492 > 0.0 13.717 0.47 > Xilinx FFT: 66.91 408.5 76422 65176 306 > 0.0 17.941 4.72 > > These results are for FFTs with fully natural data order in and out — except > for the Astron FFT, which only supports a partially-natural data order out. > > If you know of any other Verilog or VHDL SSR FFTs that I can get code for, > I’d be happy to benchmark those also. These are the ones I could find. > > Regards, > > Ross > > >> On Feb 24, 2022, at 4:39 AM, Jack Hickish <jackhick...@gmail.com >> <mailto:jackhick...@gmail.com>> wrote: >> >> >> >> On Thu, 24 Feb 2022 at 05:05, 'Ross Martin' via casper@lists.berkeley.edu >> <mailto:casper@lists.berkeley.edu> <casper@lists.berkeley.edu >> <mailto:casper@lists.berkeley.edu>> 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 >> >> <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 <jackhick...@gmail.com >>> <mailto:jackhick...@gmail.com>> wrote: >>> >>> Hi All, >>> >>> As others have reported >>> (https://www.mail-archive.com/casper@lists.berkeley.edu/msg08238.html >>> <https://www.mail-archive.com/casper@lists.berkeley.edu/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 >>> "casper@lists.berkeley.edu <mailto:casper@lists.berkeley.edu>" group. >>> To unsubscribe from this group and stop receiving emails from it, send an >>> email to casper+unsubscr...@lists.berkeley.edu >>> <mailto:casper+unsubscr...@lists.berkeley.edu>. >>> 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 >> "casper@lists.berkeley.edu <mailto:casper@lists.berkeley.edu>" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to casper+unsubscr...@lists.berkeley.edu >> <mailto:casper+unsubscr...@lists.berkeley.edu>. >> 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 "casper@lists.berkeley.edu" group. To unsubscribe from this group and stop receiving emails from it, send an email to casper+unsubscr...@lists.berkeley.edu. To view this discussion on the web visit https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/ABFDBABC-BB6B-4CE6-BA34-6F7E09956AAB%40ieee.org.
