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

31–40 of 64 posts

Re: Spade Hardware Description Language

#31

Post by duped »

adwn wrote: post #30
duped wrote: post #28

Earlier quoted context omitted.

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…

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

Re: Spade Hardware Description Language

#32

Post by ajross »

duped wrote: post #28
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…

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…

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

Re: Spade Hardware Description Language

#33

Post by Lramseyer »

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

Re: Spade Hardware Description Language

#34

Post by polalavik »

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.

Re: Spade Hardware Description Language

#35

Post by etep »

Lramseyer wrote: post #33

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

Surfer deserves to hit the front page also. Much better than gtk wave. Nice work Spade & Surfer!

Re: Spade Hardware Description Language

#36

Post by monocasa »

duped wrote: post #31
adwn wrote: post #30

Earlier quoted context omitted.

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

Re: Spade Hardware Description Language

#37

Post by adwn »

duped wrote: post #31
adwn wrote: post #30

Earlier quoted context omitted.

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

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.

Re: Spade Hardware Description Language

#38

Post by ajross »

monocasa wrote: post #36
duped wrote: post #31

Earlier quoted context omitted.

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.

Re: Spade Hardware Description Language

#39

Post by VonTum »

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.

Re: Spade Hardware Description Language

#40

Post by thezoq2 »

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;

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

Post reply on HN