To be clear, I'm specifically talking about Verilog simulators here. The EDA industry produces a wide range of tools for doing simulation, timing analysis, syn

To be clear, I'm specifically talking about Verilog simulators here. The EDA industry produces a wide range of tools for doing simulation, timing analysis, synthesis (converting a design to a gate-level netlist), DFT (automatic insertion of in-silicon testing facilities), layout, routing, analog design, and so on. You need a lot of tools to get a chip from your brain to a fab. A simulator for doing functional design is just one piece of the puzzle, but it's the one I'm most familiar with. I swear at one every day. To write a digital logic simulator is actually not very difficult at all. I've implemented a sketch of a simple one myself; I'm sure there are some folks here who, if they understood some digital design principles, could write something that would put my humble attempt to shame. But the industry doesn't want a simulator - it wants a Verilog simulator. That such a thing even exists is fundamentally wrong to my mind - a simulator should simulate the function described, not the implementation of said thing in a specific language. My own toy simulator was really a language-agnostic simulation library that you could just link to. Kind of like what SystemC is. But even polished up, I don't see there being any market for such a thing. Most designers don't think there's anything wrong with Verilog, because they don't know anything else, and most verification engineers are delighted to be using SystemVerilog because it makes us feel like we're on the cutting edge of technology for using a language that looks like a severely crippled Java, rather than one that looks like a regular crippled C. Many would not understand the previous sentence. Ironically, Verilog doesn't really lend itself to parallelization very well. The language was not designed with that in mind, if it was "designed" at all. So single-threaded seems the way to go, and that space is already too crowded. There are a couple of multi-threaded Verilog simulators out there, but they're not widely used, and I suspect the performance is not all that great, because of the semantics of the language. There have been attempts to push new languages. One, called Bluespec, is a Haskell front end to SystemVerilog, but doesn't seem to get much traction, as far as I can tell. And even if it did, the demographics of our industry would be a problem. I'm not sure how many of us could handily pick up Haskell. So it seems we're stuck with Verilog, and Verilog really is a problem. Hats off to Phil Moorby for coming up with a language that designers could write some code that looks a bit like C, and have it synthesize to a bunch of equivalent gates. It was a damn cool hack in the 1980s, when it came out, but it's really not a great language, and attempts to bolt on higher-level features on the side (SystemVerilog) just emphasize, in my mind, just how flawed the foundation really is. Our little industry is becoming more and more like software every year, but our demographics are such that we just don't have the pool of really brilliant people driving innovation. I believe I'm generally considered to be a pretty good verification engineer, but I think if I were thrown into a modern software development team, I'd probably struggle to keep up (at least at first). As for the "leaders" in my industry, I know many of them personally, and while they're certainly very intelligent, not one could be compared to luminaries of the software industry. So even amongst our leadership, I sense very little concern that something is seriously wrong. Some get darn right defensive about it. And worse, they seem to have a vested interest in maintaining the status quo. And now I has a sad.