-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,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.
+
+% 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}.