Xilinx FFT Block In/Out Sync problem

[hau]

Hello,

when I test the implementation offline in Simulink, the "Start Frame Out" port is only triggered if I previosly trigger the "Start Frame In" port and after finishing the FFT calculation.

Unfortunately the "Start Frame Out" port is triggered continuously when the implementation runs in the hardware (Kintex 7), even if the "Start Frame In" port is not triggered.

Any suggestions why this might happen?

[SG 17.2, Xilinx Library Blockset]

Thank you

[ravidapu]

This event signal is asserted for a single clock cycle when the block starts to process a new frame. This signal is provided to allow you to count frames and to synchronize the configuration of the core to a particular frame if required though the input frame is same but you are feeding it multiple times keeping start_frame_in enable. This is expected behavior of the block.

Hope it helps, please refer PG109 IP doc for more info.

[hau]

Hello,

thank you for answering but I still got some questions:

"This event signal is asserted for a single clock cycle when the block starts to process a new frame. " --> Isnt start_frame_out set high for a clock cycle when the block finishes processing the frame? Doesnt the block process a new frame only if start_frame_in is set high for a clock cycle?

"This signal is provided to allow you to count frames and to synchronize the configuration of the core to a particular frame" --> How can I synchronize an output frame to a particular input frame if even if I dont set start_frame_in high, I still get start_frame_out flags?

"This is expected behavior of the block." --> I would expect to get a start_frame_out flag only if I previously set start_frame_in high, this is the behaviour I see testing it offline.

Thank you

[hau]

Hello,

any more details you could share to my questions?

Thank you

[ravidapu]

Hello,

Thanks for writing us.

#1: Start_frame_out is a status signal which tells us how many frames have been processed i.e frame count

#2: The Block provides the output data frames in the same order that the input frames are fed. If you have one input frame, giving it to the block for multiple simulation cycles still you will see multiple Start_frame_out pulses which are equal to the number of cycles that the input frame is getting fed to the block

#3: The block is intelligent enough to descreminate the input frames and process them, user does not need to make start_frame_in high for every frame. Just assert start_frame_in once and start feeding the data 

Hope this helps.

Could you send me the design so that I will be able give you more info on this if any queries

Thanks

[hau]

Thank you for answering.

So if I only want to process specific data slot from a continuous stream, I will not be able to differentiate the outputs and correlate to my input slot because the FFT block is processing the whole time and there is no guarantee that the next output correlates to my desired input.

Is my understanding correct?

Is it possible to turn on and off the processing/FFT block?

Thank you again.

[ravidapu]

If you want to process only one input frame, please set your simulation time to the same and see the results as you expected. But you want to run simulation continuosly for one input frame, the output is always the same as we discussed previously.

FFT block output is always guaranteed and must correlate to the input

[dmittiga]

Hi, I apologize for reviving this thread. However, the OP's original question is left unanswered. I have observed the same behavior as the OP as well as other issues which I will enumerate below.

1 - The OP pointed out that when run in Simulink, start_frame_out is only high for every corresponding start_frame_in high signal. That differs from the results when run on hardware (as you have confirmed in your reply). Since System Generator is supposed to be bit and cycle accurate, isn't that concerning? That is a very clear discrepancy.

2 - I find that in System Generator, I can "re-sync" the FFT by supplying a start_frame_in at any point and the output synchronizes with it. I can do this any number of times and the data continues to be correct. However, on the hardware implementation, I find that once the FFT has been synced once (via the first high start_frame_in signal), it can never be re-synced again. Instead, it runs indefinitely on the same schedule, essentially ignoring any new start_frame_in high signals Again, this is another discrepancy.

3 - I have found that the latency calculated and shown on the FFT block can be incorrect. I have posted about this here: https://forums.xilinx.com/t5/AI-Engine-DSP-IP-and-Tools/SysGen-2019-1-FFT-shows-incorrect-latency/m-p/1082116

I am running 2019.2 with MATLAB 2019a

Thank you for your help

[timplatt]

Any update on the original problem?

i.e. not a 1:1 SFO for a given Start Frame In (as observed in SysGen simulation)

[vkanchan]

Hi @timplatt ,

There were few issues with start_frame ports of the FFT block and these have been fixed and verified in the Vivado 2020.1 release.

Please upgrade to the latest release to avoid this issue with start frame out.

[timplatt]

Thank you.

I did update the tools from 2019.1 to 2020.1 and used SysGen in 2020.1 to re-create the IP that uses the FFT and it did resolve the problem.

The SFO signal is now working as expected (i.e. one frame out from the FFT for each frame in signal).