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,
TODO: Was Haskell really a good choice? Perhaps say this somewhere else?
+ \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
implement our prototype compiler. To understand the design of the
\stopdesc
\startdesc{Recursive let expression}
\startlambda
-let
+letrec
bndr1 = value1
\vdots
bndrn = valuen
\subsection[sec:prototype:separate]{Separate compilation}
- Simplified core?
- Haskell language coverage / constraints
- Recursion
- Builtin types
- Custom types (Sum types, product types)
- Function types / higher order expressions
-
+ \section{Haskell language coverage and constraints}
+ Recursion
+ Builtin types
+ Custom types (Sum types, product types)
+ Function types / higher order expressions
projects / matthijs / master-project / report.git / blobdiff