From: Matthijs Kooijman Date: Mon, 7 Dec 2009 09:40:27 +0000 (+0100) Subject: Add a section on simulation. X-Git-Tag: final-thesis~71 X-Git-Url: https://git.stderr.nl/gitweb?a=commitdiff_plain;ds=sidebyside;h=df932c64420a4fff15ecf19f5eaada664db701e7;p=matthijs%2Fmaster-project%2Freport.git Add a section on simulation. --- diff --git a/Chapters/Prototype.tex b/Chapters/Prototype.tex index e5cbb9d..7677cde 100644 --- a/Chapters/Prototype.tex +++ b/Chapters/Prototype.tex @@ -53,11 +53,17 @@ lots of work!), using an existing language is the obvious choice. This also has the advantage that a large set of language features is available to experiment with and it is easy to find which features apply well and - which do not. A possible second prototype could use a custom language with - just the useful features (and possibly extra features that are specific to + which do not. Another import advantage of using an existing language, is + that simulation of the code becomes trivial. Since there are existing + compilers and interpreters that can run the hardware description directly, + it can be simulated without also having to write an interpreter for the + new language. + + A possible second prototype could use a custom language with just the useful + features (and possibly extra features that are specific to the domain of hardware description as well). - The second choice is which of the many existing languages to use. As + The second choice to be made is which of the many existing languages to use. As mentioned before, the chosen language is Haskell. This choice has not been the result of a thorough comparison of languages, for the simple reason that the requirements on the language were completely unclear at the start of @@ -104,6 +110,25 @@ could achieve a similar amount of optimization in our prototype (nor should it be a goal, considering this is just a prototype). + \placeintermezzo{}{ + \startframedtext[width=8cm,background=box,frame=no] + \startalignment[center] + {\tfa Translation vs. compilation vs. synthesis} + \stopalignment + \blank[medium] + In this thesis the words \emph{translation}, \emph{compilation} and + sometimes \emph{synthesis} will be used interchangedly to refer to the + process of translating the hardware description from the Haskell + language to the \VHDL language. + + Similarly, the prototype created is referred to as both the + \emph{translator} as well as the \emph{compiler}. + + The final part of this process is usually referred to as \emph{\VHDL + generation}. + \stopframedtext + } + Note that we will be using \small{VHDL} as our output language, but will not use its full expressive power. Our output will be limited to using simple, structural descriptions, without any complex behavioural @@ -114,6 +139,18 @@ to switch to \small{EDIF} in the future, with minimal changes to the prototype. + \section{Simulation and synthesis} + As mentioned above, by using the Haskell language, we get simulation of + our hardware descriptions almost for free. The only thing that is needed + is to provide a Haskell implementation of all built-in functions that can + be used by the Haskell interpreter to simulate them. + + The main topic of this thesis is therefore the path from the Haskell + hardware descriptions to \small{FPGA} synthesis, focusing of course on the + \VHDL generation. Since the \VHDL generation process preserves the meaning + of the Haskell description exactly, any simulation done in Haskell + \emph{should} produce identical results as the synthesized hardware. + \section[sec:prototype:design]{Prototype design} As suggested above, we will use the Glasgow Haskell Compiler (\small{GHC}) to implement our prototype compiler. To understand the design of the diff --git a/Outline b/Outline index c0b7ad2..c61508a 100644 --- a/Outline +++ b/Outline @@ -44,7 +44,6 @@ Future work Don't care TODO: Define user / developer -TODO: Comiler vs translator TODO: Hardware description / model vs program TODO: Separate compilation / Prelude TODO: Add case binder removal transformation