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}
-% \thanks{Supported through FP7 project: S(o)OS (248465)}
+\thanks{Supported through the FP7 project: S(o)OS (248465)}
}
% \and
% \IEEEauthorblockN{Homer Simpson}
\begin{abstract}
%\boldmath
\CLaSH\ is a functional hardware description language that borrows both its
-syntax and semantics from the functional programming language Haskell. Circuit
-descriptions can be translated to synthesizable VHDL using the prototype
-\CLaSH\ compiler. As the circuit descriptions are made in plain Haskell,
-simulations can also be compiled by a Haskell compiler.
-
-The use of polymorphism and higher-order functions allow a circuit designer to
-describe more abstract and general specifications than are possible in the
-traditional hardware description languages.
+syntax and semantics from the functional programming language Haskell. Due to
+the abstraction and generality offered by polymorphism and higher-order
+functions, a circuit designer can describe circuits in a more natural way than
+he could in the traditional hardware description languages.
+
+Circuit descriptions can be translated to synthesizable VHDL using the
+prototype \CLaSH\ compiler. As the circuit descriptions, simulation code, and
+test input are plain Haskell, complete simulations can be compiled to an
+executable binary by a Haskell compiler allowing high-speed simulation and
+analysis.
+
+Stateful descriptions are supported by explicitly making the current state an
+argument of the function, and the updated state part of the result. In this
+sense, the descriptions made in \CLaSH\ are the combinational parts of a mealy
+machine.
\end{abstract}
% IEEEtran.cls defaults to using nonbold math in the Abstract.
% This preserves the distinction between vectors and scalars. However,
\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
- fuss' = [ 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)
- ]
- inputs = 0 +> (1 +> (input +> fuss))
- out = head fuss
+ 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}
\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