Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
309 Views

Intel FFT IP core timing issue

Hello Sir/Madam,

I am simulating the intel FFT IP core, and seems FFT output has some timing issue .

Quartus prime pro 17.1

Modelsim-intel  starter 10.5c

Windows 10 pro

Arria10gx

 

FFT configuration is as below

Length:256

Direction: forward

Data flow: variable streaming

Input order: Natural

Output order: Natural

Representation: single floating point

 

What I have done

1, create a Quartus project and install a Intel FFT IP core

2, Choose to generate the testbench when setting up the FFT IP core 

3,start modelsm and bcompile vendor/user library using automatic generated msim_setup.tcl

4,use matlab2019b to generate IEEE754 format  data source, 32bits single precision floating.

5,In testbench coding to load above data source into FFT input

6, simulation and observe FFT output

 

My testbench can control data source packet input only once or repeat .

 

If I choose  data source packet input only once. then FFT IP can gave a perfect result ,which means source_sop,source_valid,source_eop all signals worked follow the expectation. I can see the FFT result source_data result is correct after loading it into matlab.

But If I choose same data source packet to input repeat continually, the FFT can output result repeat following each input packet, but all the FFT result output stated to have below common timing issue

1, source_data are correct based on the input ,after I checking it one by one

2,source_valid , and source_sop,source_eop are not align correctly on timing

3,For source_valid, it  always has one cycle low after  output stated,while in the case of single cycle imputing applied, there was no this timing issue

4, For source_sop, this signal is not align with source_valid, which means this signal is bit late than the start of data and source_valid, source_sop is moving late 1 clock per packet as the input packet repeat

4, For source_eop, this signal is not align with source_valid, which means this signal is bit late than the time supposed to be, and when source_eop is valid, source_valid is not valid.also ource_eop is moving late 1 clock per packet, and drift time is accumulated.

5, During the simulation ,sink_ready and source ready always  is 1'b1.

6, sink_error always set to be 0. and there is no any error on the output of source_error

I attached my project here for further analysis ,so you can duplicate my issue.

1,unzip my project,you can put it into the d:  , this is my original location 

2,start modelsim

3, you might need edit the quartus path in msim_setup.tcl ,my quartus is located H:/intelfpga_pro/17.1/quartus/

4,goto D:\gofft\tfft_tb\tfft_tb\sim\mentor 

source initial_setup.tcl

5,do run.do

6, if you need to control input data source only once

change multi_cycle=1'b0     in D:\gofft\tfft_tb\tfft_tb\sim\tfft_tb.v

7, you will see the issue I mentioned

 

thanks

Jim

fft.JPG

 

for single packet cycle data source input,all signal are correct ,source_sop,source_eop all valid in  correct time, also source_valid is smooth without glitch.

one_packet_cycle_marked.jpg

 

for multi cycle source input

multi_cycle_marked.jpg

 

details for timing issue

multi_cycle_detials_marked.jpg

0 Kudos
12 Replies
Highlighted
308 Views

project attached

0 Kudos
Highlighted
299 Views

Hi,


Yes, I can see the same problem in v20.1, and will feedback to the Intel FPGA FFT IP engineering team.


For the moment, you may increase the inter-packet gap number to work around the issue. For example, you can change the IPG_number to 256 in your testbench.


Regards -SK


0 Kudos
Highlighted
298 Views

Hi SK,

Thanks for your reply.

because I am using intel PAC arria10gx card, which is suggested to use Quartus 17.1 only since other version is not suppoted.

Making a IPG gap bigger might solve the issue , I can try this to see how is going.

 

thanks

 

Jim

0 Kudos
Highlighted
289 Views

Hi SK,

 

I have verified that by increasing the IPG of repeat packet input, the outputting relevant signals  can go back to correct timing. For that purpose , the minimum IPG is 256 for this case, any other number less than 256 will have same glitch and timing issue.

this workaround can solve the timing issue, the cost is FFT processing bandwidth reduced .

 

hope can have some vendor patch to solve this.

 

thanks

Jim

256 IPG.JPG 

0 Kudos
Highlighted
287 Views

Thank you for your understanding.


Regards -SK


0 Kudos
Highlighted
Moderator
280 Views

Thanks this is helpful.

0 Kudos
Highlighted
Beginner
230 Views

I have the exact same issue implementing the FFT with a cyclone V with quartus lite. Although for my implementation i need to pause the FFT stream between packets for 144 clk cycles only. Hence, the solution provided here won't help me.

0 Kudos
Highlighted
219 Views

Hi tessellation,

 

thanks for your reply.

 

I have tried 2 another solution to solve IPG issue for now, both of them not perfect.

solution 1 

install 2 FFT core in parallel and switch input packets to 2 fft core alternately, by such arrangement you will not see any IPG issue, IPG can be 0.  cost is FFT resource doubled.

 

solution 2

change output order to digit reverse, then you will not see IPG issue, but cost is you need  other logic to do re-order work.

best regard

 

Jim

0 Kudos
Highlighted
185 Views

Hi Jim,


Thanks. This is helpful.


Regards -SK


0 Kudos
Highlighted
Beginner
179 Views

Thanks Jim, very helpful

0 Kudos
Highlighted
165 Views

Hi SK,

please help to close this service request,  and my initial question has been addressed with your suggestion.

thank you very much. 

Jim

0 Kudos
Highlighted
131 Views

Yes.  I will close this case.  Thanks.

Regards -SK

0 Kudos