Forum Discussion

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

Which FFT core to use...need some advice.

I am implementing a 2D transform on images (256x256 for now). The image lines are fed thru the fft and the results stored in external memory that the fpga uses for frame buffering. Then the results are read back in (in transposed order) and fed thru the fft again.

I have been simulating using the streaming fft core but am having difficulty stopping the fft core between the two processing steps. I'm now questioning my decision to use the streaming architecture. I see that it offers the fastest thruput (at the expense of memory usage) but wonder if the burst architectures (buffered or not) might be better in terms of dealing with non-continuous signals in.

Does anyone have experience doing 2D transforms and, if so, which architecture did you use?

Thanks for any input you may have.

4 Replies

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

    thepancake

    I think I figured out how to stall the streaming core. I count lines and pixels going in so I know when all my data has been used. I am also counting lines and fft data out so I know when I have gotten all the required data.

    I push 3 extra lines in making sure I end the last extra line with the eop and immediately drop the sink_valid. The core flushes out the last 2+ lines of data and then keeps going for another 2+ lines before dropping source_valid. Since I count the output data, I only capture valid info.

    It looks like the core might flush itself if I am careful about ending input with an eop and not generating an extra sop. This is what the verilog testbench produced by the core generator shows.

    I'll try pulling it in later today to see what happens. I have an awful lot of processing to do in the freq. domain after the 2D fft and this is an imaging system so frame rate is key here. Shaving off unnecessary clock cycles is always a good thing.

    Since I can stream lines of video in from memory, seems like the streaming versions of the core gets me the fastest processing.

    If you think burst might be better, I'm all ears. I'm new to this core. Most of what I've done is spatial processing.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    17 years ago

    right, de-asserting sink_valid should stall the core. you should be able to do this mid-packet, not just between eop and sop.

    streaming (or the newer variable streaming) should be able to do what you are trying to do, i don't think you need to switch to burst.

    can you post simulation waveforms that show any problems you're running into?
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    17 years ago

    I don't think I need to stall the core mid-packet in my app. I can guarantee that the video frame can be streamed in uninterrupted. The video line length is the length of the fft. I just needed to stall the core between frames. This way, when I feed in a new frame, the source_valid signifies where my new output starts. Otherwise, I could just leave the core running and control when I start a new frame going in. The problem there would be the source_valid would be true all the time.

    Since I'm pulling pixels out of memory into a fifo to feed this thing, I already have counters going to know where line and frame boundaries are so I can just use those.

    Thanks for your thoughts.