Forum Discussion
Problems with FFT Megacore of Variable Streaming Floating Point Architecture
I've already used with success FFT Megacore of Variable Streaming Fixed Point architecture. Now I'm trying to use Floating Point architecture and it seems to me that the Core is not responding properly, although the auto-generated MATLAB model does.
For a real 32-samples input array, the output looks right for some samples and systematically not for others: the situation is represented for both real and imaginary parts of the output in the images I'm attaching. I'm also attaching a file .mat with the input array (fft_in), the output obtained from the core model (fft_out_model), the true FFT evaluated by MATLAB (fft_out_true) and the output produced by the core on the hardware (fft_out). I'm also attaching the SignalTap Logic Analyzer waveforms of the streaming interface: these waveforms are what makes me think the Core is not working properly. What could be the problem? How can I overcome that? Thank you in advance for any help you could give me. Regards, Lorenzo16 Replies
- Altera_Forum
Honored Contributor
I'm still trying the FP architecture but nothing works. In a even simpler case than the preceding one, giving a real constant input to the core gives back not even an hermitian symmetric output. I'm looking every streaming transaction on the SignalTap, so I have to suppose the core really has some internal issue about it.
Regards, Lorenzo - Altera_Forum
Honored Contributor
i don't have any useful input other than as you've found, the Variable Streaming FFT is the newest and most robust Altera FFT mode
- Altera_Forum
Honored Contributor
Hi thepancake, thank you for your answer.
First of all, I wanted to be sure there was no open known issue about it. So what you say makes me think I'm making some stupid mistake. I'm attaching the Avalon streaming waveforms I'm obtaining from SignalTap as a jpeg: they're not much clear, but if you would help me you should be able to understand what's going on on the external ports of my FFT core. I'm actually giving a constant (of value 100) real input and I'm not obtaining the FFT I'm expecting (only the first real sample to value 100*16, since the FFT is on 16 points). As I said in my last post, the output is even not an hermitian symmetrical one. What's your opinion about it? Regards, Lorenzo - Altera_Forum
Honored Contributor
If x = 100 16 times then its fft = 1600(first sample then zeros.
- Altera_Forum
Honored Contributor
Yes that's what I meant. And I couldn't obtain it from the FFT core. Any suggestion?
- Altera_Forum
Honored Contributor
Sorry I misunderstood you. In that case check your clocking scheme and try lowering speed for test purpose
- Altera_Forum
Honored Contributor
It is hard to read your files or pictures. Can you tell me what is your output then for 16(value 100) samples
- Altera_Forum
Honored Contributor
No problem, probably I didn't explain well.
Anyway, the following are the 16 output FFT points I obtain from the core (the clock frequency being 50 MHz). 0.000000e+000 +1j*-9.309915e-036 4.000000e-006 +1j*2.350989e-038 4.000000e-006 +1j*2.350989e-038 4.000000e-006 +1j*2.350989e-038 0.000000e+000 +1j*0.000000e+000 4.000000e-006 +1j*0.000000e+000 0.000000e+000 +1j*0.000000e+000 4.000000e-006 +1j*0.000000e+000 0.000000e+000 +1j*0.000000e+000 4.000000e-006 +1j*0.000000e+000 -2.000000e-006 +1j*0.000000e+000 4.000000e-006 +1j*0.000000e+000 0.000000e+000 +1j*0.000000e+000 4.000000e-006 +1j*0.000000e+000 0.000000e+000 +1j*0.000000e+000 4.000000e-006 +1j*0.000000e+000 - Altera_Forum
Honored Contributor
I just tried to lower the clock frequency to 25 MHz, but it gives me back the same response. QSYS tells me I cannot lower it anymore since the debug module I'm using works at clocks faster then 20 MHz.
Maybe some other informations could be useful for you to help me: I've set my FFT core for a maximum length of 1024 and for input and output sequences in natural order. I'm using a couple of SG-DMA in my QSYS system for writing to and reading from Avalon Streaming interface: for both SGDMA cores, data width is 64 bits (to accomodate real and imag 32-bits wide FFT data) and I've enabled automatic byte swap (bursting and unaligned transfers are disabled instead). - Altera_Forum
Honored Contributor
I'm actually obtaining more sensed results by having disabled automatic byte swap in SGDMA, which I found useful for fixed point variation before.
I'm still working on it (I haven't understood yet how it could impact on FFT core behaviour as seen on SignalTap)... so any other suggestion will still be appreciated :)