Burst FFT SOP Error

Altera_Forum · ‎11-07-2012

Hi,

I'm currently working on a burst fft core implementation. The problem is, I always get an error code 0x1 from the source_error bus of the fft block.

The errors description is "Asserted when valid goes high, but there is no start of frame".

I have succesfully simulated the core in modelsim (even with my own input data in order to get the desired frequency spectrum).

Now, I try to implement it in my cyclone III device and I think, that I#ve done everything according to the documentation and it also looks quiet similar to the signal flow in my succesful modelsim simulation. However, I always get the error and don't know, why.

I attached three signal tap screenshots in order to show the signal flow to the fft core. I would be very hapy if there is somebody who can tell what is wrong with my signal timings.

Thanks in advance,

Maik

Altera_Forum · ‎11-08-2012

Hi,

I just realized that there is a DSP IP sub forum, too. Maybe someone can move this thread over there and I possibly can get an answer there.

The problem really drives me crazy because I think everything is set up okay but it just is not working. Since it is working in modelsim, I always have to recompile my design for every bit I change in order to get it running. Depending on what bit I change, the compile times vary between 5 and 35 minutes. many time was wasted this way and I've got no idea anymore what to do next.

Regards,

Maik

Altera_Forum · ‎11-08-2012

I think the DSP Builder/IP subforum is more about the DSP builder and its specific IPs. The FFT core is also a generic megafunction that can be used outside of DSP builder, so I think your thread can stay here. I think that most of us read all the subforums anyway, so placement isn't that critical. ;)

Looking at your third attachment, I see that you indeed assert the 'end of packet' signal after 2048 data values, but on the cycle just after that, the valid signal is still asserted, but not start of packet. You are pushing data to the FFT core without placing it inside a packet. You should do one of those two things:[list][*]either you want to send immediately a new set of values to the FFT core, and in that case you should assert the start of packet signal on cycle 2048[*]or you are done for now and don't need a new FFT calculation, and in that case de-assert the valid signal on cycle 2048 and wait for the result[/list]

I'm surprised this didn't show up on the Modelsim simulation.

Altera_Forum · ‎11-08-2012

Hi Daixiwen,

you are the saviour :D !

It was exactly that what you suggested. I'm honest that I was just looking and investigating around the sink_sop signal (because the error message said so). I had no idea that it meant a "virtual" sop AFTER I set my sink_eop signal, but did not pull down sink_valid. I was just focusing on the wrong end of my package.

I also honestly admit that the signal is driven low in modelsim, too, after the eop signal was asserted. But as I said that was not the place I spend my energy on . . .

Thank you!

Maik