FPGA Intellectual Property
PCI Express*, Networking and Connectivity, Memory Interfaces, DSP IP, and Video IP
Intel Support hours are Monday-Fridays, 8am-5pm PST, except Holidays. Thanks to our community members who provide support during our down time or before we get to your questions. We appreciate you!

Need Forum Guidance? Click here
Search our FPGA Knowledge Articles here.
5950 Discussions

FFT megacore IP (source_sop is asserted for 2 cycles, sink_ready random deasserts)

Honored Contributor II



I'm having a couple of problems with the FFT IP core in variable streaming mode. When outputting the FFT transform results, the source_sop signal is asserted for two cycles instead of one. I thought this might be related to my sink_sop and eop signals, but these both pulse for one cycle only.  


My flow controller/FSM generally pulses sop, streams data of whatever size, pulses eop, then sets sink_valid to 0 for 1 cycle, which I use to give the core time to receive the new FFT size value. I believe this works for FFT sizes of 8, despite the SOP pulse width weirdness. However, when my testbench changes the FFT input size to 16, the sink_ready signal is de-asserted (perhaps I should just pause while I wait longer for the signal to be asserted again? I will try this in this meantime ). Due to this, the rest of my results are incorrect, and source error shows '11'. I believe this is due to the FFT internals, as my sink_error stays '00' for the entire time.  


I did some googling and found that people discovered a bug in the FFT core DSP with the ready signal deasserting, but that was a while ago (2008 IIRC), so I assume the problem fixed. I have attached a .png of my modelsim waveform. I am still learning Quartus etc, so am not sure what files are required to allow simulation. If anyone that can help requires extra waveform files etc, let me know and I will attach them.  


Thanks for taking your time to read this, I find this forum help invaluable.  


0 Kudos
2 Replies
Honored Contributor II

I think I know why sink_ready goes low, but still do not know how to fix the problem - When changing the FFT size, the data that was still in the pipeline must exit before the new data can be entered. The FFT core deasserts sink_ready while it is completing the existing workload. However, since posting the message, I have written in a waiting system such that whenever sink_ready goes low after a size change, the entire operation pauses. I am still getting errors with source EOP and errors being reported. My sink error stays 0, so it may be FFT internals going wrong somehow. I think my sink SOP is pulsing before I get time to pause the pipe, so I will attempt to fix that now

Honored Contributor II

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.