[crowdsupply.git] / updates / 001_2018nov28_why_a_libre_soc.mdwn

# Why make a quad-core 64-bit SoC: surely there are enough already?

So the year is 2018, and there does not exist a single commercial
"System-on-a-Chip" that is capable of running 3D mobile games and
playing 1080p60 video, where the end-user, including commercial
customers, cannot 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 (a more in-depth analysis was done
<a href="https://www.crowdsupply.com/eoma68/micro-desktop/updates/picking-a-processor">here</a>,
and 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 <a href="https://thinkpenguin.com">ThinkPenguin</a>
and <a href="https://puri.sm/products/librem-13">Purism</a>, 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 that the WIFI firmware is libre (ruling out 802.11ac), and they also
specifically do not use an NVIDIA GPU.  They also ensure that 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, using relatively expensive
power-sucking Intel processors.  15 to 50 watts just for the processor
is not uncommon, here.  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 that it goes.
Imagine that 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
with the 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.  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 an 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 that they can, getting it out the door and moving on to the next
product.  Samsung actually has two separate teams (one internal,
one of them is a third party called Nexell) that produce Samung-badged
SoCs on overlapping cycles, as a way to help reduce the risk.

The problem for all of these companies is: apart from the increased speed,
they're all using ARM cores, 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, is 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:

* **(A) the power consumption of a RISC-V core is so much lower**
  (the technical reason why is down to "Compressed" instructions,
  which result in a 25% code reduction, which in turn means that
  the L1 Instruction cache can be smaller, and that translates
  to a huge - 40% - reduction in power)
* **(B) availability of source code significantly reduces development costs**
  This is not an end-user argument, it's one for the OEMs (Original
  Equipment Manufacturers).  A good example is
  <a href="http://www.h-online.com/open/news/item/Intel-and-Valve-collaborate-to-develop-open-source-graphics-drivers-1649632.html">here</a>,
  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.
* **(C) Reduced royalties means reduced selling price**
  Softbank recently ordered ARM to increase royalties.  They believe that
  they have the market cornered.  What they don't realise is: 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, and 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.  USB2: $100k.
USB3: $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
<a href="http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev">mailing
list</a> and get in touch.  If you want to help sponsor the project
or invest in the team, contact me directly by
<a href="email:lkcl@libre-riscv.org">email</a>.