

CLaSH: A functional hardware description language - rwosync
http://hackage.haskell.org/package/clash-prelude-0.5/docs/CLaSH-Tutorial.html

======
sshine
I did my bachelor's project on translation between functional HDLs that were
also reversible, i.e. only describing total, bijective functions. The idea of
functional HDLs goes back to at least the 1970s, and the coolest language I
found was 𝜇FP by Mary Sheeran. It was an algebraic VLSI design language where
logical gates as combinators are the only language constructs.

~~~
jberryman
That sounds cool. I don't know anything about HDLs, but can you explain why
you might want your functions to be bijective? What does that give you in
hardware?

~~~
pseudonom-
Maybe for reversible computing? [0]

[0]
[https://en.wikipedia.org/wiki/Reversible_computing](https://en.wikipedia.org/wiki/Reversible_computing)

------
helpbygrace
I am hardware engineer in this industry. And I know Haskell and made my site
with Haskell language. But I do not understand why Haskell is used to hardware
design.

Designing hardware is much more important than describing hardware logic
itself. IMO, VISIO and Excel are the tools to design hardware logic not
Verilog nor like this CLaSH.

But, If this kind of HDL can be used along with Verilog, it might be helpful
to build verification IPs.

~~~
zhemao
Wait, so what are you using to describe the circuit on the logic or RTL level?
Do you have VLSI engineers using Cadence or something? From my understanding,
using Verilog in ASIC design (and not just verification) is pretty widespread
in industry.

~~~
platinum1
I think what he's saying is the architectural decisions outweigh the
implementation language.

When I was taught Verilog for IP implementation, one thing I noticed is that
people get caught in the trap of trying to abstract away the hardware or
approach it from a higher level. Haskell/Verilog 2001/SystemVerilog all give
us tools to do this. However, when trying to make real silicon, you need to
understand what is actually getting built (i.e. know exactly how many flip
flops you're creating and how they fan out) and then use the language to
describe it. If you use a 'for' loop to try to do computation, as you might in
a programming language, you could end up with something entirely unexpected or
unsynthesizable.

Traditionally you first design your module conceptually on a whiteboard (or
Excel, Viso, etc.), then implement it in an HDL. Because of the influx of
software engineers trying to get into hardware (via FPGAs, etc.), there has
been a trend in trying to obfuscate away the details of the implementation,
and this can cause a lot of confusion.

That said, I've heard of projects that already translate native Haskell to HDL
with some success. I'm not a programmer so I don't claim to understand if it's
a good idea, but I still think understanding exactly what's being output is
important to knowing if it can perform in a reasonable way, especially if
you're doing something of any complexity.

~~~
dkarapetyan
How is this any different from compiling C to assembly? Why would higher level
languages create unsynthesizable circuits? You trust the C compiler to create
the proper instructions for your target architecture then I don't see why the
same can't be done with a Haskell DSL that compiles to Verilog.

~~~
cantankerous
Higher level languages inevitably come with built in semantics that the
programmer takes for granted, but can't be synthesized directly to hardware.
In C, it's the function call stack. In Haskell it's higher order types and
recursive data structures (and more). You could in theory create some runtime
package that you'd compile to hardware for your program to be synthesized to,
or "run on".....but then you'd just be making a straight up computer, wouldn't
you. ;-)

~~~
jroesch
None of these things are relevant in most HDLs implemented as DSLs in high
level languages. The point of most of the HDL work in Haskell (for example
Lava, and Bluespec) is to provide primitives to talk about hardware and to use
a sane language as a way to manipulate them to build larger specifications. It
is embarrassing that people use tools that allow you to write un-synthesizable
code.

------
akuma73
There's already a commercial functional hardware description language called
Bluespec.
[http://en.wikipedia.org/wiki/Bluespec,_Inc](http://en.wikipedia.org/wiki/Bluespec,_Inc).

~~~
knz42
Bluespec has a strange story: initially it was developed like Clash, as a
subset of Haskell that could be translated to a HDL. However its users hated
the Haskell syntax, so the Bluespec designers added a layer of syntax on top
to make it look like more a HDL, and they also downplayed the powerful type
system for adoption.

Since then, Bluespec has not become too popular, but Haskell has. Clash may
have a chance.

------
smackay
In a former life (a long time ago), I used ELLA for designing processors. It
was a pretty decent functional language. Great at abstracting components or
subsystems and infinitely better than modelling stuff with C.

IIRC European Silicon Structures used to offer it as a part of their toolset
when VLSI design was young and hot.

[https://en.wikipedia.org/wiki/ELLA_%28programming_language%2...](https://en.wikipedia.org/wiki/ELLA_%28programming_language%29)

------
blueintegral
Is this meant for hardware people or software people? Because I'm a hardware
guy and I don't know Haskell. None of my EE friends know Haskell either. I
really don't see a serious hardware engineer using this over VHDL or Verilog,
even if it is more beautiful or provably better or whatever.

~~~
zhemao
Strangely enough, alternative HDLs embedded in Haskell seem to be a thing.
Besides this, there is also Bluespec and Lava.

[http://wiki.bluespec.com/](http://wiki.bluespec.com/)

[http://raintown.org/lava/](http://raintown.org/lava/)

~~~
sitkack
Tom Hawkins is probably around here somewhere.

[http://en.wikipedia.org/wiki/Atom_(programming_language)](http://en.wikipedia.org/wiki/Atom_\(programming_language\))

------
mikhael
without having looked at it in much detail, does anyone know how/whether this
is related at all to bluespec
([http://en.wikipedia.org/wiki/Bluespec,_Inc.](http://en.wikipedia.org/wiki/Bluespec,_Inc.))?

~~~
knz42
It's not related to bluespec. (cf my other comment in this thread)

------
ZenoArrow
Interesting language, I'll be interested to see how Clash develops.

------
psychometry
I think we have a winner for the most poorly named programming language of the
last decade. I thought that "Go" and "Hack" were bad, but at least I could
type those on my keyboard.

~~~
elliotec
Seriously. I spent more time trying to figure out how to read/say it than
reading about it. C(lambda)aSH? clambdaash? Oh, CLaSH.

~~~
dllthomas
Clam-dash. It makes your shellfish go fast, or your car smell.

------
mathieuh
Clash? C-lambda-ash? C-lambda-a-ess-aitch? C-lash?

