-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
-add a different abstraction mechanism that will allow for the modeling of
-asynchronous systems.
-
-Like the standard hardware description languages, descriptions made in a
-functional hardware description language must eventually be converted into a
-netlist. This research also features a prototype translator, which has the
-same name as the language: \CLaSH\footnote{\CLaSHtiny: \acrotiny{CAES}
-Language for Synchronous Hardware} (pronounced: clash). This compiler converts
-the Haskell code to equivalently behaving synthesizable \VHDL\ code, ready to
-be converted to an actual netlist format by an (optimizing) \VHDL\ synthesis
-tool.
-
-Besides trivial circuits such as variants of both the \acro{FIR} filter and
-the simple \acro{CPU} shown in \Cref{sec:usecases}, the \CLaSH\ compiler has
-also been shown to work for non-trivial descriptions. \CLaSH\ has been able to
-successfully translate the functional description of a streaming reduction
-circuit~\cite{reductioncircuit} for floating point numbers.
-
+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}.
+% 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, as a transition from the
+current state to the next. Many functional \acrop{HDL} model signals as a
+stream of 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.
+However, there is room with the language to eventually add an abstraction
+mechanism that allows modeling of asynchronous and multi-clock systems.
+
+Likewise as with the traditional \acrop{HDL}, descriptions made in a
+functional \acro{HDL} must eventually be converted into a netlist. This
+research also features a prototype compiler, which has the same name as the
+language: \CLaSH\footnote{\CLaSHtiny: \acrotiny{CAES} Language for Synchronous
+Hardware, where \acrotiny{CAES} % the acronyom of our chair.}
+is hidden for blind review.}
+(pronounced: clash). This compiler converts the Haskell code to equivalently
+behaving synthesizable \VHDL\ code, ready to be converted to an actual netlist
+format by an (optimizing) \VHDL\ synthesis tool.
+
+To the best knowledge of the authors, \CLaSH\ is the only (functional)
+\acro{HDL} that allows circuit specification to be written in a very concise
+way and at the same time support such advanced features as polymorphic typing,
+user-defined higher-order functions and pattern matching.
+
+The next section will describe the language elements of \CLaSH, and \Cref{sec:compiler} gives a high-level overview of the \CLaSH\ compiler. \Cref{sec:usecases} discusses two use-cases, a \acro{FIR} filter, and a higher-order \acro{CPU} design. At the end, \Cref{sec:relatedwork} compares \CLaSH\ to existing (functional) \acrop{HDL}, conclusions are given in \Cref{sec:conclusion}, and future work is discussed in \Cref{sec:futurework}.
+