Chapters/Context.tex

   1 \chapter[chap:context]{Context}
   2   An obvious question that arises when starting any research is \quote{Hasn't
   3   this 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. However, functional languages were not nearly as
   7   advanced as they are now, and functional hardware description never really
   8   got off.
   9
  10   Recently, there have been some renewed efforts, especially using the Haskell
  11   language. Examples are Lava, ForSyde, ..., which are all a form of an
  12   embedded domain specific language. Each of these have a slightly different
  13   approach, but all of these do some trickery inside the Haskell language
  14   itself, meaning you write a program that generates a hardware circuit,
  15   instead of describing the circuit directly (either by running the haskell
  16   code after compilation, or using Template Haskell to inspect parts of the
  17   code you have written). This allows the full power of Haskell for generating
  18   a circuit, but only it also creates severe limitations in the use of the
  19   language (you can't use case statements in Lava, since they would be
  20   executed only once during circuit generation) and extra notational overhead.
  21
  22 TODO: Define (E)DSL
  23 TODO: References
  24
  25   \section{Conventional hardware description languages}
  26     Considering that we already have some hardware description language like
  27     \small{VHDL} and Verilog, why would we need anything else? By introducing
  28     the functional style to hardware description, we hope to obtain a hardware
  29     description language that is:
  30     \startitemize
  31       \item More consise. Functional programs are known for their conciseness,
  32       mostly caused by the ability to abstract just about any behaviour into a
  33       helper function. This is largely enabled by features like an advanced
  34       type system with polymorphism and higher order functions.
  35       \item Type-safer. Functional programs typically have a highly expressive
  36       type system, which makes it harder to write incorrect code. This is
  37       probably not only directly caused by the type system, so perhaps this
  38       advantage does not apply in hardware descriptions.
  39       \item Easy to process. Functional languages have nice properties like
  40       purity \refdef{purity} and single binding behaviour, which make it easy
  41       to apply program transformations and optimizations and could potentially
  42       simplify program verification.
  43     \stopitemize
  44
  45   \section{Existing functional hardware description languages}
  46     As noted above, we're not the first to walk this path. However, current
  47     embedded functional hardware description languages (in particular those
  48     using Haskell) are limited by:
  49     \startitemize
  50       \item Not all of Haskell's constructs can be captured by embedded domain
  51       specific languages. For example, an if or case expression is typically
  52       executed only once and only its result is reflected in the embedded
  53       description, not the if or case expression itself. Also, sharing and
  54       loops are non-trivial do properly and safely translate (though there is
  55       some work to fix this, but that has not been possible in a completely
  56       reliable way yet.  TODO: ref
  57       http://www.ittc.ku.edu/~andygill/paper.php?label=DSLExtract09).
  58       \item Some things are verbose to express. Especially ForSyDe suffers
  59       from a lot of notational overhead due to the Template Haskell approach
  60       used. Since conditional statements are not supported, a lot of Haskell's
  61       syntax sugar (if expressions, pattern matching, guards) cannot be used
  62       either, leading to more verbose notation as well.
  63       \item Polymorphism and higher order values are not supported within the
  64       embedded language. The use of Haskell as a host language allows the use
  65       of polymorphism and higher order functions at circuit generation time
  66       (even for free, without any additional cost on the \small{EDSL}
  67       programmers), but the described circuits do not have any polymorphism
  68       or higher order functions, which can be limiting (TODO: How true or
  69       appropriate is this point?).
  70     \stopitemize