Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
8 years ago

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

Hi,

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.

ap29

2 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    8 years ago

    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

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    8 years ago

    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.