Ask HN: What's the value proposition of RISC-V?
https://www.google.com/trends/explore?date=today%201-m&q=risc-v
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've had to jump through as an embedded developer have had a direct revenue impact on past projects, so I'm pretty motivated to avoid that nonsense by supporting a neutral, open, consortium-backed architecture instead.
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's a really hard sell when it boils down to SiFive versus essentially the entire rest of the semiconductor industry.
Is there something I'm missing about RISC-V? Some commercial advantage I'm not aware of?
68 comments
[ 3.4 ms ] story [ 101 ms ] threadClean 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.
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?
Now it used to be clunky at first. For example the first generation Thumb required a processor mode switch between 16 bits instructions only and 32 bits only, with a performance penalty in thumb mode. But with Thumb2 there is no mode switch, both kinds can be mixed freely and the compilers are now smart enough that the performance impact is negligible (could be a gain sometimes with reduced I-cache pressure).
For deeply embedded designs, where code size probably matters most, such variable encoding is always supported nowadays with good results, and it's a way to differentiate for more exotic ISA like Cortus or Andes for example. In some specific benchmarks I did the lowest code sizes where from such embedded RISC ISAs, better than x86 for example (YMMV, benchmark your code for best results ;).
I haven't benchmarked the RISC-V optional compact code support, but I would expect it to be competitive with x86. Code size is no longer an intrinsic difference for CISC vs RISC from what I've seen, although there are variations between implementations.
========
Edit: one precision, there's no Thumb mode in ARMv8 64 bits mode. One can run 32 bits code using Thumb on an ARMv8 processor in 32 bits mode, but to use 64 bits mode means not using variable size instructions (Thumb), at least for now. But I see this as just an implementation specific decision from ARM. The high level message stays: it's possible to have good code density with a RISC ISA, and all deeply embedded RISC ISA have some form of variable instruction size (at least 16 and 32 bits).
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...
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.)
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.
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
Ugly, maybe. But hella clever given how much money HP+Intel spent on transitioning Itanium when a simple escape code would do.
The only real ugliness I can't stomach is the x87/MMX stack nonsense. I have it on good authority that the guy tasked with implementing it at Transmeta was driven into depression.
I'm sure you meant latency there.
Modern x86_64 chips are likely RISC-y in their core post μOP decoding. More-over it is way more complicated then that because port forwarding stalls point to what is presented as a core likely being 15-20 specialized cores working in conjunction. But then Skylake fixed this so who knows.
The RISC instruction density is just a hold over from the 80's when RAM was fast, and decoding was hard.
Modern iCache's + Moore's Law has more or less solved these problems.
Back in the 80s everyone called everything RISC. Check the Bulldog compiler book; the VLIW people were calling VLIW a RISC. Odd since Fisher had worked on microgramming but RISC was very much in vogue.
Before there was RISC there was micro programming, horizontal wide microprogramming. The VAX 11/780 was microprogrammed.
I think what people are saying when they say Haswell is a RISC is it's microprogrammed.
With the Pentium III the uop was 118 bits wide. Bandwidth not an issue. Latency always an issue.
http://www.tomshardware.com/reviews/intel,264-6.html
With Haswell, the scheduler can Macro Fuse a test and conditional branch.
I've never been happy with the shape shifting definitions of RISC over the years but that just doesn't fit any definition of RISC I've seen.
Lastly RISC started out as a critique of complex ISAs at a time when the VAX ISA was interpreted with microprogramming loops. Not with RISC loops.
So I think history has conflated the terms RISC and horizontal microcode and really they're different.
Lastly lastly, there is a difference between the interpreter loop approach VAX took and the translate approach Haswell takes. Also Transmeta compiled x86. But this does not a RISC make. All that's really going on is that Haswell is decoding an x86 instruction and caching the decoding step. The uop cache is relatively more recent (2000?) and long after RISC. But it saves decoding power and latency. The micro architecture wasn't that different before the cache was added.
The only commmon constant among all RISCs is pretty much that they separate load/stores from other operations(i.e. no memory operands).
By this definition, the only x86 Intel CPU that could vaguely be called RISC is the Pentium4 (i.e. NetBurst), which not only did break break load/stores from the rest of the operations early in the pipeline (i.e. before the trace cache), but also, for optimal performance, it was best programmed avoiding memory operands but using separate load/stores.
More recent Intel CPUs (possibly starting with Nehalem?) only break the load/store component and the actual op of complex operations at the execution stages, and keep them together for the rest of the pipeline.
That 118 bit uop is a microarchitectural implementation detail. It has a pedigree dating not just to the VAX but to 1957, to Wilkes' EDSAC.
In what way is this 118 bit uop not microcode? It is not designed for generality. It isn't exposed (other than # of uops in the Intel Optimization Manual or it is Agner Fog). A complex instruction is in fact interpreted just as POLY was on the VAX. It controls a pipeline. It is anything but Reduced.
Calling VLIW and x86 uops RISC doesn't make them RISCs.
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.
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...
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.
You may be able to get a RISC-V core for free, but will you get a fully verified RISC-V core including support for free?
Should RISC-V become a success then I imagine you'll see ARM dropping prices and perhaps core licensing will be a major cost in producing an SoC (as I understand it it's rather cheap right now, relative to full development cost) however you're still going to see people buying cores off established IP companies to get that verification and support.
Now linux gets plenty of free bug-hunting and fixing, most people in need of a linux kernel will be off to kernel.org rather than paying a company to supply a custom one. I'm not sure you'd see the same thing for a processor core. Verification requirements are a whole lot higher than they are for linux.
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.
I ask because in my experience dealing with current ARM-based boards, the development experience is, let's just say less optimal. So is there any chance we might actually see better debugging experience in RISC-V when the openness attracts more users, or is this really a hardware company's task to solve?
I assume that's just a typo/autocorrect, but it makes for a hilarious mental image
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.
* 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.
Indeed, TSMC are calling it "CyberShuttle": http://www.tsmc.com/english/dedicatedFoundry/services/cyberS...
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.
- 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.
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.
And two JVMs are on the way.
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.
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.
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.
- 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.
My SoC verification projects have been SystemVerilog only so I am not that familiar with SystemC.
Although I believe SystemC can be used for verification, my concern would be how well it performs in simulation together with SystemVerilog components.
Whenever you mix two different languages it usually runs slower. SystemVerilog is already not fast but you are stuck with it since a lot of IP is in SystemVerilog.
Also splitting the verification environment into SystemC and SystemVerilog for different parts would mean the various metrics like coverage from both sides would have to be merged somehow. It would be a challenge to put it lightly I reckon.
I thought the point of all this is to have open-source implementations for people to use in their SoCs.
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.
But yeah, this work and other work like it has me super excited about the future.
[1]: http://www.nxp.com/products/microcontrollers-and-processors/...
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, which mentions a somewhat successor (http://www.nxp.com/products/microcontrollers-and-processors/...) I haven’t checked its features against your list.
* 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/
HN comment styling: If you want literal asterisks, separate them with spaces: ( * . * . * )