Spade, a hardware description language inspired by modern software languages

53 points by kaycebasques

thezoq2

👋 Spade author here, fun to see my little language get spread around!

0x2ba22e11

Yes, the mascot is cute. Well done.

wucke13

Got a Cologne Chip Gate Mate a while back and started tinkering with it. 30 minutes in, I had my first blinky LED binary counter up and running. Another 40 minutes later I had the same, but implemented in Spade, up and running. Mind you, this is not an endorsement of my FPGA skillz, I hadn’t touched VHDL/Verilog in half a decade at that point.

Compare that to the 2.5h hours it takes to install a recent AMD Xilinx Vivado on a fast computer, it is astonishing to me how good the developer UX in the Open Source FPGA world got. I hope Spade will become industry relevant some time soon (that is, soon in this context means in the next decade, I guess)!

thezoq2

Yeah, the commercial tools are incredibly sluggish :D

It would have been even better if we had gate mate support in swim, then just swim install tools, swim init --board gatemate and swim upload would have been enough :)

khm

I’m deeply perplexed by how this is supposed to work. Is it supposed to be a more or less direct “contender” to the same niche that VHDL/Verilog fills, or..?

thezoq2

Yep, that’s the idea VHDL and Verilog to me feel very antiquated so I wanted to build something more modern.

We also try to raise the abstraction level a little bit with pipelines in the language, ready valid interfaces being modelled in the type system etc. though without sacrificing low level performance. Broadly like moving from C to Rust or C++
wucke13

On a technical level, Spade is a transpiler IIUC, so Spade lang compiles to Verilog. So all the vendor tooling for synthesis and place’n route still can be used. A bit like Typescript and JavaScript, if you will.
- thezoq2
  
  Yeah, that’s a good point, for compiling to any hardware, emitting Verilog or VHDL is pretty much the only option at the moment since that’s the lowest level that you can reliably feed to tools. I also wouldn’t want to emit anything much lower level since that’d soon devolve into having to do synthesis
  
  Offtopic, but a fellow HDL developer has a pretty good case against the use of “transpiler” https://rachit.pl/post/transpiler/, even if in this case it is quite clear what the distinction is
animatronic

It is more of a Spinal/Chisel/Bluespec competitor, folks using Verilog are the least likely to use this.

david_chisnall

This looks neat. I like the pipeline structure. I’d love to see an example of a superscalar design, with different-length pipelines. It wasn’t really clear to me how backpressure works in this kind of design from skimming the book. I can see lower-level features for building these things but they seem to be quite different from the high-level abstractions and I’d worry that I’d hit a cliff and have to completely rewrite some things.

thezoq2

That’s absolutely a problem I want to address eventually. The language has rudimentary support for backpressure and stalling of pipelines, but I realized too late that doing that properly requires being able to stall sub-pipelines, and to do that properly, I need to finalize my work on clock/reset/enable domains
- david_chisnall
  I spent some time last week writing some SystemVerilog, after mostly using BlueSpec for the few bits of hardware work I did. And, wow, it’s terrible.
  
  A few things I really miss from BlueSpec:
  
  Proper types. Yes, a 32-bit integer is a set of bits, but that requires explicit casts to extract bits from it. Otherwise, it’s a signed or unsigned fixed-width integer type with operations defined accordingly.
  
  A sane abstraction for writing values. BlueSpec’s guarded atomic actions make it a compile failure if two things write to the same FIFO / wire / register in the same cycle unless there’s explicit muxing to determine who wins. In SystemVerilog, two things write to the same output for a module and something bad happens with no warnings.
  
  FIFOs. The BlueSpec FIFO is the best thing about the library. Guarded atomic actions mean that the compiler can determine if a FIFO is never written (it’s elided), written and read once every cycle (it becomes a wire), written every cycle and read sometimes (it becomes one or more registers and extra control wires, writes are backpressured), or written sometimes and read every cycle (becomes a wire with the read actions guarded on validity), or read some cycles and written other cycles (becomes one or more registers, with control signals to backpressure on send and block on read).
  
  Registers that hold maybe types, so you can query whether the value is valid trivially (yes, it’s just another bit. It’s so useful!).
  
  BlueSpec’s FIFOs let you write things that compile down to wires if you get everything right and read and write in every cycle, but which gracefully handle the cases where you don’t. This is also really nice when prototyping because you can have some slack.
  
  I think Spade seems better for repipelining (this can be a big painful with guarded atomic actions), but I worry a bit that I didn’t really understand what the core abstractions were.