summaryrefslogtreecommitdiffstats
path: root/intro.tex
diff options
context:
space:
mode:
authorYann Herklotz <git@yannherklotz.com>2020-09-14 16:55:08 +0100
committerYann Herklotz <git@yannherklotz.com>2020-09-14 16:55:08 +0100
commit72e8dc4b707a13c68722ce2f28665a84df5a7937 (patch)
tree9ced0eafedd25d1a3e79d4b8980acf03e22e45a7 /intro.tex
parentf09e782d0925bc735aadc29bf595d1e3cc187351 (diff)
downloadfccm21_esrhls-72e8dc4b707a13c68722ce2f28665a84df5a7937.tar.gz
fccm21_esrhls-72e8dc4b707a13c68722ce2f28665a84df5a7937.zip
Add small changes
Diffstat (limited to 'intro.tex')
-rw-r--r--intro.tex5
1 files changed, 2 insertions, 3 deletions
diff --git a/intro.tex b/intro.tex
index da09f55..27b2831 100644
--- a/intro.tex
+++ b/intro.tex
@@ -1,4 +1,3 @@
-
\section{Introduction}
High-level synthesis (HLS), which refers to the automatic translation of software into hardware, is becoming an increasingly important part of the computing landscape.
It promises to increase the productivity of hardware engineers by raising the abstraction level of their designs, and it promises software engineers the ability to produce application-specific hardware accelerators without having to understand hardware desciption languages (HDL) such as Verilog and VHDL.
@@ -66,9 +65,9 @@ This paper reports on our campaign to test HLS tools by fuzzing.
\item Our testing campaign revealed that all three tools could be made to crash while compiling or to generate wrong RTL. In total, we found \ref{XX} bugs across the three tools, all of which have been reported to the respective developers, and \ref{XX} of which have been confirmed at the time of writing.
- \item To investigate whether HLS tools are getting more or less reliable over time, we also tested three different versions of Vivado HLS (2018.3, 2019.1, and 2019.2). \JW{Put a sentence here summarising our findings from this experiment, once we have them.}
+ \item To investigate whether HLS tools are getting more or less reliable over time, we also tested three different versions of Vivado HLS (2018.3, 2019.1, and 2019.2). \JW{Put a sentence here summarising our findings from this experiment, once we have them.}\YH{Yes, will do that as soon as I have them.}
\end{itemize}
-% we test, and then augment each program with randomly chosen HLS-specific directives. We synthesise each C program to RTL, and use a Verilog simulator to calculate its return value. If synthesis crashes, or if this return value differs from the return value obtained by executing a binary compiled from the C program by gcc, then we have found a candidate bug. We then use trial-and-error to reduce the C program to a minimal version that still triggers a bug.
+% we test, and then augment each program with randomly chosen HLS-specific directives. We synthesise each C program to RTL, and use a Verilog simulator to calculate its return value. If synthesis crashes, or if this return value differs from the return value obtained by executing a binary compiled from the C program by GCC, then we have found a candidate bug. We then use trial-and-error to reduce the C program to a minimal version that still triggers a bug.
% We have tested three widely used HLS tools: LegUp~\cite{canis13_legup}, Xilinx Vivado HLS~\cite{xilinx20_vivad_high_synth}, and the Intel HLS Compiler~\cite{?}. For all three tools, we were able to find valid C programs that cause crashes while compiling and valid C programs that cause wrong RTL to be generated. We have submitted a total of \ref{?} bug reports to the developers, \ref{?} of which have been confirmed and \ref{?} of which have now been fixed at the time of writing.
% We hope that our work serves to stimulate efforts to improve the quality of HLS tools.