ancharm

Will this also be available on the web via WASM compilation, in addition as a desktop app?

Is the scheduling / bare metal software open source through OneAPI? Can a link be posted showing it if so?

What ASIC/semi start up that you know of is developing everything in house? That is absurdly complex and hundreds of millions of dollars...

Is there any video of this posted somewhere?

Probably worthwhile to link this as well -- Intel just demoed 224G SerDes on one of their FPGA platforms

https://www.intel.com/content/www/us/en/products/docs/progra...

Yep, and the highest data rates are only really possible on the best processes (12nm, 7nm, 5nm) , which is a fun chunk of change to spend for a tape out.

Think of this product as infrastructure-as-code for the Silicon/ASIC workflow. It's a pythonic API for the ASIC/VLSI workflow as opposed to the traditional spaghetti script TCL nightmare that holds together modern ASIC flows.

How long before someone just goes into the Postgres source code and creates true native support for GraphQL

Is there a blog or something where someone is going through the dump and summarizing?

Though they are essentially given for free, stitching everything together is still a lot of work. Getting the tools as an individual is not really possible (with the exception of Mentor sometimes..) the open source software ecosystem needed around every tool is non-existent, which means that each company ends up recreating their own scripts and flows each time you want to design a new IP.

I've kind of always felt that synthesizable Verilog/SystemVerilog was good, but the verification side was just too complex and had too much bloat. Testing hardware with Python (like Cocotb) feels more on the right track as a high level UI.

But easily pluggable APIs for foreign SW languages are key as well. Hardware software co-design is only becoming more important.

Higher level hardware design languages that better interop with software are desperately needed, but I don't know if C/C++ is the right UI/abstraction.

Whats the % chance they start to lay the initial ideas down for a decentralized music ecosystem?

I want my private keys stored on my iPhone / Apple Watch, in Secure Enclave memory, with two-factor biometric authentication (FaceID and Fingerprint). No more passwords.

Awesome. I guess two comments on learn-anything -- is there an easy way for external users to add something? I get it's open source but when you search for something, maybe a "suggest resource" would speed up curation of resources via human indexing.

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.

Have you ever considered open sourcing this and having it be a wikipedia of learning map?

He was an important mind in our community. RIP.

Does bitcoin moving to a proof-of-stake algorithm change your opinion?

Videos for this course?

That or Achronix

This is awesome but also means that latency becomes the key metric in internet / service providers.

How long until we start seeing the edge become small micro servers that live right beside metro network access points?

Another death by iPhone

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.

I love the idea of LLHD. Also LNAST. There are some great ideas here.

https://github.com/masc-ucsc/livehd

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.

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

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.

I hate to rag on new stuff, especially in the HDL space where I think it's desperately needed, but the syntax of this language is so foreign that I think it's extremely unlikely you really get a large amount of adoption. We can't even get Verilog 1995 people to switch to 2001, let along SystemVerilog.

This looks great.

Does anyone know if these presentations were recorded and videos will be posted?