X-Git-Url: https://git.stderr.nl/gitweb?p=matthijs%2Fmaster-project%2Freport.git;a=blobdiff_plain;f=Chapters%2FContext.tex;h=3c09d95316e5c9aacd4479be0af9cbc9a77a01c8;hp=ca65c1233eec2e9b8d017c4b1245d6c16d1ddbf5;hb=b92b16b7e4ab854699bcd151bad0be7c5d73c0ae;hpb=3fc7078e3369d9e916b3663f04c51bb587434d14 diff --git a/Chapters/Context.tex b/Chapters/Context.tex index ca65c12..3c09d95 100644 --- a/Chapters/Context.tex +++ b/Chapters/Context.tex @@ -1,3 +1,112 @@ \chapter[chap:context]{Context} -Other FHDLs (short, Christiaan has details) -Advantages of clash / why clash? + An obvious question that arises when starting any research is \quote{Has + this not been done before?} Using a functional language for describing hardware + is not a new idea at all. In fact, there has been research into functional + hardware description even before the conventional hardware description + languages were created. \todo{Reference about early FHDLs} However, + functional languages were not nearly as advanced as they are now, and + functional hardware description never really got off. + +\todo{Add references} + Recently, there have been some renewed efforts, especially using the Haskell + functional language. Examples are Lava, ForSyde, ..., which are all a form of an + embedded domain specific language. Each of these have a slightly different + approach, but all of these do some trickery inside the Haskell language + itself, meaning you write a program that generates a hardware circuit, + instead of describing the circuit directly (either by running the haskell + code after compilation, or using Template Haskell to inspect parts of the + code you have written). This allows the full power of Haskell for generating + a circuit. However it also creates severe limitations in the use of the + language (you can't use case statements in Lava, since they would be + executed only once during circuit generation) and extra notational overhead. + + We will now have a look at the existing hardware description languages, + both conventional and functional to see the fields in which Cλash is + operating. + + \section{Conventional hardware description languages} + Considering that we already have some hardware description languages like + \small{VHDL} and Verilog, why would we need anything else? By introducing + the functional style to hardware description, we hope to obtain a hardware + description language that is: + \startitemize + \item More consise. Functional programs are known for their conciseness + and ability to abstract away common patterns. This is largely enabled + by features like an advanced type system with polymorphism and higher + order functions. + \todo{Does this apply to FHDLs equally?} + \item Type-safer. Functional programs typically have a highly expressive + type system, which makes it harder to write incorrect code. + \item Easy to process. Functional languages have nice properties like + purity \refdef{purity} and single binding behaviour, which make it easy + to apply program transformations and optimizations and could potentially + simplify program verification. + \stopitemize + + \placeintermezzo{}{ + \defref{EDSL} + \startframedtext[width=8.5cm,background=box,frame=no] + \startalignment[center] + {\tfa Embedded domain-specific languages (\small{EDSL})} + \stopalignment + \blank[medium] + + \startcitedquotation[hudak96] + A domain-specific language (\small{DSL}) is a program- + ming language or executable specification language + that offers, through appropriate notations and ab- + stractions, expressive power focused on, and usu- + ally restricted to, a particular problem domain. + \stopcitedquotation + + \todo{ref: http://portal.acm.org/citation.cfm?id=352035\&dl=} + + An embedded \small{DSL} is a \small{DSL} that is embedded in + another language. Haskell is commonly used to embed \small{DSL}s + in, which typically means a number of Haskell functions and types + are made available that can be called to construct a large value + of some domain-specific datatype (\eg, a circuit datatype). This + generated datatype can then be processed further by the + \small{EDSL} \quote{compiler} (which runs in the same environment + as the \small{EDSL} itself. The embedded language is then a, mostly + applicative, subset of Haskell where the library functions are the + primitives. Sometimes advanced haskell features such as + polymorphism, higher order values or type classes can be used in + the embedded language. + \stopframedtext + } + + \section[sec:context:fhdls]{Existing functional hardware description languages} + As noted above, we're not the first to walk this path. However, current + embedded functional hardware description languages (in particular those + using Haskell) are limited by:\todo{Separate TH and EDSL approaches + better} + \startitemize + \item Not all of Haskell's constructs can be captured by embedded domain + specific languages. For example, an if or case expression is typically + executed only once and only its result is reflected in the embedded + description, not the if or case expression itself. Also, sharing of + variables (\eg, using the same variable twice while only calculating it + once) and cycles in circuits are non-trivial to properly and safely + translate (though there is some work to fix this, but that has not been + possible in a completely reliable way yet. \todo{ref + http://www.ittc.ku.edu/~andygill/paper.php?label=DSLExtract09} + \item Some things are verbose to express. Especially ForSyDe suffers + from a lot of notational overhead due to the Template Haskell approach + used. Since conditional statements are not supported, a lot of Haskell's + syntax sugar (if expressions, pattern matching, guards) cannot be used + either, leading to more verbose notation as well. + \item Polymorphism and higher order values are not supported within the + embedded language. The use of Haskell as a host language allows the use + of polymorphism and higher order functions at circuit generation time + (even for free, without any additional cost on the \small{EDSL} + programmers), but the described circuits do not have any polymorphism + or higher order functions, which can be limiting. \todo{How true or + appropriate is this point?} + \todo[left]{Function structure gets lost (in Lava)} + \stopitemize + + \todo[text]{Complete translation in TH is complex: Works with Haskell AST + instead of Core} + +% vim: set sw=2 sts=2 expandtab: