12-01-2015 02:25 AM
Im using 2015.3 and have generated a HLS function used to calculate some specific texture hole closing.
The function is woorking fine but the ap_idle is not correct. ap_idle always goes low after reset even if the function is not started yet using ap_start.
Basicly I have four for loops that generates data for the next one using HLS stream interface inbetween.
indata -> loop1 -> loop2 -> loop3 -> loop4 -> outdata
From simulation (see screen shot below) it can be seen that the ap_idle goes low after reset is released. But the ap_start haven't been high yet.
I have attached the top verilog file generated from the synthesis (fill_text.v). Here it can be seen that the ap_start signal from the top port only goes to the ap_start for loop 1 (fill_text_Loop_fill_text_loop1_proc124_U0_ap_start). Where as for loop 2 ie. (fill_text_Loop_fill_text_loop2_proc_U0_ap_start) is always set high when reset is released and thereby setting ap_idle for loop 2 low (fill_text_Loop_fill_text_loop2_proc_U0_ap_idle) which again means that the top port ap_idle is going low after reset.
This seems to me to be a bug in the HLS tool.
I have also attached the c++ top level file fill_text.cpp
12-06-2015 11:28 PM
Did you try using the latest version of Vivado 2015.4?
I tried creating a project with 2015.4 and seeing errors. Can you please attach the project archive after trying with 2015.4?
12-08-2015 07:42 PM
01-15-2016 01:33 AM
Sorry for the long delay
I have finally found time to try in 2015.4 and the error is still there.
Its working fine in C simulation and C/RTL simulation but the reason why its working in C/RTL simulation is becaue as soon as reset is released ap_start goes high.
I have attached a project archive you can use to recreate the problem. Again if you look at the generated verilog code its very easy to see the error.
09-21-2016 09:04 AM
Did you find a cause for this issue? I am seeing the same problem in one of my designs (in 2016.2). We are able to workaround it by wrapping the top level function in another function, but I'd rather know what the root cause of the problem is.
10-04-2016 02:28 PM
I'm also seeing this behavior. This 100% has to be some bug with HLS as there's simply no reason for ap_idle to drop low before ap_start has been asserted. Has anyone contacted Xilinx about this issue?