Some fixes to the prototype chapter.
[matthijs/master-project/report.git] / Chapters / Introduction.tex
index 5b11f5d26f3306447338a70c778e9d92d6fbc1ea..f6e65f9f5a02a572b1ff4576ef46930f3ed6924b 100644 (file)
@@ -6,6 +6,13 @@ compilers and introduce the hardware description language Cλash that will
 connect these worlds and puts a step towards making hardware programming
 on the whole easier, more maintainable and generally more pleasant.
 
+This assignment has been performed in close cooperation with Christiaan
+Baaij, whose Master's thesis \cite[baaij09]\ has been completed at the
+same time as this thesis. Where this thesis focuses on the
+interpretation of the Haskell language and the compilation process,
+\cite[baaij09]\ has a more thorough study of the field, explores more
+advanced types and provides a case study.
+
 % Use \subject to hide this section from the toc
 \subject{Research goals}
   This research started out with the notion that a functional program is very
@@ -17,7 +24,7 @@ on the whole easier, more maintainable and generally more pleasant.
   As a motivating example, consider the simple functional program shown in
   \in{example}[ex:AndWord]\footnote[notfinalsyntax]{This example is not in the final
   Cλash syntax}. This is a very natural way to describe a lot of parallel not
-  ports, that perform a bitwise not on a bitvector. The example also shows an
+  ports, that perform a bit-wise not on a bit-vector. The example also shows an
   image of the architecture described.
 
   \startbuffer[AndWord]
@@ -58,18 +65,18 @@ on the whole easier, more maintainable and generally more pleasant.
     % Draw a dotted line between the middle operations
     ncline(a2)(a3) "linestyle(dashed withdots)", "arrows(-)";
   \stopuseMPgraphic
-  \placeexample[here][ex:AndWord]{Simple architecture that inverts a vector of bits.}
+  \placeexample[][ex:AndWord]{Simple architecture that inverts a vector of bits.}
     \startcombination[2*1]
       {\typebufferlam{AndWord}}{Haskell description of the architecture.}
       {\boxedgraphic{AndWord}}{The architecture described by the Haskell description.}
     \stopcombination
 
   Slightly more complicated is the incremental summation of
-  values show in \in{example}[ex:RecursiveSum]\note[notfinalsyntax].
+  values shown in \in{example}[ex:RecursiveSum]\note[notfinalsyntax].
 
   In this example we see a recursive function \hs{sum'} that recurses over a
   list and takes an accumulator argument that stores the sum so far. On each
-  step of the recusion, another number from the input vector is added to the
+  step of the recursion, another number from the input vector is added to the
   accumulator and each intermediate step returns its result.
 
   This is a nice description of a series of sequential adders that produce
@@ -141,7 +148,7 @@ on the whole easier, more maintainable and generally more pleasant.
 
   Or... is this the description of a single accumulating adder, that will add
   one element of each input each clock cycle and has a reset value of
-  0\todo{normal 0}? In
+  {\definedfont[Serif*normalnum]0}? In
   that case, we would have described the architecture show in \in{example}[ex:RecursiveSumAlt]
 
   \startuseMPgraphic{RecursiveSumAlt}
@@ -197,23 +204,23 @@ on the whole easier, more maintainable and generally more pleasant.
   \stopquotation
   \setupquotation[style=normal,spacebefore=]
 
-  We can further split this into subquestions from a hardware perspective:
+  We can further split this into sub-questions from a hardware perspective:
   \startitemize
     \item How can we describe a stateful design?
     \item How can we describe (hierarchical) structure in a design?
   \stopitemize
   
-  And subquestions from a functional perspective:
+  And sub-questions from a functional perspective:
   \startitemize
     \item How to interpret recursion in descriptions?
     \item How to interpret polymorphism?
-    \item How to interpret higher order descriptions?
+    \item How to interpret higher-order descriptions?
   \stopitemize
 
   In addition to looking at designing a hardware description language, we
   will also implement a prototype to test ideas. This prototype will
   translate hardware descriptions written in the Haskell functional language
-  to simple (netlist-like) hardware descriptions in the \VHDL language. The
+  to simple (netlist-like) hardware descriptions in the \VHDL\ language. The
   reasons for choosing these languages are detailed in section
   \in{}[sec:prototype:input] and \in{}[sec:prototype:output] respectively.
 
@@ -229,6 +236,8 @@ on the whole easier, more maintainable and generally more pleasant.
     Systems). The lambda in the name is of course a reference to the
     lambda abstraction, which is an essential element of most functional
     languages (and is also prominent in the Haskell logo).
+
+    Cλash is pronounced like \quote{Clash}.
     \stopframedtext
   }
 
@@ -241,11 +250,11 @@ on the whole easier, more maintainable and generally more pleasant.
 In the first chapter, we will sketch the context for this research.
 The current state and history of hardware description languages will be
 briefly discussed, as well as the state and history of functional
-programming. Since we're not the first to have merged these approaches,
+programming. Since we are not the first to have merged these approaches,
 a number of other functional hardware description languages are briefly
 described.
 
-Chapter two describes the exploratory part of this research: How can we
+Chapter two describes the exploratory part of this research: how can we
 describe hardware using a functional language and how can we use functional
 concepts for hardware descriptions?
 
@@ -255,7 +264,7 @@ hardware descriptions, Haskell. The possibilities and limits of this prototype
 are further explored.
 
 During the creation of the prototype, it became apparent that some structured
-way of doing program transformations was required. Doing ad-hoc interpretation
+way of doing program transformations was required. Doing ad hoc interpretation
 of the hardware description proved non-scalable. These transformations and
 their application are the subject of the fourth chapter.