[HN Gopher] RISC-V is succeeding
___________________________________________________________________
RISC-V is succeeding
Author : PaulHoule
Score : 296 points
Date : 2022-03-01 15:05 UTC (7 hours ago)
(HTM) web link (semiengineering.com)
(TXT) w3m dump (semiengineering.com)
| coliveira wrote:
| Apple has demonstrated that is possible to run x86 software in
| another architecture without any major loss of computing power.
| This has opened the possibilities not only for ARM-based designs,
| but for RISC-V and others as well. I believe that architectures
| like x86 and ARM will be a thing of the past in the next few
| years as companies move to produce chips that suits their needs
| instead of paying royalties to Intel or ARM.
| beagle3 wrote:
| Apple added non standard ARM extensions to make that possible.
| It could be done in other arch's but it doesn't come for free.
| vineyardmike wrote:
| > Instead of paying royalties to Intel or ARM.
|
| I totally expect intel to offer a RISC V chip in the next
| decade. Made by them, competing with ARM for low power.
| r00fus wrote:
| I totally don't, unless they can create a nice moat. Intel
| doesn't play well if it can't prevent others from playing in
| its space.
|
| Perhaps they'll try to do another WinTel combo with RISC-V?
| Sounds like MS can just do it on their own.
| UltraViolence wrote:
| RISV-V will succeed because countries like China, India and
| Russia need a CPU ISA that isn't directly or indirectly
| controlled by the U.S. government.
|
| Somehow, they're also too stupid to roll their own.
| fuoqi wrote:
| It will succeed even further after China solves its fab issues.
| Considering how the West overplays the technological sanctions
| card, many countries will jump on this bandwagon as soon as
| RISC-V solutions will be more or less competitive. We already can
| see it in the embedded space (even Russia has a sizable stake in
| RISC-V) and I expect we will see reasonable high-end solutions in
| 5-10 years.
| klelatti wrote:
| Key quote from an excellent and well balanced article.
|
| > I don't believe the success of RISC-V is because it is cheap or
| lower cost. If you just want to do the same as you can get with
| an Arm core, you absolutely should just buy an Arm core because
| it's so well verified. It's so well designed. It's exactly what
| you want. The only reason for using RISC-V is because you want
| the freedom to change it and add your own things to it.
|
| RISC-V is great and important as an enabler of innovation and
| experimentation. As a like for like replacement for the cores in
| your smartphone less so.
| zozbot234 wrote:
| > RISC-V is succeeding MIPS
|
| Fixed it for you. But hey, it's not like there's anything wrong
| with that!
| Narishma wrote:
| Why was the title changed?
| krzyk wrote:
| Is there a platform similar to RPi but with a RISC-V cpu? (I
| don't care about gpu, so headless one, but with rj45 and few USB3
| ports would be great).
| miniwark wrote:
| SiFive did had one in the past (HiFive Unleashed). They still
| offer an Arduino like board for $59.
|
| See: https://www.sifive.com/boards/hifive1-rev-b
|
| The more RPi like one actually available, seems to be the
| Nezha, available on AlieExpress for around $99~170 (and on
| other places too)
|
| https://fr.aliexpress.com/item/1005002668194142.html
|
| A short review here: https://www.cnx-
| software.com/2021/05/20/nezha-risc-v-linux-s...
|
| And a extensive wiki page: https://linux-
| sunxi.org/Allwinner_Nezha
|
| Finally, there also seem to be a BeagleBoard (coming soon or
| vaporware?) in association with the chinese chip-maker
| starFive:
|
| https://beagleboard.org/static/beagleV/beagleV.html
| St_Alfonzo wrote:
| "Sipeed Nezha 64bit RISC-V" may fit.
| https://de.aliexpress.com/item/1005002856721588.html
| blacksmith_tb wrote:
| Kind of expensive though, its cousin[1] is more appealing to
| me, though I haven't ordered one yet.
|
| 1: https://www.aliexpress.com/item/1005003594875290.html
| goodpoint wrote:
| Sipeed Lichee RV. At around 28 euro with a dock it's pretty
| unbeatable. (For a RISC-V)
| rjsw wrote:
| How about the Starfive VisionFive [1]?
|
| [1] https://starfivetech.com/en/site/exploit
| sprash wrote:
| The AMD64/x86_64 ISA patents expire 2023. This makes RISC-V kind
| of pointless since x86 has a vastly superior ecosystem. I would
| prefer a solid x86 system without IME, Pluton, secret microcode,
| EFI cripple bootloader and all the other surveillance, anti-
| freedom crap over RISC-V any day.
| phendrenad2 wrote:
| The 32-bit x86 patents expired awhile ago, and no one has done
| anything with it (far as I can tell). It's just really hard to
| implement an x86 CPU, and there probably isn't much motivation
| when they're so ubiquitous and cheap already.
| zozbot234 wrote:
| AIUI, there's quite a few new x86 systems targeted at
| industrial/embedded use and retrocomputing. I've also heard
| of at least one modern core which implements i586.
| MayeulC wrote:
| x86_64 is much harder to implement though.
|
| The superiority of the ecosystem is debatable. I guess you
| mostly have proprietary software in mind? (including Microsoft
| Windows). That will improve with time.
| freemint wrote:
| There are reason why one would want to implement a RISC CPU
| over x86-64. Atleast as a small team. Another problem is that
| many application today assume the presence of atleast SSE if
| not AVX2 which have been around for longer then or almost a
| decade. A patent expired CPU will always have to play unless
| the architecture they clone was stopped being developed much
| (as SuperH was which J-Core based it's design on).
| sprash wrote:
| AMD64 contains everything up to SSE2. AVX2 only exists since
| 2015. I doubt many applications require it.
| hajile wrote:
| Do you have a source for that? The initial announcement was in
| 1999. Did they file for the patents later?
| humanwhosits wrote:
| I too remember when AMD and Intel simply gave up on filing any
| new patents in the early 2000s
| marcodiego wrote:
| Are there plans by any vendor to develop/implement/sell any
| reasonably powerful x86 processor without IME/PSP?
| userbinator wrote:
| It depends what you mean by "reasonably powerful" --- there
| are a handful of small Chinese companies with x86-cored SoCs,
| and of course this:
|
| https://news.ycombinator.com/item?id=25589081
| Pet_Ant wrote:
| What would it take for Apple to switch to making RISC-V CPUs? I
| mean wouldn't it mostly be a change in the instruction decode
| logic? Once you are inside the chip most conventional chips (eg
| not The Mill or many-core) basically the same logically?
| Macha wrote:
| They've already got a lot of licenses for ARM already set up as
| perpetual licenses, and a lot of expertise, and an already
| deployed ARM toolchain. So there's no reason for Apple to
| switch to Apple manufactured RISC-V over Apple manufactured
| ARM, and given how Apple got burned by Intel's stagnation from
| Sandy Bridge until Alder Lake, I'm not sure there's a run of
| success long enough for another company to convince Apple to
| drop their own control in the medium term future.
| Pet_Ant wrote:
| I meant specifically, besides rewriting the instruction
| decode unit, and maybe tweaking the memory access to meet
| some technicalities, what would be involved to taking the M1
| and making it support a different instruction set.
| dehrmann wrote:
| That has very little to do with Apple. What you're really
| asking is how hard would it be to add support to a CPU for
| a second instruction set.
| snvzz wrote:
| Not really worth pondering. Apple has enough funds to do it
| just as an experiment, without much care about cost.
| Lind5 wrote:
| Intel's support for RISC-V marks a technological and cultural
| shift https://semiengineering.com/which-processor-is-best/
| tombert wrote:
| Are there any RISC-V laptops on the market? I would love to get
| my hands on one if they're available.
| darksaints wrote:
| It can't succeed fast enough. I'm sick of space heaters posing as
| x86 laptops, and I refuse to voluntarily buy into the Apple
| ecosystem, even if they do some things well. How far away are we
| from competitive laptop/desktop quality RISC-V chips? It seemed
| like there were a few extension that everybody was waiting on,
| but now most of them are complete, and still haven't seen
| anything of substance.
| kllrnohj wrote:
| > I'm sick of space heaters posing as x86 laptops
|
| Then buy AMD? There's choices here, and AMD's laptop CPUs for
| the last few generations have been _very_ power efficient. See
| for example today 's Anandtech coverage of the latest Zephyrus
| G14: https://www.anandtech.com/show/17276/amd-ryzen-9-6900hs-
| remb...
|
| It's nonsensical to think that RISC-V will somehow fix this,
| since it's a heck of a lot more about execution quality than
| ISA (fine-grained clocking, power gating, sleep states, etc...
| as well as just an overall efficient cache & instruction
| execution design).
| sprash wrote:
| > space heaters posing as x86 laptops
|
| The instruction set has nothing to do with this. Apple has
| better numbers because it uses the most advanced manufacturing
| process.
| cultofmetatron wrote:
| > Apple has better numbers because it uses the most advanced
| manufacturing process.
|
| on the contrary, arm is a simpler isa to implement which
| means radically less circuitry for reading the instruction.
| modern Intel cpus go so far as having entire systems that
| translate external x86 instructions to an internal risc based
| one. That's a huge source of wasted power ie: heat.
| marcan_42 wrote:
| But it does. x86 is hell to decode in parallel, because it's
| variable length (and in a complex way), so Intel can't build
| CPUs that keep a wide pipeline fed with instructions
| efficiently like Apple can, with the 8-wide decoder in the
| M1. That's one of the things that makes the M1 special, and
| how it gets away with lower clocks and power consumption than
| competing x86 designs.
| userbinator wrote:
| Variable length doesn't matter that much, you just have
| something that has a wide shifter on the front. And
| instruction density is important because it saves cache. A
| single x86 instruction can take the place of several RISC
| ones, which is why they needed to have it decode so wide.
| The M1 is almost entirely a process advantage.
| jabl wrote:
| Current x86 as well as many Arm cores have micro-op caches,
| so they don't need as wide decoders as a design that
| doesn't have such a thing, like M1. (That doesn't take away
| from the fact that M1 is a very impressive design, of
| course)
| paulmd wrote:
| You can certainly argue that's because of other design
| choices (optimizing for high IPC at low clocks by trading off
| space/etc) but it's certainly not _just_ because of their
| manufacturing process. Both the A15 /M2 architecture and AMD
| Zen4 will be on TSMC N5P this year, it's pretty doubtful that
| AMD will be able to catch Apple in IPC or perf/watt imo.
|
| And AMD is currently the more "low clock/high IPC" of the two
| major x86 vendors, so they're the easiest comparison, Intel
| is really clock-focused still (see: today's Anandtech review
| comparing AMD 6000/Zen3+ against Alder Lake Mobile and note
| the power scaling numbers).
|
| https://www.anandtech.com/show/17276/amd-ryzen-9-6900hs-
| remb...
|
| Anyway Jim Keller's "I'm sure x86 isn't dead yet" aside, it
| seems undeniable that tweaking the instruction set to enable
| deeper reorder and scale the frontend wider should have
| performance benefits. Saying out-of-order depth doesn't
| matter is like saying that code density doesn't matter, or
| speculation depth doesn't matter. These are things that can
| be simulated, or measured on real-world code, I don't have
| numbers at-hand but it seems self-evident that there are
| metrics that those tweaks should improve on.
|
| It doesn't mean x86 is at the end of the line, but if you
| told me that a 50-year legacy ISA (even if it's been cleaned
| up a lot over the last 30) had maybe a 10-20% performance,
| perf/watt, or area/watt benefit due to "intentional design"
| (aka tuning to the task) and the knowledge of hindsight - I
| have no reason to doubt that as being facially untrue.
|
| 10-20% is still "competitive", so Keller isn't wrong, but it
| also still puts x86 at a disadvantage in the long term.
| That's a generation of memory (Zen3+ got 12% moving to DDR5)
| or most of an architectural generation or maybe a half-node
| step that x86 would have to stay ahead to maintain _parity_
| (not just competitiveness).
| jabl wrote:
| This article suggests that on a Haswell, decoders consumed
| between 3 and 10% of the power, depending on the workload
| tested: https://www.usenix.org/system/files/conference/cool
| dc16/cool...
|
| On newer wider and deeper designs this number is most
| likely smaller, and of course the decoder on Arm or RISC-V
| consume more than 0% too. So most likely, all in all, the
| "x86 tax" in terms of power consumption is in the low
| single digit %.
| paulmd wrote:
| Haswell is a much narrower architecture than A14 though -
| 4-wide decode vs 8-wide for Firestorm. So it's 3-10% _for
| an implementation that does significantly less than Apple
| 's_. And the problem is that x86 has geometric complexity
| as you go wider, so it consumes significantly more if you
| want to go as wide as Apple did.
|
| You're saying "nothing wrong with an n^2 algorithm, it
| works fine for us with n=1000", when you're comparing
| against someone who is showing results for n=1M.
| Obviously it would be better for someone in the latter
| situation to use an n-log-n algorithm. Not real numbers
| or transistor order-complexities, but you get the idea,
| x86 has asymptotically worse transistor complexity than
| ARM as you increase the decode width, and that _is_ true.
|
| Also, that number is for a full-fat Performance Core. If
| the rest of the core shrinks, the decoder gets relatively
| bigger, unless you reduce its performance too. So the
| amount of decoder area (as a % of the overall core) is
| worse on efficiency cores than performance cores, because
| there's less "everything else" there.
|
| (likely you will reduce the decoder somewhat, Goldmont
| and Gracemont both use a 3-wide instead of 4-wide, but
| geometric scaling means that it's much more expensive to
| scale wider than you would save from scaling down. And
| the reliance on 'tricks' like instruction cache likely
| won't scale nearly as well - it's the same amount of "hot
| code" for many tasks, regardless of how many threads are
| running in it, because most of the work happens in
| certain hotspots. The increased overhead of decoding
| could, among other factors, be one of the reasons why
| Gracemont e-cores are not particularly appealing in
| perf/area. They are very solid on performance but the
| area scaling isn't _all_ that great compared to
| hyperthreaded Golden Cove Performance Cores.)
|
| Also that's really just looking at one part of the
| processor in isolation. OK, so the decoder only consumes
| 3-10%, but that doesn't say anything about how it limits
| the ways the rest of the processor to scale. Everyone
| loves car analogies, it doesn't matter how big an engine
| you put in the car if it has a rinky-dink air intake that
| can't provide enough air to fully utilize its
| displacement. Looking at "the size of the air intake
| relative to the size of the engine bay" doesn't give you
| a realistic picture of how it affects the ability of the
| rest of the design to scale. A turbo might allow you to
| scale the rest of the engine up much larger than a
| naturally aspirated one.
|
| (or maybe the fuel system might be a better analogy...)
|
| As far as the instruction cache - those are tricks can be
| used on ARM architectures too (and I believe Apple
| does?), they aren't _themselves_ a substitute for a
| scalable ISA, they 're treating the symptom. They may do
| more on an architecture that is more bottlenecked in that
| area, but they do give you at least some speedup on
| everything. Treating the symptoms is really orthogonal to
| the topic of how much an ISA limits decoding width or
| reorder depth in itself.
|
| Anyway, x86 isn't Itanium and it isn't going anywhere,
| but it strongly looks to me like ARMv8 is on a solid
| foundation that solves some weaknesses of the x86 design.
| It's a clean-sheet "how would we do out-of-
| order/speculation if we could design our instructions
| over again" and it largely achieves that goal IMO. I
| don't see it as an inherent law of the universe that
| "there must exist enough tricks for x86 to match the
| performance of any competitor". There's always lots of
| metrics to look at, and in many cases Apple is designing
| for fundamentally different metrics than AMD/Intel, but I
| don't quite get the reluctance people have to admit that
| ARM is going to be better than x86 in some of those
| metrics, even on iso-node (like A15 vs Zen4). And this is
| like, _the core metric_ that aarch64 was designed around.
| jabl wrote:
| > You're saying "nothing wrong with an n^2 algorithm
|
| Quadratic scaling is certainly not ideal, but in the
| grand scheme of things OoO processors have other
| components that consume more power as well as having
| quadratic or even worse scaling. For instance, the issue
| queue, the ROB, multiported register files, bypass
| networks.
|
| Hence, when you go to a wider and deeper OoO design I
| claim that the relative importance of the decoder will
| decrease.
|
| > If the rest of the core shrinks, the decoder gets
| relatively bigger,
|
| In the previous paragraph you're arguing that as the core
| gets beefier the decoder will get relatively bigger. Now
| you're arguing the exact opposite! So which is it?
|
| > As far as the instruction cache - those are tricks can
| be used on ARM architectures too (and I believe Apple
| does?), they aren't themselves a substitute for a
| scalable ISA, they're treating the symptom. They may do
| more on an architecture that is more bottlenecked in that
| area, but they do give you at least some speedup on
| everything. Treating the symptoms is really orthogonal to
| the topic of how much an ISA limits decoding width or
| reorder depth in itself.
|
| I'm quite sure pretty much any processor outside of some
| really tiny microcontroller will have an instruction
| cache. But maybe you're talking about micro-op caches. So
| yes, they are in a way treating the symptom that it can
| be more efficient to cache decoded instructions instead
| of decoding them over and over in a loop. But so what, if
| it works use it! Might as well claim that caching in
| general is cheating instead of just having faster memory.
|
| > looks to me like ARMv8 is on a solid foundation that
| solves some weaknesses of the x86 design. It's a clean-
| sheet "how would we do out-of-order/speculation if we
| could design our instructions over again" and it largely
| achieves that goal IMO.
|
| I fully agree, ARMv8 is certainly pretty much a 'best
| practice' general purpose ISA. I just don't think it's
| such a dominating factor. If ARM or RISC-V eventually
| take over the world I think it'll be more due to
| different licensing/business models/etc rather than the
| superiority of the ISA itself.
|
| > I don't see it as an inherent law of the universe that
| "there must exist enough tricks for x86 to match the
| performance of any competitor".
|
| Indeed there is no such inherent law, but so far looking
| at the history of microelectronics it seems that with a
| modest transistor budget penalty and some elbow grease
| you can make almost any ISA fly.
| userbinator wrote:
| Comparing decoder width for x86 vs ARM is really apples-
| to-oranges. One x86 instruction may do the work of
| several ARM ones. All the OoO stuff happens at the uop
| level anyway.
| hajile wrote:
| This argues even more against x86 as it translates to an
| internal ISA.
|
| In effect, the argument becomes that decode-to-risc-cost
| + risc-execution-cost is always going to be bigger than
| risc-execution-cost.
|
| And this is before you consider the effects of things
| like looser memory ordering or more registers reducing
| unnecessary MOVs.
| paulmd wrote:
| That's true if you take the strict textbook definition of
| "RISC" and "CISC" but everyone has been saying for 10+
| years that really isn't how things work anymore. ARM has
| pulled a lot of the "useful goodies" out of CISC ISAs and
| CISC ISAs have gone to RISC micro-ops internally on a lot
| of things. And x86-64 is really not all that dense anyway
| either.
|
| Also, a huge amount of instructions end up being used
| very little, there are a few "hotspot" instructions that
| make up a huge percent of actual instructions executed.
|
| https://arxiv.org/pdf/1607.02318.pdf
|
| Measured code density on SPEC2006, ARMv8 has geomean 6%
| more instructions, and geomean 12% higher code size. But
| Apple designs use 4x the decoders-per-thread in their
| Performance Cores compared to Intel (8 decoders for 1
| thread for Apple, vs 4 decoders for 2 threads for Intel).
|
| Apple's designs are targeting much, much higher decode
| performance even considering the lower density of ARM
| (4/1.06 = 3.77x as much "normalized decode performance
| per thread"). Which shouldn't be surprising as their IPC
| is around 3x of modern x86 processors as well according
| to Anandtech's work on M1. They aren't magic, the code
| runs about the same on their processors too, they're just
| designed for much wider layouts than x86 and using super
| deep re-ordering to get that performance into a single
| thread.
| mixedCase wrote:
| Taking into consideration how long it's taken the ARM industry
| to get a single decent laptop/desktop processor with the M1
| since ARM64 was published. And it's yet to be matched by any
| other company.
|
| Odds are good we're going to be waiting for a while.
| Qem wrote:
| ARM started at a time when Moore Law still hold strong. It
| was much harder to catch up. The incumbents can't double
| their products performance every 18-month anymore. So RISC-V
| can have a easier time catching up than ARM did, one hopes.
| ninjaoxygen wrote:
| What scares the hell out of me, it would be so easy to backdoor
| an implementation of the open core in a well-hidden way.
|
| Whereas the "big" CPU providers are staking their reputation and
| therefore future business on providing a non-backdoored CPU, it
| would be fairly trivial for an individual device manufacturer to
| provide a backdoored CPU design for their chip design.
|
| It could become the whole cheap-device OEM firmware situation all
| over again (as we saw with many backdoored routers), but this
| time the blob is located on-die, so is significantly harder to
| reverse engineer or audit.
| goodpoint wrote:
| > it would be so easy to backdoor an implementation of the open
| core in a well-hidden way
|
| If anything it's way more difficult that doing so on a closed
| core.
|
| > It could become the whole cheap-device OEM firmware situation
|
| If you think high-end proprietary routers were not backdoored
| think again.
| phendrenad2 wrote:
| If you care about security, you probably don't care about
| performance. High-performance cores are very complicated and
| hard to follow. But, if you give up performance, you can design
| a core that uses very simple concepts, making it hard to hide a
| backdoor in the design. Things like Chisel, which let you write
| your design in a higher-level language, help with that too.
| beagle3 wrote:
| The main provides already provide a backdoored CPUs - Intel ME
| and AMD PSP.
|
| There is a a general belief that only some good guys have the
| keys. I don't know what it is based on.
| marcodiego wrote:
| This is a problem with common thinking these days: " general
| belief that only some good guys have the keys". I paid for
| the device, I should get the keys!
| Macha wrote:
| This is one of the cases where HN attempts to remove clickbait
| from article titles hurts its meaning. An article titled "Why
| RISC-V is succeeding", like this one, would lead me to expect an
| overview of the positive contributors to RISV-V growth, as this
| article does.
|
| An article titled "RISC-V is succeeding" would lead me to expect
| an article focused on market share over time, which this one is
| not
| [deleted]
| snvzz wrote:
| The real reason RISC-V is succeeding, relative to ARM:
|
| _If you make your own CPU_
|
| - With ARM, You have to pay ARM for ISA license (after a several
| months long negotiation), and you cannot license your CPU design
| to anyone, as ARM has the exclusive right to do that with their
| designs.
|
| - With RISC-V, you get a free ISA license, and you can license
| your CPU design to others.
|
| _If you do not make your own CPU_
|
| - With ARM, you can (after a several months long negotiation)
| license one of the few designs ARM has available. There's no
| other vendors that can offer you ARM CPU designs.
|
| - With RISC-V, _right now_ , you can license any among hundreds
| of options available, from tens of vendors. The licensing process
| is usually very short and straightforward. Alternatively, there
| are some open hardware designs. You can get commercial support
| for some of them.
|
| Frankly, unless ARM does radically change their business model, I
| do not expect them to survive.
| gumby wrote:
| > Frankly, unless ARM does radically change their business
| model, I do not expect them to survive.
|
| I kind of agree, but it's not straightforward. ARM's growth
| wasn't so much a hockey stick as a more continuous curve with a
| small exponent. Yes, they only started in 1990, but that was
| itself a reboot/restart after acorn's 12 years of effort. And
| they were scrambling hard for every deal for at least another
| 15 years.
|
| The environment in which RISC-V emerged is different, of
| course, but many of the dynamics are still the same. Car
| companies were still using 16 and even 8 bit devices into the
| 21st century.
|
| Secondly, ARM has a large arsenal of patents that go along with
| the license, and they continue to add to the load.
|
| I bear ARM no ill will but I also want RISC-V to supplant them.
| I just don't think it's automatic.
| klelatti wrote:
| This all rests on the several suppositions including:
|
| - Arm has no IP that can't be quickly replicated by other firms
| (for very little money).
|
| - That the quality of designs from other firms will be better
| than those from Arm (or for the architecture licensees their
| own).
|
| - The really big Arm licensees would see a commercial advantage
| to switching.
|
| Intel threw billions at the smartphone market and still lost
| against Arm. Today there are zero RISC-V smartphone designs.
| That may change but probably largely because of the Arm China
| and Nvidia missteps.
|
| I expect (and look forward to) RISC-V establishing a presence
| in the market but this sort of commentary does the ISA no
| favours.
|
| Edit: I see elsewhere you think they should abandon the Arm ISA
| in favour of RISC-V! really not sure about that ..
| renox wrote:
| 1) Intel is/was handicapped by using an old CISC ISA which
| has some cost in power/performance. This complex x86 decoder
| ain't free.
|
| 2) Network effect favoured ARM.
| klelatti wrote:
| Intel also had the advantage at the time of a clear process
| advantage which almost certainly would have more than
| offset the decoder cost.
| thetallstick wrote:
| Nothing in life is ever simple...
|
| > With ARM, You have to pay ARM for ISA license
|
| This is only true for some definitions of ARM. See for example:
|
| https://en.wikipedia.org/wiki/Amber_(processor) "The Amber core
| is fully compatible with the ARMv2a instruction set and is thus
| supported by the GNU toolchain. This older version of the ARM
| instruction set is supported because it is not covered by
| patents, and so can be implemented with no license from ARM
| Holdings"
|
| > Frankly, unless ARM does radically change their business
| model, I do not expect them to survive.
|
| Looks like someone is having similar thoughts inside ARM.
| https://hackaday.com/2018/10/02/free-arm-cores-for-xilinx-fp...
|
| There are other efforts too.
| MayeulC wrote:
| Also, waiting for IP is a huge bar for entry.
|
| Suppose you just want a soft core for a one-off FPGA project.
| RISC-V is a no-brainer if you need to run complex stuff like a
| Linux kernel. There's myriad of projects to pick from on
| GitHub. Try them all, pick the one you prefer.
|
| The barrier to entry is so much reduced that you can use RISC-V
| "by accident" without having considered it in advance, as part
| of a normal engineering process in companies of any size, vs
| months-long waits for IP, after deciding it was worth
| obtaining.
| yywwbbn wrote:
| And if ARM started allowing everyone to use their IP for free
| you would expect them to survive? ARM the architecture might
| survive but probably no ARM the company. IMHO a more likely
| outcome with Risc (assuming it gets widely adopted) would be
| one or two companies like Samsung, Qualcomm, AMD or even Intel
| gaining a massive advantage and profiting from it instead of
| cheaply licensing their designs to other companies. I don't
| really see how is that preferable to the ARM model where
| company can theoretically license the most advanced ARM cores
| there are (of course aside of what Apple is doing) or mostly
| equal terms.
|
| Of course RISC might push them to make their licensing
| mechanism to be more flexible if they start considering RISC an
| a real threat to them (I don't think this is very likely to
| happen in the near future, though)
| admax88qqq wrote:
| They will have no choice. Either ARM becomes irrelevant as
| people switch to an easier to license ISA, or they have to
| swallow a different profit model and compete by having the
| _best_ ARM cores in an open market of ARM IP.
|
| The trend with RISC-V suggests that ISAs are going to be
| commoditized and the real value will be in the
| implementations themselves.
| klelatti wrote:
| Assumes that Arm have no implementation IP - which comes
| with the ISA and is not available to others - and that the
| only factor in choosing an ISA is how 'easy' it is to
| license. Very strongly disagree with these assumptions.
| YorkshireSeason wrote:
| _> real value will be in the implementations themselves._
|
| It is not that difficult to re-target a micro-architecture
| (what you call implementation) to a new ISA, especially if
| the ISAs relatively close, as most modern ISAs are. RISC-V
| and Arm ISAs are an example where that should be especially
| easy.
| admax88qqq wrote:
| Totally, all the more reason that the specific ISA is
| less important than the implementation/micro-arch.
|
| Why pay for ARM if you can retarget to RISC-V and still
| retain most of the benefits of your designs.
| baq wrote:
| you'll pay ARM for a good ARM RISC-V CPU.
| YorkshireSeason wrote:
| As "baq" also says: you pay Arm (or Apple, or Qualcomm or
| ...) for the micro-architecture. I expect Arm to drop
| licensing costs for their ISA to zero to compete with
| RISC-V at the low end.
|
| Right now, the Arm ISA has much better micro-
| architectures than RISC-V, why bother with RISC-V? I
| think this will change over the next 5 years. One of the
| ways to change this could be Arm selling RISC-V
| implementations.
|
| Of course there are also dangers in RISC-V: one is that
| we will get too many RISC-V versions, so no stable
| software ecosystem emerges for any single one of them.
| Adapting Linux, GCC and so on to your specific version of
| RISC-V (or any processor really) is rather expensive.
| melony wrote:
| ARM won't become irrelevant as long as Apple exists.
| bonzini wrote:
| Arm is the fourth ISA for the Macintosh and its
| descendents. Apple has shown three times that they're
| anything but wed to architectures.
| snvzz wrote:
| >if they start considering RISC an a real threat to them
|
| I'm afraid they have seen RISC-V as a threat for a while now.
| It has already been years since their first FUD campaign.
|
| >if ARM started allowing everyone to use their IP for free
| you would expect them to survive?
|
| That's not how I see ARM surviving.
|
| One way ARM could survive is by doing what the MIPS owners
| did: Abandon the ISA, move to RISC-V, use your extensive
| expertise to make competitive cores, and your clout in the
| market to sell them to your pre-existing clients.
|
| They could totally pull it off, but it would honestly
| surprise me if they did so, considering how poorly they've
| dealt with RISC-V so far.
| Someone wrote:
| > The way ARM could survive is by doing what the MIPS
| owners did: Abandon the ISA, move to RISC-V, use your
| extensive expertise to make competitive cores, and your
| clout in the market to sell them to your pre-existing
| clients.
|
| Even if that's their best bet, long term, I don't see why
| they would have to start doing that right now. Why would
| they leave their castle with its golden egg-laying goose,
| only because they know it won't live for X more years?
|
| Timing such transitions is always difficult (you can't wait
| until your goose is dead), but I think they're better of
| waiting at least a few more years.
|
| The MIPS owners were in a different situation, weren't
| they? Their goose already was dying or even dead.
| the_duke wrote:
| ARM has extensive IP and know how. They could build up
| and sell high performance RISC-V IP/cores now and prevent
| RISC-V focused companies like SiFive from gaining a
| foothold by denying them revenue and investment.
|
| Alas, that would probably have worked better 2+ years
| ago, there is a lot of movement now.
|
| It seems like Intel has realized this. They tried to buy
| Sifive, but have now themselves joined as a major RiscV
| International sponsor and are investing heavily in the
| ecosystem.
|
| Of course there is a downside there too, because it
| accelerates a software and hardware ecosystem transition
| to a different architecture that can enable other
| players. We'll see how it plays out
| YorkshireSeason wrote:
| > _Intel has realized this_
|
| One of the reasons Intel is spending money on RISC-V
| could be that they want to undercut Arm, as the latter
| are now beginning to be competitive in Intel's X86 world.
| RISC-V is going to succeed at all as an ISA, it is going
| to hurt Arm before Intel.
| snvzz wrote:
| >I don't see why they would have to start doing that
| right now.
|
| Me neither, but spreading FUD about RISC-V as they've
| been doing doesn't help their credibility should they
| take the MIPS path.
| cestith wrote:
| Take a look at the Halloween Documents and then look at
| Windows Subsystem for Linux. This industry can absolutely
| forgive FUD in the long term if a company changes its
| path.
| hyperman1 wrote:
| That's just a job for the marketing department. I can
| hear them already:
|
| ARM's vast experience brings the quality you've come to
| expect to the RISC-V world. Want to lower TCO and level
| up your designs, while leveraging existing experience,
| but worried about low quality IP polluting your tech?
| Fear not. etc...
|
| You can probably let an AI spew this stuff by now.
| Training data is easy to find.
| trs-80 wrote:
| > Training data is easy to find.
|
| Got a good chuckle from that, I did! :D
| [deleted]
| admax88qqq wrote:
| Abandoning the ISA is probably too extreme.
|
| MIPS was pretty dead when they abandoned it, ARM is still
| alive and well.
|
| ARM could survive by making the ISA free and competing by
| having the best ARM core designers and designs, and/or by
| having proprietary addons for media handling/decoding.
| Brian_K_White wrote:
| "And if ARM started allowing everyone to use their IP for
| free you would expect them to survive?"
|
| Irrelevant question that no one anywhere has any obligation
| to care about.
| asoneth wrote:
| I don't think the parent comment was suggesting _we_ have
| an obligation to care about ARM 's survival.
|
| But ARM probably cares about ARM's survival so it is
| relevant to the discussion about what future decisions ARM
| might make.
| darksaints wrote:
| I think the real value isn't so much to do with the Free-As-In-
| Beer aspects, and more to do with the Free-As-In-Freedom
| aspects. Having so much open documentation and off the shelf
| capabilities is like a superpower, and you're starting to see
| it with stories like these:
|
| https://riscv.org/blog/2020/11/13-year-old-nicholas-sharkey-...
|
| We've got kids designing their own cores. That was a bar that
| previously was out of reach to anybody without a nine-figure
| engineering payroll. That's amazing.
| posterboy wrote:
| Stands to reason then that they are not designing in the same
| sense, but configuring and customizing. People have been
| doing that for a while now on FPGA, or in hardware with 8080,
| and it's hardly anybody's kids. What's so "amazing" about it?
|
| Dumb cores are a commodity now, which progressed in
| horsepower from their ca. 60 years old ancestors. I.e. the
| core is hardly innovative, so what is so amazing about it,
| technically?
| mhh__ wrote:
| Not really, students have been designing RISC cores as long
| as RISC has been around. It's a standard exercise.
|
| RISCV does make it a bit easier and gives you a clean ISA but
| it hasn't really had that much of an influence due to its own
| design i.e. it's caused people to herd around it so there's
| lots of tutorials and work to borrow floating around.
| thetallstick wrote:
| This is because the underlying CAD tooling has gotten much
| smarter and easier to use. It's not because of anything RISCV
| did in particular.
|
| This toolchain enables going from knowing nothing to a core
| in one class. One doesn't even need to enroll in the class to
| follow along.
|
| See: https://ocw.mit.edu/courses/electrical-engineering-and-
| compu...
| robocat wrote:
| Surely it is because of the open source ecosystem,
| especially open-source tooling, reaching a critical mass?
|
| From article: "The open-source community developed key
| tools that are crucial to make RISC-V-based processors
| ubiquitous, such as chip technology process design kits,
| design verification suites, implementation tools, and more"
|
| Closed source tooling was available and "smart", but
| licensing, cost, and inflexibility were significant
| roadblocks. Disclaimer: I don't work in the industry.
| thetallstick wrote:
| I think to really have the conversation we would have to
| define the terms. Much of the original CAD tooling was
| open source because it was written at Universities.
|
| Things like: is it enough for one to make any core or
| does one have to make the "best" core? If it just has to
| exist that was pretty much always possible. Definitely
| not the lowest friction way to go. But possible.
|
| For example here is basic MIPS core originally written in
| 2003, from chapter 1 of a common VLSI textbook:
| http://pages.hmc.edu/harris/cmosvlsi/4e/code.html
|
| It's just over 400 lines of verilog and super easy to
| follow. The tooling changes that happened in the 90s made
| that possible.
|
| I experimented making cores that were taped-out in my
| University, as an undergraduate, in the late 90s. It
| didn't cost my University even close to 9 figures. It was
| definitely a lot harder than now but the designs were
| also a lot more modest. Things, essentially untrained,
| students can do now would've been unthinkable then.
| einpoklum wrote:
| Their business model was to be sold to NVIDIA, but that didn't
| work out.
|
| Anyway, that's all well good, but - does anyone end up making
| decent RISC-V processors that could replace a desktop CPU, or a
| RPi CPU, or something weaker but not in a small niche? Or is
| this still a vision for the future?
| snvzz wrote:
| >does anyone end up making decent RISC-V processors that
| could replace a desktop CPU
|
| As of November, a large number of extensions got ratified,
| including the vector extension, cryptography acceleration,
| hypervisor support and other important features.
|
| RISC-V is finally not missing any important feature ARM or
| amd64 have, and it does it with an order of magnitude lower
| number of instructions (equivalent but simpler, i.e. better)
| and with significantly higher code density.
|
| However, test chips with the first designs implementing all
| of that will take time, even assuming they were tapped out
| right then, after confirming no last minute changes.
|
| High performance cores depend on these extensions, so we'll
| begin to see them soon. We know multiple such efforts exist.
|
| Tenstorrent has one such project, led by Jim Keller.
|
| >Their (ARM) business model was to be sold to NVIDIA, but
| that didn't work out.
|
| They intend to go public now. I recommend against buying
| those shares, as I do not expect ARM to turn around.
| posterboy wrote:
| What remedie do you recommend against buying those shares,
| though?
| saagarjha wrote:
| > RISC-V is finally not missing any important feature ARM
| or amd64 have, and it does it with an order of magnitude
| lower number of instructions (equivalent but simpler, i.e.
| better) and with significantly higher code density.
|
| This has historically been a problem with RISC-V and it's
| not really something you've backed up as being improved.
| vbezhenar wrote:
| There are rumours of Apple being interested with RISC-V. May
| be MacBook 2030 will feature it.
| mhh__ wrote:
| Apple had a big part in aarch64 being what it is today so I
| am quite skeptical they'd just jump ship.
|
| I might be making this up (I can't remember the company)
| but I'm pretty sure at least one chip designer has moved
| from risc-v to arm. It's not clearcut.
| snvzz wrote:
| Apple posted job advertisements looking for RISC-V
| technical roles.
|
| What they plan to do with them is unknown, but Apple has
| the cash flow to try a lot of things.
|
| I would expect them to quickly adopt it for embedded
| applications, and experiment with making their own high
| performance design, including porting MacOS and Rosetta
| Stone. They can afford to do this much, regardless of
| whether they end up moving their main CPUs to RISC-V or
| not.
| jhickok wrote:
| For what it's worth, Apple always has people on hand
| monitoring innovations in technology and testing their
| stack on new hardware, most of which never sees the light
| of day.
| Macha wrote:
| See OS X on Intel being a thing inside Apple for years
| and years before they decided it should see the light of
| day.
| throwawayboise wrote:
| NEXTSTEP was multi-architecture even before Apple owned
| it.
| m463 wrote:
| I would imagine apple actually ships hundreds of devices
| with processors - each dongle and peripheral has at least
| one.
| unfocussed_mike wrote:
| Yep. There's surely a bunch of uses of RISC-V that have
| little or nothing to do with the main CPU, even in a
| conventional machine.
|
| Trust modules, device controllers, smart adapter cables
| etc.
| PaulHoule wrote:
| My take is that RISC-V is not that great of an architecture
| and might never compete at the high end. (e.g displace ARM,
| Intel, POWER, etc.)
|
| On the other hand there is a vast market for low-end CPUs
| that have specializations to be disk controllers and things
| like that. If the ISA and all the IP required to make
| specialized devices is free and particularly if there is a
| culture in which it is easy to learn how to do that then
| RISC-V will have a special place.
|
| My next spatial computing project is going to be RP 2040
| based mostly because I have the parts in stock (other
| projects are blocked because of supply chain issues) but I am
| really an AVR8 fanatic and the only path forward I see to
| higher performance AVR8 systems is a soft core running on an
| FPGA where very hard tasks (vision? comms?) get offloaded to
| the FPGA and that can be a very appealing architecture where
| somebody might prefer RISC-V particularly if the tooling and
| accelerator integration are there.)
| snvzz wrote:
| >My take is that RISC-V is not that great of an
| architecture
|
| That's not the impression I got, when I studied the
| specification.
|
| Do you care to elaborate?
| PaulHoule wrote:
| See https://gist.github.com/erincandescent/8a10eeeea1918e
| e4f9d99...
| snvzz wrote:
| From your statement, I thought you had looked into it
| yourself.
|
| I remember reading that ex-ARM employee's take back then,
| when it was discussed here[0]. It was based in a pre-
| standard version of the ISA which was already old at that
| point in time, and also ignored the rationale behind many
| of the decisions it criticized.
|
| By objective metrics (simplicity of instruction set,
| features available, code density, absence of uarch
| assumptions), I find RISC-V to be the best general
| purpose ISA available at the present time.
|
| [0]: https://news.ycombinator.com/item?id=24958423
| mhh__ wrote:
| These objective metrics are not even close to being
| tested at the moment, whereas aarch64 has made noticeably
| different decisions guided by real life. They might be
| wrong but I can't see confidently say riscv is actually
| better other than simplicity.
|
| If the macro fusions don't work for example that's a
| pretty dramatic blow against RISC-V compared to aarch64.
| Similarly code density is a tradeoff because riscv's
| simplicity means more instructions in the first place
| i.e. requires actual battle testing first.
| hajile wrote:
| Jim Keller is overseeing a very large RISC-V core that
| should be around the same performance level as X1 or Zen
| 3. I guess we'll see what the ISA can do pretty soon.
|
| He said they were talking about open-sourcing the CPU
| block. If they did (the CPU isn't their core business),
| we could see lots of RISC-V competition popping up. The
| age of CPUs being commodity items seems to be
| approaching.
|
| https://youtu.be/KOHQQyAKY14?t=494
| jabl wrote:
| The bitmanip extension that is scheduled to be part of
| the RVA22 profile will contain add with shift
| instructions (d= a + b<<c), which should obviate the need
| for one of the more common issues that otherwise would
| need fusion.
| zozbot234 wrote:
| > might never compete at the high end. (e.g displace ARM,
| Intel, POWER, etc.)
|
| It might also be successful, even in that segment. The
| RISC-V ISA was specifically designed to scale up (e.g. to
| OOO and vector processors) while still being very simple,
| especially at the low-end - a basic RV32E is really
| comparable in complexity with many real-world 8- and 16-bit
| chips.
| hajile wrote:
| Jim Keller's team is creating a 6-wide issue RISC-V CPU. It
| should have similar IPC as ARM X1 or AMD Zen 3.
|
| https://youtu.be/KOHQQyAKY14?t=494
| Taniwha wrote:
| here's an 8-issue design:
|
| https://moonbaseotago.github.io/
| rjsw wrote:
| Making a RPi equivalent would require a GPU with Linux
| support, I don't see any sign that RISC-V chip vendors are
| able to do this.
|
| Building a desktop system with a PCIe graphics card would be
| easier.
| Narishma wrote:
| Isn't Imgtec doing that?
| rjsw wrote:
| Where can I get the source code for PowerVR kernel drm
| code from?
| Narishma wrote:
| Nowhere because it's not available yet. They only made a
| few announcements.
| kllrnohj wrote:
| > Frankly, unless ARM does radically change their business
| model, I do not expect them to survive.
|
| Survive _what_? I don 't see RISC-V disrupting much of ARM's
| bigger-named business (eg, phones, with some inroads into other
| things like Apple Silicon & laptops). _Maybe_ Amazon pivots
| into RISC-V for the next Graviton? But that also seems unlikely
| unless someone with very deep pockets invests in making an
| actually competitive RISC-V CPU core at the mid /high end.
|
| ARM's low-end market seems likely to be taken over by RISC-V.
| So like the Cortex M series days seem numbered without a change
| in the business model. But that seems like about it.
| throw0101a wrote:
| > _Survive what? I don 't see RISC-V disrupting much of ARM's
| bigger-named business (eg, phones, with some inroads into
| other things like Apple Silicon & laptops)._
|
| Go back a decade or so: how many people thought that ARM
| could compete against Intel/AMD?
| uxp100 wrote:
| A decade ago Microsoft was releasing ARM based laptops (or
| laptop like tablets if you insist). They were slow as hell
| Tegra 3 disappointments, but it was happening 10 years ago.
| CalChris wrote:
| RISC-V is more than a decade old.
| kllrnohj wrote:
| ARM still isn't really competing against Intel/AMD. It took
| an entirely new form factory that radically changed the
| consumer landscape for ARM to get a foothold at all. What
| is RISC-V's smartphone explosion?
|
| ARM has so far, outside of Apple and _very_ limited cloud
| experiements (and some very badly received laptop
| experiments), not really put a dent in Intel /AMD's
| markets. But all of this was fueled by the once-in-a-
| generation explosion that gave ARM untold increases in
| adoption "for free". RISC-V has seemingly nothing similar,
| and RISC-V itself certainly isn't manufacturing any such
| radical shift.
| burnoutgal wrote:
| Graviton2 is generally available and depending on your
| codebase and dependencies can be a drop-in replacement. I
| was amazed at the breadth of ARM docker images that exist
| for common use cases.
| mcpherrinm wrote:
| One decade ago was 2012.
|
| Chromebooks on ARM have already been out for a year.
| Windows RT for ARM was coming out later in the year. Smart
| phones are clearly all going ARM. The 64 bit ARM spec was
| out and people were excited about it.
|
| I think it was a lot clearer that ARM was going to succeed
| x86, as compared to looking forwards now as to where RISCV
| will beat ARM.
|
| I do suspect the microcontroller ecosystem will have lots
| of RISC-V. But it seems a lot less clear that it will
| succeed ARM in the mobile/laptop/desktop/server markets. I
| personally do not think that'll likely happen any time
| soon.
| wongarsu wrote:
| Their phone business is probably safe for now, but as you
| said they are set to lose a lot of their embedded business.
| The stuff that powers your HDD, your fridge, your IoT
| devices. Lots of high volume use cases
| webmaven wrote:
| _> ARM 's low-end market seems likely to be taken over by
| RISC-V. So like the Cortex M series days seem numbered
| without a change in the business model. But that seems like
| about it._
|
| Doesn't that inevitably set up a classic Innovator's Dilemma?
| kllrnohj wrote:
| I don't think so. ARM may just not care about losing that
| market. The CPUs they design at that ultra-low-end really
| don't carry over into the mid & high ends, which is where
| the high profile design wins & "high" (relatively) margins
| are anyway. Like what makes for a good hard drive
| controller doesn't really have anything at all to do with
| what makes a good smartphone CPU. So RISC-V winning at hard
| drive controllers or other (tiny) embedded usages is not
| really setting up an "S" curve for explosion here to
| challenge ARM's markets. They are really fundamentally
| different markets & products.
|
| Kinda like how Intel just never cared about going after
| embedded, and they're not exactly struggling as a result of
| that. With the big asterisk of smartphones where scaling up
| proved a quicker path to shipping than scaling down, at
| which point inertia took over, but for that to repeat would
| require a currently unknown new product category.
| SV_BubbleTime wrote:
| IDK about Cortex M being soon overtaken by RISCV.
|
| There is a huge discussion about peripherals and IP. You can
| buy peripherals for ARM all day long, they'll work from one
| chip to another for the most part. Once everyone can "make
| their own CPU", expect fragmentation in the peripheral
| interfaces.
|
| I think low end cortex A and R are where V will shine first.
| Something like a CISCO IP phone, not an iPhone.
| mhh__ wrote:
| If it becomes an issue ARM probably will change dramatically,
| however keep in mind RISC-V let's you licence hundreds of
| probably pretty crummy cores (and a handful of good ones)
| whereas ARMs are battle tested, verified, and come with
| documentation. RISC-V docs are still a bit 1980s i.e. as far as
| I'm aware there's no official online source of HTML docs, and
| not as much blessed software as arm (i.e. compilers tested in-
| sync with the ISA). Oh and people to sue...
|
| I also trust the ARM ISA designers more than the RISC-V ones,
| but I don't know enough that you should trust me.
| Lramseyer wrote:
| The year is 2012. Blender is an open source 3D modeling and
| CG software. There are hundreds of crummy plugins and hacks
| (and a handful of good ones,) whereas Maya is battle tested,
| developed by professional Autodesk engineers. It comes with
| good documentation and support. Blender documentation and
| tutorials were essentially youtube videos with cheesy
| electronic music in the background. (I'm probably getting
| some details wrong, but you get the point.)
|
| You're not wrong in your assessment. However you're looking
| at it as it is right now, as opposed to where it's headed for
| in the future and what it could ultimately become. While CG
| and computer hardware are very different fields, the effects
| of communal knowledge sharing are very similar and very
| powerful. When bored high schoolers and broke college kids
| (and curious adults) can tinker with the tech, they enter the
| industry with that much more experience and/or have another
| avenue for career transition. And that is far more valuable
| than the mild (and sometimes nonexistent) conveniences of ARM
| over RISC-V.
| klelatti wrote:
| Writing code for Blender != Developing a high performance
| core that is going to be fabricated on TSMC's leading edge
| process.
|
| In the first case anyone with the right skills can do it.
| In the second you need access to lots of specialist tools /
| proprietary industry knowledge.
|
| If RISC-V 'wins' in application processors it will be
| because an Intel or a Qualcomm invests (probably) hundreds
| of millions in building a team that works on a multi year
| project. It definitely won't be bored high schoolers.
| thetallstick wrote:
| Shockingly this is not strictly the case anymore and it's
| become less true everyday.
|
| https://info.efabless.com/press-release-efabless-
| launches-ch...
| klelatti wrote:
| 130nm - that was leading edge 20 years ago.
| klelatti wrote:
| I'm sorry to say there does seem to be a certain lack of
| respect for the Arm ISA designers floating around. Arm v8 is
| in billions of smartphones and powers the core with the
| fastest single threaded performance out there, but somehow
| it's obviously inferior and will be supplanted.
| mhh__ wrote:
| > I'm sorry to say there does seem to be a certain lack of
| respect for the Arm ISA designers floating around.
|
| I was going to use that exact wording in a different
| comment but decided against it, spooky
| klelatti wrote:
| That is spooky!
|
| I mean there was clearly a lot of analysis put into
| aarch64 - which probably involved Apple etc - but I've
| seen comments previously saying they obviously got it
| wrong because [insert some headline design decision].
|
| They might have got it wrong but they're definitely not
| amateurs at this and you can't prove anything with a one
| line comment.
| ignoramous wrote:
| I guess the point is, given the eye balls RISC-V is going
| to attract, you'd have your Tencents and Apples of the
| world pouring resources into it, just like they did with
| AARCH64. And when that happens, where does ARM, as a
| company, go? They did to Intel what RISC-V is poised to
| do to them, may be in a decade or two.
|
| I feel ARM could go the Docker way, who faced a similar
| foe in the stakeholders seeking to commoditize their core
| business... ruthlessly stomped on them, creating k8s,
| runc, registries, microvms, serverless, and what-not.
| Despite Docker having stellar engs working for them (and
| in some cases, better tech: Swarm, for instance), there's
| nothing they could do.
| giantrobot wrote:
| > you'd have your Tencents and Apples of the world
| pouring resources into it
|
| The Tencent and Apple of the world are...Tencent and
| Apple.
|
| If Amazon say decided to throw billions at developing a
| Graviton 4 using RISC-V...they really couldn't leverage
| much of their previous Graviton development work. They
| also wouldn't have a deep bench of low level RISC-V
| wunderkind to bring on board to leverage the new
| platform. It's a chicken and egg problem.
|
| Why would Amazon then want to pay to bootstrap a whole
| RISC-V market? That's a lot of CapEx without a clear
| potential for returns. You'll note they _did_ develop
| Graviton using the ARM ISA so they didn 't have to create
| from whole cloth a "Graviton" market.
|
| Amazon made the same decision as PC makers in the 80s.
| They consolidated around the IBM clone architecture to
| take advantage of the rest of the market, especially
| Microsoft and IBM, supporting the IBM clone market.
| Commodore, Atari, and Apple all had to fight uphill
| against IBM clone market.
|
| I haven't seen any _technical_ advantage of RISC-V over
| ARM that would suggest it 's worth pouring billions of
| development dollars into. It might make sense for Western
| Digital for drive controllers but not phone, tablet, PC,
| or server makers.
| klelatti wrote:
| Why would Apple pour resources into it? To save a few
| cents licensing costs on a $1,000 smartphone and give up
| a decade of hardware and software investment. Sorry, not
| buying it.
| pjmlp wrote:
| I see too much cheerleadering for RISC-V.
|
| Apple is not going to adopt it, ARM is still fighting against X86
| Imperium in the desktop/server market, and the mobile ecosystem
| of tooling, compilers, libraries and build process just isn't
| there.
|
| If RISC-V manages to win education market previously targeted by
| MIPS and microcontroller, that is already quite good.
| wongarsu wrote:
| The CPU is dozens of processors in any given desktop/server.
| Thanks to SSD and HDD controllers alone a significant portion
| of processors in servers are ARM (and RISC-V candidates).
| pjmlp wrote:
| Which are meaningless for most people, probably the last time
| I cared what CPU was driving the harddisk MS-DOS still ruled
| the PC world.
| vineyardmike wrote:
| Its meaningless to you to consider, but it'll have impact.
| As ARM took over the controllers world, it gained the
| volume and engineering efforts to move to phones and
| mobile... now macs and servers.
| thetallstick wrote:
| That's part of the reason ARM will be very hard to
| displace. Just like there is a ton of x86 code out there
| in the server world that's not going anywhere. There is a
| ton of ARM code (especially peripheral driver code) out
| there in the uC world. And much, probably most, of it is
| not open source and not actively maintained.
|
| The good news is compute and memory are getting so cheap
| it's probably not long until RISCV cores just emulate ARM
| and solve the problem, all inside a greeting card at a
| profit...
| hajile wrote:
| We've moved past this for the most part. Anything running
| on an ARM will be almost entirely written in C. At that
| point, porting to RISC-V becomes much cheaper. As long as
| the savings from RISC-V exceed the cost of porting the
| firmware, this is what companies would do.
| thetallstick wrote:
| The code may have been written in C but many drivers are
| distributed in binary only form with headers.
| Unfortunately the binaries are often ARM only.
| pjmlp wrote:
| Indeed, after being founded 37 years ago, servers are
| hardly impacted by ARM, and Macs are meaningless for 80%
| of the desktop world, which by the way are still Intel in
| what concerns the Mac Pro workstation.
|
| So cheerleading for RISC-V to overtake in a couple of
| years what took ARM 37 years to achieve, is really flying
| high.
| vineyardmike wrote:
| AWS is moving big into ARM, and macs are just the first
| consumer computers to move - not the last. The story
| isn't over yet.
|
| > so cheerleading for RISC-V to overtake in a couple of
| years what took ARM 37 years to achieve, is really flying
| high.
|
| Oh yea i agree it won't be a few years. It'll be many
| years - but it'll move faster than ARM did just because
| its so much easier to do today than 37 years ago.
| pjmlp wrote:
| Macs were also the first consumer computers to move into
| PowerPC.
|
| I can hardly execute Mac software as old as some stuff I
| have on Windows floppies, backwards compatibility is what
| keeps x86 ruling on the desktop.
| initplus wrote:
| It's meaningless to us as software developers but I'm sure
| ARM likes having customers to buy their low spec designs.
| Every product doesn't have to be a top tier high
| performance CPU design.
| pjmlp wrote:
| Indeed, and not every RISC-V CPU needs to be 100% open
| source.
| cultofmetatron wrote:
| I'm itching for a riscv version of the pinebook pro. I'd drop
| some descent coin to whomever makes that avaialble.
| synergy20 wrote:
| I work with RISC-V these days.many AI chips are using RISC-V.
|
| A non-technical perspective about RISC-V: China is leading to
| some extent in RISC-V land(Sifive works with Hifive in China,
| Alibaba released its RISC-V,etc). China could not license x86,
| could not acquire MIPS, tried to get part of ARM now(the China
| ARM company is fighting with ARM), but the big land needs to
| "own" a CPU core at will desperately, RISC-V fits perfectly well.
| Qem wrote:
| Did they give up on Loongson? I thought they already had a
| domestic core architecture.
| hajile wrote:
| That was just MIPS without paying licensing fees. MIPS has
| lost most support and I doubt China wants to foot the bill
| for maintaining everything. RISC-V allows them to offload
| most of the hard software parts to other countries.
| userbinator wrote:
| ...and RISC-V is almost a clone of MIPS anyway, so no
| surprise there.
| hajile wrote:
| In what way is RISC-V a clone of MIPS?
|
| There are VERY different ideas most notably using
| variable-length instructions rather than one instruction
| width (begging the question of whether RISC-V is actually
| RISC).
| Koshkin wrote:
| Just curious, is the RISC-V arch better/worse than ARM?
| Narishma wrote:
| Yes.
| GeorgeTirebiter wrote:
| I have a question about RISC-V: Why is the OpCode on the 'wrong'
| end of the instruction? Has there ever been ANY machine that puts
| the op code in the low-order bits?
|
| It doesn't really matter -- buy why? Most RISC-V decisions were
| made for some good reason. (also, I'm not convinced RV32E makes
| sense anymore.)
| zozbot234 wrote:
| It's a little endian architecture so the low-order bits are
| found "first", directly at the insn address. This matters
| because of the variable-length insn support.
| blippage wrote:
| I follow some of the writings of Nassim Taleb. I came to the
| conclusion that RISC-V will "succeed" because there's no way for
| it to fail. It's like Linux.
|
| I don't think licensing fees to ARM are a problem per se, it's
| the "frictional costs" that it introduces. My understanding is
| that the Raspberry Pi developed their RP2040 because ARM had a
| reasonable package available for its low-end Cortex-M processors,
| which doesn't apply to their higher-end Cortex ones.
|
| RISC-V doesn't even have these restrictions. Even extremely small
| outfits can play around with RISC-V designs. Most of them won't
| go very far, but with enough lottery tickets, one of them is
| bound to draw the winning numbers.
|
| Sure there are considerable obstacles. I toy with
| microcontrollers. For hobbyists like me, ARM processors are still
| the most sensible choice. I'm not expecting any shift from that
| for at least five years. But who knows after that? Anything can
| happen.
| klelatti wrote:
| > It's like Linux.
|
| It's unlike Linux in so many ways, licensing being just one
| really key example.
|
| RISC-V may well succeed but not because it's like Linux.
| als0 wrote:
| > will "succeed" because there's no way for it to fail. It's
| like Linux.
|
| Didn't OpenRISC fail? https://en.wikipedia.org/wiki/OpenRISC
|
| Also there are different definitions of "succeed" from
| different viewpoints. In academia RISC-V is already a big
| success.
| goodpoint wrote:
| Good point. How is RISC-V better than OpenRISC's ISA?
| thesz wrote:
| RISC-V does not have unused/unusable exceptions and tries
| not to expose internal details of implementation as much as
| possible.
|
| To show difference, OpenRISC has division-by-zero exception
| which is unnecessary - it can be ruled out by compiler or,
| if compiler did not rule it out, can be checked and
| triggered by comparison, conditional jump and special trap
| command. MIPS did exactly that almost fourty years ago.
|
| OpenRISC also has (optional) branch delay slot, which
| complicates out-of-order implementations and even in-order
| implementations with memory mapping unit - what state
| should you keep to properly handle MMU exception in the
| branch delay slot command?
|
| Alpha AXP, being the ISA that was designed to be useful for
| 20-25 years, ditched both of these in early 1990-th.
| RISC-V, which extends experience of RISC-IV (SPUR [1]) and
| other RISC designs, including POWER and SPARC, also does
| not sport these atrocities.
|
| [1] https://news.ycombinator.com/item?id=19266152
|
| All in all, RISC-V represents an ISA that can be
| implemented differently with less effort than OpenRISC and,
| to be frank, most other RISC ISAs.
| tyingq wrote:
| Mainline Linux kernel support is a fairly big plus.
| chmod600 wrote:
| Can you expand on Taleb's message, and what you mean when you
| say "can't fail"?
|
| Free stuff does fail for all kinds of reasons.
| blippage wrote:
| I can't remember the exact criteria that Taleb mentioned that
| led me to believe that great things might come of RISC-V.
|
| So I'll fall back on the "optionality" argument. Vendors,
| particularly small vendors, can experiment with RISC-V either
| free, or very cheaply more so than they can with ARM. Right
| there, RISC-V opens up a segment that didn't exist before.
| They'll be more experimentation. When your downsides are
| limited, but your upside is potentially huge, that's what I
| mean by "optionality". This is a powerful driver of success.
|
| Naturally, any individual endeavour can fail, but
| collectively, there's going to be some huge winners.
|
| My prediction is that RISC-V will open up some new category
| of computing. I can't tell you what it is, who will do it, or
| when they'll do it, because I don't know. My point is not so
| much that I can predict what it will be, but merely that
| there are forces in favour of RISC-V.
|
| I am not, however, predicting the imminent demise of ARM.
|
| I think also that a lot of commentators are viewing things
| through the lens of what we understand and the received
| wisdom today. Even - or maybe especially - experts tend to be
| hemmed in by what is "obvious".
|
| RISC-V is like a genie that's been let out of the bottle. You
| can't put it back in.
| tyingq wrote:
| The "minion cores"[1] idea from lowrisc.org might be a good
| early example. You can find something similar for one ARM
| chip I know of (TI Sitara with PRUs), but only one that I
| know of...perhaps because it's expensive to experiment like
| that, as you mention.
|
| [1] https://lowrisc.org/docs/memo-2014-001-tagged-memory-
| and-min...
| josemanuel wrote:
| Vendors can experiment with Arm for free with "Arm Flexible
| Access"!
| cushychicken wrote:
| Companies fail. Information doesn't.
|
| By virtue of being open source, RISC-V won't vanish, no
| matter how many companies choose to adopt it as their ISA and
| fail.
|
| Seems like, given enough time, one of those companies will
| just not die, and end up getting big.
| chmod600 wrote:
| If I write a free operating system, nobody will use it
| except me. When I lose interest literally zero people will
| care that it exists. Hard for me to see how that would be a
| success no matter how many copies of the useless bits
| reside around the world.
| pm90 wrote:
| There's a _lot_ of open source projects, _most_ of them
| fail. I don 't think the availability of an OSS ISA is good
| enough to overcome the friction of adopting a brand new
| technology, _unless_ it enables something that competitors
| don 't. And it doesn't seem to do that w.r.t ARM (so far).
| initplus wrote:
| ARM's less open platform also comes with some advantages
| though. It's easier for ARM to prevent ecosystem fragmentation
| and non-standard instruction set extensions. Or to push for
| migrating to newer platforms like the move to 64bit ARM.
|
| Software is less affected by these issues because it's
| inherently more flexible. If I install some wonky experimental
| Linux feature, it doesn't really matter and I can just revert.
| Different story when this is baked into hardware. The startup
| costs for independents to contribute to a software only
| ecosystem is also much lower. How many organisations have the
| talent to contribute to RISC-V, but wouldn't be able to afford
| purchasing a license?
|
| Didn't mean to sound so negative but I worry in the hardware
| space that the advantages of such an open design are not as
| great.
| 0xedd wrote:
| That's the equivalent of saying forking is bad.
|
| The big plus of RISC-V is allowing those who accept the risks
| and cost to experiment and develop new specialized
| components. Arm won't let you.
| ChiefOBrien wrote:
| > ARM's less open platform also comes with some advantages
| though. It's easier for ARM to prevent ecosystem
| fragmentation and non-standard instruction set extensions.
|
| It's kind of funny way of looking at the core part of the ARM
| ecosystem while forgetting how much outside of the CPU is
| non-standard, undefined. None of the ARM devices share
| bootloader, device enumeration, and a plethora of things
| needed for an open, non-fragmented OS/Software ecosystem like
| how PC does.
|
| Maybe you can run parts of the same ARM machine code on most
| devices, but it's not terribly portable to be honest, it has
| to be very generic. For example, Android devices end up in a
| pile of trash because you can't just upgrade the kernel to
| the latest version on a 1, 5, 10 year old smartphone without
| losing functionality or being stuck at step 1 for the lack of
| tools from broken forum links and shady fileshares. So much
| for software flexibility...
| klelatti wrote:
| So you're criticising Arm fragmentation but the possibility
| of more fragmentation in RISC-V is ok?
| ChiefOBrien wrote:
| My idea is that a CPU is just a component and it's
| useless by itself without considering the rest of the
| computer system. ARM needs to dip more into standardising
| the rest of the picture, and the RISC-V guys could also
| start looking into creating an open computer architecture
| initiative/group to prevent further fragmentation.
| klelatti wrote:
| Agree 100% - Arm could certainly do better.
|
| I do worry though that the RISC-V ecosystem could be
| really torn in two by a big player (Intel?) who adds
| proprietary extensions and associated software.
| humanwhosits wrote:
| RISC-V is trying to create a standard platform
| specification to address some of these concerns
|
| https://www.youtube.com/watch?v=l2w4cWFpqAA
| stefan_ wrote:
| If you are making a custom chip, you will still license a ton
| of different IP blocks that you will pay licensing costs for.
| What is special about the CPU?
|
| I guess it's nice to have a free CPU core but at the end of the
| day you want USB, external RAM, a bus to connect all these
| things and so on.
|
| Maybe we will have free implementations of those at some point
| but it probably won't be from the current crop of chip
| designers - there have probably never been more ungrateful,
| non-reciprocal users of free software.
| SV_BubbleTime wrote:
| Right. When you are talking cores, this is all fine. A
| completely valid topic for academic discussion.
|
| When you are talking chips with peripherals and packages and
| memory configs, it gets a little more muddy.
|
| When the conversation moves from academic to trying to buy a
| chip and ship a product.
|
| I am aware of a popular chip vendor next year making a three
| core chip. Core0 the fastest and primary is a RISCV, it will
| be flanked by two smaller and weaker ARM cortex m0 or m4s.
|
| They're doing that because they have peripherals established
| for the ARM and almost none for the RISCV.
| charcircuit wrote:
| RISC V cores are not necessarily free.
| bri3d wrote:
| I think the last point in the article is super interesting and
| under-discussed here - now that academics and engineers have a
| wealth of free core IP, will we see more open development in the
| EDA space? Yosys and the ecosystem around it certainly points
| this direction, but there's a LOT to the EDA space.
|
| Are universities pursuing academic EDA development, too?
| sylware wrote:
| Hope we can get a performant 64 bits RISC-V desktop CPU not too
| far in the future. This may be an significant inflection point in
| computer systems.
| adapteva wrote:
| Too much focus on ARM OR RISC-V. The processor space is
| incredibly diverse. There are tons of embedded applications that
| don't require massive software ecosystem. The tenslica, arc, ceva
| ISAs have all shipped in the billions sitting next to arm inside
| SoCs.
| sabhiram wrote:
| We run a cluster of RISC-V CPUs based on open source designs to
| schedule and post process workloads for our edge accelerator
| ASIC.
|
| 10/10 would do it again, except this time we may pay SiFive or
| someone like that for something requiring less "customization".
| marktangotango wrote:
| Interesting, can you say anything about what sort of chip to
| chip communication is used? AXI, Wishbone, plain old serial?
| sabhiram wrote:
| AXI primarily.
|
| But, I should also mention, we only use the RISC-V cores as a
| pre/post-processor, scheduling engine, service processor. We
| have custom hardware that does the bulk of the inference math
| (we are a convolutional accelerator with a number of
| constraints traded off for speed and power). The fabric
| itself is driven by engines that are programmed by the
| scheduling engine (RISC-V).
|
| Happy to answer more specific DMs.
| 323454 wrote:
| Do you have a website / product page?
| gautamcgoel wrote:
| Can you DM on this site?
| minimilian wrote:
| Does this mean that we can have completely free computers soon?
| mistrial9 wrote:
| think for a minute - the energy inputs, the materials inputs,
| the transportation inputs, the intellectual work inputs, the
| software architecture advances inputs..
|
| asking for "free" in the face of these factual inputs, appears
| to echo the most lazy and gluttonous of human instincts..
| really unproductive, spoken from a person who has tried to
| confront the excesses of American markets e.g. software
| patents, rent-seeking models, etc..
|
| also spoken from a person who defends regularly "free as in
| Freedom, not free as in BEER" .. this is a call for free beer
| in the worst form.. really unproductive
| Pet_Ant wrote:
| I think the GP meant as completely free as in speech free. A
| computer made of 100% open source components, all chips with
| Verilog, all masks etc for the PCB... and I think I that is a
| long way off.
| snvzz wrote:
| You can have them yesterday (RISC-V or else), if performance
| isn't a concern and if you're OK with deploying said computer
| inside a FPGA.
| ThrowawayR2 wrote:
| The fine article points out that RISC-V is succeeding because
| it allows businesses to create processors customized with their
| own (no doubt proprietary) extensions for their own needs. So
| unless somebody wants to pay the immense engineering costs to
| create a completely _libre_ processor, no.
| extheat wrote:
| Yes
| elihu wrote:
| Depends whether you mean "free" as in "zero financial cost" or
| "free" as in "all the RTL, firmware, and software source code
| is available to anyone with a permissive license that permits
| derivative works".
| gnufx wrote:
| https://libre-soc.org/ is going for free hardware with free
| tools, but the value of "soon" might be quite high. There was a
| previous item on 180nm silicon:
| https://news.ycombinator.com/item?id=27772066
| mhh__ wrote:
| RISCV is an open ISA, it has absolutely no legal influence over
| the openness of a chip that implements it.
| pjc50 wrote:
| No
|
| (People forget about foundry IP, miscellaneous analog bits of
| CPUs, the actual physical cost of manufacture, and the question
| of what "free/libre" actually means for hardware.)
| oconnor663 wrote:
| I think it's interesting even just to try to define an "IP-
| free computer" in a clear way. Like presumably we don't care
| if minor components like resistors or screws are proprietary,
| because it's trivial to replace them with a different
| supplier. Or taking it to the extreme, obviously we don't
| care where the _steel in the screws_ comes from. Steel is
| steel, even if being a steel company requires tons
| (kilotons?) of proprietary machinery. It 's hard to even
| figure out where the screws in a computer come from, much
| less the steel.
| riscvmaybe wrote:
| I don't like this article because it is very scarce on data.
|
| You are succeeding? I've heard this last four years in a row.
|
| Show me the numbers, shipping units, example of arm designs
| getting displaced by risc v.
|
| This article is very light on the proof. It is just riscv talking
| points.
|
| Don't get me wrong, concept is fine. But at this stage, after
| hearing about this for years, where is the traction? Prove it.
___________________________________________________________________
(page generated 2022-03-01 23:00 UTC)