3 ms·
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
by ajross 1y ago
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.
- leonheld 1y ago> 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?
- ajross 1y agoYou 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.
- nsteel 1y agoI 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.
- oasisaimlessly 1y agoSee 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/ https://m-labs.hk/gateware/migen/
- duped 1y agoI 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.
- adwn 1y ago> 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.