Update on Overleaf.

1 files changed, 17 insertions, 0 deletions

diff --git a/related.tex b/related.tex
new file mode 100644
index 0000000..4b4c37d
--- /dev/null
+++ b/related.tex
@@ -0,0 +1,17 @@
+
+
+\section{Related Work}
+
+\JW{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.}
+
+\JW{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.}
+
+\JW{Several authors have taken steps toward more rigorously engineered HLS tools~\cite{yann_to_add_some_examples_such_as_perna} that may fare better under testing campaigns like ours. However, [something about there not existing a proper mechanically verified HLS tool that is actually usable in practice].}
+
+Existing work has already been done in finding bugs in Intel's OpenCL SDK using metamorphic testing~\cite{lidbury15_many_core_compil_fuzzin}.
+
+There is not much past research been done on the subject of interest, which is verifying the reliability of HLS tools using the fuzz testing method. Fuzz testing method has been previously performed on C/C++ compilers \ref{Csmith}, FPGA synthesis tools \ref{Verismith}, and OpenCL compiler\ref{manycore}. Those are the tools/applications that engineers or programmers are highly relied on, similar to the HLS tool investigated in this thesis. Previous work has been focusing on questioning the correct conversion from Verilog to netlist done by FPGA synthesis tools, the proper C compilation between different C/C++ compilers, and correct behaviors generated by OpenCL implantations or devices. 
+
+Through investigating the discrepancies between Verilog and netlists, 13 bugs have been detected across four FPGA synthesis tools. Furthermore, over 400 compiler bugs have been found by fuzz testing C/C++ compilers. And over 50 OpenCL compiler bugs have been reported through testing many-core systems. The bugs mentioned here are introduced by the tool solely rather than the original design. 
+
+Thus, a conclusion can be drawn that the reliability of tools should be questioned. And the fuzz testing method can efficiently and effectively trigger embedded bugs that lead to crashes or discrepancies in results. Based on those findings, we must wonder should we trust HLS tools. As the complexity of hardware design and optimization grows, it is highly possible to have wrongful conversions produced by HLS tools. If the synthesis process has been wrong, even if the programs described in HLL are valid and correct, the generated RTL description would behave differently. Thus, our work is motivated and inspired by previous related work. Based on the earlier work, it can be confirmed that the quality of randomly generated programs and the efficiency of the bug-detecting algorithm are essential. Randomly generated programs have to obey the rules of targeting system, whereas the bug-detecting method needs to be precise to prevent missing out minor bugs. With the help of applications produced by previous work, Csmith, we aimed to implement a powerful testing system that challenges HLS tools utilizing the fuzz testing method. 
\ No newline at end of file