Oxide at Home: Propolis Says Hello

Do you really need proprietary EDA tools to get started on designing custom chips? Higher-level design languages like Chisel are showing a lot of potential right now, with full CPU cores being designed entirely in such languages. Of course EDA will be needed once the high-level design has to be ported to any specific hardware-fabbing process, but that step should still be relatively simple since most potential defects in the high-level design will have been shaken out by then.

> Do you really need proprietary EDA tools to get started on designing custom chips?

Yes, actually, you do.

The "interesting" bits in chip design aren't the digital parts--the interesting bits are all analog.

A RISC core is an undergraduate exercise in digital design and synthesis in any HDL--even just straight Verilog or VHDL. It's a boring exercise for anyone with a bit of industry experience as we have infinite and cheap digital transistors. (This is part of the reason I regard RISC-V as a bit interesting but not that exciting. It's fine, but the "RISC" part isn't where we needed innovation and standardization--we needed that in the peripherals.)

However, the interfaces are where things break down. Most communication is now wireless (WiFi, BLE, NB-IoT) and that's all RF (radio frequency) analog. Interfacing generally requires analog to digital systems (ADCs and DACs) and those are, obviously, analog. Even high-speed serial stuff requires signal integrity and termination systems--all of that requires parasitic extraction for modeling--yet more analog. And MEMS are even worse as they require mechanical modeling inside your analog simulation.

If your system needs to run on a coin cell battery, that's genuinely low power and you are optimizing even the digital bits in the analog domain in order to cut your energy consumption. This means that nominally "digital" blocks like clocks and clock trees now become tradeoffs in the analog space. How does your debugging unit work when the chip is in sleep?--most vendors just punt and turn the chip completely on when debugging but that screws up your ability to take power measurements. And many of your purely digital blocks now have "power on/power off" behavior that you need to model when your chip switches from active to sleep to hibernate.

All this is why I roll my eyes every time some group implements "design initiatives" for "digital" VLSI design--"digital" VLSI is "mostly solved" and has been for years (what people behind these initiatives are really complaining about is that good VLSI designers are expensive--not that digital VLSI design is difficult). The key point is analog design (even and especially for high performance digital) with simulation modeling along with parasitic extraction being the blockers. Until one of these "design initiatives" attacks the analog parasitic extraction and modeling, they're just hot air. (Of course, you can turn that statement around and say that someone attacking analog parasitic extraction means they are VERY serious and VERY interesting.)

They've been doing Twitter Spaces for several months now, with recordings and show notes here: https://github.com/oxidecomputer/twitter-spaces Disclosure: I was the main speaker on one of their spaces.

Where does this leave companies that would like to take advantage of fully integrated software and hardware (yes, intentionally referring to your old project at Sun), but don't need a full rack's worth of computing power (and maybe never will), and don't have the in-house skills to roll their own? Or do you think that what you're selling really only has significant benefits at a large scale?

This article is about technical details of the product that aren't user-facing.

The business is fairly straightforward: we sell computers, a rack at a time. You as a customer can buy a rack, and put it in your data center. The rack offers an in-browser management console, built on top of an API you can use too. You use these tools to set up virtual machines. You can then use those VMs however you want. You get the cloud deployment model but with the "I buy the servers" ownership model.

There's a few different advantages depending on how you want to look at it.

Starting from a rack as the smallest unit rather than 1U brings a lot of advantages, but there aren't really vendors currently selling these sorts of things, instead "the hyperscalers" have internal teams building stuff like this. There are a lot of organizations who want hyperscale style servers but aren't going to start a division to begin making them themselves.

Another advantage is that everything is designed to work with the rest of it: you (or the OEM you're buying from) are not cobbling together a bunch of hardware, firmware, and software solutions from disparate vendors and hoping the whole thing works. Think "Apple," or "Sun," rather than "IBM PC Compatible." This is easier for users, as well as allows us to build systems we believe are more reliable.

There's also smaller things, like "as much as possible everything is open source/free software," which matters to some folks (and allows for interesting things like the above blog post to happen!) and is less important to others.