summaryrefslogtreecommitdiffstats
path: root/introduction.tex
diff options
context:
space:
mode:
authorYann Herklotz <git@yannherklotz.com>2021-09-13 00:20:52 +0100
committerYann Herklotz <git@yannherklotz.com>2021-09-13 00:20:52 +0100
commitb4f5506f21bf98dc36e78a809a797413fe79e8b9 (patch)
tree4ff8374c4e63d6ea3f76e6d05bd000302233c2db /introduction.tex
parent311999d1c74ea03b57e7113335e0d2c88fa8f8cf (diff)
downloadoopsla21_fvhls-b4f5506f21bf98dc36e78a809a797413fe79e8b9.tar.gz
oopsla21_fvhls-b4f5506f21bf98dc36e78a809a797413fe79e8b9.zip
a HLS -> an HLS
Diffstat (limited to 'introduction.tex')
-rw-r--r--introduction.tex2
1 files changed, 1 insertions, 1 deletions
diff --git a/introduction.tex b/introduction.tex
index 45bb1a6..65b0bfc 100644
--- a/introduction.tex
+++ b/introduction.tex
@@ -21,7 +21,7 @@ Indeed, there are reasons to doubt that HLS tools actually \emph{do} always pres
%Other reasons are more specific:
For instance, Vivado HLS has been shown to apply pipelining optimisations incorrectly\footnote{\url{https://bit.ly/vivado-hls-pipeline-bug}} or to silently generate wrong code should the programmer stray outside the fragment of C that it supports.\footnote{\url{https://bit.ly/vivado-hls-pointer-bug}}
Meanwhile, \citet{lidbury15_many_core_compil_fuzzin} had to abandon their attempt to fuzz-test Altera's (now Intel's) OpenCL compiler since it ``either crashed or emitted an internal compiler error'' on so many of their test inputs.
-More recently, \citet{herklotz21_empir_study_reliab_high_level_synth_tools} fuzz-tested three commercial HLS tools using Csmith~\cite{yang11_findin_under_bugs_c_compil}, and despite restricting the generated programs to the C fragment explicitly supported by all the tools, they still found that on average 2.5\% of test cases were compiled to designs that behaved incorrectly. %\NR{The word `input' here made me think of I/Os. `input software' or just `software' is better. I think it is worth being consistent across the article on the word used to describe the software description provided to the HLS tool. Actually, we can even signpost it like: `From here on we used the word bla to refer to the input software that is provided to a HLS tool.'} %JW: thanks, done.
+More recently, \citet{herklotz21_empir_study_reliab_high_level_synth_tools} fuzz-tested three commercial HLS tools using Csmith~\cite{yang11_findin_under_bugs_c_compil}, and despite restricting the generated programs to the C fragment explicitly supported by all the tools, they still found that on average 2.5\% of test cases were compiled to designs that behaved incorrectly. %\NR{The word `input' here made me think of I/Os. `input software' or just `software' is better. I think it is worth being consistent across the article on the word used to describe the software description provided to the HLS tool. Actually, we can even signpost it like: `From here on we used the word bla to refer to the input software that is provided to an HLS tool.'} %JW: thanks, done.
\paragraph{Existing workarounds}