lots of work!), using an existing language is the obvious choice. This
also has the advantage that a large set of language features is available
to experiment with and it is easy to find which features apply well and
- which do not. A possible second prototype could use a custom language with
- just the useful features (and possibly extra features that are specific to
+ which do not. Another import advantage of using an existing language, is
+ that simulation of the code becomes trivial. Since there are existing
+ compilers and interpreters that can run the hardware description directly,
+ it can be simulated without also having to write an interpreter for the
+ new language.
+
+ A possible second prototype could use a custom language with just the useful
+ features (and possibly extra features that are specific to
the domain of hardware description as well).
- The second choice is which of the many existing languages to use. As
+ The second choice to be made is which of the many existing languages to use. As
mentioned before, the chosen language is Haskell. This choice has not been the
result of a thorough comparison of languages, for the simple reason that
the requirements on the language were completely unclear at the start of
could achieve a similar amount of optimization in our prototype (nor
should it be a goal, considering this is just a prototype).
+ \placeintermezzo{}{
+ \startframedtext[width=8cm,background=box,frame=no]
+ \startalignment[center]
+ {\tfa Translation vs. compilation vs. synthesis}
+ \stopalignment
+ \blank[medium]
+ 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.
+
+ 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
+ generation}.
+ \stopframedtext
+ }
+
Note that we will be using \small{VHDL} as our output language, but will
not use its full expressive power. Our output will be limited to using
simple, structural descriptions, without any complex behavioural
to switch to \small{EDIF} in the future, with minimal changes to the
prototype.
+ \section{Simulation and synthesis}
+ As mentioned above, by using the Haskell language, we get simulation of
+ our hardware descriptions almost for free. The only thing that is needed
+ is to provide a Haskell implementation of all built-in functions that can
+ be used by the Haskell interpreter to simulate them.
+
+ 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
+ of the Haskell description exactly, any simulation done in Haskell
+ \emph{should} produce identical results as the synthesized hardware.
+
\section[sec:prototype:design]{Prototype design}
As suggested above, we will use the Glasgow Haskell Compiler (\small{GHC}) to
implement our prototype compiler. To understand the design of the
reason, \small{GHC} runs its simplifications and optimizations on the core
representation as well \cite[jones96].
- However, we will use the normal core representation, not the simplified
- core. Reasons for this are detailed below. \todo{Ref}
+ We will use the normal Core representation, not the simplified Core. Even
+ 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
+ (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
+ \in{section}[sec:normalization:stateproblems].
The final prototype roughly consists of three steps:
% Implementation issues: state splitting, linking input to output state,
% checking usage constraints on state variables.
%
-% \todo{Implementation issues: Separate compilation, simplified core.}
%
% vim: set sw=2 sts=2 expandtab:
projects / matthijs / master-project / report.git / blobdiff