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 <marco-oweber@gmx.de> wrote:
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 <marco-oweber@gmx.de> wrote:
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 <marco-oweber@gmx.de> wrote:
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 <marco-oweber@gmx.de> wrote:
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=fa52189d5ac4c0098c15ee324...
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