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 Initially, 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 allows our hardware descriptions to be more powerful or
28 \item Use an existing language and create a new backend for it. This has
29 the advantage that existing tools can be reused, which will speed up
33 \todo{Sidenote: No EDSL}
35 Considering that we required a prototype which should be working quickly,
36 and that implementing parsers, semantic checkers and especially
37 typcheckers is not exactly the core of this research (but it is lots and
38 lots of work!), using an existing language is the obvious choice. This
39 also has the advantage that a large set of language features is available
40 to experiment with and it is easy to find which features apply well and
41 which don't. A possible second prototype could use a custom language with
42 just the useful features (and possibly extra features that are specific to
43 the domain of hardware description as well).
45 The second choice is which of the many existing languages to use. As
46 mentioned before, the chosen language is Haskell. This choice has not been the
47 result of a thorough comparison of languages, for the simple reason that
48 the requirements on the language were completely unclear at the start of
49 this research. The fact that Haskell is a language with a broad spectrum
50 of features, that it is commonly used in research projects and that the
51 primary compiler, \GHC, provides a high level API to its internals, made
52 Haskell an obvious choice.
54 \note{There should be evaluation of the choice of Haskell and \VHDL}
56 \section[sec:prototype:output]{Output format}
57 The second important question is: What will be our output format? Since
58 our prototype won't be able to program FPGA's directly, we'll have to have
59 output our hardware in some format that can be later processed and
60 programmed by other tools.
62 Looking at other tools in the industry, the Electronic Design Interchange
63 Format (\small{EDIF}) is commonly used for storing intermediate
64 \emph{netlists} (lists of components and connections between these
65 components) and is commonly the target for \small{VHDL} and Verilog
68 However, \small{EDIF} is not completely tool-independent. It specifies a
69 meta-format, but the hardware components that can be used vary between
70 various tool and hardware vendors, as well as the interpretation of the
71 \small{EDIF} standard. \todo{Is this still true? Reference:
72 http://delivery.acm.org/10.1145/80000/74534/p803-li.pdf?key1=74534\&key2=8370537521\&coll=GUIDE\&dl=GUIDE\&CFID=61207158\&CFTOKEN=61908473}
74 This means that when working with \small{EDIF}, our prototype would become
75 technology dependent (\eg only work with \small{FPGA}s of a specific
76 vendor, or even only with specific chips). This limits the applicability
77 of our prototype. Also, the tools we'd like to use for verifying,
78 simulating and draw pretty pictures of our output (like Precision, or
79 QuestaSim) are designed for \small{VHDL} or Verilog input.
81 For these reasons, we will not use \small{EDIF}, but \small{VHDL} as our
82 output language. We choose \VHDL over Verilog simply because we are
83 familiar with \small{VHDL} already. The differences between \small{VHDL}
84 and Verilog are on the higher level, while we will be using \small{VHDL}
85 mainly to write low level, netlist-like descriptions anyway.
87 An added advantage of using VHDL is that we can profit from existing
88 optimizations in VHDL synthesizers. A lot of optimizations are done on the
89 VHDL level by existing tools. These tools have years of experience in this
90 field, so it would not be reasonable to assume we could achieve a similar
91 amount of optimization in our prototype (nor should it be a goal,
92 considering this is just a prototype).
94 Note that we will be using \small{VHDL} as our output language, but will
95 not use its full expressive power. Our output will be limited to using
96 simple, structural descriptions, without any behavioural descriptions
97 (which might not be supported by all tools). This ensures that any tool
98 that works with \VHDL will understand our output (most tools don't support
99 synthesis of more complex \VHDL). This also leaves open the option to
100 switch to \small{EDIF} in the future, with minimal changes to the
103 \section{Prototype design}
104 As suggested above, we will use the Glasgow Haskell Compiler (\small{GHC}) to
105 implement our prototype compiler. To understand the design of the
106 compiler, we will first dive into the \small{GHC} compiler a bit. It's
107 compilation consists of the following steps (slightly simplified):
109 \startuseMPgraphic{ghc-pipeline}
111 save inp, front, desugar, simpl, back, out;
112 newEmptyBox.inp(0,0);
113 newBox.front(btex Fronted etex);
114 newBox.desugar(btex Desugarer etex);
115 newBox.simpl(btex Simplifier etex);
116 newBox.back(btex Backend etex);
117 newEmptyBox.out(0,0);
119 % Space the boxes evenly
120 inp.c - front.c = front.c - desugar.c = desugar.c - simpl.c
121 = simpl.c - back.c = back.c - out.c = (0, 1.5cm);
124 % Draw lines between the boxes. We make these lines "deferred" and give
125 % them a name, so we can use ObjLabel to draw a label beside them.
126 ncline.inp(inp)(front) "name(haskell)";
127 ncline.front(front)(desugar) "name(ast)";
128 ncline.desugar(desugar)(simpl) "name(core)";
129 ncline.simpl(simpl)(back) "name(simplcore)";
130 ncline.back(back)(out) "name(native)";
131 ObjLabel.inp(btex Haskell source etex) "labpathname(haskell)", "labdir(rt)";
132 ObjLabel.front(btex Haskell AST etex) "labpathname(ast)", "labdir(rt)";
133 ObjLabel.desugar(btex Core etex) "labpathname(core)", "labdir(rt)";
134 ObjLabel.simpl(btex Simplified core etex) "labpathname(simplcore)", "labdir(rt)";
135 ObjLabel.back(btex Native code etex) "labpathname(native)", "labdir(rt)";
137 % Draw the objects (and deferred labels)
138 drawObj (inp, front, desugar, simpl, back, out);
140 \placefigure[right]{GHC compiler pipeline}{\useMPgraphic{ghc-pipeline}}
143 This step takes the Haskell source files and parses them into an
144 abstract syntax tree (\small{AST}). This \small{AST} can express the
145 complete Haskell language and is thus a very complex one (in contrast
146 with the Core \small{AST}, later on). All identifiers in this
147 \small{AST} are resolved by the renamer and all types are checked by the
150 \startdesc{Desugaring}
151 This steps takes the full \small{AST} and translates it to the
152 \emph{Core} language. Core is a very small functional language with lazy
153 semantics, that can still express everything Haskell can express. Its
154 simpleness makes Core very suitable for further simplification and
155 translation. Core is the language we will be working with as well.
157 \startdesc{Simplification}
158 Through a number of simplification steps (such as inlining, common
159 subexpression elimination, etc.) the Core program is simplified to make
160 it faster or easier to process further.
163 This step takes the simplified Core program and generates an actual
164 runnable program for it. This is a big and complicated step we will not
165 discuss it any further, since it is not required for our prototype.
168 In this process, there a number of places where we can start our work.
169 Assuming that we don't want to deal with (or modify) parsing, typechecking
170 and other frontend business and that native code isn't really a useful
171 format anymore, we are left with the choice between the full Haskell
172 \small{AST}, or the smaller (simplified) core representation.
174 The advantage of taking the full \small{AST} is that the exact structure
175 of the source program is preserved. We can see exactly what the hardware
176 descriiption looks like and which syntax constructs were used. However,
177 the full \small{AST} is a very complicated datastructure. If we are to
178 handle everything it offers, we will quickly get a big compiler.
180 Using the core representation gives us a much more compact datastructure
181 (a core expression only uses 9 constructors). Note that this does not mean
182 that the core representation itself is smaller, on the contrary. Since the
183 core language has less constructs, a lot of things will take a larger
184 expression to express.
186 However, the fact that the core language is so much smaller, means it is a
187 lot easier to analyze and translate it into something else. For the same
188 reason, \small{GHC} runs its simplifications and optimizations on the core
189 representation as well.
191 However, we will use the normal core representation, not the simplified
192 core. Reasons for this are detailed below. \todo{Ref}
194 The final prototype roughly consists of three steps:
196 \startuseMPgraphic{clash-pipeline}
198 save inp, front, norm, vhdl, out;
199 newEmptyBox.inp(0,0);
200 newBox.front(btex \small{GHC} frontend + desugarer etex);
201 newBox.norm(btex Normalization etex);
202 newBox.vhdl(btex \small{VHDL} generation etex);
203 newEmptyBox.out(0,0);
205 % Space the boxes evenly
206 inp.c - front.c = front.c - norm.c = norm.c - vhdl.c
207 = vhdl.c - out.c = (0, 1.5cm);
210 % Draw lines between the boxes. We make these lines "deferred" and give
211 % them a name, so we can use ObjLabel to draw a label beside them.
212 ncline.inp(inp)(front) "name(haskell)";
213 ncline.front(front)(norm) "name(core)";
214 ncline.norm(norm)(vhdl) "name(normal)";
215 ncline.vhdl(vhdl)(out) "name(vhdl)";
216 ObjLabel.inp(btex Haskell source etex) "labpathname(haskell)", "labdir(rt)";
217 ObjLabel.front(btex Core etex) "labpathname(core)", "labdir(rt)";
218 ObjLabel.norm(btex Normalized core etex) "labpathname(normal)", "labdir(rt)";
219 ObjLabel.vhdl(btex \small{VHDL} description etex) "labpathname(vhdl)", "labdir(rt)";
221 % Draw the objects (and deferred labels)
222 drawObj (inp, front, norm, vhdl, out);
224 \placefigure[right]{Cλash compiler pipeline}{\useMPgraphic{clash-pipeline}}
227 This is exactly the frontend and desugarer from the \small{GHC}
228 pipeline, that translates Haskell sources to a core representation.
230 \startdesc{Normalization}
231 This is a step that transforms the core representation into a normal
232 form. This normal form is still expressed in the core language, but has
233 to adhere to an extra set of constraints. This normal form is less
234 expressive than the full core language (e.g., it can have limited higher
235 order expressions, has a specific structure, etc.), but is also very
236 close to directly describing hardware.
238 \startdesc{\small{VHDL} generation}
239 The last step takes the normal formed core representation and generates
240 \small{VHDL} for it. Since the normal form has a specific, hardware-like
241 structure, this final step is very straightforward.
244 The most interesting step in this process is the normalization step. That
245 is where more complicated functional constructs, which have no direct
246 hardware interpretation, are removed and translated into hardware
247 constructs. This step is described in a lot of detail at
248 \in{chapter}[chap:normalization].
250 \section{The Core language}
251 \defreftxt{core}{the Core language}
252 Most of the prototype deals with handling the program in the Core
253 language. In this section we will show what this language looks like and
256 The Core language is a functional language that describes
257 \emph{expressions}. Every identifier used in Core is called a
258 \emph{binder}, since it is bound to a value somewhere. On the highest
259 level, a Core program is a collection of functions, each of which bind a
260 binder (the function name) to an expression (the function value, which has
263 The Core language itself does not prescribe any program structure, only
264 expression structure. In the \small{GHC} compiler, the Haskell module
265 structure is used for the resulting Core code as well. Since this is not
266 so relevant for understanding the Core language or the Normalization
267 process, we'll only look at the Core expression language here.
269 Each Core expression consists of one of these possible expressions.
271 \startdesc{Variable reference}
272 \defref{variable reference}
276 This is a reference to a binder. It's written down as the
277 name of the binder that is being referred to, which should of course be
278 bound in a containing scope (including top level scope, so a reference
279 to a top level function is also a variable reference). Additionally,
280 constructors from algebraic datatypes also become variable references.
282 The value of this expression is the value bound to the given binder.
284 Each binder also carries around its type, but this is usually not shown
285 in the Core expressions. Occasionally, the type of an entire expression
286 or function is shown for clarity, but this is only informational. In
287 practice, the type of an expression is easily determined from the
288 structure of the expression and the types of the binders and occasional
289 cast expressions. This minimize the amount of bookkeeping needed to keep
290 the typing consistent.
298 This is a literal. Only primitive types are supported, like
299 chars, strings, ints and doubles. The types of these literals are the
300 \quote{primitive} versions, like \lam{Char\#} and \lam{Word\#}, not the
301 normal Haskell versions (but there are builtin conversion functions).
304 \startdesc{Application}
309 This is function application. Each application consists of two
310 parts: The function part and the argument part. Applications are used
311 for normal function \quote{calls}, but also for applying type
312 abstractions and data constructors.
314 The value of an application is the value of the function part, with the
315 first argument binder bound to the argument part.
318 \startdesc{Lambda abstraction}
319 \defref{lambda abstraction}
323 This is the basic lambda abstraction, as it occurs in labmda calculus.
324 It consists of a binder part and a body part. A lambda abstraction
325 creates a function, that can be applied to an argument. The binder is
326 usually a value binder, but it can also be a \emph{type binder} (or
327 \emph{type variable}). The latter case introduces a new polymorphic
328 variable, which can be used in types later on. See
329 \in{section}[sec:prototype:coretypes] for details.
331 Note that the body of a lambda abstraction extends all the way to the
332 end of the expression, or the closing bracket surrounding the lambda. In
333 other words, the lambda abstraction \quote{operator} has the lowest
336 The value of an application is the value of the body part, with the
337 binder bound to the value the entire lambda abstraction is applied to.
340 \startdesc{Non-recursive let expression}
341 \defref{let expression}
343 let bndr = value in body
345 A let expression allows you to bind a binder to some value, while
346 evaluating to some other value (where that binder is in scope). This
347 allows for sharing of subexpressions (you can use a binder twice) and
348 explicit \quote{naming} of arbitrary expressions. Note that the binder
349 is not in scope in the value bound to it, so it's not possible to make
350 recursive definitions with the normal form of the let expression (see
351 the recursive form below).
353 Even though this let expression is an extension on the basic lambda
354 calculus, it is easily translated to a lambda abstraction. The let
355 expression above would then become:
361 This notion might be useful for verifying certain properties on
362 transformations, since a lot of verification work has been done on
363 lambda calculus already.
365 The value of a let expression is the value of the body part, with the
366 binder bound to the value.
369 \startdesc{Recursive let expression}
378 This is the recursive version of the let expression. In \small{GHC}'s
379 Core implementation, non-recursive and recursive lets are not so
380 distinct as we present them here, but this provides a clearer overview.
382 The main difference with the normal let expression is that each of the
383 binders is in scope in each of the values, in addition to the body. This
384 allows for self-recursive or mutually recursive definitions.
386 It should also be possible to express a recursive let using normal
387 lambda calculus, if we use the \emph{least fixed-point operator},
388 \lam{Y}. This falls beyond the scope of this report, since it is not
389 needed for this research.
392 \startdesc{Case expression}
393 \defref{case expression}
395 case scrutinee of bndr
396 DEFAULT -> defaultbody
397 C0 bndr0,0 ... bndr0,m -> body0
399 Cn bndrn,0 ... bndrn,m -> bodyn
404 A case expression is the only way in Core to choose between values. All
405 \hs{if} expressions and pattern matchings from the original Haskell
406 PRogram have been translated to case expressions by the desugarer.
408 A case expression evaluates its scrutinee, which should have an
409 algebraic datatype, into weak head normal form (\small{WHNF}) and
410 (optionally) binds it to \lam{bndr}. It then chooses a body depending on
411 the constructor of its scrutinee. If none of the constructors match, the
412 \lam{DEFAULT} alternative is chosen. A case expression must always be
413 exhaustive, \ie it must cover all possible constructors that the
414 scrutinee can have (if all of them are covered explicitly, the
415 \lam{DEFAULT} alternative can be left out).
417 Since we can only match the top level constructor, there can be no overlap
418 in the alternatives and thus order of alternatives is not relevant (though
419 the \lam{DEFAULT} alternative must appear first for implementation
422 Any arguments to the constructor in the scrutinee are bound to each of the
423 binders after the constructor and are in scope only in the corresponding
426 To support strictness, the scrutinee is always evaluated into
427 \small{WHNF}, even when there is only a \lam{DEFAULT} alternative. This
428 allows aplication of the strict function \lam{f} to the argument \lam{a}
432 f (case a of arg DEFAULT -> arg)
435 According to the \GHC documentation, this is the only use for the extra
436 binder to which the scrutinee is bound. When not using strictness
437 annotations (which is rather pointless in hardware descriptions),
438 \small{GHC} seems to never generate any code making use of this binder.
439 In fact, \GHC has never been observed to generate code using this
440 binder, even when strictness was involved. Nonetheless, the prototype
441 handles this binder as expected.
443 Note that these case statements are less powerful than the full Haskell
444 case statements. In particular, they do not support complex patterns like
445 in Haskell. Only the constructor of an expression can be matched,
446 complex patterns are implemented using multiple nested case expressions.
448 Case statements are also used for unpacking of algebraic datatypes, even
449 when there is only a single constructor. For examples, to add the elements
450 of a tuple, the following Core is generated:
453 sum = λtuple.case tuple of
457 Here, there is only a single alternative (but no \lam{DEFAULT}
458 alternative, since the single alternative is already exhaustive). When
459 it's body is evaluated, the arguments to the tuple constructor \lam{(,)}
460 (\eg, the elements of the tuple) are bound to \lam{a} and \lam{b}.
463 \startdesc{Cast expression}
464 \defref{cast expression}
468 A cast expression allows you to change the type of an expression to an
469 equivalent type. Note that this is not meant to do any actual work, like
470 conversion of data from one format to another, or force a complete type
471 change. Instead, it is meant to change between different representations
472 of the same type, \eg switch between types that are provably equal (but
475 In our hardware descriptions, we typically see casts to change between a
476 Haskell newtype and its contained type, since those are effectively
477 different types (so a cast is needed) with the same representation (but
478 no work is done by the cast).
480 More complex are types that are proven to be equal by the typechecker,
481 but look different at first glance. To ensure that, once the typechecker
482 has proven equality, this information sticks around, explicit casts are
483 added. In our notation we only write the target type, but in reality a
484 cast expressions carries around a \emph{coercion}, which can be seen as a
485 proof of equality. \todo{Example}
487 The value of a cast is the value of its body, unchanged. The type of this
488 value is equal to the target type, not the type of its body.
490 \todo{Move this paragraph}
491 Note that this syntax is also used sometimes to indicate that a particular
492 expression has a particular type, even when no cast expression is
493 involved. This is then purely informational, since the only elements that
494 are explicitely typed in the Core language are the binder references and
495 cast expressions, the types of all other elements are determined at
500 The Core language in \small{GHC} allows adding \emph{notes}, which serve
501 as hints to the inliner or add custom (string) annotations to a core
502 expression. These shouldn't be generated normally, so these are not
503 handled in any way in the prototype.
507 \defref{type expression}
511 It is possibly to use a Core type as a Core expression. For the actual
512 types supported by Core, see \in{section}[sec:prototype:coretypes]. This
513 \quote{lifting} of a type into the value domain is done to allow for
514 type abstractions and applications to be handled as normal lambda
515 abstractions and applications above. This means that a type expression
516 in Core can only ever occur in the argument position of an application,
517 and only if the type of the function that is applied to expects a type
518 as the first argument. This happens for all polymorphic functions, for
519 example, the \lam{fst} function:
522 fst :: \forall a. \forall b. (a, b) -> a
523 fst = λtup.case tup of (,) a b -> a
525 fstint :: (Int, Int) -> Int
526 fstint = λa.λb.fst @Int @Int a b
529 The type of \lam{fst} has two universally quantified type variables. When
530 \lam{fst} is applied in \lam{fstint}, it is first applied to two types.
531 (which are substitued for \lam{a} and \lam{b} in the type of \lam{fst}, so
532 the type of \lam{fst} actual type of arguments and result can be found:
533 \lam{fst @Int @Int :: (Int, Int) -> Int}).
536 \subsection[sec:prototype:coretypes]{Core type system}
537 Whereas the expression syntax of Core is very simple, its type system is
538 a bit more complicated. It turns out it is harder to \quote{desugar}
539 Haskell's complex type system into something more simple. Most of the
540 type system is thus very similar to that of Haskell.
542 We will slightly limit our view on Core's type system, since the more
543 complicated parts of it are only meant to support Haskell's (or rather,
544 \GHC's) type extensions, such as existential types, \small{GADT}s, type
545 families and other non-standard Haskell stuff which we don't (plan to)
548 In Core, every expression is typed. The translation to Core happens
549 after the typechecker, so types in Core are always correct as well
550 (though you could of course construct invalidly typed expressions).
552 Any type in core is one of the following:
554 \startdesc{A type variable}
559 This is a reference to a type defined elsewhere. This can either be a
560 polymorphic type (like the latter two \lam{t}'s in \lam{id :: \forall t.
561 t -> t}), or a type constructor (like \lam{Bool} in \lam{not :: Bool ->
562 Bool}). Like in Haskell, polymorphic type variables always
563 start with a lowercase letter, while type constructors always start
564 with an uppercase letter.
566 \todo{How to define (new) type constructors?}
568 A special case of a type constructor is the \emph{function type
569 constructor}, \lam{->}. This is a type constructor taking two arguments
570 (using application below). The function type constructor is commonly
571 written inline, so we write \lam{a -> b} when we really mean \lam{-> a
572 b}, the function type constructor applied to \lam{a} and \lam{b}.
574 Polymorphic type variables can only be defined by a lambda
575 abstraction, see the forall type below.
578 \startdesc{A type application}
583 This applies a some type to another type. This is particularly used to
584 apply type variables (type constructors) to their arguments.
586 As mentioned above, applications of some type constructors have
587 special notation. In particular, these are applications of the
588 \emph{function type constructor} and \emph{tuple type constructors}:
597 \startdesc{The forall type}
599 id :: \forall a. a -> a
601 The forall type introduces polymorphism. It is the only way to
602 introduce new type variables, which are completely unconstrained (Any
603 possible type can be assigned to it). Constraints can be added later
604 using predicate types, see below.
606 A forall type is always (and only) introduced by a type lambda
607 expression. For example, the Core translation of the
613 Here, the type of the binder \lam{x} is \lam{a}, referring to the
614 binder in the topmost lambda.
616 When using a value with a forall type, the actual type
617 used must be applied first. For example haskell expression \hs{id
618 True} (the function \hs{id} appleid to the dataconstructor \hs{True})
619 translates to the following Core:
625 Here, id is first applied to the type to work with. Note that the type
626 then changes from \lam{id :: \forall a. a -> a} to \lam{id @Bool ::
627 Bool -> Bool}. Note that the type variable \lam{a} has been
628 substituted with the actual type.
630 In Haskell, forall types are usually not explicitly specified (The use
631 of a lowercase type variable implicitly introduces a forall type for
632 that variable). In fact, in standard Haskell there is no way to
633 explicitly specify forall types. Through a language extension, the
634 \hs{forall} keyword is available, but still optional for normal forall
635 types (it is needed for \emph{existentially quantified types}, which
636 Cλash does not support).
639 \startdesc{Predicate type}
641 show :: \forall a. Show s ⇒ s → String
644 \todo{Sidenote: type classes?}
646 A predicate type introduces a constraint on a type variable introduced
647 by a forall type (or type lambda). In the example above, the type
648 variable \lam{a} can only contain types that are an \emph{instance} of
649 the \emph{type class} \lam{Show}. \refdef{type class}
651 There are other sorts of predicate types, used for the type families
652 extension, which we will not discuss here.
654 A predicate type is introduced by a lambda abstraction. Unlike with
655 the forall type, this is a value lambda abstraction, that must be
656 applied to a value. We call this value a \emph{dictionary}.
658 Without going into the implementation details, a dictionary can be
659 seen as a lookup table all the methods for a given (single) type class
660 instance. This means that all the dictionaries for the same type class
661 look the same (\eg contain methods with the same names). However,
662 dictionaries for different instances of the same class contain
663 different methods, of course.
665 A dictionary is introduced by \small{GHC} whenever it encounters an
666 instance declaration. This dictionary, as well as the binder
667 introduced by a lambda that introduces a dictionary, have the
668 predicate type as their type. These binders are usually named starting
669 with a \lam{$}. Usually the name of the type concerned is not
670 reflected in the name of the dictionary, but the name of the type
671 class is. The Haskell expression \hs{show True} thus becomes:
674 show @Bool $dShow True
678 Using this set of types, all types in basic Haskell can be represented.
680 \todo{Overview of polymorphism with more examples (or move examples
683 \section[sec:prototype:statetype]{State annotations in Haskell}
684 \fxnote{This entire section on state annotations should be reviewed}
686 Ideal: Type synonyms, since there is no additional code overhead for
687 packing and unpacking. Downside: there is no explicit conversion in Core
688 either, so type synonyms tend to get lost in expressions (they can be
689 preserved in binders, but this makes implementation harder, since that
690 statefulness of a value must be manually tracked).
692 Less ideal: Newtype. Requires explicit packing and unpacking of function
693 arguments. If you don't unpack substates, there is no overhead for
694 (un)packing substates. This will result in many nested State constructors
695 in a nested state type. \eg:
698 State (State Bit, State (State Word, Bit), Word)
701 Alternative: Provide different newtypes for input and output state. This
702 makes the code even more explicit, and typechecking can find even more
703 errors. However, this requires defining two type synomyms for each
704 stateful function instead of just one. \eg:
707 type AccumStateIn = StateIn Bit
708 type AccumStateOut = StateOut Bit
711 This also increases the possibility of having different input and output
712 states. Checking for identical input and output state types is also
713 harder, since each element in the state must be unpacked and compared
716 Alternative: Provide a type for the entire result type of a stateful
717 function, not just the state part. \eg:
720 newtype Result state result = Result (state, result)
723 This makes it easy to say "Any stateful function must return a
724 \type{Result} type, without having to sort out result from state. However,
725 this either requires a second type for input state (similar to
726 \type{StateIn} / \type{StateOut} above), or requires the compiler to
727 select the right argument for input state by looking at types (which works
728 for complex states, but when that state has the same type as an argument,
729 things get ambiguous) or by selecting a fixed (\eg, the last) argument,
730 which might be limiting.
732 \subsubsection{Example}
733 As an example of the used approach, a simple averaging circuit, that lets
734 the accumulation of the inputs be done by a subcomponent.
737 newtype State s = State s
739 type AccumState = State Bit
740 accum :: Word -> AccumState -> (AccumState, Word)
741 accum i (State s) = (State (s + i), s + i)
743 type AvgState = (AccumState, Word)
744 avg :: Word -> AvgState -> (AvgState, Word)
745 avg i (State s) = (State s', o)
748 -- Pass our input through the accumulator, which outputs a sum
749 (accums', sum) = accum i accums
750 -- Increment the count (which will be our new state)
752 -- Compute the average
754 s' = (accums', count')
757 And the normalized, core-like versions:
760 accum i spacked = res
762 s = case spacked of (State s) -> s
770 s = case spacked of (State s) -> s
771 accums = case s of (accums, \_) -> accums
772 count = case s of (\_, count) -> count
773 accumres = accum i accums
774 accums' = case accumres of (accums', \_) -> accums'
775 sum = case accumres of (\_, sum) -> sum
778 s' = (accums', count')
785 As noted above, any component of a function's state that is a substate,
786 \eg passed on as the state of another function, should have no influence
787 on the hardware generated for the calling function. Any state-specific
788 \small{VHDL} for this component can be generated entirely within the called
789 function. So,we can completely leave out substates from any function.
791 From this observation, we might think to remove the substates from a
792 function's states alltogether, and leave only the state components which
793 are actual states of the current function. While doing this would not
794 remove any information needed to generate \small{VHDL} from the function, it would
795 cause the function definition to become invalid (since we won't have any
796 substate to pass to the functions anymore). We could solve the syntactic
797 problems by passing \type{undefined} for state variables, but that would
798 still break the code on the semantic level (\ie, the function would no
799 longer be semantically equivalent to the original input).
801 To keep the function definition correct until the very end of the process,
802 we will not deal with (sub)states until we get to the \small{VHDL} generation.
803 Here, we are translating from Core to \small{VHDL}, and we can simply not generate
804 \small{VHDL} for substates, effectively removing the substate components
807 There are a few important points when ignore substates.
809 First, we have to have some definition of "substate". Since any state
810 argument or return value that represents state must be of the \type{State}
811 type, we can simply look at its type. However, we must be careful to
812 ignore only {\em substates}, and not a function's own state.
814 In the example above, this means we should remove \type{accums'} from
815 \type{s'}, but not throw away \type{s'} entirely. We should, however,
816 remove \type{s'} from the output port of the function, since the state
817 will be handled by a \small{VHDL} procedure within the function.
819 When looking at substates, these can appear in two places: As part of an
820 argument and as part of a return value. As noted above, these substates
821 can only be used in very specific ways.
823 \desc{State variables can appear as an argument.} When generating \small{VHDL}, we
824 completely ignore the argument and generate no input port for it.
826 \desc{State variables can be extracted from other state variables.} When
827 extracting a state variable from another state variable, this always means
828 we're extracting a substate, which we can ignore. So, we simply generate no
829 \small{VHDL} for any extraction operation that has a state variable as a result.
831 \desc{State variables can be passed to functions.} When passing a
832 state variable to a function, this always means we're passing a substate
833 to a subcomponent. The entire argument can simply be ingored in the
836 \desc{State variables can be returned from functions.} When returning a
837 state variable from a function (probably as a part of an algebraic
838 datatype), this always mean we're returning a substate from a
839 subcomponent. The entire state variable should be ignored in the resulting
840 port map. The type binder of the binder that the function call is bound
841 to should not include the state type either.
843 \startdesc{State variables can be inserted into other variables.} When inserting
844 a state variable into another variable (usually by constructing that new
845 variable using its constructor), we can identify two cases:
848 \item The state is inserted into another state variable. In this case,
849 the inserted state is a substate, and can be safely left out of the
850 constructed variable.
851 \item The state is inserted into a non-state variable. This happens when
852 building up the return value of a function, where you put state and
853 retsult variables together in an algebraic type (usually a tuple). In
854 this case, we should leave the state variable out as well, since we
855 don't want it to be included as an output port.
858 So, in both cases, we can simply leave out the state variable from the
859 resulting value. In the latter case, however, we should generate a state
860 proc instead, which assigns the state variable to the input state variable
864 \desc{State variables can appear as (part of) a function result.} When
865 generating \small{VHDL}, we can completely ignore any part of a function result
866 that has a state type. If the entire result is a state type, this will
867 mean the entity will not have an output port. Otherwise, the state
868 elements will be removed from the type of the output port.
871 Now, we know how to handle each use of a state variable separately. If we
872 look at the whole, we can conclude the following:
875 \item A state unpack operation should not generate any \small{VHDL}. The binder
876 to which the unpacked state is bound should still be declared, this signal
877 will become the register and will hold the current state.
878 \item A state pack operation should not generate any \small{VHDL}. The binder th
879 which the packed state is bound should not be declared. The binder that is
880 packed is the signal that will hold the new state.
881 \item Any values of a State type should not be translated to \small{VHDL}. In
882 particular, State elements should be removed from tuples (and other
883 datatypes) and arguments with a state type should not generate ports.
884 \item To make the state actually work, a simple \small{VHDL} proc should be
885 generated. This proc updates the state at every clockcycle, by assigning
886 the new state to the current state. This will be recognized by synthesis
887 tools as a register specification.
891 When applying these rules to the example program (in normal form), we will
892 get the following result. All the parts that don't generate any value are
893 crossed out, leaving some very boring assignments here and there.
897 avg i --spacked-- = res
899 s = --case spacked of (State s) -> s--
900 --accums = case s of (accums, \_) -> accums--
901 count = case s of (--\_,-- count) -> count
902 accumres = accum i --accums--
903 --accums' = case accumres of (accums', \_) -> accums'--
904 sum = case accumres of (--\_,-- sum) -> sum
907 s' = (--accums',-- count')
908 --spacked' = State s'--
909 res = (--spacked',-- o)
912 When we would really leave out the crossed out parts, we get a slightly
913 weird program: There is a variable \type{s} which has no value, and there
914 is a variable \type{s'} that is never used. Together, these two will form
915 the state proc of the function. \type{s} contains the "current" state,
916 \type{s'} is assigned the "next" state. So, at the end of each clock
917 cycle, \type{s'} should be assigned to \type{s}.
919 Note that the definition of \type{s'} is not removed, even though one
920 might think it as having a state type. Since the state type has a single
921 argument constructor \type{State}, some type that should be the resulting
922 state should always be explicitly packed with the State constructor,
923 allowing us to remove the packed version, but still generate \small{VHDL} for the
924 unpacked version (of course with any substates removed).
926 As you can see, the definition of \type{s'} is still present, since it
927 does not have a state type (The State constructor. The \type{accums'} substate has been removed,
928 leaving us just with the state of \type{avg} itself.
929 \subsection{Initial state}
930 How to specify the initial state? Cannot be done inside a hardware
931 function, since the initial state is its own state argument for the first
932 call (unless you add an explicit, synchronous reset port).
934 External init state is natural for simulation.
936 External init state works for hardware generation as well.
938 Implementation issues: state splitting, linking input to output state,
939 checking usage constraints on state variables.
941 \todo{Implementation issues: Separate compilation, simplified core.}