Add a section on simulation.

diff --git a/Chapters/Prototype.tex b/Chapters/Prototype.tex
index e5cbb9df65b536214816eed6a2808359e7d86f90..7677cde8a990aac96276880179b00083002bf10d 100644 (file)
--- a/Chapters/Prototype.tex
+++ b/Chapters/Prototype.tex
@@ -53,11 +53,17 @@
     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
     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 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
     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


@@ -104,6 +110,25 @@
     could achieve a similar amount of optimization in our prototype (nor
     should it be a goal, considering this is just a prototype).
 
     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
     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


@@ -114,6 +139,18 @@
     to switch to \small{EDIF} in the future, with minimal changes to the
     prototype.
 
     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
   \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

diff --git a/Outline b/Outline
index c0b7ad263fda4f7bfb3702b7d8590a5f9faad698..c61508a7f88c5b7ec026715e2e816309314ea9f2 100644 (file)
--- a/Outline
+++ b/Outline
@@ -44,7 +44,6 @@ Future work
         Don't care
 
 TODO: Define user / developer
         Don't care
 
 TODO: Define user / developer

-TODO: Comiler vs translator

 TODO: Hardware description / model vs program
 TODO: Separate compilation / Prelude
 TODO: Add case binder removal transformation
 TODO: Hardware description / model vs program
 TODO: Separate compilation / Prelude
 TODO: Add case binder removal transformation