summaryrefslogtreecommitdiffstats
path: root/main.tex
diff options
context:
space:
mode:
authorYann Herklotz <git@yannherklotz.com>2020-09-14 16:55:08 +0100
committerYann Herklotz <git@yannherklotz.com>2020-09-14 16:55:08 +0100
commit72e8dc4b707a13c68722ce2f28665a84df5a7937 (patch)
tree9ced0eafedd25d1a3e79d4b8980acf03e22e45a7 /main.tex
parentf09e782d0925bc735aadc29bf595d1e3cc187351 (diff)
downloadfccm21_esrhls-72e8dc4b707a13c68722ce2f28665a84df5a7937.tar.gz
fccm21_esrhls-72e8dc4b707a13c68722ce2f28665a84df5a7937.zip
Add small changes
Diffstat (limited to 'main.tex')
-rw-r--r--main.tex2
1 files changed, 1 insertions, 1 deletions
diff --git a/main.tex b/main.tex
index ace7062..1a6b605 100644
--- a/main.tex
+++ b/main.tex
@@ -115,7 +115,7 @@
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. In this paper, we investigate whether they are 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 \JW{We should decide on a consistent way to capitalise `gcc'. I vote for `GCC' because that's how Wikipedia writes it.} 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, 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.
\end{abstract}
%%