-Hardware description languages (\acrop{HDL}) have allowed the productivity of
-hardware engineers to keep pace with the development of chip technology.
-Traditional \acrop{HDL}, like \VHDL~\cite{VHDL2008} and
-Verilog~\cite{Verilog}, allowed an engineer to describe circuits using a
-`programming' language. These standard languages are very good at describing
-detailed hardware properties such as timing behavior, but are generally
-cumbersome in expressing higher-level abstractions. In an attempt to raise the
-abstraction level of the descriptions, a great number of approaches based on
-functional languages has been proposed \cite{Cardelli1981,muFP,DAISY,
-T-Ruby,HML2,Hydra,Hawk1,Lava,Wired,ForSyDe1,reFLect}. The idea of using
-functional languages for hardware descriptions started in the early 1980s
-\cite{Cardelli1981,muFP,DAISY}, a time which also saw the birth of the
-currently popular \acrop{HDL}, such as \VHDL. Functional
-languages are especially well suited to describe hardware because
-combinational circuits can be directly modeled as mathematical functions and
-functional languages are very good at describing and composing these
-functions.
-
-In an attempt to ease the prototyping process of the language, such as
-creating all the required tooling, like parsers and type-checkers, many
-functional \acrop{HDL} \cite{Hydra,Hawk1,Lava,Wired} are embedded as a domain
-specific language (\acro{DSL}) within the functional language Haskell
-\cite{Haskell}. This means that a developer is given a library of Haskell
-functions and types that together form the language primitives of the
-\acro{DSL}. The primitive functions used to describe a circuit do not actually
-process any signals, they instead compose a large domain-specific graph
-(which is usually hidden from the designer). This graph is then further
-processed by an embedded circuit compiler which can perform for example
-simulation or synthesis. As Haskell's choice elements (\hs{case}-expressions,
-pattern-matching etc.) are evaluated at the time the domain-specific graph is
-being build, they are no longer visible to the embedded compiler that
-processes the datatype. Consequently, it is impossible to capture Haskell's
-choice elements within a circuit description when taking the embedded language
-approach. This does not mean that circuits specified in an embedded language
-can not contain choice, just that choice elements only exists as functions,
-e.g. a multiplexer function, and not as language elements.
-
-The approach taken in this research is to use (a subset of) the Haskell
-language \emph{itself} for the purpose of describing hardware. By taking this
-approach, this research \emph{can} capture certain language constructs, like
-all of Haskell's choice elements, within circuit descriptions. The more
-advanced features of Haskel, such as polymorphic typing and higher-order
-function, are also supported.
+Hardware description languages (\acrop{HDL}) have not allowed the productivity
+of hardware engineers to keep pace with the development of chip technology.
+While traditional \acrop{HDL}, like \VHDL~\cite{VHDL2008} and
+Verilog~\cite{Verilog}, are very good at describing detailed hardware
+properties such as timing behavior, they are generally cumbersome in
+expressing the higher-level abstractions needed for today's large and complex
+circuit designs. In an attempt to raise the abstraction level of the
+descriptions, a great number of approaches based on functional languages have
+been proposed \cite{Cardelli1981,muFP,DAISY,T-Ruby,HML2,Hydra,Hawk1,Lava,
+Wired,ForSyDe1,reFLect}. The idea of using functional languages for hardware
+descriptions started in the early 1980s \cite{Cardelli1981,muFP,DAISY}, a
+time which also saw the birth of the currently popular \acrop{HDL}, such as
+\VHDL. Functional languages are especially well suited to describe hardware
+because combinational circuits can be directly modeled as mathematical
+functions and functional languages are very good at describing and composing
+these functions.
+
+In an attempt to reduce the effort involved with prototyping a new
+language, such as creating all the required tooling like parsers and
+type-checkers, many functional \acrop{HDL} \cite{Hydra,Hawk1,Lava,Wired} are
+embedded as a domain specific language (\acro{DSL}) within the functional
+language Haskell \cite{Haskell}. This means that a developer is given a
+library of Haskell functions and types that together form the language
+primitives of the \acro{DSL}. The primitive functions used to describe a
+circuit do not actually process any signals, they instead compose a large
+graph (which is usually hidden from the designer). This graph is then further processed by an embedded circuit compiler which can perform e.g. simulation or synthesis. As Haskell's choice elements (\hs{case}-expressions, pattern-matching, etc.) are evaluated at the time the graph is being build, they are no longer visible to the embedded compiler that processes the datatype. Consequently, it is impossible to capture Haskell's choice elements within a circuit description when taking the embedded language approach. This does not mean that circuits specified in an embedded language can not contain choice, just that choice elements only exists as functions, e.g. a multiplexer function, and not as syntactic elements of the language itself.
+
+This research is uses (a subset of) the Haskell language \emph{itself} for the purpose of describing hardware. By taking this approach, this research \emph{can} capture certain language constructs, like all of Haskell's choice elements, within circuit descriptions. Advanced features of Haskell, such as polymorphic typing and higher-order functions, are also supported.