summaryrefslogtreecommitdiffstats
path: root/main.tex
diff options
context:
space:
mode:
authorYann Herklotz <git@yannherklotz.com>2021-04-05 16:22:55 +0100
committerYann Herklotz <git@yannherklotz.com>2021-04-05 16:23:04 +0100
commit3c232b2279b5c71ef8aa5a88987d5f2ac9d88016 (patch)
tree4f6cd8668b8022f28286b553a264ded653e289ac /main.tex
parent6a7ebeb13cd708e5b9e2a09400255ccbd3f0242a (diff)
downloadfccm21_esrhls-3c232b2279b5c71ef8aa5a88987d5f2ac9d88016.tar.gz
fccm21_esrhls-3c232b2279b5c71ef8aa5a88987d5f2ac9d88016.zip
Make the paper fit again
Diffstat (limited to 'main.tex')
-rw-r--r--main.tex1
1 files changed, 0 insertions, 1 deletions
diff --git a/main.tex b/main.tex
index f5bc5c5..5732d81 100644
--- a/main.tex
+++ b/main.tex
@@ -61,7 +61,6 @@ As such, HLS tools are increasingly relied upon. But are they trustworthy?
We have subjected four widely used HLS tools -- LegUp, Xilinx Vivado HLS, the Intel HLS Compiler and Bambu -- 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 four HLS tools can be made to generate wrong designs from valid C programs and one tool could be made to crash; this underlines the need for these increasingly trusted tools to be more rigorously engineered.
Out of \totaltestcases{} test-cases, we found \totaltestcasefailures{} programs that caused at least one tool to fail, out of which we were able to discern at least \numuniquebugs{} unique bugs.
-
\end{abstract}
\input{intro}