-Hardware description languages (\acrop{HDL}) have allowed the productivity of
-hardware engineers to keep pace with the development of chip technology.
-Standard \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,FHDL,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 well
-suited to describe hardware because combinational circuits can be directly
-modeled as mathematical functions. Furthermore, 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
-\acrop{HDL} \cite{Hydra,Hawk1,Lava,ForSyDe1,Wired} are embedded as a domain
-specific language (\acro{DSL}) 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
-\acro{DSL}. 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.
-Though the embedded language approach still allows for the support of
-polymorphism and higher-order functions, it impossible to capture Haskell's
-choice elements within a circuit description.
-
-The approach taken in this research is not to make another \acro{DSL} embedded
-in Haskell, but to use (a subset of) the Haskell language \emph{itself} for
-the purpose of describing hardware. By taking this approach, we \emph{can}
-capture certain language constructs, such as Haskell's choice elements
-(\hs{if}-expressions, \hs{case}-expressions, pattern matching, etc.), within
-circuit descriptions. To the best knowledge of the authors, supporting
-polymorphism, higher-order functions and such an extensive array of
-choice-elements is new in the domain of functional \acrop{HDL}.
+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,FHDL,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,FHDL}, 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 graph.
+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 exist as functions, e.g. a multiplexer
+function, and not as syntactic elements of the language itself.
+
+This research uses (a subset of) the Haskell language \emph{itself} for the
+purpose of describing hardware. As a result, certain language constructs, like
+all of Haskell's choice elements, \emph{can} now be captured within circuit
+descriptions. 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}.