summaryrefslogtreecommitdiffstats
path: root/intro.tex
diff options
context:
space:
mode:
authorJohn Wickerson <j.wickerson@imperial.ac.uk>2020-09-04 13:36:51 +0000
committeroverleaf <overleaf@localhost>2020-09-06 15:05:10 +0000
commit58422a148843b8ce581c6f241e460c932e51fa1f (patch)
tree532d3c23f329f658e2fddd010214fd2b9be0116a /intro.tex
parent42292ef1e5552cc599c20a3d43953f56a56107cf (diff)
downloadfccm21_esrhls-58422a148843b8ce581c6f241e460c932e51fa1f.tar.gz
fccm21_esrhls-58422a148843b8ce581c6f241e460c932e51fa1f.zip
Update on Overleaf.
Diffstat (limited to 'intro.tex')
-rw-r--r--intro.tex11
1 files changed, 11 insertions, 0 deletions
diff --git a/intro.tex b/intro.tex
new file mode 100644
index 0000000..d662977
--- /dev/null
+++ b/intro.tex
@@ -0,0 +1,11 @@
+\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 Verilog.
+It is even being used in high-assurance settings, such as financial services~\cite{hls_fintech}, control systems~\cite{hls_controller}, and real-time object detection~\cite{hls_objdetect}. As such, HLS tools are increasingly relied upon. In this paper, we investigate whether they are trustworthy.
+
+Our method is brought over from the compiler testing literature. We use a tool called Csmith~\cite{yang11_findin_under_bugs_c_compil} to generate well-formed C programs from the subset of the C language that is supported by all the HLS tools 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. \ No newline at end of file