Update on Overleaf.

1 files changed, 5 insertions, 5 deletions

diff --git a/intro.tex b/intro.tex
index 1128706..99bffa3 100644
--- a/intro.tex
+++ b/intro.tex
@@ -22,14 +22,14 @@ It is even being used in high-assurance settings, such as financial services~\ci
 
 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 on HLS tools. 
+Human testing may not achieve both these objectives, as HLS tools are often require complex inputs to trigger wrong behaviour. 
+In this paper, we employ program fuzzing on HLS tools. 
 
-Fuzzing is an automated testing method that provides unexpected, counter-intuitive and random programs to compilers to test their robustness~\cite{}. 
+Fuzzing is an automated testing method that provides unexpected, counter-intuitive and random programs to compilers to test their robustness~\cite{fuzzing+chen+13+taming,fuzz+sun+16+toward,fuzzing+liang+18+survey,fuzzing+zhang+19,yang11_findin_under_bugs_c_compil,lidbury15_many_core_compil_fuzzin}. 
 Program fuzzing has been used extensively in testing software compilers.
 For example, Yang \textit{et al.}~\cite{yang11_findin_under_bugs_c_compil} found more than 300 bugs in GCC and clang.
 Despite of the influence of fuzzing on software compilers, to the best of our knowledge, it has not been explored significantly within the HLS context.
-We specifically target HLS by restricting a fuzzer to generate programs that are a subset of C that HLS tools support.
+We specifically target HLS by restricting a fuzzer to generate programs within the subset of C supported by HLS.
 
 
 % Most fuzzing tools randomly generate random C programs that are then provided to the compiler under test. 
@@ -68,7 +68,7 @@ We do so in the following manner:
     \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{intel20_sdk_openc_applic};
-    \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. 
+    \item During 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.