Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Spade Hardware Description Language

spade-lang.org

Post reply on HN
Print view View original

11–20 of 64 posts

Re: Spade Hardware Description Language

#11

Post by ajross »

leonheld wrote: post #6
ajross wrote: post #2

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 ad…

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

Re: Spade Hardware Description Language

#12

Post by oasisaimlessly »

leonheld wrote: post #6
ajross wrote: post #2

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 ad…

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

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/

Re: Spade Hardware Description Language

#13

Post by wirybeige »

tails4e wrote: post #9
Philpax wrote: post #5

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

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.

Re: Spade Hardware Description Language

#15

Post by smallpipe »

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;

Re: Spade Hardware Description Language

#17

Post by alain94040 »

smallpipe wrote: post #15

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;

Fair, but it's just a tooling issue. You don't debug your Verilog anymore at the gate-level, do you?

Re: Spade Hardware Description Language

#18

Post by grquantum »

Symmetry wrote: post #7

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.

Re: Spade Hardware Description Language

#19

Post by adwn »

alain94040 wrote: post #17
smallpipe wrote: post #15

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;

Fair, but it's just a tooling issue. You don't debug your Verilog anymore at the gate-level, do you?

> just a tooling issue

The word "just" is carrying the weight of the world on its shoulders…

Re: Spade Hardware Description Language

#20

Post by smallpipe »

alain94040 wrote: post #17
smallpipe wrote: post #15

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;

Fair, but it's just a tooling issue. You don't debug your Verilog anymore at the gate-level, do you?

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.
Post reply on HN