From: Matthijs Kooijman Date: Wed, 4 Nov 2009 16:10:09 +0000 (+0100) Subject: Add a section on the output format. X-Git-Tag: final-thesis~172 X-Git-Url: https://git.stderr.nl/gitweb?a=commitdiff_plain;h=42ec9c78da464de1ed58509a6edaa454c6a225bc;p=matthijs%2Fmaster-project%2Freport.git Add a section on the output format. --- diff --git a/Chapters/Prototype.tex b/Chapters/Prototype.tex index 85e7fb2..7cd5ea5 100644 --- a/Chapters/Prototype.tex +++ b/Chapters/Prototype.tex @@ -11,7 +11,7 @@ has gone through a number of design iterations which we will not completely describe here. - \section{Choice of language} + \section{Input language} When implementing this prototype, the first question to ask is: What (functional) language will we use to describe our hardware? (Note that this does not concern the \emph{implementation language} of the compiler, @@ -50,8 +50,49 @@ TODO: Was Haskell really a good choice? Perhaps say this somewhere else? - \subsection{Output language or format} - VHDL / Verilog / EDIF etc. Why VHDL? + \subsection{Output format} + The second important question is: What will be our output format? Since + our prototype won't be able to program FPGA's directly, we'll have to have + output our hardware in some format that can be later processed and + programmed by other tools. + + Looking at other tools in the industry, the Electronic Design Interchange + Format (\small{EDIF}) is commonly used for storing intermediate + \emph{netlists} (lists of components and connections between these + components) and is commonly the target for \small{VHDL} and Verilog + compilers. + + However, \small{EDIF} is not completely tool-independent. It specifies a + meta-format, but the hardware components that can be used vary between + various tool and hardware vendors, as well as the interpretation of the + \small{EDIF} standard (TODO Is this still true? Reference: + http://delivery.acm.org/10.1145/80000/74534/p803-li.pdf?key1=74534\&key2=8370537521&coll=GUIDE&dl=GUIDE&CFID=61207158&CFTOKEN=61908473). + + This means that when working with EDIF, our prototype would become + technology dependent (\eg only work with \small{FPGA}s of a specific + vendor, or even only with specific chips). This limits the applicability + of our prototype. Also, the tools we'd like to use for verifying, + simulating and draw pretty pictures of our output (like Precision, or + QuestaSim) work on \small{VHDL} or Verilog input (TODO: Is this really + true?). + + For these reasons, we will use \small{VHDL} as our output language. + Verilog is not used simply because we are familiar with \small{VHDL} + already. The differences between \small{VHDL} and Verilog are on the + higher level, while we will be using \small{VHDL} mainly to write low + level, netlist-like descriptions anyway. + + An added advantage of using VHDL is that we can profit from existing + optimizations in VHDL synthesizers. A lot of optimizations are done on the + VHDL level by existing tools. These tools have years of experience in this + field, so it would not be reasonable to assume we could achieve a similar + amount of optimization in our prototype (nor should it be a goal, + considering this is just a prototype). + + 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 behavioural descriptions + (which might not be supported by all tools). \section{Prototype design} As stated above, we will use the Glasgow Haskell Compiler (\small{GHC}) to