X-Git-Url: https://git.stderr.nl/gitweb?p=matthijs%2Fmaster-project%2Freport.git;a=blobdiff_plain;f=Chapters%2FContext.tex;h=9213c5515994ba0cc97e25b8d5f7854c6bcbae97;hp=ca65c1233eec2e9b8d017c4b1245d6c16d1ddbf5;hb=70c17aa5346776371e1d66ecc0371c0a3ce179d2;hpb=3fc7078e3369d9e916b3663f04c51bb587434d14

diff --git a/Chapters/Context.tex b/Chapters/Context.tex
index ca65c12..9213c55 100644
--- a/Chapters/Context.tex
+++ b/Chapters/Context.tex
@@ -1,3 +1,81 @@
 \chapter[chap:context]{Context}
-Other FHDLs (short, Christiaan has details)
-Advantages of clash / why clash?
+  An obvious question that arises when starting any research is \quote{Has
+  this not been done before?} Using a functional language for describing hardware
+  is not a new idea at all. In fact, there has been research into functional
+  hardware description even before the conventional hardware description
+  languages were created. \todo{Reference about early FHDLs} However,
+  functional languages were not nearly as advanced as they are now, and
+  functional hardware description never really got off. 
+
+\todo{Add references}
+  Recently, there have been some renewed efforts, especially using the Haskell
+  functional language. Examples are Lava, ForSyde, ..., which are all a form of an
+  embedded domain specific language. Each of these have a slightly different
+  approach, but all of these do some trickery inside the Haskell language
+  itself, meaning you write a program that generates a hardware circuit,
+  instead of describing the circuit directly (either by running the haskell
+  code after compilation, or using Template Haskell to inspect parts of the
+  code you have written). This allows the full power of Haskell for generating
+  a circuit. However it also creates severe limitations in the use of the
+  language (you can't use case statements in Lava, since they would be
+  executed only once during circuit generation) and extra notational overhead.
+
+\fxnote{There should be a section on DSLs here}
+
+  We will now have a look at the existing hardware description languages,
+  both conventional and functional to see the fields in which Cλash is
+  operating.
+
+  \section{Conventional hardware description languages}
+    Considering that we already have some hardware description languages like
+    \small{VHDL} and Verilog, why would we need anything else? By introducing
+    the functional style to hardware description, we hope to obtain a hardware
+    description language that is:
+    \startitemize
+      \item More consise. Functional programs are known for their conciseness
+      and ability to abstract away  common patterns.  This is largely enabled
+      by features like an advanced type system with polymorphism and higher
+      order functions.
+      \todo{Does this apply to FHDLs equally?}
+      \item Type-safer. Functional programs typically have a highly expressive
+      type system, which makes it harder to write incorrect code.
+      \item Easy to process. Functional languages have nice properties like
+      purity \refdef{purity} and single binding behaviour, which make it easy
+      to apply program transformations and optimizations and could potentially
+      simplify program verification.
+    \stopitemize
+  
+  \section{Existing functional hardware description languages}
+    As noted above, we're not the first to walk this path. However, current
+    embedded functional hardware description languages (in particular those
+    using Haskell) are limited by:\todo{Separate TH and EDSL approaches
+    better}
+    \startitemize
+      \item Not all of Haskell's constructs can be captured by embedded domain
+      specific languages. For example, an if or case expression is typically
+      executed only once and only its result is reflected in the embedded
+      description, not the if or case expression itself. Also, sharing of
+      variables (\eg, using the same variable twice while only calculating it
+      once) and cycles in circuits are non-trivial to properly and safely
+      translate (though there is some work to fix this, but that has not been
+      possible in a completely reliable way yet.  \todo{ref
+      http://www.ittc.ku.edu/~andygill/paper.php?label=DSLExtract09}
+      \item Some things are verbose to express. Especially ForSyDe suffers
+      from a lot of notational overhead due to the Template Haskell approach
+      used. Since conditional statements are not supported, a lot of Haskell's
+      syntax sugar (if expressions, pattern matching, guards) cannot be used
+      either, leading to more verbose notation as well.
+      \item Polymorphism and higher order values are not supported within the
+      embedded language. The use of Haskell as a host language allows the use
+      of polymorphism and higher order functions at circuit generation time
+      (even for free, without any additional cost on the \small{EDSL}
+      programmers), but the described circuits do not have any polymorphism
+      or higher order functions, which can be limiting. \todo{How true or
+      appropriate is this point?}
+      \todo[left]{Function structure gets lost (in Lava)}
+    \stopitemize
+
+    \todo[text]{Complete translation in TH is complex: Works with Haskell AST
+    instead of Core}
+
+% vim: set sw=2 sts=2 expandtab: