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?链接已复制
33 回复数
--- 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?
--- 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.
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 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.
--- 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.
--- 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
--- 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.
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.