Add sitenote about arguments vs. inputs.

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

diff --git a/Chapters/HardwareDescription.tex b/Chapters/HardwareDescription.tex
index bf797f62a7356c02a0a40c1a8339d7f0f4017637..ff4b0c0b3143c78983f6464ad52d95e090b5488f 100644 (file)
--- a/Chapters/HardwareDescription.tex
+++ b/Chapters/HardwareDescription.tex
@@ -56,7 +56,6 @@
 
 
   \section[sec:description:application]{Function application}
 
 
   \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
   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
     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
 
     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.
 
     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
 
     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.
 
     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
     \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.
 
     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
   \section{Types}
     Translation of two most basic functional concepts has been
     discussed: Function application and choice. Before looking further