[ancharm]

Yeah I've been capturing these ideas over the last couple years. I probably have a stream of consiousness document like 30 pages long. I just haven't really had the time to organize it and start figuring out what the "API" would look like.

> Wasn't that the intention of SystemVerilog?

I believe it was, but it clearly didn't pan out. A few obvious reasons:

- the language has way too much bolted onto it, if you compare SV vs C++ or even Java, there are a mindboggling ~250 keywords. Nobody can memorize all of that. If you don't have unbelievable lint/code aid tools (which we don't...), how on earth is someone supposed to be productive? Its way too much complexity. C++ has something like 80ish? C# maybe 100ish? The fat needs to be trimmed.

- Verif engineers and designers work differently, so why does a verif engineer use the same language as a designer? They probably shouldn't just like its a no-no to have a designer verify their own block. Design and Verification need to have very clear cut lines from a language standpoint, and in SV they really dont

- I think people made the wrong decision trying to Bolt on all these OO features inspired by the success of Java and OOP in the early 2000s. HDL design should be more functional than OO. And it should definitely be seperated from a verif lang.

I have so many more thoughts, everything from language syntax, to GUIs, to code analysis, etc. I should probably share it somewhere. Maybe I should just build it. I don't know.

[Rochus]

Agree. SV is even harder to parse and validate than C++ which is quite an achievement. I think they also made a wrong decision by replacing the Verilog by the SV standard.

But there are still a lot of useful parts in SV. I thought of creating a kind of "Verilog 20" which just incorporates the useful synthesizable features from SV including parts of SVA and interfaces. I would even consider to leave out parts of Verilog which are not synthesizable and use a different language for verification altogether (e.g. C++ or Python as e.g. with Cocotb).

I recently came accross Wirth's Lola and even built an IDE for it (https://github.com/rochus-keller/LolaCreator), but its practicality and usefulness is still to be demonstrated and the compiler has issues.

[ancharm]

I haven't heard of this one. Will take a look. I've been cataloguing everything I've found HDL wise and maybe one day I'll put out a potential spec API for what "the best parts" could look like. Similar to the Rust "inspired by" parts.

I completely agree with the Verilog20 idea. That's the way forward 100%.

Cocotb is awesome in my brief usage so far. The thing that remains to be seen though is performance benchmarking. It would be great to compare the sim runs of two identical tests, one in UVM and one in Cocotb. I highly doubt it could match the performance of a well written UVM test, and this becomes an issue as your SOC gets bigger.

[Rochus]

> I haven't heard of this one

Here is the specification: https://inf.ethz.ch/personal/wirth/Lola/index.html

I don't yet have representative experimental data; the language is designed for the synthesis of synchronous FPGA designs and thus avoids some of the issues Verilog and other HDL suffer from. But it's too early for me to give a recommendation.

> The thing that remains to be seen though is performance benchmarking

Agree. I often use Verilator and I also experiment with LuaJIT (see https://github.com/rochus-keller/LjTools) which is one of the fastest VM available; it intend to use it for HW simulation and debugging too.