cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
jlhx
Observer
Observer
477 Views
Registered: ‎05-20-2014

List of HLS bugs and issues

Hello,

to evaluate HLS as a tool for our company I have realized multiple small HLS projects which use many of the capabilites HLS offers (dataflow, pipelining, concurrent function execution, floating and fixed point data types). Having worked with older HLS versions before it's easy to see that many new functions and capabilites have been added, but the amount of bugs has been mind-boggling for a professional tool that is supposed to be used in productive operation. At this point I have spent more time investigating, analyzing, working around and fixing HLS specific bugs than implementing and testing the core functionality itself.

I have created an incomplete list of some of the issues that I have observed and listed the workaround/fix if I found some. All issues occured using Windows 10 64-Bit, Vitis HLS 2020.2, System Generator 2020.2 and Matlab 2019b.

Issue NumberModuleIssue
1GUIThe "Errors" and "Warnings" windows remain empty, even if there are Warnings or Errors in the Console window
2GUIThe generated "Allocation"-Pragmas using the GUI have the wrong format and do not synthesize. (e.g. it generates "#pragma HLS ALLOCATION instances=foo limit=1 function" instead of "#pragma HLS ALLOCATION function instances=foo limit=1")
3GUIOccasional error messages from the GUI that a Java error occurred ("java.lang.NullPointerException")
4GUIUsing data types like ap_fixed the debugger does not show the value of variables
5SynthesisIf a function name contains a number an ALLOCATION pragma pertaining to that function will fail (e.g. "#pragma HLS ALLOCATION function instances=foo0bar limit=1")
6SynthesisAccessing an array that is a top level argument in certain ways (e.g. T dataNew = (topArray[0]>topArray[1])?topArray[0]:topArray[1]) ) generates an Synthesis error ("HLS 214-247" "Cannot apply array transformation pragma/directive because of pointer selection." - rewritten with if/else instead of ?: works fine)
7SynthesisIt is impossible to disaggregate a struct at the interface level if it contains an array (should be possible according to https://www.xilinx.com/html_docs/xilinx2020_2/vitis_doc/hls_pragmas.html#lbk1584844390084 , will fail with one of multiple synthesis errors like "HLS 214-177")
8SynthesisAccording to the documentation pointer to pointers/pointer arrays are allowed as long as each pointer points to a scalar or an array of scalars. But creating an array whose elements point to other arrays of scalar data generates an error ("HLS 214-134" "Pointer to pointer is not supported")
9SynthesisUsing ap_fixed generates dozens of warnings ("WARNING: [HLS 207-5510] 'Resource pragma' is deprecated, and it will be removed in future release. It is suggested to replace it with 'bind_op/bind_storage pragma'.: C:/Xilinx/Vitis_HLS/2020.2/common/technology/autopilot/hls_hotbm_apfixed.h:211:9")
10Synthesis InterfaceAlthough for hls::stream in- and outputs the interface type ap_hs should be supported according to the documentation, Vitis only allows ap_fifo or ap_memory
11Synthesis InterfaceAccording to the documentation to use e.g. single port BRAMs the bind_storage pragma should be used, even for top level interface arrays. But this only works when using the interface pragma instead
12Synthesis Interfaceap_memory interface that is correctly inferred as pure output has unnecessary "q"-input port in HLS ip core
13Synthesis InterfaceUsing the array_partition pragma on an input array leads to erroneously listings in the Synthesis Summary. All "Datatype"s listet under "SW I/O Information" and "Top Function Arguments" are listed as identical despite using different data types for individual arguments in the C source code. The same is tha case in the solution .json-file.
14System Generator(Unknown condition:) Using the Vitis HLS block some in- and outputs have the binary point at position zero, even though it has been defined differently in HLS (e.g. top function "foo" has argument "bar[12]" which is signed fix point with 32 bits and binary point at position 16. The "Vitis HLS" block will expect signed 32 bits with binary point at position 0 instead)
15System GeneratorUsing the float data type as an output at the top level interface can generate an "illegal" data type for that port using the "Vitis HLS" block. Changing the "srcType" for that port in the "<solution_name>_data.json" from "float&" to "float" seems to fix the issue.
16System GeneratorThe same issue as above ("illegal" data type) can even happen for an fixed point input ("srcType" uses the data type of a different input that does not match the correct "srcSize")
17System GeneratorUsing ap_FIFO for an output creates an algebraic loop according to a simulink error since the negated full output is fed back without delay to the input. This can not be fixed by forcing the output to use a register via HLS pragma.
18System GeneratorUsing ap_FIFO with the optional register parameter leads to no outputs in the System Generator/Simulink simulation. Hardware cosimulation inside Simulink works
19System GeneratorFor some projects System Generator produces the following error: " [USF-XSim-62] 'compile' step failed with error(s)". Inside of vivado.log: "ERROR: [VRFC 10-3195] cannot open include file '<projectName>_hls_deadlock_detector.vh'" The fix is to remove the line "`include "<projectName>_hls_deadlock_detector.vh"" in <projectName>.v inside the solution folders
20System Generator

It used to be possible to provide Matlab with command line arguments using the sysgen.bat file that needs to be used to start Matlab with System Generator support. Since new Matlab version only support a single argument provided via "-r" and the sysgen.bat supplys its own string and appends the user supplied argument with a second "-r" it doesn't work anymore. This can easily be fixed by modifying the sysgen.bat so that it doesn't supply "-r <xilinxstring> -r <userstring>" but "-r <xilinxstring>;<userstring>" (pseudocode)

21Co-Simulation

Using floating point data types thousands or even millions of warnings are generated (example: "Warning: OPMODE Input Warning : The OPMODE 0110X0X with CARRYINSEL 000 to DSP48E1 instance is invalid."). This slows down the co-simulation extremly since this line is printed hundreds of thousands times to the console and log file.

22Missing FeatureSupport for custom floating point data types aside from half, single and double precision
23Missing FeatureSharing of function instances regardless of the hierarchy level
24Missing FeatureIn 2020.2 a lot of Tcl commands have been deprecated with no replacement (e.g. no way to globally optimize for resources anymore)
25Missing FeatureA way to debug co-simulation discrepancies/errors. One of my models produces results that differ orders of magnitudes more than the C testbench. No way to debug.

 

Considering that is just a subset of the issues I have encountered and some of these issues have been around since years I really have to wonder whether Xilinx still intends for HLS to be used.

I would really appreciate an answer - and even more if those bugs would get fixed in the near future (I did a short test with 2021.1 and the results were much the same).

4 Replies
joancab
Teacher
Teacher
470 Views
Registered: ‎05-11-2015

Vivado indeed easily reaches the kw (kilowarning).

nithink
Xilinx Employee
Xilinx Employee
438 Views
Registered: ‎09-04-2017

@jlhx   would you be willing to share your tests with us. If you want to share them privately with me, it's fine. 

we would like to look at the issues and get them fixed in a future release. Some of the OS specific issues, don't reproduce that easily. So if you could send us the tests, we will see how we can improve our tools

 

Thanks,

Nithin

0 Kudos
jlhx
Observer
Observer
332 Views
Registered: ‎05-20-2014

@nithink thank you for your reply.

Since I implemented proprietary closed source signal processing algorithms I can't share my projects, but those wouldn't help anyway since I worked around most of those issues as best as I could.

For example, regarding issue 15 I appended the following code snippet to my .tcl files after the sysgen export is finished:

# correct HLS bug (replace "float&" with "float" in <solution>_data.json)
set filePath "<projectName>/<solutionName>/<solutionName>_data.json"
set fd [open $filePath r]
set newfd [open "${filePath}.tmp" w]
while {[gets $fd line] >= 0} {
    set newline [string map {float& float} $line]
    puts $newfd $newline
}
close $fd
close $newfd
file rename -force "${filePath}.tmp" $filePath

 

Or when I noticed I couldn't disaggregate my structs (issue 7) I simply did not, even though it would have been really desriable to be able to do so. Or issue 6 led to me to avoiding the ?: operator completely.

Also, for most listed issues I don't think you would need an example beyond what I provided. See issue 2 for example, the pragma created by the GUI is wrong and I list examples for the automatically built pragma and the correct pragma. Or issue 15: Using float as a type on a top level function argument will always create the issue. Etc.

0 Kudos
jlhx
Observer
Observer
300 Views
Registered: ‎05-20-2014

Just encountered another issue:

A project that uses single precision floating point for a large amount of calculations generates results that are within 1e-5 of pre-calculated double results using the C-simulation.

The Co-Simulation fails since the results deviate up to 1e-1 (instead of 1e-5).

I tried literally everything to fix this (every step inside the answer record #61063 document) but to no avail.

Here is what caused the issue: I have three structs at the top level interface. One of type "A" and two of type "B". The "B" type struct contains an array aside from scalars. What caused the issue was using the packed attribute on struct type "B" ("__attribute__((packed))").

The code is valid according to the documentation and the C simulation and RTL synthesis don't produce any issues. But the Co-Simulation fails.

0 Kudos