Add more to intro

1 files changed, 3 insertions, 3 deletions

diff --git a/introduction.tex b/introduction.tex
index 4c771ef..afbaabe 100644
--- a/introduction.tex
+++ b/introduction.tex
@@ -8,14 +8,14 @@ One current approach to writing energy-efficient and high-throughput application
 
 High-level synthesis is becoming increasingly important in the hardware design process.  HLS elevates the level of abstraction, allowing designers to describe behaviour using an untimed representation, which reduces the amount of bugs that could be introduced into the design.  The higher level of abstraction makes it easier to reason about the algorithms and therefore also facilitates maintaining them.  In addition to reducing the time it takes hardware designers to produce hardware, it also reduces the barrier of entry to hardware design for software programmers.  In both cases, correctness of the HLS tool is important, as it hinders the productivity of hardware designers by needing them to check the function correctness of the hardware, whereas software programmers may be unable to properly test the  hardware as they may be unaware of the proper tools.  In addition to that, functional verification of the design becomes much more efficient than at the HDL stage, since the entire software ecosystem can be mobilised for this task.  However, any properties that were proven about the functionality of the design may not hold for the hardware design, which may require separate checks.
 
-In addition to that, HLS tools are known to be unreliable and error prone When using HLS, it is therefore necessary to not only check the software version of the design correct, but also ensure that the generated hardware design works correctly, leading to duplicate testing and verifying of the resulting hardware design.  However, with the growing size of hardware designs, it may not be feasible to check that the hardware is correct for all possible inputs.  Duplicate checking discourages the use of HLS in safety-critical environments, where correctness is key.  It is therefore safer to design hardware separately
-
 %% Definition and benefits of HLS
 % \NR{The abstraction of HLS helps in two ways: improving productivity of hardware designers and reducing the entry barrier of hardware design for software programmers. Both these audiences stand to benefit from the guarantees provided by verified C-to-Verilog generation.} \JW{Yes, Nadesh makes a good point here. Worth incorporating.}\YH{Added.}
 
 %% Unreliability of HLS
 
-Bugs in HLS tools when designing hardware are detrimental, as it may not be possible to change the hardware once it is produced.  Designers often consider HLS tools to be quite unreliable and fragile with respect to which language features that are supported.  Most HLS tools cannot guarantee that compilation is behaviour-preserving.  In fact, on the contrary, there is some evidence that current HLS tools are actually quite \emph{unreliable} in this regard.  For instance, an attempt by \citet{lidbury15_many_core_compil_fuzzin} to fuzz Altera's (now Intel's) OpenCL compiler had to be abandoned because the compiler ``either crashed or emitted an internal compiler error'' on a large number of their test inputs.  In addition to that, work by Du \emph{et al.}~\cite{?} fuzz tested three major commercial HLS using Csmith~\cite{yang11_findin_under_bugs_c_compil}, while restricting the C programs to the constructs explicitly supported by the synthesis tools and found that on average 2.5\% of test cases generated a design that did not match the behaviour of the input.  Meanwhile, Xilinx's 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}}.
+Bugs in HLS tools when designing hardware are detrimental, as it may not be possible to change the hardware once it is produced.  It is therefore necessary to not only check the software version of the design correct, but also ensure that the generated hardware design works correctly, because the HLS tool can not be trusted, leading to duplicate testing and verifying of the resulting hardware design.  However, with the growing size of hardware designs, it may not be feasible to check that the hardware is correct for all possible inputs.  In addition to that, this duplicate checking discourages the use of HLS in safety-critical environments, where correctness is key.  It is therefore considered safer to manually write and verify all the hardware designs, hindering the use of higher-level constructs, faster iteration on the designs and more maintainable designs as could be achieved using HLS.\@
+
+This is further motivated by the fact that HLS tools are often considered to be quite unreliable and fragile with respect to which language features that are supported.  Most HLS tools cannot guarantee that compilation is behaviour-preserving.  In fact, on the contrary, there is some evidence that current HLS tools are actually quite \emph{unreliable} in this regard.  For instance, an attempt by \citet{lidbury15_many_core_compil_fuzzin} to fuzz Altera's (now Intel's) OpenCL compiler had to be abandoned because the compiler ``either crashed or emitted an internal compiler error'' on a large number of their test inputs.  In addition to that, work by Du \emph{et al.}~\cite{?} fuzz tested three major commercial HLS using Csmith~\cite{yang11_findin_under_bugs_c_compil}, while restricting the C programs to the constructs explicitly supported by the synthesis tools and found that on average 2.5\% of test cases generated a design that did not match the behaviour of the input.  Meanwhile, Xilinx's 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}}.
 
 % JW: Another candidate, probably less interesting:
 % https://bit.ly/intel-hls-memory-bug