From 07f12a9ebf96c396e47f4570bae88d397dcc1d9d Mon Sep 17 00:00:00 2001 From: Christiaan Baaij Date: Tue, 2 Mar 2010 10:22:23 +0100 Subject: [PATCH 01/16] Update gitignore file to ingore .o .hi files and the vhdl directory --- .gitignore | 3 +++ 1 file changed, 3 insertions(+) diff --git a/.gitignore b/.gitignore index e0ca27e..b472a56 100644 --- a/.gitignore +++ b/.gitignore @@ -7,5 +7,8 @@ *.bak *.ptb *.synctex.gz +*.o +*.hi .latexmkrc cλash.tex +vhdl -- 2.30.2 From b4f8f6d5cfa441b0e89d9ffd67a7cb1d30a9ca02 Mon Sep 17 00:00:00 2001 From: Christiaan Baaij Date: Tue, 2 Mar 2010 10:32:04 +0100 Subject: [PATCH 02/16] Remove unneeded language pragma's from higherordercpu.hs --- HigherOrderCPU.hs | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/HigherOrderCPU.hs b/HigherOrderCPU.hs index cc242bf..fd7471b 100644 --- a/HigherOrderCPU.hs +++ b/HigherOrderCPU.hs @@ -1,5 +1,4 @@ -{-# LANGUAGE TypeOperators, TemplateHaskell, TypeFamilies, - ScopedTypeVariables, RecordWildCards, FlexibleContexts #-} +{-# LANGUAGE TypeOperators, TemplateHaskell, TypeFamilies, ScopedTypeVariables #-} module HigherOrderCPU where -- 2.30.2 From abecfadf45aab74c21700d5ed8889e3c0b168f28 Mon Sep 17 00:00:00 2001 From: Christiaan Baaij Date: Tue, 2 Mar 2010 13:03:48 +0100 Subject: [PATCH 03/16] Update piece about state to show relation between the run function and the statefull descriptions --- clash.bib | 18 ++++++++++++++++++ "c\316\273ash.lhs" | 12 +++++++----- 2 files changed, 25 insertions(+), 5 deletions(-) diff --git a/clash.bib b/clash.bib index f3aeaa5..5bec913 100644 --- a/clash.bib +++ b/clash.bib @@ -341,6 +341,24 @@ timestamp = {2010.02.24} } +@INPROCEEDINGS{Sulzmann2007, + author = {Sulzmann, Martin and Chakravarty, Manuel M. T. and Jones, Simon Peyton + and Donnelly, Kevin}, + title = {{System F with Type Equality Coercions}}, + booktitle = {{TLDI '07: Proceedings of the 2007 ACM SIGPLAN international workshop + on Types in languages design and implementation, Nice, France}}, + year = {2007}, + pages = {53--66}, + address = {{New York, NY, USA}}, + month = {January}, + publisher = {{ACM}}, + doi = {http://doi.acm.org/10.1145/1190315.1190324}, + isbn = {1-59593-393-X}, + location = {Nice, Nice, France}, + owner = {darchon}, + timestamp = {2009.10.23} +} + @ELECTRONIC{ghc, author = {{The GHC Team}}, title = {{The Glasgow Haskell Compiler}}, diff --git "a/c\316\273ash.lhs" "b/c\316\273ash.lhs" index 4c7e680..85709be 100644 --- "a/c\316\273ash.lhs" +++ "b/c\316\273ash.lhs" @@ -950,7 +950,7 @@ circuit~\cite{reductioncircuit} for floating point numbers. expression, that adds one to every element of a vector: \begin{code} - map ((+) 1) xs + map (+ 1) xs \end{code} Here, the expression \hs{(+) 1} is the partial application of the @@ -1041,8 +1041,10 @@ circuit~\cite{reductioncircuit} for floating point numbers. first input value, \hs{i}. The result is the first output value, \hs{o}, and the updated state \hs{s'}. The next iteration of the \hs{run} function is then called with the updated state, \hs{s'}, and the rest of the - inputs, \hs{inps}. Each value in the input list corresponds to exactly one - cycle of the (implicit) clock. + inputs, \hs{inps}. It is assumed that there is one input per clock cycle. + Also note how the order of the input, output, and state in the \hs{run} + function corresponds with the order of the input, output and state of the + \hs{macS} function described earlier. As both the \hs{run} function, the hardware description, and the test inputs are plain Haskell, the complete simulation can be compiled to an @@ -1052,7 +1054,7 @@ circuit~\cite{reductioncircuit} for floating point numbers. simulation, where the executable binary has an additional simulation speed bonus in case there is a large set of test inputs. -\section{\CLaSH\ prototype} +\section{\CLaSH\ compiler} The \CLaSH\ language as presented above can be translated to \VHDL\ using the prototype \CLaSH\ compiler. This compiler allows experimentation with @@ -1069,7 +1071,7 @@ The prototype heavily uses \GHC, the Glasgow Haskell Compiler. \Cref{img:compilerpipeline} shows the \CLaSH\ compiler pipeline. As you can see, the front-end is completely reused from \GHC, which allows the \CLaSH\ prototype to support most of the Haskell Language. The \GHC\ front-end -produces the program in the \emph{Core} format, which is a very small, +produces the program in the \emph{Core}~\cite{Sulzmann2007} format, which is a very small, functional, typed language which is relatively easy to process. The second step in the compilation process is \emph{normalization}. This -- 2.30.2 From 8bc0046a8c22a39991e2825592f7dec59764969f Mon Sep 17 00:00:00 2001 From: Christiaan Baaij Date: Tue, 2 Mar 2010 13:14:37 +0100 Subject: [PATCH 04/16] Correct 4tapfilter figure: --- 4tapfir.svg | 152 +++++++++++++++++++++++++--------------------------- 1 file changed, 74 insertions(+), 78 deletions(-) diff --git a/4tapfir.svg b/4tapfir.svg index 48ef449..3adf8d6 100644 --- a/4tapfir.svg +++ b/4tapfir.svg @@ -10,7 +10,7 @@ xmlns="http://www.w3.org/2000/svg" xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd" xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape" - width="180.83502" + width="193.39" height="152.82002" id="svg2" version="1.1" @@ -24,8 +24,8 @@ inkscape:pageopacity="0.0" inkscape:pageshadow="2" inkscape:zoom="2.8284271" - inkscape:cx="168.11824" - inkscape:cy="82.75736" + inkscape:cx="71.67237" + inkscape:cy="88.470287" inkscape:document-units="px" inkscape:current-layer="layer1" showgrid="true" @@ -112,7 +112,7 @@ inkscape:label="Layer 1" inkscape:groupmode="layer" id="layer1" - transform="translate(-401.56,-664.8395)"> + transform="translate(-388.72,-664.8395)"> - @@ -207,22 +202,22 @@ - - - - - - - + id="g2940" + transform="translate(-24.16501,3.21)"> + + + + + id="path4926" /> - - + + transform="matrix(0,-1,1,0,-303.17452,1262.2895)"> @@ -540,7 +521,7 @@ + transform="matrix(0,-1,1,0,-251.67452,1203.8895)"> @@ -584,7 +565,7 @@ + transform="matrix(0,-1,1,0,-211.67452,1163.8895)"> @@ -628,7 +609,7 @@ + transform="matrix(0,-1,1,0,-171.67452,1123.8895)"> @@ -672,7 +653,7 @@ + transform="matrix(0,-1,1,0,-263.17452,1222.2895)"> @@ -716,7 +697,7 @@ + transform="matrix(0,-1,1,0,-223.17452,1182.2895)"> @@ -760,7 +741,7 @@ + transform="matrix(0,-1,1,0,-183.17452,1142.2895)"> @@ -804,7 +785,7 @@ - + + + + -- 2.30.2 From 64a90253f6e0a97204415d78612bc828e83a313f Mon Sep 17 00:00:00 2001 From: Matthijs Kooijman Date: Tue, 2 Mar 2010 14:34:51 +0100 Subject: [PATCH 05/16] Minor spelling and style fixes. --- "c\316\273ash.lhs" | 148 ++++++++++++++++++++++++--------------------- 1 file changed, 79 insertions(+), 69 deletions(-) diff --git "a/c\316\273ash.lhs" "b/c\316\273ash.lhs" index 4c7e680..9c0fb6b 100644 --- "a/c\316\273ash.lhs" +++ "b/c\316\273ash.lhs" @@ -494,36 +494,38 @@ 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 combinatorial circuits can be directly -modeled as 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}. 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 then be processed further 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. +languages such as \VHDL. Functional languages are especially suited to +describe hardware because combinational circuits can be directly modeled +as 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 in creating all the +required tooling, such as parsers and type-checkers, many functional +hardware description languages \cite{Hydra,Hawk1,Lava,ForSyDe1,Wired} +are embedded as a domain specific language inside 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 domain specific language. The primitive functions used +to describe a circuit do not actually process any signals, but instead +compose a large domain-specific datatype (which is usually hidden from +the designer). This datatype is then further processed by an embedded +circuit compiler. This circuit 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 circuit 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 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 +(if-expressions, case-expressions, pattern matching, etc.), which are not available in the functional hardware description languages that are embedded in Haskell as a domain specific language. As far as the authors know, such extensive support for choice-elements is new in the domain of functional hardware description languages. As the hardware descriptions are plain Haskell -functions, these descriptions can be compiled for simulation using an -optimizing Haskell compiler such as the Glasgow Haskell Compiler (\GHC)~\cite{ghc}. +functions, these descriptions can be compiled to an executable binary +for simulation using an optimizing Haskell compiler such as the Glasgow +Haskell Compiler (\GHC)~\cite{ghc}. Where descriptions in a conventional hardware description language have an explicit clock for the purpose state and synchronicity, the clock is implied @@ -566,7 +568,7 @@ circuit~\cite{reductioncircuit} for floating point numbers. \item function applications are translated to component instantiations. \end{inparaenum} The output port can have a structured type (such as a tuple), so having - just a single output port does not pose any limitation. The arguments of a + just a single output port does not pose any limitation. The actual arguments of a function application are assigned to signals, which are then mapped to the corresponding input ports of the component. The output port of the function is also mapped to a signal, which is used as the result of the @@ -608,26 +610,27 @@ circuit~\cite{reductioncircuit} for floating point numbers. \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, + In Haskell, choice can be achieved by a large set of syntacic elements, + consisting of: \hs{case} expressions, \hs{if-then-else} expressions, pattern matching, and guards. The most general of these are the \hs{case} - constructs (\hs{if} expressions can be very directly translated to - \hs{case} expressions). A \hs{case} construct is translated to a - multiplexer, where the control value is linked to the selection port and - the output of each case is linked to the corresponding input port on the - multiplexer. + expressions (\hs{if} expressions can be very directly translated to + \hs{case} expressions). A \hs{case} expression is translated to a + multiplexer, where the control value is fed into a number of + comparators and their output is used to compose the selection port + of the multiplexer. The result of each alternative is linked to the + corresponding input port on the multiplexer. % 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 below, the first - using a \hs{case} construct and the other using an \hs{if-then-else} - construct, in the code below. The examples sums two values when they are + using a \hs{case} expression and the other using an \hs{if-then-else} + expression. Both examples sums two values when they are equal or non-equal (depending on the given predicate, the \hs{pred} variable) and returns 0 otherwise. The \hs{pred} variable has the following, user-defined, enumeration datatype: \begin{code} - data Pred = Equiv | NotEquiv + data Pred = Equal | NotEqual \end{code} The naive netlist corresponding to both versions of the example is @@ -635,17 +638,17 @@ circuit~\cite{reductioncircuit} for floating point numbers. \begin{code} sumif pred a b = case pred of - Equiv -> case a == b of + Equal -> case a == b of True -> a + b False -> 0 - NotEquiv -> case a != b of + NotEqual -> case a != b of True -> a + b False -> 0 \end{code} \begin{code} sumif pred a b = - if pred == Equiv then + if pred == Equal then if a == b then a + b else 0 else if a != b then a + b else 0 @@ -663,8 +666,8 @@ circuit~\cite{reductioncircuit} for floating point numbers. corresponding clause will be used. Expressions can also contain guards, where the expression is only executed if the guard evaluates to true, and continues with the next clause if the guard evaluates to false. Like - \hs{if-then-else} constructs, pattern matching and guards have a - (straightforward) translation to \hs{case} constructs and can as such be + \hs{if-then-else} expressions, pattern matching and guards have a + (straightforward) translation to \hs{case} expressions and can as such be mapped to multiplexers. A third version of the earlier example, using both pattern matching and guards, can be seen below. The guard is the expression that follows the vertical bar (\hs{|}) and precedes the @@ -676,9 +679,9 @@ circuit~\cite{reductioncircuit} for floating point numbers. versions of the example. \begin{code} - sumif Equiv a b | a == b = a + b + sumif Equal a b | a == b = a + b | otherwise = 0 - sumif NotEquiv a b | a != b = a + b + sumif NotEqual a b | a != b = a + b | otherwise = 0 \end{code} @@ -692,14 +695,16 @@ circuit~\cite{reductioncircuit} for floating point numbers. Haskell is a statically-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, this section will - therefor only deal with the types that do have a clear correspondence + therefore 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. The translatable types are also inferable by the compiler, + those types for which a fixed translation is defined within the \CLaSH\ + 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, meaning that a developer does not have to annotate every function with a - type signature. + type signature (though it is good practice to do so anyway). % Translation of two most basic functional concepts has been % discussed: function application and choice. Before looking further @@ -717,7 +722,7 @@ circuit~\cite{reductioncircuit} for floating point numbers. % using translation rules that are discussed later on. \subsubsection{Built-in types} - The following types have direct translations defined within the \CLaSH\ + The following types have fixed translations defined within the \CLaSH\ compiler: \begin{xlist} \item[\bf{Bit}] @@ -731,7 +736,7 @@ circuit~\cite{reductioncircuit} for floating point numbers. % 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 + \hs{if-then-else} expression, 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, @@ -755,7 +760,9 @@ circuit~\cite{reductioncircuit} for floating point numbers. arguments: the length of the vector and the type of the elements contained in it. The short-hand notation used for the vector type in 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. + 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. % The state type of an 8 element register bank would then for example % be: @@ -814,8 +821,9 @@ circuit~\cite{reductioncircuit} for floating point numbers. 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. Haskell's built-in tuple types are also defined - as single constructor algebraic types An example of a single - constructor type is the following pair of integers: + as single constructor algebraic types (but with a bit of + syntactic sugar). An example of a single constructor type is the + following pair of integers: \begin{code} data IntPair = IntPair Int Int \end{code} @@ -825,7 +833,7 @@ circuit~\cite{reductioncircuit} for floating point numbers. 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 that there a fixed translation for + defined as an enumeration type, but that there is a fixed translation for that type within the \CLaSH\ compiler. An example of such an enumeration type is the type that represents the colors in a traffic light: @@ -851,7 +859,9 @@ circuit~\cite{reductioncircuit} for floating point numbers. any number of new types. As an example of a parametric polymorphic function, consider the type of - the following \hs{append} function, which appends an element to a vector: + the following \hs{append} function, which appends an element to a + vector:\footnote{The \hs{::} operator is used to annotate a function + with its type in \CLaSH} \begin{code} append :: [a|n] -> a -> [a|n + 1] @@ -892,15 +902,15 @@ circuit~\cite{reductioncircuit} for floating point numbers. types that are \emph{instances} of the \emph{type class} \hs{Num}, so that we know that the addition (+) operator is defined for that type. \CLaSH's built-in numerical types are also instances of the \hs{Num} - class, so we can use the addition operator on \hs{SizedWords} as - well as on \hs{SizedInts}. + class, so we can use the addition operator (and thus the \hs{sum} + function) with \hs{SizedWords} as well as with \hs{SizedInts}. In \CLaSH, parametric 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 however one constraint: the top level function that is being translated can not have any polymorphic arguments. - The arguments can not be polymorphic as they are never applied and + The arguments can not be polymorphic as the function is never applied and consequently there is no way to determine the actual types for the type parameters. @@ -930,8 +940,8 @@ circuit~\cite{reductioncircuit} for floating point numbers. The \hs{map} function is called a higher-order function, since it takes another function as an argument. Also note that \hs{map} is again a parametric polymorphic function: it does not pose any constraints on the - type of the vector elements, other than that it must be the same type as - the input type of the function passed to \hs{map}. The element type of the + type of the input vector, other than that its elements must have the same type as + the first argument of the function passed to \hs{map}. The element type of the resulting vector is equal to the return type of the function passed, which need not necessarily be the same as the element type of the input vector. All of these characteristics can readily be inferred from the type @@ -955,7 +965,7 @@ circuit~\cite{reductioncircuit} for floating point numbers. 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 lambda expression allows one to introduce an + adds one to its (next) argument. A lambda expression allows one to introduce an anonymous function in any expression. Consider the following expression, which again adds one to every element of a vector: @@ -963,8 +973,8 @@ circuit~\cite{reductioncircuit} for floating point numbers. map (\x -> x + 1) xs \end{code} - Finally, higher order arguments are not limited to just built-in - functions, but any function defined by a developer can have function + Finally, not only built-in functions can have higher order + arguments, 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. The only exception is again the top-level function: if a @@ -978,7 +988,7 @@ circuit~\cite{reductioncircuit} for floating point numbers. 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. + combinational 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 @@ -992,7 +1002,7 @@ circuit~\cite{reductioncircuit} for floating point numbers. % 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 combinatorial circuits, + Pure functions are as such a perfect match for combinaionial circuits, 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 @@ -1000,7 +1010,7 @@ circuit~\cite{reductioncircuit} for floating point numbers. In \CLaSH\ we deal with the concept of state in pure functions by making current value of the state an additional argument of the function and the updated state part of result. In this sense the descriptions made in - \CLaSH\ are the combinatorial parts of a mealy machine. + \CLaSH\ are the combinaionial parts of a mealy machine. A simple example is adding an accumulator register to the earlier multiply-accumulate circuit, of which the resulting netlist can be seen in @@ -1025,7 +1035,7 @@ circuit~\cite{reductioncircuit} for floating point numbers. 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 constructs, as state values are just normal values. We can simulate + choice elements, as state values are just normal values. We can simulate stateful descriptions using the recursive \hs{run} function: \begin{code} @@ -1070,7 +1080,7 @@ The prototype heavily uses \GHC, the Glasgow Haskell Compiler. see, the front-end is completely reused from \GHC, which allows the \CLaSH\ prototype to support most of the Haskell Language. The \GHC\ front-end produces the program in the \emph{Core} format, which is a very small, -functional, typed language which is relatively easy to process. +typed, functional language which is relatively easy to process. The second step in the compilation process is \emph{normalization}. This step runs a number of \emph{meaning preserving} transformations on the @@ -1098,14 +1108,14 @@ filter is indeed equivalent to the equation of the dot-product, which is shown below: \begin{equation} -\mathbf{x}\bullet\mathbf{y} = \sum\nolimits_{i = 0}^{n - 1} {x_i \cdot y_i } +\mathbf{a}\bullet\mathbf{b} = \sum\nolimits_{i = 0}^{n - 1} {a_i \cdot b_i } \end{equation} We can easily and directly implement the equation for the dot-product using higher-order functions: \begin{code} -xs *+* ys = foldl1 (+) (zipWith (*) xs hs) +as *+* bs = foldl1 (+) (zipWith (*) as bs) \end{code} The \hs{zipWith} function is very similar to the \hs{map} function seen @@ -1118,8 +1128,8 @@ the function to the first two elements of the vector. It then applies the function to the result of the first application and the next element from the vector. This continues until the end of the vector 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. +As you can see, the \hs{zipWith (*)} function is pairwise +multiplication and the \hs{foldl1 (+)} function is summation. Returning to the actual FIR filter, we will slightly change the equation belong to it, so as to make the translation to code more obvious. @@ -1145,7 +1155,7 @@ x >> xs = x +> tail xs Where the \hs{tail} function returns all but the first element of a vector, and the concatenate operator ($\succ$) adds a new element to the -left of a vector. The complete definition of the FIR filter then becomes: +front of a vector. The complete definition of the FIR filter then becomes: \begin{code} fir (State (xs,hs)) x = (State (x >> xs,hs), xs *+* hs) -- 2.30.2 From 3f6b1b23b0a0385a2d13f06f30a6a16043e28b2e Mon Sep 17 00:00:00 2001 From: Christiaan Baaij Date: Tue, 2 Mar 2010 14:52:09 +0100 Subject: [PATCH 06/16] Update section on the prototype compiler --- "c\316\273ash.lhs" | 26 ++++++-------------------- 1 file changed, 6 insertions(+), 20 deletions(-) diff --git "a/c\316\273ash.lhs" "b/c\316\273ash.lhs" index 85709be..77747d8 100644 --- "a/c\316\273ash.lhs" +++ "b/c\316\273ash.lhs" @@ -953,7 +953,7 @@ circuit~\cite{reductioncircuit} for floating point numbers. map (+ 1) xs \end{code} - Here, the expression \hs{(+) 1} is the partial application of the + 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 lambda expression allows one to introduce an anonymous function in any expression. Consider the following expression, @@ -1055,11 +1055,9 @@ circuit~\cite{reductioncircuit} for floating point numbers. bonus in case there is a large set of test inputs. \section{\CLaSH\ compiler} +An important aspect in this research is the creation of the prototype compiler, which allows us to translate descriptions made in the \CLaSH\ language as described in the previous section to synthesizable \VHDL, allowing a designer to actually run a \CLaSH\ design on an \acro{FPGA}. -The \CLaSH\ language as presented above can be translated to \VHDL\ using -the prototype \CLaSH\ compiler. This compiler allows experimentation with -the \CLaSH\ language and allows for running \CLaSH\ designs on actual FPGA -hardware. +The Glasgow Haskell Compiler (\GHC) is an open-source Haskell compiler that also provides a high level API to most of its internals. The availability of this high-level API obviated the need to design many of the tedious parts of the prototype compiler, such as the parser, semantic checker, and especially the type-checker. The parser, semantic checker, and type-checker together form the front-end of the prototype compiler pipeline, as depicted in \Cref{img:compilerpipeline}. \begin{figure} \centerline{\includegraphics{compilerpipeline.svg}} @@ -1067,21 +1065,9 @@ hardware. \label{img:compilerpipeline} \end{figure} -The prototype heavily uses \GHC, the Glasgow Haskell Compiler. -\Cref{img:compilerpipeline} shows the \CLaSH\ compiler pipeline. As you can -see, the front-end is completely reused from \GHC, which allows the \CLaSH\ -prototype to support most of the Haskell Language. The \GHC\ front-end -produces the program in the \emph{Core}~\cite{Sulzmann2007} format, which is a very small, -functional, typed language which is relatively easy to process. - -The second step in the compilation process is \emph{normalization}. This -step runs a number of \emph{meaning preserving} transformations on the -Core program, to bring it into a \emph{normal form}. This normal form -has a number of restrictions that make the program similar to hardware. -In particular, a program in normal form no longer has any polymorphism -or higher order functions. - -The final step is a simple translation to \VHDL. +The output of the \GHC\ front-end is the original Haskell description translated to \emph{Core}~\cite{Sulzmann2007}, which is smaller, functional, typed language that is relatively easier to process than the larger 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 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 reduction systems for lambda calculus, such a $\beta$-reduction and $\eta$-expansion, but also includes \emph{defunctionalization} transformations which reduce higher-order functions to `regular' first-order functions. + +The final step in the compiler pipeline is the translation to a \VHDL\ \emph{netlist}, which is a straightforward process due to resemblance of a normalized description and a set of concurrent signal assignments. We call the 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} \label{sec:usecases} -- 2.30.2 From f8fa45d04f3efaac96db9f31cdaf2415b9971bc2 Mon Sep 17 00:00:00 2001 From: Christiaan Baaij Date: Tue, 2 Mar 2010 14:52:45 +0100 Subject: [PATCH 07/16] Add some newlines to the prototype section --- "c\316\273ash.lhs" | 31 +++++++++++++++++++++++++++---- 1 file changed, 27 insertions(+), 4 deletions(-) diff --git "a/c\316\273ash.lhs" "b/c\316\273ash.lhs" index 77747d8..e17914f 100644 --- "a/c\316\273ash.lhs" +++ "b/c\316\273ash.lhs" @@ -1057,7 +1057,13 @@ circuit~\cite{reductioncircuit} for floating point numbers. \section{\CLaSH\ compiler} An important aspect in this research is the creation of the prototype compiler, which allows us to translate descriptions made in the \CLaSH\ language as described in the previous section to synthesizable \VHDL, allowing a designer to actually run a \CLaSH\ design on an \acro{FPGA}. -The Glasgow Haskell Compiler (\GHC) is an open-source Haskell compiler that also provides a high level API to most of its internals. The availability of this high-level API obviated the need to design many of the tedious parts of the prototype compiler, such as the parser, semantic checker, and especially the type-checker. The parser, semantic checker, and type-checker together form the front-end of the prototype compiler pipeline, as depicted in \Cref{img:compilerpipeline}. +The Glasgow Haskell Compiler (\GHC) is an open-source Haskell compiler that +also provides a high level API to most of its internals. The availability of +this high-level API obviated the need to design many of the tedious parts of +the prototype compiler, such as the parser, semantic checker, and especially +the type-checker. The parser, semantic checker, and type-checker together form +the front-end of the prototype compiler pipeline, as depicted in +\Cref{img:compilerpipeline}. \begin{figure} \centerline{\includegraphics{compilerpipeline.svg}} @@ -1065,9 +1071,26 @@ The Glasgow Haskell Compiler (\GHC) is an open-source Haskell compiler that also \label{img:compilerpipeline} \end{figure} -The output of the \GHC\ front-end is the original Haskell description translated to \emph{Core}~\cite{Sulzmann2007}, which is smaller, functional, typed language that is relatively easier to process than the larger 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 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 reduction systems for lambda calculus, such a $\beta$-reduction and $\eta$-expansion, but also includes \emph{defunctionalization} transformations which reduce higher-order functions to `regular' first-order functions. - -The final step in the compiler pipeline is the translation to a \VHDL\ \emph{netlist}, which is a straightforward process due to resemblance of a normalized description and a set of concurrent signal assignments. We call the end-product of the \CLaSH\ compiler a \VHDL\ \emph{netlist} as the resulting \VHDL\ resembles an actual netlist description and not idiomatic \VHDL. +The output of the \GHC\ front-end is the original Haskell description +translated to \emph{Core}~\cite{Sulzmann2007}, which is smaller, functional, +typed language that is relatively easier to process than the larger 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 +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 +reduction systems for lambda calculus, such a $\beta$-reduction and +$\eta$-expansion, but also includes \emph{defunctionalization} transformations +which reduce higher-order functions to `regular' first-order functions. + +The final step in the compiler pipeline is the translation to a \VHDL\ +\emph{netlist}, which is a straightforward process due to resemblance of a +normalized description and a set of concurrent signal assignments. We call the +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} \label{sec:usecases} -- 2.30.2 From c177537b5c0bd0984c10c0c98624921a136c17c4 Mon Sep 17 00:00:00 2001 From: Christiaan Baaij Date: Tue, 2 Mar 2010 14:57:27 +0100 Subject: [PATCH 08/16] Rewrite sentence about defunctionalization transformations --- "c\316\273ash.lhs" | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git "a/c\316\273ash.lhs" "b/c\316\273ash.lhs" index e17914f..d0ab48b 100644 --- "a/c\316\273ash.lhs" +++ "b/c\316\273ash.lhs" @@ -1083,8 +1083,9 @@ 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 reduction systems for lambda calculus, such a $\beta$-reduction and -$\eta$-expansion, but also includes \emph{defunctionalization} transformations -which reduce higher-order functions to `regular' first-order functions. +$\eta$-expansion, but also includes self-defined transformations that are +responsible for the reduction of higher-order functions to `regular' +first-order functions. The final step in the compiler pipeline is the translation to a \VHDL\ \emph{netlist}, which is a straightforward process due to resemblance of a -- 2.30.2 From b67d2a163cc5e8d55cecc17cc0ca2d7dcfb827e8 Mon Sep 17 00:00:00 2001 From: Christiaan Baaij Date: Tue, 2 Mar 2010 16:40:27 +0100 Subject: [PATCH 09/16] Update FIR example to include jan's comments, and do general cleanup of that section --- clash.bib | 12 +++++++++ "c\316\273ash.lhs" | 66 +++++++++++++++++++++++----------------------- 2 files changed, 45 insertions(+), 33 deletions(-) diff --git a/clash.bib b/clash.bib index 5bec913..e0ef497 100644 --- a/clash.bib +++ b/clash.bib @@ -106,6 +106,18 @@ timestamp = {2010.01.21} } +@BOOK{lambdacalculus, + title = {{The Lambda Calculus: its Syntax and Semantics}}, + publisher = {{Elsevier Science}}, + year = {1984}, + author = {{H.P. Barendregt}}, + volume = {103}, + series = {{Studies in Logic and the Foundations of Mathematics}}, + edition = {{Revised}}, + owner = {baaijcpr}, + timestamp = {2010.03.02} +} + @INPROCEEDINGS{DAISY, author = {Johnson, Steven D.}, title = {Applicative programming and digital design}, diff --git "a/c\316\273ash.lhs" "b/c\316\273ash.lhs" index d0ab48b..7eaf97f 100644 --- "a/c\316\273ash.lhs" +++ "b/c\316\273ash.lhs" @@ -1082,10 +1082,10 @@ 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 -reduction systems for lambda calculus, such a $\beta$-reduction and -$\eta$-expansion, but also includes self-defined transformations that are -responsible for the reduction of higher-order functions to `regular' -first-order functions. +reduction systems for lambda calculus~\cite{lambdacalculus}, such a +$\beta$-reduction and $\eta$-expansion, but also includes self-defined +transformations that are responsible for the reduction of higher-order +functions to `regular' first-order functions. The final step in the compiler pipeline is the translation to a \VHDL\ \emph{netlist}, which is a straightforward process due to resemblance of a @@ -1094,6 +1094,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} As an example of a common hardware design where the use of higher-order functions leads to a very natural description is a FIR filter, which is @@ -1123,48 +1125,48 @@ xs *+* ys = foldl1 (+) (zipWith (*) xs hs) The \hs{zipWith} function is very similar to the \hs{map} function seen earlier: It takes a function, two vectors, and then applies the function to each of the elements in the two vectors pairwise (\emph{e.g.}, \hs{zipWith (*) -[1, 2] [3, 4]} becomes \hs{[1 * 3, 2 * 4]} $\equiv$ \hs{[3,8]}). +[1, 2] [3, 4]} becomes \hs{[1 * 3, 2 * 4]}). -The \hs{foldl1} function takes a function, a single vector, and applies +The \hs{foldl1} function takes a binary function, a single vector, and applies the function to the first two elements of the vector. It then applies the -function to the result of the first application and the next element from -the vector. This continues until the end of the vector 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. - -Returning to the actual FIR filter, we will slightly change the -equation belong to it, so as to make the translation to code more obvious. -What we will do is change the definition of the vector of input samples. -So, instead of having the input sample received at time -$t$ stored 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 will better suit -the transformation to code): +function to the result of the first application and the next element in the +vector. This continues until the end of the vector is reached. The result of +the \hs{foldl1} function is the result of the last application. It is obvious +that the \hs{zipWith (*)} function is basically pairwise multiplication and +that the \hs{foldl1 (+)} function is just summation. + +Returning to the actual FIR filter, we will slightly change the equation +describing it, so as to make the translation to code more obvious and concise. +What we do is change the definition of the vector of input samples and delay +the computation by one sample. Instead of having the input sample received at +time $t$ stored in $x_t$, $x_0$ now always stores the newest 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 will better suit the transformation to code): \begin{equation} y_t = \sum\nolimits_{i = 0}^{n - 1} {x_i \cdot h_i } \end{equation} -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. The function that shifts the input samples is shown below: +The complete definition of the FIR filter in code then becomes: \begin{code} -x >> xs = x +> tail xs +fir (State (xs,hs)) x = (State (x >> xs,hs), xs *+* hs) \end{code} -Where the \hs{tail} function returns all but the first element of a -vector, and the concatenate operator ($\succ$) adds a new element to the -left of a vector. The complete definition of the FIR filter then becomes: +Where the vector \hs{hs} contains the 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{x}) to +the list of previous input samples (\hs{xs}) and removes the oldest sample is +shown below: \begin{code} -fir (State (xs,hs)) x = (State (x >> xs,hs), xs *+* hs) +x >> xs = x +> init xs \end{code} -The resulting netlist of a 4-taps FIR filter based on the above definition -is depicted in \Cref{img:4tapfir}. +The \hs{init} function returns all but the last element of a vector, and the +concatenate operator ($\succ$) adds a new element to the left of a vector. The +resulting netlist of a 4-taps FIR filter, created by specializing the vectors of the above definition to a length of 4, is depicted in \Cref{img:4tapfir}. \begin{figure} \centerline{\includegraphics{4tapfir.svg}} @@ -1172,10 +1174,8 @@ is depicted in \Cref{img:4tapfir}. \label{img:4tapfir} \end{figure} - \subsection{Higher order CPU} - \begin{code} type FuState = State Word fu :: (a -> a -> a) -- 2.30.2 From 77b02c1e068ac8ffb7187f2a1f2ad67402d019c7 Mon Sep 17 00:00:00 2001 From: Christiaan Baaij Date: Tue, 2 Mar 2010 17:02:16 +0100 Subject: [PATCH 10/16] Fix some spelling and layout mistakes --- "c\316\273ash.lhs" | 92 ++++++++++++++++++++++++---------------------- 1 file changed, 49 insertions(+), 43 deletions(-) diff --git "a/c\316\273ash.lhs" "b/c\316\273ash.lhs" index 99d2b9a..2a384a0 100644 --- "a/c\316\273ash.lhs" +++ "b/c\316\273ash.lhs" @@ -568,11 +568,11 @@ circuit~\cite{reductioncircuit} for floating point numbers. \item function applications are translated to component instantiations. \end{inparaenum} The output port can have a structured type (such as a tuple), so having - just a single output port does not pose any limitation. The actual arguments of a - function application are assigned to signals, which are then mapped to - the corresponding input ports of the component. The output port of the - function is also mapped to a signal, which is used as the result of the - application itself. + just a single output port does not pose any limitation. The actual + arguments of a function application are assigned to signals, which are + then mapped to the corresponding input ports of the component. 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 function calls is reflected in the final netlist,% aswell, @@ -610,7 +610,7 @@ circuit~\cite{reductioncircuit} for floating point numbers. \end{figure} \subsection{Choice} - In Haskell, choice can be achieved by a large set of syntacic elements, + In Haskell, choice can be achieved by a large set of syntactic elements, consisting of: \hs{case} expressions, \hs{if-then-else} expressions, pattern matching, and guards. The most general of these are the \hs{case} expressions (\hs{if} expressions can be very directly translated to @@ -833,8 +833,8 @@ circuit~\cite{reductioncircuit} for floating point numbers. 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 that there is a fixed translation for - that type within the \CLaSH\ compiler. An example of such an + defined as an enumeration type, but that there is a fixed translation + for that type within the \CLaSH\ compiler. An example of such an enumeration type is the type that represents the colors in a traffic light: \begin{code} @@ -861,7 +861,7 @@ circuit~\cite{reductioncircuit} for floating point numbers. As an example of a parametric polymorphic function, consider the type of the following \hs{append} function, which appends an element to a vector:\footnote{The \hs{::} operator is used to annotate a function - with its type in \CLaSH} + with its type.} \begin{code} append :: [a|n] -> a -> [a|n + 1] @@ -940,12 +940,12 @@ circuit~\cite{reductioncircuit} for floating point numbers. The \hs{map} function is called a higher-order function, since it takes another function as an argument. Also note that \hs{map} is again a parametric polymorphic function: it does not pose any constraints on the - type of the input vector, other than that its elements must have the same type as - the first argument of the function passed to \hs{map}. The element type of the - resulting vector is equal to the return type of the function passed, which - need not necessarily be the same as the element type of the input vector. - All of these characteristics can readily be inferred from the type - signature belonging to \hs{map}: + type of the input vector, other than that its elements must have the same + type as the first argument of the function passed to \hs{map}. The element + type of the resulting vector is equal to the return type of the function + passed, which need not necessarily be the same as the element type of the + input vector. All of these characteristics can readily be inferred from + the type signature belonging to \hs{map}: \begin{code} map :: (a -> b) -> [a|n] -> [b|n] @@ -965,9 +965,9 @@ circuit~\cite{reductioncircuit} for floating point numbers. 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 (next) argument. A lambda expression allows one to introduce an - anonymous function in any expression. Consider the following expression, - which again adds one to every element of a vector: + adds one to its (next) argument. A lambda expression allows one to + introduce an anonymous function in any expression. Consider the following + expression, which again adds one to every element of a vector: \begin{code} map (\x -> x + 1) xs @@ -1002,7 +1002,7 @@ circuit~\cite{reductioncircuit} for floating point numbers. % 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 combinaionial circuits, + Pure functions are as such a perfect match for combinational circuits, 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 @@ -1010,7 +1010,7 @@ circuit~\cite{reductioncircuit} for floating point numbers. In \CLaSH\ we deal with the concept of state in pure functions by making current value of the state an additional argument of the function and the updated state part of result. In this sense the descriptions made in - \CLaSH\ are the combinaionial parts of a mealy machine. + \CLaSH\ are the combinational parts of a mealy machine. A simple example is adding an accumulator register to the earlier multiply-accumulate circuit, of which the resulting netlist can be seen in @@ -1065,7 +1065,10 @@ circuit~\cite{reductioncircuit} for floating point numbers. bonus in case there is a large set of test inputs. \section{\CLaSH\ compiler} -An important aspect in this research is the creation of the prototype compiler, which allows us to translate descriptions made in the \CLaSH\ language as described in the previous section to synthesizable \VHDL, allowing a designer to actually run a \CLaSH\ design on an \acro{FPGA}. +An important aspect in this research is the creation of the prototype +compiler, which allows us to translate descriptions made in the \CLaSH\ +language as described in the previous section to synthesizable \VHDL, allowing +a designer to actually run a \CLaSH\ design on an \acro{FPGA}. The Glasgow Haskell Compiler (\GHC) is an open-source Haskell compiler that also provides a high level API to most of its internals. The availability of @@ -1083,9 +1086,9 @@ the front-end of the prototype compiler pipeline, as depicted in The output of the \GHC\ front-end is the original Haskell description translated to \emph{Core}~\cite{Sulzmann2007}, which is smaller, typed, -functional language that is relatively easier to process than the larger Haskell -language. A description in \emph{Core} can still contain properties which have -no direct translation to hardware, such as polymorphic types and +functional language that is relatively easier to process than the larger +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 @@ -1108,16 +1111,16 @@ end-product of the \CLaSH\ compiler a \VHDL\ \emph{netlist} as the resulting \subsection{FIR Filter} \label{sec:usecases} As an example of a common hardware design where the use of higher-order -functions leads to a very natural description is a FIR filter, which is +functions leads to a very natural description is a \acro{FIR} filter, which is basically the dot-product of two vectors: \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 +A \acro{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$. The equation of a FIR +are summed, to produce the result at time $t$. The equation of a \acro{FIR} filter is indeed equivalent to the equation of the dot-product, which is shown below: @@ -1145,38 +1148,41 @@ the \hs{foldl1} function is the result of the last application. It is obvious that the \hs{zipWith (*)} function is pairwise multiplication and that the \hs{foldl1 (+)} function is summation. -Returning to the actual FIR filter, we will slightly change the equation -describing it, so as to make the translation to code more obvious and concise. -What we do is change the definition of the vector of input samples and delay -the computation by one sample. Instead of having the input sample received at -time $t$ stored in $x_t$, $x_0$ now always stores the newest 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 will better suit the transformation to code): +Returning to the actual \acro{FIR} filter, we will slightly change the +equation describing it, so as to make the translation to code more obvious and +concise. What we do is change the definition of the vector of input samples +and delay the computation by one sample. Instead of having the input sample +received at time $t$ stored in $x_t$, $x_0$ now always stores the newest +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 will better suit the +transformation to code): \begin{equation} y_t = \sum\nolimits_{i = 0}^{n - 1} {x_i \cdot h_i } \end{equation} -The complete definition of the FIR filter in code then becomes: +The complete definition of the \acro{FIR} filter in code then becomes: \begin{code} fir (State (xs,hs)) x = (State (x >> xs,hs), xs *+* hs) \end{code} -Where the vector \hs{hs} contains the 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{x}) to -the list of previous input samples (\hs{xs}) and removes the oldest sample is -shown below: +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{x}) to the list of previous input samples (\hs{xs}) and removes the +oldest sample is shown below: \begin{code} x >> xs = x +> init xs \end{code} The \hs{init} function returns all but the last element of a vector, and the -concatenate operator ($\succ$) adds a new element to the front of a vector. The -resulting netlist of a 4-taps FIR filter, created by specializing the vectors of the above definition to a length of 4, is depicted in \Cref{img:4tapfir}. +concatenate operator (\hs{+>}) adds a new element to the front of a vector. +The resulting netlist of a 4-taps \acro{FIR} filter, created by specializing +the vectors of the \acro{FIR} code to a length of 4, is depicted in +\Cref{img:4tapfir}. \begin{figure} \centerline{\includegraphics{4tapfir.svg}} -- 2.30.2 From 956340a350f7a8ae4aea4bdc8a7ce291a79f9d1d Mon Sep 17 00:00:00 2001 From: Christiaan Baaij Date: Tue, 2 Mar 2010 17:11:57 +0100 Subject: [PATCH 11/16] update higherorder cpu in the paper to correspond with the compilable version --- "c\316\273ash.lhs" | 33 ++++++++++++++++----------------- 1 file changed, 16 insertions(+), 17 deletions(-) diff --git "a/c\316\273ash.lhs" "b/c\316\273ash.lhs" index 2a384a0..3ac0a7c 100644 --- "a/c\316\273ash.lhs" +++ "b/c\316\273ash.lhs" @@ -1193,12 +1193,11 @@ the vectors of the \acro{FIR} code to a length of 4, is depicted in \subsection{Higher order CPU} \begin{code} -type FuState = State Word fu :: (a -> a -> a) - -> [a]:n - -> (RangedWord n, RangedWord n) - -> FuState - -> (FuState, a) + -> [a | n] + -> (Index (n - 1), Index (n - 1)) + -> a + -> (a, a) fu op inputs (addr1, addr2) (State out) = (State out', out) where @@ -1208,22 +1207,22 @@ fu op inputs (addr1, addr2) (State out) = \end{code} \begin{code} -type CpuState = State [FuState]:4 +type CpuState = State [Word | 4] + cpu :: Word - -> [(RangedWord 7, RangedWord 7)]:4 + -> [(Index 6, Index 6) | 4] -> CpuState -> (CpuState, Word) -cpu input addrs (State fuss) = - (State fuss', out) +cpu input addrs (State fuss) = (State fuss', out) where - fures = [ fu const inputs!0 fuss!0 - , fu (+) inputs!1 fuss!1 - , fu (-) inputs!2 fuss!2 - , fu (*) inputs!3 fuss!3 - ] - (fuss', outputs) = unzip fures - inputs = 0 +> 1 +> input +> outputs - out = head outputs + fures = [ 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 \end{code} \section{Related work} -- 2.30.2 From eb4c92319202b796aaf0f2ae74e3637373e56104 Mon Sep 17 00:00:00 2001 From: Christiaan Baaij Date: Tue, 2 Mar 2010 17:20:05 +0100 Subject: [PATCH 12/16] Fix some additional spelling mistakes --- choice-case.svg | 809 +++++++++++++++++++++++---------------------- "c\316\273ash.lhs" | 17 +- 2 files changed, 418 insertions(+), 408 deletions(-) diff --git a/choice-case.svg b/choice-case.svg index 75701d1..eba9d9e 100644 --- a/choice-case.svg +++ b/choice-case.svg @@ -37,62 +37,62 @@ inkscape:window-maximized="0" inkscape:snap-center="false"> + visible="true" + empspacing="5" + id="grid2818" + type="xygrid" /> + refX="0" + refY="0" + orient="auto" + inkscape:stockid="Arrow1Mend"> + d="M 0,0 5,-5 -12.5,0 5,5 0,0 z" + id="path3732" /> + refX="0" + refY="0" + orient="auto" + inkscape:stockid="Arrow1Send"> + d="M 0,0 5,-5 -12.5,0 5,5 0,0 z" + id="path3738" /> - + + inkscape:vp_y="0 : 1000 : 0" + inkscape:vp_z="1 : 0.5 : 1" + inkscape:persp3d-origin="0.5 : 0.33333333 : 1" + id="perspective3128" /> @@ -107,51 +107,32 @@ + inkscape:groupmode="layer" + inkscape:label="Layer 1"> + x="20" + height="135.5" + width="139.5" + id="rect6192" + style="fill:#ffffff;fill-opacity:1;stroke:#000000;stroke-width:1;stroke-miterlimit:4;stroke-dasharray:none" /> + d="m 368.86,585.7295 82,0" + style="fill:none;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;marker-end:url(#Arrow1Mend)" /> + d="m 368.86,595.7295 82,0" + style="fill:none;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;marker-end:url(#Arrow1Mend)" /> - - + d="m 226.91,657.82 0.01,-0.04 0.01,-0.05 0.02,-0.04 0.01,-0.04 0.02,-0.04 0.02,-0.04 0.02,-0.03 0.02,-0.03 0.02,-0.04 0.02,-0.03 0.02,-0.03 0.03,-0.03 0.02,-0.02 0.03,-0.03 0.03,-0.02 0.02,-0.02 0.03,-0.02 0.03,-0.02 0.03,-0.02 0.03,-0.02 0.03,-0.01 0.03,-0.01 0.03,-0.02 0.04,-0.01 0.03,-0.01 0.03,0 0.03,-0.01 0.04,-0.01 0.03,0 0.03,0 0.03,-0.01 0.04,0 c 0.36,0 0.57,0.25 0.72,0.56 0.18,0.38 0.3,0.96 0.3,0.98 0,0.1 -0.08,0.1 -0.15,0.1 -0.12,0 -0.13,-0.01 -0.19,-0.23 -0.14,-0.56 -0.32,-1.19 -0.66,-1.19 -0.26,0 -0.26,0.27 -0.26,0.41 0,0.07 0,0.23 0.07,0.51 l 0.67,2.71 c 0.04,0.14 0.04,0.16 0.04,0.21 0,0.21 -0.16,0.26 -0.27,0.26 -0.31,0 -0.38,-0.34 -0.39,-0.39 -0.19,0.43 -0.51,0.59 -0.83,0.59 v -0.22 c 0.44,0 0.69,-0.52 0.69,-0.94 0,-0.02 -0.01,-0.07 -0.03,-0.13 h 0 l -0.47,-1.88 c -0.08,-0.32 -0.7,-1.13 -1.25,-1.13 -0.46,0 -0.54,0.59 -0.54,0.89 0,0.5 0.3,1.66 0.48,2.08 0.25,0.61 0.71,1.11 1.12,1.11 v 0.22 c -1.11,0 -2.28,-1.52 -2.28,-2.97 0,-0.85 0.46,-1.55 1.2,-1.55 0.36,0 0.8,0.21 1.2,0.7 z" + id="path3817" /> + + + xml:space="preserve" + stroke-miterlimit="10.433" + font-style="normal" + font-variant="normal" + font-weight="normal" + font-stretch="normal" + font-size-adjust="none" + letter-spacing="normal" + word-spacing="normal" + ns0:text="$\\mathit{pred}$\n\n" + ns0:preamble="" + style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;letter-spacing:normal;word-spacing:normal;text-anchor:start;fill:none;stroke:#000000;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:10.43299961;stroke-opacity:1;stroke-dasharray:none;stroke-dashoffset:0"> + style="fill:#000000;stroke-width:0" /> + style="fill:#000000;stroke-width:0" /> + style="fill:#000000;stroke-width:0" /> + style="fill:#000000;stroke-width:0" /> + id="g5140" + transform="translate(-75.428753,-10)"> + id="g4445" + transform="translate(118.2,-6.1899623)"> + sodipodi:ry="10" + sodipodi:rx="10" + sodipodi:cy="26.984081" + sodipodi:cx="40" + id="path3641" + style="fill:#ffffff;stroke:#000000" + sodipodi:type="arc" /> + ns0:text="$\\mathbf{+}$\n\n" + word-spacing="normal" + letter-spacing="normal" + font-size-adjust="none" + font-stretch="normal" + font-weight="normal" + font-variant="normal" + font-style="normal" + stroke-miterlimit="10.433" + xml:space="preserve" + transform="matrix(1,0,0,-1,191.89,1238.2695)" + id="g3067"> + style="fill:#000000;stroke-width:0" /> + id="g4438" + transform="translate(-67.228753,71.145019)"> + id="path4429" + sodipodi:cx="40" + sodipodi:cy="26.984081" + sodipodi:rx="10" + sodipodi:ry="10" + d="m 50,26.984081 c 0,5.522848 -4.477153,10 -10,10 -5.522847,0 -10,-4.477152 -10,-10 0,-5.522847 4.477153,-10 10,-10 5.522847,0 10,4.477153 10,10 z" + transform="translate(489,516.3654)" /> + ns0:text="$\\neq$\n\n\n\n\n" + word-spacing="normal" + letter-spacing="normal" + font-size-adjust="none" + font-stretch="normal" + font-weight="normal" + font-variant="normal" + font-style="normal" + stroke-miterlimit="10.433" + xml:space="preserve" + transform="matrix(1,0,0,-1,301.695,1203.0745)" + id="g3583"> + style="fill:#000000;stroke-width:0" /> + style="fill:#000000;stroke-width:0" /> + style="fill:#000000;stroke-width:0" /> + id="g4579" + transform="translate(-12.228753,57.380016)"> + id="path4581" + sodipodi:cx="40" + sodipodi:cy="26.984081" + sodipodi:rx="10" + sodipodi:ry="10" + d="m 50,26.984081 c 0,5.522848 -4.477153,10 -10,10 -5.522847,0 -10,-4.477152 -10,-10 0,-5.522847 4.477153,-10 10,-10 5.522847,0 10,4.477153 10,10 z" + transform="translate(434,506.3654)" /> + ns0:text="$\\equiv$\n\n\n\n\n" + word-spacing="normal" + letter-spacing="normal" + font-size-adjust="none" + font-stretch="normal" + font-weight="normal" + font-variant="normal" + font-style="normal" + stroke-miterlimit="10.433" + xml:space="preserve" + transform="matrix(1,0,0,-1,246.72,1192.8695)" + id="g4583"> + d="m 230.27,661.46 0.03,0 0.03,0 0.03,0 0.02,0 0.01,0 0.02,0 0.02,0 0.01,0.01 0.01,0 0.02,0 0.01,0 0.02,0.01 0.01,0 0.01,0.01 0.01,0 0.02,0.01 0.01,0.01 0.01,0 0.01,0.01 0.01,0.01 0,0.01 0.01,0.01 0,0 0,0.01 0.01,0 0,0.01 0,0.01 0.01,0 0,0.01 0,0.01 0,0.01 0,0 0,0.01 0,0.01 0.01,0.01 0,0.01 0,0.01 c 0,0.19 -0.18,0.19 -0.35,0.19 h -5.95 c -0.17,0 -0.35,0 -0.35,-0.19 0,-0.2 0.2,-0.2 0.36,-0.2 z" /> + d="m 230.28,657.59 0.03,0 0.03,0 0.03,0 0.02,0 0.01,0 0.02,0.01 0.01,0 0.02,0 0.01,0 0.02,0 0.01,0.01 0.01,0 0.01,0.01 0.02,0 0.01,0.01 0.01,0 0.01,0.01 0.01,0.01 0.01,0.01 0.01,0 0.01,0.01 0,0.01 0,0.01 0.01,0 0,0.01 0,0 0,0.01 0.01,0.01 0,0 0,0.01 0,0.01 0,0.01 0,0 0,0.01 0.01,0.01 0,0.01 0,0.01 c 0,0.2 -0.19,0.2 -0.36,0.2 h -5.93 c -0.16,0 -0.36,0 -0.36,-0.2 0,-0.2 0.18,-0.2 0.35,-0.2 z" /> + d="m 230.28,659.52 0.03,0 0.03,0 0.03,0.01 0.02,0 0.01,0 0.02,0 0.01,0 0.02,0 0.01,0 0.02,0.01 0.01,0 0.01,0 0.01,0.01 0.02,0 0.01,0.01 0.01,0.01 0.01,0 0.01,0.01 0.01,0.01 0.01,0.01 0.01,0.01 0,0 0,0.01 0.01,0 0,0.01 0,0.01 0,0 0.01,0.01 0,0.01 0,0 0,0.01 0,0.01 0,0.01 0,0.01 0.01,0 0,0.01 0,0.01 c 0,0.2 -0.18,0.2 -0.35,0.2 h -5.95 c -0.17,0 -0.35,0 -0.35,-0.2 0,-0.2 0.18,-0.2 0.35,-0.2 z" /> - - - - - - - - - - - + transform="matrix(1,0,0,-1,220.755,1202.9395)" + id="g5038"> - - - - - - - - - - - + + + + + d="m 488.02,578.19451 10,-5 0,-10 -10,-5 0,20 z" + id="path5134" /> + id="path5247" /> + + transform="matrix(1.44,0,0,1.44,376.30016,547.21208)" /> + + + + + + + + + + sodipodi:nodetypes="cc" + id="path5408" + d="m 476.18,631.15956 10,0" + style="fill:none;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;marker-end:url(#Arrow1Mend)" /> + + + + + + + transform="matrix(1.44,0,0,-1.44,358.24516,633.982)" /> + + id="path5432" + sodipodi:nodetypes="ccc" /> + id="path5434" /> + id="path5438" + d="m 130,88.410019 5,0 0,-29 0,0 9,0" + style="fill:none;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;marker-start:none;marker-end:url(#Arrow1Mend)" /> + id="path6184" + sodipodi:nodetypes="ccccc" /> + id="path6186" + sodipodi:nodetypes="cc" /> + transform="translate(-12.228753,133.38002)" + id="g2899"> + sodipodi:ry="10" + sodipodi:rx="10" + sodipodi:cy="26.984081" + sodipodi:cx="40" + id="path2901" + style="fill:#ffffff;stroke:#000000" + sodipodi:type="arc" /> + xml:space="preserve" + stroke-miterlimit="10.433" + font-style="normal" + font-variant="normal" + font-weight="normal" + font-stretch="normal" + font-size-adjust="none" + letter-spacing="normal" + word-spacing="normal" + ns0:text="$\\equiv$\n\n\n\n\n" + ns0:preamble="" + style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;letter-spacing:normal;word-spacing:normal;text-anchor:start;fill:none;stroke:#000000;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:10.43299961;stroke-opacity:1;stroke-dasharray:none;stroke-dashoffset:0"> + style="fill:#000000;stroke-width:0" /> + style="fill:#000000;stroke-width:0" /> + style="fill:#000000;stroke-width:0" /> + d="m 368.36,660.85952 83.7,0" + style="fill:none;stroke:#000000;stroke-width:1;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;marker-end:url(#Arrow1Mend)" /> + id="path2913" + sodipodi:nodetypes="cc" /> - + id="g3005"> + id="path3007" + fill="black" + stroke-width="0" + d="M230.24,659.57 L230.24,659.57 L230.24,659.58 L230.24,659.58 L230.24,659.58 L230.24,659.58 L230.24,659.58 L230.24,659.59 L230.24,659.59 L230.25,659.6 L230.25,659.6 L230.25,659.6 L230.25,659.61 L230.25,659.61 L230.25,659.62 L230.26,659.63 L230.26,659.64 L230.26,659.64 L230.26,659.65 L230.27,659.65 L230.27,659.66 L230.27,659.66 L230.27,659.66 L230.27,659.67 L230.27,659.67 L230.27,659.68 L230.27,659.68 L230.27,659.68 L230.28,659.68 L230.28,659.69 L230.28,659.69 L230.28,659.69 L230.28,659.69 L230.28,659.69 L230.28,659.69 L230.28,659.69 L230.28,659.69 L230.28,659.69 C230.28,659.8,230.16,659.8,230.13,659.8 C230.02,659.8,230.01,659.79,229.92,659.56 C229.34,658.19,228.99,657.54,227.41,657.54 H226.19 C225.88,657.54,225.88,657.57,225.88,657.64 C225.88,657.7,225.91,657.8,225.92,657.86 L226.61,660.6 H227.48 C228.15,660.6,228.23,660.44,228.23,660.17 C228.23,660.1,228.21,659.95,228.13,659.66 C228.13,659.64,228.12,659.58,228.12,659.55 C228.12,659.43,228.21,659.43,228.27,659.43 C228.38,659.43,228.41,659.45,228.45,659.63 L229,661.83 C229.01,661.85,229.03,661.93,229.03,661.96 C229.03,662.07,228.91,662.07,228.87,662.07 C228.74,662.07,228.74,662.04,228.68,661.84 C228.49,661.13,228.3,660.91,227.5,660.91 H226.69 L227.3,663.36 C227.38,663.69,227.45,663.7,227.78,663.7 H229.02 C230.1,663.7,230.35,663.4,230.35,662.69 C230.35,662.42,230.33,662.29,230.3,662.05 C230.29,662.01,230.28,661.91,230.28,661.89 C230.28,661.77,230.39,661.77,230.43,661.77 C230.57,661.77,230.58,661.8,230.6,661.98 L230.82,663.75 C230.85,664.01,230.79,664.01,230.59,664.01 H225.93 C225.76,664.01,225.66,664.01,225.66,663.83 C225.66,663.7,225.73,663.7,225.93,663.7 C226.51,663.7,226.51,663.62,226.51,663.53 C226.51,663.52,226.51,663.45,226.47,663.3 L225.14,657.96 C225.06,657.62,225,657.54,224.32,657.54 C224.16,657.54,224.05,657.54,224.05,657.35 C224.05,657.23,224.14,657.23,224.3,657.23 H229.07 C229.27,657.23,229.28,657.24,229.35,657.39 Z " /> + id="path3009" + fill="black" + stroke-width="0" + d="M235.11,661.39 L235.11,661.39 L235.11,661.39 L235.11,661.4 L235.12,661.4 L235.12,661.4 L235.12,661.41 L235.12,661.41 L235.12,661.42 L235.12,661.42 L235.12,661.43 L235.13,661.44 L235.13,661.45 L235.13,661.46 L235.13,661.47 L235.13,661.47 L235.13,661.47 L235.14,661.48 L235.14,661.48 L235.14,661.49 L235.14,661.49 L235.14,661.5 L235.14,661.5 L235.14,661.5 L235.14,661.51 L235.14,661.51 L235.14,661.51 L235.14,661.51 L235.14,661.52 C235.14,661.61,235.06,661.63,235.03,661.63 C234.92,661.63,234.56,661.28,234.4,661 C234.29,661.29,234.03,661.64,233.55,661.64 V661.42 C233.63,661.42,233.86,661.41,234.04,661.13 C234.13,660.97,234.24,660.68,234.24,660.49 C234.24,660.46,234.23,660.42,234.21,660.36 L233.73,658.45 C233.65,658.14,233.04,657.34,232.49,657.34 C232.02,657.34,231.94,657.93,231.94,658.23 C231.94,658.73,232.25,659.89,232.43,660.31 C232.68,660.92,233.14,661.42,233.55,661.42 V661.64 C232.44,661.64,231.27,660.12,231.27,658.67 C231.27,657.82,231.72,657.12,232.47,657.12 C232.88,657.12,233.25,657.38,233.53,657.65 L233.14,656.09 C233.03,655.66,233.02,655.62,232.38,655.61 C232.25,655.61,232.14,655.61,232.14,655.42 C232.14,655.33,232.2,655.3,232.27,655.3 C232.59,655.3,232.94,655.33,233.27,655.33 C233.6,655.33,233.96,655.3,234.27,655.3 C234.33,655.3,234.46,655.3,234.46,655.49 C234.46,655.61,234.36,655.61,234.23,655.61 C233.72,655.61,233.72,655.67,233.72,655.77 C233.72,655.84,233.74,655.89,233.75,655.95 Z " /> + id="path3011" + fill="black" + stroke-width="0" + d="M239.88,661.13 L239.89,661.14 L239.89,661.15 L239.89,661.16 L239.9,661.17 L239.9,661.18 L239.9,661.19 L239.9,661.2 L239.91,661.21 L239.91,661.21 L239.91,661.22 L239.91,661.22 L239.91,661.23 L239.91,661.23 L239.91,661.23 L239.91,661.24 L239.91,661.24 L239.91,661.24 L239.91,661.25 L239.91,661.25 L239.91,661.25 L239.91,661.26 L239.91,661.26 L239.91,661.26 L239.91,661.27 C239.91,661.38,239.83,661.53,239.63,661.53 C239.34,661.53,239.27,661.24,239.25,661.16 L238.52,658.25 C238.47,658.07,238.47,658.05,238.38,657.92 C238.19,657.64,237.9,657.34,237.46,657.34 C237.01,657.34,236.92,657.78,236.92,658.11 C236.92,658.72,237.25,659.61,237.5,660.29 C237.58,660.5,237.63,660.64,237.63,660.83 C237.63,661.33,237.3,661.64,236.88,661.64 C235.95,661.64,235.6,660.16,235.6,660.1 C235.6,660,235.7,660,235.75,660 C235.88,660,235.89,660.02,235.93,660.16 C236.01,660.47,236.28,661.42,236.85,661.42 C236.96,661.42,237.07,661.39,237.07,661.13 C237.07,660.89,236.97,660.62,236.84,660.23 C236.58,659.53,236.32,658.8,236.32,658.28 C236.32,657.41,236.9,657.12,237.43,657.12 C237.96,657.12,238.3,657.42,238.54,657.72 C238.72,657.18,239.15,657.12,239.34,657.12 C239.7,657.12,239.91,657.37,240.06,657.68 C240.24,658.06,240.36,658.64,240.36,658.66 C240.36,658.76,240.28,658.76,240.21,658.76 C240.09,658.76,240.08,658.75,240.02,658.53 C239.88,657.97,239.69,657.34,239.35,657.34 C239.1,657.34,239.1,657.61,239.1,657.75 C239.1,657.82,239.1,657.98,239.17,658.26 Z " /> + id="path3013" + fill="black" + stroke-width="0" + d="M243.6,657.82 L243.61,657.78 L243.62,657.73 L243.63,657.69 L243.65,657.65 L243.67,657.61 L243.68,657.57 L243.7,657.54 L243.72,657.51 L243.74,657.47 L243.77,657.44 L243.79,657.41 L243.81,657.38 L243.84,657.36 L243.87,657.33 L243.89,657.31 L243.92,657.29 L243.95,657.27 L243.98,657.25 L244.01,657.23 L244.04,657.21 L244.07,657.2 L244.1,657.19 L244.13,657.17 L244.16,657.16 L244.2,657.15 L244.23,657.15 L244.26,657.14 L244.29,657.13 L244.33,657.13 L244.36,657.13 L244.39,657.12 L244.42,657.12 C244.79,657.12,245,657.37,245.15,657.68 C245.33,658.06,245.45,658.64,245.45,658.66 C245.45,658.76,245.37,658.76,245.3,658.76 C245.18,658.76,245.17,658.75,245.11,658.53 C244.97,657.97,244.78,657.34,244.44,657.34 C244.18,657.34,244.18,657.61,244.18,657.75 C244.18,657.82,244.18,657.98,244.26,658.26 L244.93,660.97 C244.97,661.11,244.97,661.13,244.97,661.18 C244.97,661.39,244.8,661.44,244.7,661.44 C244.38,661.44,244.31,661.1,244.3,661.05 C244.12,661.48,243.8,661.64,243.48,661.64 V661.42 C243.92,661.42,244.16,660.9,244.16,660.48 C244.16,660.46,244.15,660.41,244.13,660.35 H244.13 L243.67,658.47 C243.59,658.15,242.97,657.34,242.42,657.34 C241.95,657.34,241.87,657.93,241.87,658.23 C241.87,658.73,242.18,659.89,242.36,660.31 C242.61,660.92,243.07,661.42,243.48,661.42 V661.64 C242.37,661.64,241.2,660.12,241.2,658.67 C241.2,657.82,241.65,657.12,242.4,657.12 C242.76,657.12,243.2,657.33,243.6,657.82 Z " /> + id="path3015" + fill="black" + stroke-width="0" + d="M248.23,663.9 L248.23,663.9 L248.23,663.9 L248.23,663.91 L248.24,663.91 L248.24,663.91 L248.24,663.92 L248.24,663.92 L248.24,663.93 L248.24,663.93 L248.24,663.94 L248.24,663.95 L248.25,663.96 L248.25,663.97 L248.25,663.98 L248.25,663.98 L248.25,663.98 L248.26,663.99 L248.26,663.99 L248.26,664 L248.26,664 L248.26,664.01 L248.26,664.01 L248.26,664.01 L248.26,664.02 L248.26,664.02 L248.26,664.02 L248.26,664.02 L248.26,664.03 C248.26,664.12,248.2,664.15,248.12,664.15 C248.09,664.15,247.99,664.14,247.96,664.13 L246.98,664.05 C246.86,664.04,246.75,664.03,246.75,663.84 C246.75,663.73,246.85,663.73,246.99,663.73 C247.46,663.73,247.48,663.66,247.48,663.56 C247.48,663.53,247.45,663.4,247.45,663.39 L246.21,658.41 C246.2,658.37,246.15,658.17,246.15,658.02 C246.15,657.49,246.51,657.12,246.99,657.12 C247.36,657.12,247.56,657.39,247.69,657.64 C247.86,657.99,248,658.63,248,658.66 C248,658.76,247.92,658.76,247.85,658.76 C247.8,658.76,247.74,658.76,247.71,658.71 L247.64,658.46 C247.47,657.76,247.29,657.34,247.01,657.34 C246.75,657.34,246.75,657.61,246.75,657.75 C246.75,657.82,246.75,657.97,246.81,658.21 Z " /> diff --git "a/c\316\273ash.lhs" "b/c\316\273ash.lhs" index 3ac0a7c..d2820a4 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. + elaborate in real \CLaSH\ programs. % The state type of an 8 element register bank would then for example % be: @@ -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: @@ -1237,7 +1236,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 -- 2.30.2 From f1618a30b651a3bf99800d1655df716d853f3bc7 Mon Sep 17 00:00:00 2001 From: Christiaan Baaij Date: Wed, 3 Mar 2010 09:57:32 +0100 Subject: [PATCH 13/16] Fix some textual things, and introduce the intention of the related work section --- "c\316\273ash.lhs" | 30 ++++++++++++++++-------------- 1 file changed, 16 insertions(+), 14 deletions(-) diff --git "a/c\316\273ash.lhs" "b/c\316\273ash.lhs" index d2820a4..e02b16d 100644 --- "a/c\316\273ash.lhs" +++ "b/c\316\273ash.lhs" @@ -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 @@ -1168,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 @@ -1225,6 +1225,10 @@ cpu input addrs (State fuss) = (State fuss', out) \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 @@ -1278,9 +1282,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}. % @@ -1382,14 +1389,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 -- 2.30.2 From 04826a331fd930f2657850390efe332f18c40424 Mon Sep 17 00:00:00 2001 From: Christiaan Baaij Date: Wed, 3 Mar 2010 10:09:09 +0100 Subject: [PATCH 14/16] Reduce code-size of higher-order cpu --- HigherOrderCPU.hs | 11 ++--------- "c\316\273ash.lhs" | 13 ++----------- 2 files changed, 4 insertions(+), 20 deletions(-) diff --git a/HigherOrderCPU.hs b/HigherOrderCPU.hs index fd7471b..94bb7b6 100644 --- a/HigherOrderCPU.hs +++ b/HigherOrderCPU.hs @@ -12,15 +12,8 @@ import CLasH.Translator.Annotations type Word = SizedInt D16 type Index = RangedWord -const :: a -> a -> a const a b = a -fu :: ( PositiveT p, NaturalT n, (p :>: n) ~ True) => - (a -> a -> a) - -> Vector p a - -> (Index n, Index n) - -> a - -> (a, a) fu op inputs (addr1, addr2) out = (out', out) where @@ -42,8 +35,8 @@ cpu input addrs (State fuss) = where fures = (fu const inputs (addrs!(0 :: Index D3)) (fuss!(0 :: Index D3))) +> ( (fu (+) inputs (addrs!(1 :: Index D3)) (fuss!(1 :: Index D3))) +> ( - (fu (-) inputs (addrs!(2 :: Index D3)) (fuss!(2 :: Index D3))) +> ( singleton - (fu (*) inputs (addrs!(3 :: Index D3)) (fuss!(3 :: Index D3)))))) + (fu (-) inputs (addrs!(2 :: Index D3)) (fuss!(2 :: Index D3))) +> ( + (fu (*) inputs (addrs!(3 :: Index D3)) (fuss!(3 :: Index D3))) +> empty))) (fuss', outputs) = unzip fures inputs = 0 +> (1 +> (input +> outputs)) out = head outputs diff --git "a/c\316\273ash.lhs" "b/c\316\273ash.lhs" index e02b16d..3bcf41e 100644 --- "a/c\316\273ash.lhs" +++ "b/c\316\273ash.lhs" @@ -1192,11 +1192,6 @@ 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) where @@ -1206,12 +1201,8 @@ fu op inputs (addr1, addr2) (State out) = \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) -- 2.30.2 From 65363f98c6333631868a58c2756ba53614c59cc6 Mon Sep 17 00:00:00 2001 From: Christiaan Baaij Date: Wed, 3 Mar 2010 10:11:09 +0100 Subject: [PATCH 15/16] Reword description about vector type notation --- "c\316\273ash.lhs" | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git "a/c\316\273ash.lhs" "b/c\316\273ash.lhs" index 3bcf41e..59f529a 100644 --- "a/c\316\273ash.lhs" +++ "b/c\316\273ash.lhs" @@ -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: -- 2.30.2 From 645d4f8e703fcb77044b0fce5b3134187ef056aa Mon Sep 17 00:00:00 2001 From: Christiaan Baaij Date: Wed, 3 Mar 2010 10:15:14 +0100 Subject: [PATCH 16/16] make paper version of highordcpu resemble compilable version of highordcpu --- "c\316\273ash.lhs" | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) diff --git "a/c\316\273ash.lhs" "b/c\316\273ash.lhs" index 59f529a..2fa6b86 100644 --- "a/c\316\273ash.lhs" +++ "b/c\316\273ash.lhs" @@ -1192,12 +1192,11 @@ the vectors of the \acro{FIR} code to a length of 4, is depicted in \subsection{Higher order CPU} \begin{code} -fu op inputs (addr1, addr2) (State out) = - (State out', out) +fu op inputs (addr1, addr2) regOut = (regIn, regOut) 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} -- 2.30.2