[ancharm]

I know it's not new stuff, go look at Bluespec and their open-source HDL.

For most hardware designers though, it is new. Most hardware designers are EEs and not CS people. I know many designers that do not even want to learn a programming language like python which has a relatively easy to read syntax. ML/Functional Programming languages require a completely different mindset, just like hardware designing does if you come from programming languages.

I think the world is ripe for a new HDL. But the right foundations need to be there. It needs first class support with existing HDLs (VHDL, Verilog/SV). It needs to integrate with all the existing EDA tools in mixed language environments, and be easy to debug. Debugging is a huge problem in the "new HDL" space right now. Go look at Chisel. Google used it to design some of if not all of their TPU, but their Verif engineers had a really difficult time with the debug because it compiled to verilog, and then was difficult to reason about.

I have so many thoughts on this space and I want to make it better. It would be an absolute dream to develop a new HDL that enabled Hardware designers and Verif engineers to have all the superpowers that SWEs have in today's world. Being both proficient in various programming languages and Verilog/SV/UVM/etc, its so wild to see how big of a gap there is in productivity tools. Essentially SWEs have all the good stuff.

[Rochus]

> I have so many thoughts on this space and I want to make it better

Have you written them down somewhere? Would be interested. Are you a HW designer?

> It would be an absolute dream to develop a new HDL that enabled Hardware designers and Verif engineers to have all the superpowers that SWEs have in today's world

Wasn't that the intention of SystemVerilog?

[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.

[centimeter]

Yes, and hardware designers that refuse to upgrade from horrendous HDLs like Verilog are going to get BTFO over the next few decades by upstarts using stuff like clash, which lets you debug using SWE strategies before doing anything on hardware. Basically anything new is going to BTFO verilog really - clash, chisel, nmigen.

[ancharm]

> "HDLs like Verilog are going to get BTFO over the next few decades by upstarts using stuff like clash.."

Like I've been saying, I want a new HDL. The hardware world needs it. I don't want to get into the Moore's Law debate, but there are tons of efficiencies in TTM to be had with a newer, more modern Digital Design workflow, starting with a new foundational HDL.

WRT to getting BTFO... I don't know. The entire semi industry pushes back on this. Why? Because if you fuck up a chip in 7nm you've wasted millions of dollars not just on fab, but R&D. The hardware world cannot afford to 'move fast and break things' like software can. You have a multi-level problem here if you want a new HDL. You need the mega EDA co's to have first-class support, and then you need the massive chip co's to demand it. Why would Intel change to a new HDL when they have generations of experience in VHDL/Verilog langs, internal tools built to support teams (millions of dollars worth), hardware designers who are productive in these langs, etc. The EDA co's build tools the big dawgs want. The amount of risk involved to change HDLs is massive. Let alone to a new language without a formal spec. That's why it has to be piecewise. If we see a new HDL succeed, it will be because of how it interops with existing solutions. It will have a spec. It will be easy to transition from Verilog, or drop down/into Verilog where needed etc.

Upstarts in Semi are super different than upstarts in software. You don't just get a new grad designing a new CPU/AI-Coprocessor/etc and making millions from it like you do a new grad designing a widget that solves a human product problem in software. The core synthesizable side of SV is actually quite intuitive and good. I think all the bloat of trying to add OO ideas to it was the biggest mistake. Basically people tried piggybacking off of the success of Java in the 90s and thought that would be a good idea. If you've seen a massive UVM/SV code repo, you'd understand how much of a disaster it is.

[chas]

It turns out that CS folks with distributed systems and functional programming experience can be super productive hardware designers because distributed systems have very similar design-level tradeoffs as ASIC design e.g. how many copies of this processing-element do we use?, what's the correct ratio between storage and compute?. They both have pretty rough verification and correctness related to not being able to instantaneously-sharing state, so things like clock-domain-crossing aren't that foreign to the distributed systems folks.

You don't have a notion of clock cycles, making timing, or fan-out load in distributed systems, so if you are going to try this you definitely need some extremely experienced digital logic designers and chip architects around to keep everyone on the rails, but in turn the CS folks are really good at producing useful abstractions that make architecture exploration easy while maintaining correctness.

TL;DR: I've found it easier to teach folks that know Haskell and distributed systems design about hardware constraints than to teach RTL designers about functional abstractions and been really productive with a mix of both groups.