4 ms·

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 c

by adwn 12y 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 12y 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 12y 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.
  - MootWoop 12y ago
    > it looked very promising Thanks! > Reading from a port twice seems to trigger a clock cycle (did I get that right?) You did! It is by design that reading from the same port twice will trigger a clock cycle :-) There are several reasons why we did it this way. First, having to always explicitly declare a new clock cycle (rather than having it inferred) is kind of ugly, because your code is full of "fence;" instructions. The second reason is that we thought this would actually prevent bugs ^^ (the third is for symmetry with writes I think) The thing with Cx is that, unlike VHDL/Verilog, reading a port can mean more than accessing a single signal, and similarly writing to a port can be more than writing a single signal. For example "sync" ports have an additional "valid" signal that is set to true for one cycle when data is written to the port. This is very handy, allowing synchronization between tasks (read becomes blocking) and is useful as a control signal (the "valid" signal serves as the write enable on a RAM for example). We also have a "sync ready" that adds an additional "ready" signal computed asynchronously and again useful for back-pressure control in pipelines, FIFOs, etc.
pron 12y ago
What are your thoughts about Esterel[1]? [1]: http://en.wikipedia.org/wiki/Esterel http://en.wikipedia.org/wiki/Esterel
- adwn 12y ago
  I don't have experience with Esterel in particular, but I can make some statements about imperative synchronous languages in general: - They're a step in the right direction (e.g., implicit state machines), but then they're doing too much of a good thing. For example, in my experience, "abort" and especially "suspend" statements are not that important in non-toy examples, but they make the compiler more complex. - Integrating external IP cores is difficult, but is absolutely essential for any real-world design. - Even small FPGA designs contain usually at least two clock domains. This situation is typically impossible to design in imperative synchronous languages.
  - pron 12y ago
    See Multiclock Esterel: http://link.springer.com/chapter/10.1007%2F3-540-44798-9_10 http://link.springer.com/chapter/10.1007%2F3-540-44798-9_10
  - pron 12y ago
    P.S. Note that Esterel isn't mainly meant to design circuits but to write safety-critical hard realtime software.
gluggymug 12y ago
I used to work in ASIC design and verification. I have to agree with you. I can't take any of this stuff seriously. They are all toys aimed at newbies. They address problems that are no problem at all to a qualified engineer in the profession. Combinatorial logic is not hard. I would argue sequential stuff isn't that hard either. It's all undergrad engineering stuff studied in the first year or two. The design size of a modern ASIC is at a massive scale that makes the problems of whichever description language trivial. Even the cheapest stuff has quite a few modules: memory controllers, CPU, caches, power stuff, bus controllers, various io modules, debugging modules. Nowadays it's multiple cores. Even the sub modules are just wrappers around other cores sometimes. The teams are large, usually in the dozens because the problems are non-trivial. This clash stuff is like building a mailbox. Engineers in the profession are designing and verifying the equivalent of an apartment complex.
- FullyFunctional 12y ago
  Reduceron, which I try to maintain, is written in York Lava. It has a module for writing sequential logic (called Recipe) and while it makes sequential logic way easier, I have been working on an alternative for a while. I completely agree that the sequential parts of a design is the challenging (= bug prone) part and IMO this is the area where an EDSL like Lava can really shine. If you have worked in ASIC designs that you are almost certainly used to not work with Verilog directly, but with an ad-hoc macro language. I've seen them all, but most commonly Perl is used. It is especially for circuits that we desperately need better tools and abstractions. When designing with Lava you aren't describing a circuit, but a the method to create that circuit. That makes it relatively trivial to completely parametrize it or statically check properties of the circuit. As an example, if done right (Recipe isn't), adding a pipeline stage can be a matter of adding a single line. Compare that to what it takes in say Verilog. This style of ASIC development is simply incomparable to the primitive Verilog-style, but there's not enough experience in the industry to understand it [yet]. Now, Clash isn't (IIUC) an EDSL like Lava so without knowing more about it, I fear it looses much of the point. EDIT: formatting
  - gluggymug 12y ago

by adwn 12y ago

MootWoop 12y 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 12y 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.
- MootWoop 12y ago
  > it looked very promising Thanks! > Reading from a port twice seems to trigger a clock cycle (did I get that right?) You did! It is by design that reading from the same port twice will trigger a clock cycle :-) There are several reasons why we did it this way. First, having to always explicitly declare a new clock cycle (rather than having it inferred) is kind of ugly, because your code is full of "fence;" instructions. The second reason is that we thought this would actually prevent bugs ^^ (the third is for symmetry with writes I think) The thing with Cx is that, unlike VHDL/Verilog, reading a port can mean more than accessing a single signal, and similarly writing to a port can be more than writing a single signal. For example "sync" ports have an additional "valid" signal that is set to true for one cycle when data is written to the port. This is very handy, allowing synchronization between tasks (read becomes blocking) and is useful as a control signal (the "valid" signal serves as the write enable on a RAM for example). We also have a "sync ready" that adds an additional "ready" signal computed asynchronously and again useful for back-pressure control in pipelines, FIFOs, etc.

pron 12y ago

What are your thoughts about Esterel[1]? [1]: http://en.wikipedia.org/wiki/Esterel http://en.wikipedia.org/wiki/Esterel

adwn 12y ago
I don't have experience with Esterel in particular, but I can make some statements about imperative synchronous languages in general: - They're a step in the right direction (e.g., implicit state machines), but then they're doing too much of a good thing. For example, in my experience, "abort" and especially "suspend" statements are not that important in non-toy examples, but they make the compiler more complex. - Integrating external IP cores is difficult, but is absolutely essential for any real-world design. - Even small FPGA designs contain usually at least two clock domains. This situation is typically impossible to design in imperative synchronous languages.
- pron 12y ago
  See Multiclock Esterel: http://link.springer.com/chapter/10.1007%2F3-540-44798-9_10 http://link.springer.com/chapter/10.1007%2F3-540-44798-9_10
- pron 12y ago
  P.S. Note that Esterel isn't mainly meant to design circuits but to write safety-critical hard realtime software.

gluggymug 12y ago

I used to work in ASIC design and verification. I have to agree with you. I can't take any of this stuff seriously. They are all toys aimed at newbies. They address problems that are no problem at all to a qualified engineer in the profession. Combinatorial logic is not hard. I would argue sequential stuff isn't that hard either. It's all undergrad engineering stuff studied in the first year or two. The design size of a modern ASIC is at a massive scale that makes the problems of whichever description language trivial. Even the cheapest stuff has quite a few modules: memory controllers, CPU, caches, power stuff, bus controllers, various io modules, debugging modules. Nowadays it's multiple cores. Even the sub modules are just wrappers around other cores sometimes. The teams are large, usually in the dozens because the problems are non-trivial. This clash stuff is like building a mailbox. Engineers in the profession are designing and verifying the equivalent of an apartment complex.

FullyFunctional 12y ago
Reduceron, which I try to maintain, is written in York Lava. It has a module for writing sequential logic (called Recipe) and while it makes sequential logic way easier, I have been working on an alternative for a while. I completely agree that the sequential parts of a design is the challenging (= bug prone) part and IMO this is the area where an EDSL like Lava can really shine. If you have worked in ASIC designs that you are almost certainly used to not work with Verilog directly, but with an ad-hoc macro language. I've seen them all, but most commonly Perl is used. It is especially for circuits that we desperately need better tools and abstractions. When designing with Lava you aren't describing a circuit, but a the method to create that circuit. That makes it relatively trivial to completely parametrize it or statically check properties of the circuit. As an example, if done right (Recipe isn't), adding a pipeline stage can be a matter of adding a single line. Compare that to what it takes in say Verilog. This style of ASIC development is simply incomparable to the primitive Verilog-style, but there's not enough experience in the industry to understand it [yet]. Now, Clash isn't (IIUC) an EDSL like Lava so without knowing more about it, I fear it looses much of the point. EDIT: formatting
- gluggymug 12y ago