Somewhat related: I believe RISC-V is going to well in the coming decade. I've been trying to figure out what I can invest in to get exposed to it, but have been unable to find anything. If anybody had got any angles, I'd love to hear them!
For the processors designers themselves, I wouldn’t bet outside value accrues to them since the instruction set is open and competition could be fierce.
Another option would be to figure out who you think will be manufacturing the other peripherals needed to use RISC processors. Something like Supermicro on the server side (which benefitted hugely from a similar relationship making nvidia cards into servers), or find some supplier on whatever market you think will pop because of RISC-V (automotive, military systems, etc). Basically whoever turns these processors into finished systems is probably a good bet, but I haven’t done enough research to know who that would be.
disclaimer: this is pure speculation, I am not privy to any information, I am just a rando engineer.
It took until...tomorrow for me to be able to run my workloads on arm. That only happened (hasn't 100% happened yet) because we had RPi and then the M1 forcing all the dependency folks to ship arm builds. I've never seen a RISC-V docker container...
RISC-V is going to show up more and more in heavily customized stuff like HPC chips or networking accelerators before it starts replacing Xeons, as (right now) thats what its best suited for. Look up what Jim Keller said about RISC-V usage for Tenstorrent and how ARM just doesn't allow for the kind of customization these specialized designs need from a standardized ISA.
This is the problem with arm, it’s this foundational technology that underpins everything from Grace to Dojo and TPU and yet arm doesn’t make any fucking money. They lost money during the first year of the pandemic (and the two years prior iirc!) despite the boom in electronics sales!
Nvidia buying arm for the synergy of forcing CUDA as the default arm graphics IP (and BYO for higher price) was the good ending. Nobody else is going to pay $40b for a company that makes 0.5b +/- 1b without some other synergy, and the other possibilities are companies like Samsung, tsmc, or Oracle with their own synergies. CUDA as an ai platform was absolutely a play that would be cashing out big right now if they had succeeded.
Well, if it’s not nvidia (and it seems any other buyout would be equally unlikely to get approval) then SoftBank is just gonna have to make the existing licensees pay up, and cash out the business that way (revenue and then IPO). So there’s a lot of licensees who are going to find an extra zero on their TCO of ARM usage.
That’s the reason you saw Qualcomm pitch a fit and start lying about the terms of their licensing deal last year. And google and meta and Amazon are equally upset. And they’re gonna start funding a competitor.
Those companies (and the bulk android market) mostly don’t care about performance, this is the “cheapest thing that works” market. The accelerator (TPU etc) is the thing that really matters now.
There may be a minimal amount of collaboration (ala Minix or CDDL) to build that common platform but that’s all they really care about, is some basic P-core and E-core designs. There is no incentive for Amazon to build processors that are way faster than googles, actually everyone is still selling vCPUs based on sandy bridge processing power. They’d rather make cheaper smaller CPUs (this is why zen4c and zen5c exist, in large part) than compete on performance or features. That’s just not where the secret sauce is, and it’s not where the revenue is.
So we are going to see the same thing as the software space, where vendors take the fruit of risc-v, build their own stuff around it, and pay nothing and contribute nothing back. Everything important will live in proprietary, non-portable IP that doesn’t need to be shared under open terms. The same problems as always when you BSD/MIT license.
The future is a google TPU that you are not allowed to purchase yourself, stamping on a human face endlessly. But the boot will be based on a core of open-source/open-license designs, how wonderful! (with the interesting parts living inside proprietary parts of the core ofc)
Nvidia/CUDA dominance is way better than google platform-as-service that you can’t even run on-prem if you wanted to. And for all you can say about them, nvidia has never stopped pushing to the next thing, even when they had an insurmountable lead, and even when nobody else believed in the goal or saw where they were trying to go. Google and Amazon don’t benefit from pushing the limit like this, they just want cheap arm.micro instances and a host for their proprietary accelerators.
The difference between BSD/MIT and GPL is fundamentally about who gets the freedom - BSD/MIT let developers do what they want with it, and that sometimes comes at the expense of user freedoms. And when google/Amazon/meta say they want free and open cores, they certainly don’t mean they’ll be giving away their IP.
That’s arm’s predicament in a nutshell. Their business model lets other companies extract all the value and revenue. They’re this foundational technology that google/Amazon/meta make billions off of, and arm gets to lick the beaters. And any change to this model is is going to piss off enormous amounts of people, not least google/Amazon/meta. And arm’s play is “ok but if we don’t contribute anything worth paying for, then you won’t mind switching”. There is no BATNA for arm licensees right now.
Long term this could mean arm being knocked off its pillar. But that could happen anyway too, eg with the nvidia merger perhaps.
The only Balkanization that has occurred so far is companies implementing draft versions of standard extensions because they don't want to wait years for the final version: e.g. the Kendryte K210 with priv ISA 1.9.1 [1], THead C906 and C910 implementing draft 0.7.1 of the Vector specification [2], THead implementing Physical Memory Attributes which didn't even have an official draft spec yet, THead and Andes implementing equivalents to (mostly) the eventual Zb or Zc extensions [3]
None of that has much in the way of lock-in as affected code can be either simply recompiled using the relevant official extension or else trivially ported.
[1] they appear to have simply used the current Berkeley Rocket snapshot at the time, 1.10 is what was ratified
[2] which document said "we think we're really really close to being ready to ratify this" but there turned out to be three more major revisions over 1.5 years. Nevertheless, many important library functions such as memcpy() are binary compatible between them, and forward-porting other 0.7.1 code to 1.0 is trivial.
[3] e.g. clz and popcount, shift-and-add for addressing calculations, byteswap, short opcodes for simple forms of byte load/store
We are in totally different world. For almost all compute task there are large amount of existing products, both open and closed. And all of them already target specific profiles.
If you develop something that is not in a standard profile you have a huge amount of work ahead of you to maintain a gigantic amount of software in forked state. Any many of those projects will simply not accept any proposals to up stream. And with the commercial software its worse because unless you achieve huge market dominance, those companies simply wont make a release for you.
RISC-V is in the process of standardizing pretty much everything that is commonly used. And any company pushing an alternative to those standards is pretty much dead in the water. The waste majority of software in the world is already fine with what's standard now. And over the next 1-2 years lots of stuff that some software needs will be standard.
Beyond that we are getting into highly specialized extensions. In those there will be competition and balkanization. But this simply wont effect the waste majority of users. Those things will be mostly about proprietary AI acceleration functions, special data types and so on. This has already happened but its simply not relevant to the waste majority of software in the world.
But all those companies understand that if their thing isn't gone be standard, they will have issues in the long run. So in reality what we are seeing is that all these companies are involved in the standards discussion and try to find one standard. They don't want to fight each other when Nvidia, Intel, AMD are much better targets.
Other companies are already public, like Andes
Look at names of companies that give talks at https://events.linuxfoundation.org/riscv-summit/
Think of it a bit like what happened to JS. Being the open language the web runs, it saw immense competition from multiple particles and today we have a what should be a shitty dynamically typed prototype based scripting language outperform and outoptimize the likes of Java with its static classes and types in some scenarios.
I don't see how than can work when developing competitive CPU cores is extremely expensive. Why would anyone who does that make them free? (even licensing seems like a poor idea looking at ARMs business model).
Also the web ecosystem is still basically a pile of shit on a few key metrics compared.to (say) boring Microsoft-land stuff a decade or 3 ago, so I'm not so sure if that's such a good argument.
We know there's already a lot of "built to purpose" RISC-V products ending up in embedded environments. When you have less obligations to a restrictive ISA grant, you can make something that fits your needs exactly.
So the business case is second-order:
* As has repeatedly been joked, fab companies who aren't locked to a captive/capricious owner (Intel) look appealing. It likely isn't about cutting-edge there, but the flexibility to handle diverse custom orders. Plenty of these products will be like "133MHz and a couple hundred thousand gates" that would be fine on 90nm or bigger.
* Firms that can move from "product" to "consultancy". There's a lot of brilliant work in existing ARM and RISC-V MCUs, but will existing firms be able to move away from "here's a matrix of features, order from the list" and into "Let us meet with your team, build a custom pick-and-mix and add a bespoke unit to meet your need for (smaller number than was historically common) product-specific MCUs?"
Otherwise, I'd imagine the cost of the mask set and validation to far, far outweigh any reduction in unit cost you might see from a custom chip. MCUs are already extremely cheap, especially if you're buying significant quantities.
Disclaimer: Not investment advice.