%
\documentclass[conference,pdf,a4paper,10pt,final,twoside,twocolumn]{IEEEtran}
+\IEEEoverridecommandlockouts
% Add the compsoc option for Computer Society conferences.
%
% If IEEEtran.cls has not been installed into the LaTeX system files,
\IEEEauthorblockA{%Computer Architecture for Embedded Systems (CAES)\\
Department of EEMCS, University of Twente\\
P.O. Box 217, 7500 AE, Enschede, The Netherlands\\
-c.p.r.baaij@@utwente.nl, matthijs@@stdin.nl, j.kuper@@utwente.nl}}
+c.p.r.baaij@@utwente.nl, matthijs@@stdin.nl, j.kuper@@utwente.nl}
+% \thanks{Supported through FP7 project: S(o)OS (248465)}
+}
% \and
% \IEEEauthorblockN{Homer Simpson}
% \IEEEauthorblockA{Twentieth Century Fox\\
the rest of paper is: \hs{[a|n]}. Where the \hs{a} is the element
type, and \hs{n} is the length of the vector. Note that this is
a notation used in this paper only, vectors are slightly more
- elaborate in real \CLaSH\ programs.
+ verbose in real \CLaSH\ descriptions.
% The state type of an 8 element register bank would then for example
% be:
\subsection{Higher order CPU}
\begin{code}
-fu op inputs (addr1, addr2) (State out) =
- (State out', out)
+fu op inputs (addr1, addr2) = regIn
where
- in1 = inputs!addr1
- in2 = inputs!addr2
- out' = op in1 in2
+ in1 = inputs!addr1
+ in2 = inputs!addr2
+ regIn = op in1 in2
\end{code}
\begin{code}
-cpu :: Word -> [(Index 6, Index 6) | 4]
- -> State [Word | 4] -> (State [Word | 4], Word)
-cpu input addrs (State fuss) = (State fuss', out)
+cpu :: State [Word | 4] -> Word
+ -> [(Index 6, Index 6) | 4]
+ -> (State [Word | 4], Word)
+cpu (State regsOut) input addrs = (State regsIn, out)
where
- fures = [ fu const inputs (addrs!0) (fuss!0)
- , fu (+) inputs (addrs!1) (fuss!1)
- , fu (-) inputs (addrs!2) (fuss!2)
- , fu (*) inputs (addrs!3) (fuss!3)
- ]
- (fuss', outputs) = unzip fures
- inputs = 0 +> (1 +> (input +> outputs))
- out = head outputs
+ regsIn = [ fu const inputs (addrs!0)
+ , fu (+) inputs (addrs!1)
+ , fu (-) inputs (addrs!2)
+ , fu (*) inputs (addrs!3)
+ ]
+ inputs = 0 +> (1 +> (input +> regsOut))
+ out = head regsOut
\end{code}
\section{Related work}
The merits of polymorphic typing, combined with higher-order functions, are
now also recognized in the `main-stream' hardware description languages,
exemplified by the new \VHDL-2008 standard~\cite{VHDL2008}. \VHDL-2008 support
-for generics has been extended to types, allowing a developer to describe
-polymorphic components. Note that those types still require an explicit
-generic map, whereas types can be automatically inferred in \CLaSH. There are
-also no (generally available) \VHDL\ synthesis tools that currently support
-the \VHDL-2008 standard, and thus the synthesis of polymorphic types.
+for generics has been extended to types and subprograms, allowing a developer to describe components with polymorphic ports and function-valued arguments. Note that the types and subprograms still require an explicit generic map, whereas types can be automatically inferred, and function-values can be automatically propagated by the \CLaSH\ compiler. There are also no (generally available) \VHDL\ synthesis tools that currently support the \VHDL-2008 standard, and thus the synthesis of polymorphic types and function-valued arguments.
% Wired~\cite{Wired},, T-Ruby~\cite{T-Ruby}, Hydra~\cite{Hydra}.
%
\section{Conclusion}
-The conclusion goes here.
-
-
-
+This research demonstrates once more that functional languages are well suited
+for hardware descriptions: function applications provide an elegant notation
+for component instantiation. Where this research goes beyond the existing
+(functional) hardware descriptions languages is the inclusion of various
+choice elements, such as patter matching, that are well suited to describe the
+conditional assignments in control-oriented hardware. Besides being able to
+translate these basic constructs to synthesizable \VHDL, the prototype
+compiler can also correctly translate descriptions that contain both
+polymorphic types and function-valued arguments.
+
+Where recent functional hardware description languages have mostly opted to
+embed themselves in an existing functional language, this research features a
+`true' compiler. As a result there is a clear distinction between compile-time
+and run-time, which allows a myriad of choice constructs to be part of the
+actual circuit description; a feature the embedded hardware description
+languages do not offer.
+
+\section{Future Work}
+The choice of describing state explicitly as extra arguments and results can
+be seen as a mixed blessing. Even though the description that use state are
+usually very clear, one finds that dealing with unpacking, passing, receiving
+and repacking can become tedious and even error-prone, especially in the case
+of sub-states. Removing this boilerplate, or finding a more suitable
+abstraction mechanism would make \CLaSH\ easier to use.
+
+The transformations in normalization phase of the prototype compiler were
+developed in an ad-hoc manner, which makes the existence of many desirable
+properties unclear. Such properties include whether the complete set of
+transformations will always lead to a normal form or if the normalization
+process always terminates. Though various use cases suggests that these
+properties usually hold, they have not been formally proven. A systematic
+approach to defining the set of transformations allows one to proof that the
+earlier mentioned properties do indeed exist.
% conference papers do not normally have an appendix
projects / matthijs / master-project / dsd-paper.git / blobdiff