summaryrefslogtreecommitdiffstats
path: root/main.tex
diff options
context:
space:
mode:
authorYann Herklotz <git@yannherklotz.com>2020-08-10 16:28:12 +0200
committerYann Herklotz <git@yannherklotz.com>2020-08-10 16:28:12 +0200
commit221d3d7ca073b32696b4118b98658b74e94c7a02 (patch)
tree8c6c71399144c4cca25416d87040cc1982c10bdd /main.tex
parentc45bea00f992666b09211acb1fc3f96f70426b8b (diff)
downloadfccm21_esrhls-221d3d7ca073b32696b4118b98658b74e94c7a02.tar.gz
fccm21_esrhls-221d3d7ca073b32696b4118b98658b74e94c7a02.zip
Add some references
Diffstat (limited to 'main.tex')
-rw-r--r--main.tex4
1 files changed, 2 insertions, 2 deletions
diff --git a/main.tex b/main.tex
index 528c1c7..6695417 100644
--- a/main.tex
+++ b/main.tex
@@ -148,9 +148,9 @@ Abstract
High-level synthesis (HLS) is increasingly important. It is being adopted both by hardware engineers aiming to increase their productivity, and by software engineers aiming to attain the performance and energy-efficiency of custom hardware. It is even being used in safety-critical settings \cite{?}. As such, HLS tools are increasingly trusted. But are they trustworthy? In this paper, we investigate how reliable existing HLS tools are.
-Our method is brought over from the compiler testing literature. We use a tool called Csmith~\cite{?} to generate well-formed C programs from the subset of the C language that is supported by all the HLS tools we test. 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.
+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. 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{?}, Xilinx Vivado HLS~\cite{?}, 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 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.
\section{Method}
\begin{itemize}