From: Matthijs Kooijman Date: Mon, 7 Dec 2009 09:57:23 +0000 (+0100) Subject: Use \VHDL\ (etc.) instead of relying on \autoinsertnextspace. X-Git-Tag: final-thesis~67 X-Git-Url: https://git.stderr.nl/gitweb?a=commitdiff_plain;h=75d1001c7a7809c80bc4113477ad90b12f23b80f;p=matthijs%2Fmaster-project%2Freport.git Use \VHDL\ (etc.) instead of relying on \autoinsertnextspace. The \autoinsertnextspace macro is not always reliable and was removed in a recent ConTeXt version. --- diff --git a/Chapters/Conclusions.tex b/Chapters/Conclusions.tex index fff4b3d..a8d7e9b 100644 --- a/Chapters/Conclusions.tex +++ b/Chapters/Conclusions.tex @@ -12,7 +12,7 @@ assigment in the hardware. Useful features from the functional perspective, like polymorphism and higher-order functions and expressions also prove suitable to describe hardware and our implementation shows that they can be translated to -\VHDL as well. +\VHDL\ as well. A prototype compiler was created in this research. For this prototype the Haskell language was chosen as the input language, instead of creating a new @@ -63,7 +63,7 @@ It is expected that Cλash will be used as a tool in education at the University of Twente soon, hopefully this will provide a better insight in how the system performs. -The prototype compiler has a clear design. Its frontend is taken from the \GHC +The prototype compiler has a clear design. Its frontend is taken from the \GHC\ compiler and desugares Haskell into a small, but functional and typed language, called \emph{Core}. Cλash adds a transformation system that reduces this small language to a normal form and a simple backend that performs a diff --git a/Chapters/Context.tex b/Chapters/Context.tex index 45c1686..7e620a0 100644 --- a/Chapters/Context.tex +++ b/Chapters/Context.tex @@ -95,7 +95,7 @@ \stopalignment \blank[medium] - Template Haskell is an extension to the \GHC compiler that allows + Template Haskell is an extension to the \GHC\ compiler that allows a program to mark some parts to be evaluated \emph{at compile time}. These \emph{templates} can then access the abstract syntax tree (\small{AST}) of the program that is being compiled and @@ -130,7 +130,7 @@ with an \small{EDSL} approach, it can get confusing when to use \small{TH} and when not to. \item Function hierarchies cannot be observed in an \small{EDSL}. - For example, Lava generates a single flat \VHDL architecture, + For example, Lava generates a single flat \VHDL\ architecture, which has no structure whatsoever. Even though this is strictly correct, it offers no support to the synthesis software about which parts of the system can best be placed together and makes diff --git a/Chapters/Future.tex b/Chapters/Future.tex index 0399db9..da1b23d 100644 --- a/Chapters/Future.tex +++ b/Chapters/Future.tex @@ -234,7 +234,7 @@ feasible. \subsection{Arrows} Another abstraction mechanism offered by Haskell are arrows. Arrows are -a generalisation of monads \cite[hughes98], for which \GHC also supports +a generalisation of monads \cite[hughes98], for which \GHC\ also supports some syntax sugar \cite[paterson01]. Their use for hiding away state boilerplate is not directly evident, but since arrows are a complex concept further investigation is appropriate. @@ -479,7 +479,7 @@ behaviour is not needed. The main cost of this approach will probably be extra complexity in the compiler: The paths (state) data can take become very non-trivial, and it is probably hard to properly analyze these paths and produce the -intended \VHDL description. +intended \VHDL\ description. \section{Multiple cycle descriptions} In the current Cλash prototype, every description is a single-cycle @@ -597,7 +597,7 @@ that is never used for a particular state variable. This separation is probably a non-trivial problem, though. \section{Don't care values} - A powerful value in \VHDL is the \emph{don't care} value, given as + A powerful value in \VHDL\ is the \emph{don't care} value, given as \type{'-'}. This value tells the compiler that you do not really care about which value is assigned to a signal, allowing the compiler to make some optimizations. Since choice in hardware is often implemented using @@ -622,7 +622,7 @@ probably a non-trivial problem, though. This would also require some kind of \quote{Don't careable} type class that allows each type to specify what its don't care value is. The compiler must then recognize this constant and replace it with don't care - values in the final \VHDL code. + values in the final \VHDL\ code. This is of course a very intrusive solution. Every type must become member of this type class, and there is now some member in every type that is a diff --git a/Chapters/HardwareDescription.tex b/Chapters/HardwareDescription.tex index 7b56199..bf797f6 100644 --- a/Chapters/HardwareDescription.tex +++ b/Chapters/HardwareDescription.tex @@ -70,9 +70,9 @@ mapped to a signal, which is used as the result of the application. Since every top level function generates its own component, the - hierarchy of of function calls is reflected in the final \VHDL output - as well, creating a hierarchical \VHDL description of the hardware. - This separation in different components makes the resulting \VHDL + hierarchy of of function calls is reflected in the final \VHDL\ output + as well, creating a hierarchical \VHDL\ description of the hardware. + This separation in different components makes the resulting \VHDL\ output easier to read and debug. \in{Example}[ex:And3] shows a simple program using only function @@ -160,7 +160,7 @@ and3 a b c = and (and a b) c the comparator and directly feed 'in' into the multiplexer (or even use an inverter instead of a multiplexer). However, we will try to make a general translation, which works for all possible \hs{case} expressions. - Optimizations such as these are left for the \VHDL synthesizer, which + Optimizations such as these are left for the \VHDL\ synthesizer, which handles them very well. \todo{Be more explicit about >2 alternatives} @@ -354,17 +354,17 @@ and3 a b c = and (and a b) c \subsection{User-defined types} There are three ways to define new types in Haskell: Algebraic datatypes with the \hs{data} keyword, type synonyms with the \hs{type} - keyword and type renamings with the \hs{newtype} keyword. \GHC + keyword and type renamings with the \hs{newtype} keyword. \GHC\ offers a few more advanced ways to introduce types (type families, existential typing, \small{GADT}s, etc.) which are not standard Haskell. These will be left outside the scope of this research. Only an algebraic datatype declaration actually introduces a - completely new type, for which we provide the \VHDL translation + completely new type, for which we provide the \VHDL\ translation below. Type synonyms and renamings only define new names for existing types (where synonyms are completely interchangeable and renamings need explicit conversion). Therefore, these do not need - any particular \VHDL translation, a synonym or renamed type will + any particular \VHDL\ translation, a synonym or renamed type will just use the same representation as the original type. The distinction between a renaming and a synonym does no longer matter in hardware and can be disregarded in the generated \VHDL. @@ -382,7 +382,7 @@ and3 a b c = and (and a b) c to this type. The collection for a product type is the Cartesian product of the collections for the types of its fields. - These types are translated to \VHDL record types, with one field for + These types are translated to \VHDL\ record types, with one field for every field in the constructor. This translation applies to all single constructor algebraic datatypes, including those with just one field (which are technically not a product, but generate a VHDL @@ -397,7 +397,7 @@ and3 a b c = and (and a b) c Note that Haskell's \hs{Bool} type is also defined as an enumeration type, but we have a fixed translation for that. - These types are translated to \VHDL enumerations, with one value for + These types are translated to \VHDL\ enumerations, with one value for each constructor. This allows references to these constructors to be translated to the corresponding enumeration value. \stopdesc @@ -413,7 +413,7 @@ and3 a b c = and (and a b) c union of the the collections for each of the constructors. Sum types are currently not supported by the prototype, since there is - no obvious \VHDL alternative. They can easily be emulated, however, as + no obvious \VHDL\ alternative. They can easily be emulated, however, as we will see from an example: \starthaskell @@ -436,7 +436,7 @@ and3 a b c = and (and a b) c last one if \hs{B}), all the other ones have no useful value. An obvious problem with this naive approach is the space usage: The - example above generates a fairly big \VHDL type. Since we can be + example above generates a fairly big \VHDL\ type. Since we can be sure that the two \hs{Word}s in the \hs{Sum} type will never be valid at the same time, this is a waste of space. @@ -466,13 +466,13 @@ and3 a b c = and (and a b) c If the naive approach for sum types described above would be used, a record would be created where the first field is an enumeration to distinguish \hs{Empty} from \hs{Cons}. Furthermore, two more - fields would be added: One with the (\VHDL equivalent of) type + fields would be added: One with the (\VHDL\ equivalent of) type \hs{t} (assuming this type is actually known at compile time, this should not be a problem) and a second one with type \hs{List t}. The latter one is of course a problem: This is exactly the type that was to be translated in the first place. - The resulting \VHDL type will thus become infinitely deep. In + The resulting \VHDL\ type will thus become infinitely deep. In other words, there is no way to statically determine how long (deep) the list will be (it could even be infinite). @@ -665,7 +665,7 @@ quadruple n = mul (mul n) Fortunately, we can again use the principle of specialization: Since every function application generates a separate piece of hardware, we can know the types of all arguments exactly. Provided that existential typing - (which is a \GHC extension) is not used typing, all of the + (which is a \GHC\ extension) is not used typing, all of the polymorphic types in a function must depend on the types of the arguments (In other words, the only way to introduce a type variable is in a lambda abstraction). @@ -990,7 +990,7 @@ acc in s = (s', out) result is stateful. This means that the annotation lives \quote{outside} of the function, it is completely invisible when looking at the function body. - \item Use some kind of annotation on the type level, \ie give stateful + \item Use some kind of annotation on the type level, \ie\ give stateful arguments and stateful (parts of) results a different type. This has the potential to make this annotation visible inside the function as well, such that when looking at a value inside the function body you can @@ -1101,7 +1101,7 @@ acc in s = (s', out) (evaluation of constant comparisons), to ensure non-termination. Supporting general recursion will probably require strict conditions on the input descriptions. Even then, it will be hard (if not - impossible) to really guarantee termination, since the user (or \GHC + impossible) to really guarantee termination, since the user (or \GHC\ desugarer) might use some obscure notation that results in a corner case of the simplifier that is not caught and thus non-termination. diff --git a/Chapters/Introduction.tex b/Chapters/Introduction.tex index 334b1c8..af334a3 100644 --- a/Chapters/Introduction.tex +++ b/Chapters/Introduction.tex @@ -220,7 +220,7 @@ advanced types and provides a case study. In addition to looking at designing a hardware description language, we will also implement a prototype to test ideas. This prototype will translate hardware descriptions written in the Haskell functional language - to simple (netlist-like) hardware descriptions in the \VHDL language. The + to simple (netlist-like) hardware descriptions in the \VHDL\ language. The reasons for choosing these languages are detailed in section \in{}[sec:prototype:input] and \in{}[sec:prototype:output] respectively. diff --git a/Chapters/Normalization.tex b/Chapters/Normalization.tex index 5a3fecb..8de3794 100644 --- a/Chapters/Normalization.tex +++ b/Chapters/Normalization.tex @@ -324,7 +324,7 @@ There are two things missing: Cast expressions are sometimes allowed by the prototype, but not specified here and the below - definition allows uses of state that cannot be translated to \VHDL + definition allows uses of state that cannot be translated to \VHDL\ properly. These two problems are discussed in \in{section}[sec:normalization:castproblems] and \in{section}[sec:normalization:stateproblems] respectively. @@ -383,8 +383,8 @@ Most function applications bound by the let expression define a component instantiation, where the input and output ports are mapped to local signals or arguments. Some of the others use a - built-in construction (\eg the \lam{case} expression) or call a - built-in function (\eg \lam{+} or \lam{map}). For these, a + built-in construction (\eg\ the \lam{case} expression) or call a + built-in function (\eg\ \lam{+} or \lam{map}). For these, a hardcoded \small{VHDL} translation is available. \section[sec:normalization:transformation]{Transformation notation} @@ -413,9 +413,9 @@ against (subexpressions of) the expression to be transformed. We call this a pattern, because it can contain \emph{placeholders} (variables), which match any expression or binder. Any such placeholder is said to be \emph{bound} to - the expression it matches. It is convention to use an uppercase letter (\eg + the expression it matches. It is convention to use an uppercase letter (\eg\ \lam{M} or \lam{E}) to refer to any expression (including a simple variable - reference) and lowercase letters (\eg \lam{v} or \lam{b}) to refer to + reference) and lowercase letters (\eg\ \lam{v} or \lam{b}) to refer to (references to) binders. For example, the pattern \lam{a + B} will match the expression @@ -666,7 +666,7 @@ lambda abstractions, let expressions and pattern matches of case alternatives). This is a slightly different notion of global versus local than what \small{GHC} uses internally, but for our purposes - the distinction \GHC makes is not useful. + the distinction \GHC\ makes is not useful. \defref{global variable} \defref{local variable} A \emph{hardware representable} (or just \emph{representable}) type or value @@ -901,7 +901,7 @@ desugarer or simplifier emits some bindings that cannot be normalized (e.g., calls to a \hs{Control.Exception.Base.patError}) but are not used anywhere - either. To prevent the \VHDL generation from breaking on these + either. To prevent the \VHDL\ generation from breaking on these artifacts, this transformation removes them. \todo{Do not use old-style numerals in transformations} @@ -971,7 +971,7 @@ \subsubsection[sec:normalization:simplelet]{Simple let binding removal} This transformation inlines simple let bindings, that bind some - binder to some other binder instead of a more complex expression (\ie + binder to some other binder instead of a more complex expression (\ie\ a = b). This transformation is not needed to get an expression into intended @@ -1072,11 +1072,11 @@ \in{Section}[section:prototype:polymorphism]. Without this transformation, there would be a \lam{(+)} entity - in the \VHDL which would just add its inputs. This generates a + in the \VHDL\ which would just add its inputs. This generates a lot of overhead in the \VHDL, which is particularly annoying when browsing the generated RTL schematic (especially since most non-alphanumerics, like all characters in \lam{(+)}, are not - allowed in \VHDL architecture names\footnote{Technically, it is + allowed in \VHDL\ architecture names\footnote{Technically, it is allowed to use non-alphanumerics when using extended identifiers, but it seems that none of the tooling likes extended identifiers in filenames, so it effectively does not @@ -1326,7 +1326,7 @@ This transformation ensures that all representable arguments will become references to local variables. This ensures they will become references to local signals in the resulting \small{VHDL}, which is required due to - limitations in the component instantiation code in \VHDL (one can only + limitations in the component instantiation code in \VHDL\ (one can only assign a signal or constant to an input port). By ensuring that all arguments are always simple variable references, we always have a signal available to map to the input ports. @@ -1341,7 +1341,7 @@ function without arguments, but also an argumentless dataconstructors like \lam{True}) are also simplified. Only local variables generate signals in the resulting architecture. Even though argumentless - dataconstructors generate constants in generated \VHDL code and could be + dataconstructors generate constants in generated \VHDL\ code and could be mapped to an input port directly, they are still simplified to make the normal form more regular. @@ -1476,10 +1476,10 @@ will become one of: \refdef{intended normal form definition} \startitemize \item An extractor case with a single alternative that picks a field - from a datatype, \eg \lam{case x of (a, b) -> a}. + from a datatype, \eg\ \lam{case x of (a, b) -> a}. \item A selector case with multiple alternatives and only wild binders, that makes a choice between expressions based on the constructor of another - expression, \eg \lam{case x of Low -> a; High -> b}. + expression, \eg\ \lam{case x of Low -> a; High -> b}. \stopitemize For an arbitrary case, that has \lam{n} alternatives, with @@ -1628,7 +1628,7 @@ There is one case where polymorphism cannot be completely removed: Built-in functions are still allowed to be polymorphic (Since we have no function body that we could properly - specialize). However, the code that generates \VHDL for built-in + specialize). However, the code that generates \VHDL\ for built-in functions knows how to handle this, so this is not a problem. \subsubsection[sec:normalization:defunctionalization]{Defunctionalization} @@ -1697,7 +1697,7 @@ \stoplambda This example shows a number of higher-order values that we cannot - translate to \VHDL directly. The \lam{double} binder bound in the let + translate to \VHDL\ directly. The \lam{double} binder bound in the let expression has a function type, as well as both of the alternatives of the case expression. The first alternative is a partial application of the \lam{map} built-in function, whereas the second alternative is a @@ -1856,11 +1856,11 @@ Haskell's \hs{Num} type class, which offers a \hs{fromInteger} method that converts any \hs{Integer} to the Cλash datatypes. - When \GHC sees integer literals, it will automatically insert calls to + When \GHC\ sees integer literals, it will automatically insert calls to the \hs{fromInteger} method in the resulting Core expression. For example, the following expression in Haskell creates a 32 bit unsigned word with the value 1. The explicit type signature is needed, since - there is no context for \GHC to determine the type from otherwise. + there is no context for \GHC\ to determine the type from otherwise. \starthaskell 1 :: SizedWord D32 @@ -2155,7 +2155,7 @@ normal form definition} offers enough freedom to describe all valid stateful descriptions, but is not limiting enough. It is possible to write descriptions which are in intended normal - form, but cannot be translated into \VHDL in a meaningful way + form, but cannot be translated into \VHDL\ in a meaningful way (\eg, a function that swaps two substates in its result, or a function that changes a substate itself instead of passing it to a subfunction). @@ -2172,7 +2172,7 @@ Without going into detail about the exact problems (of which there are probably more than have shown up so far), it seems unlikely that these problems can be solved entirely by just - improving the \VHDL state generation in the final stage. The + improving the \VHDL\ state generation in the final stage. The normalization stage seems the best place to apply the rewriting needed to support more complex stateful descriptions. This does of course mean that the intended normal form definition must be @@ -2389,7 +2389,7 @@ sufficient for our goals (but it is a good start). It should be possible to have a single formal definition of - meaning for Core for both normal Core compilation by \GHC and for + meaning for Core for both normal Core compilation by \GHC\ and for our compilation to \VHDL. The main difference seems to be that in hardware every expression is always evaluated, while in software it is only evaluated if needed, but it should be possible to @@ -2438,7 +2438,7 @@ This approach is especially useful for proving completeness of our system, since if expressions exist to which none of the - transformations apply (\ie if the system is not yet complete), it + transformations apply (\ie\ if the system is not yet complete), it is immediately clear which expressions these are and adding (or modifying) transformations to fix this should be relatively easy. diff --git a/Chapters/Prototype.tex b/Chapters/Prototype.tex index 96abdba..3d8fb67 100644 --- a/Chapters/Prototype.tex +++ b/Chapters/Prototype.tex @@ -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. @@ -243,7 +243,7 @@ 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 + 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 @@ -308,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} @@ -549,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). @@ -568,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. @@ -605,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 @@ -688,7 +688,7 @@ 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: @@ -799,7 +799,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. @@ -876,7 +876,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 @@ -900,7 +900,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 @@ -990,7 +990,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 @@ -1033,7 +1033,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 @@ -1182,11 +1182,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 @@ -1198,12 +1198,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 @@ -1234,12 +1234,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 + 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'}, @@ -1273,7 +1273,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 @@ -1306,7 +1306,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] @@ -1384,9 +1384,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 diff --git a/Utils/Shortcuts.tex b/Utils/Shortcuts.tex index 5c46d37..442a5c4 100644 --- a/Utils/Shortcuts.tex +++ b/Utils/Shortcuts.tex @@ -2,11 +2,9 @@ % This file defines some useful shortcut commands % -\def\autoinsertnextspace{} - % A shortcut for italicized e.g. and i.e. -\define[0]\eg{{\em e.g.}\autoinsertnextspace} -\define[0]\ie{{\em i.e.}\autoinsertnextspace} +\define[0]\eg{{\em e.g.}} +\define[0]\ie{{\em i.e.}} % Define a new reference to a definition of the term. The text of the @@ -30,8 +28,8 @@ \define[1]\refdef{\inothermargin{\goto{\ref[t][def:#1] p.\ref[p][def:#1]}[def:#1]}} % Shortcuts to write in smallcaps -\def\VHDL{\small{VHDL}\autoinsertnextspace} -\def\GHC{\small{GHC}\autoinsertnextspace} +\def\VHDL{\small{VHDL}} +\def\GHC{\small{GHC}} % TODO: Use this instead of $ to fool syntax highlighting \def\${\char36}