I wonder how the driver situation is. From Jeff Geerling's work on running "big" GPUs on Raspberry Pis, my impression is that often less-common platforms should work but are littered with papercuts in practice.
AMD GPUs have worked on RISC-V for a couple years at this point. I have a Milk-V Titan that's paired with an AMD GPU running well: https://milkv.io/titan
…and when it comes to the most common use of big-iron GPUs right now, neural network engines, they're all so poorly put together that a papercut is often fatal. If every dependency isn't the exact needed version, the whole thing will collapse, and using all but the most common hardware is sure to be unsupported in some deprecated library version that is absolutely required to get everything running.
I had thought Xilinx ISE and Altera Quartus had the market cornered on the most difficult environments to get running, but then LLMs and stable diffusion came along.
You haven’t lived until you have done a model training run where different stages require mutually incompatible nvidia driver revisions and everything on top.
> I had thought Xilinx ISE and Altera Quartus had the market cornered on the most difficult environments to get running, …
These tools were the reason why I gave up on FPGAs years ago and chose to spend my time on GPUs instead. And to this day, I still don't understand why they worked so differently from what I had expected in so many ways.
I highly recommend getting a small, cheap FPGA development board with something supported by Yosys, like a Latice ICE40UP5k, Efinix T8F81C2, or GOWIN GW1NR-9.
Yosys is a super lightweight open-source FPGA toolchain that really easy to get up and running. The FPGA models I mentioned have ~5k to ~10k LUTs, can all support simple RISC-V processors, and have built-in memory and DSPs.
lean from a technical point of view: size and complexity. That would include the SDK, namely the complexity of the syntax of used computer language (for instance excluding de facto c++ and similar), the build system, the amount of dependencies, etc.
Somehow the RISC-V designs mostly seem to have more coherent PCIe implementations, meaning some devices are easier to get running without the arm64 quirks drivers have to work around.
Drivers still need tweaking, most of the time, since most are still built assuming an amd64 world.
RISC V making its way into proper server platforms is a huge milestone. The open architecture could eventually disrupt the current vendor lock in we see in cloud data centers.
I don't doubt RISC-V can be used to make powerful cores but adoption as a general purpose CPU (rather than MCU) will need more than good numbers.
There's still a missing piece in the RISC-V ecosystem: a coordination body of platform-level standards. Debian took a stand with RVA23 support but then there's a ton of little things that are taken for granted on the PC platform such as UEFI and ACPI (as horrible as they may be).
risc-v is basically borrowing the ARM SystemReady stuff. This includes the expectations for ACPI and UEFI on servers. The RISE organization has been trying to drive these standards iiuc.
Which axis of vendor lock in are you seeing possibly being disrupted by this? x86 is rather dominant, though ARM is making a play. RISC V just means AWS offers a different ISA on compute, you'd still be vendor lock-in'd to AWS/whomever. Or I'm totally not getting it.
Lock-in to x86 or ARM is painful from an operator like AWSs perspective. With x86 you end up with two vendors to play off against each other, which isn't great. ARM gives you the ability to design your own silicon, but you're still beholden to a single licensor -- arguably worse. On top of that, some customers mandate a specific ISA or even a specific vendor, so none of it is truly fungible outside vertically integrated workloads like S3.
The ideal scenario for a hyperscaler is an open architecture at the core with 10+ competing implementations -- including potentially their own.
> The ideal scenario for a hyperscaler is an open architecture at the core with 10+ competing implementations -- including potentially their own.
This is what Arm actually is. Arm primarily functions as a talking shop for random insights to get back from integrators into the ISA and architecture, then cleared and released for everyone to use. The reason there are so few novel implementations of it is it just isn’t worth the trouble unless you are pushing mobile levels of units.
On top of that, some customers mandate a specific ISA or even a specific vendor, so none of it is truly fungible outside vertically integrated workloads like S3.
I would be very interested to be a fly on the wall when a customer attempts to mandate to AWS they must support an ISA that AWS doesn't have plans to support out, say, a decade[1]. That would be almost as amusing as the many, many times I've heard clients say "we spend $X million dollars with Microsoft! We're a Big Company! We have leverage! Of course they'll do what we want!". And the local M$ salesthing just smiles nods and says "I'll get back to you on that..." and for some reason Nadella doesn't return their calls.
[1] Maybe if one of the big nations says "thou shalt only use our glorious domestic processor, and the processor of thine enemy shall be verboten, for all the data things" or some such...but not a commercial enterprise.
Considering how consolidated the hyperscalar market is and their natural inclination to reduce hardware SKUs, I'm not entirely sure they would make it viable for multiple vendors to produce chips they could actually use. There is no reason to believe it'll work out differently from the ARM server market.
Not to knock on RISC-V, which I’ve been following from the embedded side of things for many years now, but I feel I must question the value of a license-free ISA in this specific market segment at this time.
Surely between the squeeze on RAM and storage pricing and the exorbitant costs of training or mass-inference scale GPUs (if you’re going into AI), the nominal cost of the CPU licensing is really not going to make or brake anything or unlock some new business viability?
Even RISC-V aside, we are essentially in a position that would have been impossible to even dream of ten or twenty years ago when Intel was the only player in the game.
Wouldn’t buying off-lease hardware (not even in bulk) give you better performance per dollar, better compatibility, and more options?
Not to say any of this will always be the case; even if RAM pricing doesn’t come down, storage will, and RISC-V processors will (maybe) eventually actually be competitive when it comes to SOTA performance, but today in 2026?
The promise of RISC-V is probably not that it cuts pennies of a $1 embedded ARM core (or dollars off a $100 core).
Instead, it’s that Moore’s law keeps on trucking along, so now we have lots of dark silicon (you cannot turn the whole core on at once, or it will turn into a puddle of glass) and specialized silicon.
RISC-V removes all the gatekeepers (except TSMC and the other fabs) that historically blocked new specialized silicon.
I could get an ARM license, but suspect that, at best, that means dealing with sales folks and also building out a legal division just to manage the license.
I could be wrong, but it’s easier to go with the open core, in the same way that I suspect I cannot afford to figure out how much I would have to pay in order to license windows for my servers.
The point with RISC-V is that you can first pick the architecture and then have many potential providers and you are sure to never be stuck with one provider.
Its not the cost that is the major change, its the business model.
Granted ARM potentially gives you part of that, but its still tricky.
And of course this theory only works out if you have enough competitive providers. But that's always questionable.
I think in the server space the story is more about Chinese autonomy from US regulation/control. As long as they're dependent on closed western IP there is risk of being rug pulled, that having their own RISC-V IP eliminates.
In the embedded / microcontroller space it's a different story. License cost there must be absolutely key, and I think less vulnerable on a per unit basis to the RAM etc storage factors you mention. I don't actually know the numbers but I'd expect that as a percent of total BoM cost the ARM license must be higher for microcontrollers than bigger machines? Maybe someone more qualified knows the answer to this.
The article doesn't put much emphasis on it, but like it says this is still a development system. It's not intending itself to be competitive with ARM and x86 servers for the typical server buyer in 2026.
Yeah it seems to be aimed at people wanting to do Risc-V CI for future stuff, not as a "Real" product thats competitive. They need software to work on Risc-V to sell stuff in future.
having dev unit ci machines is incredibly useful. one of the most annoying parts of supporting macos is having to rack mount a dozen Mac minis to operate ci (and having a robot/human to power cycle them when they crash since their netboot is buggy
It's TSMC N6. What does that information benefit you? We're still talking about a boutique chip that's not going to outperform anything from the past decade's worth of amd64 products.
Because process affects performance per watt more than architecture so its a useful data point.
Even knowing nothing about performance, knowing that it is N6 means it probably isnt particularly power efficient (as compared to leading edge x86/ARM).
That chip is actually reasonably power efficient, not very far away from leading edge x86 assuming 180W TDP. At 120W, the RISC-V server is on par or even exceeds the power efficiency of the x86 system.
Yep, you compare chips on the same level of silicon process.
I was curious to see how far RISC-V still have to go from a microarchitecture stand point, but even in the same silicon process level, there are other things to take into account: the RISC-V compiler support, and something which is really new: since RISC-V is a non-IP-lock worldwide standard, assembly writting is much more a reasonable thing.
And not just the same level of silicon process, as with a reference point, it is possible to further extrapolate using knowledge of differences between process nodes.
> Support for double-wide GPUs (Up to 450W)
I wonder how the driver situation is. From Jeff Geerling's work on running "big" GPUs on Raspberry Pis, my impression is that often less-common platforms should work but are littered with papercuts in practice.
AMD GPUs have worked on RISC-V for a couple years at this point. I have a Milk-V Titan that's paired with an AMD GPU running well: https://milkv.io/titan
Maybe a Zen microarchitecture with a RISC-V/RVA front-end?
While thinking about it, if NVIDIA or SAMSUNG go performant RISC-V CPU micro-architecture, will "probably" change the world.
…and when it comes to the most common use of big-iron GPUs right now, neural network engines, they're all so poorly put together that a papercut is often fatal. If every dependency isn't the exact needed version, the whole thing will collapse, and using all but the most common hardware is sure to be unsupported in some deprecated library version that is absolutely required to get everything running.
I had thought Xilinx ISE and Altera Quartus had the market cornered on the most difficult environments to get running, but then LLMs and stable diffusion came along.
You haven’t lived until you have done a model training run where different stages require mutually incompatible nvidia driver revisions and everything on top.
> I had thought Xilinx ISE and Altera Quartus had the market cornered on the most difficult environments to get running, …
These tools were the reason why I gave up on FPGAs years ago and chose to spend my time on GPUs instead. And to this day, I still don't understand why they worked so differently from what I had expected in so many ways.
I highly recommend getting a small, cheap FPGA development board with something supported by Yosys, like a Latice ICE40UP5k, Efinix T8F81C2, or GOWIN GW1NR-9.
Yosys is a super lightweight open-source FPGA toolchain that really easy to get up and running. The FPGA models I mentioned have ~5k to ~10k LUTs, can all support simple RISC-V processors, and have built-in memory and DSPs.
That's why _LEAN_ open source is really required, and that includes the SDK.
What does "LEAN" mean in this context? (I'm not familiar and 10 seconds of duckduckgo didn't answer)
lean from a technical point of view: size and complexity. That would include the SDK, namely the complexity of the syntax of used computer language (for instance excluding de facto c++ and similar), the build system, the amount of dependencies, etc.
Somehow the RISC-V designs mostly seem to have more coherent PCIe implementations, meaning some devices are easier to get running without the arm64 quirks drivers have to work around.
Drivers still need tweaking, most of the time, since most are still built assuming an amd64 world.
> Support for double-wide GPUs (Up to 450W)
oh a double wide surprise for the AI industry? just what we needed.
RISC V making its way into proper server platforms is a huge milestone. The open architecture could eventually disrupt the current vendor lock in we see in cloud data centers.
I don't doubt RISC-V can be used to make powerful cores but adoption as a general purpose CPU (rather than MCU) will need more than good numbers.
There's still a missing piece in the RISC-V ecosystem: a coordination body of platform-level standards. Debian took a stand with RVA23 support but then there's a ton of little things that are taken for granted on the PC platform such as UEFI and ACPI (as horrible as they may be).
risc-v is basically borrowing the ARM SystemReady stuff. This includes the expectations for ACPI and UEFI on servers. The RISE organization has been trying to drive these standards iiuc.
>Debian took a stand with RVA23 support
Debian? Sure you don't mind Ubuntu?
It's fine, they'll just make a high performance extension set
Which axis of vendor lock in are you seeing possibly being disrupted by this? x86 is rather dominant, though ARM is making a play. RISC V just means AWS offers a different ISA on compute, you'd still be vendor lock-in'd to AWS/whomever. Or I'm totally not getting it.
Obviously not OP, but:
Lock-in to x86 or ARM is painful from an operator like AWSs perspective. With x86 you end up with two vendors to play off against each other, which isn't great. ARM gives you the ability to design your own silicon, but you're still beholden to a single licensor -- arguably worse. On top of that, some customers mandate a specific ISA or even a specific vendor, so none of it is truly fungible outside vertically integrated workloads like S3.
The ideal scenario for a hyperscaler is an open architecture at the core with 10+ competing implementations -- including potentially their own.
> The ideal scenario for a hyperscaler is an open architecture at the core with 10+ competing implementations -- including potentially their own.
This is what Arm actually is. Arm primarily functions as a talking shop for random insights to get back from integrators into the ISA and architecture, then cleared and released for everyone to use. The reason there are so few novel implementations of it is it just isn’t worth the trouble unless you are pushing mobile levels of units.
On top of that, some customers mandate a specific ISA or even a specific vendor, so none of it is truly fungible outside vertically integrated workloads like S3.
I would be very interested to be a fly on the wall when a customer attempts to mandate to AWS they must support an ISA that AWS doesn't have plans to support out, say, a decade[1]. That would be almost as amusing as the many, many times I've heard clients say "we spend $X million dollars with Microsoft! We're a Big Company! We have leverage! Of course they'll do what we want!". And the local M$ salesthing just smiles nods and says "I'll get back to you on that..." and for some reason Nadella doesn't return their calls.
[1] Maybe if one of the big nations says "thou shalt only use our glorious domestic processor, and the processor of thine enemy shall be verboten, for all the data things" or some such...but not a commercial enterprise.
Considering how consolidated the hyperscalar market is and their natural inclination to reduce hardware SKUs, I'm not entirely sure they would make it viable for multiple vendors to produce chips they could actually use. There is no reason to believe it'll work out differently from the ARM server market.
[flagged]
https://camel-cdr.github.io/rvv-bench-results/sifive_p870/in...
what is the boot environment like for these type of platforms?
is it opensource or megs of blob?
It varies a lot by vendor. The older SiFive P550 is pretty good, see these forum threads: https://forums.sifive.com/t/where-is-the-source-code-of-the-... https://forums.sifive.com/t/building-opensbi-and-uboot/7681/...
256gb ddr5, so this is going to cost north of 100k? Damn.
Seems like the memory is of a socketed type, so I'm sure they'd send you one without RAM if you want :D.
No way, it's only like 4x64 GB of ECC DDR5 5600 RDIMMs. Who's paying $100k for that? I'll gladly sell them this at a 10% discount.
Not to knock on RISC-V, which I’ve been following from the embedded side of things for many years now, but I feel I must question the value of a license-free ISA in this specific market segment at this time.
Surely between the squeeze on RAM and storage pricing and the exorbitant costs of training or mass-inference scale GPUs (if you’re going into AI), the nominal cost of the CPU licensing is really not going to make or brake anything or unlock some new business viability?
Even RISC-V aside, we are essentially in a position that would have been impossible to even dream of ten or twenty years ago when Intel was the only player in the game.
Wouldn’t buying off-lease hardware (not even in bulk) give you better performance per dollar, better compatibility, and more options?
Not to say any of this will always be the case; even if RAM pricing doesn’t come down, storage will, and RISC-V processors will (maybe) eventually actually be competitive when it comes to SOTA performance, but today in 2026?
The promise of RISC-V is probably not that it cuts pennies of a $1 embedded ARM core (or dollars off a $100 core).
Instead, it’s that Moore’s law keeps on trucking along, so now we have lots of dark silicon (you cannot turn the whole core on at once, or it will turn into a puddle of glass) and specialized silicon.
RISC-V removes all the gatekeepers (except TSMC and the other fabs) that historically blocked new specialized silicon.
I could get an ARM license, but suspect that, at best, that means dealing with sales folks and also building out a legal division just to manage the license.
I could be wrong, but it’s easier to go with the open core, in the same way that I suspect I cannot afford to figure out how much I would have to pay in order to license windows for my servers.
The point with RISC-V is that you can first pick the architecture and then have many potential providers and you are sure to never be stuck with one provider.
Its not the cost that is the major change, its the business model.
Granted ARM potentially gives you part of that, but its still tricky.
And of course this theory only works out if you have enough competitive providers. But that's always questionable.
I think in the server space the story is more about Chinese autonomy from US regulation/control. As long as they're dependent on closed western IP there is risk of being rug pulled, that having their own RISC-V IP eliminates.
In the embedded / microcontroller space it's a different story. License cost there must be absolutely key, and I think less vulnerable on a per unit basis to the RAM etc storage factors you mention. I don't actually know the numbers but I'd expect that as a percent of total BoM cost the ARM license must be higher for microcontrollers than bigger machines? Maybe someone more qualified knows the answer to this.
The article doesn't put much emphasis on it, but like it says this is still a development system. It's not intending itself to be competitive with ARM and x86 servers for the typical server buyer in 2026.
Yeah it seems to be aimed at people wanting to do Risc-V CI for future stuff, not as a "Real" product thats competitive. They need software to work on Risc-V to sell stuff in future.
> SiFive isn’t trying to beat x86 or Arm with the BigSky platform and it doesn’t have to. This is a development system
A 2U dev unit? Seems a bit premature..
having dev unit ci machines is incredibly useful. one of the most annoying parts of supporting macos is having to rack mount a dozen Mac minis to operate ci (and having a robot/human to power cycle them when they crash since their netboot is buggy
Can’t see myself buying my this but glad riscv is making progress.
All the linux distros and android packagers need boxes like bigsky for CI pipelines
Missing the silicon process.
It's TSMC N6. What does that information benefit you? We're still talking about a boutique chip that's not going to outperform anything from the past decade's worth of amd64 products.
Because process affects performance per watt more than architecture so its a useful data point.
Even knowing nothing about performance, knowing that it is N6 means it probably isnt particularly power efficient (as compared to leading edge x86/ARM).
That chip is actually reasonably power efficient, not very far away from leading edge x86 assuming 180W TDP. At 120W, the RISC-V server is on par or even exceeds the power efficiency of the x86 system.
https://www.sifive.com/blog/sifive-empowering-a-new-era-of-d...
According to that graph, the P870 has 80% of the performance of Ice Lake.
>It's TSMC N6. What does that information benefit you?
We can compare performance with other TSMC N6 designs. Even more so if we also know the area and power.
>not going to outperform anything from the past decade's worth of amd64 products.
This isn't some U74. This is P870. Its published performance data is no joke.
Yep, you compare chips on the same level of silicon process.
I was curious to see how far RISC-V still have to go from a microarchitecture stand point, but even in the same silicon process level, there are other things to take into account: the RISC-V compiler support, and something which is really new: since RISC-V is a non-IP-lock worldwide standard, assembly writting is much more a reasonable thing.
And not just the same level of silicon process, as with a reference point, it is possible to further extrapolate using knowledge of differences between process nodes.
Knowing it is TSMC N6 unlocks at least this much.
[flagged]
Clean logic, easy to follow