Add some context.

diff --git a/Chapters/Context.tex b/Chapters/Context.tex
index ca65c1233eec2e9b8d017c4b1245d6c16d1ddbf5..4b529c924afcb2e3130486de69874805b2be30e6 100644 (file)
--- a/Chapters/Context.tex
+++ b/Chapters/Context.tex
@@ -1,3 +1,36 @@
 \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
+
+  Advantages over conventional HDLs
+   - More consise
+   - More expressive
+   - Easy to transform / optimize / etc.
+
+  Advantages over existing FHDLs
+   - More control
+   - Full Haskell available
+   - Concise notation
+
+  Disadvantages over existing FHDLs
+   - More work to implement advanced things