Live data from Hacker News

SiFive Announces First RISC-V OoO CPU Core

anandtech.com

21–30 of 52 posts

Re: SiFive Announces First RISC-V OoO CPU Core

#21
post #14

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

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.

Re: SiFive Announces First RISC-V OoO CPU Core

#22
post #2

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

Re: SiFive Announces First RISC-V OoO CPU Core

#26
post #11
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 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 instr…

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

Re: SiFive Announces First RISC-V OoO CPU Core

#27
post #2

"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…

Why can't a library be IP?

Re: SiFive Announces First RISC-V OoO CPU Core

#28
post #10
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…

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.

Re: SiFive Announces First RISC-V OoO CPU Core

#29

Earlier quoted context omitted.

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

Re: SiFive Announces First RISC-V OoO CPU Core

#30
post #23

Is there a risc-v chip on the market which includes Bluetooth?

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.
Post reply on HN