summaryrefslogtreecommitdiffstats
path: root/related.tex
diff options
context:
space:
mode:
authorYann Herklotz <ymh15@ic.ac.uk>2020-09-12 09:52:07 +0000
committeroverleaf <overleaf@localhost>2020-09-12 10:03:11 +0000
commit47ffe25ba969f577e1829d136aae541b9eeceeb5 (patch)
treec465b3f4115929522efbe7e7dda5278d36f0018f /related.tex
parent639377a488e3d079bf95d9ee53cb748a3d3bedba (diff)
downloadfccm21_esrhls-47ffe25ba969f577e1829d136aae541b9eeceeb5.tar.gz
fccm21_esrhls-47ffe25ba969f577e1829d136aae541b9eeceeb5.zip
Update on Overleaf.
Diffstat (limited to 'related.tex')
-rw-r--r--related.tex8
1 files changed, 4 insertions, 4 deletions
diff --git a/related.tex b/related.tex
index 4b4c37d..024bcd2 100644
--- a/related.tex
+++ b/related.tex
@@ -2,15 +2,15 @@
\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.}
+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.}
+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].}
+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 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.
+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.