[leonheld]

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

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.

[nsteel]

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.

[oasisaimlessly]

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/