X-Git-Url: https://git.stderr.nl/gitweb?p=matthijs%2Fmaster-project%2Freport.git;a=blobdiff_plain;f=Chapters%2FHardwareDescription.tex;h=ff4b0c0b3143c78983f6464ad52d95e090b5488f;hp=bf797f62a7356c02a0a40c1a8339d7f0f4017637;hb=d92aa4307ca45f07c6ae50056e08ffc874839756;hpb=549db3f3ac20300b86403b0aa4320d7bf3945b5c

diff --git a/Chapters/HardwareDescription.tex b/Chapters/HardwareDescription.tex
index bf797f6..ff4b0c0 100644
--- a/Chapters/HardwareDescription.tex
+++ b/Chapters/HardwareDescription.tex
@@ -56,7 +56,6 @@
 
 
   \section[sec:description:application]{Function application}
-  \todo{Sidenote: Inputs vs arguments}
   The basic syntactic elements of a functional program are functions and
   function application. These have a single obvious \small{VHDL}
   translation: Each top level function becomes a hardware component, where each
@@ -136,8 +135,7 @@ and3 a b c = and (and a b) c
     the condition is false.
 
     This \hs{if} function would then essentially describe a multiplexer and
-    allows us to describe any architecture that uses multiplexers. \fxnote{Are
-    there other mechanisms of choice in hardware?}
+    allows us to describe any architecture that uses multiplexers.
 
     However, to be able to describe our hardware in a more convenient way, we
     also want to translate Haskell's choice mechanisms. The easiest of these
@@ -146,7 +144,26 @@ and3 a b c = and (and a b) c
     simply be translated to a conditional assignment, where the conditions use
     equality comparisons against the constructors in the \hs{case} expressions.
 
-    \todo{Assignment vs multiplexers}
+    \placeintermezzo{}{
+      \defref{substitution notation}
+      \startframedtext[width=8cm,background=box,frame=no]
+      \startalignment[center]
+        {\tfa Arguments / results vs. inputs / outputs}
+      \stopalignment
+      \blank[medium]
+        Due to the translation chosen for function application, there is a
+        very strong relation between arguments, results, inputs and outputs.
+        For clarity, the former two will always refer to the arguments and
+        results in the functional description (either Haskell or Core). The
+        latter two will refer to input and output ports in the generated
+        \VHDL.
+
+        Even though these concepts seem to be nearly identical, when stateful
+        functions are introduces we will see arguments and results that will
+        not get translated into input and output ports, making this
+        distinction more important.
+      \stopframedtext
+    }
 
     In \in{example}[ex:CaseInv] a simple \hs{case} expression is shown,
     scrutinizing a boolean value. The corresponding architecture has a
@@ -163,8 +180,6 @@ and3 a b c = and (and a b) c
     Optimizations such as these are left for the \VHDL\ synthesizer, which
     handles them very well.
 
-    \todo{Be more explicit about >2 alternatives}
-
     \startbuffer[CaseInv]
     inv :: Bool -> Bool
     inv x = case x of
@@ -235,6 +250,11 @@ and3 a b c = and (and a b) c
     nested) multiplexers. These multiplexers are driven by comparators and
     other logic, that check each pattern in turn.
 
+    In these examples we have seen only binary case expressions and pattern
+    matches (\ie, with two alternatives). In practice, case expressions can
+    choose between more than two values, resulting in a number of nested
+    multiplexers.
+
   \section{Types}
     Translation of two most basic functional concepts has been
     discussed: Function application and choice. Before looking further