Update piece about state to show relation between the run function and the statefull...

[matthijs/master-project/dsd-paper.git] / cλash.lhs

diff --git a/cλash.lhs b/cλash.lhs
index dfd0a4fdc5f58595fdb890890dca5f30a112a102..85709be26568b10604138c111cd659cca186f2b9 100644 (file)
--- a/cλash.lhs
+++ b/cλash.lhs
@@ -950,7 +950,7 @@ circuit~\cite{reductioncircuit} for floating point numbers.
     expression, that adds one to every element of a vector:
 
     \begin{code}
-    map ((+) 1) xs
+    map (+ 1) xs
     \end{code}
 
     Here, the expression \hs{(+) 1} is the partial application of the
@@ -1041,8 +1041,10 @@ circuit~\cite{reductioncircuit} for floating point numbers.
     first input value, \hs{i}. The result is the first output value, \hs{o}, 
     and the updated state \hs{s'}. The next iteration of the \hs{run} function 
     is then called with the updated state, \hs{s'}, and the rest of the 
-    inputs, \hs{inps}. Each value in the input list corresponds to exactly one 
-    cycle of the (implicit) clock.
+    inputs, \hs{inps}. It is assumed that there is one input per clock cycle.
+    Also note how the order of the input, output, and state in the \hs{run} 
+    function corresponds with the order of the input, output and state of the 
+    \hs{macS} function described earlier.
     
     As both the \hs{run} function, the hardware description, and the test 
     inputs are plain Haskell, the complete simulation can be compiled to an 
@@ -1052,7 +1054,7 @@ circuit~\cite{reductioncircuit} for floating point numbers.
     simulation, where the executable binary has an additional simulation speed 
     bonus in case there is a large set of test inputs.
     
-\section{\CLaSH\ prototype}
+\section{\CLaSH\ compiler}
 
 The \CLaSH\ language as presented above can be translated to \VHDL\ using
 the prototype \CLaSH\ compiler. This compiler allows experimentation with
@@ -1069,7 +1071,7 @@ The prototype heavily uses \GHC, the Glasgow Haskell Compiler.
 \Cref{img:compilerpipeline} shows the \CLaSH\ compiler pipeline. As you can 
 see, the front-end is completely reused from \GHC, which allows the \CLaSH\ 
 prototype to support most of the Haskell Language. The \GHC\ front-end 
-produces the program in the \emph{Core} format, which is a very small, 
+produces the program in the \emph{Core}~\cite{Sulzmann2007} format, which is a very small, 
 functional, typed language which is relatively easy to process.
 
 The second step in the compilation process is \emph{normalization}. This
@@ -1160,6 +1162,44 @@ is depicted in \Cref{img:4tapfir}.
 \label{img:4tapfir}
 \end{figure}
 
+
+\subsection{Higher order CPU}
+
+
+\begin{code}
+type FuState = State Word
+fu :: (a -> a -> a)
+      -> [a]:n
+      -> (RangedWord n, RangedWord n)
+      -> FuState
+      -> (FuState, a)
+fu op inputs (addr1, addr2) (State out) =
+  (State out', out)
+  where
+    in1  = inputs!addr1
+    in2  = inputs!addr2
+    out' = op in1 in2
+\end{code}
+
+\begin{code}
+type CpuState = State [FuState]:4
+cpu :: Word 
+       -> [(RangedWord 7, RangedWord 7)]:4
+       -> CpuState
+       -> (CpuState, Word)
+cpu input addrs (State fuss) =
+  (State fuss', out)
+  where
+    fures = [ fu const inputs!0 fuss!0
+            , fu (+)   inputs!1 fuss!1
+            , fu (-)   inputs!2 fuss!2
+            , fu (*)   inputs!3 fuss!3
+            ]
+    (fuss', outputs) = unzip fures
+    inputs = 0 +> 1 +> input +> outputs
+    out = head outputs
+\end{code}
+
 \section{Related work}
 Many functional hardware description languages have been developed over the 
 years. Early work includes such languages as $\mu$\acro{FP}~\cite{muFP}, an