1 \chapter[chap:context]{Context}
2 An obvious question that arises when starting any research is \quote{Has
3 this not been done before?} Using a functional language for describing hardware
4 is not a new idea at all. In fact, there has been research into functional
5 hardware description even before the conventional hardware description
6 languages were created. \todo{Reference about early FHDLs} However,
7 functional languages were not nearly as advanced as they are now, and
8 functional hardware description never really got off.
11 Recently, there have been some renewed efforts, especially using the Haskell
12 functional language. Examples are Lava, ForSyde, ..., which are all a form of an
13 embedded domain specific language. Each of these have a slightly different
14 approach, but all of these do some trickery inside the Haskell language
15 itself, meaning you write a program that generates a hardware circuit,
16 instead of describing the circuit directly (either by running the haskell
17 code after compilation, or using Template Haskell to inspect parts of the
18 code you have written). This allows the full power of Haskell for generating
19 a circuit. However it also creates severe limitations in the use of the
20 language (you can't use case statements in Lava, since they would be
21 executed only once during circuit generation) and extra notational overhead.
23 \fxnote{There should be a section on DSLs here}
25 We will now have a look at the existing hardware description languages,
26 both conventional and functional to see the fields in which Cλash is
29 \section{Conventional hardware description languages}
30 Considering that we already have some hardware description languages like
31 \small{VHDL} and Verilog, why would we need anything else? By introducing
32 the functional style to hardware description, we hope to obtain a hardware
33 description language that is:
35 \item More consise. Functional programs are known for their conciseness
36 and ability to abstract away common patterns. This is largely enabled
37 by features like an advanced type system with polymorphism and higher
39 \todo{Does this apply to FHDLs equally?}
40 \item Type-safer. Functional programs typically have a highly expressive
41 type system, which makes it harder to write incorrect code.
42 \item Easy to process. Functional languages have nice properties like
43 purity \refdef{purity} and single binding behaviour, which make it easy
44 to apply program transformations and optimizations and could potentially
45 simplify program verification.
48 \section{Existing functional hardware description languages}
49 As noted above, we're not the first to walk this path. However, current
50 embedded functional hardware description languages (in particular those
51 using Haskell) are limited by:\todo{Separate TH and EDSL approaches
54 \item Not all of Haskell's constructs can be captured by embedded domain
55 specific languages. For example, an if or case expression is typically
56 executed only once and only its result is reflected in the embedded
57 description, not the if or case expression itself. Also, sharing of
58 variables (\eg, using the same variable twice while only calculating it
59 once) and cycles in circuits are non-trivial to properly and safely
60 translate (though there is some work to fix this, but that has not been
61 possible in a completely reliable way yet. \todo{ref
62 http://www.ittc.ku.edu/~andygill/paper.php?label=DSLExtract09}
63 \item Some things are verbose to express. Especially ForSyDe suffers
64 from a lot of notational overhead due to the Template Haskell approach
65 used. Since conditional statements are not supported, a lot of Haskell's
66 syntax sugar (if expressions, pattern matching, guards) cannot be used
67 either, leading to more verbose notation as well.
68 \item Polymorphism and higher order values are not supported within the
69 embedded language. The use of Haskell as a host language allows the use
70 of polymorphism and higher order functions at circuit generation time
71 (even for free, without any additional cost on the \small{EDSL}
72 programmers), but the described circuits do not have any polymorphism
73 or higher order functions, which can be limiting. \todo{How true or
74 appropriate is this point?}
75 \todo[left]{Function structure gets lost (in Lava)}
78 \todo[text]{Complete translation in TH is complex: Works with Haskell AST