Forum Discussion

User1582192733150209's avatar
User1582192733150209
Icon for Occasional Contributor rankOccasional Contributor
5 years ago

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

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

12 Replies

  • SengKok_L_Intel's avatar
    SengKok_L_Intel
    Icon for Regular Contributor rankRegular Contributor

    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


    • User1582192733150209's avatar
      User1582192733150209
      Icon for Occasional Contributor rankOccasional 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

    • User1582192733150209's avatar
      User1582192733150209
      Icon for Occasional Contributor rankOccasional 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

    • tessellation's avatar
      tessellation
      Icon for New Contributor rankNew 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.

      • User1582192733150209's avatar
        User1582192733150209
        Icon for Occasional Contributor rankOccasional 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

    • User1582192733150209's avatar
      User1582192733150209
      Icon for Occasional Contributor rankOccasional Contributor

      Hi SK,

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

      thank you very much.

      Jim