I wrote and verified IP and I worked at the SoC integration level. I would say hardware engineers realize the tools suck but this stuff is targeting issues I don't care about.
The bugs are not due to language generally. If software guys want to write a new language for HW engineers, they need to ask HW engineers what the issues are rather then go off on a tangent.
As it is they don't even know what the workflow is like and where the real pain lies. They are just writing tools for themselves. The problem is their applications are not commercial.
New commercial tools are targeted at the verification side: UVM etc. This is where most of the time is consumed. This is where the software guys could offer some actual solutions because UVM is object oriented all over the place. Us HW guys are idiots and don't understand the performance costs of making all the object hierarchies and using reflection everywhere. When simulations are so long and on such large designs, the computing resources needed becomes huge.
That's like saying that buffer overflows are not due to how strings are represented in C. Yes a bug is the programmer's fault, but languages can make it harder to have bugs in the first place (for instance you can't have buffer overflows in any other higher level language than C).
In the case of the hardware industry, we see a language with a weak type system (Verilog). So the "solution" is to use lint tools to check that your design is properly typed. Similarly, nothing in VHDL/Verilog prevents you from accidentally creating latches, or crossing domains badly, or many other small bugs. So again, the "solution" is to do extensive verification. That's the Haskell VS Python debate: you can either make it impossible to have a certain class of bugs (and detect them very early), or you can just write a lot of tests (which, in the case of hardware, take forever to run).
The same logic extends at a higher level. You can have a language that models common patterns (like a synchronous loop, a "ready before valid" port) so you can reduce the amount of verification needed because you don't need to always re-verify everything. One could even argue that having such higher-level mechanisms would also make static verification easier, since you might reason in terms of transactions rather than updates to registers.
Latches are caught by the synthesis tools generally. Designers usually run a unconstrained synthesis as a matter of course to determine whether they have written junk.
As for the other bugs, I look forward to this new paradigm of spotting them early without verification effort.
Reasoning about transactions is already how verification works. It is transaction based. UVM is a library of SystemVerilog classes aimed at abstracting the verification to higher levels.
The bugs are not due to language generally. If software guys want to write a new language for HW engineers, they need to ask HW engineers what the issues are rather then go off on a tangent.
As it is they don't even know what the workflow is like and where the real pain lies. They are just writing tools for themselves. The problem is their applications are not commercial.
New commercial tools are targeted at the verification side: UVM etc. This is where most of the time is consumed. This is where the software guys could offer some actual solutions because UVM is object oriented all over the place. Us HW guys are idiots and don't understand the performance costs of making all the object hierarchies and using reflection everywhere. When simulations are so long and on such large designs, the computing resources needed becomes huge.