09-22-2017 01:09 AM
Hi,I use HLS fft ip to implement 1K fft.In HLS,there is a example project about fft.The example can work well,but if I copy the source files and create a new project,besides the same input datas are used,the new project can pass the C simulation and the synthesis,while the C/RTL Cosimulation failed.I do not know why this happen.And the errors show like this:
starting static elaboration
Can anyone help me with the problem? Is there anything wrong with the installation of the vivado HLS? Or something else wrong with my project? Any suggestions?
09-25-2017 02:27 AM
If you want somebody to respond to an error like that you might want to attach your project (.zip) to the post. It is easier when an issue can be reproduced.
10-23-2017 08:16 PM
Did you find any progress on this issue?
I just ran into the same problem with the FFT core in HLS. It looks like the FFT is trying to instantiate some kind of BRAM interface on the IO ports (it's looking for xn_address0, xn_address1, xk_address0, xk_address1, and associated ports...). I'm not sure why it would be doing that, because the actual FFT core does not have those interfaces.
10-30-2017 05:40 AM
I had no success generating HDL from an HLS model with the fft function. I'm really not sure what went wrong... I tried all sorts of permutations of compiler directives, including adding/removing dataflow, adding/removing pipeline, and different IO formats on the input and outputs variables.
Like your tests, I confirmed the default FFT example works successfully, but the only other step remaining I'd perhaps try is to make a direct copy of the FFT example and then incrementally add my application specific content until the example breaks. But, I was discouraged from trying this because it seems as though you already found that a direct copy of the FFT example breaks in the same way I saw.
My workaround solution is to split the HLS model into two parts 1) pre-fft and 2) post-fft, and I will wrap a Xilinx-generated FFT IP core in between the two HLS models using verilog, without using HLS to generate the FFT.
This is a real bummer... I'm hoping it gets fixed in more recent versions of HLS (I'm still using 2015.4, but it's disappointing you're finding similar problems in 2016.4 and 2017.2)
03-05-2018 01:12 AM
I am not clear about your solution "My workaround solution is to split the HLS model into two parts 1) pre-fft and 2) post-fft, and I will wrap a Xilinx-generated FFT IP core in between the two HLS models using verilog, without using HLS to generate the FFT. " What do you mean "wrap a Xilinx-generated FFT IP core in between the two HLS models using verilog"? Could you please explain more? Thanks very much.
Through your method, does your project work well? Is it convenient for you to show me your code?
10-12-2018 06:51 AM
The bug is still there on 2018.2...
This is what causes it:
INPUT_WIDTH = 32,
OUTPUT_WIDTH = 32,
CONFIG_WIDTH = 16,
STATUS_WIDTH = 8
input wire ap_clk,
input wire ap_rst,
input wire ap_start,
input wire ap_ce,
output reg ap_done,
output reg ap_ready,
output wire ap_idle,
input wire [CONFIG_WIDTH-1:0] config_ch_data_V_dout,
input wire config_ch_data_V_empty_n,
output wire config_ch_data_V_read,
input wire [INPUT_WIDTH-1:0] xn_dout,
input wire xn_empty_n,
output wire xn_read,
output wire [OUTPUT_WIDTH-1:0] xk_din,
input wire xk_full_n,
output wire xk_write,
output wire [STATUS_WIDTH-1:0] status_data_V_din,
input wire status_data_V_full_n,
output wire status_data_V_write
There are mismatches between variable names in fft_config_1_s instantiations and definitions...