Update background and intro

2 files changed, 20 insertions, 21 deletions

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;
diff --git a/related.tex b/related.tex
index 33a96e9..2296f33 100644
--- a/related.tex
+++ b/related.tex
@@ -1,7 +1,5 @@
 \section{Background}
 
-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.
-
 Lidbury et al. \cite{lidbury15_many_core_compil_fuzzin} fuzz-tested several OpenCL compilers, including an HLS compiler from Altera (now Intel). They were only able to subject that compiler to superficial testing because so many of the test cases they generated led to it crashing. In comparison to our work: where Lidbury et al. generated target-independent OpenCL programs that could be used to test HLS tools and conventional compilers alike, we specifically generate programs that are tailored for HLS (e.g. with HLS-specific pragmas) with the aim of testing the HLS tools more deeply. Another difference is that where we test using sequential C programs, they test using highly concurrent OpenCL programs, and thus have to go to great lengths to ensure that any discrepancies observed between compilers cannot be attributed to the nondeterminism of concurrency.
 
 Herklotz et al.~\cite{verismith} fuzz-tested several FPGA synthesis tools using randomly generated Verilog programs. Where they concentrated on the RTL-to-netlist stage of hardware design, we focus our attention on the earlier C-to-RTL stage.