Will this also be available on the web via WASM compilation, in addition as a desktop app?
34 karma · joined November 15, 2019
https://www.intel.com/content/www/us/en/products/docs/progra...
But easily pluggable APIs for foreign SW languages are key as well. Hardware software co-design is only becoming more important.
The other big thing that would be helpful is a "videos" node where you could link to videos on the subject. A lot of people that I talk to struggle learning completely new topics just by reading. Some of the feedback I hear is that a few videos goes a long way to introducing something new, so a videos node could be useful in the overall graph.
How long until we start seeing the edge become small micro servers that live right beside metro network access points?
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.
> 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.
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.
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.