X-Git-Url: https://git.stderr.nl/gitweb?p=matthijs%2Fmaster-project%2Freport.git;a=blobdiff_plain;f=Chapters%2FPrototype.tex;h=d5ae72fd84f32b6375ee434496d12136732b8b3f;hp=7cd5ea5e90da46e8286902a2eb34101406f8f61a;hb=a472d8d94908d8f466a4cafe4d55c4c9410161d8;hpb=42ec9c78da464de1ed58509a6edaa454c6a225bc

diff --git a/Chapters/Prototype.tex b/Chapters/Prototype.tex
index 7cd5ea5..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{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