Chapters/Conclusions.tex

   1 \chapter[chap:conclusions]{Conclusions}
   2 At the end of this research, we have created a system called Cλash, which
   3 allows us to translate hardware descriptions written in Haskell to be
   4 translated to \VHDL, and be programmed into an FPGA.
   5
   6 In this research, we have seen that a functional language is well suited
   7 for hardware descriptions. Function applications provide elegant notation for
   8 component instantiation and the various choice mechanisms (pattern matching,
   9 case expressions, if expressions) are well suited to describe conditional
  10 assigment in the hardware.
  11
  12 Useful features from the functional perspective, like polymorphism and higher
  13 order functions and expressions also prove suited to describe hardware
  14 and our implementation shows that they can be translated to \VHDL as
  15 well.
  16
  17 Using Haskell as as source language in this research has proven
  18 fruitful. It has enabled creating a prototype rapidly, to experiment
  19 with various language features in Cλash. Even supporting more complex
  20 features like polymorphism and higher order values has been possible. If
  21 a new language and compiler would have been designed from scratch, that
  22 language would not have been nearly as advanced as current Cλash.
  23
  24 However, Haskell might not have been the best choice for describing
  25 hardware. Some of the expressiveness it offers is not appropriate for
  26 hardware description (such as infinite recursion or recursive types),
  27 but also some extra syntax sugar could be useful (to reduce
  28 boilerplate).
  29
  30 The lack of real dependent typing support in Haskell has been a burden.
  31 Haskell provides the tools to create some type level programming
  32 constructs (and is improving fast), but other language might have
  33 support for more advanced dependent types (and even type level
  34 operations) as a fundamental part of the language. The need for
  35 dependent typing is particularly present in Cλash to be able to fix some
  36 properties (list length, recursion depth, etc.) at compile time. Having
  37 better support for dependent typing might allow the use of typesafe
  38 recursion in Cλash, though this is fundamentally still a hard problem.
  39
  40 The choice of describing state very explicitly as extra arguments and
  41 results is a mixed blessing. It provides very explicit specification of
  42 state, which allows for very clear descriptions. This also allows for
  43 easy modification of the description in our normalization program, since
  44 state can be handled just like other arguments and results.
  45
  46 On the other hand, the explictness of the states and in particular
  47 substates, mean that more complex descriptions can become cumbersome
  48 very quick.  One finds that dealing with unpacking, passing, receiving
  49 and repacking becomes tedious and even errorprone. Removing some of this
  50 boilerplate would make the language even easier to use.
  51
  52 On the whole, the usefulness of Cλash for describing hardware is not
  53 completely clear yet. Most elements of the language haven proven
  54 suitable, and even a real world hardware circuit (the reducer \todo{ref
  55 christiaan}) has been implemented. However, the language has not been
  56 used during a complete design process, where its rapid prototyping and
  57 reusability qualities could become real advantages, or perhaps the state
  58 boilerplate or synchronicity limitations could become real problems.
  59
  60 It is expected that Cλash will be used as a tool in education at the
  61 University of Twente soon, hopefully this will provide a better insight
  62 in how the system performs.
  63
  64 The general design of the prototype (A frontend that desugares into a
  65 small, but functional and typed language, a transformation
  66 system that works on this small language, and a simple backend) has
  67 worked well and should probably be preserved. Especially the
  68 transformation based normalization system is suitable. It is easy to
  69 program a transformation in the prototype, though it is not trivial to
  70 maintain enough overview to guarantee that the system is correct and
  71 complete. In fact, the current set of transformations is probably not
  72 complete yet, in particular when stateful descriptions are involved.
  73 However, the system can be (and has been) described in a mathematical
  74 sense, allowing us to reason about it and probably also prove various
  75 correctness properties in the future.
  76
  77 The scope of this research has been limited to structural descriptions
  78 that are synchronous in a single clock domain using cycle accurate
  79 designs. Even though this is a broad spectrum already, it may turn out
  80 that this scope is too narrow for practical use of Cλash. Most people
  81 that hear about using a functional language for hardware description
  82 instantly hope to be able to provide a concise mathematical description
  83 of their algorithm and have the hardware generated for them. Since this
  84 is obviously a different problem alltogether, we could not have hoped to
  85 even start solving it. However, hopefully the current Cλash system
  86 provides a solid base on top of which further experimentation with
  87 functional descriptions can be built.