SiFive Announces First RISC-V OoO CPU Core(anandtech.com)
anandtech.com
SiFive Announces First RISC-V OoO CPU Core
https://www.anandtech.com/show/15036/sifive-announces-first-riscv-ooo-cpu-core-the-u8series-processor-ip
51 comments
The RISC-V ISA was made with some hindsight of what choices makes it easy to optimize for OoO superscalar CPUs. If I remember correctly, that's one of the reasons everyone jumped ship from OpenRISC to RISC-V (the big mistake in OpenRISC being branch delay slots I believe)
It might also help starting from scratch.
I'm also not convinced it's entirely an apples-to-apples comparison. ARM might support more complex instructions that their core don't, and the ARM core might have features like TrustZone.
It might also help starting from scratch.
I'm also not convinced it's entirely an apples-to-apples comparison. ARM might support more complex instructions that their core don't, and the ARM core might have features like TrustZone.
OpenRISC also has divide overflow exception and integer overflow exceptions. Both are generally avoidably with the "exception with code" instruction, some little condition checking and some small compiler work.
MIPS, for instance, does not have divide overflow exception. It uses compare, conditional branching and "exception with exception code" instruction.
Most of the time (int32_t/int32_t) division is safe, because divisor is checked for zero in the code logic somewhere else and guaranteed to be non-zero. Sometimes (int64_t/int32_t) it is not safe (higher word is divident can be bigger than divisor) and checking code must be executed in run time. And execution overhead is so little that it is quite good design choice.
You don't have hardware that drains energy constantly for slight slowdown for code that is rare.
As far I can remember, RISC-V does not have divide overflow exception.
As a rule of thumb: if you can put something into software, please do (overflow checks, code scheduling instead of delay slots). Hardware is for things where software can't help (branch prefetch, out of order, etc).
MIPS, for instance, does not have divide overflow exception. It uses compare, conditional branching and "exception with exception code" instruction.
Most of the time (int32_t/int32_t) division is safe, because divisor is checked for zero in the code logic somewhere else and guaranteed to be non-zero. Sometimes (int64_t/int32_t) it is not safe (higher word is divident can be bigger than divisor) and checking code must be executed in run time. And execution overhead is so little that it is quite good design choice.
You don't have hardware that drains energy constantly for slight slowdown for code that is rare.
As far I can remember, RISC-V does not have divide overflow exception.
As a rule of thumb: if you can put something into software, please do (overflow checks, code scheduling instead of delay slots). Hardware is for things where software can't help (branch prefetch, out of order, etc).
> The RISC-V ISA was made with some hindsight of what choices makes it easy to optimize for OoO superscalar CPUs.
ARM's 64-bit architecture (AArch64) was also made with similar hindsight, so that's probably not the whole reason.
ARM's 64-bit architecture (AArch64) was also made with similar hindsight, so that's probably not the whole reason.
Most AArch64 cores still have to support AArch32 modes, and so aren't allowed to take advantage of those optimizations.
Considering binary compatibility is not a huge issue in the ARM space (at least not as huge as it is in x86) it seems more like a design choice - it's perfectly reasonable to have a CPU part that is aarch64 and knows nothing about the 32-bit ARM ISA
For the bigger ARM cores it is a huge issue. They're pretty much just used inside phones and compatibility with everything in the app store is an extremely important component of their requirements.
It depends.
Most software for Android is not native. My current phone can't run some applications I bought on my Motorola Droid even though I doubt they have one single line of native code. Those applications also don't show up on the Google Store (at least on my phone), so nobody will get them anyway. I had one x86 phone in the meantime, and I didn't see any compatibility issues.
As for the other player in town, Apple, they design everything, silicon, OS and SDK and operate the only application store you can publish to, so, for them, this is also something that can be easily controlled.
Most software for Android is not native. My current phone can't run some applications I bought on my Motorola Droid even though I doubt they have one single line of native code. Those applications also don't show up on the Google Store (at least on my phone), so nobody will get them anyway. I had one x86 phone in the meantime, and I didn't see any compatibility issues.
As for the other player in town, Apple, they design everything, silicon, OS and SDK and operate the only application store you can publish to, so, for them, this is also something that can be easily controlled.
Almost all games are native. Games are what generate the most microtransactions, and are an extremely important component of the app store from a revenue perspective.
And even Apple, who as you said has easily the most control of their ecosystem, is rumored to go to only AArch64 on their next gen chips. They want to move that way, but even they know the issues with moving that direction too fast.
The x86 chip was relying on a process node advantage in order to have a more intelligent memory subsystem that their competitors, to allow them to emulate AArch32 perfoantly compared to their competitors. That process node advantage is now gone and that option isn't available to x86 (and x86 disappeared from the phone market as soon as the writing on the wall was apparent there).
And going back to original point, AArch32 is an albatross around the neck of OoO core design. Features like making nearly every instruction conditional, the restartable load/store multiple instructions, the instruction decoder is almost as complex as x86 (there's almost 1200 instructions in AArch32), instructions can straddle cache line and page boundaries, etc. heavily complicate OoO designs.
Additionally, the one niche that wants powerful cores and isn't dependent on backwards compatiblity (servers), has seen AArch64 only chips.
And even Apple, who as you said has easily the most control of their ecosystem, is rumored to go to only AArch64 on their next gen chips. They want to move that way, but even they know the issues with moving that direction too fast.
The x86 chip was relying on a process node advantage in order to have a more intelligent memory subsystem that their competitors, to allow them to emulate AArch32 perfoantly compared to their competitors. That process node advantage is now gone and that option isn't available to x86 (and x86 disappeared from the phone market as soon as the writing on the wall was apparent there).
And going back to original point, AArch32 is an albatross around the neck of OoO core design. Features like making nearly every instruction conditional, the restartable load/store multiple instructions, the instruction decoder is almost as complex as x86 (there's almost 1200 instructions in AArch32), instructions can straddle cache line and page boundaries, etc. heavily complicate OoO designs.
Additionally, the one niche that wants powerful cores and isn't dependent on backwards compatiblity (servers), has seen AArch64 only chips.
I doubt their numbers are correct. They've fudged them in the past, giving area numbers for the smallest configuration, but performance number for a ridiculously large chip.
The A72 supports at least three completely different instruction sets (A64, A32, T32), which has a cost. You could make a much sleeker A64-only CPU core as Apple, Cavium, and Fujitsu do, though it's still not going to be as sleek as RISC-V.
> it's still not going to be as sleek as RISC-V
Why? A64 is a completely new design, and unlike RISC-V, by people who've been doing it a while professionally and successfully
Why? A64 is a completely new design, and unlike RISC-V, by people who've been doing it a while professionally and successfully
I wonder if that's comparing the non-vector U84 against the A72 with Neon.
It will be, yes, and the U87 with a vector unit will obviously be a bit bigger. There are many applications where a vector unit is unnecessary silicon that adds nothing but cost and power consumption.
7nm instead of 16nm probably helps a lot.
> A lot of the performance increases of the U8-series come thanks to the increased frequencies capabilities which are 1.4x higher this generation, with the core scaling up to 2.6GHz on 7nm.
Pretty cool that these chips are approaching performance parity so quickly.
Pretty cool that these chips are approaching performance parity so quickly.
"IP Core" in semi industry terminlogy means a bunch of RTL that is offered for licensing, so this is not yet a working chip.
God I hate that term. It's not your secret sauce intellectual property, it's a fucking library.
Possibly the biggest reason FPGA/ASIC tech has lagged so hard behind CPU/GPGPU in terms of consumer use is because they have managed to use their hardware to completely stifle all open source software (they even go to some lengths to distance themselves from the term "software"). FPGA libraries are almost always encrypted and have to be treated as a true black box when designing. Doing things as mundane as interacting with a PCIe bus or simple signal filtering are all locked away behind ludicrously overpriced "IP" packages that are often vendor specific.
Possibly the biggest reason FPGA/ASIC tech has lagged so hard behind CPU/GPGPU in terms of consumer use is because they have managed to use their hardware to completely stifle all open source software (they even go to some lengths to distance themselves from the term "software"). FPGA libraries are almost always encrypted and have to be treated as a true black box when designing. Doing things as mundane as interacting with a PCIe bus or simple signal filtering are all locked away behind ludicrously overpriced "IP" packages that are often vendor specific.
Interacting with a PCIe bus does not seem "mundane" to me. Analog electronics is hard, and, just as importantly, process-specific (and the details of any one process are generally kept strictly confidential to the fab, with tightly-binding NDAs). Now, when it comes to pure digital logic I agree, but that's also where open hardware (with meaningful contributions by SiFive themselves) has been most successful.
The analog parts of PCIe interfaces are not programmable. The artificially black boxes we are talking about are purely digital. They use fixed resources but we are not asking for the design of those parts.
Hell, I'm glad Symbiflow[0] exists. Once the toolchain is a little more mature, a library of modules with OSHW licenses is bound to pop up, perhaps even integrated into some sort of IDE.
[0] https://symbiflow.github.io/
[0] https://symbiflow.github.io/
Why can't a library be IP?
IP means nothing. It's a poorly defined conglomerate of vastly different laws, like about brands, patents, models, etc.
A library is typically "protected" (that is: artificially restricted) by copyright, and the situation is then blurry but in some cases also patents (depending on the region of the world and/or good lawyers knowing the magic words to patent non-patentable things) and trade secrets.
A library is typically "protected" (that is: artificially restricted) by copyright, and the situation is then blurry but in some cases also patents (depending on the region of the world and/or good lawyers knowing the magic words to patent non-patentable things) and trade secrets.
I think this may be more than a register-level transfer abstraction. The slides make claims about die area and frequency, and show a layout.
SiFive offer IP but also produce SoCs (presumably with TSMC, SMIC, and GlobalFoundries, who are listed as partners).
SiFive offer IP but also produce SoCs (presumably with TSMC, SMIC, and GlobalFoundries, who are listed as partners).
"IP core" can mean "soft IP", which is just RTL, or "hard IP", which is a full layout (set of mask layers), ready to put on silicon. I haven't read the SiFive announcement closely, but if they're quoting area/frequency/power numbers, it would most likely be the latter.
Interestingly, although all the RTL for the SiFive Freedom platform is in the SiFive's GitHub repository, and they've produced chips and boards (with public schematics and BOM), the hard IP doesn't appear to be public.
I wonder if this is because the hard IP is specific to the fabs' trade secret tooling, and so subject to their NDAs, making it impossible to distribute publicly.
I wonder if this is because the hard IP is specific to the fabs' trade secret tooling, and so subject to their NDAs, making it impossible to distribute publicly.
You're on point with the second paragraph. I only know of one chip fab that has it's design rules public, and they're an open source fab running out of HKUST that'll give you about Arduino level gate counts.
Why can't a fab with something like 28nm use public design rules? I guess there aren't valuable trade secrets still in a process that old. But some chips can usably be made on such a process.
There's a lot of mixed-signal specialty ASICs at the 350 nm and 180 nm nodes. As long as you don't need the density, it's a great option. Masks are relatively cheap and the processes are dialed in extremely well at this point. Just because the tech is 20-30 years old doesn't mean it's not useful.
There's absolutely valuable trade secrets even at 28nm. For starters, a fab's work at 28nm would absolutely inform descions on newer nodes. Additionally, the older nodes don't just shut down their lines, but are dependent on continued use to pay off their massive capital investment. They're still competing with the other 28nm fabs.
I wish one of them would just try and release a 180nm process in a way that allows public domain maskset distribution.
If it flops, so be it; if not, many people like myself can suddenly start hacking on analog or mixed IC designs for potentially exotic things, like analog-computer-based UAV controllers that integrate the control loop with e.g. external feedback like simple doppler/chirp radar to reach microseconds of feedback latency and thus enabling monolithic closed-loop control.
A miniaturized version of https://www.research-drone.com/en/ with the blade's counterweight being a single neodymium magnet in an outrunner configuration and a ferrite stator fabricated using SMD inductor technology to target the 5g (+ payload + battery) UAV class would be interesting, but the ~3KHz (typical disc loading and high subsonic tip speed) rotation rate (~200k rpm) make software control of the motor driver difficult.
If it flops, so be it; if not, many people like myself can suddenly start hacking on analog or mixed IC designs for potentially exotic things, like analog-computer-based UAV controllers that integrate the control loop with e.g. external feedback like simple doppler/chirp radar to reach microseconds of feedback latency and thus enabling monolithic closed-loop control.
A miniaturized version of https://www.research-drone.com/en/ with the blade's counterweight being a single neodymium magnet in an outrunner configuration and a ferrite stator fabricated using SMD inductor technology to target the 5g (+ payload + battery) UAV class would be interesting, but the ~3KHz (typical disc loading and high subsonic tip speed) rotation rate (~200k rpm) make software control of the motor driver difficult.
When you are selling IP like this you would need to do your own physical design due diligence, even if the deliverable is just some Verilog code.
IP cores are sometimes deployed on FPGAs though, so that can be a working chip (depending on definitions).
I wasn't sure what OoO stood for and since they never mentioned it in the article I had to look it up. For anyone else who is asking the same question.
OoO = out of order execution
OoO = out of order execution
It’s actually mentioned in a header after the third paragraph in the article...
Yeah, I saw that later on when I continued reading. I did a Find on the page and was looking for "ooo" and didn't find anything like "order of order (ooo)" because it's customary to define it when it is first used.
I’m right there with you!
I’ve been doing embedded hardware and CE work for 15 years non-stop, and had no idea what OoO meant.
Kept thinking “on a”. As in SoC or PoC.
I’ve been doing embedded hardware and CE work for 15 years non-stop, and had no idea what OoO meant.
Kept thinking “on a”. As in SoC or PoC.
A Raspberry Pi type SBC based on this would be neat, is that something we can expect to see any time soon in light of this announcement or is that not an application this is really aimed at?
That would be neat, and would come out somewhere similar to a Pi 4 (which are pretty awesome).
Note that the Pi 4 has ARM processor cores, but ARM doesn't make either the processor chip or the board. Broadcom design and make the BCM2711 SoC, and the Raspberry Pi Foundation designed and manufactures the board.
No doubt SiFive would be very happy to work with someone who wanted to make retail SoCs and/or SBCs using the U84, but as with ARM it's not really their business model to do that themselves.
SiFive has made several low-volume chips and boards for potential core IP customers to use for evaluation and development e.g. the $999 HiFive Unleashed. ARM similarly offers a $10000 dev board for the A72.
Note that the Pi 4 has ARM processor cores, but ARM doesn't make either the processor chip or the board. Broadcom design and make the BCM2711 SoC, and the Raspberry Pi Foundation designed and manufactures the board.
No doubt SiFive would be very happy to work with someone who wanted to make retail SoCs and/or SBCs using the U84, but as with ARM it's not really their business model to do that themselves.
SiFive has made several low-volume chips and boards for potential core IP customers to use for evaluation and development e.g. the $999 HiFive Unleashed. ARM similarly offers a $10000 dev board for the A72.
This is most likely to come from lowrisc[0] instead.
[0] https://www.lowrisc.org/
[0] https://www.lowrisc.org/
Have we gotten confirmation yet on whether this is a BOOM core or not? It certainly feels like it is
Is there a risc-v chip on the market which includes Bluetooth?
Espressif is planning a RISCV based ESP32 upgrade, it'll probably will have Bluetooth. No schedule yet.
Usually Bluetooth modules are add-on peripherals, unless I'm mistaken.
This is very a big statement. It's hard for me to think of how they do that, when 8th gen ARM cores are said to be blowing just anything else on size/performance ratio.
Where does SiFive get such an expertise in size optimisation?