07-06-2021 06:35 AM - edited 07-06-2021 11:45 AM
I'm trying to implement an SSR FFT using sysgen. I'm modifying the example project "sysgenSSRIFFT" which is for N=1024 and SSR=4. I was able to successfully convert this project to a forward FFT, however, when I increase N and/or SSR, the resulting spectrum has spurious spikes outside of the expected frequency component (plots attached). At the begging I though it was a problem related to the sync of the parallel output, so I decide to just dump the output to the workspace and reassemble it using Matlab after the simulation, but the problem persists.
I'm using a pure complex sinusoidal as test input and noticed that this problem occurs periodically, with different intensity, depending on a combination of N and SSR. For example, for N=4196 and SSR=16, there are only a half dozen spurious at multiple integers of the the test frequency, however, when N=8192 or SSR = 32, the undesired outputs increase significantly. My goal here is N=8192 and SSR=32, which obviously outputs a lot of "garbage". I can upload the model file if needed.
Is this a known issue for the FFT algorithm in general? An error on the FFT block? Or problems in the SSR implementation? Overflow?
Are the SSR blocks intended to be used in real applications or are they a kind of "beta test"?
07-08-2021 02:03 AM
07-08-2021 06:18 AM
Thanks for your help.
The device selected on the sysgen token is the ZCU106 evaluation platform. There is only the SSR FFT block and the input width is 18bit (Fix_18_16). The scaling input is 13bit ufix, but it is set to zero right now. Output is 26 (Fix_26_16).
07-09-2021 06:04 AM
Hi @canisio ,
This mostly looks like an issue due to overflow. Referring to the documentation, there should be at least log2N bits more to avoid overflow due to bit growth.
I have a small design that I modified for N=8192 and SSR=32 and feed a sine wave, and the output is reflected in the desired bin. I am attaching the design here.
07-09-2021 06:52 AM
Thanks for the update,
I was already playing with the dynamic range of the input and it definitely looks like an overflow issue. I'll test your design ASAP.
Since you mentioned the documentation... The documentation for SSR blocks is extremely simple. How can we know details about the parallelism and the architecture of these blocks? Is there any extra source for it?
07-10-2021 07:09 AM
Thank you @vkanchan , it works. I still have some questions
Could you please explain why does your project has an extra delay at the "N-sample enable"?(z2 instead of z1)
Why it is active low if the documentation says it is active high? Maybe to deactivate the block after N/SSR clocks?
Why are all those delays needed before the gateways in? One could say that it is to break the critical path, but they're outside the FPGA.
Could you also explain what the "unbuffer" subsystem do? Actually I'm trying to understand how the output should be reassembled after the SSRFFT. In other words, what is the correspondent bin for each parallel output. I'm sorry for insisting, the documentation for the SSR is poor.
07-10-2021 09:11 AM
HI @canisio ,
Extra delay on the N-sample is to avoid the first frame from the buffer on the input data paths. The first frame from the buffer would be all zero value samples and this would not be a valid input frame.
In_valid becomes low after N/SSR blocks because only one input frame of data is considered here.
The delays before the gatewaysin were for simple handling of the data inputs from the frame buffers in this example.
The unbuffer subsystem in this example feeds each "SSR" vector data into a delay line of length 'N' so it can access all the 'N' values at the same time after "N/SSR" clock cycles, which is indicated by the tlast.