8 ms·

CλaSH – From Haskell to Hardware

158 points by jdmoreira 11y ago

marvel_boy 11y ago
Newbie here. From the page seems that CλaSH can be used to other tasks apart from a hardware modeller, it's that true?
- cantankerous 11y ago
  What kinds of other tasks do you mean? Clash's surface language is Haskell, which is a general purpose programming language.
deadgrey19 11y ago
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.
platz 11y ago
the CλaSH vs Lava page was interesting: 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/...
krick 11y ago
I 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?
- raverbashing 11y ago
  > 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
  - krick 11y ago
    And it would be significantly faster than if I would concentrate on optimizing the code for, say, executing it on GPU?
    - raverbashing 11y ago
      Depends on what you want to do. It's not about faster, it's about the application, you can't plug a PC with a GPU to solve all problems. FPGAs weren't created for bitcoin mining.
    - CHY872 11y ago
      Perhaps. Perhaps not. If you have an algorithm that is better implemented in hardware, you might well see better performance executing it on a GPU (for example, if you want to mine bitcoins). Really, FPGAs are meant for prototyping hardware; you synthesize your ASIC onto the FPGA and check it for functionality. Of course, there's a reason you're making that ASIC.
      - raverbashing 11y ago
        Or you don't do an ASIC and ship the FPGA. That's common as well (for the big manufacturers it's cheaper to do an ASIC, for the not so big, it's more common to sell the FPGA)
catchmrbharath 11y ago
This is very interesting. I have always felt that having a language that has immutable constructs translates very well into a hardware description language. This is because most of the hardware modules are immutable, except for state machines, which can be modelled using state monads(or something similar). Considering the hardware tooling right now, I would love to see a language with more abstractions than verilog or vhdl. I would love to see programming languages, that just don't compile to system verilog / VHDL, but can directly move to synthesizing step. I have worked with Bluespec and I don't see that as the successor. I would say, a language like haskell(or a derivative) can map to a hardware really well, and this is a very good attempt. Please pursue it / turn it into a product, so that hacking on hardware(a FPGA) is much more easier and beautiful.
d-equivalence 11y ago
When I was writing the chips from nand2tetris in HDL I noticed how cleanly they could be expressed with function composition in SML. I dismissed the ideas as a bit weird, if cool, but after a few weeks I came across HardCaml http://www.ujamjar.com/hardcaml/ http://www.ujamjar.com/hardcaml/ and some references to HML (Hardware ML). Unfortunately only the thesis survives and not any actual code, but still. The moral of the story is to take your weird ideas more seriously I guess ;-)
microarchitect 11y ago
There's been a few different proposals to use functional languages to write hardware: Chisel (https://chisel.eecs.berkeley.edu/ https://chisel.eecs.berkeley.edu/) and Bluespec (http://www.bluespec.com/ http://www.bluespec.com/) are two others. They haven't really taken off because the productivity bottleneck in hardware is not in design but verification and specifically sequential verification. Combinational verification is quote easy, because modern SAT solvers can prove almost all combinational properties you can throw at them. The trouble comes in when you start dealing with complex state machines with non-obvious invariants. I don't think these functional languages can really help too much here because unlike C or C++ in the software world, there isn't unnecessary complexity introduced by a language, e.g. verification becoming harder due to aliasing. It's the properties themselves that are complex. Lots of progress is happening though: Aaron Bradley's PDR (http://theory.stanford.edu/~arbrad/ http://theory.stanford.edu/~arbrad/) and Arie Gurfinkel and Yakir Vizel's AVY (http://arieg.bitbucket.org/avy/ http://arieg.bitbucket.org/avy/) have made pretty major breakthroughs in proving a lot of complex sequential properties and these algorithms have made their way into industrial formal tools as well.
adwn 11y ago
Disclaimer: I haven't read through the details of the language yet. > The merits of using a functional language to describe hardware comes from the fact that combinational circuits can be directly modeled as mathematical functions and that functional languages lend themselves very well at describing and (de-)composing mathematical functions. Whenever I read something like this, I cannot really take the language or the language designer seriously. The complexity and difficulty of hardware design is not in the combinational part, it's in the sequential (i.e., state-carrying) part of the circuit [1]. One of the major drawbacks of Verilog, SystemVerilog, and VHDL, is that successive sequential statements have to be translated manually to state machines (at least for synthesizable code – simulation code does not suffer from this restriction) [2]. [1] Source: I'm an FPGA design engineer with a computer science background. [2] There are of course languages with an improved design, but nearly all of them are research prototypes and unsuited for non-toy/example designs. The more innovative commercial products have hardly any marketshare, because electrical engineers seem to be extremely conservative [1].
- MootWoop 11y ago
  Interesting, I feel like you would like what we've done with the Cx language at Synflow. Probably the exact opposite of CλaSH, the language is sequential imperative (C-like even) and focuses on making the sequential part easier (Cx still has first class support for parallel tasks and hierarchical descriptions though). You have synchronous "for", "while", "if", this kind of thing :-) http://cx-lang.org http://cx-lang.org Enjoy!
  - adwn 11y ago
    I've actually had a brief look at Cx a couple of months ago, and it looked very promising! Unfortunately, due to private and job-related reasons I didn't have the time to look at it in depth. There's one thing that irritated me though: Reading from a port twice seems to trigger a clock cycle (did I get that right?). My intuition tells me that this is a huge source of bugs, comparable to the infered-latch-instead-of-combinational problem in VHDL/Verilog. I might be wrong though, since I haven't actually designed anything with it.
Tehnix 11y ago
I tried this out briefly while working on a VHDL project some time ago. I absolutely love how quick it is to run and test your code, compared to the toolings for VHDL. Also, Haskell's terse syntax is very much a plus! :)
Ericson2314 11y ago
I've used CLaSH over most of the pass year to do all my Verilog assignments (CS major doing EE electives), and also contributed a bit to the project, so figure I'd offer some insight. For all you saying "but sequential is the hard part". Yes functional programming is most clearly a smash-hit with combinatorial circuits, but CLaSH shines with sequential circuits too. Basically, time-varying nets are represented as infinite streams where the nth element is the value at the nth cycle. Registers are basically `cons`, they just "delay" the stream by one cycle, tacking on the initial value in front. To make complex sequential code you just "tie the knot" around the streams with `letrec`s -- which actually corresponds to exactly what the feedback loop looks like on the schematic. [Anyone that's done FRP should recognize this ideom.] In this way CLaSH is both more high-level and more low level than Verilog/VHDL: clocks nets are derived automatically, but feed back loops are explicit. Now if you are an electrical engineer, subsisting one tedious task (routing clocks) for another (programming without "blocking assignment") might seem like no net gain. But us functional programmers are fluent at working with such fix-points, and abstracting both what we tie together an the knot-tying itself. The Moore and Mealy combinatorial are the tip of the iceberg -- examples that we hope will be more accessible to electrical engineers unfamiliar with functional programming. For all you saying that "the hard part isn't working with the HDL at all, but lower level concerns like timing, layout, etc", I have two things. First you are acting like HDL writing is not on the "critical path" of your development process, and thus of no concern. Well that's not just true--you can't have one engineer do HDL writing, one do layout, and one engineer do testing completely independently because there are some basic data dependencies here that linearized the development workflow. It may not be the component with the "most delay" but it's still on that critical path, and thus improving it will yield at least some speedup to some extent. Automatic layout and timing analysis is great too, but unless you have a massive amount of computing power at your disposal, AFIAK you can't get very far, so improving the HDL side of things might be the /best/ you can do. Second, there is the development cost of finding all your bugs with low-level tools. Yes timing analysis is essential, but it's not great in diagnosing the underlying problem. If you have lots of code that, well, isn't very aesthetically pleasing, and you do all your debugging on FPGA or with timing analysis, I suppose just about all bugs look like timing issues. With CLaSH: - You have far less code, and it's more high-level, so just reading looking for errors it is more productive. - You can try out your code on the repl, seeing providing a stream of inputs and getting a stream of output. High level state machine errors (do you really nail this the first time with verilog?) are easily caught this way. - Because you have more opportunities to modularize your code, you have more opportunities to test components in isolation. Unit tests vs. System tests--y'all know the deal. The former is no panacea, but obviously it makes complete code/path coverage way more tractable computationally. - QuickCheck. I generate programs, run my single-cycle and pipeline processor for n cycles, see if they both halted and compare register/mem stage, otherwise throw out the test. I /suppose/ you could do this with C-augmented testbenches, but it would be way, way, way more code and effort. QuichCheck worked so well that I never wrote a test bench. - EVENTUALLY, with idris or [faking it with] dependent Haskell prove your circuit correct up to the synchronous model CLaSH is built around. In practice I can say I honestly wrote and debugged programs all from GHCi (the Haskell REPL, so very much in software land), and saw them work first time on the FPGA. Where this didn't happen was usually do to a black boxes, like megfunctions and other components on the dev board. Obviously my Haskell testing is of no use if I model them wrong in CLaSH. Finally, it would be dishonest and misleading to not mention CLaSH's downsides. CLaSH is designed assuming your circuit is totally synchronous (or purely combinatorial, but that's the trivial case). I don't know often this comes up in the real world, but in interfacing with the components on the dead board, I often had to do things that violated rigidly synchronous circuit design --- inverting my clock to get a second 180-degree-off clock domain, asynchronous communication with SRAM. [CLaSH supports multiple clock domains, but only knows about their relative frequency, not phase.] You can often still describe these circuit in CLaSH, but because it violates its synchronous model, it won't understand them and neither will your Haskell-land testing infrastructure. Basically you loose the benefits that made CLaSH great in the first place. Fundamentally, I think true fixing these cases means designing a lower-level "asynchronous CLaSH" that both normal CLaSH and these cases can elaborate to. Trying to tack them on as special cases to CLaSH and it's synchronous modle won't fly. But all is not lost, if you can contain the model-violation to one bit of code and give it kosher synchronous interface, you are all good. Write some Haskell to simulate what it does (need not be even in the subset CLaSH can understand), and make a Verilog/VHDL black box. CLaSH doesn't help you with that module, but that module doesn't pollute the rest of your program either. Most real-world designs are by and large synchronous, unless the world has been lying to me. So the quarantined modules would never form a significant part of your program. That about wraps it up, ...hope somebody's still reading this thread after writing all that.

158 points by jdmoreira 11y ago

marvel_boy 11y ago

Newbie here. From the page seems that CλaSH can be used to other tasks apart from a hardware modeller, it's that true?

cantankerous 11y ago
What kinds of other tasks do you mean? Clash's surface language is Haskell, which is a general purpose programming language.

deadgrey19 11y ago

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.

platz 11y ago

the CλaSH vs Lava page was interesting: 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/...

krick 11y ago

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

raverbashing 11y ago
> 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
- krick 11y ago
  And it would be significantly faster than if I would concentrate on optimizing the code for, say, executing it on GPU?
  - raverbashing 11y ago
    Depends on what you want to do. It's not about faster, it's about the application, you can't plug a PC with a GPU to solve all problems. FPGAs weren't created for bitcoin mining.
  - CHY872 11y ago
    Perhaps. Perhaps not. If you have an algorithm that is better implemented in hardware, you might well see better performance executing it on a GPU (for example, if you want to mine bitcoins). Really, FPGAs are meant for prototyping hardware; you synthesize your ASIC onto the FPGA and check it for functionality. Of course, there's a reason you're making that ASIC.
    - raverbashing 11y ago
      Or you don't do an ASIC and ship the FPGA. That's common as well (for the big manufacturers it's cheaper to do an ASIC, for the not so big, it's more common to sell the FPGA)

catchmrbharath 11y ago

This is very interesting. I have always felt that having a language that has immutable constructs translates very well into a hardware description language. This is because most of the hardware modules are immutable, except for state machines, which can be modelled using state monads(or something similar). Considering the hardware tooling right now, I would love to see a language with more abstractions than verilog or vhdl. I would love to see programming languages, that just don't compile to system verilog / VHDL, but can directly move to synthesizing step. I have worked with Bluespec and I don't see that as the successor. I would say, a language like haskell(or a derivative) can map to a hardware really well, and this is a very good attempt. Please pursue it / turn it into a product, so that hacking on hardware(a FPGA) is much more easier and beautiful.

d-equivalence 11y ago

When I was writing the chips from nand2tetris in HDL I noticed how cleanly they could be expressed with function composition in SML. I dismissed the ideas as a bit weird, if cool, but after a few weeks I came across HardCaml http://www.ujamjar.com/hardcaml/ http://www.ujamjar.com/hardcaml/ and some references to HML (Hardware ML). Unfortunately only the thesis survives and not any actual code, but still. The moral of the story is to take your weird ideas more seriously I guess ;-)

microarchitect 11y ago

There's been a few different proposals to use functional languages to write hardware: Chisel (https://chisel.eecs.berkeley.edu/ https://chisel.eecs.berkeley.edu/) and Bluespec (http://www.bluespec.com/ http://www.bluespec.com/) are two others. They haven't really taken off because the productivity bottleneck in hardware is not in design but verification and specifically sequential verification. Combinational verification is quote easy, because modern SAT solvers can prove almost all combinational properties you can throw at them. The trouble comes in when you start dealing with complex state machines with non-obvious invariants. I don't think these functional languages can really help too much here because unlike C or C++ in the software world, there isn't unnecessary complexity introduced by a language, e.g. verification becoming harder due to aliasing. It's the properties themselves that are complex. Lots of progress is happening though: Aaron Bradley's PDR (http://theory.stanford.edu/~arbrad/ http://theory.stanford.edu/~arbrad/) and Arie Gurfinkel and Yakir Vizel's AVY (http://arieg.bitbucket.org/avy/ http://arieg.bitbucket.org/avy/) have made pretty major breakthroughs in proving a lot of complex sequential properties and these algorithms have made their way into industrial formal tools as well.

adwn 11y ago

Disclaimer: I haven't read through the details of the language yet. > The merits of using a functional language to describe hardware comes from the fact that combinational circuits can be directly modeled as mathematical functions and that functional languages lend themselves very well at describing and (de-)composing mathematical functions. Whenever I read something like this, I cannot really take the language or the language designer seriously. The complexity and difficulty of hardware design is not in the combinational part, it's in the sequential (i.e., state-carrying) part of the circuit [1]. One of the major drawbacks of Verilog, SystemVerilog, and VHDL, is that successive sequential statements have to be translated manually to state machines (at least for synthesizable code – simulation code does not suffer from this restriction) [2]. [1] Source: I'm an FPGA design engineer with a computer science background. [2] There are of course languages with an improved design, but nearly all of them are research prototypes and unsuited for non-toy/example designs. The more innovative commercial products have hardly any marketshare, because electrical engineers seem to be extremely conservative [1].

MootWoop 11y ago
Interesting, I feel like you would like what we've done with the Cx language at Synflow. Probably the exact opposite of CλaSH, the language is sequential imperative (C-like even) and focuses on making the sequential part easier (Cx still has first class support for parallel tasks and hierarchical descriptions though). You have synchronous "for", "while", "if", this kind of thing :-) http://cx-lang.org http://cx-lang.org Enjoy!
- adwn 11y ago
  I've actually had a brief look at Cx a couple of months ago, and it looked very promising! Unfortunately, due to private and job-related reasons I didn't have the time to look at it in depth. There's one thing that irritated me though: Reading from a port twice seems to trigger a clock cycle (did I get that right?). My intuition tells me that this is a huge source of bugs, comparable to the infered-latch-instead-of-combinational problem in VHDL/Verilog. I might be wrong though, since I haven't actually designed anything with it.

Tehnix 11y ago

I tried this out briefly while working on a VHDL project some time ago. I absolutely love how quick it is to run and test your code, compared to the toolings for VHDL. Also, Haskell's terse syntax is very much a plus! :)

Ericson2314 11y ago

I've used CLaSH over most of the pass year to do all my Verilog assignments (CS major doing EE electives), and also contributed a bit to the project, so figure I'd offer some insight. For all you saying "but sequential is the hard part". Yes functional programming is most clearly a smash-hit with combinatorial circuits, but CLaSH shines with sequential circuits too. Basically, time-varying nets are represented as infinite streams where the nth element is the value at the nth cycle. Registers are basically `cons`, they just "delay" the stream by one cycle, tacking on the initial value in front. To make complex sequential code you just "tie the knot" around the streams with `letrec`s -- which actually corresponds to exactly what the feedback loop looks like on the schematic. [Anyone that's done FRP should recognize this ideom.] In this way CLaSH is both more high-level and more low level than Verilog/VHDL: clocks nets are derived automatically, but feed back loops are explicit. Now if you are an electrical engineer, subsisting one tedious task (routing clocks) for another (programming without "blocking assignment") might seem like no net gain. But us functional programmers are fluent at working with such fix-points, and abstracting both what we tie together an the knot-tying itself. The Moore and Mealy combinatorial are the tip of the iceberg -- examples that we hope will be more accessible to electrical engineers unfamiliar with functional programming. For all you saying that "the hard part isn't working with the HDL at all, but lower level concerns like timing, layout, etc", I have two things. First you are acting like HDL writing is not on the "critical path" of your development process, and thus of no concern. Well that's not just true--you can't have one engineer do HDL writing, one do layout, and one engineer do testing completely independently because there are some basic data dependencies here that linearized the development workflow. It may not be the component with the "most delay" but it's still on that critical path, and thus improving it will yield at least some speedup to some extent. Automatic layout and timing analysis is great too, but unless you have a massive amount of computing power at your disposal, AFIAK you can't get very far, so improving the HDL side of things might be the /best/ you can do. Second, there is the development cost of finding all your bugs with low-level tools. Yes timing analysis is essential, but it's not great in diagnosing the underlying problem. If you have lots of code that, well, isn't very aesthetically pleasing, and you do all your debugging on FPGA or with timing analysis, I suppose just about all bugs look like timing issues. With CLaSH: - You have far less code, and it's more high-level, so just reading looking for errors it is more productive. - You can try out your code on the repl, seeing providing a stream of inputs and getting a stream of output. High level state machine errors (do you really nail this the first time with verilog?) are easily caught this way. - Because you have more opportunities to modularize your code, you have more opportunities to test components in isolation. Unit tests vs. System tests--y'all know the deal. The former is no panacea, but obviously it makes complete code/path coverage way more tractable computationally. - QuickCheck. I generate programs, run my single-cycle and pipeline processor for n cycles, see if they both halted and compare register/mem stage, otherwise throw out the test. I /suppose/ you could do this with C-augmented testbenches, but it would be way, way, way more code and effort. QuichCheck worked so well that I never wrote a test bench. - EVENTUALLY, with idris or [faking it with] dependent Haskell prove your circuit correct up to the synchronous model CLaSH is built around. In practice I can say I honestly wrote and debugged programs all from GHCi (the Haskell REPL, so very much in software land), and saw them work first time on the FPGA. Where this didn't happen was usually do to a black boxes, like megfunctions and other components on the dev board. Obviously my Haskell testing is of no use if I model them wrong in CLaSH. Finally, it would be dishonest and misleading to not mention CLaSH's downsides. CLaSH is designed assuming your circuit is totally synchronous (or purely combinatorial, but that's the trivial case). I don't know often this comes up in the real world, but in interfacing with the components on the dead board, I often had to do things that violated rigidly synchronous circuit design --- inverting my clock to get a second 180-degree-off clock domain, asynchronous communication with SRAM. [CLaSH supports multiple clock domains, but only knows about their relative frequency, not phase.] You can often still describe these circuit in CLaSH, but because it violates its synchronous model, it won't understand them and neither will your Haskell-land testing infrastructure. Basically you loose the benefits that made CLaSH great in the first place. Fundamentally, I think true fixing these cases means designing a lower-level "asynchronous CLaSH" that both normal CLaSH and these cases can elaborate to. Trying to tack them on as special cases to CLaSH and it's synchronous modle won't fly. But all is not lost, if you can contain the model-violation to one bit of code and give it kosher synchronous interface, you are all good. Write some Haskell to simulate what it does (need not be even in the subset CLaSH can understand), and make a Verilog/VHDL black box. CLaSH doesn't help you with that module, but that module doesn't pollute the rest of your program either. Most real-world designs are by and large synchronous, unless the world has been lying to me. So the quarantined modules would never form a significant part of your program. That about wraps it up, ...hope somebody's still reading this thread after writing all that.