Add related work

1 files changed, 6 insertions, 10 deletions

diff --git a/related.tex b/related.tex
index 024bcd2..1d22c4d 100644
--- a/related.tex
+++ b/related.tex
@@ -1,17 +1,13 @@
-
-
 \section{Related Work}
 
 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.
 
-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, .
-
-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 highly rely 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. 
+Several authors have taken steps toward more rigorously engineered HLS tools that may fare better under testing campaigns like ours.  One such example might be a Handel-C compiler which has been partially formally proven in a theorem prover called HOL~\cite{perna12_mechan_wire_wise_verif_handel_c_synth}.  However, Handel-C requires the manual parallelisation of hardware and would require many more checks to avoid data races.  In addition to that, a HLS tool called SPARK~\cite{gupta03_spark} also contains passes that are validated during compilation time~\cite{chouksey20_verif_sched_condit_behav_high_level_synth}, such as the scheduling algorithm.  Unfortunately the tools are not readily available yet to properly test, or do not support C as input directly.  Finally Catapult C~\cite{mentor20_catap_high_level_synth} is also a high-level synthesis tool that proves that the netlist is equivalent to the input, and should therefore not produce any bugs and only fail if the output cannot be proven.
 
-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
+%%% Local Variables:
+%%% mode: latex
+%%% TeX-master: "main"
+%%% TeX-command-extra-options: "-shell-escape"
+%%% End: