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
+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
+\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
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]
% 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
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
- \lam{0}? In
+ {\definedfont[Serif*normalnum]0}? In
that case, we would have described the architecture show in \in{example}[ex:RecursiveSumAlt]
\startuseMPgraphic{RecursiveSumAlt}
\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?
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.
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
}
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?
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.