X-Git-Url: https://git.stderr.nl/gitweb?p=matthijs%2Fmaster-project%2Fdsd-paper.git;a=blobdiff_plain;f=c%CE%BBash.lhs;h=a0ccb8e02769951d18c1ca59f3069a8938c65dcf;hp=f7a763ee1923d1cbe5fd0d2775bc1e8d1a76dc50;hb=432416d4f3cb67cdb0ae332d01a78dae6328d0f5;hpb=997b8f1eadcc74a0a58c17f038f61f6d5a3d9fc1 diff --git "a/c\316\273ash.lhs" "b/c\316\273ash.lhs" index f7a763e..a0ccb8e 100644 --- "a/c\316\273ash.lhs" +++ "b/c\316\273ash.lhs" @@ -63,6 +63,7 @@ % 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. % @@ -93,9 +94,6 @@ - - - % *** CITATION PACKAGES *** % \usepackage{cite} @@ -122,7 +120,7 @@ % *** 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 @@ -371,6 +369,12 @@ \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 @@ -512,47 +516,58 @@ 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 the circuit part of the -input of the function and the updated state part of the output of a function. +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 optimizing \VHDL\ synthesis tools. +by an optimizing \VHDL\ synthesis tools. \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} - -\comment{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{Choices} Although describing components and connections allows describing a @@ -603,7 +618,17 @@ mac a b c = add (mul a b) c sumif _ _ _ = 0 \end{code} - \comment{TODO: Pretty picture} + \begin{figure} + \centerline{\includegraphics{choice-ifthenelse}} + \caption{Choice - \emph{if-then-else}} + \label{img:choice} + \end{figure} + + \begin{figure} + \centerline{\includegraphics{choice-case}} + \caption{Choice - \emph{case-statement / pattern matching}} + \label{img:choice} + \end{figure} \subsection{Types} Translation of two most basic functional concepts has been