FFT problem. Simulation vs HW's execution

If you have 4 instants of same ip in parallel with exactly same input then they should give same output.

If not either your inputs are not timed together or you have timing problem.|Have you set your sdc timing constraints?

--- Quote Start ---

If you have 4 instants of same ip in parallel with exactly same input then they should give same output.

If not either your inputs are not timed together or you have timing problem.|Have you set your sdc timing constraints?

--- Quote End ---

Yes i have one sdc with timing constraints. The sdc has a lot of constraints related the GIDEL plataform, but related to my desing it has only one constraint about the frequency of the clock of my top module.

Thanks for the fast reply!!!

if internal clock is declared then it should be enough for fft check.

io constraints may also be relevant if fft inputs/outputs go across io. If your slack is positive then check inputs to all ffts in signaltap.

even a single input variation such as a zero or repeated sample will result in difference as fft is frame based and the whole frame should be identical for all four ffts. Is your sampling rate correct (if different from system clock)

you may also try single tone input to see a line spectrum indicating that it might be functionally correct after all.

The plataform that the GIDEL provides look like this:

It has a memory controller that reads or writes data from/to the DDR2 and it has the interface based in FIFOs. The controller makes a burst to read some data and store it in FIFOs, so when the user makes a request of a new data, he is actually reading the FIFO. The write operation is look like, the user writes in another FIFO and the controller reads the data from that FIFO and makes a burst to the DDR2.

The clock is one input of the top module of the plataform. The clock is generated on PLL outside the top module of the plataform. It is configured by SW, so in the application that communicates with the HW you can define the frequency of the clock.

So the data that is inputed in the FFTs are not coming from the pins of the FPGA, and the data generated by then is not going to the pins, too.

I've already checked the inputs and outputs of the FFTs in the signaltaps. There, I've seen that the inputs are being provided in the same time to all 4 FFTs (same clock cycle), but the response of one FFT is one clock cycle before or after the others. And in the signaltap i've seen that the outputs values were wrong. For example, sometimes the expoent were giving a positive value, and according to the documentation it is impossible.

The inputs of each FFT is different from another, but i've compared each input and output of the FFTs in HW with the inputs and outputs of the simulation.

Thanks.

Before we blame fft core we must make sure the whole input frames are same to all 4 ffts. Don't just compare four different results with sim results as this could be misleading. Are you sure the fifos are getting data correctly? Or can you just look at whole frames at inputs/outputs of fft directly and not just few samples. Is start of frame ...etc all correct as well. If your clock is variable I take it you have constrained for fastest case.

If indeed you inject same input frames into same instants of fifos and you get different results then I will blame fifos. If however you get good results by lowering frequency then something else is wrong such as timing or your control signals logic.

We really belive that the control is correct. Maybe the GIDEL plataform are reading the data in a wrong way, but I believe we are facing timimg problems, because using the frequency at 125MHz and 250MHz the plataform is doing fine. But only in this two frequency. In the sdc I've requested 250 MHz in the clock that is going to be used in my top module. So if I configure the clock to 100MHz, for example, the outputs of the FFTs are differents.

Thanks.

If timing report is ok then at least we know that internal logic (fft) should behave well at any speed up to fmax.

If io constraints are not right but you are not reading them in your analysis (rather you read inputs/outputs of fft directly) then you can ignore io for now.

try freezer testing if it forces a change.

What do you mean by freezer the test?!

The timing report is ok, execept by the the false paths warnings related to the GIDEL constraints.

I'm thinking in replace the FFTs per altera's adders, and see if the architecture will behavior like it shoud at any frequency!

Thanks!

freeze the fpga using freezing spray (not ice blocks). Brings temperature down to zero or so and see if design shows any improvement by monitoring the outputs of ffts.

If so it is viewed as definite test of timing failure.

We've replaced the FFTs by Adders+Multipliers+Divisor, and everything was right! The ideia was to replace the FFT by something that is a little big. So we really think that the Altera`s FFT have some problem in the execution in FPGA.

Best regards.