11-01-2019 07:26 AM
10-23-2019 04:21 AM
The core sources were available back in 2018.3. The source text contains 4 syntax errors - they are simple and easy to correct, but the very fact of their presence leads to sad thoughts. The core documentation also does not match what it is. The core is collected only for fixed-point numbers, for the float type we have an error in the syntax (not related to the above), and double is not synthesized. The size of the synthesized core for a fixed point is not acceptable for use. It is also synthesized not for operation in pipeline mode.
10-24-2019 07:25 PM
In UG902 V2019.1,page 245，It is clearly stated that the recommended starting point is to start with float/double inner type in std::complex<> and verify the SNR against a reference model, such as the Matlab/Python/Octave/Simulink – whichever modeling language or tools are used by generating golden test vectors. The synthesizable version of the SSR FFT currently only supports ap_fixed<> inner type, so the next step is to start experimenting with a fixed point model.
The FFT cannot be used in a region which is pipelined. If high-performance operation is required, pipeline the loops or functions before and after the FFT then use dataflow optimization on all loops and functions in the region. If you have to use the float tpye, consider the FFT lP Library instead of SSR FFT.
**~ Got a minute? Answer our Vitis HLS survey here! ~**
10-25-2019 02:44 AM
According to its functionality, the IP SSR FFT should be designed to process "wide" data coming, for example, with IP JESD for ADCs operating at frequencies above the maximum allowable for ordinary IP FFT. For example, with an ADC at a sampling frequency of 3.2 GHz, the output of IP JESD will be 256 bits wide with a frequency of 200 MHz. They could be processed by one IP SSR FFT operating in pipeline mode or by fragmenting data into 3-4 "ordinary" IP FFTs. The first option would be much preferable, but in the current state it cannot be implemented, because the inability of IP SSR FFT to operate in pipeline mode makes its existence useless.
10-28-2019 03:42 PM
I have made some progress but am having trouble instantiating a SSR FFT module. UG902 v2019.1, pg. 249 states that the FFT should be called as follows:
after I have set the ssr_fft_params based on the extended struct, ssr_fft_default_params. At this point, HLS complains of an invalid overload. I have dug somewhat throught hls_ssr_fft.h file but am still at a loss.
What is the correct instantiation?
10-29-2019 01:03 AM
Using IP SSR FFT is similar to using regular IP FFT in HLS. I took the project "Xilinx\Vivado\2019.1\examples\design\FFT\fft_single_x_complex" as the basis.
10-29-2019 05:14 PM
I have looked at the example you recommened but cannot for the life me make the SSR FFT work. Do you have an example line of code for instantiation and calling of the module?
10-30-2019 02:13 AM
I already wrote above that this IP is useless - in the current state it is not applicable for its intended purpose - there is no pipeline and there is no support for data in the float format.
11-01-2019 07:26 AM
11-20-2019 03:41 AM - edited 11-20-2019 03:42 AM
The IP SSR FFT has moved to the Vitis library and now, according to the documentation and examples, now supports the complex float data type. Is it possible to synthesize the current version using HLS and get an IP for Vivado?
11-20-2019 12:58 PM
The source code of this kernel for Vitis, usage examples and documentation links can be found at https://github.com/Xilinx/Vitis_Libraries/tree/master/dsp
The source code for Vitis has much in common with HLS - perhaps they can also be adapted to form regular IPs for Vivado. I would like to hear from Xilinx experts about this.