X-Git-Url: https://git.stderr.nl/gitweb?p=matthijs%2Fmaster-project%2Fdsd-paper.git;a=blobdiff_plain;f=c%CE%BBash.lhs;h=9fb964773a948b737ee7055d4e86500b3202a3c5;hp=3ac0a7ceb6a1c80b0b4cc3cd76655a0c5d6dadc4;hb=8cf5b5c041beee1dd39678bc70b7ec934ecc4d98;hpb=956340a350f7a8ae4aea4bdc8a7ce291a79f9d1d diff --git "a/c\316\273ash.lhs" "b/c\316\273ash.lhs" index 3ac0a7c..9fb9647 100644 --- "a/c\316\273ash.lhs" +++ "b/c\316\273ash.lhs" @@ -548,9 +548,9 @@ 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 FIR filter and the -simple CPU shown in \Cref{sec:usecases}, the \CLaSH\ compiler has also been -shown to work for non-trivial descriptions. \CLaSH\ has been able to +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. @@ -702,9 +702,9 @@ circuit~\cite{reductioncircuit} for floating point numbers. compiler. The \CLaSH\ compiler has generic translation rules to translated the user-defined types described below. - The \CLaSH compiler is able to infer unspecified types, + The \CLaSH\ compiler is able to infer unspecified types, meaning that a developer does not have to annotate every function with a - type signature (though it is good practice to do so anyway). + type signature (even if it is good practice to do so). % Translation of two most basic functional concepts has been % discussed: function application and choice. Before looking further @@ -762,7 +762,7 @@ circuit~\cite{reductioncircuit} for floating point numbers. the rest of paper is: \hs{[a|n]}. Where the \hs{a} is the element type, and \hs{n} is the length of the vector. Note that this is a notation used in this paper only, vectors are slightly more - elaborate in real \CLaSH programs. + verbose in real \CLaSH\ descriptions. % The state type of an 8 element register bank would then for example % be: @@ -1091,7 +1091,7 @@ Haskell language. A description in \emph{Core} can still contain properties which have no direct translation to hardware, such as polymorphic types and function-valued arguments. Such a description needs to be transformed to a \emph{normal form}, which only contains properties that have a direct -translation. The second stage of the compiler, the \emph{normalization} phase +translation. The second stage of the compiler, the \emph{normalization} phase, exhaustively applies a set of \emph{meaning-preserving} transformations on the \emph{Core} description until this description is in a \emph{normal form}. This set of transformations includes transformations typically found in @@ -1107,9 +1107,8 @@ end-product of the \CLaSH\ compiler a \VHDL\ \emph{netlist} as the resulting \VHDL\ resembles an actual netlist description and not idiomatic \VHDL. \section{Use cases} - -\subsection{FIR Filter} \label{sec:usecases} +\subsection{FIR Filter} As an example of a common hardware design where the use of higher-order functions leads to a very natural description is a \acro{FIR} filter, which is basically the dot-product of two vectors: @@ -1169,10 +1168,10 @@ fir (State (xs,hs)) x = (State (x >> xs,hs), xs *+* hs) \end{code} Where the vector \hs{hs} contains the \acro{FIR} coefficients and the vector -\hs{xs} contains the latest input sample in front and older samples behind. -The code for the shift (\hs{>>}) operator that adds the new input sample +\hs{xs} contains the previous input sample in front and older samples behind. +The code for the shift (\hs{>>}) operator, that adds the new input sample (\hs{x}) to the list of previous input samples (\hs{xs}) and removes the -oldest sample is shown below: +oldest sample, is shown below: \begin{code} x >> xs = x +> init xs @@ -1193,39 +1192,32 @@ the vectors of the \acro{FIR} code to a length of 4, is depicted in \subsection{Higher order CPU} \begin{code} -fu :: (a -> a -> a) - -> [a | n] - -> (Index (n - 1), Index (n - 1)) - -> a - -> (a, a) -fu op inputs (addr1, addr2) (State out) = - (State out', out) +fu op inputs (addr1, addr2) = regIn where - in1 = inputs!addr1 - in2 = inputs!addr2 - out' = op in1 in2 + in1 = inputs!addr1 + in2 = inputs!addr2 + regIn = op in1 in2 \end{code} \begin{code} -type CpuState = State [Word | 4] - -cpu :: Word - -> [(Index 6, Index 6) | 4] - -> CpuState - -> (CpuState, Word) +cpu :: Word -> [(Index 6, Index 6) | 4] + -> State [Word | 4] -> (State [Word | 4], Word) cpu input addrs (State fuss) = (State fuss', out) where - fures = [ fu const inputs (addrs!0) (fuss!0) + fuss' = [ fu const inputs (addrs!0) (fuss!0) , fu (+) inputs (addrs!1) (fuss!1) , fu (-) inputs (addrs!2) (fuss!2) , fu (*) inputs (addrs!3) (fuss!3) ] - (fuss', outputs) = unzip fures - inputs = 0 +> (1 +> (input +> outputs)) - out = head outputs + inputs = 0 +> (1 +> (input +> fuss)) + out = head fuss \end{code} \section{Related work} +This section describes the features of existing (functional) hardware +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 @@ -1237,7 +1229,7 @@ circuits, and has a particular focus on layout. functional language \acro{ML}, and has support for polymorphic types and higher-order functions. Published work suggests that there is no direct simulation support for \acro{HML}, but that a description in \acro{HML} has to -be translated to \VHDL\ and that the translated description can than be +be translated to \VHDL\ and that the translated description can then be simulated in a \VHDL\ simulator. Also not all of the mentioned language features of \acro{HML} could be translated to hardware. The \CLaSH\ compiler on the other hand can correctly translate all of the language constructs @@ -1279,9 +1271,12 @@ mentioned in this section. 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, allowing a developer to describe +exemplified by the new \VHDL-2008 standard~\cite{VHDL2008}. \VHDL-2008 support +for generics has been extended to types, allowing a developer to describe polymorphic components. Note that those types still require an explicit -generic map, whereas types can be automatically inferred in \CLaSH. +generic map, whereas types can be automatically inferred in \CLaSH. There are +also no (generally available) \VHDL\ synthesis tools that currently support +the \VHDL-2008 standard, and thus the synthesis of polymorphic types. % Wired~\cite{Wired},, T-Ruby~\cite{T-Ruby}, Hydra~\cite{Hydra}. % @@ -1383,14 +1378,9 @@ The conclusion goes here. % use section* for acknowledgement -\section*{Acknowledgment} - - -The authors would like to thank... - - - - +% \section*{Acknowledgment} +% +% The authors would like to thank... % trigger a \newpage just before the given reference % number - used to balance the columns on the last page