I have a couple of articles on my website about my experiences with (previous versions of) Clash if anyone wants some examples. I used Clash in a processor design class and it was amazing. We had some "competitions" between the various CPUs in the class (e.g. performance and correctness given some ISA spec) and I was able to create one of the top few CPUs with only a small fraction of the effort of my classmates using a "traditional" HDL like VHDL or Verilog.
The biggest pain point of "programming" hardware is the vendor tools. Imagine if all modern languages from Swift to Rust, from Python to Fortran, will all compile to C. The same situation is with HDLs - most of them compile to Verilog (some to VHDL). The world needs an open standard to rule them all - low-level HDL IR, that like LLVM can give birth to the endless variations of the cool languages, while giving them all flexibility they need. The synthesizing part would have to be written only once too. I proposed joining efforts[1] on building such a language either from scratch or based on something existing.
There was some interesting discussion between the LLHD[1] and MLIR[2] folks about just this topic recently[3]. My takeaway: modeling behavioral HDL semantics in the IR is a huge mess that has to account for all of the complexity in the existing HDL landscape. However, there is hope for modeling structural HDL semantics in an IR that could be the target for many languages.
You mentioned LLVM, and I think of MLIR as sort of a successor to LLVM. I'm hopeful that a low-level HDL IR is standardized as an MLIR dialect, so the compiler ecosystem and the hardware ecosystem can start to unite.
There was another language kinda similar to this (functional language HDL), called Bluespec. It was originally very Haskell-like, but at some point had to change its syntax to a more C-like version because of its unpopularity with hardware engineers. I had to use the newer version at my Computer Architecture class, and although the experience was way better than Verilog, it had very little documention/tutorials (being a commercial product and having almost no users), which made understanding the more complex parts of the language really hard.
Nowadays Chisel seems to be the best bet if you want a sane Verilog alternative (with functional-lang features) for your HDL needs. (https://www.chisel-lang.org/) It was originally a transpiler to Verilog, but recently it began to have its own IR code (FIRRTL) for optimization purposes.
As I recall, Chisel is a very shallowly embedded HDL, which is completely different from the approach used by Clash. Clash is a subset of Haskell that is directly compiled to a hardware representation, which has some unique advantages and disadvantages. One big advantage of Clash's approach is that you can code from any regular Haskell library as long as the code is within the subset of Haskell supported by Clash. E.g. you could import `Linear.V3` and have access to a 3-dimensional vector type with all the operators and stuff already defined, and this would compile to hardware no problem.
It turns out that Haskell's non-strict semantics are a shockingly close match for the semantics of hardware (the only difference I'm aware of being pretty obscure, having to do with zero-width busses).
> It turns out that Haskell's non-strict semantics are a shockingly close match for the semantics of hardware
Doesn't Haskell need automatic memory management in order to implement higher-order functions, that being perhaps the most prominent difference in semantics between Haskell/Ocaml and Rust? Is Clash limited to first-class functions ala C?
Bluespec is still around and actually got open-sourced recently! [0] The Bluespec company is focused on using their tools to build RISC-V cores: https://bluespec.com/
Well, I continue to ask myself what the advantage should be, if there are synthesizable subsets for more and more programming languages, to be able to develop hardware with them. The people who absolutely want to use a functional programming language for this can already use e.g. Chisel or SpinalHDL, for example, which are based on Scala. So now there is yet another HDL based on Haskell (don't forget e.g. Bluespec). There are also HDL based on OCaml or ML. But I think it is not wrong to assume that the task of developing error free hardware hasn't become easier hence.
> if there are synthesizable subsets for more and more programming languages
Haskell is the only language I'm aware of that has semantics approaching those of hardware - in particular, purity and non-strict evaluation are absolutely required to match (or closely approximate) the semantics of digital hardware. (To get you started - bottom is equivalent to X in the HDL simulator nomenclature)
> Chisel or SpinalHDL... HDL based on OCaml or ML
Chisel is a shallow embedding. Not sure about SpinalHDL. Hardcaml is a shallow embedding. Very different approach from Clash, and I prefer Clash's deep/direct embedding approach.
I don't think this builds right now, but it's my favorite example of a project really leveraging the expressivity of Clash to do hardware design: https://github.com/cbiffle/cfm
I hate to rag on new stuff, especially in the HDL space where I think it's desperately needed, but the syntax of this language is so foreign that I think it's extremely unlikely you really get a large amount of adoption. We can't even get Verilog 1995 people to switch to 2001, let along SystemVerilog.
I think this works well for people who are interested in both Haskell and hardware design. The syntax is pretty nutty if you're just a hardware designer, but it's ultimately a language embedded in Haskell, so it has the friction of having to be embedded but the benefit of the Haskell ecosystem. I don't think it'll see super wide adoption, but imagine it will have its uses and fans.
I know it's not new stuff, go look at Bluespec and their open-source HDL.
For most hardware designers though, it is new. Most hardware designers are EEs and not CS people. I know many designers that do not even want to learn a programming language like python which has a relatively easy to read syntax. ML/Functional Programming languages require a completely different mindset, just like hardware designing does if you come from programming languages.
I think the world is ripe for a new HDL. But the right foundations need to be there. It needs first class support with existing HDLs (VHDL, Verilog/SV). It needs to integrate with all the existing EDA tools in mixed language environments, and be easy to debug. Debugging is a huge problem in the "new HDL" space right now. Go look at Chisel. Google used it to design some of if not all of their TPU, but their Verif engineers had a really difficult time with the debug because it compiled to verilog, and then was difficult to reason about.
I have so many thoughts on this space and I want to make it better. It would be an absolute dream to develop a new HDL that enabled Hardware designers and Verif engineers to have all the superpowers that SWEs have in today's world. Being both proficient in various programming languages and Verilog/SV/UVM/etc, its so wild to see how big of a gap there is in productivity tools. Essentially SWEs have all the good stuff.
Clash needs Verilog and VHDL to Clash translators. Make the translator available online for learning purposes, for small samples. Then you can at least leverge your existing knowledge, see how it translates to the new language, and then a tutorial using this could easily show how it's an improvement, either in expressiveness or safety checking.
Ok, now can we have automatic Clash-to-Linux-dts (Device Tree Source) generation? So we can port Linux to a new board with a click? That would be something. And it might drive adoption of Clash, just for that integration advantage.
I think you might be skipping a few layers of abstraction there, but you could have something like a parametric PCIe or I2C core that would autogenerate both the hardware (de)serialization logic and the Linux-side driver logic. If your driver was written in Haskell, you could even use the exact same library on the hardware side and the software side. So let's say you have an FPGA card in a PCIe slot - with a change to a single file, you could change the wire protocol on both the Linux side and the FPGA side.
I think this is just the abstraction needed to generate the device tree. Pinouts, bus address strapping, modes - all are/could be specified in the Clash and emitted thru some template or schema. I guess that's the missing part - the dts schema. But its the closest we've ever got!
It's wouldn't be too hard to build. Clash types are already required to derive Generic. You could take all those definition and use the Haskell Generic API to generate a device tree.
This reminds me of Cryptol https://cryptol.net which can be compiled into VHDL. It is a more general language than its description as cryptographic DSL suggests.
Readit News
Slides from a clash talk I gave in probably 2016:
https://yager.io/talks/CLaSH.pdf
Simple non-pipelined CPU (I've been meaning to release part 2 for years but never got around to it):
https://yager.io/CPU/CPU1.html
SKI calculus processor on an FPGA:
https://yager.io/HaSKI/HaSKI.html
A superscalar out-of-order processor I built for a CPU design class at UT Austin:
https://github.com/wyager/Lambda17
(Take a look at Hardware.hs to see some of the cool parametric stuff you can do.)
Like I said, these are all with old versions of Clash - it's changed in the last few years, but I haven't done any HDL projects recently.
[1] https://github.com/SymbiFlow/ideas/issues/19
You mentioned LLVM, and I think of MLIR as sort of a successor to LLVM. I'm hopeful that a low-level HDL IR is standardized as an MLIR dialect, so the compiler ecosystem and the hardware ecosystem can start to unite.
[1] https://news.ycombinator.com/item?id=22825107 [2] https://news.ycombinator.com/item?id=22429107 [3] https://drive.google.com/file/d/1x7B0IRdcJ5JBQvfHbPUBcShbTFC...
https://github.com/masc-ucsc/livehd
Nowadays Chisel seems to be the best bet if you want a sane Verilog alternative (with functional-lang features) for your HDL needs. (https://www.chisel-lang.org/) It was originally a transpiler to Verilog, but recently it began to have its own IR code (FIRRTL) for optimization purposes.
It turns out that Haskell's non-strict semantics are a shockingly close match for the semantics of hardware (the only difference I'm aware of being pretty obscure, having to do with zero-width busses).
Doesn't Haskell need automatic memory management in order to implement higher-order functions, that being perhaps the most prominent difference in semantics between Haskell/Ocaml and Rust? Is Clash limited to first-class functions ala C?
[0]: https://github.com/B-Lang-org/bsc
Clash has been around for a while now.
Deleted Comment
Haskell is the only language I'm aware of that has semantics approaching those of hardware - in particular, purity and non-strict evaluation are absolutely required to match (or closely approximate) the semantics of digital hardware. (To get you started - bottom is equivalent to X in the HDL simulator nomenclature)
> Chisel or SpinalHDL... HDL based on OCaml or ML
Chisel is a shallow embedding. Not sure about SpinalHDL. Hardcaml is a shallow embedding. Very different approach from Clash, and I prefer Clash's deep/direct embedding approach.
This intersection is not likely to differ much from the empty set.
Haskell/ML syntax is hardly "new stuff".
> I think it's extremely unlikely you really get a large amount of adoption
Clash is used to manufacture production hardware by at least one of the top 5 largest companies in the world.
For most hardware designers though, it is new. Most hardware designers are EEs and not CS people. I know many designers that do not even want to learn a programming language like python which has a relatively easy to read syntax. ML/Functional Programming languages require a completely different mindset, just like hardware designing does if you come from programming languages.
I think the world is ripe for a new HDL. But the right foundations need to be there. It needs first class support with existing HDLs (VHDL, Verilog/SV). It needs to integrate with all the existing EDA tools in mixed language environments, and be easy to debug. Debugging is a huge problem in the "new HDL" space right now. Go look at Chisel. Google used it to design some of if not all of their TPU, but their Verif engineers had a really difficult time with the debug because it compiled to verilog, and then was difficult to reason about.
I have so many thoughts on this space and I want to make it better. It would be an absolute dream to develop a new HDL that enabled Hardware designers and Verif engineers to have all the superpowers that SWEs have in today's world. Being both proficient in various programming languages and Verilog/SV/UVM/etc, its so wild to see how big of a gap there is in productivity tools. Essentially SWEs have all the good stuff.
Can you elaborate on that?