Spade Hardware Description Language

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

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

> 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.

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).

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

That said, I'm all for better languages, of they really are better and as expressive

> 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 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?

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!

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'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.

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