X-Git-Url: https://git.stderr.nl/gitweb?p=matthijs%2Fmaster-project%2Freport.git;a=blobdiff_plain;f=Chapters%2FPrototype.tex;h=d5ae72fd84f32b6375ee434496d12136732b8b3f;hp=644ce01ce4cf4e6629a80fc53958d4d7d789e98d;hb=4a1874f15102d7ad201d9f1f7fa8800bebff4ffc;hpb=c9258d5e0a89adb2f9f87ce5c668ba2a561d6bf3

diff --git a/Chapters/Prototype.tex b/Chapters/Prototype.tex
index 644ce01..d5ae72f 100644
--- a/Chapters/Prototype.tex
+++ b/Chapters/Prototype.tex
@@ -11,7 +11,7 @@
   has gone through a number of design iterations which we will not completely
   describe here.
 
-  \section{Choice of language}
+  \section[sec:prototype:input]{Input language}
     When implementing this prototype, the first question to ask is: What
     (functional) language will we use to describe our hardware? (Note that
     this does not concern the \emph{implementation language} of the compiler,
@@ -50,8 +50,49 @@
 
     TODO: Was Haskell really a good choice? Perhaps say this somewhere else?
 
-    \subsection{Output language or format}
-        VHDL / Verilog / EDIF etc. Why VHDL?
+  \section[sec:prototype:output]{Output format}
+    The second important question is: What will be our output format? Since
+    our prototype won't be able to program FPGA's directly, we'll have to have
+    output our hardware in some format that can be later processed and
+    programmed by other tools.
+
+    Looking at other tools in the industry, the Electronic Design Interchange
+    Format (\small{EDIF}) is commonly used for storing intermediate
+    \emph{netlists} (lists of components and connections between these
+    components) and is commonly the target for \small{VHDL} and Verilog
+    compilers.
+
+    However, \small{EDIF} is not completely tool-independent. It specifies a
+    meta-format, but the hardware components that can be used vary between
+    various tool and hardware vendors, as well as the interpretation of the
+    \small{EDIF} standard (TODO Is this still true? Reference:
+    http://delivery.acm.org/10.1145/80000/74534/p803-li.pdf?key1=74534\&key2=8370537521\&coll=GUIDE\&dl=GUIDE\&CFID=61207158\&CFTOKEN=61908473).
+   
+    This means that when working with EDIF, our prototype would become
+    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'd like to use for verifying,
+    simulating and draw pretty pictures of our output (like Precision, or
+    QuestaSim) work on \small{VHDL} or Verilog input (TODO: Is this really
+    true?).
+
+    For these reasons, we will use \small{VHDL} as our output language.
+    Verilog is not used 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.
+
+    An added advantage of using VHDL is that we can profit from existing
+    optimizations in VHDL synthesizers. A lot of optimizations are done on the
+    VHDL level by existing tools. These tools have years of experience in this
+    field, so it would not be reasonable to assume we could achieve a similar
+    amount of optimization in our prototype (nor should it be a goal,
+    considering this is just a prototype).
+
+    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 behavioural descriptions
+    (which might not be supported by all tools).
 
   \section{Prototype design}
     As stated above, we will use the Glasgow Haskell Compiler (\small{GHC}) to
@@ -306,7 +347,7 @@ let bndr = value in body
     \stopdesc
     \startdesc{Recursive let expression}
 \startlambda
-let 
+letrec
   bndr1 = value1
   \vdots
   bndrn = valuen