Update outline.

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

diff --git a/Chapters/Context.tex b/Chapters/Context.tex
index ca65c1233eec2e9b8d017c4b1245d6c16d1ddbf5..827f61f5506f5f9bfab3c61b863683ab8720f704 100644 (file)
--- a/Chapters/Context.tex
+++ b/Chapters/Context.tex
@@ -1,3 +1,70 @@
 \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{Hasn't
+  this 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. However, functional languages were not nearly as
+  advanced as they are now, and functional hardware description never really
+  got off. 
+
+  Recently, there have been some renewed efforts, especially using the Haskell
+  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, but only 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.
+
+TODO: Define (E)DSL
+TODO: References
+
+  \section{Conventional hardware description languages}
+    Considering that we already have some hardware description language 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,
+      mostly caused by the ability to abstract just about any behaviour into a
+      helper function. This is largely enabled by features like an advanced
+      type system with polymorphism and higher order functions.
+      \item Type-safer. Functional programs typically have a highly expressive
+      type system, which makes it harder to write incorrect code. This is
+      probably not only directly caused by the type system, so perhaps this
+      advantage does not apply in hardware descriptions.
+      \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:
+    \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 and
+      loops are non-trivial do 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?).
+    \stopitemize