FPGA Intellectual Property
PCI Express*, Networking and Connectivity, Memory Interfaces, DSP IP, and Video IP
6359 Discussions

Altera FFT IP-CORE core version 9

Altera_Forum
Honored Contributor II
1,208 Views

Is there someone who would knows the Altera FFT IP-CORE core version 9? 

 

Thank you 

 

Jean
0 Kudos
8 Replies
Altera_Forum
Honored Contributor II
366 Views

What's your question about it. i'm currently using this core in a 256 FFT streaming form for a design. 

 

It seems to work as advertised, Although the interface isn't the most straight forward. 

 

Pete
0 Kudos
Altera_Forum
Honored Contributor II
366 Views

Allo, 

 

I have a small problem with the FFT core! 

 

i try to run the fft core in mode: 

IFFT 

burst 

INPUT: 8192 samples @ 16bits (I do not use the imaginary part) 

OUTPUT: 8196 samples @ 16 bits. (I do not use the imaginary part) 

Twiddle : 8bits 

Single Output 

FFT engines : 2 

 

My clock is 100Mhz, clk_ena is actif high and the reset_n (actif low) was activated at first. 

 

Sink_ready signal is still high (active) and according to the doc, it should be active only for the length of a block (FIFO) and this length, I do not know !!!!! 

 

The doc says: 

 

In a burst I/O data flow architecture, the core can process a single input block only. 

There is a small FIFO buffer at the sink of the block and sink_ready is not 

deasserted until this FIFO buffer is full. Thus you can provide a small number of 

additional input samples associated with the subsequent input block. It is not 

mandatory to provide data to the FFT during sink_ready cycles. The burst 

architecture can load the rest of the subsequent FFT frame only when the previous 

transform has been fully unloaded. 

 

What is the size of the FIFO in burst mode ?  

Why Sink_ready does not fall down when the FIFO is full? 

Why Source_valid is never valid even if source_ready is valid? 

 

Thanks
0 Kudos
Altera_Forum
Honored Contributor II
366 Views

 

--- Quote Start ---  

Allo, 

 

I have a small problem with the FFT core! 

 

What is the size of the FIFO in burst mode ?  

 

--- Quote End ---  

 

 

Basically I don't know, but my guess is they start the transform before end of the input writes, So with a dual core, if the input buffer is 8k, you could potentially keep running, for up to 3/4ths the second transform before the input buffer is seen as "Full". (I don't think it's a fifo in the classical since. 

 

 

 

--- Quote Start ---  

 

Why Sink_ready does not fall down when the FIFO is full? 

 

--- Quote End ---  

 

 

My guess again is you are not running enough clocks. If you have your sink_sop and sink_eop, if you don't do a second sink_sop it will never get full since it will no longer be writing data into the input buffer. 

 

If you have the sink_sop and sink_eop in the wrong place, you will get unknown results. 

 

So my guess is you ended the first transform with sink_eop, but never started the second, so there's no new data getting written into the input buffer. Hard to say without the simulation results however. Also make sure you sink_error = 0. If it's non-zero, then you may be off in your counts for sink_sop/sink_eop positions. 

 

 

--- Quote Start ---  

 

Why Source_valid is never valid even if source_ready is valid? 

 

--- Quote End ---  

 

 

Did you give it a sink_sop?  

Is sink_error zero?  

Have you ran enough clock cycles for it to complete the transform? 

Is source_error zero? 

 

Those are my thoughts. Also having the twiddle factor size not equal the data size could potentially expose a bug in the core generator. With an 8k transform I would suggest you keep the twiddle factors at least 16 bits, and maybe larger. Hardware wise, other than the memory for the twiddle ROM you really aren't saving much, and you are loosing accuracy. 

 

If the 3 items above are correct, then I suggest re-trying with 16 bit twiddle rom and seeing if it all of a sudden starts to work, then you can post a bug to altera about the 8 bit twiddle issue (if that's it). It would be the first time a specific configuration of the core had issues. I've found several over the years with the various versions. 

 

Also for simulation you could try the streaming core and see if you have any better luck. Hardware wise it takes some more logic, but you could compare results and see if it's acting better than your "Burst" mode core. 

 

 

Hope this helps. 

 

Pete
0 Kudos
Altera_Forum
Honored Contributor II
366 Views

Thank you pete, 

 

I'll try that tomorrow morning (16bits twiddles). 

 

What is the exact definition of Twiddle ? 

 

Do you have a function to convert Bit reverse to natural order ? 

Do you have a doc about bit order definition ? 

 

Thank you very much Pete, I appreciate. 

 

Jean 

0 Kudos
Altera_Forum
Honored Contributor II
366 Views

Hi Jean: 

 

I'm just running out of the office, so I'll post some more tomorrow: 

 

In layman's terms, the twiddle factors are basically sin()/cos() table lookups used in the fft calculation. I'm sure a math guru would have a complicated explanation, but that's the simple answer. The size of the table is dependent on the size of the FFT, and the size of the and in general the more points you are doing the more number of bits you should have in your twiddle table. 

 

I don't have anything off the shelf, but it's not too complicated to do. I'll dig up a doc tomorrow on it. In general unless the Burst core is different the core should like everything in natural order, so you should only require this if your source data for your IFFT is in reverse order. 

 

I'll dig up a doc, and send you what I have tomorrow. I happen to be writing a FFT core now for an asic conversion, so I have a few around. 

 

Pete
0 Kudos
Altera_Forum
Honored Contributor II
366 Views

Thank you very much Pete :)  

 

Jean
0 Kudos
Altera_Forum
Honored Contributor II
366 Views

Hi Jean: 

 

http://www.dspguide.com/ch12/2.htm 

 

has a pretty good description on the bit-reversal. Basically all you need to do is read hook up the address bits in reverse order, and you are good to go. IE if the data is in a ram block in bit reversed order, if you hook up the address bits backwards on the read port so instead of A7,A6,A5,A4,A3,A2,A1,A0 and they are hooked up A0, A1,A2,A3,A4,A5,A6,A7 you will get the data back in natural order. 

 

I should have remembered this, but I'm working on a Radix-4 engine, so it's slightly different, In that case you "Digit-Reverse" the addresses 2 bits at a time, so in this case, 

instead of A7, A6, A5, A4,A3,A2,A1,A0 it's A1,A0, A3,A2, A5,A4, A7,A6.  

 

Pete
0 Kudos
Altera_Forum
Honored Contributor II
366 Views

Hello pete, 

 

Again, thank very much. 

I tried my IFFT 8192 bins with 16bits twiddle in burst mode and It's work very well. :) (the FIFO = Trandform length) 

 

Also, in variable streaming mode, It's work very weel (for my receiver) but I have a question ! 

 

My input bin is 8192 samples @16bits presision and the output (variable streaming mode with 16bits twiddles) and the output is 32 bits !!!! 

(No floating point) 

 

What is the relationship between them? 

 

Jean
0 Kudos
Reply