[HN Gopher] Spade Hardware Description Language
___________________________________________________________________
Spade Hardware Description Language
Author : spmcl
Score : 100 points
Date : 2025-05-12 12:19 UTC (10 hours ago)
(HTM) web link (spade-lang.org)
(TXT) w3m dump (spade-lang.org)
| ajross wrote:
| 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 wrote:
| > 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?
| ajross wrote:
| 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.
| nsteel wrote:
| 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.
| oasisaimlessly wrote:
| 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/
| duped wrote:
| 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.
| adwn wrote:
| > _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.
| duped wrote:
| 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).
| monocasa wrote:
| That's like saying that software languages are all DSLs,
| the domain being the description of von Neumann style
| software.
| ajross wrote:
| Lots of "DSLs" are general purpose Turing-complete
| environments. What distinguishes them is their specific
| features that target a particular usage, usually just
| limited to syntax that directly reflects the domain in
| question.
|
| But my point upthread is that even though these are
| "general purpose", they're still _extremely_ limited in
| Practical Expressive Power for Large Scale Development,
| simply by being weird things that most people don 't
| learn.
|
| Python and Rust and even C++ projects can draw on decades
| of community experience and best practices and tools and
| tutorials that tell you how to get stuff done in their
| environments (and importantly how not to do things).
|
| Literally the smartest people in software are trying to
| help you write Python et. al... With e.g. SystemVerilog
| you're limited to whatever the yahoos at Synopsys thought
| was a good idea. It's not the same.
| adwn wrote:
| Okay, I grant that HDLs fall under the wider definition
| of "domain specific language". I was thinking of the
| narrower definition, which is apparently more precisely
| called "embedded DSL" - a language which is a
| specialization of a general purpose language,
| respectively embedded or defined within a GPL.
| ajross wrote:
| > 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.
| Surac wrote:
| 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
| RetroTechie wrote:
| 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.
| thezoq2 wrote:
| Chisel, BlueSpec Spinal and Migen are already used quite a bit
| though of course much less so than Verilog. But we do need new
| languages, https://drops.dagstuhl.de/storage/00lipics/lipics-
| vol136-sna... does a pretty good job at articulating why
| adwn wrote:
| 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.
| thezoq2 wrote:
| Spade author here!
|
| That's a good reminder that I need to update the example on the
| website, I must have written that example almost 3 years ago at
| this point :)
|
| For more up to date motivation, my talk from LatchUp last year
| is probably the best one I have
| https://www.youtube.com/watch?v=_EdOHbY2dlg&t=277s
|
| > 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
|
| That's annoyingly quite close to the truth :D But I think I
| have enough experience now to not be completely stumbling
| around in the dark
| Philpax wrote:
| 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/
| tails4e wrote:
| 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 wrote:
| 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.
| IshKebab wrote:
| It's better than Verilog but it's still awful. If you thought
| C had footguns....
| Symmetry wrote:
| I wonder how it compares to Bluespec?
| grquantum wrote:
| 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.
| fooblaster wrote:
| Where do you work that uses bluespec? Any open positions?
| Apologies for being forward.
| thezoq2 wrote:
| Spade author here! The biggest difference is that BlueSpec uses
| a different abstraction than standard "RTL". That has
| significant advantages of course, but also means some overhead
| and a shift in mental model.
|
| With Spade my goal is to build new abstractions on top of RTL.
| That should allow you to operate at a higher abstraction level
| with minimal overhead most of the time, and dive down to
| regular RTL when necessary
| fjfaase wrote:
| 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
| thezoq2 wrote:
| Clash was the HDL that I used before starting Spade. I'm not a
| huge fan of haskell and wanted a few more hardware specific
| features which is why I didn't stick with it.
|
| That said, Clash is great and I know quite a few people at
| QBay. They don't seem to be slowing down any time soon!
| chrsw wrote:
| 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.
| smallpipe wrote:
| 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:
| 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;
| alain94040 wrote:
| Fair, but it's just a tooling issue. You don't debug your
| Verilog anymore at the gate-level, do you?
| adwn wrote:
| > _just a tooling issue_
|
| The word "just" is carrying the weight of the world on its
| shoulders...
| TeMPOraL wrote:
| It's been said that the arc of history bends toward just-
| ice...
| Pet_Ant wrote:
| Whenever I see that I think of the Itanium where it was
| destined to be a success, the compiler just needed to...
| smallpipe wrote:
| 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.
| variaga wrote:
| 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.
| thezoq2 wrote:
| Spade author here!
|
| My probably controversial opinion on output code quality is
| that if you have to see the generated Verilog, I've done
| something wrong since there is probably a compiler bug if you
| need to go down to that level.
|
| Of course, you could just be looking at output from tools like
| timing reports, and then as someone else commented out, it is a
| bit of a tooling issue. Spade does emit (* src = *) attributes
| which yosys and friends accept to show the original Spade
| source instead of Verilog, but it is still kind of leaky in
| some cases
| IshKebab wrote:
| Yeah.... I mean I get where you're coming from because how
| often do you have to look at disassembly to debug a C bug?
| Very rarely.
|
| But that's because _the tools debug at the C level_. That isn
| 't the case for SV at all - all the tools operate at the SV
| level.
|
| Unless you're going to create commercial grade simulators,
| debuggers, synthesis tools etc. then users are going to be
| debugging SV.
|
| My day job is debugging generated SV and even though it isn't
| nearly as bad as the code smallpipe posted it still suuucks.
| It costs me a lot of time reverse engineering it.
|
| If anything is going to replace SV (and I really hope it
| does) it really really needs to focus on producing clean
| debuggable output. That includes things like using
| interfaces, structs and so on.
| js8 wrote:
| 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.
| kayson wrote:
| 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.
| IshKebab wrote:
| This looks much more likely to succeed tbh. Similar enough to
| SV that you can piggy back off the features that you're likely
| never going to replicate (SVA, functional coverage, multiple
| clock domains, etc. etc.) but also fixes the footguns.
| raluk wrote:
| 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
| Lramseyer wrote:
| 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."
| etep wrote:
| Surfer deserves to hit the front page also. Much better than
| gtk wave. Nice work Spade & Surfer!
| VonTum wrote:
| > 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."
|
| Exactly! It's astounding how often the documentation of some
| vendor component has in the documentation: "data_out is valid 2
| cycles after read_enable is asserted", and NOTHING in the
| actual module definition makes a mention of this. There's so
| much dumb and error-prone mental arithmetic designers have to
| do to synchronize such latencies.
|
| Spade does make a nod at this, with its pipelining notation.
| The issue I have with it is that it takes a too simplistic
| approach to said port timings. In a Spade pipeline you separate
| "pipeline stages" by adding a "reg;" statement on its own line.
| (It's an approach shared by another language called TL-
| Verilog.). A consequence of this style is that all inputs
| arrive at the sime time (say cycle 0), and all results are
| produced at a second time (say cycle 5). This is irrespective
| of if an input is actually only ever needed in a final addition
| in cycle 4. It'll insert the 4 extra registers regardless.
| Likewise, it leads to unnatural expression of subpipelines,
| where syntactically you can already see a value, but can only
| _access_ it 3 pipeline stages later.
|
| With SUS, I have a solution to this: Latency Counting. (Intro
| here: https://m.youtube.com/watch?v=jJvtZvcimyM&t=937). A
| similar philosophy is also followed by Filament, though they go
| a step further with adding validity intervals too.
|
| The gist of Latency Counting is that Instead of explicitly
| marking and naming "Pipeline stages", you annotate a statement
| to say that it "takes one cycle", and through exploring the
| dependency graph between your wires, it assigns a unique
| "absolute latency" to every wire, and places registers
| accordingly. (And now it can even infer submodule parameters
| based on this pipelining, in a bid to do HLS-style design in an
| RTL language).
| sitkack wrote:
| It needs dependent types to encode when signals are valid.
|
| I have looked at TL-Verilog, I love the language, I am on the
| fence with the syntax, which arguably, is nearly an
| inconsequential nit given how far languages and tools need to
| progress.
|
| https://github.com/TL-X-org/TL-V_Projects
|
| Wow, a TL-Verilog video!
| https://www.youtube.com/watch?v=o2epusH-fXI
| thezoq2 wrote:
| Thanks for the kind words!
|
| > 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."
|
| That's an excellent quote, I might steal it :D In general, I
| think good abstractions are the ones that make important
| details explicit rather than ones that hide "uninteresting"
| details.
| polalavik wrote:
| If a new HDL language doesn't have simulation capabilities baked
| in its next to useless. See: hardcaml and amaranth.
|
| 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.
| thezoq2 wrote:
| Spade author here!
|
| That is a good point, sadly I'm not experienced enough with
| verification to know what is actually needed for verification
| from a language design perspective which is why I just offload
| to cocotb. There are a few interesting HDLs that do focus more
| on verification, ReWire, PDVL, Silver Oak, and Koika are the
| ones I know about if you're interested in looking into them
|
| Also, nitpick but amaranth does have its own simulator as far
| as I know
| IshKebab wrote:
| This is another good reason to generate clean SV with
| meaningful stable signal names etc. There's absolutely no way
| you are going to replace e.g. SVA and formal verification
| tools.
| polalavik wrote:
| Sorry hardcaml and amaranth were my examples of things with
| baked in sim features.
|
| Also great work with spade. I love to hate, but the hardware
| industry needs folks like you pushing it forward. I just fear
| most people are making toys or focusing a ton of effort on
| the wrong issues (how to write HDL in a different way)
| instead of solving industry issues like verification,
| wrangling hand written modules with enormous I/O, stitching
| IP together, targeting real FPGAs, auto generating memory
| maps, etc. some of that is a tough solve because it's
| proprietary.
|
| [1] https://github.com/janestreet/hardcaml/blob/master/docs/w
| ave...
| VonTum wrote:
| I've been wondering how long it'd take for it to show up here. I
| can attest to Frans (the lead dev) being a talented and highly
| active developer. It's frankly quite intimidating to be a
| competitor of his. (https://sus.rocks)
|
| Hopefully one day we'll break open the hardware design ecosystem.
| Verilog & VHDL still being de-facto industry standard is
| pathetic. And IMO the only reason is the white-knuckle grip Intel
| (Altera again?) and Xilinx have over what languages are accepted
| by their respective proprietary design tools.
___________________________________________________________________
(page generated 2025-05-12 23:01 UTC)