SiFive bags $175m to further challenge Arm with RISC-V SiFive is pulling in nearly $400m in funding this year between a new investment round and the proceeds of a business sale with the ambitious mission of eclipsing rival Arm – and the x86 world of Intel and AMD – with processor designs for everything from smartphones to servers. The Silicon Valley-based chip designer said …
I’m curious to see how ARM will respond to this disruption. I guess there is the option of going into RISC V core design. Or maybe coming up with something new to compete in efficiency.
ARM cores years ago were simple things, but over the years the extensions weigh it down. This seems to be a natural lifecycle that these things go through, so a back to basics open source ARM NG maybe.
They're facing what Microsoft faced a generation ago... And the open source equivalent is only going to get stronger as the proprietary sector diminishes - it's especially so in tech.
I gather that Arm have already had to change their licensing agreements on MPU processors. They've also had to allow more flexibility (to some) with the ISA - something they really didn't want to do.
The smart move may be to put the ARM ISA and decision-making body into a foundation, and separate Arm Ltd into a pure design company. That way, companies might stick with what they know - so long as the licensing costs are right. Then Arm Ltd can go after the projects (and funding) it wants to do. There'd be nothing to stopping them designing RISC-V processors either...
But what will they do? I guess, they'll try to carry on with business as usual, and try to persuade everyone that they're Top Dog, and that they're all-powerful. Hubris.
To me the more interesting question is: what will ARM's sponsors do?
Qualcomm is pushing ARM in every nook and cranny much like Intel was x86 at the beginning of the epoch. IBM is another interesting one. As is NVIDIA; after the failed merger they confirmed the partnership with ARM for the long-term.
Legacy is a powerful thing, and it is not necessarily bad to pay ARM to do part of the work for you, especially if you're big. It'll be interesting to see when some large players will start to think that there is enough of a gain in making the switch. And what disruptive start-ups RISC-V enables in the meantime.
So if Arm were to pull an OpenPower move and make the ARM ISA open and royalty-free, exactly what would the appeal of RISC-V/SiFive be?
On which note, what is the appeal of RISC-V here compared to the much more established Power ISA for desktop & server usage? The actual chip design is still proprietary, no matter what.
Well... as things stand, RISC-V can beat ARM on Arm's X86-beating metric of PPA - Performance, Power, Area, because it's extensible.
It's said to be a simpler, cleaner ISA too. And there's open source design and verification software available for it.
There are also open sourced chip designs for RISC-V that I suppose can be built upon. These open source processors will eventually bite SiFive, Andes, et al too.
On which planet is SIFIvE or any of the RISCV *current implementations* even close to as PPA efficient as an ARM core? This is nonsense.
“In theory” RISCV could be. As indeed could the ISA I wrote on the back of an envelope five minutes ago. It’s quite similar to saying that “a four-cylinder engine is more fuel-efficient than a six-cylinder engine”. It’s just comparing the wrong domains.
RISCV is a spec, not an implementation. An Open-source set of synthesisable VHDL or Verilog is still a spec, not an implementation. It doesn’t have a “power” or an “area”, any more than it has a colour or a taste. This is just nonsense spouted by people who have never designed any hardware.
This has been discussed/debunked several times before. Micro Magic are not in the business of selling chips, and have no intention to do so. They are an EDA vendor. What they (claim to) have is a very innovative transistor design that allows extremely low-power operation. Of *all* chips. They happen to have picked RISCV to showcase on, but it would work the same on ARM. Or NXP cores for that matter. What they are selling is for *you* to license *their transistor IP* and make any damn core you please. This has zero implications for RISCV vs ARM.
The second aspect of this, is using Coremark to benchmark. This is an extremely restricted benchmark, and the problem with it is that it deliberately doesn’t stress the memory bandwidth. The consequence is that you can report as high a Coremark performance as you like, just by sticking a large number of cores on the die. In this case, they need 25 cores to match the performance of just 4 ARM cores. But in practice, 25 RISCV cores would need 25 cores worth of on-chip cache, which would be *huge*. There’s a reason why modern CPUs try to max out the IPC of the core at cost of area before scaling to multiple cores. And it just shows the inexperience of the RISCV folk to propose such a tradeoff. Anyone in the hardware industry spots this a mile off.
ARM was simple and clean when it started out. It's just picked up a lot of stuff along the way to meet new requirements/roles. If ARM were to open source the simpler subset of its ISA it might be possible to build multi-core dies with efficient cores equivalent to RISC V with back compatible cores for back compatibility.
Much like some CPUs have powerful cores for heavy workloads with lighter cores for standby/background functions.
The one thing that appeals to me about RISC-V is that they went through all the expired patents in that area, and took the best of the best from everything that was there and merged it very nicely into a very coherent ISA.
How you implement the ISA behind the scenes is effected by those decisions, and most of the best ones were to maximise what you got out while simultaneously minimising the resources required.
Ultimately it does not bring anything new to the table (It is not "Mill Computing, Inc"), but it is still very solid. But to interface to PCIe, DRAM, you will realistically still need to license those (proprietary) blocks from others, it is not like a free ISA makes everything magically cheaper.
In what sense is RISC-V about any of those things you mentioned? From a cursory glance RISC-V looks mostly like a text-book MIPS clone ISA, following a similar layout for e.g. conditionals. Yes, this will affect the underlying design and the software written for it, but whether any of it is necessarily better than MIPS, or ARM, or Power, or even x86_64 is still very much up for debate.
Especially when RISC-V's vector and many other extensions aren't even finished parts of the ISA yet. It's more of a concept of something that 'could be'. But so did AMD figure it could conquer the world with its 3DNow tech before Intel steamrolled it with MMX, SSE and we're now doing AVX, even as AMD ran over Intel's own 64-bit ISA (Itanium).
It's a harsh world out there, and as you mentioned, there's a much more to a system architecture than just the basic CPU core. Proprietary IP blocks, licensing vector extensions instead of rolling your own... depending on your target market it might be better to just suck it up, get an ARM ISA license and roll your own cores that work with any existing ARM-based software and extensions.
Kinda like what Apple did, for example.
An example would be the '“C” Standard Extension for Compressed Instructions'. RISC-V learned all they could from the previous "ARM Thumb" and "MIPS16" and then from "ARM Thumb2, microMIPS, PowerPC VLE".
"Typically, 50%–60% of the RISC-V instructions in a program can be replaced with RVC instructions, resulting in a 25%–30% code-size reduction."
"Benefiting from 25 years of hindsight, RISC-V was designed to support compressed instructions from the outset, leaving enough opcode space for RVC to be added as a simple extension on top of the base ISA (along with many other extensions). The philosophy of RVC is to reduce code size for embedded applications and to improve performance and energy-efficiency for all applications due to fewer misses in the instruction cache. Waterman shows that RVC fetches 25%-30% fewer instruction bits, which reduces instruction cache misses by 20%-25%, or roughly the same performance impact as doubling the instruction cache size"
"It is surprising that the most popular 64-bit ISA for mobile platforms (ARM v8) does not include a compressed instruction format given that static code size and dynamic instruction fetch bandwidth are important metrics. Although static code size is not a major concern in larger systems, instruction fetch bandwidth can be a major bottleneck in servers running commercial workloads, which often have a large instruction working set."
An alternative take could be that RISCV *didn’t* learn from previous industry experience.
As noted, ARM started with the Thumb (compressed) format on low-power low-capability devices, which makes a major difference for the reasons stated (reduced size of instruction cache). Other manufacturers also use compressed format (e.g. Texas Instruments DSPs). Given that ARM already had Thumb in-house, it is indeed surprising they didn’t build on it for ARMv8. And neither do AMD/Intel use a code compression engine.
Without being party to the detailed tradeoffs, I would note that the L1 instruction cache is tiny compared to the L2 cache and especially L3 of a modern superscalar out-of-order. The benefits are strongly diluted. However, there are downsides of code compression, such as extra cycle pipeline delay which reduces the efficacy of the speculative prediction. All things considered, it’s not obvious what the correct tradeoff is - could be one way, could be t’other. But ARM, Intel and AMD have the benefit of decades of internal simulations and feedback from previous generations. And they made their decision. But RISCV, *without having a single successful CPU out in the market*, think they’re all wrong. Good-o.
As an aside, real-time hardware code compression/decompression isn’t that hard to implement. I have designed and implemented it in the past on CPUs that I have worked on. It can be implemented transparent to the ISA, so it doesn’t affect the compiler (Flag to Compress going into RAM, decompress at instruction decode). Fairly standard. I have literally no idea why RISCV felt it necessary to clutter up the ISA spec with that, I expect they had their reasons.
By the way, for those to who it isn’t obvious: the advantage of keeping code compression *out* of the ISA and implementing it transparently into/out of RAM, is precisely the fact that it *is* a tradeoff.
Therefore, whether it is the right thing to do or not can depend on which silicon generation you are targeting. It might well be the right thing to do at 65nm, the wrong thing at 14nm, and the right thing at 3nm. So, if you want to maintain long-term binary compatibility, the additional cost of implementing a hardware *compressor*, rather than doing any required compression upfront in the compiler, might be worth it. Or not. Everything is a tradeoff. There is no “one true answer” independent of silicon vendor that you can just open source. Doesn’t work like that.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
