
Ask HN: What's the value proposition of RISC-V? - trelliscoded
I&#x27;ve been seeing more interest in RISC-V lately, I suppose due to the recent RISC-V workshop at the end of November:<p>https:&#x2F;&#x2F;www.google.com&#x2F;trends&#x2F;explore?date=today%201-m&amp;q=risc-v<p>I can see how the architecture is of benefit for academic research, given how conservative all the other ones are with regard to protecting their IP.  Some of the NDA related hoops I&#x27;ve had to jump through as an embedded developer have had a direct revenue impact on past projects, so I&#x27;m pretty motivated to avoid that nonsense by supporting a neutral, open, consortium-backed architecture instead.<p>However, if I put my business hat on and am preparing to bid on a project, I find myself without a strong argument for favoring RISC-V instead of ARM or MIPS.  I can make an argument for the usual open source benefits of design longevity and avoiding vendor lock-in, but it&#x27;s a really hard sell when it boils down to SiFive versus essentially the entire rest of the semiconductor industry.<p>Is there something I&#x27;m missing about RISC-V?  Some commercial advantage I&#x27;m not aware of?
======
audunw
In the beginning, the main commercial interest in RISC-V, is as an internal
MCU core which is not customer-programmable. In my previous job, we used an
OpenRISC core, and it was awful. If I didn't quit I would have made a very
strange push for developing a simple RISC-V core, at least once the compressed
ISA was finalized.

It's very simple to make a small and efficient RISC-V core in-house, and if
that means we can avoid paying a huge amount of money to ARM, that's
fantastic. For some products (radio microcontrollers), it's possible that
RISC-V will live alongside ARM for a while. Maybe if RISC-V is lucky,
semiconductor companies will start to allow customers to program the RISC-V
core, and that creates an opening to take on ARM. All it takes is one big
customer that says "we are willing to take the hit in debugging and
development tooling, in order to save a few cents in ARM licenses on this
chip"

You can kind of see ARM positioning themselves for this reality as well. They
are branching out into a lot of different areas in order to stay relevant.
They've invested massively in debugging IPs and are now investing in
architectures for more secure CPUs/MCUs (TrustZone). They have GPU cores, DSP
extensions, etc.

Over time, the market for "plain, dumb 32-bit MCU cores" will definitely be
taken over by some open source, royalty free solution.

~~~
chrsw
Can you explain what you mean by "Maybe if RISC-V is lucky, semiconductor
companies will start to allow customers to program the RISC-V core"?

~~~
xemdetia
As far as I am aware if you license ARM you are not just getting the
information to put an ARM core with an ARM instruction set in your system, you
can also add custom instructions to access custom silicon that's in the same
package (I think the Wii did that to an extent with their DRM). That way you
can add your own very high performance and specialized extensions that might
normally end up being separate custom silicon IC's. Compare this to the
generally available RISC-V cores which would be not specialized towards some
end but allow you to program them as a more general device cooperating with a
larger system. This I feel is more apparent in SoC circumstances.

------
phkahler
In my day job we're using an Infineon SoC with an ARM core. Because it's
mixed-signal with 20-30v power stuff on a 130nm process, the ARM core only
runs at 40MHz. See here:
[http://www.infineon.com/cms/en/applications/automotive/body-...](http://www.infineon.com/cms/en/applications/automotive/body-
convenience/3-phase-motor-control/)

The SiFive RISC-V core runs at 320MHz on a 180nm process IIRC, so I'm
wondering if a near drop-in replacement would get me better performance on the
SoC I'm using. It certainly wouldn't hurt and they could save an ARM license
fee. As a customer I'd switch in a heartbeat if I could get faster throughput.

Now there are other companies that make gate drivers and the other peripherals
we need but don't have a CPU core. They could readily compete with this chip
by paying SiFive or one the other consulting companies to help them integrate
a RISC-V core with their existing IP. No per-unit costs, and the software
toolchain is already there. Anyone can use it to ease the transition from
analog to mixed-signal.

~~~
_chris_
_the ARM core only runs at 40MHz_

I wouldn't be surprised if that's purely a licensing/price discrimination
issue, and not a technical issue. Either way, an other argument for RISC-V.

------
BenoitP
My two cents:

* It is hardware's linux moment. The entry cost is low, everything is customizeable to your client's needs, everything can be inspected and modified. Everybody can copy-paste a SoC, do some plumbing; and hit the ground running. The conditions are perfect for ownership to be shared. As it is the first to do so, RISC-V will ride the first-mover advantage.

* New great tools are being created, and given away for free.

* Economics are changing. It is apparently possible now to buy tiny areas of a mask set for 30k USD, and have the results in shorter times. This means short and cheap iterations. Garage level silicon startups are becoming a thing; and the intricate corners of the market will get filled exactly to their need.

* Physics has been depleted. Walls everywhere. Power wall, clock wall, Moore's law. The only way to offer better performance now is opening things to customization. This is why we're seeing AWS pushing FPGAs as a first class citizen. This is why we're seeing Google's TPU. Microsoft is toying with FPGA-based networking, and you can bet there will (RISC-V?) silicon once their use case settles. Generic CPUs will become rarer, you will host your webservers on a GoLangChip™ with hardware support for GC and actors.

* More customization means RISC-V will be the chip of IoT; in which power consumption, size, performance requirements will be to the extremes of the envelope. If you have a niche market and simple things to do, and you customize your silicon well; 0.01 mm^2 of solar panel can power 0.01 mm^2 of chip. Dust computing could be a thing for select workloads.

* David Patterson says so.

\----

On your question to choosing between RISC-V vs ARM or MIPS, I say it does not
matter that much if you need a general purpose CPU. On the other hand if you
gain something from having the thing customized (power consumption, memory
access patterns, some DSPs here and there); then you should choose RISC-V
because someone will do it for you at low costs. Choosing RISC-V now leaves
the door opened to these customizations.

\----

On another note, I think that in the future we will wonder why we spend so
much time bikeshedding javascript vs java vs ruby vs php vs python. All those
things only run on a CPU.

~~~
rwmj
_Economics are changing. It is apparently possible now to buy tiny areas of a
mask set for 30k USD_

Indeed, TSMC are calling it "CyberShuttle":
[http://www.tsmc.com/english/dedicatedFoundry/services/cyberS...](http://www.tsmc.com/english/dedicatedFoundry/services/cyberShuttle.htm)

------
cesarb
One interesting advantage of RISC-V is _extensibility_. RISC-V has:

\- Two major opcodes reserved for custom extensions (four if you aren't using
RV-128, which you probably aren't);

\- Easy-to-decode variable length encoding, not only for half-size
instructions (normally the C standard extension), but also for longer
instructions; IIRC, the HWACHA extension uses that for 48-bit vector
instructions.

That is, RISC-V can be used as a base ISA for a your own custom ISA, while
keeping the same tooling and being able to reuse common code. Need a
coprocessor with extra DSP instructions? No problem, get a 64-bit RISC-V core
as a base and add the DSP instructions to it. Need an extremly small embedded
processor to manage your complicated chip? RISC-V has a small variant, RV32E,
which is the same as the normal 32-bit RISC-V but with half the registers.
Don't want to wait for the B standard extension to add POPCOUNT? Make your own
extension. And so on.

~~~
lttlrck
How easy is it to extend the tooling to support these opcode customizations?

~~~
_chris_
Incredibly easy at the assembler level, harder if you want the compiler to
understand/schedule it for you.

------
rwmj
I thought this was a good talk -- you only really need to watch the first
quarter, and I'll try to summarise the main points below.

[https://www.youtube.com/watch?v=b5g8u3GA-
lo](https://www.youtube.com/watch?v=b5g8u3GA-lo)

 _(Please note, these are not my points, they are arguments from the talk)_

\- There are many ISAs used on a SoC. According to the talk there are SoCs
with a dozen different instruction sets.

\- Some of them are homebrew.

\- Would be nice if instead of having to invent an ISA, there was a free, easy
to implement ISA already there with toolchain support.

\- Different purposes (eg. DSP, GPU) require different ISA variants, so RISC-V
is extensible.

\- You could use ARM (but not x86), but the license is very expensive, and you
need the license to verify compatibility, use logos, avoid infringing patents.

\- Benefits everyone because there becomes a really free market in chip
designs, resulting in reduced cost.

\- RISC-V is much simpler than x86 or ARM.

\- Microarchitecture independent.

------
yaantc
I see an interest in the deeply embedded space. ARM has a reputation of being
cheap, and it certainly is compared to Intel. But when you go to the low end
(mass volume basic IoT), it's not cheap anymore. And their portfolio may not
have all the options one need, and the core won't be customizable
(architectural licenses are out of reach for small/medium shops).

The possibility of having customizable royalty free cores with good compiler
support, good traction (strong ecosystem), and support available if needed is
interesting in this space, and would be new. There are commercial offering
with lower royalties than ARM and a flexible offering, but AFAIK not
customizable. There are free options with full RTL access like the Latice
Mico32 (lm32 in GCC), and although it's supported by GCC it's a small
ecosystem and the available options quite basic. In this space RISC-V could be
a way to gather a bigger community than what already exists and put resources
in common to quickly provide more options to designers.

One nice thing RISC-V could bring is that most such "exotic" deeply embedded
options are only supported by GCC (or proprietary compilers, ouch). RISC-V has
LLVM support, so could support Rust too before other embedded options. For
security sensitive applications that could be a plus.

------
valarauca1

         Some commercial advantage I'm not aware of?
    

1\. No licensing cost upfront for tap-out.

2\. Open source designs so you can even decrease tap-out costs further.
Allowing you to focus on the features you are selling.

3\. Out of the box compiler support for GCC and LLVM.

4\. Provided you stick with RISC-V one doesn't have to re-pay their software
development cost every generation. Your compiled ELF's will still work.
Software Development $$$ >>>> Hardware Tapout $$$.

5\. Out of box compiler/debugger support. Not making your dev team adopt a new
tool chain is a HUGE time saver and cannot be understated.

~~~
tonyplee
Not sure it is really good deal for SOC company in US.

For the past 10 years, I have been working for an ARM SOC company in US. More
and more I see zero margin in ARM SOC especially - with $5-15 4 core 32, 64
bits ARM soc in the market.

For Pi-zero, it is $5 for PCB with 512MB of RAM.

There are no $ to be made in SOC HW and board. If there is any margin left,
small ARM SOC vendors from China/Taiwan will quickly take them over and make
sure nothing is left for US companies.

For these reasons, I don't see anyone can make $ from making any HW SOC/board
in US with ARM nor RISC-V type ISV.

------
CalChris
Chisel is pretty cool in its own right. But the best I can say about RISC-V is
that it's clean and open source. It is clean. Basically, it's a clean up. Get
rid of register windows, branch delays slots, tagged integers, ..., every wart
that previous RISCs thought were a good idea but turned out very bad.

Clean is good but in 2016 that's not enough for me. x86 is very ugly but Intel
has spent decades making it fast, low power, ... Anything you want it to be
but never _perfect_.

I think RISC was sort of a good idea in the 80s. Not great but good. It
continued the ld/st/register approach of Saint Seymour. IBM ran with it and
arguably started it.

But it's been tried and found ... wanting.

~~~
MrBuddyCasino
> Get rid of register windows

The ESP32 is a very new chip and has them too (xtensa arch). Why are they bad?

> RISC was sort of a good idea in the 80s

This is where people usually come in saying that x86 is internally RISC, and
that the ISA helps with code density which is otherwise a problem for RISC. Is
there any truth to that?

~~~
userbinator
As mentioned, the whole RISC approach came out of the 80s, but it's important
to remember that this was at a time when RAM was (briefly) faster than the
CPU, so memory bandwidth was largely unused and the CPU instruction execution
was the bottleneck. Thus the idea of sacrificing fetch bandwidth to achieve
lower cycle times and thus more instruction throughput, along with simplifying
the CPU core in the effort to speed up instruction decode/execute to allow
raising clock speeds.

Today, memory bandwidth is the bottleneck, caches are essentially mandatory
for reasonable performance, and newer implementations of even architectures
classically considered RISC, e.g. ARM, do uop-based decoding. Physical limits
also put an end to increasing clock speeds, and because of OoO execution and
the memory bottleneck (which becomes even more of an issue with multiple
cores), it makes more sense for a CPU to consume more complex instructions and
decode them internally into "RISC-like" uops for scheduling and execution,
even if each one takes a few more cycles.

 _This is where people usually come in saying that x86 is internally RISC, and
that the ISA helps with code density which is otherwise a problem for RISC. Is
there any truth to that?_

This comparison might be of interest:
[https://www.extremetech.com/extreme/188396-the-final-isa-
sho...](https://www.extremetech.com/extreme/188396-the-final-isa-showdown-is-
arm-x86-or-mips-intrinsically-more-power-efficient)

It shows that x86 and ARM are very close, while the MIPS, the "purer RISC",
lags behind in terms of efficiency despite having twice as much cache as the
next smaller system in the list.

IMHO, as someone who has a long experience working with x86 Asm, I rather like
it. I think its predecessor, Z80/8085/8080, is pretty nice too. The 32-bit
extension (i386) was quite orthogonal and retained a compact encoding. If
there's anything I'd consider "ugly", it'd be what AMD did to it with their
64-bit extensions. From this perspective, all the RISCs look absolutely boring
and limited, more so the "cleaner" they are. (ARM is slightly less of a "pure
RISC", and that may be one of the reasons why it has remained competitive.)

~~~
dfox
The main proposition of RISC is that you can get near 1 IPC without caches
provided that you have enough fetch bandwith (which still is not significant
problem for deeply embeded harvard designs). Doing >=1 IPC on CISC
architecture with variable length unaligned instructions is essentially
impossible without I-cache and significant complexity.

The reason why ARM implementations do uop-based decoding partly lies in the
fact that while ARM ISA maps well to traditional RISC pipeline, it does not
map so well to superscalar pipeline be it with or without OoO.

~~~
CalChris
> The reason why ARM implementations do uop-based decoding partly lies in the
> fact that while ARM ISA maps well to traditional RISC pipeline, it does not
> map so well to superscalar pipeline be it with or without OoO.

Do you have a cite on that? I'd like to know what the problem was with ARM's
ISA that presented problems for superscalar.

If ARM is doing it then that argues against calling uops RISC instructions.

~~~
_chris_
_I 'd like to know what the problem was with ARM's ISA that presented problems
for superscalar._

Load/store multiple, for starters. Even just load-pair-increment-address is a
pain as it requires 3 write ports.

[https://arxiv.org/pdf/1607.02318.pdf](https://arxiv.org/pdf/1607.02318.pdf)

------
mwcampbell
A recurring theme I've seen on this thread is the feasibility of producing
customized chips. I, for one, would love to see a processor that can run Linux
(with an MMU), a high-quality audio DAC, a power management unit, and a WiFi
radio -- but no GPU or VPU -- all integrated on one chip. Something like the
i.MX233 [1], but with an up-to-date ISA rather than ARMv5, and with integrated
WiFi. One could imagine Amazon using such a chip in a future generation of the
Echo Dot.

[1]: [http://www.nxp.com/products/microcontrollers-and-
processors/...](http://www.nxp.com/products/microcontrollers-and-
processors/arm-processors/i.mx-applications-processors/i.mx23-applications-
processors-integrated-power-management-pmu-arm9-core/multimedia-applications-
processors-power-management-unit-arm9-core:i.MX233?&tid=vanIMX233)

~~~
Someone
I think the reason that you can’t get such a CPU isn’t that it impossible to
create one with other instructions sets, but that, apparently, nobody has
thought it be a product that will make them money.

I doubt that the licensing cost of an up-to-date ISA is the bottleneck there.
Because of that, I don’t see how RISC-V would be of much help there.

What would help is if a cheap way to make bespoke CPUs in low numbers would
become available. That would enable hobbyists to order exotic hardware.

Also note
[https://community.nxp.com/thread/440796](https://community.nxp.com/thread/440796),
which mentions a somewhat successor
([http://www.nxp.com/products/microcontrollers-and-
processors/...](http://www.nxp.com/products/microcontrollers-and-
processors/arm-processors/i.mx-applications-
processors/i.mx-6-processors/i.mx6qp/i.mx-6ull-single-core-processor-with-arm-
cortex-a7-core:i.MX6ULL)) I haven’t checked its features against your list.

------
gluggymug

        However, if I put my business hat on and am preparing to bid on a project, I find myself without a strong argument for favoring RISC-V instead of ARM or MIPS.
    

I think I agree with you on that. It is still early days for RISC-V and it
would be a big risk to use the core in an SoC now. Every time I take a look at
it as an SoC engineer I see a lot of work that needs doing to integrate it.

\- Basically you would be using a heap of dev tools that you never touched
before.

\- The bus is something called TileLink which is their own protocol so all
your peripherals have to be compatible or wrappers have to be made.

\- Verification IP seems minimal and not SystemVerilog so you'd have to write
it all yourself.

\- Your SW guys would need a good emulator. Don't know if theirs is any good.

Other posts are going on about features but if I think about how much SoC work
would be required I question whether it is cheaper than ARM or MIPS.

~~~
_chris_
_\- The bus is something called TileLink which is their own protocol so all
your peripherals have to be compatible or wrappers have to be made._

FYI: TileLink is not a RISC-V thing, it's a Berkeley/SiFive rocket-chip
processor thing. And it has an AXI interface on it anyways.

~~~
gluggymug
Sorry I am just basing this off what I can find. I don't see AXI mentioned in
the SiFive docs when I skim through.

------
cmrdporcupine
My take is that it's still early days, but:

Over the next decade more and more companies will be building out their own
SoC-type solutions, either as FPGA or ASIC. The cost of developing custom SoCs
is going to drop. In this context licensing an ARM core every time you
approach this problem is going to end up being a major part of the cost and
hassle. Having a quality open ISA that can be adapted by anybody will be
extremely useful.

I don't work in the processor industry, but that's how I see it from the
outside. And the work on RISC-V so far is very impressive.

~~~
StringyBob
The cost per transistor is going down every generation, but the NRE cost of
developing a SoC is going up and up. Pretty much doubling every manufacturing
generation (e.g. 40nm -> 28nm -> 16nm).

The cpu is actually a relatively small chunk of that cost these days, but once
in volume production even this is dwarfed by software development costs...

~~~
valarauca1

        but once in volume production even this is dwarfed by 
        software development costs...
    

This is one of the strongest arguments for RISC-V

Not only do you avoid licensing costs, but the ELF files you have from the
2-3year old model will still execute on your new model chip.

All one needs to do is dynamically link against their new special
instructions.

------
monocasa
Having access to the HDL for a chip would be awesome. We use a custom RTOS at
work, and occasionally run into actually new silicon bugs (ie. the vendor ends
up writing errata based on what we found). If I had access to the HDL, it'd
reduce a month long debugging->fix cycle quite a bit and let me get back to
more important work.

~~~
simcop2387
Don't know your requirements, but take a look at picorv32.
[https://github.com/cliffordwolf/picorv32](https://github.com/cliffordwolf/picorv32)

~~~
monocasa
I'm mainly waiting I can actually buy silicon, and can trust the company not
to go under in six months since our products typically have ~10 year
lifespans.

But yeah, this work and other work like it has me super excited about the
future.

~~~
simcop2387
Ah wasn't sure if you were doing it on an FPGA or not but I've been wanting to
give it a try myself. It looks like it'd be really nice for some projects that
I want to attempt (in particular an HDMI compatible ambient lighting project
for my TV).

------
moflome
Thanks for asking, I've been thinking about this too although from a different
viewpoint: I'm in the semi hardware industry so my questions are do I invest
time & resources in RISC-V? Here are my conclusions so far:

* Eco-System Value The contributors to the most recent RISC-V workshop [0] are an impressive list, there are sure to be lessons to be learned by all involved. R&D folks have a new, rich eco-system in which to explore new micro- and macro-level architecture optimization concepts. Vendors have, potentially, a head start on feeding new commercial interest. I rate this value five out-of five stars ( __ __ _)

_ Performance Value Related to eco-system, and perhaps why you're seeing
interest among cloud service providers, is that the industry workloads are
changing. Intel, Qualcomm and others are certainly focused on this too, but
perhaps RISC-V can be a game changer. In the same way that Tesla up-ended the
automotive market by delivering new technology directly to consumers without
the typical supply chain burden, Google, Facebook, Alibaba, Amazon (ie.,
hyperscalers) and perhaps Tesla too can find value in new SOC architectures
which they directly design. I rate this currently at two out of five, for
potential ( __...)

* Cost Savings Value I hear your concerns about the overhead of IP licensing, but don't blame the vendors: you folks purchasing IP ask for unlimited indemnification and ECO's -- it's crazy. And of course a CPU does not an SOC make, you'll still need plenty of additional IP (even lowly USB cores!) to develop an SOC. Plus, while I'm sure the LLVM/GDB tooling is better than it used to be, if RISC-V becomes poplar the commercial tools will follow. One star ( _....)

_ IP Terms The whisper in the industry for years has been that 'ARM/Intel glom
critical design ideas from customers which they roll into future cores to sell
to competitors.' Perhaps, rather than fighting this, RISC-V can allow all of
us to embrace this type of collaboration? Hard to see it now, and I don't
think Son-san should write-down his ARM acquisition costs just yet, but the
"CPU is just another core" could push the industry forward. Intel becomes a
compute-cloud provider. Qualcomm the IOT mesh provider. NVIDIA the AI services
provider. And the rest of us focus on software differentiation! Three stars (
__*..)

Thanks for the chance to frame my thoughts on this. I think I'm motivated to
stay more involved now.

[0] [https://riscv.org/2016/12/5th-risc-v-workshop-
proceedings/](https://riscv.org/2016/12/5th-risc-v-workshop-proceedings/)

~~~
sounds
Great analysis!

HN comment styling: If you want literal asterisks, separate them with spaces:
( * . * . * )

~~~
moflome
Thanks... wondered what happened to my damn asterisks!

------
simcop2387
I'm liking it for the open IP cores for FPGAs, there's some that are really
tiny but give you a nice powerful core that you can fit into as little as 750
LUT. That can be really powerful for handling stuff that is better suited to a
CPU instead of complicated logic gates.

------
jwatte
How about achievable raw performance?

