Chapters/Conclusions.tex

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