Showing results for 
Search instead for 
Did you mean: 
Honored Contributor I

FFT megacore (variable-stream) sink_ready deasserts after dynamic size change 16->32

Hi, it is me again. 


In my previous thread on the FFT IP ( core I posted this:  



--- Quote Start ---  

I attempted to fix this behaviour by simultaneously changing fft size at the same time as SOP is pulsed - this is written in the documentation and I missed this the first time. However, I found a section missing in the documentation - page 33 of the May 2016 version of the FFT altera megacore pdf, the steps are not listed for changing fft size dynamically - It appears the section was started but is incomplete as it only states: '1. Change the size of the incoming FFT,' and nothing else before moving onto the next section. Anyway, I found that I could change the size up from 8 to 16, and after the pipeline flushes the data of fft size 8, sink_ready is reasserted and fft sizes of 16 are fine to be passed through. HOWEVER, when changing from size 16 to 32 in the same manner, sink_ready seems to never be reasserted, even after waiting for 1000s of cycles. I will move this to a fresh thread as the problem is now only semi-related to the original thread title.  


--- Quote End ---  



The idea is that I test my pipeline and FSM all the way from length 8 to length 256 which is the max size of my FFT IP. When changing from 16 to 32, my FSM cannot proceed further as sink_ready is de-asserted and never reasserted.  


I am going to attempt to fix this in the meantime, although if anyone on these forums has used the core before with variable size streaming implementation, I would be grateful for any advice/help. 


Thanks for your time. 


Tags (1)
0 Kudos
2 Replies
Honored Contributor I

I found this thread which discusses sink_ready never asserting ( - however, I believe these users had these problems due to resetn not being set properly when initializing the core. As my core works correctly for size 8, I think this is not the same problem that I am having. But it might help anyone that comes across this thread before finding that thread...

Honored Contributor I

Okay, I was able to fix this problem after carefully timing events as the size changes. SOP should pulse on the same cycle as fftpts_in is changed, and on the next cycle, I de-asserted sink_valid to prevent loading of more data into FFT while the FFT is outputting results of previous size. While this is happening, sink_ready is de-asserted by the core. This can now reassert when the pipeline is empty.