Add new introduction start

1 files changed, 3 insertions, 1 deletions

diff --git a/introduction.tex b/introduction.tex
index 35d5ce7..6793af6 100644
--- a/introduction.tex
+++ b/introduction.tex
@@ -6,7 +6,9 @@
 
 \JW{A few high-level comments: \begin{enumerate} \item Create more tension from the start by making the reader doubt whether existing HLS tools are trustworthy. \item The intro currently draws quite a bit of motivation from Lidbury et al. 2015, but we should also now lean on our FPGA submission too. \item I wonder whether the paragraph `To mitigate the problems...' should be demoted to a `related work' discussion (perhaps as a subsection towards the end of the introduction). It outlines (and nicely dismisses) some existing attempts to tackle the problem, which is certainly useful motivation for your work, especially for readers already familiar with HLS, but I feel that it's not really on the critical path for understanding the paper.\end{enumerate}}
 
-One current approach to writing energy-efficient and high-throughput applications is to use application-specific hardware, instead of relying on a general-purpose CPU.\@  However, custom hardware designs come at the cost of having to design and produce them, which can be a tedious and error-prone process using hardware description languages (HDL) such as Verilog.  High-level synthesis (HLS) is becoming a
+One current approach to writing energy-efficient and high-throughput applications is to use application-specific hardware, instead of relying on a general-purpose CPU.\@  However, custom hardware designs come at the cost of having to design and produce them, which can be a tedious and error-prone process using hardware description languages (HDL) such as Verilog.  High-level synthesis (HLS) is becoming a viable alternative, allowing designers to describe the hardware in a software programming language such as C, and inferring the hardware design from it.  However, can we really trust that the generated hardware functions correctly?  It is often assumed that compilers do not change the behaviour of the original program through it's various transformations, however, as HLS tools perform complex transformations, this might not always be the case.
+
+Compiler bugs in HLS tools when designing hardware are detrimental, as it may not be possible to change the hardware once it is produced.  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 also works correctly.
 
 Especially with the size of hardware designs growing over the years, it can become difficult to verify that the hardware design behaves in the expected way, as simulation of HDLs can be quite inefficient.  Furthermore, the algorithms that are being accelerated in hardware often already have a software implementation, meaning they have to be reimplemented efficiently in a hardware description language which can be time-consuming.