These gate and metal pitch numbers don’t tell the whole story. In the end it’s logic gate density that counts.
And while decreasing the gate and metal pitch, also the logic gates have shrunk to be smaller (typically expressed by measuring the height of a gate in amount of metal tracks) from 9tracks down to 6tracks.
Changing the transistor from planar to fins, and now hopefully to ribbons with eventually stacked pmos and nmos are a big enabler.
That said, we’re still not hitting the ideal scaling numbers. We’re just doing somewhat better than what’s suggested by poly and metal pitch only.
This looks like a treasure trove on what it takes in terms of algorithms to enable tools like Cadence Innovus or Synopsys ICC. It’s not a user guide on how to use these tools, but rather a perk behind the curtain.
I’ve worked with Andrew, one of the authors on occasion in the past, and he and his team of students are among the best academic teams in the world on this topic.
I do think a lot of the secret sauce lives as trade secret with Cadence, Synopsys, Mentor… They see all the real problems in designs from all their customers in bleeding edge nodes like 3nm and beyond.
Thank you for the write up! Very enlightening to see how things went for you. I was on the fence recently whether to go for contractor work but ended up just switching companies in the end. In part because I didn’t know what to expect. Articles like these hwould have helped!
Thank you! Swig indeed can be a pain but having used it before I have become somewhat blind to it. But eg smart pointers are not easy to deal with well, I’ve found out recently…
I’ll have a look at pybind11. I’ve worked on Cython codebases too, which indeed allows to really nicely compile Python code and interact with c code. It does get weird when using eg pyqt and native qt…
This is a somewhat tangential question to the new release, but there might be folks here that can answer this question.
Having used swig to create Python bindings for C++ code over 10 years ago, what’s the recommended way to do this in 2023? There’s still swig, there’s Cython, pybind11 and a few others. I do know swig and how complicated it can get with footguns abound when things grow more complex.
Is Cython the way to go? How does it hold up to the alternatives? Google search gives many articles on the topic, but many typical SEO optimized low-value, and those that do show a bit of depth, focus on the basic mechanics, not really on things hold up for larger projects…
If you just need a nice print: fmtlib is a really nice c++23 style implementation without needing c++23 compiler support. Highly recommend it. It’s simple. It’s fast.
Not really knowing Vercel, I thought, based on the title, that it might have been a new GPU competitor (accelerator card) but it’s a startup accelerator.
While I have no need for its online functionality and the SAAS part of plotly, I really do like plotly python + cufflinks [1]. It lets you make interactive plots in html/js format. Which means you can save the notebook as html, and while people won't be able to rerun the code, they can still zoom in on graphs, hover to see annotations etc, which is a really nice way to share the outcome of your work in a more accessible way.
A lot of companies are indeed trying to build AI accelerator cards, but I would not necessarily call them ASICs in the narrow sense of the word, they are by necessity always quite programmable and flexible: NN workloads characteristics change much much faster than you can design and manufacture chips.
I would say they are more like GPUs or DSPs: programmable but optimised for a specific application domain, ML/AI workloads in this case. Sometimes people call this ASIPs: application specific instruction set processors. While maybe not a very commonly used term, it is technically more correct.
I had the exact same question. I do like this - it's nice and ambitious to build something like this from the ground up. Looking at the todo list though, they still have quite some work to get to parity with qemu...
The RISC-V isa is specifically designed to be nice and regular and easy to decode, and work with, which definitely shows here (also in the RTL code if you look at some of the well designed RISC-V cores)
Of course, bot x86 and Arm started like that as well - but after 20+ years of evolution, they have to drag along a lot of history. (and one never really takes things away from an ISA, you only add new features, and at best deprecate old ones).
That said, with the extensibility of the ISA in mind as a design principle, I do have good hopes, RISC-V will stand the test of time reasonable well in that sense...