Spade Hardware Description Language
19 comments
·May 12, 2025smallpipe
alain94040
Fair, but it's just a tooling issue. You don't debug your Verilog anymore at the gate-level, do you?
smallpipe
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.
adwn
> just a tooling issue
The word "just" is carrying the weight of the world on its shoulders…
Philpax
If you're curious why people keep wanting to reinvent HDLs, these posts by Dan Luu might be useful:
tails4e
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
wirybeige
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.
fjfaase
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.
js8
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.
chrsw
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.
null
adwn
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.
Surac
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
Symmetry
I wonder how it compares to Bluespec?
grquantum
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.
ajross
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.
leonheld
> 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?
oasisaimlessly
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.
ajross
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.
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: