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
+ which do not. 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).
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
This means that when working with \small{EDIF}, our prototype would become
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.
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).
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[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);
\stopdesc
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
+ 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.
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
% 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].
+
+
+ \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{The Core language}
+ \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
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.
+ process, we will only look at the Core expression language here.
Each Core expression consists of one of these possible expressions.
\startlambda
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
This is a literal. Only primitive types are supported, like
chars, strings, ints and doubles. The types of these literals are the
\quote{primitive}, unboxed versions, like \lam{Char\#} and \lam{Word\#}, not the
- normal Haskell versions (but there are builtin conversion
+ 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.
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
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. A binder is not
- in scope in the value bound it is bound to, so it's not possible
+ 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).
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 is also possible to express a recursive let expression using
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
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
+ are explicitly 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
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:
+ as the first argument. This happens in applications of all
+ polymorphic functions. Consider the \lam{fst} function:
\startlambda
fst :: \forall t1. \forall t2. (t1, t2) ->t1
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.
In Core, every expression is typed. The translation to Core happens
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:
\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
+ 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
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).
+ 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
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
+ 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.
\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.
projects / matthijs / master-project / report.git / blobdiff