From 22fdb92e4376f8d951701333f0e301200c74c375 Mon Sep 17 00:00:00 2001
From: Yann Herklotz <git@yannherklotz.com>
Date: Sun, 13 Sep 2020 20:22:53 +0100
Subject: Update background and intro

---
 intro.tex | 39 ++++++++++++++++++++-------------------
 1 file changed, 20 insertions(+), 19 deletions(-)

(limited to 'intro.tex')

diff --git a/intro.tex b/intro.tex
index abddb2c..6d17fe9 100644
--- a/intro.tex
+++ b/intro.tex
@@ -1,5 +1,21 @@
 \section{Introduction}
 
+\begin{figure}[t]
+  \centering
+\begin{minted}{c}
+unsigned int b = 0x1194D7FF;
+int a[6] = {1, 1, 1, 1, 1, 1};
+
+int main() {
+  int c;
+  for (c = 0; c < 2; c++)
+    b = b >> a[c];
+  return b;
+}
+\end{minted}
+  \caption{Miscompilation bug found in Vivado 2018.3 and 2019.2 which returns \code{0x006535FF} instead of \code{0x046535FF} which is the correct result.}\label{fig:vivado_bug1}
+\end{figure}
+
 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.
 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.
@@ -10,7 +26,9 @@ Human or unit testing may not achieve both these objectives, as HLS tools are of
 Hence, in this paper, we employ program fuzzing to perform automated testing of HLS tools. 
 Program fuzzing has been used extensively in testing software compilers.
 Most fuzzing tools randomly generate random C programs that are then provided to the compiler under test. 
-Furthermore, fuzzing tools can be configured by users to generate and avoid particular patterns, which is important since HLS tools typically support a subset of C. 
+Furthermore, fuzzing tools can be configured by users to generate and avoid particular patterns, which is important since HLS tools typically support a subset of C.
+
+Compiler Fuzzing is a popular technique to find bugs in programs, and it is especially effective at finding compiler bugs, as Yang \textit{et al.}~\cite{yang11_findin_under_bugs_c_compil} demonstrated by finding more than 300 bugs in GCC and clang.  This technique can therefore also be used to find bugs in HLS tools.  There has also been some prior work in trying to find bugs in HLS tools and also ensuring that synthesis tools output a correct design.
 
 % \NR{add a sentence about fuzzing}
 
@@ -19,23 +37,6 @@ Furthermore, fuzzing tools can be configured by users to generate and avoid part
 % Fuzzing enables us to overcome
 
 
-\begin{figure}[t]
-  \centering
-\begin{minted}{c}
-unsigned int b = 0x1194D7FF;
-int a[6] = {1, 1, 1, 1, 1, 1};
-
-int main() {
-  int c;
-  for (c = 0; c < 2; c++)
-    b = b >> a[c];
-  return b;
-}
-\end{minted}
-  \caption{Miscompilation bug found in Vivado 2018.3 and 2019.2 which returns \code{0x006535FF} instead of \code{0x046535FF} which is the correct result.}\label{fig:vivado_bug1}
-\end{figure}
-
-
 \paragraph{An example of a fuzzed buggy program}
 Figure~\ref{fig:vivado_bug1} shows a minimal example that produces the wrong result during RTL simulation in VivadoHLS, compared to GCC execution. 
 In this example, we right shift a large integer value \code{b} by values of array elements, in array \code{a}, within iterations of a \code{for}-loop.
@@ -55,7 +56,7 @@ Thus, it was natural to adopt program fuzzing for our HLS testing campaign.
 
 \paragraph{Our contributions}
 In this paper, we conduct a widespread testing campaign by fuzzing HLS compilers. 
-We do so in the following manner: 
+We do so in the following manner:
 \begin{itemize}
     \item We utilise Csmith~\cite{yang11_findin_under_bugs_c_compil} to generate well-formed C programs from the subset of the C language supported by HLS tools;
     \item Then, we test these programs together with a random selection of HLS directives by comparing the gcc and HLS outputs, and we  also keep track of programs that crash HLS tools;
-- 
cgit 

