X-Git-Url: https://git.stderr.nl/gitweb?p=matthijs%2Fmaster-project%2Freport.git;a=blobdiff_plain;f=Chapters%2FPrototype.tex;h=257328e58d1da08923701176403ce0e06f5adb8d;hp=e11788611fa6ab3ae827c3fd13a69602415d4368;hb=9a64968e619e6cf17f914e59f90e1d4996e8724c;hpb=af95dbcdd9ed866f9ae9100dfc82e3bc051ed54c

diff --git a/Chapters/Prototype.tex b/Chapters/Prototype.tex
index e117886..257328e 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,6 +50,50 @@
 
     TODO: Was Haskell really a good choice? Perhaps say this somewhere else?
 
+  \subsection[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
     implement our prototype compiler. To understand the design of the
@@ -303,7 +347,7 @@ let bndr = value in body
     \stopdesc
     \startdesc{Recursive let expression}
 \startlambda
-let 
+letrec
   bndr1 = value1
   \vdots
   bndrn = valuen
@@ -710,9 +754,8 @@ fstint = λa.λb.fst @Int @Int a b
           \subsection[sec:prototype:separate]{Separate compilation}
           - Simplified core?
 
-        Haskell language coverage / constraints
-                Recursion
-                Builtin types
-                Custom types (Sum types, product types)
-                Function types / higher order expressions
-
+  \section{Haskell language coverage and constraints}
+    Recursion
+    Builtin types
+    Custom types (Sum types, product types)
+    Function types / higher order expressions