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
FFT configuration is as below
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
3, you might need edit the quartus path in msim_setup.tcl ,my quartus is located H:/intelfpga_pro/17.1/quartus/
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
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.
for multi cycle source input
details for timing issue
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.
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.
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.
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.
thanks for your reply.
I have tried 2 another solution to solve IPG issue for now, both of them not perfect.
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.
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.