Add quote

3 files changed, 24 insertions, 5 deletions

diff --git a/conference.bib b/conference.bib
index 7e1c24d..fd9d0ad 100644
--- a/conference.bib
+++ b/conference.bib
@@ -241,7 +241,7 @@ with {LegUp} High-Level Synthesis},
   bibsource = {dblp computer science bibliography, https://dblp.org}
 }
 
-@InProceedings{karine+20,
+@inproceedings{karine+20,
 author = {Karine Even-Mendoza and Cristian Cadar and Alastair Donaldson},
 title = {Closer to the Edge: Testing Compilers More Thoroughly by Being Less Conservative About Undefined Behaviour},
 booktitle = {IEEE/ACM International Conference on Automated Software Engineering, New Ideas and Emerging Results Track (ASE-NIER 2020)},
@@ -249,3 +249,22 @@ year = {2020},
 month = {09},
 location = {undefined},
 }
+
+@inproceedings{pilato13_bambu,
+  author = {C. {Pilato} and F. {Ferrandi}},
+  booktitle = {2013 23rd International Conference on Field programmable Logic and Applications},
+  title = {Bambu: A modular framework for the high level synthesis of memory-intensive applications},
+  year = {2013},
+  volume = {},
+  number = {},
+  pages = {1-4},
+  doi = {10.1109/FPL.2013.6645550}
+}
+
+@phdthesis{canis15_legup,
+  keywords = {high-level synthesis, hardware/software co-simulation, FPGA},
+  title = {{LegUp}: open-source high-level synthesis research framework},
+  author = {Canis, Andrew Christopher},
+  school = {University of Toronto},
+  year = {2015}
+}
diff --git a/intro.tex b/intro.tex
index 710b520..18c0074 100644
--- a/intro.tex
+++ b/intro.tex
@@ -1,7 +1,7 @@
 \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 hardware engineers an increase in productivity 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 description languages (HDL) such as Verilog and VHDL.
-HLS is being used in an ever greater range of domains, including such high-assurance settings 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.
+HLS is being used in an ever greater range of domains, including such high-assurance settings 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, even though ``high-level synthesis research and development is inherently prone to introducing bugs or regressions in the final circuit functionality''~\cite[Section 3.4.6]{canis15_legup}.  In this paper, we investigate whether they are trustworthy and give an empirical evaluation of their reliability.
 
 The approach we take is \emph{fuzzing}.
 %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. 
@@ -56,7 +56,7 @@ Yet this example also begs the question: do bugs found by fuzzers really \emph{m
 \subsection{Our approach and results}
 
 Our approach to fuzzing HLS tools comprises three steps. 
-First, we use Csmith~\cite{yang11_findin_under_bugs_c_compil} to generate thousands of valid C programs from within the subset of the C language that is supported by all the HLS tools we test. We also augment each program with a random selection of HLS-specific directives. Second, we give these programs to three widely used HLS tools: Xilinx Vivado HLS~\cite{xilinx20_vivad_high_synth}, LegUp HLS~\cite{canis13_legup} and the Intel HLS Compiler, which is also known as i++~\cite{intel20_sdk_openc_applic}. Third, if we find a program that causes an HLS tool to crash, or to generate hardware that produces a different result from GCC, we reduce it to a minimal example with the help of the \creduce{} tool~\cite{creduce}.
+First, we use Csmith~\cite{yang11_findin_under_bugs_c_compil} to generate thousands of valid C programs from within the subset of the C language that is supported by all the HLS tools we test. We also augment each program with a random selection of HLS-specific directives. Second, we give these programs to four widely used HLS tools: Xilinx Vivado HLS~\cite{xilinx20_vivad_high_synth}, LegUp HLS~\cite{canis13_legup}, the Intel HLS Compiler, which is also known as i++~\cite{intel20_sdk_openc_applic} and finally Bambu~\cite{pilato13_bambu}. Third, if we find a program that causes an HLS tool to crash, or to generate hardware that produces a different result from GCC, we reduce it to a minimal example with the help of the \creduce{} tool~\cite{creduce}.
 
 Our testing campaign revealed that all three tools could be made to crash while compiling or to generate wrong RTL.  In total, \totaltestcases{} test cases were run through each tool out of which \totaltestcasefailures{} test cases failed in at least one of the tools.  Test case reduction was then performed on some of these failing test cases to obtain at least \numuniquebugs{} unique failing test cases.
     
diff --git a/main.tex b/main.tex
index 146983d..b21c907 100644
--- a/main.tex
+++ b/main.tex
@@ -23,7 +23,7 @@
 
 \newcommand\totaltestcases{6700}
 \newcommand\totaltestcasefailures{272}
-\newcommand\numuniquebugs{7}
+\newcommand\numuniquebugs{8}
 \newcommand\vivadotestcases{3645}
 
 \theoremstyle{definition}
@@ -57,7 +57,7 @@ Email: \{zewei.du19, yann.herklotz15, n.ramanathan14, j.wickerson\}@imperial.ac.
 High-level synthesis (HLS) is becoming an increasingly important part of the computing landscape, even in safety-critical domains where correctness is key. 
 As such, HLS tools are increasingly relied upon. But are they trustworthy?
 
-We have subjected three widely used HLS tools -- LegUp, Xilinx Vivado HLS, and the Intel HLS Compiler -- to a rigorous fuzzing campaign using thousands of random, valid C programs that we generated using a modified version of the Csmith tool. For each C program, we compiled it to a hardware design using the HLS tool under test and checked whether that hardware design generates the same output as an executable generated by the GCC compiler. When discrepancies arose between GCC and the HLS tool under test, we reduced the C program to a minimal example in order to zero in on the potential bug. Our testing campaign has revealed that all three HLS tools can be made either to crash or to generate wrong code when given valid C programs, and thereby underlines the need for these increasingly trusted tools to be more rigorously engineered.
+We have subjected three widely used HLS tools -- LegUp, Xilinx Vivado HLS, the Intel HLS Compiler and Bambu -- to a rigorous fuzzing campaign using thousands of random, valid C programs that we generated using a modified version of the Csmith tool. For each C program, we compiled it to a hardware design using the HLS tool under test and checked whether that hardware design generates the same output as an executable generated by the GCC compiler. When discrepancies arose between GCC and the HLS tool under test, we reduced the C program to a minimal example in order to zero in on the potential bug. Our testing campaign has revealed that all three HLS tools can be made either to crash or to generate wrong code when given valid C programs, and thereby underlines the need for these increasingly trusted tools to be more rigorously engineered.
 Out of \totaltestcases{} test cases, we found \totaltestcasefailures{} programs that failed in at least one tool, out of which we were able to discern at least \numuniquebugs{} unique bugs. 
 
 \end{abstract}