X-Git-Url: https://git.stderr.nl/gitweb?p=matthijs%2Fmaster-project%2Freport.git;a=blobdiff_plain;f=Chapters%2FState.tex;h=f8f268a9c8f079494bb09ac1f149dc271dc887e8;hp=2cffa218533d46e894a2d1e6990b1bf24633712b;hb=a9c202b10658a4993aae80b8fc986da14c6fe19e;hpb=6b779650796b6ef5c72ea261238f8576b049d925 diff --git a/Chapters/State.tex b/Chapters/State.tex index 2cffa21..f8f268a 100644 --- a/Chapters/State.tex +++ b/Chapters/State.tex @@ -123,13 +123,13 @@ newtype Result state result = Result (state, result) As noted above, any component of a function's state that is a substate, \eg passed on as the state of another function, should have no influence on the hardware generated for the calling function. Any state-specific - VHDL for this component can be generated entirely within the called + \small{VHDL} for this component can be generated entirely within the called function. So,we can completely leave out substates from any function. From this observation, we might think to remove the substates from a function's states alltogether, and leave only the state components which are actual states of the current function. While doing this would not - remove any information needed to generate VHDL from the function, it would + remove any information needed to generate \small{VHDL} from the function, it would cause the function definition to become invalid (since we won't have any substate to pass to the functions anymore). We could solve the syntactic problems by passing \type{undefined} for state variables, but that would @@ -137,9 +137,9 @@ newtype Result state result = Result (state, result) longer be semantically equivalent to the original input). To keep the function definition correct until the very end of the process, - we will not deal with (sub)states until we get to the VHDL generation. - Here, we are translating from Core to VHDL, and we can simply not generate - VHDL for substates, effectively removing the substate components + we will not deal with (sub)states until we get to the \small{VHDL} generation. + Here, we are translating from Core to \small{VHDL}, and we can simply not generate + \small{VHDL} for substates, effectively removing the substate components alltogether. There are a few important points when ignore substates. @@ -152,19 +152,19 @@ newtype Result state result = Result (state, result) In the example above, this means we should remove \type{accums'} from \type{s'}, but not throw away \type{s'} entirely. We should, however, remove \type{s'} from the output port of the function, since the state - will be handled by a VHDL procedure within the function. + will be handled by a \small{VHDL} procedure within the function. When looking at substates, these can appear in two places: As part of an argument and as part of a return value. As noted above, these substates can only be used in very specific ways. - \desc{State variables can appear as an argument.} When generating VHDL, we + \desc{State variables can appear as an argument.} When generating \small{VHDL}, we completely ignore the argument and generate no input port for it. \desc{State variables can be extracted from other state variables.} When extracting a state variable from another state variable, this always means we're extracting a substate, which we can ignore. So, we simply generate no - VHDL for any extraction operation that has a state variable as a result. + \small{VHDL} for any extraction operation that has a state variable as a result. \desc{State variables can be passed to functions.} When passing a state variable to a function, this always means we're passing a substate @@ -200,7 +200,7 @@ newtype Result state result = Result (state, result) \stopdesc \desc{State variables can appear as (part of) a function result.} When - generating VHDL, we can completely ignore any part of a function result + generating \small{VHDL}, we can completely ignore any part of a function result that has a state type. If the entire result is a state type, this will mean the entity will not have an output port. Otherwise, the state elements will be removed from the type of the output port. @@ -210,16 +210,16 @@ newtype Result state result = Result (state, result) look at the whole, we can conclude the following: \startitemize - \item A state unpack operation should not generate any VHDL. The binder + \item A state unpack operation should not generate any \small{VHDL}. The binder to which the unpacked state is bound should still be declared, this signal will become the register and will hold the current state. - \item A state pack operation should not generate any VHDL. The binder th + \item A state pack operation should not generate any \small{VHDL}. The binder th which the packed state is bound should not be declared. The binder that is packed is the signal that will hold the new state. - \item Any values of a State type should not be translated to VHDL. In + \item Any values of a State type should not be translated to \small{VHDL}. In particular, State elements should be removed from tuples (and other datatypes) and arguments with a state type should not generate ports. - \item To make the state actually work, a simple VHDL proc should be + \item To make the state actually work, a simple \small{VHDL} proc should be generated. This proc updates the state at every clockcycle, by assigning the new state to the current state. This will be recognized by synthesis tools as a register specification. @@ -258,7 +258,7 @@ newtype Result state result = Result (state, result) might think it as having a state type. Since the state type has a single argument constructor \type{State}, some type that should be the resulting state should always be explicitly packed with the State constructor, - allowing us to remove the packed version, but still generate VHDL for the + allowing us to remove the packed version, but still generate \small{VHDL} for the unpacked version (of course with any substates removed). As you can see, the definition of \type{s'} is still present, since it