Add the prototype to the research goals.

[matthijs/master-project/report.git] / Chapters / Prototype.tex

diff --git a/Chapters/Prototype.tex b/Chapters/Prototype.tex
index 7cd5ea5e90da46e8286902a2eb34101406f8f61a..257328e58d1da08923701176403ce0e06f5adb8d 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{Input 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,7 +50,7 @@
 
     TODO: Was Haskell really a good choice? Perhaps say this somewhere else?
 
-  \subsection{Output format}
+  \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
@@ -66,7 +66,7 @@
     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).
+    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