FFT 8.0, sink_ready de-asserted

[Altera_Forum]

Hi, 

 I am trying to test the functionality of FFT version 8.0. The device family that I am using is Cyclone II. Below is the parameter of the FFT:   Transform Length: 64 points Data Precision: 8 bits Twiddle Precision: 8 bits I/O Data Flow: Streaming Structure: 4 Mults/2Adders Implement Multipliers in: DSP Blocks/Logic Cells Twiddle ROM Distribution 100% M4K   As for the FFT input, I wrote a FSM code for it. My input looks fine, sink_sop, sink_eop and sink_valid are where it is suppose to be. However sink_ready was asserted at the beginning, one clock cycle before sink_valid and sink_sop were asserted. Then sink_ready was de-asserted half way before sink_eop (before 64 data ends). As a result, source_error shows “11”; meaning that EOP is asserted before 64 valid samples are accepted.    Since I am using streaming architecture, I thought this architecture allows continuous processing of input data and outputs a continuous complex data stream. So that means the sink_ready was suppose to be asserted all the time isn’t it? Unlike in buffered burst and burst architecture, sink_ready signal will be de-asserted when FIFO is filled. So why for streaming architecture in my case, the sink_ready can be de-asserted causing it unable to accept data? Does anyone know this answer?

[Altera_Forum]

the sink_ready signal shouldn't be deasserted. can you post screenshots of your simulation?

[Altera_Forum]

--- Quote Start ---  the sink_ready signal shouldn't be deasserted. can you post screenshots of your simulation?  --- Quote End ---       Hi,    Thanks thepancake for your reply.   Here is it. Does had to do with my input? The input should be fixed point complex number right? If my input is -97- j97 and I set the radix as signed decimal, is it wrong?

[Altera_Forum]

--- Quote Start ---  Hi,    Thanks thepancake for your reply.   Here is it. Does had to do with my input? The input should be fixed point complex number right? If my input is -97- j97 and I set the radix as signed decimal, is it wrong?  --- Quote End ---       Sorry, image seems small. I attach again here.

[Altera_Forum]

what does the input clock look like? is it running at the same speed as the imaginary data is changing, or the real data? 

 leaving source_ready asserted all the time is legal but i don't think it will solve your problem.  i simulated an FFT core with your settings in Quartus 8.0 SP1 using Altera's testbench and i got the expected results.

[Altera_Forum]

--- Quote Start ---  what does the input clock look like? is it running at the same speed as the imaginary data is changing, or the real data?   leaving source_ready asserted all the time is legal but i don't think it will solve your problem.   i simulated an FFT core with your settings in Quartus 8.0 SP1 using Altera's testbench and i got the expected results.  --- Quote End ---       Hi,  Thanks thepancake. I zoom in the image closer so you can see.

[Altera_Forum]

ok your clock looks right. 

 try asserting reset_n?

[Altera_Forum]

--- Quote Start ---  ok your clock looks right.   try asserting reset_n?  --- Quote End ---       Yup, the reset_n was asserted.

[Altera_Forum]

in both of your pictures reset_n has not been asserted (set to '0'), right?

[Altera_Forum]

Nope. For both picture both reset_n was set high. If reset_n was set (0) the sink_ready will be (0).

[Altera_Forum]

i understand that, but you should try asserting reset_n for the first few clocks of your simulation.

[Altera_Forum]

Hi thepancake, 

May I know how did you get your expected result? Can you show me your waveform too? Maybe I can learn something from there.

[Altera_Forum]

i just used the Altera provided test bench in ModelSim. you should be able to run it too but i'll take a screen shot.

[Altera_Forum]

attached is a screen shot of the Altera test bench in ModelSim.

[Altera_Forum]

Hi, 

Thanks a lot thepancake. I will try to deal with the reset_n, and let you know how it goes soon.

[Altera_Forum]

--- Quote Start ---  i understand that, but you should try asserting reset_n for the first few clocks of your simulation.  --- Quote End ---     Hi,   I have with me a new waveform, with some changes in the reset_n. But the FFT block still display the same error (source_error = 11). It seems like it was able to accept data, but not all the N valid samples are accepted due to sink_ready that de-asserted half way through the process.

[Altera_Forum]

--- Quote Start ---  Then sink_ready was de-asserted half way before sink_eop (before 64 data ends). As a result, source_error shows “11”; meaning that EOP is asserted before 64 valid samples are accepted.   --- Quote End ---    looks like this error only pertains to sink_error. for source_error:  11 = other error  pg. 49 FFT user guide

[Altera_Forum]

i tried with 8.0 (i was using 8.0 sp1) and still can't reproduce your error with the Altera test bench. 

 can you post your testbench file?

[Altera_Forum]

ok i made my own test bench and tested the core (8.0sp1). i still can't reproduce your error, everything looks fine. :mad: 

 your state machine timing looks right to me. how are you feeding the real/imaginary data to the core?

[Altera_Forum]

--- Quote Start ---  ok i made my own test bench and tested the core (8.0sp1). i still can't reproduce your error, everything looks fine. :mad:   your state machine timing looks right to me. how are you feeding the real/imaginary data to the core?  --- Quote End ---       Hi,   Thanks for the efforts thepancake. http://www.alteraforum.com/forum//images/icons/icon7.gif  The real/imaginary data comes from a FSM code that I wrote in VHDL. The code was nothing confidential, I just create it to test the FFT. Here, please have a look at it. I use functional simulation mode to test it. We can all learn from it.

[Altera_Forum]

hey bellman i haven't been able to test you're code today but i do intend to check out what's going on. 

 in the mean time you may want to try just running a test bench straight into the FFT core to see if you can repeat my second result.