FPGA Intellectual Property
PCI Express*, Networking and Connectivity, Memory Interfaces, DSP IP, and Video IP
Announcements
Intel Support hours are Monday-Fridays, 8am-5pm PST, except Holidays. Thanks to our community members who provide support during our down time or before we get to your questions. We appreciate you!

Need Forum Guidance? Click here
Search our FPGA Knowledge Articles here.
5915 Discussions

FFT 8.0, sink_ready de-asserted

Altera_Forum
Honored Contributor II
2,898 Views

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?
0 Kudos
33 Replies
Altera_Forum
Honored Contributor II
112 Views

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

Altera_Forum
Honored Contributor II
112 Views

 

--- 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
Honored Contributor II
112 Views

 

--- 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
Honored Contributor II
112 Views

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
Honored Contributor II
112 Views

 

--- 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
Honored Contributor II
112 Views

ok your clock looks right. 

 

try asserting reset_n?
Altera_Forum
Honored Contributor II
112 Views

 

--- Quote Start ---  

ok your clock looks right. 

 

try asserting reset_n? 

--- Quote End ---  

 

 

 

Yup, the reset_n was asserted.
Altera_Forum
Honored Contributor II
112 Views

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

Altera_Forum
Honored Contributor II
112 Views

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

Altera_Forum
Honored Contributor II
112 Views

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

Altera_Forum
Honored Contributor II
112 Views

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
Honored Contributor II
112 Views

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
Honored Contributor II
112 Views

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

Altera_Forum
Honored Contributor II
112 Views

Hi, 

Thanks a lot thepancake. I will try to deal with the reset_n, and let you know how it goes soon.
Altera_Forum
Honored Contributor II
112 Views

 

--- 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
Honored Contributor II
112 Views

 

--- 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
Honored Contributor II
112 Views

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
Honored Contributor II
112 Views

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
Honored Contributor II
112 Views

 

--- 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
Honored Contributor II
60 Views

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.
Reply