[Haskell-cafe] FPGA / Lava and haskell
Marc Weber
program FPGAs and create circuits on chips?
The Chalmers Lava homepage tells abouta Xilinx version which should be
merged in soon. But on the xilinx homepage there was no reference to
neither Lava nor haskell..
I'm thinking about designing a similar tool to www.combimouse.com.
Sincerly
Marc
_______________________________________________
Haskell-Cafe mailing list
Haskel...@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Philip Weaver
> Is Haskell still used (in industry as well ?) to write (V)HDL code to
> program FPGAs and create circuits on chips?
Indeed! Galois maintains a language called Cryptol. Almost all tools for
this language, including an FPGA compiler that produces HDL, are written in
Haskell. It is not open source, nor is it free as in beer, but there is a
free academic version without FPGA support.
The Chalmers Lava homepage tells abouta Xilinx version which should be
> merged in soon. But on the xilinx homepage there was no reference to
> neither Lava nor haskell..
As for Lava and the Xilinx version, I am not really sure how actively it is
being developed. Perhaps someone else here knows?
> I'm thinking about designing a similar tool to www.combimouse.com.
You're going to design something like that with an FPGA in it? :)
For a simple enough design, it can be useful to write specs in Haskell and
then translate them to HDL by hand. I believe someone on this list had a
particularly successful experience doing that :).
- Philip
Alfonso Acosta
version of ForSyDe[1] which, among other things, has a VHDL backend
(with specific support for Altera's Modelsim and Quartus).
ForSyDe's new implementation is internally based upon the same concept
as Lava (Observable Sharing). However, it has quite a few differences:
* ForSyDe is behavioural (computations are expressed in plain haskell)
* It has support for components
* Is not barely targeted at synchrounous hardware systems (although
the VHDL backend is obviously aimed at them). It has suport for other
MoCs (Models of Computation).
[1] http://www.imit.kth.se/info/FOFU/ForSyDe/
Marc Weber
like to put it on the market. My hope is to get one low cost chip doing
everything this way. Would you suggest using other tools? I'm still a
total noob in this area
> For a simple enough design, it can be useful to write specs in Haskell and
> then translate them to HDL by hand. I believe someone on this list had a
> particularly successful experience doing that :).
Thanks for this note.
Marc Weber
Don Stewart
> Is Haskell still used (in industry as well ?) to write (V)HDL code to
> program FPGAs and create circuits on chips?
> The Chalmers Lava homepage tells abouta Xilinx version which should be
> merged in soon. But on the xilinx homepage there was no reference to
> neither Lava nor haskell..
> I'm thinking about designing a similar tool to www.combimouse.com.
See also BlueSpec and Atom et al,
http://funhdl.org/wiki/doku.php
http://funhdl.org/wiki/doku.php?id=funhdl&DokuWiki=fa52189d5ac4c0098c15ee324e0056ec
Philip Weaver
> > You're going to design something like that with an FPGA in it? :)
> The FPGA is only used for developement. If everything works fine I'd
> like to put it on the market. My hope is to get one low cost chip doing
> everything this way. Would you suggest using other tools?
>
Ah, yes, it is common to develop on an FPGA before fabricating to, say, on
ASIC .
> I'm still a total noob in this area
So you plan on developing a chip or board without any previous hardware
experience? Sounds.... challenging :).
Matthew Naylor
> The Chalmers Lava homepage tells abouta Xilinx version which should
> be merged in soon. But on the xilinx homepage there was no reference
> to neither Lava nor haskell..
> I'm thinking about designing a similar tool to www.combimouse.com.
you also might consider using a PIC or some such microcontroller for
this kind of project. I don't think there is a Haskell library for
PIC programming, but it would be fun to make one! For somewhat
related work, see issues 6 and 7 of The Monad.Reader
(http://www.haskell.org/haskellwiki/The_Monad.Reader), especially
Russell O'Conner's article. As mentioned in issue 7, I did use Lava
to program an RCX microcontroller, but in general the techniques I
used are much better suited to hardware. Also, there is "PICBIT: A
Scheme System for the PIC Microcontroller" by Marc Feeley
(http://www.iro.umontreal.ca/~feeley/papers/sw03.pdf) which might be
of interest.
Regarding Lava, there is a version on Satnam Singh's website
(http://raintown.org/lava/). I use Emil Axelsson's version of
Chalmers Lava (http://www.cs.chalmers.se/~emax/darcs/Lava2000/) that
works with the latest GHC. I made some mods to target the Xilinx
toolset and to provide very basic support for block RAMs
(http://www.cs.york.ac.uk/fp/darcs/reduceron2/Lava2000/). I wish I
had time to work more on this, and make it more accessible to others!
Nevertheless, Chalmers Lava as it stands is already very usable. It
is also very hacker-friendly, so I can recommend diving in!
As an aside: I'm currently finishing off a document about my uses of
Lava and its capabilities/weaknesses. Hopefully this will be
publicly available soon.
Matt.
Satnam Singh
I've been distracted with the Kiwi project (parallel C# programs to hardware) and right now a Bluespec project so I've not made any progress on a merge of the Lava I produced for designing circuits (with layout) for Xilinx's FPGAs and the Chalmers version (which I recommend for situations where you don't care about circuit layout or when you don't want to use FPGA architecture specific features). The version of Lava on my website at http://raintown.org/lava/ still builds under the current version of ghc and it provides support for generating Xilinx EDIF netlists that supports the basic FPGA circuit building blocks. If you need things like ODDRs etc. which appear in the new FPGAs then you have to either add them yourself (not too difficult) or wait for me to do it :)
Cheers,
Satnam
________________________________
Satnam Singh
Microsoft
7 JJ Thomson Avenue
Cambridge
CB3 0FB
United Kingdom
Email: sat...@microsoft.com<mailto:sat...@microsoft.com>
UK tel: +44 1223 479905
Fax: +44 1223 479 999
UK mobile: +44 7979 648412
USA cell: 206 330 1580
USA tel: 206 219 9024
URL: http://research.microsoft.com/~satnams
Live Messenger: sat...@raintown.org<mailto:sat...@raintown.org>
John O'Donnell
Here are some more references relevant to ForSyDe, which looks very
interesting!
The following paper describes the first version of Hydra, a functional
hardware description language which has gone through many versions,
using several different functional languages. Hydra uses streams for
modelling synchronous circuits, and the paper contains references to the
first work on streams for hardware description, by Steve Johnson. Note
that the syntax in this paper isn't Haskell; after all, Hydra was
initially implemented in 1982, and Haskell didn't exist then!
www.dcs.gla.ac.uk/~jtod/publications/1987-HDRE/
The mid 80s version of Hydra had multiple semantics, including both
behaviour and netlist generation, and it used observable sharing to
implement the netlists. That's described in the following paper, which
also shows how Hydra can (optionally) use combinators to express layout
and wiring. The geometric combinators are based on Mary Sheeran's Ruby
language, although the actual combinators in Hydra are a bit different.
The main difference between Hydra and Ruby is that Hydra is functional,
it's based on streams, and the geometric combinators are optional: you
can just use connect the streams together if all you want is a
simulation and netlist but not a layout.
www.dcs.gla.ac.uk/~jtod/publications/1988-HydraCombinators
The netlists are represented as a data structure, and can be converted
to a particular netlist notation with a suitable "show" function. The
paper doesn't use the term "observable sharing" -- that name for the
technique was introduced in Lava -- but the technique was already
implemented and published in 1988. Lava is essentially a clone of Hydra
the way it was from around 1985 to about 1992.
However, there are a number of drawbacks to using observable sharing for
generating netlists, and some of these are discussed in the following
paper, which also proposes an alternative approach based on program
transformation.
www.dcs.gla.ac.uk/~jtod/publications/1992-Netlist
The program transformation approach to netlist generation has been
implemented using Template Haskell to perform the transformations
automatically, as described in the next paper. Currently, Hydra uses
this, and it avoids observable sharing.
www.dcs.gla.ac.uk/~jtod/publications/2004-EmbedHDLinTH/
Here are a few more papers that give an overview of Hydra with some
examples,:
www.dcs.gla.ac.uk/~jtod/publications/1995-Hydra-FPLE/
www.dcs.gla.ac.uk/~jtod/publications/2002-Hydra-PDSECA/
www.dcs.gla.ac.uk/~jtod/publications/2004-DeriveFastAdder/
John O'Donnell