From: Christiaan Baaij Date: Wed, 27 Jan 2010 13:29:07 +0000 (+0100) Subject: Merge branch 'master' of http://git.stderr.nl/matthijs/projects/cλash-paper X-Git-Url: https://git.stderr.nl/gitweb?p=matthijs%2Fmaster-project%2Fdsd-paper.git;a=commitdiff_plain;h=4ba989a081577d97bf2e48458841150dd6558fbc;hp=a3f637b15eaa7eef95507963a0bc96bb18d844ae Merge branch 'master' of git.stderr.nl/matthijs/projects/cλash-paper * 'master' of http://git.stderr.nl/matthijs/projects/cλash-paper: Don't pass --haskell to lhs2TeX, it is the default. --- diff --git "a/c\316\273ash.lhs" "b/c\316\273ash.lhs" index ca4f1cd..16608ab 100644 --- "a/c\316\273ash.lhs" +++ "b/c\316\273ash.lhs" @@ -343,9 +343,10 @@ % Macro for certain acronyms in small caps. Doesn't work with the % default font, though (it contains no smallcaps it seems). -\def\VHDL{{\small{VHDL}}} -\def\GHC{{\small{GHC}}} -\def\CLaSH{\textsc{C$\lambda$aSH}} +\def\acro#1{{\small{#1}}} +\def\VHDL{\acro{VHDL}} +\def\GHC{\acro{GHC}} +\def\CLaSH{{\small{C}}$\lambda$a{\small{SH}}} % Macro for pretty printing haskell snippets. Just monospaced for now, perhaps % we'll get something more complex later on. @@ -366,13 +367,15 @@ } {\end{list}} +\usepackage{paralist} + %include polycode.fmt \begin{document} % % paper title % can use linebreaks \\ within to get better formatting as desired -\title{\CLaSH: Structural Descriptions \\ of Synchronous Hardware using Haskell} +\title{C$\lambda$aSH: Structural Descriptions \\ of Synchronous Hardware using Haskell} % author names and affiliations @@ -381,7 +384,7 @@ \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}} % \and % \IEEEauthorblockN{Homer Simpson} % \IEEEauthorblockA{Twentieth Century Fox\\ @@ -686,7 +689,7 @@ type RegisterIndex = RangedWord D7 For algebraic types, we can make the following distinction: \begin{xlist} - \item[Product types] + \item[\textbf{Product types}] A product type is an algebraic datatype with a single constructor with two or more fields, denoted in practice like (a,b), (a,b,c), etc. This is essentially a way to pack a few values together in a record-like @@ -702,7 +705,7 @@ type RegisterIndex = RangedWord D7 constructor algebraic data-types, including those with just one field (which are technically not a product, but generate a VHDL record for implementation simplicity). - \item[Enumerated types] + \item[\textbf{Enumerated types}] An enumerated type is an algebraic datatype with multiple constructors, but none of them have fields. This is essentially a way to get an enumeration-like type containing alternatives. @@ -713,7 +716,7 @@ type RegisterIndex = RangedWord D7 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[Sum types] + \item[\textbf{Sum types}] A sum type is an algebraic datatype with multiple constructors, where the constructors have one or more fields. Technically, a type with more than one field per constructor is a sum of products type, but @@ -761,22 +764,61 @@ type Sum = (SumC, Bit, Word, Word) so we have a 100\% size increase by not sharing these. \end{xlist} - + \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 + state. State is usually stored in registers, which retain their value + during a clock cycle. As we want to describe more than simple + combinatorial designs, \CLaSH\ needs an abstraction mechanism for state. + + An important property in Haskell, and in most other functional languages, + is \emph{purity}. A function is said to be \emph{pure} if it satisfies two + conditions: + \begin{inparaenum} + \item given the same arguments twice, it should return the same value in + both cases, and + \item when the function is called, it should not have observable + side-effects. + \end{inparaenum} + This purity property is important for functional languages, since it + enables all kinds of mathematical reasoning that could not be guaranteed + correct for impure functions. Pure functions are as such a perfect match + for a combinatorial circuit, where the output solely depends on the + inputs. When a circuit has state however, it can no longer be simply + described by a pure function. Simply removing the purity property is not a + valid option, as the language would then lose many of it mathematical + properties. In an effort to include the concept of state in pure + functions, the current value of the state is made an argument of the + function; the updated state becomes part of the result. + + 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) + where + outp = s + inp + s' = outp + \end{code} + 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 + existing code and language features, such as all the choice elements, as + state values are just normal values. \section{\CLaSH\ prototype} foo\par bar \section{Related work} Many functional hardware description languages have been developed over the -years. Early work includes such languages as \textsc{$\mu$fp}~\cite{muFP}, an -extension of Backus' \textsc{fp} language to synchronous streams, designed +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. \textsc{hml}~\cite{HML2} is a +circuits, and has a particular focus on layout. \acro{HML}~\cite{HML2} is a hardware modeling language based on the strict functional language -\textsc{ml}, and has support for polymorphic types and higher-order functions. +\acro{ML}, and has support for polymorphic types and higher-order functions. Published work suggests that there is no direct simulation support for -\textsc{hml}, and that the translation to \VHDL\ is only partial. +\acro{HML}, and that the translation to \VHDL\ is only partial. Like this work, many functional hardware description languages have some sort of foundation in the functional programming language Haskell. @@ -815,7 +857,7 @@ Wired~\cite{Wired},, T-Ruby~\cite{T-Ruby}, Hydra~\cite{Hydra}. A functional language designed specifically for hardware design is $re{\mathit{FL}}^{ect}$~\cite{reFLect}, which draws experience from earlier -language called \textsc{fl}~\cite{FL} to la +language called \acro{FL}~\cite{FL} to la % An example of a floating figure using the graphicx package. % Note that \label must occur AFTER (or within) \caption.