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 hardware description languages, such as \VHDL. Functional
+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
-mathematical functions.
+functional languages are very good at describing and composing these
+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
simulation or synthesis. As Haskell's choice elements (\hs{if}-expressions,
\hs{case}-expressions, etc.) are evaluated at the time the domain-specific
datatype is being build, they are no longer visible to the embedded compiler
-that processes the datatype. Consequently, it is impossible the capture
+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
\emph{can} capture certain language constructs, such as Haskell's choice
elements, 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}.
+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
Though ForSyDe offers higher-order functions and polymorphism, ForSyDe's
choice elements are limited to \hs{if} and \hs{case} expressions. ForSyDe's
explicit conversions, where function have to be wrapped in processes and
-process have to be wrapped in systems, combined with the explicit
-instantiations of components also makes ForSyDe more verbose than
-\CLaSH.
+processes have to be wrapped in systems, combined with the explicit
+instantiations of components, also makes ForSyDe more verbose than \CLaSH.
Lava~\cite{Lava} is a hardware description language, embedded in Haskell, and
focuses on the structural representation of hardware. Like \CLaSH, Lava has
\CLaSH\ differs from Lava, in that all of Haskell's choice elements, such as
\hs{case}-expressions and pattern matching, are synthesized to choice elements
in the eventual circuit. Consequently, descriptions containing rich control
-structures can be specified in a far more user-friendly way in \CLaSH\ than
-possible within Lava. As a result, the control structures are also less
-error-prone.
+structures can be specified in a more user-friendly way in \CLaSH\ than possible within Lava, and are hence less error-prone.
Bluespec~\cite{Bluespec} is a high-level synthesis language that features
guarded atomic transactions and allows for the automated derivation of control
projects / matthijs / master-project / dsd-paper.git / blobdiff