Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

SiFive Announces First RISC-V OoO CPU Core

anandtech.com

Post reply on HN
Print view View original

41–50 of 52 posts

Re: SiFive Announces First RISC-V OoO CPU Core

#41

Post by dmitrygr »

brucehoult wrote: post #32
baybal2 wrote: post #8

> 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. 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 SiF…

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

Re: SiFive Announces First RISC-V OoO CPU Core

#42

Post by yhvh »

aneutron wrote: post #30
arcticbull wrote: post #24

Earlier quoted context omitted.

Usually Bluetooth modules are add-on peripherals, unless I'm mistaken.

Exactly what I was thinking when I read the parent at first, but I'm assuming the parent is asking about all-in-on SoC chips.

Indeed I was

Re: SiFive Announces First RISC-V OoO CPU Core

#44

Post by temac »

zozbot234 wrote: post #33
AWildC182 wrote: post #22

Earlier quoted context omitted.

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…

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.

Re: SiFive Announces First RISC-V OoO CPU Core

#45

Post by temac »

fwip wrote: post #27
AWildC182 wrote: post #22

Earlier quoted context omitted.

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…

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.

Re: SiFive Announces First RISC-V OoO CPU Core

#46

Post by rbanffy »

monocasa wrote: post #31
cesarb wrote: post #15

Earlier quoted context omitted.

> 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.

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

Re: SiFive Announces First RISC-V OoO CPU Core

#47

Post by monocasa »

rbanffy wrote: post #46
monocasa wrote: post #31

Earlier quoted context omitted.

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.

Re: SiFive Announces First RISC-V OoO CPU Core

#48

Post by rbanffy »

monocasa wrote: post #47
rbanffy wrote: post #46

Earlier quoted context omitted.

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.

Re: SiFive Announces First RISC-V OoO CPU Core

#49

Post by monocasa »

rbanffy wrote: post #48
monocasa wrote: post #47

Earlier quoted context omitted.

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, App…

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.

Re: SiFive Announces First RISC-V OoO CPU Core

#50

Post by namibj »

monocasa wrote: post #29
wolf550e wrote: post #19

Earlier quoted context omitted.

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 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.

Post reply on HN