“If you’re trying to create a company, it’s like baking a cake. You have to have all the ingredients in the right proportion.” – Elon Musk

“Our vision is to enable two guys in a garage to build a custom chip.” Thus spake Jack Kang, Vice President of SiFive, the 40-person startup making RISC-V chips. SiFive isn’t just another company pulling the RISC-V bandwagon. They’re trying to change the way we create SoCs. The au courant open-source processor design is just a means to that end.

Like Esperanto, SiFive is quite happy using RISC-V as the basis for its technology, but it isn’t particularly wedded to the architecture. What the company really wants to do is to simplify the arduous process of designing an application-specific SoC to the point where it becomes a non-issue. Instead of investing millions of dollars in EDA tools and engineering talent, and spending millions of hours (or so it seems) on circuit design and verification, SiFive wants to make it as simple as signing a check.

SiFive wants to become the Bisquick mix of SoCs.

(For readers unfamiliar with rudimentary baking skills, Bisquick is a premade powdered mix of flour, baking powder, sugar, and other constituents that takes the place of mixing one’s own ingredients. Just add water or milk to produce pancakes, biscuits, dumplings, pie crusts, breads, cakes, or just about anything else containing carbohydrates.)
Everybody wants their own custom or semi-custom device, but not everyone is equipped to design or build one, the company believes. Kang compares his customer base to programmers creating new smartphone apps. They’re good programmers, but they don’t know – or need to know – everything about how smartphones are put together. It’s enough to know what you want, not necessarily all the steps involved in making it happen. Today, anyone developing a custom chip has to be deeply knowledgeable about each step of design, testing, verification, and fabrication. SiFive is hoping to dumb that down a bit.

In the process, the company uses RISC-V as a configurable part of its IP portfolio. Again, the company doesn’t expect its customers to be microprocessor aficionados, or to have strong ideas about how to customize their CPU. That’s what SiFive is for. They can recommend the changes, if any, that will benefit the customer’s application, and then make those changes happen. Along the way, SiFive will surround the CPU with its in-house IP, produce a complete design, and fab it for you at TSMC. Just add water.

The company also produces a small range of standard, off-the-shelf parts, both as a way to demonstrate its prowess and to generate cashflow. Over time, SiFive intends to expand its product catalog to the point where chips, not services, become its major source of income.

But isn’t customizing a processor fraught with troubles? What happens to software compatibility? Where do you get tools? And how do you program a one-off CPU that’s unique to your company?

SiFive believes that these are all solved problems, and there is some truth to that. RISC-V is hardly the first or only user-customizable processor. ARC (now part of Synopsys) and Tensilica (now part of Cadence) both pioneered the idea in the 1990s. (Disclosure: I was ARC’s SVP of Marketing for a time.) Like SiFive, the ARC and Tensilica processor designs both had, and still have, an immutable core instruction-set architecture (ISA) that all chips must support. You can add to it all you want, but you can’t alter or remove the basic foundation ISA. It is this foundation that compilers, operating system ports, drivers, code libraries, and other software tools will target. Any instructions, registers, or processor state beyond that is gravy, but at least everyone can agree on the basics.

In RISC-V’s case, that core ISA contains about four dozen instructions. There are also optional but “approved” extensions to that foundation, such as a compressed ISA and various atomic instructions. A set of Java-acceleration extensions is also in the works. In other words, if you’re going to add any of those features to your RISC-V design, you’d better do them exactly as defined. No point in veering off into your own implementation of a compressed instruction set, because the software tools won’t support them. (Having said that, there’s no absolute prohibition against implementing the approved extensions in your own, incompatible, way. Just that it’s a stupid idea.) You can also add your own wildly creative features to the processor, and there’s a section of the opcode map set aside for just that purpose. Any such custom additions definitely will not be supported by the community tools. You’re on your own.

At ARC and Tensilica, the idea of custom extensions was met with a mixture of excitement and horror. The engineers were excited by the idea; their managers were horrified. Hardware developers saw customizable processors as a way to finally create that ideal CPU they’d been dreaming of, albeit with a lot of help. Project managers, however, saw nothing but a huge time-sink, as their engineering staff disappeared down the rabbit hole of processor customization, testing, and re-customization. Suddenly ARM, MIPS, and x86 started looking like much safer choices.

Few users of these customizable processors actually did add their own extensions. Most were intrigued by the idea but ultimately decided against it, for a number of reasons. (Those who did add their own extensions often saw enormous improvements in performance, however.) Some were concerned about breaking software compatibility with the rest of the community. Others were put off by the hardware/software work required. Others just didn’t see the point. They wanted a nice, simple “software engine” to run their embedded code and they didn’t much care whether their CPU was compatible with anything else.

These same problems/opportunities afflict RISC-V. Yes, it can be customized – or you can leave it alone. Yes, the baseline software tools support the core ISA – or you can enhance the tools in synchrony with your hardware extensions. Yes, you can make those extensions proprietary and protect your own “secret sauce” – or you can share them openly and even propose adding them to the official RISC-V definition, benefiting the entire community. It’s processor design by democratic process.

Ironically, many RISC-V users say that its base ISA is “pretty good,” meaning that it does well on benchmarks in its base configuration. That is to say, extensions aren’t necessary. If they were needed, or even significantly useful, they would’ve been part of the base definition.

It’s right there in the name: RISC-V. As in, “reduced instruction set.” The whole point behind any RISC architecture is simplicity; that you can do more with less. Superfluous instructions aren’t just unnecessary; they’re bad things. Gratuitous features just add hardware complexity and slow down the pipeline. John von Neumann posited that computers really need only three operations; anything beyond that is window-dressing. Today’s RISC machines aren’t quite that Spartan, but the point is still valid. RISC-V, like most other RISC architectures, is already supposed to be “just right,” neither too simple nor too complicated. Meddling with that would seem to defeat the purpose.

Still, SiFive is happy to let you experiment. Maybe you’ll discover that one custom feature that radically alters your system’s performance, or security, or power consumption. Or maybe you’re happy with the standard configuration. Either way, SiFive can make your SoC dreams come true. You can have your pancake and eat it, too.