CλaSH – From Haskell to Hardware
clash-lang.org
CλaSH – From Haskell to Hardware
1–10 of 56 posts
Re: CλaSH – From Haskell to Hardware
#2Newbie here. From the page seems that CλaSH can be used to other tasks apart from a hardware modeller, it's that true?
Re: CλaSH – From Haskell to Hardware
#3Interesting idea. Very similar to Bluespec Verilog (http://www.bluespec.com/high-level-synthesis-tools.html) which also builds on a foundation of Haskell to Verilog translation (http://en.wikipedia.org/wiki/Bluespec,_Inc.) Unlike CλaSH, BSV is non-free (CλaSH is using a BSD License) which is a major (and cool) difference.
Having said all that, I'm currently writing a lot of Verilog for a system design that I'm working on. I also learned to program Haskell at university, (although it's been a few years...), so this language would seem PERFECT for me. But it isn't...
Reading through the CλaSH documentation/tutorial I've found the examples are baffling. I have no idea what is being written in either Haskell or Verilog space. The examples seem to be focusing on the language aspects of the tool rather than how to express actual hardware in it.
It would help me greatly if the authors would go through something like this: http://asic-world.com/examples/verilog/index.html or this: http://asic-world.com/examples/vhdl/ and write a side by side comparison of how I express these fundamental hardware concepts in this new language.
Re: CλaSH – From Haskell to Hardware
#4Interesting idea. Very similar to Bluespec Verilog ( http://www.bluespec.com/high-level-synthesis-tools.html ) which also builds on a foundation of Haskell to Verilog translation ( http://en.wikipedia.org/wiki/Bluespec,_Inc. ) Unlike CλaSH, BSV is non-free (CλaSH is using a BSD License) which is a major (and cool) difference. Having said all that, I'm currently writing a lot of Verilog for a system design that I'm wo…
Maybe look at cryptol or kansas-lava as more practically-focused alternatives?
Re: CλaSH – From Haskell to Hardware
#5the CλaSH vs Lava page was interesting: http://hackage.haskell.org/package/clash-prelude-0.7.5/docs/...
Re: CλaSH – From Haskell to Hardware
#6Interesting idea. Very similar to Bluespec Verilog ( http://www.bluespec.com/high-level-synthesis-tools.html ) which also builds on a foundation of Haskell to Verilog translation ( http://en.wikipedia.org/wiki/Bluespec,_Inc. ) Unlike CλaSH, BSV is non-free (CλaSH is using a BSD License) which is a major (and cool) difference. Having said all that, I'm currently writing a lot of Verilog for a system design that I'm wo…
The way I see it, it's Register Transfer Level, just written differently. Instead of writing:
@always(clock)
counter you write:
counter = s
where
s = register 0 (s + 1)
per http://hackage.haskell.org/package/clash-prelude-0.7.5/docs/...
I agree, it is an interesting idea. I suspect that just having "Haskell" got the link a lot of upvotes :-) As stated on the "Why CλaSH", the advantage is obvious for combinational circuits. But it doesn't seem to help much for synchronous logic (which arguably represents the majority of hardware designs). You'll still be writing everything as "how to update register X in state S".
Re: CλaSH – From Haskell to Hardware
#7Interesting idea. Very similar to Bluespec Verilog ( http://www.bluespec.com/high-level-synthesis-tools.html ) which also builds on a foundation of Haskell to Verilog translation ( http://en.wikipedia.org/wiki/Bluespec,_Inc. ) Unlike CλaSH, BSV is non-free (CλaSH is using a BSD License) which is a major (and cool) difference. Having said all that, I'm currently writing a lot of Verilog for a system design that I'm wo…
The way I see it, it's Register Transfer Level, just written differently. Instead of writing: @always(clock) counter you write: counter = s where s = register 0 (s + 1) per http://hackage.haskell.org/package/clash-prelude-0.7.5/docs/... I agree, it is an interesting idea . I suspect that just having "Haskell" got the link a lot of upvotes :-) As stated on the "Why CλaSH", the advantage is obvious for combinational ci…
Helpful explanation. Thanks! Looking at this I have a very specific question, from a practical getting work done point of view, is this better than what we have, or just different to what we have. If the answer is "different" I don't mind, but it will hinder my adoption ;-) I guess this is why I want to see a side-by-side comparison of real hardware constructs. Things I use regularly. It would aid greatly in understanding the (potential) benefit of expressing things these ways.
Re: CλaSH – From Haskell to Hardware
#8I don't know a first thing about hardware design, so it's a good opportunity to ask a question.
So say it would be something actually useful and after some tinkering I'm actually generating nice Verilog specifications. Can I apply it somehow if I'm not working in Intel or something? What can I do with it?
Re: CλaSH – From Haskell to Hardware
#9I don't know a first thing about hardware design, so it's a good opportunity to ask a question. So say it would be something actually useful and after some tinkering I'm actually generating nice Verilog specifications. Can I apply it somehow if I'm not working in Intel or something? What can I do with it?
> I'm actually generating nice Verilog specifications. Can I apply it somehow if I'm not working in Intel or something? What can I do with it?
Throw it into an FPGA
Re: CλaSH – From Haskell to Hardware
#10I don't know a first thing about hardware design, so it's a good opportunity to ask a question. So say it would be something actually useful and after some tinkering I'm actually generating nice Verilog specifications. Can I apply it somehow if I'm not working in Intel or something? What can I do with it?
> I'm actually generating nice Verilog specifications. Can I apply it somehow if I'm not working in Intel or something? What can I do with it? Throw it into an FPGA
And it would be significantly faster than if I would concentrate on optimizing the code for, say, executing it on GPU?