summaryrefslogtreecommitdiffstats
path: root/conclusion.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 /conclusion.tex
parent6a7ebeb13cd708e5b9e2a09400255ccbd3f0242a (diff)
downloadfccm21_esrhls-3c232b2279b5c71ef8aa5a88987d5f2ac9d88016.tar.gz
fccm21_esrhls-3c232b2279b5c71ef8aa5a88987d5f2ac9d88016.zip
Make the paper fit again
Diffstat (limited to 'conclusion.tex')
-rw-r--r--conclusion.tex8
1 files changed, 3 insertions, 5 deletions
diff --git a/conclusion.tex b/conclusion.tex
index c5f1f6a..22aef6c 100644
--- a/conclusion.tex
+++ b/conclusion.tex
@@ -1,17 +1,15 @@
\section{Conclusion}
-We have shown how an existing fuzzing tool can be modified so that its output is suitable for HLS, and then used it in a campaign to test the reliability of four modern HLS tools. In total, we found at least \numuniquebugs{} unique bugs across all the tools, including both crashes and miscompilations.
-Further work could be done on supporting more HLS tools, especially those that claim to prove that their output is correct before terminating, such as Catapult-C~\cite{mentor20_catap_high_level_synth}. % This could give an indication of how effective these proofs are, and how often they are actually able to complete their equivalence proofs during compilation in a feasible timescale.
-Conventional compilers have become quite resilient to fuzzing over the last decade, so recent work on fuzzing compilers has had to employ increasingly imaginative techniques to keep finding new bugs~\cite{karine+20}. In contrast, we have found that HLS tools -- at least, as they currently stand -- can be made to exhibit bugs even using the relatively basic fuzzing techniques that we employed in this project.
+We have shown how an existing fuzzing tool can be modified so that its output is suitable for HLS, and then used it in a campaign to test the reliability of four modern HLS tools. In total, we found at least \numuniquebugs{} unique bugs across all the tools, including both crashes and miscompilations.
+Further work could be done on supporting more HLS tools, especially those that claim to prove that their output is correct before terminating, such as Catapult C~\cite{mentor20_catap_high_level_synth}. % This could give an indication of how effective these proofs are, and how often they are actually able to complete their equivalence proofs during compilation in a feasible timescale.
-As HLS is becoming increasingly relied upon, it is important to make sure that HLS tools are also reliable. We hope that this work further motivates the need for rigorous engineering of HLS tools, whether that is by validating that each output the tool produces is correct or by proving the HLS tool itself correct once and for all.
+Conventional compilers have become quite resilient to fuzzing over the last decade, so recent work on fuzzing compilers has had to employ increasingly imaginative techniques to keep finding new bugs~\cite{karine+20}. In contrast, we have found that HLS tools can be made to exhibit bugs even using the relatively basic fuzzing techniques employed in this project. We hope that this work further motivates the need for rigorous engineering of HLS tools, whether that is by validating that each output the tool produces is correct or by proving the HLS tool itself correct once and for all.
\section*{Acknowledgements}
We thank Alastair F. Donaldson for helpful feedback.
We acknowledge financial support from the Research Institute on Verified Trustworthy Software Systems (VeTSS), which is funded by the UK National Cyber Security Centre (NCSC).
-
%%% Local Variables:
%%% mode: latex
%%% TeX-master: "main"