From f03ce6925c4709f4a92f5371347050fc65147e3f Mon Sep 17 00:00:00 2001 From: Matthijs Kooijman Date: Mon, 26 Oct 2009 11:23:45 +0100 Subject: [PATCH 1/1] Add some more context. --- Chapters/Context.tex | 58 +++++++++++++++++++++++++++++++++++--------- 1 file changed, 46 insertions(+), 12 deletions(-) diff --git a/Chapters/Context.tex b/Chapters/Context.tex index 4b529c9..827f61f 100644 --- a/Chapters/Context.tex +++ b/Chapters/Context.tex @@ -22,15 +22,49 @@ TODO: Define (E)DSL TODO: References - Advantages over conventional HDLs - - More consise - - More expressive - - Easy to transform / optimize / etc. - - Advantages over existing FHDLs - - More control - - Full Haskell available - - Concise notation - - Disadvantages over existing FHDLs - - More work to implement advanced things + \section{Conventional hardware description languages} + Considering that we already have some hardware description language 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, + mostly caused by the ability to abstract just about any behaviour into a + helper function. This is largely enabled by features like an advanced + type system with polymorphism and higher order functions. + \item Type-safer. Functional programs typically have a highly expressive + type system, which makes it harder to write incorrect code. This is + probably not only directly caused by the type system, so perhaps this + advantage does not apply in hardware descriptions. + \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 + + \section{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: + \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 and + loops are non-trivial do 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?). + \stopitemize -- 2.30.2