EXACTLY. This lazy, backwards approach to tooling and workflow is why I jumped ship from logic design to software despite having an EE degree. VHDL/Verilog tooling is heinously terrible and everyone in the industry seems to be actively opposed to doing anything about it.

And your post is a great example of why I still get paid a lot of money come clean up when VLSI design goes wrong. :)

You think Verilog/VHDL and its simulations are the most important thing to a VLSI designer. That's a very narrow lens that clouds your thinking and is only applicable in the world of ASICs (that's not really true there, either, but I'm being generous).

Verilog/VHDL is of very little importance to chips with lots of analog or RF blocks. And, for extremely large chips, Verilog/VHDL generally takes a back seat to things like timing closure (and probably power consumption analysis) since once the Verilog/VHDL is written and tested, it's STATIC. As a VLSI designer, you have to close a block every 2 weeks and once it's closed it needs to stay that way or you'll never ship that chip. Repeat for 18+ months.

In that environment, version control is a nice way to validate that I haven't accidentally mangled something, but it doesn't have the same force as it does to software developers who have an infinitely malleable, continuously changing codebase. In fact, source control often gets in the way because non-text merging isn't arbitrarily resolvable. This means that you don't have nice distributed version control, you have the old-school Subversion-type of source control which locks files.

CI doesn't work in VLSI the way it does in software. Tests aren't infinitely fractal. Sometimes that job that creates the data for your static timing analyzer takes 5 hours and that's just how it goes and that's just the start of your pipeline. If you touch a header file in software, a long compile is a couple minutes. A couple of hours is an absurdly large software codebase. In VLSI design, a fundamental library component may take hours to check timing and generate timing values if your fab house generated new models. And that's just one of hundreds of library components. If your fab releases a new transistor model deck, it will take weeks for that to propagate through your design.

As for languages, Tcl is FINE. Creating scripting hooks is absurdly more complicated than you think (look at the grief KiCad has keeping Python supported--Blender had to create a whole GUI library from scratch to have Python hooks--Altium's Python scripting is still a horribly broken bodge). Tcl means that you get scripting hooks that work. I haven't seen any other language do it better yet. And the fact that you haven't been burned by floating point in VLSI and think Javascript, which only has floats, is a better language says something ...

Could things be better? Sure!

The fact that the pay is crap compared to FAANGs is the first problem. That's why most of us who know what we are doing have left VLSI design for software and can only be brought back with large chunks of cash.

As for Verilog/VHDL--the problem is that they are fit for purpose with hardware. If you want to displace them, you need to create something that takes into account the nature of simultaneity in hardware systems and makes it explicit. And, in modern programming languages, we've gone backward on that front--async makes simultaneity more implicit rather than less.

Scripting hooks could be better. Open source tools help because you have all the code.

Non-binary formats help because you can read and decode the dumb things. You can now also put everything into standard source control tooling.

Analog and RF are still the wild west in many ways. Computers are faster, but we really don't have fundamentally better ways of doing that kind of design than we did 20 years ago. It's a bit surprising that we don't have the equivalent of RF "standard cells".

There are, without doubt, luddites in VLSI. However, there are also a lot of greybeards with deep scars. Do not confuse the two even if they look very similar.

> Chips are much simpler than software and therefore way easier to verify

I've got a few friends who are waiting for your insights. One has a power grid that seems to oscillate at weird frequencies, another has a VCO that pulls on the 2nd full moon of the month, and another that can't run down 2 orders of magnitude in leakage current.

Do keep in mind that VLSI design is larger than the slice that you have been exposed to. Dismissing that will make it quite a lot harder to convince people of your positions.

You seem to be mostly talking about physical design, not logical design. But either way this is a depressingly familiar - and wrong - take.