Love to see this at the top of HN! I haven't written anything with this language yet, but I have met some of the developers of this language. They're pretty great and they are doing a lot of really good work in the open source hardware community. Another project they maintain is Surfer: https://surfer-project.org/
The challenge of a HDL over a regular sequential programming (software) language is that a software language is programmed in time, whereas a HDL is programmed in both space and time. As one HDL theory expert once told me "Too many high level HDLs try to abstract out time, when what they really need to do is expose time."
If the output SystemVerilog is unreadable I'm unlikely to use this. SV is still the lingua franca for physical tools. I'm not debugging timing on something that looks like this:
When debugging/fixing timing problems, or trying to implement a functional change using only metal layers - yes, it is absolutely still necessary to debug verilog at the gate level.
Also, "just a tooling issue" is a pretty big problem when you're talking about something that wants to be adopted as part of the toolchain.
I do for the most sensitive path of the design, but only because it's needed. I don't want to have to look at it for day-to-day debugging, where it's just a distraction.
SystemVerilog is a much better language than verilog. You can get pretty strong typed behaviour now, if you use the language parts that allow that. It's like C, if you use it poorly/the 'verilog way' it's got some serious footguns, but you can use it quite safely if you use the more modern features.
That said, I'm all for better languages, of they really are better and as expressive
To add, even before SV we've had VHDL which is also strongly typed and has other nice features. But I do still like using SV more than VHDL :3. I'm not wholly convinced of these languages that have been popping up so far.
I thought that this was about the hardware description language Clash developed by some ex-colleagues, but it appeared to be something else. Clash [1] is based on the functional programming language Haskell and it can output to VHDL, Verilog, or SystemVerilog.
Although the last official release mentioned on the website is from 2021, it is still actively developed on GitHub [2]. See also contranomy [3] for a non-pipelined RV32I RISC-V core written in Clash.
It'll be a long while before either gets enough traction to be serious competition to system erilog, even if SV is, compared to modern software languages, outdated.
How one writes circular circuit, for example stream of fibonnachi numbers or IIR filter? For IIR filter it would be nice if it has protoype like iir(sig : T, a : vec<T, N>, b : vec<T,M>) -> T
I think any HDL that is more inspired by functional languages (with better composability) is good. But yeah there is lot of inertia in using existing tools.
On the surface this seems like it strikes a nice balance between addressing issues with expressing digital design intent and not completely breaking the mental model digital designers are used to in traditional HDLs.
There are already Verilog and VHDL based tools alvilable. i think nopne likes to learn a third HDL. Including specific ideas into the hdl makes it less attractive to people
Each HDL has its own strengths, weaknesses, tool support & application areas. So each has its place as long as -for specific designs/projects- it's better than alternative HDLs. Users can define "better" for themselves.
Not to mention: existing designs already done in Verilog, VHDL or whatever. Converting such a design from one HDL to another may no be easy.
I'll take a closer look later, and I welcome anything that tries to bring concepts from modern programming languages to hardware design.
But. The focus on "CPU" examples on the landing page (A 3 stage CPU supporting Add, Sub, Set and Jump, "You can easily build an ALU") is immediately discouraging. I implement and verify FPGA designs for a living, and the vast, vast majority of my work is nothing like designing a CPU. So my fear is that this new hardware description language hasn't been created by a veteran who has many years of experience in using HDLs and therefore knows what and where the real pain points are, but by someone who's ultimately a software developer – even a highly skilled and motivated software developer – and who has never designed, implemented, and verified a large FPGA design. And skilled, motivated software developers without a lot of domain-specific experience tend to solve the wrong problems.
I think this commits the same sin many other new HDLs do -- it just tries to awkwardly smush the paradigm of clocked logic into a sequential software language. The abstractions just don't match, which means you lose the mental connection between the code and the generated Verilog, which makes debugging stuff like timing awkward.
I'm a big Bluespec booster, and beyond the nice typing and functional programming you get I think the big advance it brings to the table is the Guarded Atomic Action paradigm, which simplifies reasoning about what the code is doing and means that it's usually not too painful to poke at the generated HDL too since there's a clear connection between the two halves. At $WORK$ we've been using Bluespec very successfully in a small team to quickly iterate on hardware designs.
I don't want to denigrate the Spade developers since it's clearly a labor of love and nicely done, but I feel that unless the underlying mental model changes there's not much benefit to any of these neo-HDLs compared to SV or VHDL.
Haven't looked at this one, but IMHO HDL's are sort of the ultimate existence proof that "DSLs Are Bad Design Smell".
DSLs are great and elegant and beautiful for expressing a domain solution. Once. But real solutions evolve, and as they do they get messy, and when that happens you need to address that with software tools. And DSLs are, intentionally, inadequate to the tasks of large scale software design. So they add features[1], and we gets stuff like SystemC that looks almost like real programming. Except that it's walled off from updates in the broader community, so no tools like MSAN or whatnot, and you're working from decades-stale language standards, and everything is proprietary...
Honestly my sense is that it's just time to rip the bandaid off and generate synthesizable hardware from Python or Rust or whatnot. More syntax isn't what's needed.
[1] In what can be seen as an inevitable corollary of Greenspun's Tenth Rule, I guess.
I would argue that the prevalence of HDLs proves that DSLs are a good design for problem domains that scale in complexity. The alternative is point and click CAD, which has a ceiling on the scale of complexity you can reach.
> Honestly my sense is that it's just time to rip the bandaid off and generate synthesizable hardware from Python or Rust or whatnot. More syntax isn't what's needed.
People who think the problem is that they can't synthesize a program in hardware from something like Python completely misunderstand the purpose of an HDL. You do not write a program and press a button to get that program on hardware. You write a program to generate the design and verify its correctness. It is much less like writing an imperative or functional program and more like writing macros or code generation.
Now if you want to write a Python library for generating the underlying data for programming an FPGA or taping out circuits that's actually a good idea that people have tried out - the problem you run into though are network effects. Generating designs is easy, verifying and debugging them is very hard. All the money is in the tooling, and that tooling speaks HDLs.
> I would argue that the prevalence of HDLs proves that DSLs are a good design for problem domains that scale in complexity.
The major HDLs (i.e., Verilog/SystemVerilog and VHDL) are not DSLs in any meaningful sense of the word. There exist HDLs which actually are DSLs, but they're mostly used by hobbyist and aren't gaining any significant traction in the industry.
> Honestly my sense is that it's just time to rip the bandaid off and generate synthesizable hardware from Python or Rust or whatnot.
I worked a bit with VHDL and the parallelism aspect is - to me - so fundamentally different than what our sequential programming languages can express that I'm not sure I a layer of abstraction between this and that. How would that work?
TL;DR: The hardware modules you're generating are represented as first-class objects that can be constructed from a DSL embedded within Python or explicitly from a list of primitives.
You mean parallelism for simulation? Generate a simulator output from your input (in VHDL if you like) and run it in an appropriate runtime.
You don't need to run Python/whatever to simulate and you don't need (and probably don't want) your semantic constraints and checks to be expressed in python/whatever syntax. But the process of moving from a parametrized design through the inevitable cross-team-design-madness and decade-stale-design-mistake-workarounds needs to be managed in a development environment that can handle it.
I don't think this is about simulation. Python requires an additional DSL layer in order to express parallelism. I've personally no interest in learning that, or anything like that stuck on top some other language that's similarly unfit for HDL purposes.
Modern VHDL isn't too far off what we need. I'd rather see more improvements to that. But most crucially, we need tooling that actually supports the improvements and new features. We don't have that today, it's an absolute mess trying to use VHDL '19 with the industry's standard tools. We even avoid using '08 for fear of issues. I can't speak to how far off SV is.
Love to see this at the top of HN! I haven't written anything with this language yet, but I have met some of the developers of this language. They're pretty great and they are doing a lot of really good work in the open source hardware community. Another project they maintain is Surfer: https://surfer-project.org/
The challenge of a HDL over a regular sequential programming (software) language is that a software language is programmed in time, whereas a HDL is programmed in both space and time. As one HDL theory expert once told me "Too many high level HDLs try to abstract out time, when what they really need to do is expose time."
If the output SystemVerilog is unreadable I'm unlikely to use this. SV is still the lingua franca for physical tools. I'm not debugging timing on something that looks like this:
Fair, but it's just a tooling issue. You don't debug your Verilog anymore at the gate-level, do you?
When debugging/fixing timing problems, or trying to implement a functional change using only metal layers - yes, it is absolutely still necessary to debug verilog at the gate level.
Also, "just a tooling issue" is a pretty big problem when you're talking about something that wants to be adopted as part of the toolchain.
I do for the most sensitive path of the design, but only because it's needed. I don't want to have to look at it for day-to-day debugging, where it's just a distraction.
> just a tooling issue
The word "just" is carrying the weight of the world on its shoulders…
Whenever I see that I think of the Itanium where it was destined to be a success, the compiler just needed to...
It's been said that the arc of history bends toward just-ice...
If you're curious why people keep wanting to reinvent HDLs, these posts by Dan Luu might be useful:
- https://danluu.com/why-hardware-development-is-hard/
- https://danluu.com/pl-troll/
SystemVerilog is a much better language than verilog. You can get pretty strong typed behaviour now, if you use the language parts that allow that. It's like C, if you use it poorly/the 'verilog way' it's got some serious footguns, but you can use it quite safely if you use the more modern features.
That said, I'm all for better languages, of they really are better and as expressive
To add, even before SV we've had VHDL which is also strongly typed and has other nice features. But I do still like using SV more than VHDL :3. I'm not wholly convinced of these languages that have been popping up so far.
I thought that this was about the hardware description language Clash developed by some ex-colleagues, but it appeared to be something else. Clash [1] is based on the functional programming language Haskell and it can output to VHDL, Verilog, or SystemVerilog.
Although the last official release mentioned on the website is from 2021, it is still actively developed on GitHub [2]. See also contranomy [3] for a non-pipelined RV32I RISC-V core written in Clash.
[1] https://clash-lang.org/
[2] https://github.com/clash-lang/clash-compiler
[3] https://github.com/christiaanb/contranomy
Another new HDL: https://veryl-lang.org/
It'll be a long while before either gets enough traction to be serious competition to system erilog, even if SV is, compared to modern software languages, outdated.
How one writes circular circuit, for example stream of fibonnachi numbers or IIR filter? For IIR filter it would be nice if it has protoype like iir(sig : T, a : vec<T, N>, b : vec<T,M>) -> T
I think any HDL that is more inspired by functional languages (with better composability) is good. But yeah there is lot of inertia in using existing tools.
On the surface this seems like it strikes a nice balance between addressing issues with expressing digital design intent and not completely breaking the mental model digital designers are used to in traditional HDLs.
There are already Verilog and VHDL based tools alvilable. i think nopne likes to learn a third HDL. Including specific ideas into the hdl makes it less attractive to people
Each HDL has its own strengths, weaknesses, tool support & application areas. So each has its place as long as -for specific designs/projects- it's better than alternative HDLs. Users can define "better" for themselves.
Not to mention: existing designs already done in Verilog, VHDL or whatever. Converting such a design from one HDL to another may no be easy.
So as always: use the best tool for the job.
I'll take a closer look later, and I welcome anything that tries to bring concepts from modern programming languages to hardware design.
But. The focus on "CPU" examples on the landing page (A 3 stage CPU supporting Add, Sub, Set and Jump, "You can easily build an ALU") is immediately discouraging. I implement and verify FPGA designs for a living, and the vast, vast majority of my work is nothing like designing a CPU. So my fear is that this new hardware description language hasn't been created by a veteran who has many years of experience in using HDLs and therefore knows what and where the real pain points are, but by someone who's ultimately a software developer – even a highly skilled and motivated software developer – and who has never designed, implemented, and verified a large FPGA design. And skilled, motivated software developers without a lot of domain-specific experience tend to solve the wrong problems.
I would be happy to be proven wrong, though.
I wonder how it compares to Bluespec?
I think this commits the same sin many other new HDLs do -- it just tries to awkwardly smush the paradigm of clocked logic into a sequential software language. The abstractions just don't match, which means you lose the mental connection between the code and the generated Verilog, which makes debugging stuff like timing awkward.
I'm a big Bluespec booster, and beyond the nice typing and functional programming you get I think the big advance it brings to the table is the Guarded Atomic Action paradigm, which simplifies reasoning about what the code is doing and means that it's usually not too painful to poke at the generated HDL too since there's a clear connection between the two halves. At $WORK$ we've been using Bluespec very successfully in a small team to quickly iterate on hardware designs.
I don't want to denigrate the Spade developers since it's clearly a labor of love and nicely done, but I feel that unless the underlying mental model changes there's not much benefit to any of these neo-HDLs compared to SV or VHDL.
Where do you work that uses bluespec? Any open positions? Apologies for being forward.
Haven't looked at this one, but IMHO HDL's are sort of the ultimate existence proof that "DSLs Are Bad Design Smell".
DSLs are great and elegant and beautiful for expressing a domain solution. Once. But real solutions evolve, and as they do they get messy, and when that happens you need to address that with software tools. And DSLs are, intentionally, inadequate to the tasks of large scale software design. So they add features[1], and we gets stuff like SystemC that looks almost like real programming. Except that it's walled off from updates in the broader community, so no tools like MSAN or whatnot, and you're working from decades-stale language standards, and everything is proprietary...
Honestly my sense is that it's just time to rip the bandaid off and generate synthesizable hardware from Python or Rust or whatnot. More syntax isn't what's needed.
[1] In what can be seen as an inevitable corollary of Greenspun's Tenth Rule, I guess.
I would argue that the prevalence of HDLs proves that DSLs are a good design for problem domains that scale in complexity. The alternative is point and click CAD, which has a ceiling on the scale of complexity you can reach.
> Honestly my sense is that it's just time to rip the bandaid off and generate synthesizable hardware from Python or Rust or whatnot. More syntax isn't what's needed.
People who think the problem is that they can't synthesize a program in hardware from something like Python completely misunderstand the purpose of an HDL. You do not write a program and press a button to get that program on hardware. You write a program to generate the design and verify its correctness. It is much less like writing an imperative or functional program and more like writing macros or code generation.
Now if you want to write a Python library for generating the underlying data for programming an FPGA or taping out circuits that's actually a good idea that people have tried out - the problem you run into though are network effects. Generating designs is easy, verifying and debugging them is very hard. All the money is in the tooling, and that tooling speaks HDLs.
> more like writing macros or code generation
Tasks which are also best done by premier software development environments and not ad hoc copies of ideas from other areas.
> I would argue that the prevalence of HDLs proves that DSLs are a good design for problem domains that scale in complexity.
The major HDLs (i.e., Verilog/SystemVerilog and VHDL) are not DSLs in any meaningful sense of the word. There exist HDLs which actually are DSLs, but they're mostly used by hobbyist and aren't gaining any significant traction in the industry.
HDLs are the textbook definition of a domain specific language (the domain being the description of hardware, either it's behavior or design or both).
> Honestly my sense is that it's just time to rip the bandaid off and generate synthesizable hardware from Python or Rust or whatnot.
I worked a bit with VHDL and the parallelism aspect is - to me - so fundamentally different than what our sequential programming languages can express that I'm not sure I a layer of abstraction between this and that. How would that work?
See e.g. Migen [1], a Python HDL.
TL;DR: The hardware modules you're generating are represented as first-class objects that can be constructed from a DSL embedded within Python or explicitly from a list of primitives.
[1]: https://m-labs.hk/gateware/migen/
You mean parallelism for simulation? Generate a simulator output from your input (in VHDL if you like) and run it in an appropriate runtime.
You don't need to run Python/whatever to simulate and you don't need (and probably don't want) your semantic constraints and checks to be expressed in python/whatever syntax. But the process of moving from a parametrized design through the inevitable cross-team-design-madness and decade-stale-design-mistake-workarounds needs to be managed in a development environment that can handle it.
I don't think this is about simulation. Python requires an additional DSL layer in order to express parallelism. I've personally no interest in learning that, or anything like that stuck on top some other language that's similarly unfit for HDL purposes.
Modern VHDL isn't too far off what we need. I'd rather see more improvements to that. But most crucially, we need tooling that actually supports the improvements and new features. We don't have that today, it's an absolute mess trying to use VHDL '19 with the industry's standard tools. We even avoid using '08 for fear of issues. I can't speak to how far off SV is.