% should be used if it is desired that the figures are to be displayed in
% draft mode.
%
+
\documentclass[conference,pdf,a4paper,10pt,final,twoside,twocolumn]{IEEEtran}
% Add the compsoc option for Computer Society conferences.
%
-
-
-
% *** CITATION PACKAGES ***
%
\usepackage{cite}
% *** GRAPHICS RELATED PACKAGES ***
%
\ifCLASSINFOpdf
- % \usepackage[pdftex]{graphicx}
+ \usepackage[pdftex]{graphicx}
% declare the path(s) where your graphic files are
% \graphicspath{{../pdf/}{../jpeg/}}
% and their extensions so you won't have to specify these with
\setlength{\leftmargin}{\labelwidth}
\addtolength{\leftmargin}{\labelsep}
\setlength{\rightmargin}{0pt}
- \setlength{\parsep}{0.5ex plus 0.2ex minus 0.1ex}
+ \setlength{\listparindent}{\parindent}
\setlength{\itemsep}{0 ex plus 0.2ex}
\renewcommand{\makelabel}[1]{##1:\hfil}
}
{\end{list}}
\usepackage{paralist}
+\usepackage{xcolor}
+\def\comment#1{{\color[rgb]{1.0,0.0,0.0}{#1}}}
+
+\usepackage{cleveref}
+\crefname{figure}{figure}{figures}
+\newcommand{\fref}[1]{\cref{#1}}
+\newcommand{\Fref}[1]{\Cref{#1}}
+
%include polycode.fmt
%include clash.fmt
\author{\IEEEauthorblockN{Christiaan P.R. Baaij, Matthijs Kooijman, Jan Kuper, Marco E.T. Gerards, Bert Molenkamp, Sabih H. Gerez}
\IEEEauthorblockA{University of Twente, Department of EEMCS\\
P.O. Box 217, 7500 AE, Enschede, The Netherlands\\
-c.p.r.baaij@@utwente.nl, matthijs@@stdin.nl}}
+c.p.r.baaij@@utwente.nl, matthijs@@stdin.nl, j.kuper@@utwente.nl}}
% \and
% \IEEEauthorblockN{Homer Simpson}
% \IEEEauthorblockA{Twentieth Century Fox\\
\section{Introduction}
Hardware description languages has allowed the productivity of hardware
engineers to keep pace with the development of chip technology. Standard
-Hardware description languages, like \VHDL\ and 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. These languages also tend to have a complex syntax and a lack of
-formal semantics. To overcome these complexities, and raise the abstraction
-level, 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 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. What gives functional languages
-as hardware description languages their merits is the fact that basic
-combinatorial circuits are equivalent to mathematical function, and that
-functional languages lend themselves very well to describe and compose these
-mathematical functions.
+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. The merit of using a functional language to describe
+hardware comes from the fact that basic combinatorial circuits are equivalent
+to 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 with creating all the
required tooling, such as parsers and type-checkers, many functional hardware
description languages are embedded as a domain specific language inside the
-functional language Haskell \cite{Hydra,Hawk1,Lava,ForSyDe1,Wired}. What this
-means is that a developer is given a library of Haskell functions and types
-that together form the language primitives of the domain specific language.
-Using these functions, the designer does not only describes a circuit, but
-actually builds a large domain-specific datatype which can be further
-processed by an embedded compiler. This 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 compiler is usually compiled by the same
-Haskell compiler as the circuit description itself.
+functional language Haskell \cite{Hydra,Hawk1,Lava,ForSyDe1,Wired}. This
+means that a developer is given a library of Haskell~\cite{Haskell} functions
+and types that together form the language primitives of the domain specific
+language. As a result of how the signals are modeled and abstracted, the
+functions used to describe a circuit also build a large domain-specific
+datatype (hidden from the designer) which can be further processed by an
+embedded compiler. This 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 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 to be used as hardware description language.
+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-constructs, case-constructs, pattern matching, etc.), which are not
+available in the functional hardware description languages that are embedded
+in Haskell as a domain specific languages. As far as the authors know, such
+extensive support for choice-elements is new in the domain of functional
+hardware description language. As the hardware descriptions are plain Haskell
+functions, these descriptions can be compiled for simulation using using the
+optimizing Haskell compiler \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. The functions describe the behavior of the hardware between
+clock cycles, as such, only synchronous systems can be described. Many
+functional hardware description models 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.
+
+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 called \CLaSH\
+(pronounced: clash), which 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.
\section{Hardware description in Haskell}
\subsection{Function application}
The basic syntactic elements of a functional program are functions
- and function application. These have a single obvious \VHDL\
- translation: each top level function becomes a hardware component,
- where each argument is an input port and the result value is the
- (single) output port. This output port can have a complex type (such
- as a tuple), so having just a single output port does not create a
- limitation.
-
- Each function application in turn becomes component instantiation.
- Here, the result of each argument expression is assigned to a
- signal, which is mapped to the corresponding input port. The output
- port of the function is also mapped to a signal, which is used as
- the result of the application itself.
+ and function application. These have a single obvious translation to a
+ netlist: every function becomes a component, every function argument is an
+ input port and the result value is of a function is an output port. This
+ output port can have a complex type (such as a tuple), so having just a
+ single output port does not create a limitation. Each function application
+ in turn becomes a component instantiation. Here, the result of each
+ argument expression is assigned to a signal, which is mapped to the
+ corresponding input port. The output port of the function is also mapped
+ to a signal, which is used as the result of the application itself.
Since every top level function generates its own component, the
- hierarchy of of function calls is reflected in the final \VHDL\
- output as well, creating a hierarchical \VHDL\ description of the
- hardware. This separation in different components makes the
- resulting \VHDL\ output easier to read and debug.
-
- Example that defines the \texttt{mac} function by applying the
- \texttt{add} and \texttt{mul} functions to calculate $a * b + c$:
-
-\begin{code}
-mac a b c = add (mul a b) c
-\end{code}
-
- TODO: Pretty picture
-
- \subsection{Choices}
- Although describing components and connections allows describing a
- lot of hardware designs already, there is an obvious thing missing:
- choice. We need some way to be able to choose between values based
- on another value. In Haskell, choice is achieved by \hs{case}
- expressions, \hs{if} expressions, pattern matching and guards.
-
- The easiest of these are of course case expressions (and \hs{if}
- expressions, which can be very directly translated to \hs{case}
- expressions). A \hs{case} expression can in turn simply be
- translated to a conditional assignment in \VHDL, where the
- conditions use equality comparisons against the constructors in the
- \hs{case} expressions.
-
- A slightly more complex (but very powerful) form of choice is
- pattern matching. A function can be defined in multiple clauses,
- where each clause specifies a pattern. When the arguments match the
- pattern, the corresponding clause will be used.
-
- A pattern match (with optional guards) can also be implemented using
- conditional assignments in \VHDL, where the condition is the logical
- and of comparison results of each part of the pattern as well as the
- guard.
-
- Contrived example that sums two values when they are equal or
- non-equal (depending on the predicate given) and returns 0
- otherwise. This shows three implementations, one using and if
- expression, one using only case expressions and one using pattern
- matching and guards.
-
-\begin{code}
-sumif pred a b = if pred == Eq && a == b ||
- pred == Neq && a != b
- then a + b
- else 0
-
-sumif pred a b = case pred of
- Eq -> case a == b of
- True -> a + b
- False -> 0
- Neq -> case a != b of
- True -> a + b
- False -> 0
-
-sumif Eq a b | a == b = a + b
-sumif Neq a b | a != b = a + b
-sumif _ _ _ = 0
-\end{code}
-
- TODO: Pretty picture
+ hierarchy of function calls is reflected in the final netlist aswell,
+ creating a hierarchical description of the hardware. This separation in
+ different components makes the resulting \VHDL\ output easier to read and
+ debug.
+
+ As an example we can see the netlist of the |mac| function in
+ \Cref{img:mac-comb}; the |mac| function applies both the |mul| and |add|
+ function to calculate $a * b + c$:
+
+ \begin{code}
+ mac a b c = add (mul a b) c
+ \end{code}
+
+ \begin{figure}
+ \centerline{\includegraphics{mac}}
+ \caption{Combinatorial Multiply-Accumulate}
+ \label{img:mac-comb}
+ \end{figure}
+
+ The result of using a complex input type can be seen in
+ \cref{img:mac-comb-nocurry} where the |mac| function now uses a single
+ input tuple for the |a|, |b|, and |c| arguments:
+
+ \begin{code}
+ mac (a, b, c) = add (mul a b) c
+ \end{code}
+
+ \begin{figure}
+ \centerline{\includegraphics{mac-nocurry}}
+ \caption{Combinatorial Multiply-Accumulate (complex input)}
+ \label{img:mac-comb-nocurry}
+ \end{figure}
+
+ \subsection{Choice}
+ In Haskell, choice can be achieved by a large set of language constructs,
+ consisting of: \hs{case} constructs, \hs{if-then-else} constructs,
+ pattern matching, and guards. The easiest of these are the \hs{case}
+ constructs (and \hs{if} expressions, which can be very directly translated
+ to \hs{case} expressions). A \hs{case} expression can in turn simply be
+ translated to a conditional assignment in \VHDL, where the conditions use
+ equality comparisons against the constructors in the \hs{case}
+ expressions. We can see two versions of a contrived example, the first
+ using a \hs{case} construct and the other using a \hs{if-then-else}
+ constructs, in the code below. The example sums two values when they are
+ equal or non-equal (depending on the predicate given) and returns 0
+ otherwise.
+
+ \begin{code}
+ sumif pred a b = case pred of
+ Eq -> case a == b of
+ True -> a + b
+ False -> 0
+ Neq -> case a != b of
+ True -> a + b
+ False -> 0
+ \end{code}
+
+ \begin{code}
+ sumif pred a b =
+ if pred == Eq then
+ if a == b then a + b else 0
+ else
+ if a != b then a + b else 0
+ \end{code}
+
+ Both versions of the example correspond to the same netlist, which is
+ depicted in \Cref{img:choice}.
+
+ \begin{figure}
+ \centerline{\includegraphics{choice-case}}
+ \caption{Choice - sumif}
+ \label{img:choice}
+ \end{figure}
+
+ A slightly more complex (but very powerful) form of choice is pattern
+ matching. A function can be defined in multiple clauses, where each clause
+ specifies a pattern. When the arguments match the pattern, the
+ corresponding clause will be used. Expressions can also contain guards,
+ where the expression is only executed if the guard evaluates to true. A
+ pattern match (with optional guards) can be to a conditional assignments
+ in \VHDL, where the conditions are an equality test of the argument and
+ one of the patterns (combined with the guard if was present). A third
+ version of the earlier example, using both pattern matching and guards,
+ can be seen below:
+
+ \begin{code}
+ sumif Eq a b | a == b = a + b
+ sumif Neq a b | a != b = a + b
+ sumif _ _ _ = 0
+ \end{code}
+
+ The version using pattern matching and guards has the same netlist
+ representation (\Cref{img:choice}) as the earlier two versions of the
+ example.
+
+ % \begin{figure}
+ % \centerline{\includegraphics{choice-ifthenelse}}
+ % \caption{Choice - \emph{if-then-else}}
+ % \label{img:choice}
+ % \end{figure}
\subsection{Types}
- Translation of two most basic functional concepts has been
- discussed: function application and choice. Before looking further
- into less obvious concepts like higher-order expressions and
- polymorphism, the possible types that can be used in hardware
- descriptions will be discussed.
-
- Some way is needed to translate every value used to its hardware
- equivalents. In particular, this means a hardware equivalent for
- every \emph{type} used in a hardware description is needed.
-
- The following types are \emph{built-in}, meaning that their hardware
- translation is fixed into the \CLaSH compiler. A designer can also
- define his own types, which will be translated into hardware types
- using translation rules that are discussed later on.
-
- \subsection{Built-in types}
+ Haskell is a strongly-typed language, meaning that the type of a variable
+ or function is determined at compile-time. Not all of Haskell's typing
+ constructs have a clear translation to hardware, as such this section will
+ only deal with the types that do have a clear correspondence to hardware.
+ The translatable types are divided into two categories: \emph{built-in}
+ types and \emph{user-defined} types. Built-in types are those types for
+ which a direct translation is defined within the \CLaSH\ compiler; the
+ term user-defined types should not require any further elaboration.
+
+ % Translation of two most basic functional concepts has been
+ % discussed: function application and choice. Before looking further
+ % into less obvious concepts like higher-order expressions and
+ % polymorphism, the possible types that can be used in hardware
+ % descriptions will be discussed.
+ %
+ % Some way is needed to translate every value used to its hardware
+ % equivalents. In particular, this means a hardware equivalent for
+ % every \emph{type} used in a hardware description is needed.
+ %
+ % The following types are \emph{built-in}, meaning that their hardware
+ % translation is fixed into the \CLaSH\ compiler. A designer can also
+ % define his own types, which will be translated into hardware types
+ % using translation rules that are discussed later on.
+
+ \subsubsection{Built-in types}
\begin{xlist}
- \item[\hs{Bit}]
+ \item[\bf{Bit}]
This is the most basic type available. It can have two values:
- \hs{Low} and \hs{High}. It is mapped directly onto the
- \texttt{std\_logic} \VHDL\ type.
- \item[\hs{Bool}]
+ \hs{Low} and \hs{High}.
+ % It is mapped directly onto the \texttt{std\_logic} \VHDL\ type.
+ \item[\bf{Bool}]
This is a basic logic type. It can have two values: \hs{True}
- and \hs{False}. It is translated to \texttt{std\_logic} exactly
- like the \hs{Bit} type (where a value of \hs{True} corresponds
- to a value of \hs{High}). Supporting the Bool type is
- particularly useful to support \hs{if ... then ... else ...}
- expressions, which always have a \hs{Bool} value for the
- condition.
- \item[\hs{SizedWord}, \hs{SizedInt}]
+ and \hs{False}.
+ % It is translated to \texttt{std\_logic} exactly like the \hs{Bit}
+ % type (where a value of \hs{True} corresponds to a value of
+ % \hs{High}).
+ Supporting the Bool type is required in order to support the
+ \hs{if-then-else} construct, which requires a \hs{Bool} value for
+ the condition.
+ \item[\bf{SizedWord}, \bf{SizedInt}]
These are types to represent integers. A \hs{SizedWord} is unsigned,
- while a \hs{SizedInt} is signed. These types are parametrized by a
- length type, so you can define an unsigned word of 32 bits wide as
- follows:
-
-\begin{code}
-type Word32 = SizedWord D32
-\end{code}
-
- Here, a type synonym \hs{Word32} is defined that is equal to the
- \hs{SizedWord} type constructor applied to the type \hs{D32}. \hs{D32}
- is the \emph{type level representation} of the decimal number 32,
- making the \hs{Word32} type a 32-bit unsigned word.
-
- These types are translated to the \VHDL\ \texttt{unsigned} and
- \texttt{signed} respectively.
- \item[\hs{Vector}]
- This is a vector type, that can contain elements of any other type and
- has a fixed length.
-
- The \hs{Vector} type constructor takes two type arguments: the length
- of the vector and the type of the elements contained in it. The state
- type of an 8 element register bank would then for example be:
-
-\begin{code}
-type RegisterState = Vector D8 Word32
-\end{code}
-
- Here, a type synonym \hs{RegisterState} is defined that is equal to
- the \hs{Vector} type constructor applied to the types \hs{D8} (The type
- level representation of the decimal number 8) and \hs{Word32} (The 32
- bit word type as defined above). In other words, the
- \hs{RegisterState} type is a vector of 8 32-bit words.
-
- A fixed size vector is translated to a \VHDL\ array type.
- \item[\hs{RangedWord}]
+ while a \hs{SizedInt} is signed. Both are parametrizable in their
+ size.
+ % , so you can define an unsigned word of 32 bits wide as follows:
+
+ % \begin{code}
+ % type Word32 = SizedWord D32
+ % \end{code}
+
+ % Here, a type synonym \hs{Word32} is defined that is equal to the
+ % \hs{SizedWord} type constructor applied to the type \hs{D32}.
+ % \hs{D32} is the \emph{type level representation} of the decimal
+ % number 32, making the \hs{Word32} type a 32-bit unsigned word. These
+ % types are translated to the \VHDL\ \texttt{unsigned} and
+ % \texttt{signed} respectively.
+ \item[\bf{Vector}]
+ This is a vector type that can contain elements of any other type and
+ has a fixed length. The \hs{Vector} type constructor takes two type
+ arguments: the length of the vector and the type of the elements
+ contained in it.
+ % The state type of an 8 element register bank would then for example
+ % be:
+
+ % \begin{code}
+ % type RegisterState = Vector D8 Word32
+ % \end{code}
+
+ % Here, a type synonym \hs{RegisterState} is defined that is equal to
+ % the \hs{Vector} type constructor applied to the types \hs{D8} (The
+ % type level representation of the decimal number 8) and \hs{Word32}
+ % (The 32 bit word type as defined above). In other words, the
+ % \hs{RegisterState} type is a vector of 8 32-bit words. A fixed size
+ % vector is translated to a \VHDL\ array type.
+ \item[\bf{RangedWord}]
This is another type to describe integers, but unlike the previous
two it has no specific bit-width, but an upper bound. This means that
its range is not limited to powers of two, but can be any number.
A \hs{RangedWord} only has an upper bound, its lower bound is
- implicitly zero.
-
- The main purpose of the \hs{RangedWord} type is to be used as an
- index to a \hs{Vector}.
-
- TODO: Perhaps remove this example?
-
- To define an index for the 8 element vector above, we would do:
-
-\begin{code}
-type RegisterIndex = RangedWord D7
-\end{code}
-
- Here, a type synonym \hs{RegisterIndex} is defined that is equal to
- the \hs{RangedWord} type constructor applied to the type \hs{D7}. In
- other words, this defines an unsigned word with values from
- 0 to 7 (inclusive). This word can be be used to index the
- 8 element vector \hs{RegisterState} above.
-
- This type is translated to the \texttt{unsigned} \VHDL type.
+ implicitly zero. The main purpose of the \hs{RangedWord} type is to be
+ used as an index to a \hs{Vector}.
+
+ % \comment{TODO: Perhaps remove this example?} To define an index for
+ % the 8 element vector above, we would do:
+
+ % \begin{code}
+ % type RegisterIndex = RangedWord D7
+ % \end{code}
+
+ % Here, a type synonym \hs{RegisterIndex} is defined that is equal to
+ % the \hs{RangedWord} type constructor applied to the type \hs{D7}. In
+ % other words, this defines an unsigned word with values from
+ % 0 to 7 (inclusive). This word can be be used to index the
+ % 8 element vector \hs{RegisterState} above. This type is translated
+ % to the \texttt{unsigned} \VHDL type.
\end{xlist}
- \subsection{User-defined types}
+ \subsubsection{User-defined types}
There are three ways to define new types in Haskell: algebraic
data-types with the \hs{data} keyword, type synonyms with the \hs{type}
- keyword and type renamings with the \hs{newtype} keyword. \GHC\
+ keyword and datatype renamings with the \hs{newtype} keyword. \GHC\
offers a few more advanced ways to introduce types (type families,
existential typing, {\small{GADT}}s, etc.) which are not standard
Haskell. These are not currently supported.
Only an algebraic datatype declaration actually introduces a
completely new type, for which we provide the \VHDL\ translation
below. Type synonyms and renamings only define new names for
- existing types (where synonyms are completely interchangeable and
- renamings need explicit conversion). Therefore, these do not need
+ existing types, where synonyms are completely interchangeable and
+ renamings need explicit conversiona. Therefore, these do not need
any particular \VHDL\ translation, a synonym or renamed type will
just use the same representation as the original type. The
distinction between a renaming and a synonym does no longer matter
- in hardware and can be disregarded in the generated \VHDL.
-
- For algebraic types, we can make the following distinction:
+ in hardware and can be disregarded in the generated \VHDL. For algebraic
+ types, we can make the following distinction:
\begin{xlist}
\item[\bf{Single constructor}]
Algebraic datatypes with a single constructor with one or more
fields, are essentially a way to pack a few values together in a
- record-like structure.
-
- An example of such a type is the following pair of integers:
+ record-like structure. An example of such a type is the following pair
+ of integers:
-\begin{code}
-data IntPair = IntPair Int Int
-\end{code}
+ \begin{code}
+ data IntPair = IntPair Int Int
+ \end{code}
Haskell's builtin tuple types are also defined as single
constructor algebraic types and are translated according to this
- rule by the \CLaSH compiler.
-
- These types are translated to \VHDL\ record types, with one field for
- every field in the constructor.
+ rule by the \CLaSH\ compiler. These types are translated to \VHDL\
+ record types, with one field for every field in the constructor.
\item[\bf{No fields}]
Algebraic datatypes with multiple constructors, but without any
fields are essentially a way to get an enumeration-like type
- containing alternatives.
-
- Note that Haskell's \hs{Bool} type is also defined as an
- enumeration type, but we have a fixed translation for that.
-
- These types are translated to \VHDL\ enumerations, with one value for
- each constructor. This allows references to these constructors to be
- translated to the corresponding enumeration value.
+ containing alternatives. Note that Haskell's \hs{Bool} type is also
+ defined as an enumeration type, but we have a fixed translation for
+ that. These types are translated to \VHDL\ enumerations, with one
+ value for each constructor. This allows references to these
+ constructors to be translated to the corresponding enumeration value.
\item[\bf{Multiple constructors with fields}]
Algebraic datatypes with multiple constructors, where at least
one of these constructors has one or more fields are not
currently supported.
\end{xlist}
+ \subsection{Polymorphic functions}
+ A powerful construct in most functional language is polymorphism.
+ This means the arguments of a function (and consequentially, values
+ within the function as well) do not need to have a fixed type.
+ Haskell supports \emph{parametric polymorphism}, meaning a
+ function's type can be parameterized with another type.
+
+ As an example of a polymorphic function, consider the following
+ \hs{append} function's type:
+
+ \comment{TODO: Use vectors instead of lists?}
+
+ \begin{code}
+ append :: [a] -> a -> [a]
+ \end{code}
+
+ This type is parameterized by \hs{a}, which can contain any type at
+ all. This means that append can append an element to a list,
+ regardless of the type of the elements in the list (but the element
+ added must match the elements in the list, since there is only one
+ \hs{a}).
+
+ This kind of polymorphism is extremely useful in hardware designs to
+ make operations work on a vector without knowing exactly what elements
+ are inside, routing signals without knowing exactly what kinds of
+ signals these are, or working with a vector without knowing exactly
+ how long it is. Polymorphism also plays an important role in most
+ higher order functions, as we will see in the next section.
+
+ The previous example showed unconstrained polymorphism \comment{(TODO: How
+ is this really called?)}: \hs{a} can have \emph{any} type.
+ Furthermore,Haskell supports limiting the types of a type parameter to
+ specific class of types. An example of such a type class is the
+ \hs{Num} class, which contains all of Haskell's numerical types.
+
+ Now, take the addition operator, which has the following type:
+
+ \begin{code}
+ (+) :: Num a => a -> a -> a
+ \end{code}
+
+ This type is again parameterized by \hs{a}, but it can only contain
+ types that are \emph{instances} of the \emph{type class} \hs{Num}.
+ Our numerical built-in types are also instances of the \hs{Num}
+ class, so we can use the addition operator on \hs{SizedWords} as
+ well as on {SizedInts}.
+
+ In \CLaSH, unconstrained polymorphism is completely supported. Any
+ function defined can have any number of unconstrained type
+ parameters. The \CLaSH\ compiler will infer the type of every such
+ argument depending on how the function is applied. There is one
+ exception to this: The top level function that is translated, can
+ not have any polymorphic arguments (since it is never applied, so
+ there is no way to find out the actual types for the type
+ parameters).
+
+ \CLaSH\ does not support user-defined type classes, but does use some
+ of the builtin ones for its builtin functions (like \hs{Num} and
+ \hs{Eq}).
+
+ \subsection{Higher order}
+ Another powerful abstraction mechanism in functional languages, is
+ the concept of \emph{higher order functions}, or \emph{functions as
+ a first class value}. This allows a function to be treated as a
+ value and be passed around, even as the argument of another
+ function. Let's clarify that with an example:
+
+ \begin{code}
+ notList xs = map not xs
+ \end{code}
+
+ This defines a function \hs{notList}, with a single list of booleans
+ \hs{xs} as an argument, which simply negates all of the booleans in
+ the list. To do this, it uses the function \hs{map}, which takes
+ \emph{another function} as its first argument and applies that other
+ function to each element in the list, returning again a list of the
+ results.
+
+ As you can see, the \hs{map} function is a higher order function,
+ since it takes another function as an argument. Also note that
+ \hs{map} is again a polymorphic function: It does not pose any
+ constraints on the type of elements in the list passed, other than
+ that it must be the same as the type of the argument the passed
+ function accepts. The type of elements in the resulting list is of
+ course equal to the return type of the function passed (which need
+ not be the same as the type of elements in the input list). Both of
+ these can be readily seen from the type of \hs{map}:
+
+ \begin{code}
+ map :: (a -> b) -> [a] -> [b]
+ \end{code}
+
+ As an example from a common hardware design, let's look at the
+ equation of a FIR filter.
+
+ \begin{equation}
+ y_t = \sum\nolimits_{i = 0}^{n - 1} {x_{t - i} \cdot h_i }
+ \end{equation}
+
+ A FIR filter multiplies fixed constants ($h$) with the current and
+ a few previous input samples ($x$). Each of these multiplications
+ are summed, to produce the result at time $t$.
+
+ This is easily and directly implemented using higher order
+ functions. Consider that the vector \hs{hs} contains the FIR
+ coefficients and the vector \hs{xs} contains the current input sample
+ in front and older samples behind. How \hs{xs} gets its value will be
+ show in the next section about state.
+
+ \begin{code}
+ fir ... = foldl1 (+) (zipwith (*) xs hs)
+ \end{code}
+
+ Here, the \hs{zipwith} function is very similar to the \hs{map}
+ function: It takes a function two lists and then applies the
+ function to each of the elements of the two lists pairwise
+ (\emph{e.g.}, \hs{zipwith (+) [1, 2] [3, 4]} becomes
+ \hs{[1 + 3, 2 + 4]}.
+
+ The \hs{foldl1} function takes a function and a single list and applies the
+ function to the first two elements of the list. It then applies to
+ function to the result of the first application and the next element
+ from the list. This continues until the end of the list is reached.
+ The result of the \hs{foldl1} function is the result of the last
+ application.
+
+ As you can see, the \hs{zipwith (*)} function is just pairwise
+ multiplication and the \hs{foldl1 (+)} function is just summation.
+
+ To make the correspondence between the code and the equation even
+ more obvious, we turn the list of input samples in the equation
+ around. So, instead of having the the input sample received at time
+ $t$ in $x_t$, $x_0$ now always stores the current sample, and $x_i$
+ stores the $ith$ previous sample. This changes the equation to the
+ following (Note that this is completely equivalent to the original
+ equation, just with a different definition of $x$ that better suits
+ the \hs{x} from the code):
+
+ \begin{equation}
+ y_t = \sum\nolimits_{i = 0}^{n - 1} {x_i \cdot h_i }
+ \end{equation}
+
+ So far, only functions have been used as higher order values. In
+ Haskell, there are two more ways to obtain a function-typed value:
+ partial application and lambda abstraction. Partial application
+ means that a function that takes multiple arguments can be applied
+ to a single argument, and the result will again be a function (but
+ that takes one argument less). As an example, consider the following
+ expression, that adds one to every element of a vector:
+
+ \begin{code}
+ map ((+) 1) xs
+ \end{code}
+
+ Here, the expression \hs{(+) 1} is the partial application of the
+ plus operator to the value \hs{1}, which is again a function that
+ adds one to its argument.
+
+ A labmda expression allows one to introduce an anonymous function
+ in any expression. Consider the following expression, which again
+ adds one to every element of a list:
+
+ \begin{code}
+ map (\x -> x + 1) xs
+ \end{code}
+
+ Finally, higher order arguments are not limited to just builtin
+ functions, but any function defined in \CLaSH\ can have function
+ arguments. This allows the hardware designer to use a powerful
+ abstraction mechanism in his designs and have an optimal amount of
+ code reuse.
+
+ \comment{TODO: Describe ALU example (no code)}
+
\subsection{State}
A very important concept in hardware it the concept of state. In a
stateful design, the outputs depend on the history of the inputs, or the
A simple example is the description of an accumulator circuit:
\begin{code}
- acc :: Word -> State Word -> (State Word, Word)
- acc inp (State s) = (State s', outp)
+ macS a b (State c) = (State c', outp)
where
- outp = s + inp
- s' = outp
+ outp = mac a b c
+ c' = outp
\end{code}
+ \begin{figure}
+ \centerline{\includegraphics{mac-state}}
+ \caption{Stateful Multiply-Accumulate}
+ \label{img:mac-state}
+ \end{figure}
This approach makes the state of a function very explicit: which variables
are part of the state is completely determined by the type signature. This
approach to state is well suited to be used in combination with the
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 has
+exemplified by the new \VHDL-2008 standard~\cite{VHDL2008}. \VHDL-2008 has
support to specify types as generics, thus allowing a developer to describe
polymorphic components. Note that those types still require an explicit
generic map, whereas type-inference and type-specialization are implicit in
projects / matthijs / master-project / dsd-paper.git / blobdiff