CλaSH – From Haskell to Hardware • Hacker News Board

Re: CλaSH – From Haskell to Hardware

#21

Post by MootWoop » Sat, May 09, 2015, 5:22 PM UTC

krick wrote: post #8

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?

That's the beauty (and sometimes the curse) of hardware design: it doesn't need a processor to run. You essentially describe an electronic circuit, and "program" (configure would be more appropriate) an FPGA to act like the circuit you described. A circuit can be as simple as you want (like a sequential counter) or very complex (people have implemented entire H.264 and HEVC decoders in hardware).

This is so powerful that in fact you can even describe your own processor, and prototype it on an FPGA for testing.

Re: CλaSH – From Haskell to Hardware

#22

Post by adwn » Sat, May 09, 2015, 5:58 PM UTC

MootWoop wrote: post #20

adwn wrote: post #16

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 th…

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 Enjoy!

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.

Re: CλaSH – From Haskell to Hardware

#23

Post by Tehnix » Sat, May 09, 2015, 6:27 PM UTC

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! :)

Re: CλaSH – From Haskell to Hardware

#24

Post by MootWoop » Sat, May 09, 2015, 7:07 PM UTC

adwn wrote: post #22

MootWoop wrote: post #20

Earlier quoted context omitted.

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 Enjoy!

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-c…

> 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.

Re: CλaSH – From Haskell to Hardware

#25

Post by pron » Sat, May 09, 2015, 7:25 PM UTC

adwn wrote: post #16

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 th…

What are your thoughts about Esterel[1]?

[1]: http://en.wikipedia.org/wiki/Esterel

Re: CλaSH – From Haskell to Hardware

#26

Post by cantankerous » Sat, May 09, 2015, 11:02 PM UTC

marvel_boy wrote: post #2

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

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

Re: CλaSH – From Haskell to Hardware

#27

Post by gluggymug » Sat, May 09, 2015, 11:54 PM UTC

adwn wrote: post #16

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 th…

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.

Re: CλaSH – From Haskell to Hardware

#28

Post by FullyFunctional » Sun, May 10, 2015, 2:54 AM UTC

gluggymug wrote: post #27

adwn wrote: post #16

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 th…

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 o…

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

Re: CλaSH – From Haskell to Hardware

#29

Post by gluggymug » Sun, May 10, 2015, 4:59 AM UTC

FullyFunctional wrote: post #28

gluggymug wrote: post #27

Earlier quoted context omitted.

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 o…

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 th…

Working in industry it IS straight Verilog directly. No macro language in Perl or anything else.

Maybe people use emacs to help make stuff neat but that's it. Qualcomm has their own tool that created register files for sub modules from a MSWord table and it sucked big time.

Parametrizing is just via `defines.

On the verification side, it is System Verilog or something similar. On top of that is a pile of crap called UVM.

For an engineer it does not matter about the language that describes the circuit. It does not matter how many lines it takes to add a pipeline stage. The effort is in creating the design itself, not how it is represented in text files.

Typical engineers write hundreds of lines every day when they feel like it. Think of the complexity of an SoC in a mobile device. There are millions of lines of Verilog for the design and the same or more lines of System Verilog to do the verification. Typing it in is the easiest part.

The real work is simulation of the design under test running millions of cycles. Say we are verifying the wifi, we have to simulate traffic of transactions to and from the device. Millions of transactions while the design is running at various clock speeds with other modules also creating traffic on the buses etc.

Waveforms and log files is the majority of the work.

These languages from academia don't fix anything I care about.

Re: CλaSH – From Haskell to Hardware

#30

Post by adwn » Sun, May 10, 2015, 6:21 AM UTC

gluggymug wrote: post #27

adwn wrote: post #16

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 th…

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 o…

Thank you for this perspective from the top. Sure, when verifying the final ASIC design, the problems of the implementation language don't matter much anymore. However, those IP cores have to be written by someone, and they actually get to suffer the deficiencies of the HDL.

> I would argue sequential stuff isn't that hard either. It's all undergrad engineering stuff studied in the first year or two.

So? That's like saying that "writing software isn't that hard either. It's all undergrad comp science studied in the first year or two", which is obviously false. If your tools and languages suck, they'll slow you down and you'll produce more bugs – in software as in hardware.

I often get the impression, that many hardware engineers don't even realize how much their tools suck, because the lack the perspective on the outside world, specifically the software world, to see better ways of doing things.