1 \chapter[chap:prototype]{Prototype}
2 An important step in this research is the creation of a prototype compiler.
3 Having this prototype allows us to apply the ideas from the previous chapter
4 to actual hardware descriptions and evaluate their usefulness. Having a
5 prototype also helps to find new techniques and test possible
8 Obviously the prototype was not created after all research
9 ideas were formed, but its implementation has been interleaved with the
10 research itself. Also, the prototype described here is the final version, it
11 has gone through a number of design iterations which we will not completely
14 \section[sec:prototype:input]{Input language}
15 When implementing this prototype, the first question to ask is: What
16 (functional) language will we use to describe our hardware? (Note that
17 this does not concern the \emph{implementation language} of the compiler,
18 just the language \emph{translated by} the compiler).
20 On the highest level, we have two choices:
23 \item Create a new functional language from scratch. This has the
24 advantage of having a language that contains exactly those elements that
25 are convenient for describing hardware and can contain special
26 constructs that might.
27 \item Use an existing language and create a new backend for it. This has
28 the advantage that existing tools can be reused, which will speed up
32 Considering that we required a prototype which should be working quickly,
33 and that implementing parsers, semantic checkers and especially
34 typcheckers isn't exactly the core of this research (but it is lots and
35 lots of work!), using an existing language is the obvious choice. This
36 also has the advantage that a large set of language features is available
37 to experiment with and it is easy to find which features apply well and
38 which don't. A possible second prototype could use a custom language with
39 just the useful features (and possibly extra features that are specific to
40 the domain of hardware description as well).
42 The second choice is to pick one of the many existing languages. As
43 mentioned before, this language is Haskell. This choice has not been the
44 result of a thorough comparison of languages, for the simple reason that
45 the requirements on the language were completely unclear at the start of
46 this language. The fact that Haskell is a language with a broad spectrum
47 of features, that it is commonly used in research projects and that the
48 primary compiler, GHC, provides a high level API to its internals, made
49 Haskell an obvious choice.
51 TODO: Was Haskell really a good choice? Perhaps say this somewhere else?
53 \section[sec:prototype:output]{Output format}
54 The second important question is: What will be our output format? Since
55 our prototype won't be able to program FPGA's directly, we'll have to have
56 output our hardware in some format that can be later processed and
57 programmed by other tools.
59 Looking at other tools in the industry, the Electronic Design Interchange
60 Format (\small{EDIF}) is commonly used for storing intermediate
61 \emph{netlists} (lists of components and connections between these
62 components) and is commonly the target for \small{VHDL} and Verilog
65 However, \small{EDIF} is not completely tool-independent. It specifies a
66 meta-format, but the hardware components that can be used vary between
67 various tool and hardware vendors, as well as the interpretation of the
68 \small{EDIF} standard (TODO Is this still true? Reference:
69 http://delivery.acm.org/10.1145/80000/74534/p803-li.pdf?key1=74534\&key2=8370537521\&coll=GUIDE\&dl=GUIDE\&CFID=61207158\&CFTOKEN=61908473).
71 This means that when working with EDIF, our prototype would become
72 technology dependent (\eg only work with \small{FPGA}s of a specific
73 vendor, or even only with specific chips). This limits the applicability
74 of our prototype. Also, the tools we'd like to use for verifying,
75 simulating and draw pretty pictures of our output (like Precision, or
76 QuestaSim) work on \small{VHDL} or Verilog input (TODO: Is this really
79 For these reasons, we will use \small{VHDL} as our output language.
80 Verilog is not used simply because we are familiar with \small{VHDL}
81 already. The differences between \small{VHDL} and Verilog are on the
82 higher level, while we will be using \small{VHDL} mainly to write low
83 level, netlist-like descriptions anyway.
85 An added advantage of using VHDL is that we can profit from existing
86 optimizations in VHDL synthesizers. A lot of optimizations are done on the
87 VHDL level by existing tools. These tools have years of experience in this
88 field, so it would not be reasonable to assume we could achieve a similar
89 amount of optimization in our prototype (nor should it be a goal,
90 considering this is just a prototype).
92 Note that we will be using \small{VHDL} as our output language, but will
93 not use its full expressive power. Our output will be limited to using
94 simple, structural descriptions, without any behavioural descriptions
95 (which might not be supported by all tools).
97 \section{Prototype design}
98 As stated above, we will use the Glasgow Haskell Compiler (\small{GHC}) to
99 implement our prototype compiler. To understand the design of the
100 compiler, we will first dive into the \small{GHC} compiler a bit. It's
101 compilation consists of the following steps (slightly simplified):
103 \startuseMPgraphic{ghc-pipeline}
105 save inp, front, desugar, simpl, back, out;
106 newEmptyBox.inp(0,0);
107 newBox.front(btex Parser etex);
108 newBox.desugar(btex Desugarer etex);
109 newBox.simpl(btex Simplifier etex);
110 newBox.back(btex Backend etex);
111 newEmptyBox.out(0,0);
113 % Space the boxes evenly
114 inp.c - front.c = front.c - desugar.c = desugar.c - simpl.c
115 = simpl.c - back.c = back.c - out.c = (0, 1.5cm);
118 % Draw lines between the boxes. We make these lines "deferred" and give
119 % them a name, so we can use ObjLabel to draw a label beside them.
120 ncline.inp(inp)(front) "name(haskell)";
121 ncline.front(front)(desugar) "name(ast)";
122 ncline.desugar(desugar)(simpl) "name(core)";
123 ncline.simpl(simpl)(back) "name(simplcore)";
124 ncline.back(back)(out) "name(native)";
125 ObjLabel.inp(btex Haskell source etex) "labpathname(haskell)", "labdir(rt)";
126 ObjLabel.front(btex Haskell AST etex) "labpathname(ast)", "labdir(rt)";
127 ObjLabel.desugar(btex Core etex) "labpathname(core)", "labdir(rt)";
128 ObjLabel.simpl(btex Simplified core etex) "labpathname(simplcore)", "labdir(rt)";
129 ObjLabel.back(btex Native code etex) "labpathname(native)", "labdir(rt)";
131 % Draw the objects (and deferred labels)
132 drawObj (inp, front, desugar, simpl, back, out);
134 \placefigure[right]{GHC compiler pipeline}{\useMPgraphic{ghc-pipeline}}
137 This step takes the Haskell source files and parses them into an
138 abstract syntax tree (\small{AST}). This \small{AST} can express the
139 complete Haskell language and is thus a very complex one (in contrast
140 with the Core \small{AST}, later on). All identifiers in this
141 \small{AST} are resolved by the renamer and all types are checked by the
144 \startdesc{Desugaring}
145 This steps takes the full \small{AST} and translates it to the
146 \emph{Core} language. Core is a very small functional language with lazy
147 semantics, that can still express everything Haskell can express. Its
148 simpleness makes Core very suitable for further simplification and
149 translation. Core is the language we will be working on as well.
151 \startdesc{Simplification}
152 Through a number of simplification steps (such as inlining, common
153 subexpression elimination, etc.) the Core program is simplified to make
154 it faster or easier to process further.
157 This step takes the simplified Core program and generates an actual
158 runnable program for it. This is a big and complicated step we will not
159 discuss it any further, since it is not required for our prototype.
162 In this process, there a number of places where we can start our work.
163 Assuming that we don't want to deal with (or modify) parsing, typechecking
164 and other frontend business and that native code isn't really a useful
165 format anymore, we are left with the choice between the full Haskell
166 \small{AST}, or the smaller (simplified) core representation.
168 The advantage of taking the full \small{AST} is that the exact structure
169 of the source program is preserved. We can see exactly what the hardware
170 descriiption looks like and which syntax constructs were used. However,
171 the full \small{AST} is a very complicated datastructure. If we are to
172 handle everything it offers, we will quickly get a big compiler.
174 Using the core representation gives us a much more compact datastructure
175 (a core expression only uses 9 constructors). Note that this does not mean
176 that the core representation itself is smaller, on the contrary. Since the
177 core language has less constructs, a lot of things will take a larger
178 expression to express.
180 However, the fact that the core language is so much smaller, means it is a
181 lot easier to analyze and translate it into something else. For the same
182 reason, \small{GHC} runs its simplifications and optimizations on the core
183 representation as well.
185 However, we will use the normal core representation, not the simplified
186 core. Reasons for this are detailed below.
188 The final prototype roughly consists of three steps:
190 \startuseMPgraphic{ghc-pipeline}
192 save inp, front, norm, vhdl, out;
193 newEmptyBox.inp(0,0);
194 newBox.front(btex \small{GHC} frontend + desugarer etex);
195 newBox.norm(btex Normalization etex);
196 newBox.vhdl(btex \small{VHDL} generation etex);
197 newEmptyBox.out(0,0);
199 % Space the boxes evenly
200 inp.c - front.c = front.c - norm.c = norm.c - vhdl.c
201 = vhdl.c - out.c = (0, 1.5cm);
204 % Draw lines between the boxes. We make these lines "deferred" and give
205 % them a name, so we can use ObjLabel to draw a label beside them.
206 ncline.inp(inp)(front) "name(haskell)";
207 ncline.front(front)(norm) "name(core)";
208 ncline.norm(norm)(vhdl) "name(normal)";
209 ncline.vhdl(vhdl)(out) "name(vhdl)";
210 ObjLabel.inp(btex Haskell source etex) "labpathname(haskell)", "labdir(rt)";
211 ObjLabel.front(btex Core etex) "labpathname(core)", "labdir(rt)";
212 ObjLabel.norm(btex Normalized core etex) "labpathname(normal)", "labdir(rt)";
213 ObjLabel.vhdl(btex \small{VHDL} description etex) "labpathname(vhdl)", "labdir(rt)";
215 % Draw the objects (and deferred labels)
216 drawObj (inp, front, norm, vhdl, out);
218 \placefigure[right]{GHC compiler pipeline}{\useMPgraphic{ghc-pipeline}}
221 This is exactly the frontend and desugarer from the \small{GHC}
222 pipeline, that translates Haskell sources to a core representation.
224 \startdesc{Normalization}
225 This is a step that transforms the core representation into a normal
226 form. This normal form is still expressed in the core language, but has
227 to adhere to an extra set of constraints. This normal form is less
228 expressive than the full core language (e.g., it can have limited higher
229 order expressions, has a specific structure, etc.), but is also very
230 close to directly describing hardware.
232 \startdesc{\small{VHDL} generation}
233 The last step takes the normal formed core representation and generates
234 \small{VHDL} for it. Since the normal form has a specific, hardware-like
235 structure, this final step is very straightforward.
238 The most interesting step in this process is the normalization step. That
239 is where more complicated functional constructs, which have no direct
240 hardware interpretation, are removed and translated into hardware
241 constructs. This step is described in a lot of detail at
242 \in{chapter}[chap:normalization].
244 \section{The Core language}
245 Most of the prototype deals with handling the program in the Core
246 language. In this section we will show what this language looks like and
249 The Core language is a functional language that describes
250 \emph{expressions}. Every identifier used in Core is called a
251 \emph{binder}, since it is bound to a value somewhere. On the highest
252 level, a Core program is a collection of functions, each of which bind a
253 binder (the function name) to an expression (the function value, which has
256 The Core language itself does not prescribe any program structure, only
257 expression structure. In the \small{GHC} compiler, the Haskell module
258 structure is used for the resulting Core code as well. Since this is not
259 so relevant for understanding the Core language or the Normalization
260 process, we'll only look at the Core expression language here.
262 Each Core expression consists of one of these possible expressions.
264 \startdesc{Variable reference}
268 This is a simple reference to a binder. It's written down as the
269 name of the binder that is being referred to, which should of course be
270 bound in a containing scope (including top level scope, so a reference
271 to a top level function is also a variable reference). Additionally,
272 constructors from algebraic datatypes also become variable references.
274 The value of this expression is the value bound to the given binder.
276 Each binder also carries around its type, but this is usually not shown
277 in the Core expressions. Occasionally, the type of an entire expression
278 or function is shown for clarity, but this is only informational. In
279 practice, the type of an expression is easily determined from the
280 structure of the expression and the types of the binders and occasional
281 cast expressions. This minimize the amount of bookkeeping needed to keep
282 the typing consistent.
289 This is a simple literal. Only primitive types are supported, like
290 chars, strings, ints and doubles. The types of these literals are the
291 \quote{primitive} versions, like \lam{Char\#} and \lam{Word\#}, not the
292 normal Haskell versions (but there are builtin conversion functions).
295 \startdesc{Application}
299 This is simple function application. Each application consists of two
300 parts: The function part and the argument part. Applications are used
301 for normal function \quote{calls}, but also for applying type
302 abstractions and data constructors.
304 The value of an application is the value of the function part, with the
305 first argument binder bound to the argument part.
308 \startdesc{Lambda abstraction}
312 This is the basic lambda abstraction, as it occurs in labmda calculus.
313 It consists of a binder part and a body part. A lambda abstraction
314 creates a function, that can be applied to an argument. The binder is
315 usually a value binder, but it can also be a \emph{type binder} (or
316 \emph{type variable}). The latter case introduces a new polymorphic
317 variable, which can be used in types later on. See
318 \in{section}[sec:prototype:coretypes] for details.
320 Note that the body of a lambda abstraction extends all the way to the
321 end of the expression, or the closing bracket surrounding the lambda. In
322 other words, the lambda abstraction \quote{operator} has the lowest
325 The value of an application is the value of the body part, with the
326 binder bound to the value the entire lambda abstraction is applied to.
329 \startdesc{Non-recursive let expression}
331 let bndr = value in body
333 A let expression allows you to bind a binder to some value, while
334 evaluating to some other value (where that binder is in scope). This
335 allows for sharing of subexpressions (you can use a binder twice) and
336 explicit \quote{naming} of arbitrary expressions. Note that the binder
337 is not in scope in the value bound to it, so it's not possible to make
338 recursive definitions with the normal form of the let expression (see
339 the recursive form below).
341 Even though this let expression is an extension on the basic lambda
342 calculus, it is easily translated to a lambda abstraction. The let
343 expression above would then become:
349 This notion might be useful for verifying certain properties on
350 transformations, since a lot of verification work has been done on
351 lambda calculus already.
353 The value of a let expression is the value of the body part, with the
354 binder bound to the value.
357 \startdesc{Recursive let expression}
366 This is the recursive version of the let expression. In \small{GHC}'s
367 Core implementation, non-recursive and recursive lets are not so
368 distinct as we present them here, but this provides a clearer overview.
370 The main difference with the normal let expression is that each of the
371 binders is in scope in each of the values, in addition to the body. This
372 allows for self-recursive definitions or mutually recursive definitions.
374 It should also be possible to express a recursive let using normal
375 lambda calculus, if we use the \emph{least fixed-point operator},
379 \startdesc{Case expression}
382 DEFAULT -> defaultbody
383 C0 bndr0,0 ... bndr0,m -> body0
385 Cn bndrn,0 ... bndrn,m -> bodyn
390 A case expression is the only way in Core to choose between values. A case
391 expression evaluates its scrutinee, which should have an algebraic
392 datatype, into weak head normal form (\small{WHNF}) and (optionally) binds
393 it to \lam{bndr}. It then chooses a body depending on the constructor of
394 its scrutinee. If none of the constructors match, the \lam{DEFAULT}
395 alternative is chosen.
397 Since we can only match the top level constructor, there can be no overlap
398 in the alternatives and thus order of alternatives is not relevant (though
399 the \lam{DEFAULT} alternative must appear first for implementation
402 Any arguments to the constructor in the scrutinee are bound to each of the
403 binders after the constructor and are in scope only in the corresponding
406 To support strictness, the scrutinee is always evaluated into WHNF, even
407 when there is only a \lam{DEFAULT} alternative. This allows a strict
408 function argument to be written like:
411 function (case argument of arg
415 This seems to be the only use for the extra binder to which the scrutinee
416 is bound. When not using strictness annotations (which is rather pointless
417 in hardware descriptions), \small{GHC} seems to never generate any code
418 making use of this binder. The current prototype does not handle it
419 either, which probably means that code using it would break.
421 Note that these case statements are less powerful than the full Haskell
422 case statements. In particular, they do not support complex patterns like
423 in Haskell. Only the constructor of an expression can be matched, complex
424 patterns are implemented using multiple nested case expressions.
426 Case statements are also used for unpacking of algebraic datatypes, even
427 when there is only a single constructor. For examples, to add the elements
428 of a tuple, the following Core is generated:
431 sum = λtuple.case tuple of
435 Here, there is only a single alternative (but no \lam{DEFAULT}
436 alternative, since the single alternative is already exhaustive). When
437 it's body is evaluated, the arguments to the tuple constructor \lam{(,)}
438 (\eg, the elements of the tuple) are bound to \lam{a} and \lam{b}.
441 \startdesc{Cast expression}
445 A cast expression allows you to change the type of an expression to an
446 equivalent type. Note that this is not meant to do any actual work, like
447 conversion of data from one format to another, or force a complete type
448 change. Instead, it is meant to change between different representations
449 of the same type, \eg switch between types that are provably equal (but
452 In our hardware descriptions, we typically see casts to change between a
453 Haskell newtype and its contained type, since those are effectively
454 different representations of the same type.
456 More complex are types that are proven to be equal by the typechecker,
457 but look different at first glance. To ensure that, once the typechecker
458 has proven equality, this information sticks around, explicit casts are
459 added. In our notation we only write the target type, but in reality a
460 cast expressions carries around a \emph{coercion}, which can be seen as a
461 proof of equality. TODO: Example
463 The value of a cast is the value of its body, unchanged. The type of this
464 value is equal to the target type, not the type of its body.
466 Note that this syntax is also used sometimes to indicate that a particular
467 expression has a particular type, even when no cast expression is
468 involved. This is then purely informational, since the only elements that
469 are explicitely typed in the Core language are the binder references and
470 cast expressions, the types of all other elements are determined at
476 The Core language in \small{GHC} allows adding \emph{notes}, which serve
477 as hints to the inliner or add custom (string) annotations to a core
478 expression. These shouldn't be generated normally, so these are not
479 handled in any way in the prototype.
486 It is possibly to use a Core type as a Core expression. This is done to
487 allow for type abstractions and applications to be handled as normal
488 lambda abstractions and applications above. This means that a type
489 expression in Core can only ever occur in the argument position of an
490 application, and only if the type of the function that is applied to
491 expects a type as the first argument. This happens for all polymorphic
492 functions, for example, the \lam{fst} function:
495 fst :: \forall a. \forall b. (a, b) -> a
496 fst = λtup.case tup of (,) a b -> a
498 fstint :: (Int, Int) -> Int
499 fstint = λa.λb.fst @Int @Int a b
502 The type of \lam{fst} has two universally quantified type variables. When
503 \lam{fst} is applied in \lam{fstint}, it is first applied to two types.
504 (which are substitued for \lam{a} and \lam{b} in the type of \lam{fst}, so
505 the type of \lam{fst} actual type of arguments and result can be found:
506 \lam{fst @Int @Int :: (Int, Int) -> Int}).
509 \subsection{Core type system}
510 Whereas the expression syntax of Core is very simple, its type system is
511 a bit more complicated. It turns out it is harder to \quote{desugar}
512 Haskell's complex type system into something more simple. Most of the
513 type system is thus very similar to that of Haskell.
515 We will slightly limit our view on Core's type system, since the more
516 complicated parts of it are only meant to support Haskell's (or rather,
517 \GHC's) type extensions, such as existential types, type families and
518 other non-standard Haskell stuff which we don't (plan to) support.
520 In Core, every expression is typed. The translation to Core happens
521 after the typechecker, so types in Core are always correct as well
522 (though you could of course construct invalidly typed expressions).
524 Any type in core is one of the following:
526 \startdesc{A type variable}
531 This is a reference to a type defined elsewhere. This can either be a
532 polymorphic type (like \hs{a} in \hs{id :: a -> a}), or a type
533 constructor (like \hs{Bool} in \hs{null :: [a] -> Bool}).
535 A special case of a type constructor is the \emph{function type
536 constructor}, \hs{->}. This is a type constructor taking two arguments
537 (using application below). The function type constructor is commonly
538 written inline, so we write \hs{a -> b} when we really mean \hs{-> a
539 b}, the function type constructor applied to a and b.
541 Polymorphic type variables can only be defined by a lambda
542 abstraction, see the forall type below.
545 \startdesc{A type application}
550 This applies a some type to another type. This is particularly used to
551 apply type variables (type constructors) to their arguments.
553 As mentioned above, some type applications have special notation. In
554 particular, these are applications of the \emph{function type
555 constructor} and \emph{tuple type constructors}:
564 \startdesc{The forall type}
566 id :: \forall a . a -> a
568 The forall type introduces polymorphism. It is the only way to
569 introduce new type variables, which are completely unconstrained (Any
570 possible type can be assigned to it). Constraints can be added later
571 using predicate types, see below.
573 A forall type is always (and only) introduced by a type lambda
574 expression. For example, the Core translation of the
580 here, type type of the binder \lam{x} is \lam{a}, referring to the
581 binder in the topmost lambda.
583 When using a value with a forall type, the actual type
584 used must be applied first. For example haskell expression \hs{id
585 True} translates to the following Core:
591 Here, id is first applied to the type to work with. Note that the type
592 then changes from \lam{id :: \forall a . a -> a} to \lam{id @Bool ::
593 Bool -> Bool}. Note that the type variable \lam{a} has been
594 substituted with the actual type.
597 \startdesc{Predicate type}
599 show :: \forall a. Show s => s -> String
602 TODO: Introduce type classes?
604 A predicate type introduces a constraint on a type variable introduced
605 by a forall type (or type lambda). In the example above, the type
606 variable \lam{a} can only contain types that are an \emph{instance} of
607 the \emph{type class} \lam{Show}.
609 There are other sorts of predicate types, used for the type families
610 extension, which we will not discuss here.
612 A predicate type is introduced by a lambda abstraction. Unlike with
613 the forall type, this is a value lambda abstraction, that must be
614 applied to a value. We call this value a \emph{dictionary}.
616 Without going into the implementation details, a dictionary can be
617 seen as a lookup table all the methods for a given (single) type class
618 instance. This means that all the dictionaries for the same type class
619 look the same (\eg contain methods with the same names). However,
620 dictionaries for different instances of the same class contain
621 different methods, of course.
623 A dictionary is introduced by \small{GHC} whenever it encounters an
624 instance declaration. This dictionary, as well as the binder
625 introduced by a lambda that introduces a dictionary, have the
626 predicate type as their type. These binders are usually named starting
627 with a \lam{\$}. Usually the name of the type concerned is not
628 reflected in the name of the dictionary, but the name of the type
629 class is. The Haskell expression \hs{show True} thus becomes:
632 show @Bool $dShow True
636 Using this set of types, all types in basic Haskell can be represented.
638 \section[sec:prototype:statetype]{State annotations in Haskell}
639 TODO: This section should be reviewed and expanded.
641 Ideal: Type synonyms, since there is no additional code overhead for
642 packing and unpacking. Downside: there is no explicit conversion in Core
643 either, so type synonyms tend to get lost in expressions (they can be
644 preserved in binders, but this makes implementation harder, since that
645 statefulness of a value must be manually tracked).
647 Less ideal: Newtype. Requires explicit packing and unpacking of function
648 arguments. If you don't unpack substates, there is no overhead for
649 (un)packing substates. This will result in many nested State constructors
650 in a nested state type. \eg:
653 State (State Bit, State (State Word, Bit), Word)
656 Alternative: Provide different newtypes for input and output state. This
657 makes the code even more explicit, and typechecking can find even more
658 errors. However, this requires defining two type synomyms for each
659 stateful function instead of just one. \eg:
662 type AccumStateIn = StateIn Bit
663 type AccumStateOut = StateOut Bit
666 This also increases the possibility of having different input and output
667 states. Checking for identical input and output state types is also
668 harder, since each element in the state must be unpacked and compared
671 Alternative: Provide a type for the entire result type of a stateful
672 function, not just the state part. \eg:
675 newtype Result state result = Result (state, result)
678 This makes it easy to say "Any stateful function must return a
679 \type{Result} type, without having to sort out result from state. However,
680 this either requires a second type for input state (similar to
681 \type{StateIn} / \type{StateOut} above), or requires the compiler to
682 select the right argument for input state by looking at types (which works
683 for complex states, but when that state has the same type as an argument,
684 things get ambiguous) or by selecting a fixed (\eg, the last) argument,
685 which might be limiting.
687 \subsubsection{Example}
688 As an example of the used approach, a simple averaging circuit, that lets
689 the accumulation of the inputs be done by a subcomponent.
692 newtype State s = State s
694 type AccumState = State Bit
695 accum :: Word -> AccumState -> (AccumState, Word)
696 accum i (State s) = (State (s + i), s + i)
698 type AvgState = (AccumState, Word)
699 avg :: Word -> AvgState -> (AvgState, Word)
700 avg i (State s) = (State s', o)
703 -- Pass our input through the accumulator, which outputs a sum
704 (accums', sum) = accum i accums
705 -- Increment the count (which will be our new state)
707 -- Compute the average
709 s' = (accums', count')
712 And the normalized, core-like versions:
715 accum i spacked = res
717 s = case spacked of (State s) -> s
725 s = case spacked of (State s) -> s
726 accums = case s of (accums, \_) -> accums
727 count = case s of (\_, count) -> count
728 accumres = accum i accums
729 accums' = case accumres of (accums', \_) -> accums'
730 sum = case accumres of (\_, sum) -> sum
733 s' = (accums', count')
740 As noted above, any component of a function's state that is a substate,
741 \eg passed on as the state of another function, should have no influence
742 on the hardware generated for the calling function. Any state-specific
743 \small{VHDL} for this component can be generated entirely within the called
744 function. So,we can completely leave out substates from any function.
746 From this observation, we might think to remove the substates from a
747 function's states alltogether, and leave only the state components which
748 are actual states of the current function. While doing this would not
749 remove any information needed to generate \small{VHDL} from the function, it would
750 cause the function definition to become invalid (since we won't have any
751 substate to pass to the functions anymore). We could solve the syntactic
752 problems by passing \type{undefined} for state variables, but that would
753 still break the code on the semantic level (\ie, the function would no
754 longer be semantically equivalent to the original input).
756 To keep the function definition correct until the very end of the process,
757 we will not deal with (sub)states until we get to the \small{VHDL} generation.
758 Here, we are translating from Core to \small{VHDL}, and we can simply not generate
759 \small{VHDL} for substates, effectively removing the substate components
762 There are a few important points when ignore substates.
764 First, we have to have some definition of "substate". Since any state
765 argument or return value that represents state must be of the \type{State}
766 type, we can simply look at its type. However, we must be careful to
767 ignore only {\em substates}, and not a function's own state.
769 In the example above, this means we should remove \type{accums'} from
770 \type{s'}, but not throw away \type{s'} entirely. We should, however,
771 remove \type{s'} from the output port of the function, since the state
772 will be handled by a \small{VHDL} procedure within the function.
774 When looking at substates, these can appear in two places: As part of an
775 argument and as part of a return value. As noted above, these substates
776 can only be used in very specific ways.
778 \desc{State variables can appear as an argument.} When generating \small{VHDL}, we
779 completely ignore the argument and generate no input port for it.
781 \desc{State variables can be extracted from other state variables.} When
782 extracting a state variable from another state variable, this always means
783 we're extracting a substate, which we can ignore. So, we simply generate no
784 \small{VHDL} for any extraction operation that has a state variable as a result.
786 \desc{State variables can be passed to functions.} When passing a
787 state variable to a function, this always means we're passing a substate
788 to a subcomponent. The entire argument can simply be ingored in the
791 \desc{State variables can be returned from functions.} When returning a
792 state variable from a function (probably as a part of an algebraic
793 datatype), this always mean we're returning a substate from a
794 subcomponent. The entire state variable should be ignored in the resulting
795 port map. The type binder of the binder that the function call is bound
796 to should not include the state type either.
798 \startdesc{State variables can be inserted into other variables.} When inserting
799 a state variable into another variable (usually by constructing that new
800 variable using its constructor), we can identify two cases:
803 \item The state is inserted into another state variable. In this case,
804 the inserted state is a substate, and can be safely left out of the
805 constructed variable.
806 \item The state is inserted into a non-state variable. This happens when
807 building up the return value of a function, where you put state and
808 retsult variables together in an algebraic type (usually a tuple). In
809 this case, we should leave the state variable out as well, since we
810 don't want it to be included as an output port.
813 So, in both cases, we can simply leave out the state variable from the
814 resulting value. In the latter case, however, we should generate a state
815 proc instead, which assigns the state variable to the input state variable
819 \desc{State variables can appear as (part of) a function result.} When
820 generating \small{VHDL}, we can completely ignore any part of a function result
821 that has a state type. If the entire result is a state type, this will
822 mean the entity will not have an output port. Otherwise, the state
823 elements will be removed from the type of the output port.
826 Now, we know how to handle each use of a state variable separately. If we
827 look at the whole, we can conclude the following:
830 \item A state unpack operation should not generate any \small{VHDL}. The binder
831 to which the unpacked state is bound should still be declared, this signal
832 will become the register and will hold the current state.
833 \item A state pack operation should not generate any \small{VHDL}. The binder th
834 which the packed state is bound should not be declared. The binder that is
835 packed is the signal that will hold the new state.
836 \item Any values of a State type should not be translated to \small{VHDL}. In
837 particular, State elements should be removed from tuples (and other
838 datatypes) and arguments with a state type should not generate ports.
839 \item To make the state actually work, a simple \small{VHDL} proc should be
840 generated. This proc updates the state at every clockcycle, by assigning
841 the new state to the current state. This will be recognized by synthesis
842 tools as a register specification.
846 When applying these rules to the example program (in normal form), we will
847 get the following result. All the parts that don't generate any value are
848 crossed out, leaving some very boring assignments here and there.
852 avg i --spacked-- = res
854 s = --case spacked of (State s) -> s--
855 --accums = case s of (accums, \_) -> accums--
856 count = case s of (--\_,-- count) -> count
857 accumres = accum i --accums--
858 --accums' = case accumres of (accums', \_) -> accums'--
859 sum = case accumres of (--\_,-- sum) -> sum
862 s' = (--accums',-- count')
863 --spacked' = State s'--
864 res = (--spacked',-- o)
867 When we would really leave out the crossed out parts, we get a slightly
868 weird program: There is a variable \type{s} which has no value, and there
869 is a variable \type{s'} that is never used. Together, these two will form
870 the state proc of the function. \type{s} contains the "current" state,
871 \type{s'} is assigned the "next" state. So, at the end of each clock
872 cycle, \type{s'} should be assigned to \type{s}.
874 Note that the definition of \type{s'} is not removed, even though one
875 might think it as having a state type. Since the state type has a single
876 argument constructor \type{State}, some type that should be the resulting
877 state should always be explicitly packed with the State constructor,
878 allowing us to remove the packed version, but still generate \small{VHDL} for the
879 unpacked version (of course with any substates removed).
881 As you can see, the definition of \type{s'} is still present, since it
882 does not have a state type (The State constructor. The \type{accums'} substate has been removed,
883 leaving us just with the state of \type{avg} itself.
884 \subsection{Initial state}
885 How to specify the initial state? Cannot be done inside a hardware
886 function, since the initial state is its own state argument for the first
887 call (unless you add an explicit, synchronous reset port).
889 External init state is natural for simulation.
891 External init state works for hardware generation as well.
893 Implementation issues: state splitting, linking input to output state,
894 checking usage constraints on state variables.
896 TODO: Implementation issues
897 TODO: \subsection[sec:prototype:separate]{Separate compilation}
898 TODO: Simplified core?