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.
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."
> 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.
> 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).
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.
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:
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
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.
Having clean SV will enable Spade to be used incrementally inside of a SV codebase. Var names should make it through, comments, asserts, etc. Treat it like a CASE tool.
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.
FPGA toolchains are infamous for one of the worst and cursed toolchains in the world. Where writing tcl scripts to imperatively connects blocks together in a block diagram that will integrate all the verilog code is not just normal, but encouraged. Because their internal block diagram description file is git hostile
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.
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 Kôika 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
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.
> wrangling hand written modules with enormous I/O, stitching IP together
This is something where I'm confident a good type system can help significantly, part of the problem imo is that the module interfaces are often communicated with prefixes on variable names. The Spade type system bundles them together as one interface, and with methods on that interface you can start to transform things in a predictable way
Generating memory maps is also an obvious problem to solve with a language that attaches more semantics to things. I haven't looked into it with Spade, but I believe the Clash people are working on something there
What you need to do is have first party formal verification/design by contract support. Instead of the old school test bench approach, you should prioritize tools like fuzzing and model checking to find counter examples (e.g. bugs).
If there is something worth checking, but its only possible to check it in simulation (think UBSan), then you should add it anyway, just so that it can get triggered by a counterexample. (Think debug only signals/wires/record fields/inputs/outputs/components) You don't want people to write lengthy exhaustive tests or stare at waveforms all day.
Note that the point of formal verification here isn't to be uptight about writing perfect software in a vacuum. It's in fact the opposite. It's about being lazy and getting away with it. If you fuzz Rust code merely to make sure that you're not triggering panics, you've already made a huge improvement in software correctness, even though you haven't defined any application specific contracts yet!
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.
At my shop verification to design time is like 10/1 or more. RTL is generated via Perl scripts. Nobody is coding directly at RTL level here. It's just for debugging.
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.
Spade author here :) Coming from a functional programming adjacent background, the VHDL type system leaves a lot to be desired. Not supporting types with generics means you can't encode things like a genral purpose ready/valid stream. When you have those, you can start using methods to compose those streams which becomes even more powerful when you add higher order functions which allow you to transform the content of the stream without worrying about the stream details.
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.
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.
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.
> 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?
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.
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.
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.
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!
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.
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.
As the author of Veryl and an ASIC frontend engineer, I aim to enable smooth transitions from existing SystemVerilog projects, making it immediately applicable to ASIC projects. (In fact, it’s already being applied to an ASIC currently under design.) I see languages like Spade and SUS as HDLs for a slightly more future-oriented.
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.
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
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'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.
Hehe thanks for the kind words! I think once Verilog and VHDL are de-throned there will be plenty of room for more than one new HDL :) Especially if we can figure out interoperability between languages
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.
I don't get what you're talking about. If I had to describe Spade it's just VHDL, but this time with Rust syntax instead of Pascal. The pipeline syntax is just syntax sugar and nowhere near full blown high level synthesis.
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
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.
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
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."
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.
> 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).
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
Surfer deserves to hit the front page also. Much better than gtk wave. Nice work Spade & Surfer!
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:
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
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.
Having clean SV will enable Spade to be used incrementally inside of a SV codebase. Var names should make it through, comments, asserts, etc. Treat it like a CASE tool.
https://en.wikipedia.org/wiki/Computer-aided_software_engine...
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...
> it's just a tooling issue
FPGA toolchains are infamous for one of the worst and cursed toolchains in the world. Where writing tcl scripts to imperatively connects blocks together in a block diagram that will integrate all the verilog code is not just normal, but encouraged. Because their internal block diagram description file is git hostile
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.
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 Kôika 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
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/wave...
Ah right, I didn't know hardcaml has a simulator
> wrangling hand written modules with enormous I/O, stitching IP together
This is something where I'm confident a good type system can help significantly, part of the problem imo is that the module interfaces are often communicated with prefixes on variable names. The Spade type system bundles them together as one interface, and with methods on that interface you can start to transform things in a predictable way
Generating memory maps is also an obvious problem to solve with a language that attaches more semantics to things. I haven't looked into it with Spade, but I believe the Clash people are working on something there
What you need to do is have first party formal verification/design by contract support. Instead of the old school test bench approach, you should prioritize tools like fuzzing and model checking to find counter examples (e.g. bugs).
If there is something worth checking, but its only possible to check it in simulation (think UBSan), then you should add it anyway, just so that it can get triggered by a counterexample. (Think debug only signals/wires/record fields/inputs/outputs/components) You don't want people to write lengthy exhaustive tests or stare at waveforms all day.
Note that the point of formal verification here isn't to be uptight about writing perfect software in a vacuum. It's in fact the opposite. It's about being lazy and getting away with it. If you fuzz Rust code merely to make sure that you're not triggering panics, you've already made a huge improvement in software correctness, even though you haven't defined any application specific contracts yet!
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.
At my shop verification to design time is like 10/1 or more. RTL is generated via Perl scripts. Nobody is coding directly at RTL level here. It's just for debugging.
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
It's better than Verilog but it's still awful. If you thought C had footguns....
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.
Spade author here :) Coming from a functional programming adjacent background, the VHDL type system leaves a lot to be desired. Not supporting types with generics means you can't encode things like a genral purpose ready/valid stream. When you have those, you can start using methods to compose those streams which becomes even more powerful when you add higher order functions which allow you to transform the content of the stream without worrying about the stream details.
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.
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).
That's like saying that software languages are all DSLs, the domain being the description of von Neumann style software.
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.
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.
> 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.
> 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?
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.
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/
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
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!
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.
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.
As the author of Veryl and an ASIC frontend engineer, I aim to enable smooth transitions from existing SystemVerilog projects, making it immediately applicable to ASIC projects. (In fact, it’s already being applied to an ASIC currently under design.) I see languages like Spade and SUS as HDLs for a slightly more future-oriented.
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.
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
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
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
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'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.
Hehe thanks for the kind words! I think once Verilog and VHDL are de-throned there will be plenty of room for more than one new HDL :) Especially if we can figure out interoperability between languages
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.
I don't get what you're talking about. If I had to describe Spade it's just VHDL, but this time with Rust syntax instead of Pascal. The pipeline syntax is just syntax sugar and nowhere near full blown high level synthesis.
Where do you work that uses bluespec? Any open positions? Apologies for being forward.
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