Update on Overleaf.

1 files changed, 31 insertions, 8 deletions

diff --git a/intro.tex b/intro.tex
index 2928014..8c2f56d 100644
--- a/intro.tex
+++ b/intro.tex
@@ -1,9 +1,25 @@
 \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 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.
 
+To test the trustworthiness of HLS tools, we need a robust way of generating programs that both have good coverage and also explores various corner cases. 
+Therein lies the difficulty in testing HLS tools. 
+Human or unit testing may not achieve both these objectives, as HLS tools are often require complex inputs to trigger wrong behaviour. 
+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. 
+
+% \NR{add a sentence about fuzzing}
+
+% % Our method is brought over from the compiler testing literature. 
+% Program fuzzing is bla.. 
+% Fuzzing enables us to overcome 
+
+
+
 \begin{figure}[t]
   \centering
 \begin{minted}{c}
@@ -22,12 +38,12 @@ int main() {
 
 
 \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 all three versions of VivadoHLS, compared to GCC execution. 
+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.
 VivadoHLS returns \code{0x006535FF} instead of \code{0x046535FF} as in GCC. 
 The circumstances in which we found this bug shows the challenge of testing HLS tools.
 
-For instance, the for-loop was also necessary to ensure that a bug was detected.
+For instance, the for-loop is necessary to ensure that a bug was detected.
 Also, the shift value needs to be accessed from an array.
 Replacing the array accesses within the loop with constants result in the bug not surfacing.
 Additionally, the array \code{a} needed to be at least six elements in size although the for-loop only has two iterations. 
@@ -38,12 +54,19 @@ In contrast, producing non-intuitive, complex but valid C programs is the corner
 Thus, it was natural to adopt program fuzzing for our HLS testing campaign. 
 % \NR{Yann, please double check my claims about the bug. I hope I accurately described what we discussed. }\YH{Yes I agree with all that, I think that is a good description of it}
 
-\paragraph{Our contribution}
-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. 
+\paragraph{Our contributions}
+In this paper, we conduct a widespread testing campaign by fuzzing HLS compilers. 
+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;
+    \item As part of our testing campaign, we generate 10 thousand test cases that we test against the three well-known HLS tools: Vivado HLS~\cite{xilinx20_vivad_high_synth}, LegUp HLS~\cite{canis13_legup} and Intel HLS~\cite{};
+    \item For our testing campaign, we found \ref{XX} bugs that we discuss and also report to the respective developers, where \ref{XX} bugs have been confirmed. 
+\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 hope that our work serves to stimulate efforts to improve the quality of HLS tools.
+% 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.
 
 %%% Local Variables:
 %%% mode: latex