So, the year is 2018, and there does not exist a single commercial "System-on-a-Chip" (SoC) that is capable of running 3D mobile games and playing 1080p60 video, where the end-user, including commercial customers, can say that they have full control over their devices.

Let that sink in for a moment.

To reiterate: there does not exist, anywhere in the world, one single, popular, modern, commercial, portable tablet, IPTV device, netbook, or smartphone, today - in the year 2018 - where an end-user may download the full and complete source code of the bootloader, kernel, operating system, video processor library, and 3D GPU library, and all the internal and external peripherals. (For a more in-depth analysis, see a previous EOMA68 update — two years later the situation still has not changed.)

Now, there happen to be some medium- to high-end systems based on Intel processors, from both ThinkPenguin and Purism, where both these companies go to the trouble of actually re-flashing the BIOS, replacing it with LibreBoot or Coreboot. They both also make sure the Wi-Fi firmware is libre (ruling out 802.11ac), and they specifically do not use an NVIDIA GPU. Finally, they ensure the Intel "Management Engine" (known as an NSA backdoor spying co-processor) is (or may be) disabled.

However, that is the medium- to high-end market, using relatively expensive, power-sucking Intel processors. In this realm, 15 to 50 watts just for the processor is not uncommon. Everything else - tablets, smartphones, and most netbooks, use ARM SoCs in order to keep power consumption well below 10 watts, and in some cases below 5 watts, and that’s where it goes to hell in a handbasket.

It’s not specifically ARM’s "fault": it’s just the way it goes. Imagine you are a new (or even an established) fabless semiconductor company. Your "job" is to get an integrated, all-in-one product out the door at minimum cost (where that’s going to be at least USD $10m to $30m), and the least amount of risk. In evaluating the options, you absolutely want tried-and-tested, proven, risk-free, "off-the-shelf" peripherals (called "hard macros") which you can first test in the biggest, most horribly-expensive FPGAs you can get hold of, then when the engineers are happy, throw around a quarter of a million dollars a pop at a test chip, and, finally, once that’s tested and known to be working, put down a couple of million on production masks. That’s before even actually getting chips manufactured.

The sums of money involved are so vast that absolutely no fabless semi company will take the risk of using an unknown, unproven design. They would far rather pay USD $250,000 to an established company to license a proprietary GPU hard macro, for example, which comes with an associated proprietary software library, because the company that licenses that GPU design has had multiple customers successfully tape it out. The same story goes for the VPU: another USD \$100,000 to \$200,000 on license fees is better than spending USD $10m and above, only to find that the chip doesn’t work. DDR3/4 PHY and Controller hard macro licensing: in excess of USD \$1m, even as high as \$2m. These are not costs where you can mess about.

All of this is because these are integrated processors. There is no separate VPU: it’s on-board. There is no separate GPU: it’s on-board. There is no separate "Northbridge" or "Southbridge" IC: it’s on-board, all on the same die as the actual processor, as a way to save both on space (think mobile phones) and power (driving external pins uses a huge amount of power, which an "embedded" all-in-one design does not have). The down-side of this all-in-one approach: one single mistake and the entire chip, with all the investment up to that point, is junk.

And the problem is compounded by the fact that foundries themselves make money only by selling wafers. They absolutely hate having their time wasted. If you, as a new fabless semiconductor company, come to them with a design that fails, and yet you booked a production run because you were expecting it to succeed, now the slot’s cancelled because your chip failed, and they just lost tens to hundreds of millions of dollars worth of business, if none of the foundry’s other customers happen to be ready with a mask set and the cash lined up. If that happens, do you think that foundry will ever take your calls again?

This is just how things are. Most fabless semi companies looking to compete with other embedded tablet / smartphone / netbook / IPTV / etc. SoC companies are taking what they can get, doing the best integration job they can, getting it out the door, and moving on to the next product. Samsung actually has two separate teams (one internal, the other a third party called Nexell) that produce Samsung-badged SoCs on overlapping cycles, as a way to help reduce the risk.

The problem for all of these companies is that, apart from some differences in processor speed, they’re all using ARM cores and they’re all using the same GPU hard macros licensed from the same handful of companies: there really is absolutely nothing really significant that differentiates them from each other (and to be frank, the end-user genuinely doesn’t care what the processor is: they just buy the end-product).

Along comes RISC-V, which in the same geometry has a power envelope that is a whopping 40% lower than any ARM or Intel processor available today.

So, this is where it gets interesting, given that power consumption is key to the success of mobile devices. Here in Taiwan, kids as young as eight carry around a smartphone… oh, and a "power bank" that’s twice the size of the phone (anyone who used to have a Nokia 6310i, with a standby time of over two weeks, will be laughing and crying at the same time).

The point of this story is: it’s not enough to just go "oh, I think I will design a Libre SoC today", it has to have an actual commercial hook: it has to have compelling reasons why it will sell. For the Libre RISC-V SoC, those are threefold:

1. Significantly lower power consumption. The technical reason why RISC-V has lower power consumption is down to "compressed" instructions, which result in a 25% code reduction, which in turn means the L1 instruction cache can be smaller, and that translates to a huge - 40% - reduction in power.
2. Reduced development cost due to source code availability. This is not an end-user argument, it's one for the OEMs (Original Equipment Manufacturers). A good example is [here](http://www.h-online.com/open/news/item/Intel-and-Valve collaborate-to-develop-open-source-graphics-drivers-1649632.html), where two completely independent really large companies came together to fix bugs in their respective 3D codebases, all without requiring NDAs or lawyers to get involved.
3. Reduced royalties means reduced selling price. Softbank recently ordered ARM to increase royalties. They believe they have the market cornered. What they don't realise is that end-users don't care what processor is inside. They just want a device that "does the job." By using libre-licensed hard macros (including for the main on-board CPU, the VPU, and the GPU), the royalties are slashed literally to zero.

There are additional justifications for going libre, even with the hard macros for the peripherals: the costs of licensing proprietary hard macros are enormous. The highest is for DDR3/4, which can come to around USD $2 million for the PHY and the Controller (per 32-bit interface). Gigabit Ethernet: USD \$50k. USB 2: \$100k. USB 3: $500k. All of these costs are per interface instance. If as many of these can be cut as possible, it adds up to a saving of over USD $4 million, bringing the development cost down to only around USD $6 million.

Sad to have to say it: being ethical isn’t enough. Money talks. Once that’s accepted, it turns out that yes, there’s a strategy that happens to reduce both development cost and end-product cost, oh, and happens to be ethical and gives people back control of their devices at the same time.

If this is something you want to help with, join the mailing list and get in touch. If you want to help sponsor the project or invest in the team, contact me directly at lkcl@libre-riscv.org.