X-Git-Url: https://git.stderr.nl/gitweb?p=matthijs%2Fmaster-project%2Freport.git;a=blobdiff_plain;f=Chapters%2FPrototype.tex;h=101594bf2a9b4aaacbd210c1242fd968ed0f2fa7;hp=7677cde8a990aac96276880179b00083002bf10d;hb=05ab912a6a0d53892521265750b313126ab442af;hpb=df932c64420a4fff15ecf19f5eaada664db701e7 diff --git a/Chapters/Prototype.tex b/Chapters/Prototype.tex index 7677cde..101594b 100644 --- a/Chapters/Prototype.tex +++ b/Chapters/Prototype.tex @@ -73,7 +73,7 @@ Haskell an obvious choice. \section[sec:prototype:output]{Output format} - The second important question is: What will be our output format? + 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 @@ -91,14 +91,14 @@ \small{EDIF} standard. \cite[li89] This means that when working with \small{EDIF}, our prototype would become - technology dependent (\eg only work with \small{FPGA}s of a specific + technology dependent (\eg\ only work with \small{FPGA}s of a specific vendor, or even only with specific chips). This limits the applicability of our prototype. Also, the tools we would like to use for verifying, simulating and draw pretty pictures of our output (like Precision, or QuestaSim) are designed for \small{VHDL} or Verilog input. For these reasons, we will not use \small{EDIF}, but \small{VHDL} as our - output language. We choose \VHDL over Verilog simply because we are + output language. We choose \VHDL\ over Verilog simply because we are familiar with \small{VHDL} already. The differences between \small{VHDL} and Verilog are on the higher level, while we will be using \small{VHDL} mainly to write low level, netlist-like descriptions anyway. @@ -119,12 +119,12 @@ In this thesis the words \emph{translation}, \emph{compilation} and sometimes \emph{synthesis} will be used interchangedly to refer to the process of translating the hardware description from the Haskell - language to the \VHDL language. + language to the \VHDL\ language. Similarly, the prototype created is referred to as both the \emph{translator} as well as the \emph{compiler}. - The final part of this process is usually referred to as \emph{\VHDL + The final part of this process is usually referred to as \emph{\VHDL\ generation}. \stopframedtext } @@ -134,7 +134,7 @@ 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 + 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. @@ -147,7 +147,7 @@ The main topic of this thesis is therefore the path from the Haskell hardware descriptions to \small{FPGA} synthesis, focusing of course on the - \VHDL generation. Since the \VHDL generation process preserves the meaning + \VHDL\ generation. Since the \VHDL\ generation process preserves the meaning of the Haskell description exactly, any simulation done in Haskell \emph{should} produce identical results as the synthesized hardware. @@ -239,8 +239,15 @@ reason, \small{GHC} runs its simplifications and optimizations on the core representation as well \cite[jones96]. - However, we will use the normal core representation, not the simplified - core. Reasons for this are detailed below. \todo{Ref} + We will use the normal Core representation, not the simplified Core. Even + though the simplified Core version is an equivalent, but simpler + definition, some problems were encountered with it in practice. The + simplifier restructures some (stateful) functions in a way the normalizer + and the \VHDL\ generation cannot handle, leading to uncompilable programs + (whereas the non-simplified version more closely resembles the original + program, allowing the original to be written in a way that can be + handled). This problem is further discussed in + \in{section}[sec:normalization:stateproblems]. The final prototype roughly consists of three steps: @@ -301,7 +308,7 @@ \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 + function}. \VHDL\ is generated for this function first, followed by any functions used by the entry functions (recursively). \section[sec:prototype:core]{The Core language} @@ -372,7 +379,7 @@ func arg \stoplambda This is function application. Each application consists of two - parts: The function part and the argument part. Applications are used + parts: the function part and the argument part. Applications are used for normal function \quote{calls}, but also for applying type abstractions and data constructors. @@ -509,12 +516,12 @@ A case expression evaluates its scrutinee, which should have an algebraic datatype, into weak head normal form (\small{WHNF}) and - (optionally) binds it to \lam{bndr}. Every alternative lists a - single constructor (\lam{C0 ... Cn}). Based on the actual - constructor of the scrutinee, the corresponding alternative is - chosen. The binders in the chosen alternative (\lam{bndr0,0 .... - bndr0,m} are bound to the actual arguments to the constructor in - the scrutinee. + (optionally) binds it to \lam{bndr}. If bndr is wild, \refdef{wild + binders} it is left out. Every alternative lists a single constructor + (\lam{C0 ... Cn}). Based on the actual constructor of the scrutinee, the + corresponding alternative is chosen. The binders in the chosen + alternative (\lam{bndr0,0 .... bndr0,m} are bound to the actual + arguments to the constructor in the scrutinee. This is best illustrated with an example. Assume there is an algebraic datatype declared as follows\footnote{This @@ -542,7 +549,7 @@ evaluates to this bit. If none of the alternatives match, the \lam{DEFAULT} alternative - is chosen. A case expression must always be exhaustive, \ie it + is chosen. A case expression must always be exhaustive, \ie\ it must cover all possible constructors that the scrutinee can have (if all of them are covered explicitly, the \lam{DEFAULT} alternative can be left out). @@ -561,11 +568,11 @@ f (case a of arg DEFAULT -> arg) \stoplambda - According to the \GHC documentation, this is the only use for the extra + According to the \GHC\ documentation, this is the only use for the extra binder to which the scrutinee is bound. When not using strictness annotations (which is rather pointless in hardware descriptions), \small{GHC} seems to never generate any code making use of this binder. - In fact, \GHC has never been observed to generate code using this + In fact, \GHC\ has never been observed to generate code using this binder, even when strictness was involved. Nonetheless, the prototype handles this binder as expected. @@ -598,7 +605,7 @@ equivalent type. Note that this is not meant to do any actual work, like conversion of data from one format to another, or force a complete type change. Instead, it is meant to change between different representations - of the same type, \eg switch between types that are provably equal (but + of the same type, \eg\ switch between types that are provably equal (but look different). In our hardware descriptions, we typically see casts to change between a @@ -615,14 +622,6 @@ The value of a cast is the value of its body, unchanged. The type of this value is equal to the target type, not the type of its body. - - \todo{Move and update this paragraph} - Note that this syntax is also used sometimes to indicate that a particular - expression has a particular type, even when no cast expression is - involved. This is then purely informational, since the only elements that - are 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} @@ -678,10 +677,26 @@ families and other non-standard Haskell stuff which we do not (plan to) support. + \placeintermezzo{}{ + \startframedtext[width=8cm,background=box,frame=no] + \startalignment[center] + {\tfa The \hs{id} function} + \stopalignment + \blank[medium] + A function that is probably present in every functional language, is + the \emph{identity} function. This is the function that takes a + single argument and simply returns it unmodified. In Haskell this + function is called \hs{id} and can take an argument of any type + (\ie, it is polymorphic). + + The \hs{id} function will be used in the examples every now and + then. + \stopframedtext + } In Core, every expression is typed. The translation to Core happens after the typechecker, so types in Core are always correct as well (though you could of course construct invalidly typed expressions - through the \GHC API). + through the \GHC\ API). Any type in core is one of the following: @@ -792,7 +807,7 @@ Without going into the implementation details, a dictionary can be seen as a lookup table all the methods for a given (single) type class instance. This means that all the dictionaries for the same type class - look the same (\eg contain methods with the same names). However, + look the same (\eg\ contain methods with the same names). However, dictionaries for different instances of the same class contain different methods, of course. @@ -869,7 +884,7 @@ Word} and \hs{Word} types by pattern matching and by using the explicit the \hs{State constructor}. - This explicit conversion makes the \VHDL generation easier: Whenever we + This explicit conversion makes the \VHDL\ generation easier: whenever we remove (unpack) the \hs{State} type, this means we are accessing the current state (\eg, accessing the register output). Whenever we are a adding (packing) the \hs{State} type, we are producing a new value for @@ -893,7 +908,7 @@ \subsubsection{Different input and output types} An alternative could be to use different types for input and output - state (\ie current and updated state). The accumulator example would + state (\ie\ current and updated state). The accumulator example would then become something like: \starthaskell @@ -983,7 +998,7 @@ 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 have seen in \in{section}[sec:prototype:design], the translation to - \VHDL happens as a simple, final step in the compilation process. + \VHDL\ happens as a simple, final step in the compilation process. This step works on a core expression in normal form. The specifics of normal form will be explained in \in{chapter}[chap:normalization], but the examples given should be @@ -1026,7 +1041,7 @@ Before describing how to translate state from normal form to \VHDL, we will first see how state handling looks in normal form. What limitations are there on their use to guarantee that proper - \VHDL can be generated? + \VHDL\ can be generated? We will try to formulate a number of rules about what operations are allowed with state variables. These rules apply to the normalized Core @@ -1175,11 +1190,11 @@ The prototype currently does not check much of the above conditions. This means that if the conditions are violated, sometimes a compile error is generated, but in other cases output - can be generated that is not valid \VHDL or at the very least does + can be generated that is not valid \VHDL\ or at the very least does not correspond to the input. \subsection{Translating to \VHDL} - As noted above, the basic approach when generating \VHDL for stateful + As noted above, the basic approach when generating \VHDL\ for stateful functions is to generate a single register for every stateful function. We look around the normal form to find the let binding that removes the \lam{State} newtype (using a cast). We also find the let binding that @@ -1191,12 +1206,12 @@ This approach seems simple enough, but will this also work for more complex stateful functions involving substates? Observe that any - component of a function's state that is a substate, \ie passed on as + component of a function's state that is a substate, \ie\ passed on as the state of another function, should have no influence on the hardware generated for the calling function. Any state-specific \small{VHDL} for this component can be generated entirely within the called function. So, we can completely ignore substates when - generating \VHDL for a function. + generating \VHDL\ for a function. From this observation it might seem logical to remove the substates from a function's states altogether and leave only the @@ -1227,12 +1242,12 @@ to \lam{s'}. However, \lam{s'} is build up from both \lam{accs'} and \lam{count'}, while only \lam{count'} should end up in the register. \lam{accs'} is a substate for the \lam{acc} function, for which a - register will be created when generating \VHDL for the \lam{acc} + register will be created when generating \VHDL\ for the \lam{acc} function. Fortunately, the \lam{accs'} variable (and any other substate) has a - property that we can easily check: It has a \lam{State} type - annotation. This means that whenever \VHDL is generated for a tuple + property that we can easily check: it has a \lam{State} type + annotation. This means that whenever \VHDL\ is generated for a tuple (or other algebraic type), we can simply leave out all elements that have a \lam{State} type. This will leave just the parts of the state that do not have a \lam{State} type themselves, like \lam{count'}, @@ -1266,7 +1281,7 @@ 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 do not - generate any \VHDL directly are crossed out, leaving just the + generate any \VHDL\ directly are crossed out, leaving just the actual flow of values in the final hardware. \startlambda @@ -1288,7 +1303,7 @@ \stoplambda When we would really leave out the crossed out parts, we get a slightly - weird program: There is a variable \lam{s} which has no value, and there + weird program: there is a variable \lam{s} which has no value, and there is a variable \lam{s'} that is never used. Together, these two will form the state process of the function. \lam{s} contains the "current" state, \lam{s'} is assigned the "next" state. So, at the end of each clock @@ -1299,7 +1314,7 @@ removed, leaving us just with the state of \lam{avg} itself. As an illustration of the result of this function, - \in{example}[ex:AccStateVHDL] and \in{example}[ex:AvgStateVHDL] show the the \VHDL that is + \in{example}[ex:AccStateVHDL] and \in{example}[ex:AvgStateVHDL] show the the \VHDL\ that is generated from the examples is this section. \startbuffer[AvgStateVHDL] @@ -1377,9 +1392,9 @@ end architecture structural; \stopbuffer - \placeexample[][ex:AccStateVHDL]{\VHDL generated for acc from \in{example}[ex:AvgState]} + \placeexample[][ex:AccStateVHDL]{\VHDL\ generated for acc from \in{example}[ex:AvgState]} {\typebuffer[AccStateVHDL]} - \placeexample[][ex:AvgStateVHDL]{\VHDL generated for avg from \in{example}[ex:AvgState]} + \placeexample[][ex:AvgStateVHDL]{\VHDL\ generated for avg from \in{example}[ex:AvgState]} {\typebuffer[AvgStateVHDL]} % \subsection{Initial state} % How to specify the initial state? Cannot be done inside a hardware @@ -1393,6 +1408,5 @@ % Implementation issues: state splitting, linking input to output state, % checking usage constraints on state variables. % -% \todo{Implementation issues: Separate compilation, simplified core.} % % vim: set sw=2 sts=2 expandtab: