Hacker News Reader

Comment by ajross | Hacker News Reader

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.

View on HN

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/

Reply on news.ycombinator.com