It's definitely not a flash in the pan. It's already taking off. Many chip makers today are moving towards RV for their embedded controllers. Western Digital moved to RISC-V for their embedded controllers, Microchip has a SiFive CPU in their upcoming PolarFire FPGA, Nvidia moved to RV to replace their controllers, Chinese chip makers (e.g. Sipeed) are moving to RV instead of using ARM. Those are only the ones that we know about. Why would they not do it? There's really no good reason to choose a Cortex-M0 over some RV core as long as your customers (internal or external) are OK with it.

Do it matter that it's open source? Maybe not in terms of the CPU RTL being open source: you still need to do a lot of verification if you take your job seriously.

But the fact that the ISA was open source made a bunch of people interested enough to start tinkering with it and contributed to tools etc. I think the open source part was essential to get the RV thing moving.

Clang is the sound of the bell that tolls for Arm which isn't in as strong of a place as it used to be.

This is where part of the industry is going. There’s a high demand for cores with low licensing costs. Think of how many cores you have in your cell phone or laptop… dozens? Hundreds? (Honestly I have no idea.) The CPU and GPU are just a small part of it. A company that makes baseband processors, SSDs/HDDs, GPUs, network equipment, etc. needs a bunch of cores. The cores aren’t big or powerful, they don’t need to be. RISC-V means those cores have zero licensing costs for the ISA, and you get good toolchain support.

Yep. It's huge for large manufacturers, who get to save a bunch on licensing fees, and cut bom costs.

I think there are a lot of reasons RISC-V matters beyond just being open source. Working with MIPS tool chains is positively ghoulish, but they fill a niche.

If another architecture that is reasonably well designed, with reasonable core licensing fees, and had even decent tooling came out I think even that would have broken MIPS's back.

RISC-V hits the mark on all of those by either being open source or by using existing open source tooling effectively. There will be a transition period slowly moving to new hardware and learning barriers (but IMHO they're pretty low), but yes I'd say these kind of details are going to start to matter to the industry.

For one it would be really nice to be able to have a computer without a highly insecure and backdoorable management engine inside its CPU, basically all x86 computers sold since 2010.

How would you know that other than the assurances of the company that designed the chip? They could easily insert a few gates in the layout to subvert protections under the right conditions.

Same could be said for MIPS or RISC-V or indeed any piece of silicon.

As an embedded designer I know for a fact that CPUs used in embedded systems get so much scrutiny on their I/O messages all the way up the stack, it would be real good subversion to hide something like this and not be discovered in all use case scenarios. More likely is some sort of back door when you can access the hardware. Disclaimer I only work on the smallest MIPS and ARM embedded chips not those with full MMU's

With intel/AMD you have an assurance that your chip does contain a backdoor. I know this is probably difficult to do, but if we have access to published architecture specs/layouts, it might be easier to audit the chip design, even if doing so requires an x-ray microscope.

> it might be

This is the crux of the matter. While your statements are perfectly correct, their implications aren't. The assumption with open source is always that it's easily auditable and anyone can see the source (code, floorplan, etc.) which somehow implies the finished binary or chip that you have received is "safe". And herein lies the problem:

1) Assuming the source is really clean there's no guarantee the end product is;

2) Even if the source appears to be clean you have no guarantee it was actually (thoroughly) checked because "someone else" always checks.

The best example I can give you is OpenSSL, a library used by most of the internet and hundreds of billion+ $ companies (and hundreds of thousands of million+ $ ones). It took 2 years for anyone to notice it. And there are far more qualified SW engineers around that could have spotted the bug than there are HW engineers capable of finding the equivalent backdoor in a complex piece of silicon. So I am very skeptical that someone would notice one if one was there.

> ...but if we have access to published architecture specs/layouts, it might be easier to audit the chip design...

there are no "architecture specs/layouts" provided by RISC-V. it's an ISA. companies making RISC-V chips can put whatever they want in them, and don't have to document any of it.

True, but that's a lot better than your CPU running a non-stop Java webserver / rootkit.

When you know you have a backdoor you may take some steps, small as they may be, to protect yourself. For example in some cases you can remove the ME blob from the BIOS, effectively disabling the ME. You can choose to drop the product entirely. You definitely can't protect yourself from something you don't know exists.

Considering nation state actors have been consistently backdooring everything they can get their hands on (network equipment, CPUs, software, storage devices, you name it - and they've done it without the manufacturer ever knowing sometimes) the assumption that such an open source project would not have it and it's "a lot better" is based purely on wishful thinking.

It matters a lot. But there are different technologies that are converging that give it a better shot at success this time.

An Instruction Set Architecture (ISA), by itself, is really nothing more than a computer science exercise. However, a systems architecture which allows you to build complete systems, that is something entirely different.

For a new "system" to take hold, you need four things:

1) An ISA that can express useful computation in a way that the computation can be completed in a useful amount of time. Everyone loves to build a little Turing machine which can compute anything, but nobody really wants to run and editor that is running on a simple Turing processor because it isn't performant enough to be useful as an editor. So the combination is critical, good ISA, and an efficient way to process that ISA in hardware.

2) Tools to convert algorithms expressed in a common high level language, into a reasonably efficient use of the ISA. The gcc suite of tools has really helped here for a large number of ISAs. The majority of engineers express their algorithmic ideas in languages like C and C++ Etc. When they are compiled into code on a machine, the less space they use in RAM and FLASH and the faster they can run, increase the value of the ISA.

3) Resource and configuration management for the systems. Typically the operating system, Linux works well for this, it is software that is already built/available that means you only need to invest in the "new" algorithm code to get your idea running, not a bunch of basic system management code. For example, developing for Android, you just need to write your app, you don't need to create a new compiler, or write an OS, or device drivers, just your app. Successful systems have this "eco-system" already in place to support a wide variety of applications.

4) An effective I/O channel. If you want a good example of this, look at routers in the early 2000's. The Power architecture had a much better infrastructure for building many many lanes of I/O into the CPU and so folks like Cisco, Juniper, and others used systems based on that architecture for their routers and switches. The "software" could run on x86 architecture systems, but those systems were always challenged in creating hundreds of I/O endpoints in part due to the legacy of the IBM PC and Intel's "southbridge"/chipset strategy for holding on to additional margin (aka profits).

Open source hardware is getting to the point where all of these conditions are close to being met, and when they are, it really changes who gets to keep the 'value' that is derived from selling complete systems. It takes it away from the chip maker and moves it toward the system integrator. Perhaps it is surprising but that translates into systems integrators selling systems for less money and making more (or at least the same) profit on them.

Quite a bit! Look at all the places Linux ended up. Servers, phones, embedded systems, etc. The freedom to modify and tinker encourages innovation. The cost encourages cheap experimentation.

The difference is that most of us don't own million-dollar fabrication labs. At best, we would be tinkering with FPGAs with custom cores, but FPGAs are an order-of-magnitude slower than traditional CPU ASICs.

So we the typical user can't make use of open source designs.

------

An open source "conglomerate" of companies may work. But I haven't fully thought about the economics of it.

Linux is funded by billion dollar companies (https://www.linuxfoundation.org/membership/members/), and it is put into phones & cloud servers by billion dollar companies.

How many of those billion dollar companies own a fab?

Realistically, only Samsung, Intel, and TSMC can make next-generation chips. (Global Foundries just quit the 7nm race. They're going to be stuck at 12nm). Intel is fully proprietary tech, so that leaves Samsung and TSMC as the only companies that make chips for other companies.

At the end of the day, an open-source chip isn't really much benefit when there are only two manufacturers of chips.

Intel actually does do contract fab work - they just happen to be really bad at it so they don't get much business.

But there is a long tail of chip-making at older nodes to reduce cost, and for analogue integration. Risc-V is getting its start here. I hope we'll see a practical desktop version at some point, but that's not necessary for Risc-V to win.

TSMC is fab-only.

It does not compete with its clients who produce chips.

Thus anyone with a contract with TSMC can be a chip producer.

quite a bit of open source software is maintained and consumed by megacorps nowadays - like, OSS really does become a way for conglomerates of companies to share tech (when the alternative is monopoly-supplied monocultures, it makes a lot of sense). The hardware world seems analogous to what the software world was like in the 90s - a small number of proprietary platforms.

I think the open source hardware has more appeal in that end-users can "audit" their hardware... I'm not sure how true it is, but that's the idea...

Maybe a bit like the OpenPOWER project?

Yeah, but its a bad example. Because OpenPOWER doesn't need an open-source chip to function. POWER9 is still owned and controlled by IBM.

OpenPOWER is basically a set of documents and specifications that is analogous to IBM's original "PC" specification. This is good for sure, but it doesn't mean that POWER9 is open source like RISC-V is.

If anything, I think OpenPOWER is a good example of why an open-source chip is unnecessary. It shows that a group of companies can work together and build a major platform without the need of open sourcing the chip. I'm unsure what RISC-V gains above and beyond the OpenPOWER consortium.