Add a section on the output format.

diff --git a/Chapters/Prototype.tex b/Chapters/Prototype.tex
index 85e7fb2816ffb04aeb898b4ffebb5e36cd23fac4..7cd5ea5e90da46e8286902a2eb34101406f8f61a 100644 (file)
--- 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{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?
+  \subsection{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