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 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,FHDL}, a time which also saw the birth of the
-currently popular hardware description languages, such as \VHDL. Functional
+\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
-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
-\acrop{HDL} \cite{Hydra,Hawk1,Lava,ForSyDe1,Wired} are embedded as a domain
+\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
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. Descriptions can however still contain
-polymorphism and higher-order functions.
+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 language
+elements.
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
\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
\end{minipage}
\begin{figure}
- \vspace{1em}
\centerline{\includegraphics{mac-nocurry.svg}}
\caption{Combinational Multiply-Accumulate (composite output)}
\label{img:mac-comb-composite}
\end{minipage}
\begin{figure}
+ \vspace{1em}
\centerline{\includegraphics{choice-case.svg}}
\caption{Choice - sumif}
\label{img:choice}
description languages and highlights the advantages that this research has
over existing work.
-Many functional hardware description languages have been developed over the
-years. Early work includes such languages as $\mu$\acro{FP}~\cite{muFP}, an
-extension of Backus' \acro{FP} language to synchronous streams, designed
-particularly for describing and reasoning about regular circuits. The
-Ruby~\cite{Ruby} language uses relations, instead of functions, to describe
-circuits, and has a particular focus on layout.
-
-\begin{figure}
-\centerline{\includegraphics{highordcpu.svg}}
-\caption{CPU with higher-order Function Units}
-\label{img:highordcpu}
-\vspace{-1.5em}
-\end{figure}
+% Many functional hardware description languages have been developed over the
+% years. Early work includes such languages as $\mu$\acro{FP}~\cite{muFP}, an
+% extension of Backus' \acro{FP} language to synchronous streams, designed
+% particularly for describing and reasoning about regular circuits. The
+% Ruby~\cite{Ruby} language uses relations, instead of functions, to describe
+% circuits, and has a particular focus on layout.
\acro{HML}~\cite{HML2} is a hardware modeling language based on the strict
functional language \acro{ML}, and has support for polymorphic types and
\CLaSH\ compiler on the other hand can correctly translate all of the language
constructs mentioned in this paper. % to a netlist format.
-Like the work presented in this paper, many functional hardware description
-languages have some sort of foundation in the functional programming language
-Haskell. Hawk~\cite{Hawk1} uses Haskell to describe system-level executable
-specifications used to model the behavior of superscalar microprocessors. Hawk
-specifications can be simulated; to the best knowledge of the authors there is
-however no support for automated circuit synthesis.
+\begin{figure}
+\centerline{\includegraphics{highordcpu.svg}}
+\caption{CPU with higher-order Function Units}
+\label{img:highordcpu}
+\vspace{-1.5em}
+\end{figure}
+
+Like the research presented in this paper, many functional hardware
+description languages have some sort of foundation in the functional
+programming language Haskell. Hawk~\cite{Hawk1} uses Haskell to describe
+system-level executable specifications used to model the behavior of
+superscalar microprocessors. Hawk specifications can be simulated; to the best
+knowledge of the authors there is however no support for automated circuit
+synthesis.
The ForSyDe~\cite{ForSyDe2} system uses Haskell to specify abstract system
models. A designer can model systems using heterogeneous models of
electronic systems which have both analog as digital parts. ForSyDe has
several backends including simulation and automated synthesis, though
automated synthesis is restricted to the synchronous model of computation.
-Unlike \CLaSH\ there is no support for the automated synthesis of descriptions
-that contain polymorphism or higher-order functions.
-
-Lava~\cite{Lava} is a hardware description language that focuses on the
-structural representation of hardware. Besides support for simulation and
-circuit synthesis, Lava descriptions can be interfaced with formal method
-tools for formal verification. Lava descriptions are actually circuit
-generators when viewed from a synthesis viewpoint, in that the language
-elements of Haskell, such as choice, can be used to guide the circuit
-generation. If a developer wants to insert a choice element inside an actual
-circuit he will have to explicitly instantiate a multiplexer-like component.
-
-In this respect \CLaSH\ differs from Lava, in that all the choice elements,
-such as case-statements and pattern matching, are synthesized to choice
-elements in the eventual circuit. As such, richer control structures can both
-be specified and synthesized in \CLaSH\ compared to any of the embedded
-languages, such as: Hawk, ForSyDe, or Lava.
-
-The merits of polymorphic typing, combined with higher-order functions, are
-now also recognized in the `main-stream' hardware description languages,
-exemplified by the new \VHDL-2008 standard~\cite{VHDL2008}. \VHDL-2008 support
-for generics has been extended to types and subprograms, allowing a developer
-to describe components with polymorphic ports and function-valued arguments.
-Note that the types and subprograms still require an explicit generic map,
-whereas types can be automatically inferred, and function-values can be
-automatically propagated by the \CLaSH\ compiler. There are also no (generally
-available) \VHDL\ synthesis tools that currently support the \VHDL-2008
-standard, and thus the synthesis of polymorphic types and function-valued
-arguments.
+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
+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
+support for polymorphic types and higher-order functions. Besides support for
+simulation and circuit synthesis, Lava descriptions can be interfaced with
+formal method tools for formal verification. As discussed in the introduction,
+taking the embedded language approach does not allow for Haskell's choice
+elements to be captured within the circuit descriptions. In this respect
+\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 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
+structures based on these atomic transactions. Bluespec, like \CLaSH, supports
+polymorphic typing and function-valued arguments. Bluespec's syntax and
+language features \emph{had} their basis in Haskell. However, in order to
+appeal to the users of the traditional \acrop{HDL}, Bluespec has adapted
+imperative features and a syntax that resembles Verilog. As a result, Bluespec
+is (unnecessarily) verbose when compared to \CLaSH.
+
+The merits of polymorphic typing and function-valued arguments are now also
+recognized in the traditional \acrop{HDL}, exemplified by the new \VHDL-2008
+standard~\cite{VHDL2008}. \VHDL-2008 support for generics has been extended to
+types and subprograms, allowing a designer to describe components with
+polymorphic ports and function-valued arguments. Note that the types and
+subprograms still require an explicit generic map, whereas types can be
+automatically inferred, and function-values can be automatically propagated
+by the \CLaSH\ compiler. There are also no (generally available) \VHDL\
+synthesis tools that currently support the \VHDL-2008 standard.
% Wired~\cite{Wired},, T-Ruby~\cite{T-Ruby}, Hydra~\cite{Hydra}.
%
projects / matthijs / master-project / dsd-paper.git / blobdiff