SiFive's New RISC-V Chip Challenges Decades-old Computing Designs (cnet.com) 33
The Performance P650 won't beat a top-end Arm chip in a Samsung or Apple smartphone, but the startup believes its designs eventually could. From a report: It's really hard to get a new chip family to catch on when companies like Intel and Qualcomm ship their products by the millions, but SiFive has a faster new design it hopes will carve a niche. The startup on Thursday announced its Performance P650 design, which comes with a 50% speed boost over the P550 that arrived in June. SiFive is one of the most prominent members of RISC-V International, an alliance collectively developing a family of processors using the new RISC-V architecture. That competes against the x86 architecture from Intel and AMD that dominates in PCs and the Arm architecture used by Qualcomm, Samsung, Apple, MediaTek and others to power all smartphones. Unlike x86 and Arm, though, RISC-V is free to use. It's a fresh start its advocates believe will be more economical and efficient.
SiFive doesn't make chips. Instead, it licenses its designs to others that customize them for their own purposes, an approach that's served Arm well. With performance comparable to Arm's two-year-old midrange Cortex A77 design, the P650 won't be ejecting Qualcomm or other Arm designs out of smartphones any time soon. Customers can start evaluating the design in the first quarter of 2022, SiFive said. But if SiFive succeeds with its longer-term plans for better speed, battery life and cost, you could get a SiFive powered phone in a couple years. "By 2023, you're likely to see the first mobile phone with RISC-V," SiFive Chief Executive Patrick Little said in an October interview. "I think we have an excellent shot at the phone."
SiFive doesn't make chips. Instead, it licenses its designs to others that customize them for their own purposes, an approach that's served Arm well. With performance comparable to Arm's two-year-old midrange Cortex A77 design, the P650 won't be ejecting Qualcomm or other Arm designs out of smartphones any time soon. Customers can start evaluating the design in the first quarter of 2022, SiFive said. But if SiFive succeeds with its longer-term plans for better speed, battery life and cost, you could get a SiFive powered phone in a couple years. "By 2023, you're likely to see the first mobile phone with RISC-V," SiFive Chief Executive Patrick Little said in an October interview. "I think we have an excellent shot at the phone."
and to be fair (Score:1, Offtopic)
thank you msmash for a posting something salient and worthy of /. lineage
no mention of strife nor politics nor class warfare nor faux moral outrage; remember, we all can get that shite from just about anywhere these days; it's nice to visit /. and get back to why most of us came here in the first place
Re: (Score:3)
I came for the dating tips. You?
Re:and to be fair (Score:4, Insightful)
I came for the dating tips. You?
I came for Natalie Portman to make me Hot Grits.
Re: (Score:2)
the winner!
Re: (Score:2)
I came for the dating tips. You?
I fell for Slashdot's scam, offering, "Nudes for Nerds."
Re: and to be fair (Score:2)
Re: (Score:2)
Irony's not your strong suit, I take it.
I'm not happy with the vector instructions (Score:2)
RISC-V's design decisions for vector and floating point seems good for a microcontroller and multimedia processors. But it does compromise on the performance scalability side [wikipedia.org], and I'm skeptical that it can really make it into high performance computing, at least with the current RISC-V standard. I expect the winners of RISC-V in the data center will be a chip that has a vector coprocessor instead of standard RISC-V design. Even so, without good branch prediction the failed predictions will pay a heavy price
Re: (Score:2)
Might be useful to a certain Chinese company denied the current tech.
Re: (Score:2)
When People's Liberation Army walks into Taiwan they can have their pick of cutting edge Western tech. And the CCP won't even pretend to ask for permission to use it domestically.
Re: (Score:3)
Re: (Score:2)
Well as demonstrated by certain centrifuges software can damage hardware so it's possible to go beyond that especially for such delicate equipment.
Re: (Score:2)
ASML's EUV equipment is maintenance intensive requiring service and support on the basis of months, so even under ideal conditions were the factory and workers are taken completely intact, it will shortly become inoperable.
Re:I'm not happy with the vector instructions (Score:5, Interesting)
RISC-V's design decisions for vector and floating point seems good for a microcontroller and multimedia processors. But it does compromise on the performance scalability side [wikipedia.org], and I'm skeptical that it can really make it into high performance computing, at least with the current RISC-V standard.
this is pretty much spot-on with the general consensus, that yes, RISC-V is fantastic for commercial embedded uses (Western Digital SSDs/USB sticks, Trinamic's fantastic high-current Stepper ICs were amongst the very first commercial deployments). there's a particularly good technical analysis and rebuttal of the original design decisions: https://news.ycombinator.com/i... [ycombinator.com]
* compression makes multi-issue extraordinarily complex, and "macro-op fusion" even more so. these assumptions raise the bar to unacceptably-high levels (development costs wise) in order to compensate for.
* the lack of Condition Registers (Carry, LE/GE/EQ) was what caused the Loongson (China ICT MIPS64) x86 emulation to have to use **TEN** MIPS64 instructions to emulate one single x86 branch.
* the lack of condition codes places pressure on the integer regfile. the use of integer registers for FP comparisons places *even more* pressure on the integer regfile.
* the lack of LDST-with-update and LDST-shifted results in severe penalties (triple the number of instructions) in hot-loops
and the thing is: *none of these things can be corrected* without basically throwing away the entire ISA and starting again because there isn't enough free encoding space to add fixes retrospectively. even if they did it would be an incompatibility nightmare - basically you'd have to call it RISC-VI and start again.
the Power ISA has 240 or so instructions in the base scalar set where RV64GC has only 90, but Power ISA has Condition Codes and LDST-with-update, already (interestingly it doesn't have LDST-shifted).
in the research paper that inspired that ycombinator thread, the Alibaba team only managed to exceed ARM performance by drastically extending RISC-V with a massive 40+ extra instructions - in an *unauthorised*, rogue "custom" way - that, if it became popular mass-volume programmable (de-facto ubiquitous) would completely dominate the "custom reserved" opcodes, force gcc upstream to accept the patches made, and at that point it's goodbye custom opcodes... *by following the rules set down by the RISC-V Foundation*. then, the next vendor does the exact same thing and you've got the Altivec ISA conflict nightmare which plagued the Power ISA 15 years ago, all over again.
and there's *nothing that can be done about it*, because both parties are "obeying the rules" laid down by the RISC-V Foundation by creating "custom opcodes": the pressure comes from *users* - software developers - complaining about how they have to use some silly "unauthorised" version of gcc that's not "permitted" to be upstream [because it uses custom non-standard opcodes] and how they are forced to either choose between using some rogue unauthorised version of gcc on an arbitrary unofficial website, or that their software suffers severe performance penalties when compiled with the "standard" version of gcc that knows nothing of the custom (rogue) instructions.
i warned the RISC-V Foundation about this potential situation multiple times. i did not receive a response.
I expect the winners of RISC-V in the data center will be a chip that has a vector coprocessor instead of standard RISC-V design.
yes but it triples the number of instructions from around 90 in RV64GC by adding a massive 190 extra operations. and still doesn't have Condition Codes.
Re: (Score:2)
Ah yes, Condition Codes, a foundational concept of RISC design. Funny how it stops being cruft when there's work to be done.
Sounds like Open Source is really proving it's worth here.
Re: (Score:2)
Condition Codes are inelegant. It's extra state that carried between instructions and isn't represented as a general purpose register. Often produced as a side-effect of another operation. Of course if you write an ordinary program, then you want state to carry over between instructions and you like that more than one thing can happen in a single instruction. oops!
One "clean" way to deal with it is instead of having 64-bit general purpose registers you have say 70-bits or whatever. With a 64-bit data field
Re: (Score:2)
Condition Codes are inelegant. It's extra state that carried between instructions and isn't represented as a general purpose register. Often produced as a side-effect of another operation.
in the Libre-SOC design, where we are moving incrementally towards a full multi-issue out-of-order engine, i take the unusual step of treating 4-bit Power ISA Condition Register Fields as actual complete, separate and distinct registers, even though they are 4 bits. this then allows them to have their own dedicated entries in the Dependency Matrices, their own distinct Read-after-Write and Write-after-Read Hazard protection.
consequently, Power ISA Branch-Conditional instructions which depend on thoes CR Fi
Re: (Score:2)
Condition Codes are inelegant. It's extra state that carried between instructions and isn't represented as a general purpose register.
apologies for follow-up posting on this: i feel like i missed out something important, here.
in RISC-V the only way to do integer comparisons is to perform a subtract (an integer instruction). if you have multiple conditions to combine, you must either do it as multiple BEQ/BNE/BLT operations (which puts pressure on the Branch Prediction Unit) or you have to use integer-subtracts followed by integer logical operations (which puts pressure on the Integer regfile, using only 1-2 *actual* bits of precious 64-b
Re: (Score:2)
One "clean" way to deal with it is instead of having 64-bit general purpose registers you have say 70-bits or whatever. With a 64-bit data field and some condition codes for the last operation to write that register. No magic flags floating around, and you can pipeline and interleave operations at compile time. I don't think anyone does this today, probably more common in the mainframe era (before my time).
I have proposed the same thing several times now for stateful condition condition codes like carry and overflow. If the condition codes are stored in a separate parallel register file, then they can remove access pressure from the regular register file. There are not many per register so the entire set might be aggregated into a single conditions code register as far as saving state.
I think Power does it but with a limited number of condition code registers (4?).
Re: (Score:2)
As you read though the RISC-V ISA specification, a few phrases you hear a lot are, "we considered but did not use...", usually followed by, "too complex." Right from the onset, it appears the primary goal of the design is to be as dirt cheap as possible for the embedded market, but not very robust. I was quite disappointed.
If that's the only way they can get their foot in the door, then from a marketing perspective that's not a bad thing. However, I don't expect to find RISC-V in a "real" computer for a
Re: (Score:2)
Re: (Score:2)
microcontroller is really a processor + peripherals. that extra stuff is what makes it appropriate for one application versus enough. There are fairly good general purpose uCs out there. But to get something that ticks enough boxes for most of the industry you'd need a automotive/industrial temp range Cortex-Mx (like one of the STM32). with a medium amount of SRAM and flash ( 8k/128k? maybe more). A generic design ends up being expensive in volume.
thinko (Score:2)
s/enough/another
laughable (Score:2)
"I think we have an excellent shot at the phone."
No they don't. They DO have an excellent shot at getting this processor into general embedded applications though.
But that's not what the investors want to hear, they want to know that the designs are going to be licensed in the billions.
Thinking that people are just going to stop using Qualcomm or some other mainstream vendor in phones and pick up sifive is not even remotely reasonable.
This guy is lying and he knows he his.
Does he think Qualcomm or vendor X
Re: (Score:2)
Well, they do have an excellent shot at 'controller' applications, like autos, and that is where the billions come.
I, for one, welcome our open-source microprocessor overlords, And I expect to work with one as soon as it's practical for me, and to enjoy a future where CPU options expand and breed innovation at an even greater rate.
The naysayers have their place, You'll see them back there.
Re: (Score:2)
"... CPU options expand and breed innovation at an even greater rate."
How does more CPU options "breed innovation", particularly when the entire exercise is to have one new architecture catch up to existing ones that satisfy the market now?
It would appear that, reading the few comments here, innovation is not being bred.
Re: (Score:2)
It would appear that, reading the few comments here, innovation is not being recognized. ARM wasn't a performance solution early on, and behold, it's trying to solve all problems - speed, power, flexibility. Watch. I expect to see RISC-V coming out of the big boys, especially those who missed the mobile revolution the first few times around. It's early.
Re: (Score:2)
Innovation does not only happen in the biggest, fastest chips.
You misunderstood the discussion above about high end scientific computing. Entirely.
In robotics engineering (and embedded generally) it is often a feature not to be good at branching and condition codes, because with branching the number of instructions executed changes with the data values and there is a lot of extra work adding NOPs all over.
If it goes into a phone, obviously it wouldn't be a Super Appity-App phone that is running lots of thre
Re: (Score:2)
In embedded generally, most of the desired innovation right now is in decreased power consumption, not increased speed.
fascinatingly and paradoxically this is an area where Cray-style Vectors are a boon. there's an excellent article which goes through a comparative analysis vs SIMD: https://www.sigarch.org/simd-i... [sigarch.org]
what *isn't* really highlighted is the knock-on consequences of the reduction in the number of instructions needed, and of course that's: Power Consumption.
by reducing the number of instructions needed to process data - which was the big advantage of Cray-style Vectors - the pressure is greatly reduced on the In
Re: (Score:2)
your instructions *think* they're executing multiple Vector Elements in parallel
This is exactly the sort of throughput hack that I don't want in my workloads.
And it is a huge strength for RISC-V that I don't have to jump through hoops, I can just use straightforwards code. The "right way" is already the correct way.
ARM does just fine here, but only if the programmer knows to ignore the "right way" and follow the local style guide.
With RISC-V the ASM is almost as easy to write as the C when you're counting cycles.
Re: (Score:2)
If you managed to read the summary you'd have found out that he didn't say this chip would be in phones, he said that one of the next few generations might make it into phones.
This guy is lying and he knows he his.
You don't even know what he said, but you know what he knows? Durrr
Arm (Score:3)
Re: (Score:2)
Well MIPS and Propeller is still out there.