describe here.
\section[sec:prototype:input]{Input language}
- When implementing this prototype, the first question to ask is: What
- (functional) language will we use to describe our hardware? (Note that
- this does not concern the \emph{implementation language} of the compiler,
- just the language \emph{translated by} the compiler).
+ When implementing this prototype, the first question to ask is:
+ Which (functional) language will be used to describe our hardware?
+ (Note that this does not concern the \emph{implementation language}
+ of the compiler, just the language \emph{translated by} the
+ compiler).
Initially, we have two choices:
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
+ approaches have not been included. As we have seen in
\in{section}[sec:context:fhdls], these approaches have all kinds
of limitations on the description language that we would like to
avoid.
lots of work!), using an existing language is the obvious choice. This
also has the advantage that a large set of language features is available
to experiment with and it is easy to find which features apply well and
- which don't. A possible second prototype could use a custom language with
- just the useful features (and possibly extra features that are specific to
+ which do not. Another import advantage of using an existing language, is
+ that simulation of the code becomes trivial. Since there are existing
+ compilers and interpreters that can run the hardware description directly,
+ it can be simulated without also having to write an interpreter for the
+ new language.
+
+ A possible second prototype could use a custom language with just the useful
+ features (and possibly extra features that are specific to
the domain of hardware description as well).
- The second choice is which of the many existing languages to use. As
+ The second choice to be made is which of the many existing languages to use. As
mentioned before, the chosen language is Haskell. This choice has not been the
result of a thorough comparison of languages, for the simple reason that
the requirements on the language were completely unclear at the start of
Haskell an obvious choice.
\section[sec:prototype:output]{Output format}
- The second important question is: What will be our output format? Since
- our prototype won't be able to program FPGA's directly, we'll have to have
- output our hardware in some format that can be later processed and
- programmed by other tools.
+ The second important question is: what will be our output format?
+ This output format should at least allow for programming the
+ hardware design into a field-programmable gate array (\small{FPGA}).
+ The choice of output format is thus limited by what hardware
+ synthesis and programming tools can process.
Looking at other tools in the industry, the Electronic Design Interchange
Format (\small{EDIF}) is commonly used for storing intermediate
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
+ technology dependent (\eg\ only work with \small{FPGA}s of a specific
vendor, or even only with specific chips). This limits the applicability
- of our prototype. Also, the tools we'd like to use for verifying,
+ of our prototype. Also, the tools we would like to use for verifying,
simulating and draw pretty pictures of our output (like Precision, or
QuestaSim) are designed for \small{VHDL} or Verilog input.
For these reasons, we will not use \small{EDIF}, but \small{VHDL} as our
- output language. We choose \VHDL over Verilog simply because we are
+ output language. We choose \VHDL\ over Verilog simply because we are
familiar with \small{VHDL} already. The differences between \small{VHDL}
and Verilog are on the higher level, while we will be using \small{VHDL}
mainly to write low level, netlist-like descriptions anyway.
An added advantage of using VHDL is that we can profit from existing
optimizations in VHDL synthesizers. A lot of optimizations are done on the
- VHDL level by existing tools. These tools have years of experience in this
- field, so it would not be reasonable to assume we could achieve a similar
- amount of optimization in our prototype (nor should it be a goal,
- considering this is just a prototype).
+ VHDL level by existing tools. These tools have been under
+ development for years, so it would not be reasonable to assume we
+ could achieve a similar amount of optimization in our prototype (nor
+ should it be a goal, considering this is just a prototype).
+
+ \placeintermezzo{}{
+ \startframedtext[width=8cm,background=box,frame=no]
+ \startalignment[center]
+ {\tfa Translation vs. compilation vs. synthesis}
+ \stopalignment
+ \blank[medium]
+ In this thesis the words \emph{translation}, \emph{compilation} and
+ sometimes \emph{synthesis} will be used interchangedly to refer to the
+ process of translating the hardware description from the Haskell
+ language to the \VHDL\ language.
+
+ Similarly, the prototype created is referred to as both the
+ \emph{translator} as well as the \emph{compiler}.
+
+ The final part of this process is usually referred to as \emph{\VHDL\
+ generation}.
+ \stopframedtext
+ }
Note that we will be using \small{VHDL} as our output language, but will
not use its full expressive power. Our output will be limited to using
- simple, structural descriptions, without any behavioural descriptions
- (which might not be supported by all tools). This ensures that any tool
- that works with \VHDL will understand our output (most tools don't support
- synthesis of more complex \VHDL). This also leaves open the option to
- switch to \small{EDIF} in the future, with minimal changes to the
+ simple, structural descriptions, without any complex behavioural
+ descriptions like arbitrary sequential statements (which might not
+ be supported by all tools). This ensures that any tool that works
+ with \VHDL\ will understand our output (most tools do not support
+ synthesis of more complex \VHDL). This also leaves open the option
+ to switch to \small{EDIF} in the future, with minimal changes to the
prototype.
+ \section{Simulation and synthesis}
+ As mentioned above, by using the Haskell language, we get simulation of
+ our hardware descriptions almost for free. The only thing that is needed
+ is to provide a Haskell implementation of all built-in functions that can
+ be used by the Haskell interpreter to simulate them.
+
+ The main topic of this thesis is therefore the path from the Haskell
+ hardware descriptions to \small{FPGA} synthesis, focusing of course on the
+ \VHDL\ generation. Since the \VHDL\ generation process preserves the meaning
+ of the Haskell description exactly, any simulation done in Haskell
+ \emph{should} produce identical results as the synthesized hardware.
+
\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
+ compiler, we will first dive into the \small{GHC} compiler a bit. Its
compilation consists of the following steps (slightly simplified):
\startuseMPgraphic{ghc-pipeline}
% Create objects
save inp, front, desugar, simpl, back, out;
newEmptyBox.inp(0,0);
- newBox.front(btex Fronted etex);
+ newBox.front(btex Frontend etex);
newBox.desugar(btex Desugarer etex);
newBox.simpl(btex Simplifier etex);
newBox.back(btex Backend etex);
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.
- 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
+ In this process, there are a number of places where we can start our work.
+ Assuming that we do not want to deal with (or modify) parsing, typechecking
+ and other frontend business and that native code is not really a useful
format anymore, we are left with the choice between the full Haskell
\small{AST}, or the smaller (simplified) core representation.
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.
Using the core representation gives us a much more compact datastructure
(a core expression only uses 9 constructors). Note that this does not mean
- that the core representation itself is smaller, on the contrary. Since the
- core language has less constructs, a lot of things will take a larger
- expression to express.
+ that the core representation itself is smaller, on the contrary.
+ Since the core language has less constructs, most Core expressions
+ are larger than the equivalent versions in Haskell.
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.
-
- However, we will use the normal core representation, not the simplified
- core. Reasons for this are detailed below. \todo{Ref}
+ representation as well \cite[jones96].
+
+ We will use the normal Core representation, not the simplified Core. Even
+ though the simplified Core version is an equivalent, but simpler
+ definition, some problems were encountered with it in practice. The
+ simplifier restructures some (stateful) functions in a way the normalizer
+ and the \VHDL\ generation cannot handle, leading to uncompilable programs
+ (whereas the non-simplified version more closely resembles the original
+ program, allowing the original to be written in a way that can be
+ handled). This problem is further discussed in
+ \in{section}[sec:normalization:stateproblems].
The final prototype roughly consists of three steps:
% Create objects
save inp, front, norm, vhdl, out;
newEmptyBox.inp(0,0);
- newBox.front(btex \small{GHC} frontend + desugarer etex);
+ newBox.front(btex \small{GHC} frontend etex);
newBox.norm(btex Normalization etex);
newBox.vhdl(btex \small{VHDL} generation etex);
newEmptyBox.out(0,0);
\placefigure[right]{Cλash compiler pipeline}{\useMPgraphic{clash-pipeline}}
\startdesc{Frontend}
- This is exactly the frontend and desugarer from the \small{GHC}
- pipeline, that translates Haskell sources to a core representation.
+ This is exactly the frontend from the \small{GHC} pipeline, that
+ translates Haskell sources to a typed Core representation.
\stopdesc
\startdesc{Normalization}
This is a step that transforms the core representation into a normal
form. This normal form is still expressed in the core language, but has
- to adhere to an extra set of constraints. This normal form is less
- expressive than the full core language (e.g., it can have limited higher
- order expressions, has a specific structure, etc.), but is also very
- close to directly describing hardware.
+ to adhere to an additional set of constraints. This normal form is less
+ expressive than the full core language (e.g., it can have limited
+ higher-order expressions, has a specific structure, etc.), but is
+ also very close to directly describing hardware.
\stopdesc
\startdesc{\small{VHDL} generation}
The last step takes the normal formed core representation and generates
hardware interpretation, are removed and translated into hardware
constructs. This step is described in a lot of detail at
\in{chapter}[chap:normalization].
+
- \section{The Core language}
+ \defref{entry function}Translation of a hardware description always
+ starts at a single function, which is referred to as the \emph{entry
+ function}. \VHDL\ is generated for this function first, followed by
+ any functions used by the entry functions (recursively).
+
+ \section[sec:prototype:core]{The Core language}
\defreftxt{core}{the Core language}
Most of the prototype deals with handling the program in the Core
language. In this section we will show what this language looks like and
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
- process, we'll only look at the Core expression language here.
+ 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 will 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
+ This is a reference to a binder. It is 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.
+
+ 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.
+ 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 built-in 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}
func arg
\stoplambda
This is function application. Each application consists of two
- parts: The function part and the argument part. Applications are used
+ parts: the function part and the argument part. Applications are used
for normal function \quote{calls}, but also for applying type
abstractions and data constructors.
+
+ In core, there is no distinction between an operator and a
+ function. This means that, for example the addition of two numbers
+ looks like the following in Core:
+ \startlambda
+ (+) 1 2
+ \stoplambda
+
+ Where the function \quote{\lam{(+)}} is applied to the numbers 1
+ and 2. However, to increase readability, an application of an
+ operator like \lam{(+)} is sometimes written infix. In this case,
+ the parenthesis are also left out, just like in Haskell. In other
+ words, the following means exactly the same as the addition above:
+
+ \startlambda
+ 1 + 2
+ \stoplambda
+
The value of an application is the value of the function part, with the
first argument binder bound to the argument part.
\stopdesc
\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 is 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
Core implementation, non-recursive and recursive lets are not so
distinct as we present them here, but this provides a clearer overview.
- The main difference with the normal let expression is that each of the
- binders is in scope in each of the values, in addition to the body. This
+ The main difference with the normal let expression is that it can
+ contain multiple bindings (or even none) and each of the 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}. If bndr is wild, \refdef{wild
+ binders} it is left out. 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}
f (case a of arg DEFAULT -> arg)
\stoplambda
- According to the \GHC documentation, this is the only use for the extra
+ According to the \GHC\ documentation, this is the only use for the extra
binder to which the scrutinee is bound. When not using strictness
annotations (which is rather pointless in hardware descriptions),
\small{GHC} seems to never generate any code making use of this binder.
- In fact, \GHC has never been observed to generate code using this
+ In fact, \GHC\ has never been observed to generate code using this
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:
Here, there is only a single alternative (but no \lam{DEFAULT}
alternative, since the single alternative is already exhaustive). When
- it's body is evaluated, the arguments to the tuple constructor \lam{(,)}
+ its body is evaluated, the arguments to the tuple constructor \lam{(,)}
(\eg, the elements of the tuple) are bound to \lam{a} and \lam{b}.
\stopdesc
equivalent type. Note that this is not meant to do any actual work, like
conversion of data from one format to another, or force a complete type
change. Instead, it is meant to change between different representations
- of the same type, \eg switch between types that are provably equal (but
+ of the same type, \eg\ switch between types that are provably equal (but
look different).
In our hardware descriptions, we typically see casts to change between a
The value of a cast is the value of its body, unchanged. The type of this
value is equal to the target type, not the type of its body.
-
- \todo{Move and update this paragraph}
- Note that this syntax is also used sometimes to indicate that a particular
- expression has a particular type, even when no cast expression is
- involved. This is then purely informational, since the only elements that
- are explicitely typed in the Core language are the binder references and
- cast expressions, the types of all other elements are determined at
- runtime.
\stopdesc
\startdesc{Note}
The Core language in \small{GHC} allows adding \emph{notes}, which serve
as hints to the inliner or add custom (string) annotations to a core
- expression. These shouldn't be generated normally, so these are not
+ expression. These should not be generated normally, so these are not
handled in any way in the prototype.
\stopdesc
\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 in applications of all
+ polymorphic functions. Consider 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
We will slightly limit our view on Core's type system, since the more
complicated parts of it are only meant to support Haskell's (or rather,
\GHC's) type extensions, such as existential types, \small{GADT}s, type
- families and other non-standard Haskell stuff which we don't (plan to)
+ families and other non-standard Haskell stuff which we do not (plan to)
support.
+ \placeintermezzo{}{
+ \startframedtext[width=8cm,background=box,frame=no]
+ \startalignment[center]
+ {\tfa The \hs{id} function}
+ \stopalignment
+ \blank[medium]
+ A function that is probably present in every functional language, is
+ the \emph{identity} function. This is the function that takes a
+ single argument and simply returns it unmodified. In Haskell this
+ function is called \hs{id} and can take an argument of any type
+ (\ie, it is polymorphic).
+
+ The \hs{id} function will be used in the examples every now and
+ then.
+ \stopframedtext
+ }
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
- used must be applied first. For example haskell expression \hs{id
+ used must be applied first. For example Haskell expression \hs{id
True} (the function \hs{id} appleid to the dataconstructor \hs{True})
translates to the following Core:
\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
Without going into the implementation details, a dictionary can be
seen as a lookup table all the methods for a given (single) type class
instance. This means that all the dictionaries for the same type class
- look the same (\eg contain methods with the same names). However,
+ look the same (\eg\ contain methods with the same names). However,
dictionaries for different instances of the same class contain
different methods, of course.
Word} and \hs{Word} types by pattern matching and by using the explicit
the \hs{State constructor}.
- This explicit conversion makes the \VHDL generation easier: Whenever we
+ This explicit conversion makes the \VHDL\ generation easier: whenever we
remove (unpack) the \hs{State} type, this means we are accessing the
current state (\eg, accessing the register output). Whenever we are a
adding (packing) the \hs{State} type, we are producing a new value for
\subsubsection{Different input and output types}
An alternative could be to use different types for input and output
- state (\ie current and updated state). The accumulator example would
+ state (\ie\ current and updated state). The accumulator example would
then become something like:
\starthaskell
\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.\footnote{Currently, the prototype
- is not able to compile this example, since the builtin function
+ is not able to compile this example, since the built-in function
for division has not been added.}
\startbuffer[AvgState]
\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.
+ we have 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
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?
+ \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
\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
+ 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 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
+ 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
+ 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
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
+ 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.
+ 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).
+ From this observation it might seem logical to remove the
+ substates from a function's states altogether 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 will not 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.
+ the substate components altogether.
But, how will we know what exactly is a substate? Since any state
argument or return value that represents state must be of the
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}
+ 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
+ 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'},
\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.
+ \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
+ in \in{example}[ex:AvgStateRemoved]. All the parts that do not
+ generate any \VHDL\ directly are crossed out, leaving just the
actual flow of values in the final hardware.
\startlambda
- avg = iλ.--λspacked.--
+ avg = iλ.λ--spacked.--
let
s = --spacked ▶ (AccState, Word)--
--accs = case s of (accs, _) -> accs--
\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
+ 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 proc of the function. \lam{s} contains the "current" state,
+ 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
+ In the example 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
+ \in{example}[ex:AccStateVHDL] and \in{example}[ex:AvgStateVHDL] show the the \VHDL\ that is
generated from the examples is this section.
\startbuffer[AvgStateVHDL]
end architecture structural;
\stopbuffer
- \placeexample[][ex:AccStateVHDL]{\VHDL generated for acc from \in{example}[ex:AvgState]}
+ \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]}
+ \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
% 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