
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. Sincerly Marc

On Tue, Jul 8, 2008 at 5:43 PM, Marc Weber
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
Sincerly Marc _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

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? 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

On Wed, Jul 9, 2008 at 2:22 AM, Marc Weber
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 :).

We'll soon (before september, hopefully) relase a deep-embedded
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/
On Tue, Jul 8, 2008 at 7:43 PM, Marc Weber
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.
Sincerly Marc _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Hello,
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
-----Original Message-----
From: haskell-cafe-bounces@haskell.org
[mailto:haskell-cafe-bounces@haskell.org] On Behalf Of Alfonso Acosta
Sent: 09 July 2008 03:27
To: Marc Weber; haskell-cafe@haskell.org
Subject: Re: [Haskell-cafe] FPGA / Lava and haskell
We'll soon (before september, hopefully) relase a deep-embedded
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/
On Tue, Jul 8, 2008 at 7:43 PM, Marc Weber
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.
Sincerly Marc _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

marco-oweber:
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

Hi Marc,
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.
participants (6)
-
Alfonso Acosta
-
Don Stewart
-
John O'Donnell
-
Marc Weber
-
Matthew Naylor
-
Philip Weaver