Update outline.

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

diff --git a/Chapters/Prototype.tex b/Chapters/Prototype.tex
index 7cd5ea5e90da46e8286902a2eb34101406f8f61a..d5ae72fd84f32b6375ee434496d12136732b8b3f 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}
+  \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
@@ -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