Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

CλaSH – From Haskell to Hardware

clash-lang.org

Post reply on HN
Print view View original

41–50 of 56 posts

Re: CλaSH – From Haskell to Hardware

#41

Post by MootWoop »

gluggymug wrote: post #35
adwn wrote: post #30

Earlier quoted context omitted.

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

I wrote and verified IP and I worked at the SoC integration level. I would say hardware engineers realize the tools suck but this stuff is targeting issues I don't care about. The bugs are not due to language generally. If software guys want to write a new language for HW engineers, they need to ask HW engineers what the issues are rather then go off on a tangent. As it is they don't even know what the workflow is li…

> The bugs are not due to language generally.

That's like saying that buffer overflows are not due to how strings are represented in C. Yes a bug is the programmer's fault, but languages can make it harder to have bugs in the first place (for instance you can't have buffer overflows in any other higher level language than C).

In the case of the hardware industry, we see a language with a weak type system (Verilog). So the "solution" is to use lint tools to check that your design is properly typed. Similarly, nothing in VHDL/Verilog prevents you from accidentally creating latches, or crossing domains badly, or many other small bugs. So again, the "solution" is to do extensive verification. That's the Haskell VS Python debate: you can either make it impossible to have a certain class of bugs (and detect them very early), or you can just write a lot of tests (which, in the case of hardware, take forever to run).

The same logic extends at a higher level. You can have a language that models common patterns (like a synchronous loop, a "ready before valid" port) so you can reduce the amount of verification needed because you don't need to always re-verify everything. One could even argue that having such higher-level mechanisms would also make static verification easier, since you might reason in terms of transactions rather than updates to registers.

Re: CλaSH – From Haskell to Hardware

#42

Post by MootWoop »

adwn wrote: post #33
sigterm wrote: post #32

Earlier quoted context omitted.

I am a pretty junior ASIC engineer who has relatively more exposure to software world compared to many of my peers. In my last project I did some IP integration work and the lack of decent development tools led to significant chores. I did make use of Emacs verilog-mode like GP mentioned and even wrote some small macros in elisp but overall experience is far from satisfactory. Not to even mention the usability of pro…

> I want to make some difference. But I'm not sure where to start... 1. Take a promising language, improve it where necessary. 2. Add excellent support for translation to VHDL and Verilog. The generated HDL code has to be readable, editable, and it has to reflect the structure of the original code more or less 1:1. You also need to support "inline VHDL/Verilog" (like inline assembly in software). Otherwise, your lang…

2. I am curious to hear what you think about our solution of wrapping existing VHDL/Verilog in an external task in Cx? http://cx-lang.org/documentation/tasks#external

Re: CλaSH – From Haskell to Hardware

#43

Post by pron »

adwn wrote: post #31
pron wrote: post #25

Earlier quoted context omitted.

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

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

See Multiclock Esterel: http://link.springer.com/chapter/10.1007%2F3-540-44798-9_10

Re: CλaSH – From Haskell to Hardware

#44

Post by pron »

MootWoop wrote: post #40
gluggymug wrote: post #29

Earlier quoted context omitted.

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…

> For an engineer it does not matter about the language that describes the circuit. [...] Typing it in is the easiest part. Well... once upon a time, people were writing software with assembly, and they probably didn't care about the number of lines either. After all, typing was easy, in fact the only problem was just porting your program to a different architecture :-) You talk about the complexity of a SoC, and you…

> So how do software engineers manage all that? They use better languages than assembly.

Well, better languages than assembly, yes, but the situation is not so simple. In the past 40 years or so in the software industry, there were two, and exactly two, language-related major productivity leaps in the production of "serious" software: C and Java. Java didn't add too much in expressivity over C (in fact, it added less than C++ had), and neither did C add a lot of expressivity over assembly (more convenient syntax but not too many new abstractions) -- but both added a lot in terms of safety, modularity, portability and the like.

The problem is that we haven't been able to make yet another significant jump. Much of current PL research focuses on expressivity and proof of correctness -- two things that aren't the really painful problems for the software industry these days, and aren't what made C and Java such productivity boosters, either. In both cases, productivity was enhanced not through some clever language syntax design, but through the ecosystem the language supported (i.e. extra-linguistic features).

Yes, some other languages like Ruby added some productivity benefits, but mostly in the "toy" application department -- the same kind of applications people used to use MS Access or VB for, or other "application generators" prior to those -- and you see Ruby shops transitioning to Java as they become "serious". The thing is that with modern hardware, even toy software projects are quite usable, but this isn't the case with hardware design.

Re: CλaSH – From Haskell to Hardware

#45

Post by MootWoop »

MootWoop wrote: post #40
gluggymug wrote: post #29

Earlier quoted context omitted.

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…

> For an engineer it does not matter about the language that describes the circuit. [...] Typing it in is the easiest part. Well... once upon a time, people were writing software with assembly, and they probably didn't care about the number of lines either. After all, typing was easy, in fact the only problem was just porting your program to a different architecture :-) You talk about the complexity of a SoC, and you…

To whomever downvoted this: would you mind telling me why? Have I offended you in some way? Is it because of the criticism of the hardware industry? Or the sarcasm?

Re: CλaSH – From Haskell to Hardware

#46

Post by gluggymug »

MootWoop wrote: post #40
gluggymug wrote: post #29

Earlier quoted context omitted.

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…

> For an engineer it does not matter about the language that describes the circuit. [...] Typing it in is the easiest part. Well... once upon a time, people were writing software with assembly, and they probably didn't care about the number of lines either. After all, typing was easy, in fact the only problem was just porting your program to a different architecture :-) You talk about the complexity of a SoC, and you…

Today's beginners don't make the tools.

I must be too old. The new guys can come and bring their new tools. I am retired now.

Back when I started, we used to care how the older engineers did stuff. The academics who trained us at uni had never worked in industry and had no real clue. Hence we had to learn the real stuff from the older guys. These days we are the old guys but just treated like yesterday's newspaper.

Re: CλaSH – From Haskell to Hardware

#47

Post by MootWoop »

pron wrote: post #44
MootWoop wrote: post #40

Earlier quoted context omitted.

> For an engineer it does not matter about the language that describes the circuit. [...] Typing it in is the easiest part. Well... once upon a time, people were writing software with assembly, and they probably didn't care about the number of lines either. After all, typing was easy, in fact the only problem was just porting your program to a different architecture :-) You talk about the complexity of a SoC, and you…

> So how do software engineers manage all that? They use better languages than assembly. Well, better languages than assembly, yes, but the situation is not so simple. In the past 40 years or so in the software industry, there were two, and exactly two, language-related major productivity leaps in the production of "serious" software: C and Java. Java didn't add too much in expressivity over C (in fact, it added less…

Good point about the reasons of productivity leaps. Funnily enough, I recall that one of the main selling points of Java was portability (the famous "Write Once Run Everywhere"), even though C was already supposed to be portable; but the environment wasn't, and you still had to develop OS-specific code.

Anyway, yes I agree the ecosystem is key. This is why a lot of new languages are either running on the JVM (like Clojure and Scala) or are interoperable with C (like Rust and Nim). In other cases, languages have managed to create an entire ecosystem very rapidly (Node.js and Javascript in general, Ruby and others).

> The thing is that with modern hardware, even toy software projects are quite usable

You're right. I must admit I'm not a big fan of this "throw more at the problem" approach, and I wonder for how long this approach will work. After all, Moore's law is slowing down, as the unit cost per transistor has stopped decreasing after 28nm.

> but this isn't the case with hardware design.

Yes, for one because if you design hardware that is sub-optimal, in other words that requires more transistors, that translates into higher costs, and lower margins. That's some powerful incentive IMO. Not to mention that if the hardware is not powerful enough, the toy software projects that you mention will have trouble running ^^

Therefore I think a central question is the loss of performance compared to the gain in productivity. A naive translation of C to assembly leads to disastrous performance. For years (decades?) people had to resort to assembly for speed-critical routines, and you can still find assembly in video decoders for instance. But the productivity is so much higher than the loss of performance is acceptable.

Re: CλaSH – From Haskell to Hardware

#48

Post by MootWoop »

gluggymug wrote: post #46
MootWoop wrote: post #40

Earlier quoted context omitted.

> For an engineer it does not matter about the language that describes the circuit. [...] Typing it in is the easiest part. Well... once upon a time, people were writing software with assembly, and they probably didn't care about the number of lines either. After all, typing was easy, in fact the only problem was just porting your program to a different architecture :-) You talk about the complexity of a SoC, and you…

Today's beginners don't make the tools. I must be too old. The new guys can come and bring their new tools. I am retired now. Back when I started, we used to care how the older engineers did stuff. The academics who trained us at uni had never worked in industry and had no real clue. Hence we had to learn the real stuff from the older guys. These days we are the old guys but just treated like yesterday's newspaper.

> Today's beginners don't make the tools.

Not necessarily, I am a beginner in hardware design, and I am creating a new programming language and IDE for hardware design.

> The academics who trained us at uni had never worked in industry and had no real clue. Hence we had to learn the real stuff from the older guys.

I can relate, this is by talking to older designers that my co-founder and myself learned that CDC is a big thing to address for instance. But a lot of times we were just dismissed as too young and inexperienced. Anyway, I'm curious, in your opinion what would be the biggest pain points in digital hardware design today?

Re: CλaSH – From Haskell to Hardware

#49

Post by adwn »

MootWoop wrote: post #42
adwn wrote: post #33

Earlier quoted context omitted.

> I want to make some difference. But I'm not sure where to start... 1. Take a promising language, improve it where necessary. 2. Add excellent support for translation to VHDL and Verilog. The generated HDL code has to be readable, editable, and it has to reflect the structure of the original code more or less 1:1. You also need to support "inline VHDL/Verilog" (like inline assembly in software). Otherwise, your lang…

2. I am curious to hear what you think about our solution of wrapping existing VHDL/Verilog in an external task in Cx? http://cx-lang.org/documentation/tasks#external

Very nicely done!

Is there a way to get in contact with you? I suppose you're either Nicolas or Matthieu?

Re: CλaSH – From Haskell to Hardware

#50

Post by MootWoop »

adwn wrote: post #49
MootWoop wrote: post #42

Earlier quoted context omitted.

2. I am curious to hear what you think about our solution of wrapping existing VHDL/Verilog in an external task in Cx? http://cx-lang.org/documentation/tasks#external

Very nicely done! Is there a way to get in contact with you? I suppose you're either Nicolas or Matthieu?

Yep, I'm Matthieu! You can send me an email at matthieu.wipliez at synflow.com
Post reply on HN