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
\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.
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
}
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.
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.
% Draw the objects (and deferred labels)
drawObj (inp, front, desugar, simpl, back, out);
\stopuseMPgraphic
- \placefigure[right]{GHC compiler pipeline}{\useMPgraphic{ghc-pipeline}}
+ \placefigure[right]{GHC compiler pipeline}{\startboxed \useMPgraphic{ghc-pipeline}\stopboxed}
\startdesc{Frontend}
This step takes the Haskell source files and parses them into an
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
% Draw the objects (and deferred labels)
drawObj (inp, front, norm, vhdl, out);
\stopuseMPgraphic
- \placefigure[right]{Cλash compiler pipeline}{\useMPgraphic{clash-pipeline}}
+ \placefigure[right]{Cλash compiler pipeline}{\startboxed \useMPgraphic{clash-pipeline}\stopboxed}
\startdesc{Frontend}
This is exactly the frontend from the \small{GHC} pipeline, that
\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}
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.
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
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).
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.
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
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}
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:
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.
\stopdesc
Using this set of types, all types in basic Haskell can be represented.
-
\todo{Overview of polymorphism with more examples (or move examples
- here)}.
+ here)}
\section[sec:prototype:statetype]{State annotations in Haskell}
As noted in \in{section}[sec:description:stateann], Cλash needs some
equal to an existing type (or rather, a new name for an existing type).
This allows both the original type and the synonym to be used
interchangedly in a Haskell program. This means no explicit conversion
- is needed either. For example, a simple accumulator would become:
+ is needed. For example, a simple accumulator would become:
\starthaskell
+ -- This type synonym would become part of Cλash, it is shown here
+ -- just for clarity.
type State s = s
+
acc :: Word -> State Word -> (State Word, Word)
acc i s = let sum = s + i in (sum, sum)
\stophaskell
This looks nice in Haskell, but turns out to be hard to implement. There
- are no explicit conversion in Haskell, but not in Core either. This
- means the type of a value might be show as \hs{AccState} in some places,
- but \hs{Word} in others (and this can even change due to
- transformations). Since every binder has an explicit type associated
- with it, the type of every function type will be properly preserved and
- could be used to track down the statefulness of each value by the
- compiler. However, this makes the implementation a lot more complicated
- than it currently is using \hs{newtypes}.
+ is no explicit conversion in Haskell, but not in Core either. This
+ means the type of a value might be shown as \hs{State Word} in
+ some places, but \hs{Word} in others (and this can even change due
+ to transformations). Since every binder has an explicit type
+ associated with it, the type of every function type will be
+ properly preserved and could be used to track down the
+ statefulness of each value by the compiler. However, this would make
+ the implementation a lot more complicated than when using type
+ renamings as described in the next section.
% Use \type instead of \hs here, since the latter breaks inside
% section headings.
\subsection{Type renaming (\type{newtype})}
Haskell also supports type renamings as a way to declare a new type that
has the same (runtime) representation as an existing type (but is in
- fact a different type to the typechecker). With type renaming, an
+ fact a different type to the typechecker). With type renaming,
explicit conversion between values of the two types is needed. The
accumulator would then become:
\starthaskell
+ -- This type renaming would become part of Cλash, it is shown here
+ -- just for clarity.
newtype State s = State s
+
acc :: Word -> State Word -> (State Word, Word)
acc i (State s) = let sum = s + i in (State sum, sum)
\stophaskell
never cause name collisions with values). The difference with the type
synonym example is in the explicit conversion between the \hs{State
Word} and \hs{Word} types by pattern matching and by using the explicit
- the \hs{State constructor}.
+ 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
+ current state (\ie, accessing the register output). Whenever we are
adding (packing) the \hs{State} type, we are producing a new value for
- the state (\eg, providing the register input).
+ the state (\ie, providing the register input).
When dealing with nested states (a stateful function that calls stateful
functions, which might call stateful functions, etc.) the state type
needed. For example, consider the following state type (this is just the
state type, not the entire function type):
- \starttyping
+ \starthaskell
State (State Bit, State (State Word, Bit), Word)
- \stoptyping
+ \stophaskell
We cannot leave all these \hs{State} type constructors out, since that
would change the type (unlike when using type synonyms). However, when
\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
+ -- These type renaminges would become part of Cλash, it is shown
+ -- here just for clarity.
newtype StateIn s = StateIn s
newtype StateOut s = StateOut s
+
acc :: Word -> StateIn Word -> (StateIn Word, Word)
acc i (StateIn s) = let sum = s + i in (StateIn sum, sum)
\stophaskell
This could make the implementation easier and the hardware
- descriptions less errorprone (you can no longer \quote{forget} to
+ descriptions less error-prone (you can no longer \quote{forget} to
unpack and repack a state variable and just return it directly, which
can be a problem in the current prototype). However, it also means we
need twice as many type synonyms to hide away substates, making this
- approach a bit cumbersome. It also makes it harder to copmare input
- and output state types, possible reducing the type safety of the
+ approach a bit cumbersome. It also makes it harder to compare input
+ and output state types, possible reducing the type-safety of the
descriptions.
\subsection[sec:prototype:substatesynonyms]{Type synonyms for substates}
As noted above, when using nested (hierarchical) states, the state types
of the \quote{upper} functions (those that call other functions, which
- call other functions, etc.) quickly becomes complicated. Also, when the
+ call other functions, etc.) quickly become complicated. Also, when the
state type of one of the \quote{lower} functions changes, the state
types of all the upper functions changes as well. If the state type for
each function is explicitly and completely specified, this means that a
losing any expressivity.
\subsubsection{Example}
- As an example of the used approach, there is a simple averaging circuit in
- \in{example}[ex:AvgState]. This circuit lets the accumulation of the
- inputs be done by a subcomponent, \hs{acc}, but keeps a count of value
- accumulated in its own state.\footnote{Currently, the prototype
- is not able to compile this example, since the built-in function
- for division has not been added.}
+ As an example of the used approach, a simple averaging circuit
+ is shown in \in{example}[ex:AvgState]. This circuit lets the
+ accumulation of the inputs be done by a subcomponent, \hs{acc},
+ but keeps a count of value accumulated in its own
+ state.\footnote{Currently, the prototype is not able to compile
+ this example, since there is no built-in function for division.}
\startbuffer[AvgState]
- -- The state type annotation
+ -- This type renaming would become part of Cλash, it is shown
+ -- here just for clarity
newtype State s = State s
-- The accumulator state type
%\stopcombination
\todo{Picture}
- \section{Implementing state}
+ \section{\VHDL\ generation for state}
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.
- This step works on a core expression in normal form. The specifics
+ \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
- easy to understand using the definitin of Core given above.
+ easy to understand using the definition of Core given above. The
+ conversion to and from the \hs{State} type is done using the cast
+ operator, \lam{▶}.
\startbuffer[AvgStateNormal]
acc = λi.λspacked.
let
-- Remove the State newtype
s = spacked ▶ Word
- s' = s + i
- o = s + i
+ sum = s + i
-- Add the State newtype again
- spacked' = s' ▶ State Word
- res = (spacked', o)
+ spacked' = sum ▶ State Word
+ res = (spacked', sum)
in
res
avg = λi.λspacked.
let
s = spacked ▶ (AccState, Word)
- accs = case s of (accs, _) -> accs
- count = case s of (_, count) -> count
+ accs = case s of (a, b) -> a
+ count = case s of (c, d) -> d
accres = acc i accs
- accs' = case accres of (accs', _) -> accs'
- sum = case accres of (_, sum) -> sum
+ accs' = case accres of (e, f) -> e
+ sum = case accres of (g, h) -> h
count' = count + 1
o = sum / count'
s' = (accs', count')
\subsection[sec:prototype:statelimits]{State in normal form}
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?
+ How must their use be limited to guarantee that proper \VHDL\ can
+ be generated?
- We will try to formulate a number of rules about what operations are
+ We will formulate a number of rules about what operations are
allowed with state variables. These rules apply to the normalized Core
representation, but will in practice apply to the original Haskell
hardware description as well. Ideally, these rules would become part
(state) variables} and \emph{substate variables}, which will be
defined in the rules themselves.
+ These rules describe everything that can be done with state
+ variables and state-containing variables. Everything else is
+ invalid. For every rule, the corresponding part of
+ \in{example}[ex:AvgStateNormal] is shown.
+
\startdesc{State variables can appear as an argument.}
\startlambda
avg = λi.λspacked. ...
\lam{State} type.
If the result of this unpacking does not have a state type and does
- not contain state variables, there are no limitations on its use.
- Otherwise if it does not have a state type but does contain
- substates, we refer to it as a \emph{state-containing input
- variable} and the limitations below apply. If it has a state type
- itself, we refer to it as an \emph{input substate variable} and the
- below limitations apply as well.
+ not contain state variables, there are no limitations on its
+ use (this is the function's own state). Otherwise if it does
+ not have a state type but does contain substates, we refer to it
+ as a \emph{state-containing input variable} and the limitations
+ below apply. If it has a state type itself, we refer to it as an
+ \emph{input substate variable} and the below limitations apply
+ as well.
It may seem strange to consider a variable that still has a state
type directly after unpacking, but consider the case where a
\startdesc{Variables can be extracted from state-containing input variables.}
\startlambda
- accs = case s of (accs, _) -> accs
+ accs = case s of (a, b) -> a
\stoplambda
A state-containing input variable is typically a tuple containing
multiple, when the input variable is nested).
If the result has no state type and does not contain any state
- variables either, there are no further limitations on its use. If
- the result has no state type but does contain state variables we
- refer to it as a \emph{state-containing input variable} and this
- limitation keeps applying. If the variable has a state type itself,
- we refer to it as an \emph{input substate variable} and below
- limitations apply.
+ variables either, there are no further limitations on its use
+ (this is the function's own state). If the result has no state
+ type but does contain state variables we refer to it as a
+ \emph{state-containing input variable} and this limitation keeps
+ applying. If the variable has a state type itself, we refer to
+ it as an \emph{input substate variable} and below limitations
+ apply.
\startdesc{Input substate variables can be passed to functions.}
\startlambda
accres = acc i accs
- accs' = case accres of (accs', _) -> accs'
+ accs' = case accres of (e, f) -> e
\stoplambda
An input substate variable can (only) be passed to a function.
A function's output state is usually a tuple containing its own
updated state variables and all output substates. This result is
- built up using any single-constructor algebraic datatype.
+ built up using any single-constructor algebraic datatype
+ (possibly nested).
The result of these expressions is referred to as a
\emph{state-containing output variable}, which are subject to these
As soon as all a functions own update state and output substate
variables have been joined together, the resulting
state-containing output variable can be packed into an output
- state variable. Packing is done by casting into a state type.
+ state variable. Packing is done by casting to a state type.
\stopdesc
\startdesc{Output state variables can appear as (part of) a function result.}
to be passed to functions, the corresponding output substates
should be inserted into the output state in the same way. In other
words, each pair of corresponding substates in the input and
- output states should be passed / returned from the same called
+ output states should be passed to / returned from the same called
function.
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
+ \lam{State} type renaming (using a cast). We also find the let binding that
adds a \lam{State} type. These are connected to the output and the input
of the generated let binding respectively. This means that there can
only be one let binding that adds and one that removes the \lam{State}
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
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
\small{VHDL} generation. Then, we are translating from Core to
- \small{VHDL}, and we can simply ignore substates, effectively removing
- the substate components altogether.
+ \small{VHDL}, and we can simply generate no \VHDL for substates,
+ effectively removing them altogether.
But, how will we know what exactly is a substate? Since any state
argument or return value that represents state must be of the
must be careful to ignore only \emph{substates}, and not a
function's own state.
- In \in{example}[ex:AvgStateNorm] above, we should generate a register
- connected with its output connected to \lam{s} and its input connected
+ For \in{example}[ex:AvgStateNormal] above, we should generate a register
+ with its output connected to \lam{s} and its input connected
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
- (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'},
- which is exactly a function's own state. This approach also means that
- the state part of the result is automatically excluded when generating
- the output port, which is also required.
+ property that we can easily check: it has a \lam{State} type. 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'},
+ which is exactly a function's own state. This approach also means
+ that the state part of the result (\eg\ \lam{s'} in \lam{res}) is
+ automatically excluded when generating the output port, which is
+ also required.
We can formalize this translation a bit, using the following
rules.
register specification.
\stopitemize
- When applying these rules to the description in
+ When applying these rules to the function \lam{avg} from
\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
- actual flow of values in the final hardware.
+ generate any \VHDL\ directly are crossed out, leaving just the
+ actual flow of values in the final hardware. To illustrate the
+ change of the types of \lam{s} and \lam{s'}, their types are also
+ shown.
- \startlambda
+ \startbuffer[AvgStateRemoved]
avg = iλ.λ--spacked.--
let
+ s :: (--AccState,-- Word)
s = --spacked ▶ (AccState, Word)--
- --accs = case s of (accs, _) -> accs--
- count = case s of (--_,-- count) -> count
+ --accs = case s of (a, b) -> a--
+ count = case s of (--c,-- d) -> d
accres = acc i --accs--
- --accs' = case accres of (accs', _) -> accs'--
- sum = case accres of (--_,-- sum) -> sum
+ --accs' = case accres of (e, f) -> e--
+ sum = case accres of (--g,-- h) -> h
count' = count + 1
o = sum / count'
+ s' :: (--AccState,-- Word)
s' = (--accs',-- count')
--spacked' = s' ▶ State (AccState, Word)--
res = (--spacked',-- o)
in
res
- \stoplambda
+ \stopbuffer
+ \placeexample[here][ex:AvgStateRemoved]{Normalized version of \in{example}[ex:AvgState] with ignored parts crossed out}
+ {\typebufferlam{AvgStatRemoved}}
- 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
- is a variable \lam{s'} that is never used. Together, these two will form
+ When we actually leave out the crossed out parts, we get a slightly
+ weird program: there is a variable \lam{s} which has no value, and there
+ is a variable \lam{s'} that is never used. But 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
cycle, \lam{s'} should be assigned to \lam{s}.
- In the example the definition of \lam{s'} is still present, since
- it does not have a state type. The \lam{accums'} substate has been
- 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
- generated from the examples is this section.
+ \in{example}[ex:AccStateVHDL] and \in{example}[ex:AvgStateVHDL] show the the \VHDL\ that is
+ generated by Cλash from the examples is this section.
\startbuffer[AvgStateVHDL]
entity avgComponent_0 is
end process state;
end architecture structural;
\stopbuffer
+
+ \startbuffer[AvgStateTypes]
+ package types is
+ subtype \unsigned_31\ is unsigned (0 to 31);
+
+ type \(,)unsigned_31\ is record
+ A : \unsigned_31\;
+ end record;
+ end package types;
+ \stopbuffer
+
\startbuffer[AccStateVHDL]
entity accComponent_1 is
port (\izAob3\ : in \unsigned_31\;
resetn : in std_logic);
end entity accComponent_1;
-
architecture structural of accComponent_1 is
signal \szAod3\ : \unsigned_31\;
signal \reszAonzAor3\ : \unsigned_31\;
end architecture structural;
\stopbuffer
- \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]}
- {\typebuffer[AvgStateVHDL]}
+ \placeexample[][ex:AvgStateTypes]{\VHDL\ types generated for acc and avg from \in{example}[ex:AvgState]}
+ {\typebuffervhdl{AvgStateTypes}}
+ \placeexample[][ex:AccStateVHDL]{\VHDL\ generated for acc from \in{example}[ex:AvgState]}
+ {\typebuffervhdl{AccStateVHDL}}
+ \placeexample[][ex:AvgStateVHDL]{\VHDL\ generated for avg from \in{example}[ex:AvgState]}
+ {\typebuffervhdl{AvgStateVHDL}}
% \subsection{Initial state}
% How to specify the initial state? Cannot be done inside a hardware
% function, since the initial state is its own state argument for the first
projects / matthijs / master-project / report.git / blobdiff