
Google, HP, Oracle Join RISC-V – Open-source processor core gains traction - mparramon
http://www.eetimes.com/document.asp?doc_id=1328561&
======
zhemao
Hi, I'm a Ph.D. student at UC Berkeley on the RISC-V team. Happy to answer any
questions about the RISC-V ISA or Rocket, our open-source reference
implementation.

Since there's always confusion about it, I'll start off by clarifying the
difference between the two. RISC-V is an open-source ISA standard. Rocket is
an implementation of this ISA which also happens to be open source. We do not
intend for the ISA to be tied to a single reference implementation. The
intention for RISC-V is to enable many different implementations (whether
open-source or proprietary). These different implementations can all run an
open-source software ecosystem, which currently consists of a GNU toolchain,
LLVM, and Linux kernel port.

~~~
orionblastar
What operating systems have been ported to RISC-V so far?

I would assume GNU/Linux, Android, Solaris because of the companies involved.
Am I correct?

~~~
justin66
If anyone has a RISC-V processor that will run Solaris, let alone a port of
Solaris, they haven't announced it.

It really would be interesting to know why Oracle got involved, though, since
their involvement is not the universal sign of pending success for an open
source project.

~~~
richardwhiuk
To be a cynic, one of the best ways to kill a project is to get involved and
make a mess from the inside.

~~~
BogusIKnow
Wasn't that in the CIA operations manual that surfaced some time ago?

[https://news.ycombinator.com/item?id=4831363](https://news.ycombinator.com/item?id=4831363)

------
asb
There's been a fair bit of discussion about this over on reddit:

[https://www.reddit.com/r/linux/comments/3z9t7k/open_source_p...](https://www.reddit.com/r/linux/comments/3z9t7k/open_source_processor_core_gains_traction_google/)

[https://www.reddit.com/r/opensource/comments/3z5ue8/open_sou...](https://www.reddit.com/r/opensource/comments/3z5ue8/open_source_processor_core_gains_traction_google/)

I'm a cofounder of lowRISC, a not-for-profit working to produce a fully open
source SoC implementing the RISC-V ISA, in volume silicon. If you have
questions then fire away.

~~~
modeless
Not a question really, but a comment for anyone involved: please push to add
integer overflow traps. No processor adds support because C doesn't require
them, and as a result no language detects integer overflow by default because
the processors make it slow. We need to break this cycle and it's not often
that a new processor architecture comes around.

[http://blog.regehr.org/archives/1154](http://blog.regehr.org/archives/1154)

~~~
Marat_Dukhan
MIPS has arithmetic instructions which trap on overflow. And guess what - gcc
& clang use variants which _DO NOT_ trap on overflow.

~~~
twoodfin
Why? If I had to guess, it's because there's more than a little C code out in
the wild that relies on "typical" signed overflow behavior.

~~~
renox
I don't know: both compilers are trying to use 'undefined use' to optimize
code (and too bad for you if this create problems for your application), so
your explanation isn't coherent.. My explanation is: lack of interest/money:
security is the thing that is always ignored, see the lack of funding of
OpenSSL until recently..

------
0xcde4c3db
Microsemi (the names "Actel" and "ProASIC" might be better-known) and Lattice
are also mentioned as sponsors in the article itself. These are FPGA vendors,
which suggests that they might be interested in shipping RISC-V soft cores in
their design tools or possibly even shipping chips with RISC-V hard cores
(similar to the Xilinx Zynq and Altera SoC families).

Notably, Lattice manufactures the only FPGA for which a full open source
design flow currently exists (albeit unsupported by Lattice themselves) [1],
and has its own set of open source soft processor cores [2] [3].

[1] [http://www.clifford.at/icestorm/](http://www.clifford.at/icestorm/)

[2]
[http://www.latticesemi.com/en/Products/DesignSoftwareAndIP/I...](http://www.latticesemi.com/en/Products/DesignSoftwareAndIP/IntellectualProperty/IPCore/IPCores02/LatticeMico32.aspx)

[3]
[http://www.latticesemi.com/en/Products/DesignSoftwareAndIP/I...](http://www.latticesemi.com/en/Products/DesignSoftwareAndIP/IntellectualProperty/IPCore/IPCores02/Mico8.aspx)

~~~
petra
I think the main reason the fpga companies aren't offering a low-cost , hard
core mcu+fpga chip is that they are afraid about competing against the mcu
companies.They can certainly reach the prices (Lattice claims a 50 cents
fpga).And it's very affordable to license from ARM.

So i don't see this sector changing with an open-source core.

~~~
sitkack
As sanddancer said, there are already high end parts from both of the top FPGA
companies that include hard MCUs. Xilinx has been doing this for a really long
time going back to embedded PPC. They wouldn't be competing against MCU
companies, they are already competing against other programmable logic
companies with the same features. The difficult part is the engineering and
marketing in a way that doesn't cut into the profit margin of those low cost
FPGAs. And RISCV provides a zero to low cost path to working netlists and
toolchains. MCU+FPGA hybrids are absolutely the future in programmable logic
it is only a matter of time before _all_ shipping fpgas have built in hard
programmable control logic.

~~~
petra
>> MCU+FPGA hybrids are absolutely the future

If so , it will probably come from china - they're building all the parts, are
hungry(even at the state level) to achieve dominance , and don't care much
about legacies, and have the market (probably backed by government) to support
such strategy.

------
mwcampbell
I wonder what Google, HP, and Oracle are planning to do with RISC-V. Will
RISC-V-based chips be able to compete with Intel in the server market?

Incidentally, I think the first consumer devices to adopt RISC-V will be home
wireless routers, because the stock firmwares for those are closed, so they'll
just need to be recompiled with a new toolchain. And those devices don't need
a GPU.

~~~
zhemao
We do expect embedded systems to be the main use of RISC-V processors at the
outset. In fact, I believe there is a consumer product out now - some kind of
camera - which uses a RISC-V processor.

I don't think we'll be able to compete with Intel's x86 chips for a while.
Mostly because Intel's silicon processes are more advanced than those offered
by other foundries.

~~~
aurhum
The AXIOM, a 4K camera uses a RISC-V

[http://riscv.org/workshop-jan2016.html](http://riscv.org/workshop-
jan2016.html)

------
bitwize
I wonder what the copyright license terms on Oracle's proprietary ISA
extensions will be...

------
thebeardisred
Obligatory: ¨RISC architecture is going to change everything¨ -
[https://arikia.files.wordpress.com/2013/02/test2.gif?w=625](https://arikia.files.wordpress.com/2013/02/test2.gif?w=625)

------
fmarch
Has any one created a verification infrastructure with any of RISC-V
implementations? The git repository does have a set of tests and benchmarks
but could not find any thing more than that.

~~~
gluggymug
Check out : [https://github.com/ucb-bar/rocket-chip](https://github.com/ucb-
bar/rocket-chip)

Last time I complained here about the verification infrastructure of this
project, someone gave that link.

I didn't like much of what I could find there.

What exactly are you trying to do?

~~~
fmarch
I want to at the minimum compare the architectural state of the implementation
on every retire with the ISA simulator (Spike).

In addition it would be good to have a set of assertions to maintain the
sanity (read functional correctness) while experimenting with the design.

How are these implementations verified right now ? All I see are few
assertions in chisel and small set of tests.

~~~
_chris_
You can get a commit log (PC, inst, write-back address, write-back data) from
Rocket to compare against Spike's commit log. It's not documented because the
verification story is still in flux, and the commit log is fairly manual
(since there will be many false positives).

Comparing a real CPU against an ISA simulator is VERY HARD. There's counter
instructions, there's interrupts, timers will differ, multi-core will exhibit
different (correct) answers, Rocket has out-of-order write-back+early commit,
floating point registers are 65-bit recoded values, some (required) ambiguity
in the spec that can't be reconciled easily (e.g., storing single-precision FP
values using FSD puts undefined values in memory, the only requirement being
that the value is properly restored by a corresponding FLD).

We also use a torture tester that we'll open source Soon (tm).

~~~
fmarch
Thanks for the information. I understand its a hard problem but an essential
one that needs a solution. It needs to be supported both in Chisel and with
appropriate infrastructure to test and compare with the golden ISA model. Is
there any one in the community who is actively working on the verification
story ?

~~~
_chris_
> Is there any one in the community who is actively working on the
> verification story ?

Not sure. I'd look out for videos to show up at the RISC-V workshop that's
ongoing ([http://riscv.org/workshop-jan2016.html](http://riscv.org/workshop-
jan2016.html)).

The problem is verification is where the $$$ is, so even amongst people
sharing their CPU source code, they're less willing to share the true value-
provided of their efforts. A debug spec is being developed and will be added
to Rocket-chip to make this problem easier.

With that said, MIT gave a good talk at the RISC-V workshop about their works
on verification, and we open sourced our torture tester at
([http://riscv.org/workshop-jan2016.html](http://riscv.org/workshop-
jan2016.html)).

~~~
_chris_
[https://github.com/ucb-bar/riscv-torture](https://github.com/ucb-bar/riscv-
torture), stupid copy/paste.

------
tbirdz
How does RISC-V compare with the J2 core based on the SuperH architecture by
the Open Processor Foundation[1]?

1: [http://0pf.org/](http://0pf.org/)

~~~
asb
I answered a similar (but slightly different) question here:
[https://lobste.rs/s/jmgsyl/untethered_lowrisc_release/commen...](https://lobste.rs/s/jmgsyl/untethered_lowrisc_release/comments/ng761j#c_ng761j),
comparing lowRISC and the Open Processor Foundation.

------
wstrange
Can someone explain the advantage of RISC-V vs. other open source
architectures (e.g. OpenSPARC?).

Are there legal issues that make it more favourable?

~~~
tw04
Well, I think the fact it's LGPL vs. GPLv2 is one point in favor of RISC-V.
The other major factor I believe is that the RISC-V architecture is better
suited for embedded type applications. I don't think you could (easily) scale
down the OpenSPARC design enough to make it a suitable architecture.

~~~
zhemao
The RISC-V ISA and Berkeley's open source reference implementations are BSD-
licensed, not LGPL.

And yes, the RISC-V ISA is simpler than the SPARC ISA. We also have clearly
separated the base integer ISA from the various extensions, such as floating-
point, atomics, supervisor, etc.

~~~
tw04
Thank you for the correction, I was thinking OpenRISC (which is LGPL), vs.
RISC-V (which is BSD).

------
chei0aiV
I wonder if HP are looking at RISC-V/lowRISC for their "The Machine" project.

------
Const-me
I wonder how are they going to compete with Intel?

I don’t see how they’re going to match raw performance against those 1tflops+
20-cores xeons. I don’t see how they’re going to match performance/watt
against 7w quad-core C2338. I don’t see how they’re going to match price
against $20 x5-Z8300. If none of the above, then why should
Google/HP/Oracle/anyone else buy that?

~~~
jeffbush
I don't think they need to compete with Intel.

The numbers I've seen suggests Intel ships around 300-400 Million processors
per year[1]. In 2014, 12 Billon (with a B) devices with ARM cores shipped[2].
In 2011, around 500 Million MIPS based cores shipped[3].

These are obviously very different businesses. But it's clear there is an
enormous market for licensable low-end IP cores that are used in everything
from cars, cable boxes, TVs, cellphones (many phones have multiple cores
internally to operate functions like the cellular baseband), etc. Most of the
licensees are just gluing together licensed cores and contracting foundries
like TSMC or Global Foundries to build them. The margins tend to be pretty
thin (we're talking chips that are in the single digits for cost), so saving a
little money on IP licensing is attractive. Since these are often custom
applications, binary compatibility is less of an issue.

That seems like a more interesting market for an open ISA and open core
processors.

[1]
[http://www.ft.com/cms/s/0/beff6e56-53ed-11e4-80db-00144feab7...](http://www.ft.com/cms/s/0/beff6e56-53ed-11e4-80db-00144feab7de.html#axzz3wFGbKjgu)
[2]
[https://atlas.qz.com/charts/Ek18VmbP](https://atlas.qz.com/charts/Ek18VmbP)
[3] [http://www.forbes.com/forbes/2011/0509/technology-mips-
sande...](http://www.forbes.com/forbes/2011/0509/technology-mips-sandeep-vij-
dvd-micro-chips-less-more.html)

~~~
Const-me
Thanks, that sounds reasonable.

