~256k 16b FFT performance on an embedded chip - ARM Micro?  FPGA?  DSP? - Page 1
Forum section: electronics / general

author: DaJMasta
author_rank: Super Contributor
timestamp: March 13, 2017, 02:10:41 am
content: I'm in the earliest stages of planning a project that involves a fairly high resolution FFT display in a handheld sized case (approximately a phone, maybe a little thicker), and while I think I know what sort of performance I want, I don't know what kind of chip architecture will be the most suitable. I have some experience working with STM32 ARM chips, and as I understand you can get some pretty decent computational performance out of the higher end ones, but I'm not sure it could even get near what I'm looking it, so I'd like to know if DSP or FPGA/CPLD architectures would be better suited to the task - or even if there is some other thing that would be best.Looking for ~256k usable bins with a 16 bit depth. For this application, dynamic range isn't hugely important, but frequency resolution is.To the frequency resolution end, I also will be overlapping several (3-8) frames, but I don't need any long-term storage capability - the overlapped output will be displayed in real time and that's itThe stored frames will not actually need to be 256k by 16b in size, because I intend to group higher frequency bins for a logarithmic displayFor a performance goal, I'm aiming for 20 frames per second, but 10 would be sufficient.That's a ballpark 2-5M FFT calculations a second, some relatively simple averaging en masse, and a few MB of quick memory needed.Aside from FFT and frame overlap calculations, I really only need basic input and output performance - monitoring some buttons and driving a monochrome low resolution graphic display, and this can certainly be done on a different chip if need be. The ADC will be external, 16 bit 96kHz, stretched in the processor to keep the sample rate from tanking FFT performance. The frequencies being looked at are all audio band, so it will be basically direct buffered input to the ADC.The trouble is, I don't have the experience to really know how taxing FFT calculations would be or what architectures are realistically capable of this kind of work. The purpose of asking is so that after a bit more planning and research, I can get a dev board and actually verify the performance and build up a rudimentary prototype.Edited for a better ADC choice.

author: Marco
author_rank: Super Contributor
timestamp: March 13, 2017, 02:24:29 am
content: Quote from: DaJMasta on March 13, 2017, 02:10:41 amIt doesn't work like that.QuoteWhy are you sampling an audio signal at 10 Msps?

author: DaJMasta
author_rank: Super Contributor
timestamp: March 13, 2017, 02:56:00 am
content: Because when I recalculated how many bins I needed for the resolution I was looking for, my knee-jerk reaction was to think about increasing the sample rate.I think 96kHz over an I2S bus and a little padding is probably plenty.

author: BrianHG
author_rank: Super Contributor
timestamp: March 13, 2017, 04:12:32 am
content: Any cell phone or tablet computer with 3D capabilities can do this today. The key is you use the GPU to compute the FFT, as many already do for high end audio processing. You'll should be able to run circles around what you need.If you are only processing 1 or 2 channels, this is overkill by at least an order of magnitude if not more, but it is efficient since the GPU is hard wired to do so many multiply adds in parallel. Also, learning how to program the 3D pixel shaders to perform the math is tricky, or you can google for existing code examples out there, but now, your main CPU load is close to 0%.

author: Marco
author_rank: Super Contributor
timestamp: March 13, 2017, 05:58:13 am
content: Quote from: DaJMasta on March 13, 2017, 02:56:00 amDoesn't work, the frequency resolution of a DFT is 1/T. You get more bins at higher sampling rates, because you get a larger frequency range.

author: ehughes
author_rank: Frequent Contributor
timestamp: March 15, 2017, 03:54:03 am
content: A short time fourier transform gets you good resolution in time... Or in frequency. You don't get both.You might want to go back to the drawing board and ask the question if you really need 256k bins. This number sounds a bit ridiculous if you are trying to make a spectrum display.How many bins do you really need assuming a logarithmic spacing?An FPGA is the only thing that will come close to do what you want to do at a reasonable power consumption spec. And plan on getting something that is really expensive. Your million FFT/sec sounds a bit suspect that you don't have the correct algorithm.

author: BrianHG
author_rank: Super Contributor
timestamp: March 15, 2017, 12:28:36 pm
content: Quote from: ehughes on March 15, 2017, 03:54:03 amEven a cheap Rasberi PI's GPU can accelerate FFT with 128kpoint with around 20hz refresh. Any faster 3D accelerated GPU will run a lot faster. You also get a display, and network, OS, & sound with these boards, let alone using some of the bigger power houses PC boards at 85$ with 192Khz audio, 4k display, full blown WiFi Blue tooth, 1G LAN. There exists enough public domain code out there to give you sample configurable FFTs with different bit depths, usually integer, or FP16...

author: splin
author_rank: Frequent Contributor
timestamp: March 15, 2017, 02:29:31 pm
content: There are some benchmark results for an optimized Cortex M3 DSP library here:http://www.embeddedsignals.com/FFTlibrary2bench.pdfThe FFT source code (at least some of it) can be found here:https://e2e.ti.com/support/microcontrollers/stellaris_arm/f/471/t/44034The biggest FFT is 4096 though but you can see the relationship between proceesing time and size.ST show some complex FFT results for an M4 and M7 here:http://www.st.com/content/ccc/resource/technical/document/application_note/group0/c1/ee/18/7a/f9/45/45/3b/DM00273990/files/DM00273990.pdf/jcr:content/translations/en.DM00273990.pdfThe M4 results are not as good as the previous M3 library as they use the standard CMSIS implementation in C.It may well not be possible to get much better performance on an M4 for the non-floating point versions as the DSP enhancements in the M4 may not be useful for FFTs. Of course if anyone knows of any good M4 FFT implementations, please tell.

author: ehughes
author_rank: Frequent Contributor
timestamp: March 15, 2017, 02:42:38 pm
content: QuoteI am unsure if that is what he wants, or a "2-5M FFT/sec". These specs seem to be in conflict.Etiher way, a 256k FFT sounds fishy. I have *rarely* if *ever* seen that large of an FFT needed for anything in 20 years of doing DSP on high end FPGAs and DSPs. When it gets to that size, it is usually to implement circular convolution for some ridiculous reverb algorithm.In every case when someone thought they needed an FFT that large, they almost always didn't understand their own problem.

author: BrianHG
author_rank: Super Contributor
timestamp: March 15, 2017, 03:59:19 pm
content: Quote from: ehughes on March 15, 2017, 02:42:38 pmWhich is why i went with a processor combination which can do 128k point FFT, 20 times a second as per his request. I figures he is trying to create an audio spectrum analyzer with enough points to show many bands in the low frequency range, below 100hz. When plotting the table on a log frequency scale, yes the upper frequency bands are lost since he wont have a high enough resolution display, but, down below 100hz, the band spacing gets fat and ugly with say 4k point. On the other hand, for audio, above 16k point is getting absurd.To get the processing power he wants for that 2-5m FFT/sec, Nvidia Cuda library has a 1D and 2D FFT library function for their video cards. If he were to use one of those with a NVidia 1080ti video card using over 10 T-Flops of processing power, now he can get the speed he wants. Though, the power consumption, a full blown desktop PC, cooling and everything else...

author: Kalvin
author_rank: Super Contributor
timestamp: March 15, 2017, 05:29:57 pm
content: If the purpose is to achieve fine frequency resolution at the low frequencies, one could also use multirate digital signal processing with decimating half-band filtering and perform shorter FFT in each filter bank instead of using just raw computing power.

author: bson
author_rank: Unknown
timestamp: March 18, 2017, 06:16:13 pm
content: For a pure log frequency display (no phase) it might be better to use a whole bunch of FIR bandpass filters and do basic peak measurements. Naively, for 200 frequency points (0-20kHz by decade) and order 5 you'd need 1000 FIR convolution steps. The result of each of the 200 taps doesn't need to be kept, just the peak value which you decay, say by dividing it by two eachsample periodbandpass filter cycle. This is computationally less complex (O(n) vs O(nlogn)) than obtaining the same from an RFFT, never mind the FFT won't give you a log distribution.

author: Kleinstein
author_rank: Super Contributor
timestamp: March 18, 2017, 07:31:35 pm
content: The multi rate FFT is likely the way to get high resolution for the low frequencies and a fast update rate for the higher frequencies. As a first step, there is no much sense in starting with more than about 48 kHz data rate for audio - this already reduces the data by half.For the higher frequencies a relatively short window is enough - one also needs it to get a fast display update rate for this range. So something like 4096 point FFT (and thus about a 80 ms Window) should be good enough for much of the frequencies. For the low frequency end, a larger data window of maybe 1 second (to get 1 Hz resolution) could be needed - but no high data rate anymore - so maybe 4 kHz could be enough and thus again a 4096 points FFT. So for this crude concept one would have two FFTs with 4096 points and some decimation / averaging instead of a maybe 32000 or 65000 points FFT. Besides less raw computation this would also reduce the amount of fast memory access needed - this can be a big advantage as chip internal RAM can be much faster than external RAM.This was just a very crude example for multirate calculation. One might also decide to use more than 2 ranges and than even smaller FFT chunks (e.g. 1024). The idea is doing decimation on the raw data instead of later combining FFT bins that are to close together anyway.

author: Lovely_Santa
author_rank: Contributor
timestamp: March 18, 2017, 09:41:45 pm
content: Quote from: DaJMasta on March 13, 2017, 02:56:00 amIf you want to measure audio signals, they are sampeled at 44K1Hz, Let for now just assume you apply a perfect sine wave with some little noise on it (1% or so)...If you sample at a rate of 44K1Hz, you will get your sine wave and almost nothing of the noise, becose it's not capable of registering the high frequency noise inside it. So it acts as a low pass filter. When you apply an fft on your signal, and you surely won't measure the perfect sine (becose of the margin on the ADC for example), you will still get your single spike at your frequency of the sine wave, and maybe some little noise arounnd your sample rate becose of the noise (as on sample rate/2, rate/4 etc)becose of the nyquist theoreme and the way you will register the noise with the ADC...So this is the normal noise you won't be able to filter with an analoge filter (here I assume the fft acts as an analoge filter, but that's just how it's made, i know it's not correct) When you sample at twice that frequency, you still will get your mayor spike at the frequency of your sine wave you aplied, but you will also get a spike at double the frequency, becose you won't sample 100% correctly, but that spike won't be as intense as the first one. This means your resolution = 1/T will rise as Marco said, but the faults you make by the noise are waaay to big versus the resolution gain.A solution for this problem is to apply a digital filter before applieing the fft, so you filter noise and avarage first. If you want the high resolution you where talking about, you should add 9 times more 0's at the begin and and (4.5 times the amount of zeros on both sides), so you will have 10 times as much samples as you had first, this will result in a surpression of the amplitude of the spikes that aren't in your sample, without loosing detailed information of your sample signal.Quote from: Kalvin on March 15, 2017, 05:29:57 pmWhat he said! ^^If you want some background and detailed information how to make an fft with dsp, I recommend the book Digital Signal Processing from Schaum's outline written by Monson Hayel (prof. Electrical & Computer Engineering)