5 ms·

Interesting idea. Very similar to Bluespec Verilog (http://www.bluespec.com/high-level-synthesis-tools.html http://www.bluespec.com/high-level-synthesis-tools.h

Interesting idea. Very similar to Bluespec Verilog (http://www.bluespec.com/high-level-synthesis-tools.html 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. 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 http://asic-world.com/examples/verilog/index.html or this: http://asic-world.com/examples/vhdl/ 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.

dons 11y ago
Maybe look at cryptol or kansas-lava as more practically-focused alternatives?
MootWoop 11y ago
The way I see it, it's Register Transfer Level, just written differently. Instead of writing: @always(clock) counter <= counter + 1; you write: counter = s where s = register 0 (s + 1) per http://hackage.haskell.org/package/clash-prelude-0.7.5/docs/CLaSH-Tutorial.html 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".
- deadgrey19 11y ago
  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.
  - zackmorris 11y ago
    Well, when I used VHDL back in college, I noticed that it had a really hard time with math. So for example it could do look up tables all day (basically switch commands) but if you tried to encode that logic into the kind of math we're used to in a C-based language where A = B (insert operator here) C, it fell down hard and the circuit would be so unstable that it would only run a few cycles before spinning off into some exceptional state that was nothing like we expected. I think that's because humans have a hard time considering the ramifications of things like boundary conditions and edge cases with respect to types. So maybe we can visualize one register being added to another, but we can't intuitively extrapolate what happens when one is signed and one is unsigned, or their widths are different, or one is floating point, etc etc etc. VHDL doesn't touch on all of these edge cases very well (because for one thing they are hard!) it just does exactly what it’s told. That often flies in the face of intuition, once we’ve analyzed the circuit and seen how much we underestimated the complexity of what we were asking. In other words elegant math doesn’t always translate to simple circuits, and vice versa. So it really needs a meta language that can grapple with these subtle nuances and compile to VHDL without a lot of friction. Probably what’s going to happen is we’ll see DSP logic (and limited subsets of it like GPU shaders/OpenCL/CUDA) and VHDL/Verilog merge into a functional concurrent language that can cover all of it. It won’t be as explicit as Rust because it will infer what the user is after but allow for overriding default assumptions. It won’t have opaque syntax either like most functional languages today. I’m thinking probably it will look more like MATLAB/Octave but have access to some of the more concise notation of Mathematica. So think Excel except having cells arranged arbitrarily in some ND space rather than 2D, and we’ll be able to specify formulas on groups of cells rather than individually, and in any language we desire that’s then compiled to Lisp and either run on distributed economy hardware or translated to a hardware description language. CλaSH probably isn’t it, but its approach and open source license is certainly a start. Realized I didn't answer the question - different yes, but probably not different enough to be compelling for mainstream use at this point. Without having ever used it, I have concerns that circuits will still fall down or take up gratuitous chip area because handling the edge cases is one of the more complex problems to solve, and I'm not convinced that functional programming alone is enough.

dons 11y ago

Maybe look at cryptol or kansas-lava as more practically-focused alternatives?

MootWoop 11y ago

The way I see it, it's Register Transfer Level, just written differently. Instead of writing: @always(clock) counter <= counter + 1; you write: counter = s where s = register 0 (s + 1) per http://hackage.haskell.org/package/clash-prelude-0.7.5/docs/CLaSH-Tutorial.html 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".

deadgrey19 11y ago
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.
- zackmorris 11y ago
  Well, when I used VHDL back in college, I noticed that it had a really hard time with math. So for example it could do look up tables all day (basically switch commands) but if you tried to encode that logic into the kind of math we're used to in a C-based language where A = B (insert operator here) C, it fell down hard and the circuit would be so unstable that it would only run a few cycles before spinning off into some exceptional state that was nothing like we expected. I think that's because humans have a hard time considering the ramifications of things like boundary conditions and edge cases with respect to types. So maybe we can visualize one register being added to another, but we can't intuitively extrapolate what happens when one is signed and one is unsigned, or their widths are different, or one is floating point, etc etc etc. VHDL doesn't touch on all of these edge cases very well (because for one thing they are hard!) it just does exactly what it’s told. That often flies in the face of intuition, once we’ve analyzed the circuit and seen how much we underestimated the complexity of what we were asking. In other words elegant math doesn’t always translate to simple circuits, and vice versa. So it really needs a meta language that can grapple with these subtle nuances and compile to VHDL without a lot of friction. Probably what’s going to happen is we’ll see DSP logic (and limited subsets of it like GPU shaders/OpenCL/CUDA) and VHDL/Verilog merge into a functional concurrent language that can cover all of it. It won’t be as explicit as Rust because it will infer what the user is after but allow for overriding default assumptions. It won’t have opaque syntax either like most functional languages today. I’m thinking probably it will look more like MATLAB/Octave but have access to some of the more concise notation of Mathematica. So think Excel except having cells arranged arbitrarily in some ND space rather than 2D, and we’ll be able to specify formulas on groups of cells rather than individually, and in any language we desire that’s then compiled to Lisp and either run on distributed economy hardware or translated to a hardware description language. CλaSH probably isn’t it, but its approach and open source license is certainly a start. Realized I didn't answer the question - different yes, but probably not different enough to be compelling for mainstream use at this point. Without having ever used it, I have concerns that circuits will still fall down or take up gratuitous chip area because handling the edge cases is one of the more complex problems to solve, and I'm not convinced that functional programming alone is enough.