SiFive Announces First RISC-V OoO CPU Core: The U8-Series Processor IPby Andrei Frumusanu on October 30, 2019 10:00 AM EST
In the last few year’s we’ve seen an increasing amount of talk about RISC-V and it becoming real competitor to the Arm in the embedded market. Indeed, we’ve seen a lot of vendors make the switch from licensing Arm’s architecture and IP designs to the open-source RISC-V architecture and either licensed or custom-made IP based on the ISA. While many vendors do choose to design their own microarchitectures to replace Arm-based microcontroller designs in their products, things get a little bit more complicated once you scale up in performance. It’s here where SiFive comes into play as a RISC-V IP vendor offering more complex designs for companies to license – essentially a similar business model to Arm’s – just that it’s based on the new open ISA.
Today’s announcement marks a milestone in SiFive’s IP offering as the company is revealing its first ever out-of-order CPU microarchitecture, promising a significant performance jump over existing RISC-V cores, and offering competitive PPA metrics compared to Arm’s products. We’ll be taking a look at the microarchitecture of the new U8 Series CPU and how it’s built and what it promises to deliver.
As a bit of background on the company, SiFive was founded in 2015 by the researchers who invented the RISC-V instruction set at UC Berkeley back in 2010. The company’s goal was to develop and implement CPUs and IP based on the RISC-V ISA and produce the first hardware based on the technology. The company first full-blown CPU IP that was able to run a full OS such as Linux was the U54 series which was released in 2017, and ever since SiFive has been in an upward trend of success and hypergrowth.
Introducing the U8-Series - A Scalable Out-of-Order RISC-V CPU Core
Up until now, it’s been relatively unsurprising that if you’re designing a new CPU based on a new ISA, you first start out small and then iterate as you continue to add more complexity to your design. SiFive’s U5 and U7 series as such have been relatively more simplistic in-order CPU microarchitectures. While offering functionality and being very cost-effective options and alternatives compared to Arm’s low-end and microcontroller cores, they really weren’t up to the task of more complex workloads that needed more raw performance.
The new U8-Series addresses these concerns by massively improving the performance that can be delivered by the new microarchitecture – outpacing the U54 and U74 by factors of up to 5-4x, a quite significant performance jump that we don’t usually see very often in the industry.
The new CPU IP’s performance promises to vastly expand SiFive’s and the RISC-V’s ecosystem viability in end-point products, and really be able to offer alternatives to the embedded Arm products in the world today and in the future.
SiFive’s design goals for the U8-Series are quite straightforward: Compared to an Arm Cortex-A72, the U8-Series aims to be comparable in performance, while offering 1.5x better power efficiency at the same time as using half the area. The A72 is quite an old comparison point by now, however SiFive’s PPA targets are comparatively quite high, meaning the U8 should be quite competitive to Arm’s latest generation cores.
Post Your CommentPlease log in or sign up to comment.
View All Comments
AshlayW - Saturday, November 2, 2019 - linkThanks for the read :) very informative
hecksagon - Sunday, November 3, 2019 - linkA bit of research shows that Intel, AMD, and all the major ARM SOC vendors are using SRAM for all cache. Intel does use some DRAM in its Iris Pro graphics, which can be used by the CPU cache.
peevee - Tuesday, November 5, 2019 - link"The registers and such aren't static though"
They absolutely are.
name99 - Wednesday, October 30, 2019 - linkI'd put it differently.
Pragmatism equals design wins, and I see ARM as the most pragmatic company out there.
Intel insisted on x86 uber alles, even where it made no sense (Larrabee, mobile) and paid the price.
RISC-V has insisted on a certain kind of intellectual purity that makes no sense in terms of commerce, or the future properties of CPU manufacturing (plentiful transistors).
ARM on the other hand, has always done a really masterful job of adding enough new functionality to get what they need at not too much cost, of changing the ISA when appropriate (but not too often), of accepting that some markets (like ARM-M) need different types of vector/DSP extensions from what's appropriate for ARM-A.
bji - Wednesday, October 30, 2019 - linkBut this is not the MIPS ISA. It's a new ISA. Why are you mentioning MIPS?
name99 - Wednesday, October 30, 2019 - linkIt feels very much like MIPS. (Since it comes from much the same people, substantially [too much so, IMHO] unchanged in those beliefs since the 1980s.)
Wilco1 - Wednesday, October 30, 2019 - linkIt's a MIPS variant indeed. This is why it's so funny when people try to claim it's a modern ISA - it's literally based on 80's RISCs. Same people, same minimalistic approach to reducing instructions at the cost of larger codesize and lower performance. No lessons learnt from MIPS...
bji - Wednesday, October 30, 2019 - linkARM is literally 80's RISC too. What is your point? That nobody who have designed an ISA in the past can make a better ISA in the future?
Wilco1 - Wednesday, October 30, 2019 - linkMy point is it's the same people repeating the exact same mistakes. It has the same issues as MIPS like no register offset addressing or base with update. Some things are worse, for example branch ranges and immediate ranges are smaller than MIPS. That's what you get when you're stuck in the 80's dogma of making decode as simple as possible...
Arm never did things like the other RISCs. Is it possible to learn and do better today? Sure, look at AArch64 for example.
name99 - Thursday, October 31, 2019 - linkThat's an exceptionally silly riposte. Are you unaware that ARM has constantly evolved their instruction set, not just tweaks but experimenting with substantial changes (like Thumb and Thumb2)?
There is a HUGE amount of learning that informed ARMv8, from the dropping of predication and shifting everywhere, to the way constants are encoded, to high-impact ideas like load/store pair and their particular version of conditional selection, to the codification of the memory ordering rules.
Look at SVE as the newest version of something very different from what they were doing earlier.