development.
\stopitemize
- \todo{Sidenote: No EDSL}
+ \placeintermezzo{}{
+ \startframedtext[width=8cm,background=box,frame=no]
+ \startalignment[center]
+ {\tfa No \small{EDSL} or Template Haskell}
+ \stopalignment
+ \blank[medium]
+
+ Note that in this consideration, embedded domain-specific
+ languages (\small{EDSL}) and Template Haskell (\small{TH})
+ approaches have not been included. As we've seen in
+ \in{section}[sec:context:fhdls], these approaches have all kinds
+ of limitations on the description language that we would like to
+ avoid.
+ \stopframedtext
+ }
Considering that we required a prototype which should be working quickly,
and that implementing parsers, semantic checkers and especially
typcheckers is not exactly the core of this research (but it is lots and
However, \small{EDIF} is not completely tool-independent. It specifies a
meta-format, but the hardware components that can be used vary between
various tool and hardware vendors, as well as the interpretation of the
- \small{EDIF} standard. \todo{Is this still true? Reference:
- http://delivery.acm.org/10.1145/80000/74534/p803-li.pdf?key1=74534\&key2=8370537521\&coll=GUIDE\&dl=GUIDE\&CFID=61207158\&CFTOKEN=61908473}
+ \small{EDIF} standard. \cite[li89]
This means that when working with \small{EDIF}, our prototype would become
technology dependent (\eg only work with \small{FPGA}s of a specific
switch to \small{EDIF} in the future, with minimal changes to the
prototype.
- \section{Prototype design}
+ \section[sec:prototype:design]{Prototype design}
As suggested above, we will use the Glasgow Haskell Compiler (\small{GHC}) to
implement our prototype compiler. To understand the design of the
compiler, we will first dive into the \small{GHC} compiler a bit. It's
discuss it any further, since it is not required for our prototype.
\stopdesc
- In this process, there a number of places where we can start our work.
+ In this process, there are a number of places where we can start our work.
Assuming that we don't want to deal with (or modify) parsing, typechecking
and other frontend business and that native code isn't really a useful
format anymore, we are left with the choice between the full Haskell
The advantage of taking the full \small{AST} is that the exact structure
of the source program is preserved. We can see exactly what the hardware
- descriiption looks like and which syntax constructs were used. However,
+ description looks like and which syntax constructs were used. However,
the full \small{AST} is a very complicated datastructure. If we are to
handle everything it offers, we will quickly get a big compiler.
However, the fact that the core language is so much smaller, means it is a
lot easier to analyze and translate it into something else. For the same
reason, \small{GHC} runs its simplifications and optimizations on the core
- representation as well.
+ representation as well \cite[jones96].
However, we will use the normal core representation, not the simplified
core. Reasons for this are detailed below. \todo{Ref}
binder (the function name) to an expression (the function value, which has
a function type).
- The Core language itself does not prescribe any program structure, only
- expression structure. In the \small{GHC} compiler, the Haskell module
- structure is used for the resulting Core code as well. Since this is not
- so relevant for understanding the Core language or the Normalization
+ The Core language itself does not prescribe any program structure
+ (like modules, declarations, imports, etc.), only expression
+ structure. In the \small{GHC} compiler, the Haskell module structure
+ is used for the resulting Core code as well. Since this is not so
+ relevant for understanding the Core language or the Normalization
process, we'll only look at the Core expression language here.
Each Core expression consists of one of these possible expressions.
\startdesc{Variable reference}
\defref{variable reference}
\startlambda
- x :: T
+ bndr :: T
\stoplambda
This is a reference to a binder. It's written down as the
name of the binder that is being referred to along with its type. The
- binder name should of course be bound in a containing scope (including
- top level scope, so a reference to a top level function is also a
- variable reference). Additionally, constructors from algebraic datatypes
- also become variable references.
+ binder name should of course be bound in a containing scope
+ (including top level scope, so a reference to a top level function
+ is also a variable reference). Additionally, constructors from
+ algebraic datatypes also become variable references.
- The value of this expression is the value bound to the given binder.
+ In our examples, binders will commonly consist of a single
+ characters, but they can have any length.
+
+ The value of this expression is the value bound to the given
+ binder.
Each binder also carries around its type (explicitly shown above), but
this is usually not shown in the Core expressions. Only when the type is
\stoplambda
This is a literal. Only primitive types are supported, like
chars, strings, ints and doubles. The types of these literals are the
- \quote{primitive} versions, like \lam{Char\#} and \lam{Word\#}, not the
- normal Haskell versions (but there are builtin conversion functions).
+ \quote{primitive}, unboxed versions, like \lam{Char\#} and \lam{Word\#}, not the
+ normal Haskell versions (but there are builtin conversion
+ functions). Without going into detail about these types, note that
+ a few conversion functions exist to convert these to the normal
+ (boxed) Haskell equivalents.
\stopdesc
\startdesc{Application}
\startlambda
λbndr.body
\stoplambda
- This is the basic lambda abstraction, as it occurs in labmda calculus.
+ This is the basic lambda abstraction, as it occurs in lambda calculus.
It consists of a binder part and a body part. A lambda abstraction
creates a function, that can be applied to an argument. The binder is
usually a value binder, but it can also be a \emph{type binder} (or
variable, which can be used in types later on. See
\in{section}[sec:prototype:coretypes] for details.
- Note that the body of a lambda abstraction extends all the way to the
- end of the expression, or the closing bracket surrounding the lambda. In
- other words, the lambda abstraction \quote{operator} has the lowest
- priority of all.
+ The body of a lambda abstraction extends all the way to the end of
+ the expression, or the closing bracket surrounding the lambda. In
+ other words, the lambda abstraction \quote{operator} has the
+ lowest priority of all.
The value of an application is the value of the body part, with the
binder bound to the value the entire lambda abstraction is applied to.
let bndr = value in body
\stoplambda
A let expression allows you to bind a binder to some value, while
- evaluating to some other value (where that binder is in scope). This
+ evaluating to some other value (for which that binder is in scope). This
allows for sharing of subexpressions (you can use a binder twice) and
- explicit \quote{naming} of arbitrary expressions. Note that the binder
- is not in scope in the value bound to it, so it's not possible to make
- recursive definitions with the normal form of the let expression (see
- the recursive form below).
+ explicit \quote{naming} of arbitrary expressions. A binder is not
+ in scope in the value bound it is bound to, so it's not possible
+ to make recursive definitions with a non-recursive let expression
+ (see the recursive form below).
Even though this let expression is an extension on the basic lambda
calculus, it is easily translated to a lambda abstraction. The let
binders is in scope in each of the values, in addition to the body. This
allows for self-recursive or mutually recursive definitions.
- It should also be possible to express a recursive let using normal
- lambda calculus, if we use the \emph{least fixed-point operator},
- \lam{Y}. This falls beyond the scope of this report, since it is not
- needed for this research.
+ It is also possible to express a recursive let expression using
+ normal lambda calculus, if we use the \emph{least fixed-point
+ operator}, \lam{Y} (but the details are too complicated to help
+ clarify the let expression, so this will not be explored further).
\stopdesc
+ \placeintermezzo{}{
+ \startframedtext[width=8cm,background=box,frame=no]
+ \startalignment[center]
+ {\tfa Weak head normal form (\small{WHNF})}
+ \stopalignment
+ \blank[medium]
+ An expression is in weak head normal form if it is either an
+ constructor application or lambda abstraction. \todo{How about
+ atoms?}
+
+ Without going into detail about the differences with head
+ normal form and normal form, note that evaluating the scrutinee
+ of a case expression to normal form (evaluating any function
+ applications, variable references and case expressions) is
+ sufficient to decide which case alternatives should be chosen.
+ \todo{ref?}
+ \stopframedtext
+
+ }
+
\startdesc{Case expression}
\defref{case expression}
\startlambda
Cn bndrn,0 ... bndrn,m -> bodyn
\stoplambda
- \todo{Define WHNF}
-
A case expression is the only way in Core to choose between values. All
\hs{if} expressions and pattern matchings from the original Haskell
PRogram have been translated to case expressions by the desugarer.
A case expression evaluates its scrutinee, which should have an
algebraic datatype, into weak head normal form (\small{WHNF}) and
- (optionally) binds it to \lam{bndr}. It then chooses a body depending on
- the constructor of its scrutinee. If none of the constructors match, the
- \lam{DEFAULT} alternative is chosen. A case expression must always be
- exhaustive, \ie it must cover all possible constructors that the
- scrutinee can have (if all of them are covered explicitly, the
- \lam{DEFAULT} alternative can be left out).
+ (optionally) binds it to \lam{bndr}. Every alternative lists a
+ single constructor (\lam{C0 ... Cn}). Based on the actual
+ constructor of the scrutinee, the corresponding alternative is
+ chosen. The binders in the chosen alternative (\lam{bndr0,0 ....
+ bndr0,m} are bound to the actual arguments to the constructor in
+ the scrutinee.
+
+ This is best illustrated with an example. Assume
+ there is an algebraic datatype declared as follows\footnote{This
+ datatype is not suported by the current Cλash implementation, but
+ serves well to illustrate the case expression}:
+
+ \starthaskell
+ data D = A Word | B Bit
+ \stophaskell
+
+ This is an algebraic datatype with two constructors, each getting
+ a single argument. A case expression scrutinizing this datatype
+ could look like the following:
+
+ \startlambda
+ case s of
+ A word -> High
+ B bit -> bit
+ \stoplambda
+
+ What this expression does is check the constructor of the
+ scrutinee \lam{s}. If it is \lam{A}, it always evaluates to
+ \lam{High}. If the constructor is \lam{B}, the binder \lam{bit} is
+ bound to the argument passed to \lam{B} and the case expression
+ evaluates to this bit.
+
+ If none of the alternatives match, the \lam{DEFAULT} alternative
+ is chosen. A case expression must always be exhaustive, \ie it
+ must cover all possible constructors that the scrutinee can have
+ (if all of them are covered explicitly, the \lam{DEFAULT}
+ alternative can be left out).
Since we can only match the top level constructor, there can be no overlap
in the alternatives and thus order of alternatives is not relevant (though
the \lam{DEFAULT} alternative must appear first for implementation
efficiency).
- Any arguments to the constructor in the scrutinee are bound to each of the
- binders after the constructor and are in scope only in the corresponding
- body.
-
To support strictness, the scrutinee is always evaluated into
\small{WHNF}, even when there is only a \lam{DEFAULT} alternative. This
allows aplication of the strict function \lam{f} to the argument \lam{a}
binder, even when strictness was involved. Nonetheless, the prototype
handles this binder as expected.
- Note that these case statements are less powerful than the full Haskell
- case statements. In particular, they do not support complex patterns like
+ Note that these case expressions are less powerful than the full Haskell
+ case expressions. In particular, they do not support complex patterns like
in Haskell. Only the constructor of an expression can be matched,
complex patterns are implemented using multiple nested case expressions.
- Case statements are also used for unpacking of algebraic datatypes, even
+ Case expressions are also used for unpacking of algebraic datatypes, even
when there is only a single constructor. For examples, to add the elements
of a tuple, the following Core is generated:
\startdesc{Type}
\defref{type expression}
\startlambda
- @type
+ @T
\stoplambda
- It is possibly to use a Core type as a Core expression. For the actual
- types supported by Core, see \in{section}[sec:prototype:coretypes]. This
- \quote{lifting} of a type into the value domain is done to allow for
- type abstractions and applications to be handled as normal lambda
- abstractions and applications above. This means that a type expression
- in Core can only ever occur in the argument position of an application,
- and only if the type of the function that is applied to expects a type
- as the first argument. This happens for all polymorphic functions, for
- example, the \lam{fst} function:
+ It is possibly to use a Core type as a Core expression. To prevent
+ confusion between types and values, the \lam{@} sign is used to
+ explicitly mark a type that is used in a Core expression.
+
+ For the actual types supported by Core, see
+ \in{section}[sec:prototype:coretypes]. This \quote{lifting} of a
+ type into the value domain is done to allow for type abstractions
+ and applications to be handled as normal lambda abstractions and
+ applications above. This means that a type expression in Core can
+ only ever occur in the argument position of an application, and
+ only if the type of the function that is applied to expects a type
+ as the first argument. This happens for all polymorphic functions,
+ for example, the \lam{fst} function:
\startlambda
- fst :: \forall a. \forall b. (a, b) -> a
- fst = λtup.case tup of (,) a b -> a
+ fst :: \forall t1. \forall t2. (t1, t2) ->t1
+ fst = λt1.λt2.λ(tup :: (t1, t2)). case tup of (,) a b -> a
fstint :: (Int, Int) -> Int
fstint = λa.λb.fst @Int @Int a b
The type of \lam{fst} has two universally quantified type variables. When
\lam{fst} is applied in \lam{fstint}, it is first applied to two types.
- (which are substitued for \lam{a} and \lam{b} in the type of \lam{fst}, so
- the type of \lam{fst} actual type of arguments and result can be found:
+ (which are substitued for \lam{t1} and \lam{t2} in the type of \lam{fst}, so
+ the actual type of arguments and result of \lam{fst} can be found:
\lam{fst @Int @Int :: (Int, Int) -> Int}).
\stopdesc
In Core, every expression is typed. The translation to Core happens
after the typechecker, so types in Core are always correct as well
- (though you could of course construct invalidly typed expressions).
+ (though you could of course construct invalidly typed expressions
+ through the \GHC API).
Any type in core is one of the following:
Maybe Int
\stoplambda
- This applies a some type to another type. This is particularly used to
+ This applies some type to another type. This is particularly used to
apply type variables (type constructors) to their arguments.
As mentioned above, applications of some type constructors have
special notation. In particular, these are applications of the
\emph{function type constructor} and \emph{tuple type constructors}:
\startlambda
- foo :: a -> b
- foo' :: -> a b
- bar :: (a, b, c)
- bar' :: (,,) a b c
+ foo :: t1 -> t2
+ foo' :: -> t1 t2
+ bar :: (t1, t2, t3)
+ bar' :: (,,) t1 t2 t3
\stoplambda
\stopdesc
\startdesc{The forall type}
\startlambda
- id :: \forall a. a -> a
+ id :: \forall t. t -> t
\stoplambda
The forall type introduces polymorphism. It is the only way to
introduce new type variables, which are completely unconstrained (Any
expression. For example, the Core translation of the
id function is:
\startlambda
- id = λa.λx.x
+ id = λt.λ(x :: t).x
\stoplambda
- Here, the type of the binder \lam{x} is \lam{a}, referring to the
+ Here, the type of the binder \lam{x} is \lam{t}, referring to the
binder in the topmost lambda.
When using a value with a forall type, the actual type
\stoplambda
Here, id is first applied to the type to work with. Note that the type
- then changes from \lam{id :: \forall a. a -> a} to \lam{id @Bool ::
+ then changes from \lam{id :: \forall t. t -> t} to \lam{id @Bool ::
Bool -> Bool}. Note that the type variable \lam{a} has been
substituted with the actual type.
\startdesc{Predicate type}
\startlambda
- show :: \forall a. Show s ⇒ s → String
+ show :: \forall t. Show t ⇒ t → String
\stoplambda
\todo{Sidenote: type classes?}
A predicate type introduces a constraint on a type variable introduced
by a forall type (or type lambda). In the example above, the type
- variable \lam{a} can only contain types that are an \emph{instance} of
+ variable \lam{t} can only contain types that are an \emph{instance} of
the \emph{type class} \lam{Show}. \refdef{type class}
There are other sorts of predicate types, used for the type families
could be used to track down the statefulness of each value by the
compiler. However, this makes the implementation a lot more complicated
than it currently is using \hs{newtypes}.
- \subsection{Type renaming (\hs{newtype})}
+
+ % Use \type instead of \hs here, since the latter breaks inside
+ % section headings.
+ \subsection{Type renaming (\type{newtype})}
Haskell also supports type renamings as a way to declare a new type that
has the same (runtime) representation as an existing type (but is in
fact a different type to the typechecker). With type renaming, an
We cannot leave all these \hs{State} type constructors out, since that
would change the type (unlike when using type synonyms). However, when
- using type synonyms to hide away substates, \todo{see below} this
+ using type synonyms to hide away substates (see
+ \in{section}[sec:prototype:substatesynonyms] below), this
disadvantage should be limited.
\subsubsection{Different input and output types}
and output state types, possible reducing the type safety of the
descriptions.
- \subsection{Type synonyms for substates}
+ \subsection[sec:prototype:substatesynonyms]{Type synonyms for substates}
As noted above, when using nested (hierarchical) states, the state types
of the \quote{upper} functions (those that call other functions, which
call other functions, etc.) quickly becomes complicated. Also, when the
\subsection{Chosen approach}
To keep implementation simple, the current prototype uses the type
- renaming approach, with a single type for both input and output states.
- \todo{}
+ renaming approach, with a single type for both input and output
+ states. In the future, it might be worthwhile to revisit this
+ approach if more complicated flow analysis is implemented for
+ state variables. This analysis is needed to add proper error
+ checking anyway and might allow the use of type synonyms without
+ losing any expressivity.
\subsubsection{Example}
As an example of the used approach, there is a simple averaging circuit in
\in{example}[ex:AvgState]. This circuit lets the accumulation of the
inputs be done by a subcomponent, \hs{acc}, but keeps a count of value
- accumulated in its own state.
-
+ accumulated in its own state.\footnote{Currently, the prototype
+ is not able to compile this example, since the builtin function
+ for division has not been added.}
\startbuffer[AvgState]
-- The state type annotation
newtype State s = State s
-- The accumulator state type
- type AccState = State Bit
+ type AccState = State Word
-- The accumulator
acc :: Word -> AccState -> (AccState, Word)
acc i (State s) = let sum = s + i in (State sum, sum)
-- The averaging circuit state type
- type AvgState = (AccState, Word)
+ type AvgState = State (AccState, Word)
-- The averaging circuit
avg :: Word -> AvgState -> (AvgState, Word)
avg i (State s) = (State s', o)
%\stopcombination
\todo{Picture}
- And the normalized, core-like versions:
+ \section{Implementing state}
+ Now its clear how to put state annotations in the Haskell source,
+ there is the question of how to implement this state translation. As
+ we've seen in \in{section}[sec:prototype:design], the translation to
+ \VHDL happens as a simple, final step in the compilation process.
+ This step works on a core expression in normal form. The specifics
+ of normal form will be explained in
+ \in{chapter}[chap:normalization], but the examples given should be
+ easy to understand using the definitin of Core given above.
\startbuffer[AvgStateNormal]
acc = λi.λspacked.
\placeexample[here][ex:AvgStateNormal]{Normalized version of \in{example}[ex:AvgState]}
{\typebufferlam{AvgStateNormal}}
-
- \subsection{What can you do with state?}
- Now that we've seen how state variables are typically used, the
- question rises of what can be done with these state variables exactly?
- What limitations are there on their use to guarantee that proper \VHDL
- can be generated?
-
- We will try to formulate a number of rules about what operations are
- allowed with state variables. These rules apply to the normalized Core
- representation, but will in practice apply to the original Haskell
- hardware description as well. Ideally, these rules would become part
- of the intended normal form definition \refdef{intended normal form
- definition}, but this is not the case right now. This can cause some
- problems, which are detailed in
- \in{section}[sec:normalization:stateproblems].
-
- In these rules we use the terms state variable to refer to any
- variable that has a \lam{State} type. A state-containing variable is
- any variable whose type contains a \lam{State} type, but is not one
- itself (like \lam{(AccState, Word)} in the example, which is a tuple
- type, but contains \lam{AccState}, which is again equal to \lam{State
- Word}).
-
- We also use a distinction between input and output (state) variables,
- which will be defined in the rules themselves.
-
- \startdesc{State variables can appear as an argument.}
- \startlam
- λspacked. ...
- \stoplam
-
- Any lambda that binds a variable with a state type, creates a new
- input state variable.
- \stopdesc
-
- \startdesc{Input state variables can be unpacked.}
- \startlam
- s = spacked ▶ (AccState, Word)
- \stoplam
-
- An input state variable may be unpacked using a cast operation. This
- removes the \lam{State} type renaming and the result has no longer a
- \lam{State} type.
-
- If the result of this unpacking does not have a state type and does
- not contain state variables, there are no limitations on its use.
- Otherwise if it does not have a state type but does contain
- substates, we refer to it as a \emph{state-containing input
- variable} and the limitations below apply. If it has a state type
- itself, we refer to it as an \emph{input substate variable} and the
- below limitations apply as well.
-
- It may seem strange to consider a variable that still has a state
- type directly after unpacking, but consider the case where a
- function does not have any state of its own, but does call a single
- stateful function. This means it must have a state argument that
- contains just a substate. The function signature of such a function
- could look like:
-
- \starthaskell
- type FooState = State AccState
- \stophaskell
-
- Which is of course equivalent to \lam{State (State Word)}.
- \stopdesc
-
- \startdesc{Variables can be extracted from state-containing input variables.}
- \startlam
- accs = case s of (accs, _) -> accs
- \stoplam
-
- A state-containing input variable is typically a tuple containing
- multiple elements (like the current function's state, substates or
- more tuples containing substates). All of these can be extracted
- from an input variable using an extractor case (or possibly
- multiple, when the input variable is nested).
-
- If the result has no state type and does not contain any state
- variables either, there are no further limitations on its use. If
- the result has no state type but does contain state variables we
- refer to it as a \emph{state-containing input variable} and this
- limitation keeps applying. If the variable has a state type itself,
- we refer to it as an \emph{input substate variable} and below
- limitations apply.
-
- \startdesc{Input substate variables can be passed to functions.}
- \startlam
- accres = acc i accs
- accs' = case accres of (accs', _) -> accs'
- \stoplam
-
- An input substate variable can (only) be passed to a function.
- Additionally, every input substate variable must be used in exactly
- \emph{one} application, no more and no less.
-
- The function result should contain exactly one state variable, which
- can be extracted using (multiple) case statements. The extracted
- state variable is referred to the \emph{output substate}
-
- The type of this output substate must be identical to the type of
- the input substate passed to the function.
- \stopdesc
-
- \startdesc{Variables can be inserted into state-containing output variables.}
- \startlam
- s' = (accs', count')
- \stoplam
-
- A function's output state is usually a tuple containing its own
- updated state variables and all output substates. This result is
- built up using any single-constructor algebraic datatype.
-
- The result of these expressions is referred to as a
- \emph{state-containing output variable}, which are subject to these
- limitations.
- \stopdesc
-
- \startdesc{State containing output variables can be packed}
- As soon as all a functions own update state and output substate
- variables have been joined together, the va...
- todo{}
- spacked' = s' ▶ State (AccState, Word)
- \desc{State variables can appear as (part of) a function result.} When
- generating \small{VHDL}, we can completely ignore any part of a
- function result that has a state type. If the entire result is a state
- type, this will mean the entity will not have an output port.
- Otherwise, the state elements will be removed from the type of the
- output port.
-
- \subsection{Translating to \VHDL}
- \in{Example}[ex:AvgStateNormal] shows the normalized Core version of the
- same description (note that _ is a wild binder). \refdef{wild binder}
- The normal form is used to translated to \VHDL.
-
- As noted above, the basic approach when generating \VHDL for stateful
- functions is to generate a single register for every stateful function.
- We look around the normal form to find the let binding that removes the
- \lam{State} newtype (using a cast). We also find the let binding that
- adds a \lam{State} type. These are connected to the output and the input
- of the generated let binding respectively. This means that there can
- only be one let binding that adds and one that removes the \lam{State}
- type. It is easy to violate this constraint. This problem is detailed in
- \in{section}[sec:normalization:stateproblems].
-
- This approach seems simple enough, but will this also work for more
- complex stateful functions involving substates? Observe that any
- component of a function's state that is a substate, \ie passed on as
- the state of another function, should have no influence on the
- hardware generated for the calling function. Any state-specific
- \small{VHDL} for this component can be generated entirely within the
- called function. So, we can completely ignore substates when
- generating \VHDL for a function.
-
- From this observation, we might think to remove the substates from a
- function's states alltogether, and leave only the state components
- which are actual states of the current function. While doing this
- would not remove any information needed to generate \small{VHDL} from
- the function, it would cause the function definition to become invalid
- (since we won't have any substate to pass to the functions anymore).
- We could solve the syntactic problems by passing \type{undefined} for
- state variables, but that would still break the code on the semantic
- level (\ie, the function would no longer be semantically equivalent to
- the original input).
-
- To keep the function definition correct until the very end of the
- process, we will not deal with (sub)states until we get to the
- \small{VHDL} generation. Then, we are translating from Core to
- \small{VHDL}, and we can simply ignore substates, effectively removing
- the substate components alltogether.
-
- There are a few important points when ignoring substates.
-
- First, we have to have some definition of "substate". Since any state
- argument or return value that represents state must be of the
- \type{State} type, we can look at the type of a value. However, we
- must be careful to ignore only \emph{substates}, and not a function's
- own state.
-
- In \in{example}[ex:AvgStateNorm] above, we should generate a register
- connected with its output connected to \lam{s} and its input connected
- to \lam{s'}. However, \lam{s'} is build up from both \lam{accs'} and
- \lam{count'}, while only \lam{count'} should end up in the register.
- \lam{accs'} is a substate for the \lam{acc} function, for which a
- register will be created when generating \VHDL for the \lam{acc}
- function.
-
- Fortunately, the \lam{accs'} variable (and any other substate) has a
- property that we can easily check: It has a \lam{State} type
- annotation. This means that whenever \VHDL is generated for a tuple
- (or other algebraic type), we can simply leave out all elements that
- have a \lam{State} type. This will leave just the parts of the state
- that do not have a \lam{State} type themselves, like \lam{count'},
- which is exactly a function's own state. This approach also means that
- the state part of the result is automatically excluded when generating
- the output port, which is also required.
-
-
-
-
-
-
-
-
-
-
- Now, we know how to handle each use of a state variable separately. If we
- look at the whole, we can conclude the following:
-
- \startitemize
- \item A state unpack operation should not generate any \small{VHDL}.
- The binder to which the unpacked state is bound should still be
- declared, this signal will become the register and will hold the
- current state.
- \item A state pack operation should not generate any \small{VHDL}.
- The binder to which the packed state is bound should not be
- declared. The binder that is packed is the signal that will hold the
- new state.
- \item Any values of a State type should not be translated to
- \small{VHDL}. In particular, State elements should be removed from
- tuples (and other datatypes) and arguments with a state type should
- not generate ports.
- \item To make the state actually work, a simple \small{VHDL} proc
- should be generated. This proc updates the state at every
- clockcycle, by assigning the new state to the current state. This
- will be recognized by synthesis tools as a register specification.
- \stopitemize
-
- When applying these rules to the example program (in normal form), we will
- get the following result. All the parts that don't generate any value are
- crossed out, leaving some very boring assignments here and there.
-
-
+ \subsection[sec:prototype:statelimits]{State in normal form}
+ Before describing how to translate state from normal form to
+ \VHDL, we will first see how state handling looks in normal form.
+ What limitations are there on their use to guarantee that proper
+ \VHDL can be generated?
+
+ We will try to formulate a number of rules about what operations are
+ allowed with state variables. These rules apply to the normalized Core
+ representation, but will in practice apply to the original Haskell
+ hardware description as well. Ideally, these rules would become part
+ of the intended normal form definition \refdef{intended normal form
+ definition}, but this is not the case right now. This can cause some
+ problems, which are detailed in
+ \in{section}[sec:normalization:stateproblems].
+
+ In these rules we use the terms \emph{state variable} to refer to any
+ variable that has a \lam{State} type. A \emph{state-containing
+ variable} is any variable whose type contains a \lam{State} type,
+ but is not one itself (like \lam{(AccState, Word)} in the example,
+ which is a tuple type, but contains \lam{AccState}, which is again
+ equal to \lam{State Word}).
+
+ We also use a distinction between \emph{input} and \emph{output
+ (state) variables} and \emph{substate variables}, which will be
+ defined in the rules themselves.
+
+ \startdesc{State variables can appear as an argument.}
+ \startlambda
+ avg = λi.λspacked. ...
+ \stoplambda
+
+ Any lambda that binds a variable with a state type, creates a new
+ input state variable.
+ \stopdesc
+
+ \startdesc{Input state variables can be unpacked.}
+ \startlambda
+ s = spacked ▶ (AccState, Word)
+ \stoplambda
+
+ An input state variable may be unpacked using a cast operation. This
+ removes the \lam{State} type renaming and the result has no longer a
+ \lam{State} type.
+
+ If the result of this unpacking does not have a state type and does
+ not contain state variables, there are no limitations on its use.
+ Otherwise if it does not have a state type but does contain
+ substates, we refer to it as a \emph{state-containing input
+ variable} and the limitations below apply. If it has a state type
+ itself, we refer to it as an \emph{input substate variable} and the
+ below limitations apply as well.
+
+ It may seem strange to consider a variable that still has a state
+ type directly after unpacking, but consider the case where a
+ function does not have any state of its own, but does call a single
+ stateful function. This means it must have a state argument that
+ contains just a substate. The function signature of such a function
+ could look like:
+
\starthaskell
- avg i --spacked-- = res
- where
- s = --case spacked of (State s) -> s--
- --accums = case s of (accums, \_) -> accums--
- count = case s of (--\_,-- count) -> count
- accumres = accum i --accums--
- --accums' = case accumres of (accums', \_) -> accums'--
- sum = case accumres of (--\_,-- sum) -> sum
- count' = count + 1
- o = sum / count'
- s' = (--accums',-- count')
- --spacked' = State s'--
- res = (--spacked',-- o)
+ type FooState = State AccState
\stophaskell
-
- When we would really leave out the crossed out parts, we get a slightly
- weird program: There is a variable \type{s} which has no value, and there
- is a variable \type{s'} that is never used. Together, these two will form
- the state proc of the function. \type{s} contains the "current" state,
- \type{s'} is assigned the "next" state. So, at the end of each clock
- cycle, \type{s'} should be assigned to \type{s}.
-
- Note that the definition of \type{s'} is not removed, even though one
- might think it as having a state type. Since the state type has a single
- argument constructor \type{State}, some type that should be the resulting
- state should always be explicitly packed with the State constructor,
- allowing us to remove the packed version, but still generate \small{VHDL} for the
- unpacked version (of course with any substates removed).
+
+ Which is of course equivalent to \lam{State (State Word)}.
+ \stopdesc
+
+ \startdesc{Variables can be extracted from state-containing input variables.}
+ \startlambda
+ accs = case s of (accs, _) -> accs
+ \stoplambda
+
+ A state-containing input variable is typically a tuple containing
+ multiple elements (like the current function's state, substates or
+ more tuples containing substates). All of these can be extracted
+ from an input variable using an extractor case (or possibly
+ multiple, when the input variable is nested).
+
+ If the result has no state type and does not contain any state
+ variables either, there are no further limitations on its use. If
+ the result has no state type but does contain state variables we
+ refer to it as a \emph{state-containing input variable} and this
+ limitation keeps applying. If the variable has a state type itself,
+ we refer to it as an \emph{input substate variable} and below
+ limitations apply.
+
+ \startdesc{Input substate variables can be passed to functions.}
+ \startlambda
+ accres = acc i accs
+ accs' = case accres of (accs', _) -> accs'
+ \stoplambda
+
+ An input substate variable can (only) be passed to a function.
+ Additionally, every input substate variable must be used in exactly
+ \emph{one} application, no more and no less.
+
+ The function result should contain exactly one state variable, which
+ can be extracted using (multiple) case expressions. The extracted
+ state variable is referred to the \emph{output substate}
+
+ The type of this output substate must be identical to the type of
+ the input substate passed to the function.
+ \stopdesc
+
+ \startdesc{Variables can be inserted into a state-containing output variable.}
+ \startlambda
+ s' = (accs', count')
+ \stoplambda
- As you can see, the definition of \type{s'} is still present, since it
- does not have a state type (The State constructor. The \type{accums'} substate has been removed,
- leaving us just with the state of \type{avg} itself.
- \subsection{Initial state}
- How to specify the initial state? Cannot be done inside a hardware
- function, since the initial state is its own state argument for the first
- call (unless you add an explicit, synchronous reset port).
+ A function's output state is usually a tuple containing its own
+ updated state variables and all output substates. This result is
+ built up using any single-constructor algebraic datatype.
- External init state is natural for simulation.
+ The result of these expressions is referred to as a
+ \emph{state-containing output variable}, which are subject to these
+ limitations.
+ \stopdesc
- External init state works for hardware generation as well.
+ \startdesc{State containing output variables can be packed.}
+ \startlambda
+ spacked' = s' ▶ State (AccState, Word)
+ \stoplambda
- Implementation issues: state splitting, linking input to output state,
- checking usage constraints on state variables.
+ As soon as all a functions own update state and output substate
+ variables have been joined together, the resulting
+ state-containing output variable can be packed into an output
+ state variable. Packing is done by casting into a state type.
+ \stopdesc
- \todo{Implementation issues: Separate compilation, simplified core.}
+ \startdesc{Output state variables can appear as (part of) a function result.}
+ \startlambda
+ avg = λi.λspacked.
+ let
+ \vdots
+ res = (spacked', o)
+ in
+ res
+ \stoplambda
+ When the output state is packed, it can be returned as a part
+ of the function result. Nothing else can be done with this
+ value (or any value that contains it).
+ \stopdesc
+ There is one final limitation that is hard to express in the above
+ itemization. Whenever substates are extracted from the input state
+ to be passed to functions, the corresponding output substates
+ should be inserted into the output state in the same way. In other
+ words, each pair of corresponding substates in the input and
+ output states should be passed / returned from the same called
+ function.
+
+ The prototype currently does not check much of the above
+ conditions. This means that if the conditions are violated,
+ sometimes a compile error is generated, but in other cases output
+ can be generated that is not valid \VHDL or at the very least does
+ not correspond to the input.
+
+ \subsection{Translating to \VHDL}
+ As noted above, the basic approach when generating \VHDL for stateful
+ functions is to generate a single register for every stateful function.
+ We look around the normal form to find the let binding that removes the
+ \lam{State} newtype (using a cast). We also find the let binding that
+ adds a \lam{State} type. These are connected to the output and the input
+ of the generated let binding respectively. This means that there can
+ only be one let binding that adds and one that removes the \lam{State}
+ type. It is easy to violate this constraint. This problem is detailed in
+ \in{section}[sec:normalization:stateproblems].
+
+ This approach seems simple enough, but will this also work for more
+ complex stateful functions involving substates? Observe that any
+ component of a function's state that is a substate, \ie passed on as
+ the state of another function, should have no influence on the
+ hardware generated for the calling function. Any state-specific
+ \small{VHDL} for this component can be generated entirely within the
+ called function. So, we can completely ignore substates when
+ generating \VHDL for a function.
+
+ From this observation, we might think to remove the substates from a
+ function's states alltogether, and leave only the state components
+ which are actual states of the current function. While doing this
+ would not remove any information needed to generate \small{VHDL} from
+ the function, it would cause the function definition to become invalid
+ (since we won't have any substate to pass to the functions anymore).
+ We could solve the syntactic problems by passing \type{undefined} for
+ state variables, but that would still break the code on the semantic
+ level (\ie, the function would no longer be semantically equivalent to
+ the original input).
+
+ To keep the function definition correct until the very end of the
+ process, we will not deal with (sub)states until we get to the
+ \small{VHDL} generation. Then, we are translating from Core to
+ \small{VHDL}, and we can simply ignore substates, effectively removing
+ the substate components alltogether.
+
+ But, how will we know what exactly is a substate? Since any state
+ argument or return value that represents state must be of the
+ \type{State} type, we can look at the type of a value. However, we
+ must be careful to ignore only \emph{substates}, and not a
+ function's own state.
+
+ In \in{example}[ex:AvgStateNorm] above, we should generate a register
+ connected with its output connected to \lam{s} and its input connected
+ to \lam{s'}. However, \lam{s'} is build up from both \lam{accs'} and
+ \lam{count'}, while only \lam{count'} should end up in the register.
+ \lam{accs'} is a substate for the \lam{acc} function, for which a
+ register will be created when generating \VHDL for the \lam{acc}
+ function.
+
+ Fortunately, the \lam{accs'} variable (and any other substate) has a
+ property that we can easily check: It has a \lam{State} type
+ annotation. This means that whenever \VHDL is generated for a tuple
+ (or other algebraic type), we can simply leave out all elements that
+ have a \lam{State} type. This will leave just the parts of the state
+ that do not have a \lam{State} type themselves, like \lam{count'},
+ which is exactly a function's own state. This approach also means that
+ the state part of the result is automatically excluded when generating
+ the output port, which is also required.
+
+ We can formalize this translation a bit, using the following
+ rules.
+
+ \startitemize
+ \item A state unpack operation should not generate any \small{VHDL}.
+ The binder to which the unpacked state is bound should still be
+ declared, this signal will become the register and will hold the
+ current state.
+ \item A state pack operation should not generate any \small{VHDL}.
+ The binder to which the packed state is bound should not be
+ declared. The binder that is packed is the signal that will hold the
+ new state.
+ \item Any values of a State type should not be translated to
+ \small{VHDL}. In particular, State elements should be removed from
+ tuples (and other datatypes) and arguments with a state type should
+ not generate ports.
+ \item To make the state actually work, a simple \small{VHDL}
+ (sequential) process should be generated. This process updates
+ the state at every clockcycle, by assigning the new state to the
+ current state. This will be recognized by synthesis tools as a
+ register specification.
+ \stopitemize
+
+ When applying these rules to the description in
+ \in{example}[ex:AvgStateNormal], we be left with the description
+ in \in{example}[ex:AvgStateRemoved]. All the parts that don't
+ generate any \VHDL directly are crossed out, leaving just the
+ actual flow of values in the final hardware.
+
+ \startlambda
+ avg = iλ.λ--spacked.--
+ let
+ s = --spacked ▶ (AccState, Word)--
+ --accs = case s of (accs, _) -> accs--
+ count = case s of (--_,-- count) -> count
+ accres = acc i --accs--
+ --accs' = case accres of (accs', _) -> accs'--
+ sum = case accres of (--_,-- sum) -> sum
+ count' = count + 1
+ o = sum / count'
+ s' = (--accs',-- count')
+ --spacked' = s' ▶ State (AccState, Word)--
+ res = (--spacked',-- o)
+ in
+ res
+ \stoplambda
+
+ When we would really leave out the crossed out parts, we get a slightly
+ weird program: There is a variable \lam{s} which has no value, and there
+ is a variable \lam{s'} that is never used. Together, these two will form
+ the state process of the function. \lam{s} contains the "current" state,
+ \lam{s'} is assigned the "next" state. So, at the end of each clock
+ cycle, \lam{s'} should be assigned to \lam{s}.
+
+ As you can see, the definition of \lam{s'} is still present, since
+ it does not have a state type. The \lam{accums'} substate has been
+ removed, leaving us just with the state of \lam{avg} itself.
+
+ As an illustration of the result of this function,
+ \in{example}[ex:AccStateVHDL] and \in{example}[ex:AvgStateVHDL] show the the \VHDL that is
+ generated from the examples is this section.
+
+ \startbuffer[AvgStateVHDL]
+ entity avgComponent_0 is
+ port (\izAlE2\ : in \unsigned_31\;
+ \foozAo1zAo12\ : out \(,)unsigned_31\;
+ clock : in std_logic;
+ resetn : in std_logic);
+ end entity avgComponent_0;
+
+
+ architecture structural of avgComponent_0 is
+ signal \szAlG2\ : \(,)unsigned_31\;
+ signal \countzAlW2\ : \unsigned_31\;
+ signal \dszAm62\ : \(,)unsigned_31\;
+ signal \sumzAmk3\ : \unsigned_31\;
+ signal \reszAnCzAnM2\ : \unsigned_31\;
+ signal \foozAnZzAnZ2\ : \unsigned_31\;
+ signal \reszAnfzAnj3\ : \unsigned_31\;
+ signal \s'zAmC2\ : \(,)unsigned_31\;
+ begin
+ \countzAlW2\ <= \szAlG2\.A;
+
+ \comp_ins_dszAm62\ : entity accComponent_1
+ port map (\izAob3\ => \izAlE2\,
+ \foozAoBzAoB2\ => \dszAm62\,
+ clock => clock,
+ resetn => resetn);
+
+ \sumzAmk3\ <= \dszAm62\.A;
+
+ \reszAnCzAnM2\ <= to_unsigned(1, 32);
+
+ \foozAnZzAnZ2\ <= \countzAlW2\ + \reszAnCzAnM2\;
+
+ \reszAnfzAnj3\ <= \sumzAmk3\ * \foozAnZzAnZ2\;
+
+ \s'zAmC2\.A <= \foozAnZzAnZ2\;
+
+ \foozAo1zAo12\.A <= \reszAnfzAnj3\;
+
+ state : process (clock, resetn)
+ begin
+ if resetn = '0' then
+ elseif rising_edge(clock) then
+ \szAlG2\ <= \s'zAmC2\;
+ end if;
+ end process state;
+ end architecture structural;
+ \stopbuffer
+ \startbuffer[AccStateVHDL]
+ entity accComponent_1 is
+ port (\izAob3\ : in \unsigned_31\;
+ \foozAoBzAoB2\ : out \(,)unsigned_31\;
+ clock : in std_logic;
+ resetn : in std_logic);
+ end entity accComponent_1;
+
+
+ architecture structural of accComponent_1 is
+ signal \szAod3\ : \unsigned_31\;
+ signal \reszAonzAor3\ : \unsigned_31\;
+ begin
+ \reszAonzAor3\ <= \szAod3\ + \izAob3\;
+
+ \foozAoBzAoB2\.A <= \reszAonzAor3\;
+
+ state : process (clock, resetn)
+ begin
+ if resetn = '0' then
+ elseif rising_edge(clock) then
+ \szAod3\ <= \reszAonzAor3\;
+ end if;
+ end process state;
+ end architecture structural;
+ \stopbuffer
+
+ \placeexample[][ex:AccStateVHDL]{\VHDL generated for acc from \in{example}[ex:AvgState]}
+ {\typebuffer[AccStateVHDL]}
+ \placeexample[][ex:AvgStateVHDL]{\VHDL generated for avg from \in{example}[ex:AvgState]}
+ {\typebuffer[AvgStateVHDL]}
+% \subsection{Initial state}
+% How to specify the initial state? Cannot be done inside a hardware
+% function, since the initial state is its own state argument for the first
+% call (unless you add an explicit, synchronous reset port).
+%
+% External init state is natural for simulation.
+%
+% External init state works for hardware generation as well.
+%
+% Implementation issues: state splitting, linking input to output state,
+% checking usage constraints on state variables.
+%
+% \todo{Implementation issues: Separate compilation, simplified core.}
+%
% vim: set sw=2 sts=2 expandtab:
projects / matthijs / master-project / report.git / blobdiff