X-Git-Url: https://git.stderr.nl/gitweb?p=matthijs%2Fmaster-project%2Freport.git;a=blobdiff_plain;f=Chapters%2FConclusions.tex;h=0b378996293bedeafed9d3d2f982b6f175bbef34;hp=c12e99d0665c6d3f172573f86993804c5670bca3;hb=b2047c9f1622d62aecc6708dd19c38b14810f275;hpb=901c9881c60ac1897aa8efb63d082798272e1ae7 diff --git a/Chapters/Conclusions.tex b/Chapters/Conclusions.tex index c12e99d..0b37899 100644 --- a/Chapters/Conclusions.tex +++ b/Chapters/Conclusions.tex @@ -10,29 +10,81 @@ case expressions, if expressions) are well suited to describe conditional assigment in the hardware. Useful features from the functional perspective, like polymorphism and higher -order functions and expressions are also well-suited for translation to -hardware. +order functions and expressions also prove suitable to describe hardware +and our implementation shows that they can be translated to \VHDL as +well. -Using Haskell enabled a rapid prototype supporting complex features like -polymorphism and higher order values. Mostly typechecker would have been -complicated otherwise. +A prototype compiler was created in this research. For this prototype the +Haskell language was chosen as the input language, instead of creating a new +language from scratch. This has enabled creating the prototype rapidly, +allowing for experimenting with various functional language features and +interpretations in Cλash. Even supporting more complex features like +polymorphism and higher order values has been possible. If a new language and +compiler would have been designed from scratch, that new language would not +have been nearly as advanced as current Cλash. -Haskell is not the perfect language. Some of the expressiveness it offers is -not appropriate for hardware description, but also some extra syntax sugar -could be useful. Lack of type-safe recursion is a big downside (but also a -hard problem!), perhaps improvements to Haskell will fix this. +However, Haskell might not have been the best choice for describing +hardware. Some of the expressiveness it offers is not appropriate for +hardware description (such as infinite recursion or recursive types), +but also some extra syntax sugar could be useful (to reduce +boilerplate). -Explicit state descriptions... +The lack of real dependent typing support in Haskell has been a burden. +Haskell provides the tools to create some type level programming +constructs (and is improving fast), but other language might have +support for more advanced dependent types (and even type level +operations) as a fundamental part of the language. The need for +dependent typing is particularly present in Cλash to be able to fix some +properties (list length, recursion depth, etc.) at compile time. Having +better support for dependent typing might allow the use of typesafe +recursion in Cλash, though this is fundamentally still a hard problem. -Transformation based system is suitable, allows for reasoning about the -system. Easy to specify transformation in the prototype. Implmentation is stil -lacking, especially when combined with pattern matching. +The choice of describing state very explicitly as extra arguments and +results is a mixed blessing. It provides very explicit specification of +state, which allows for very clear descriptions. This also allows for +easy modification of the description in our normalization program, since +state can be handled just like other arguments and results. -General design (frontend + desugaring into small language, transformation -system, simple backend) works well and should be preserved. +On the other hand, the explicitness of the states and in particular +substates, mean that more complex descriptions can become cumbersome +very quickly. One finds that dealing with unpacking, passing, receiving +and repacking becomes tedious and even errorprone. Removing some of this +boilerplate would make the language even easier to use. -Usefulness of Cλash is not completely clear yet. Advanced features work -nicely, as well as choice, but no extensive testing (actual design projects) -have been done yet. Use in education possible due to prototype. +On the whole, the usefulness of Cλash for describing hardware is not +completely clear yet. Most elements of the language haven proven +suitable, and even a real world hardware circuit (the reducer \todo{ref +christiaan}) has been implemented. However, the language has not been +used during a complete design process, where its rapid prototyping and +reusability qualities could become real advantages, or perhaps the state +boilerplate or synchronicity limitations could become real problems. -Limited to structural, single clock domain synchronous, etc. +It is expected that Cλash will be used as a tool in education at the +University of Twente soon, hopefully this will provide a better insight +in how the system performs. + +The prototype compiler has a clear design. Its frontend is taken from the \GHC +compiler and desugares Haskell into a small, but functional and typed +language, called \emph{Core}. Cλash adds a transformation system that reduces +this small language to a normal form and a simple backend that performs a +direct translation to \VHDL. This approach has worked well and should probably +be preserved. Especially the transformation based normalization system is +suitable. It is easy to implement a transformation in the prototype, though it +is not trivial to maintain enough overview to guarantee that the system is +correct and complete. In fact, the current set of transformations is probably +not complete yet, in particular when stateful descriptions are involved. +However, the system can be (and has been) described in a mathematical sense, +allowing us to reason about it and probably also prove various correctness +properties in the future. + +The scope of this research has been limited to structural descriptions +that are synchronous in a single clock domain using cycle accurate +designs. Even though this is a broad spectrum already, it may turn out +that this scope is too narrow for practical use of Cλash. Most people +that hear about using a functional language for hardware description +instantly hope to be able to provide a concise mathematical description +of their algorithm and have the hardware generated for them. Since this +is obviously a different problem alltogether, we could not have hoped to +even start solving it. However, hopefully the current Cλash system +provides a solid base on top of which further experimentation with +functional descriptions can be built.