-Hardware description languages have allowed the productivity of hardware
-engineers to keep pace with the development of chip technology. Standard
-Hardware description languages, 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{T-Ruby,Hydra,HML2,Hawk1,Lava,
-ForSyDe1,Wired,reFLect}. The idea of using functional languages for hardware
-descriptions started in the early 1980s \cite{Cardelli1981, muFP,DAISY,FHDL},
-a time which also saw the birth of the currently popular hardware description
-languages such as \VHDL. Functional languages are especially suited to
-describe hardware because combinational circuits can be directly modeled
-as mathematical functions and that functional languages are very good at
-describing and composing mathematical functions.
-
-In an attempt to decrease the amount of work involved in creating all the
-required tooling, such as parsers and type-checkers, many functional
-hardware description languages \cite{Hydra,Hawk1,Lava,ForSyDe1,Wired}
-are embedded as a domain specific language inside 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 domain specific language. The primitive functions used
-to describe a circuit do not actually process any signals, but instead
-compose a large domain-specific datatype (which is usually hidden from
-the designer). This datatype is then further processed by an embedded
-circuit compiler. This circuit compiler actually runs in the same
-environment as the description; as a result compile-time and run-time
-become hard to define, as the embedded circuit compiler is usually
-compiled by the same Haskell compiler as the circuit description itself.
-
-The approach taken in this research is not to make another domain specific
-language embedded in Haskell, but to use (a subset of) the Haskell language
-itself for the purpose of describing hardware. By taking this approach, we can
-capture certain language constructs, such as Haskell's choice elements
-(if-expressions, case-expressions, pattern matching, etc.), which are not
-available in the functional hardware description languages that are embedded
-in Haskell as a domain specific language. As far as the authors know, such
-extensive support for choice-elements is new in the domain of functional
-hardware description languages. As the hardware descriptions are plain Haskell
-functions, these descriptions can be compiled to an executable binary
-for simulation using an optimizing Haskell compiler such as the Glasgow
-Haskell Compiler (\GHC)~\cite{ghc}.
-
-Where descriptions in a conventional hardware description language have an
-explicit clock for the purpose state and synchronicity, the clock is implied
-in this research. A developer describes the behavior of the hardware between
-clock cycles. Many functional hardware description model signals as a stream
-of all values over time; state is then modeled as a delay on this stream of
-values. The approach taken in this research is to make the current state of a
-circuit part of the input of the function and the updated state part of the
-output. The current abstraction of state and time limits the descriptions to
-synchronous hardware, there however is room within the language to eventually
+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 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 e.g. 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 syntactic elements of the language
+itself.
+
+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 Haskell, such as polymorphic typing and higher-order
+functions, are also supported.
+
+% supporting polymorphism, higher-order functions and such an extensive array
+% of choice-elements, combined with a very concise way of specifying circuits
+% is new in the domain of (functional) \acrop{HDL}.
+% As the hardware descriptions are plain Haskell
+% functions, these descriptions can be compiled to an executable binary
+% for simulation using an optimizing Haskell compiler such as the Glasgow
+% Haskell Compiler (\GHC)~\cite{ghc}.
+
+Where descriptions in a conventional \acro{HDL} have an explicit clock for the
+purposes state and synchronicity, the clock is implicit for the descriptions
+and research presented in this paper. A circuit designer describes the
+behavior of the hardware between clock cycles. Many functional \acrop{HDL}
+model signals as a stream of all values over time; state is then modeled as a
+delay on this stream of values. Descriptions presented in this research make
+the current state an additional input and the updated state a part of their
+output. This abstraction of state and time limits the descriptions to
+synchronous hardware, there is however room within the language to eventually