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.
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.
That said, I'm all for better languages, of they really are better and as expressive
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.
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.
localparam[14:0] _e_953 = 0;
localparam[14:0] _e_958 = 1;
assign _e_956 = \count + _e_958;
assign _e_955 = _e_956[14:0];
assign _e_948 = _e_949 ? _e_953 : _e_955;The word "just" is carrying the weight of the world on its shoulders…
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.
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.
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."
The hard part has never been writing HDL, it’s verifying HDL and making the verification as organized and as easy as possible. Teams spend something like 20% of time on design and 80%+ on verification allegedly (definitely true at my shop).
Edit: I see it’s tightly integrated with cocotb which is good. But someone needs to take a verification-first approach to writing a new language for HDL. It shouldn’t be a fun after thought, it’s a bulk of the job.
ajross•5h ago
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.
leonheld•5h ago
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?
ajross•4h ago
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.
nsteel•2h ago
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.
oasisaimlessly•4h ago
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/
duped•2h ago
> 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.
adwn•2h ago
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.
duped•2h ago
monocasa•47m ago
adwn•42m ago
ajross•1h ago
Tasks which are also best done by premier software development environments and not ad hoc copies of ideas from other areas.