FFT v6.1 - sink_ready de-asserting by itself

[Altera_Forum]

I have encountered a problem in FFT v6.1 (streaming architecture). It seems like the core is de-asserting sink_ready signal (for exactly three cycles) even if the core is not back-pressured.  

 This has caused me many sleepless nights Not expecting the sink_ready signal to go low by itself, I kept feeding data into the core. Needless to say, the core did not get three data points. Consequently, I asserted sink_eop exactly three cycles too early. This really messed up the core as it asserts source_eop before it asserts source_sop.  I checked with Altera. They claimed that this is technically not an illegal behavior for the Avalon Streaming protocol. However, they did agree that the behavior is not desirable and promised to fix this problem in a future release. For the meantime, they have suggested two temporary work-arounds:  a. Use variable streaming mode and tie the transform size to a fix number. b. Insert a fifo (depth of 4) in front of the FFT core.  Hope this helps.

[Altera_Forum]

Here is a FFT example (built in DSP Builder) to get around the sink_ready de-asserting problem.

[Altera_Forum]

Something I have noticed about FFT v6.1 is that if you are running multiple FFTs in parallel with synchronized controls, the constants that are used are not shared, leading to large memory usage. In the previous version of the FFT core the constants would be shared, leading to lower overall memory requirements.

[Altera_Forum]

the problem with sinc_ready has been fixed in the latest 7.1 relase of the FFT core