From affd28eceee9b564f5b7ba5321ea0c617df808f5 Mon Sep 17 00:00:00 2001 From: John Wickerson Date: Mon, 14 Sep 2020 21:59:45 +0000 Subject: Update on Overleaf. --- conclusion.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/conclusion.tex b/conclusion.tex index 7d65824..c3acf9c 100644 --- a/conclusion.tex +++ b/conclusion.tex @@ -1,7 +1,7 @@ \section{Conclusion} We have shown how existing fuzzing tools can be modified so that their outputs are compatible with HLS tools. We have used this testing framework to run 10,000 test cases \JW{check numbers} through three different HLS tools. In total, we found at least 6 individual and unique bugs in all the tools, which have been reduced, analysed, and reported to the tool vendors. These bugs include crashes as well as instances of generated designs not behaving in the same way as the original code. -One can always question how much bugs found by fuzzers really \emph{matter}, given that they are usually found by combining language features in ways that are vanishingly unlikely to happen `in the wild'. This question is especially pertinent for our particular context of HLS tools, which are well-known to have restrictions on the language features that they handle. Nevertheless, we would argue that any errors in the design have the potential to cause problems +One can always question how much bugs found by fuzzers really \emph{matter}, given that they are usually found by combining language features in ways that are vanishingly unlikely to happen `in the wild'. This question is especially pertinent for our particular context of HLS tools, which are well-known to have restrictions on the language features that they handle. Nevertheless, we would argue that any errors in the logic of th have the potential to cause problems Further work could be done on supporting more HLS tools, especially ones that claim to prove that their output is correct before terminating. This could give an indication on how effective these proofs are, and how often they are actually able to complete their equivalence proofs during compilation in a feasible time scale. -- cgit From 60006f3735f3ee2d1dae1e73e79e27e2f36be546 Mon Sep 17 00:00:00 2001 From: John Wickerson Date: Mon, 14 Sep 2020 22:04:05 +0000 Subject: Update on Overleaf. --- conclusion.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/conclusion.tex b/conclusion.tex index c3acf9c..cd052bb 100644 --- a/conclusion.tex +++ b/conclusion.tex @@ -1,7 +1,7 @@ \section{Conclusion} We have shown how existing fuzzing tools can be modified so that their outputs are compatible with HLS tools. We have used this testing framework to run 10,000 test cases \JW{check numbers} through three different HLS tools. In total, we found at least 6 individual and unique bugs in all the tools, which have been reduced, analysed, and reported to the tool vendors. These bugs include crashes as well as instances of generated designs not behaving in the same way as the original code. -One can always question how much bugs found by fuzzers really \emph{matter}, given that they are usually found by combining language features in ways that are vanishingly unlikely to happen `in the wild'. This question is especially pertinent for our particular context of HLS tools, which are well-known to have restrictions on the language features that they handle. Nevertheless, we would argue that any errors in the logic of th have the potential to cause problems +One can always question how much bugs found by fuzzers really \emph{matter}, given that they are usually found by combining language features in ways that are vanishingly unlikely to happen `in the wild'. This question is especially pertinent for our particular context of HLS tools, which are well-known to have restrictions on the language features that they handle. Nevertheless, we would argue that any errors in the HLS tool are worth identifying because they have the potential to cause problems, either now or in the future. And when HLS tools \emph{do} go wrong (or indeed any sort of compiler for that matter), it is particularly infuriating for end-users because it is so difficult to identify whether the problem Further work could be done on supporting more HLS tools, especially ones that claim to prove that their output is correct before terminating. This could give an indication on how effective these proofs are, and how often they are actually able to complete their equivalence proofs during compilation in a feasible time scale. -- cgit