| Author |
Message |
Nilnod
Guest
|
Posted:
Thu Dec 09, 2004 9:34 am Post subject:
1024-point FFT buffer size of OFDM receiver |
|
|
Hi,
In a typical application of OFDM receiver an 8 bit -ADC is sampled at
6.4 Msamples/s. I have to take ADC output
through a serial port. After transfering to memory I need to perform
1024-point FFT on real time basis.
What should be my optimum buffer size. Do we need to know FFT
processing delay, Clock speed of the processor etc. in advance?
I thought it should be 2*1024 - Is that correct? (consider :: One
memory unit holds a complex sample)
Santosh |
|
| Back to top |
|
 |
Ravi Srikantiah
Guest
|
Posted:
Thu Dec 09, 2004 4:36 pm Post subject:
Re: 1024-point FFT buffer size of OFDM receiver |
|
|
Typically, you'd be getting the samples and performing the FFT in a
pipelined fashion. So you'd need two 1024 sample buffers - one to hold
your input and the other on which you'd be performing your FFT. Of
course, this assumes that the processor is fast enough to complete the
FFT and all other processing BEFORE the next block of data is ready.
If your sampling clock is 6.4MHz, then you have a 1024-point blockset
available in 160us. So you need to make sure that your DSP can finish
other processing and free up the buffer before then.
As an example, the c64x requires about 6000 cycles to do a 1024 point
complex fft (see
http://dspvillage.ti.com/docs/catalog/generation/details.jhtml?templateId=5154&path=templatedata/cm/dspdetail/data/c64_benchmarks).
If you have a c64x running at 500MHz, then it would need 12us to
complete the FFT giving it (160-12)us for other processing. If all your
other processing with the data can be completed in that time, then
you're ok.
Of course, you need to be careful of benchmark numbers you accept and
estimate all the other tasks your dsp is loaded with.
- Ravi |
|
| Back to top |
|
 |
Ravi Srikantiah
Guest
|
Posted:
Fri Dec 10, 2004 11:02 am Post subject:
Re: 1024-point FFT buffer size of OFDM receiver |
|
|
Ravi Srikantiah wrote:
| Quote: | Typically, you'd be getting the samples and performing the FFT in a
pipelined fashion. So you'd need two 1024 sample buffers - one to hold
your input and the other on which you'd be performing your FFT. Of
course, this assumes that the processor is fast enough to complete the
FFT and all other processing BEFORE the next block of data is ready.
If your sampling clock is 6.4MHz, then you have a 1024-point blockset
available in 160us. So you need to make sure that your DSP can finish
other processing and free up the buffer before then.
As an example, the c64x requires about 6000 cycles to do a 1024 point
complex fft (see
http://dspvillage.ti.com/docs/catalog/generation/details.jhtml?templateId=5154&path=templatedata/cm/dspdetail/data/c64_benchmarks).
If you have a c64x running at 500MHz, then it would need 12us to
complete the FFT giving it (160-12)us for other processing. If all your
other processing with the data can be completed in that time, then
you're ok.
Of course, you need to be careful of benchmark numbers you accept and
estimate all the other tasks your dsp is loaded with.
- Ravi
|
Actually, you really don't need two complete buffers. You only need 1.x
buffers depending on the speed of your DSP. Continuing with the above
example, if say, all processing by the dsp only took 60us, then the dsp
could free up the buffer after that time, you'd only need a buffer to
store incoming samples for the 60us that the dsp is using the 1024-point
buffer. 60us time translates to 384 samples at 6.4MHz, so you'd need a
(1024+384) sample buffer.
- Ravi |
|
| Back to top |
|
 |
|
|
|
|