Forum Discussion
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
- User15821927331502095 years ago
Occasional Contributor
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
- User15821927331502095 years ago
Occasional Contributor
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
- tessellation5 years ago
New Contributor
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.
- User15821927331502095 years ago
Occasional Contributor
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
- tessellation5 years ago
New Contributor
Thanks Jim, very helpful