Change formatting of table

1 files changed, 2 insertions, 0 deletions

diff --git a/related.tex b/related.tex
index 1d22c4d..af4d491 100644
--- a/related.tex
+++ b/related.tex
@@ -1,5 +1,7 @@
 \section{Related Work}
 
+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.