Condor Computing's Cuzco, a High-Perf RISC-V Design at Hot Chips 2025

[-]

moofunk@reddit

Jim Keller talked about how you have no IP limitations on how you can modify or extend a RISC-V chip design.

For Tenstorrent, they initially were going to use ARM, and asked the consortium, if they could add a custom high performance vector engine to an existing design to use in their own product. The consortium said no. With RISC-V, there is nobody to ask, so you just do it. Tenstorrent's entire business model revolves around the openness and license free model of RISC-V.

RISC-V is not being pursued for the sake of being a hot new fad, but because you can do any kind of custom extension for it without having to ask anyone permission or pay someone a license fee.

As for why it's popular in the embedded space, you don't have to design your own chip ISA and toolchain anymore. You can take the RISC-V ISA and use it as to design a controller for your hardware and use existing code compilers. Hence, so much hardware today piggybacks one or several complete RISC-V cores, often in secret.

We're going to see some interesting chip designs now from quite many startups, thanks to RISC-V.

[-]

ghenriks@reddit

The ability to do whatever you want works for embedded where maintaining (or never updating) a compiler can be viable

But custom extensions will be a problem in the mainstream market (think x64, Apple M) as there will be limits to how much support the LLVM or gcc maintainers will be willing to add to their products given the long term maintenance costs

So the ability to do custom hardware isn’t relevant for mainstream acceptance

[-]

moofunk@reddit

You're maintaining a compiler anyway, regardless of what kind of chip you're going to be building or extending. It's the same maintenance burden, if you pick RISC-V or some other architecture or make your own.

The user facing advantage to RISC-V will mainly be lower cost chips, less product segmentation between consumer/pro/enterprise and unique chip designs from startups that do new things that will require even more unique software support. I mentioned Tenstorrent as such a company and they produce unique user facing hardware with custom extensions as well as the software to support it.

It's less "RISC-V is going to stomp all over ARM and x86 in 5 years with faster CPUs for gamers and be absolutely mainstream" and more "RISC-V is going to make unique chip designs on all performance levels more common in user facing products."

Of course there may also be 1:1 substitutes for the common x86 chips to make the gamers happy, and with that, hopefully much less hand wringing over support for vector instructions on ordinary consumer CPUs and dumb artificial segmentation of feature sets and core counts between consumer, workstation and enterprise CPUs.

[-]

ghenriks@reddit

You're maintaining a compiler anyway, regardless of what kind of chip you're going to be building or extending.

I suspect that will be news to Microsoft and the LLVM and GCC maintainers, who are the ones doing all the heavy lifting. And then there are all the other languages with their own code generators like Go, Python, Java, etc.

The user facing advantage to RISC-V will mainly be lower cost chips,

Maybe. Even though RISC-V is open source anyone building a decent chip still needs expensive hardware engineers and the cost of licensing all the relevant hardware patents (possibly including patents held by ARM). In the end saving the ARM licensing fee may not be as big a deal as some think it is.

"RISC-V is going to make unique chip designs on all performance levels more common in user facing products."

Doubtful.

There is a reason RISC-V is going heavily into standards like RVA23, and that's because the compiler and OS maintainers are demanding it. And developers will also want it when reasonable hardware becomes more available, see the troubles of AVX512 which is only finally being taken seriously now that AMD has implemented it given the mess of implementing it Intel made.

And it's not just me saying it, see this quote from RISC-V (1) when announcing RVA23 -

"The newly ratified RVA23 Profile is a major release for the RISC-V software ecosystem and will help accelerate widespread implementation among toolchains and operating systems."

The only place the ability to deviate from standards will happen will be with add in cards like what Tenstorrent is currently doing and where maintaining a unique software stack is viable (just like Nvidia does with CUDA, AMD with ROCm, etc).

But that is not what most people are thinking of when they dream of RISC-V taking over the world.

1) https://riscv.org/riscv-news/2024/10/risc-v-announces-ratification-of-the-rva23-profile-standard/

[-]

moofunk@reddit

Maybe. Even though RISC-V is open source anyone building a decent chip still needs expensive hardware engineers and the cost of licensing all the relevant hardware patents (possibly including patents held by ARM).

In the end saving the ARM licensing fee may not be as big a deal as some think it is.

It's not a matter of paying the fee. It's a matter of being allowed to make a chip at all. The consortium can completely deny permission and will sue you into the dirt, if you try. This can be due to your business case for the chip not be seen as viable by the consortium, even if you disagree with it.

Nobody will stop you with RISC-V. This can be important for economic and geopolitical reasons and certainly is for China and EU.

Doubtful. There is a reason RISC-V is going heavily into standards like RVA23...

You can have interesting designs under these profiles as well. There will be one for automotive, as this sector is increasingly interested in moving to RISC-V.

Even, if you don't do any extensions at all, you are free to design strange machines, like a 1000-core 32-bit CPU, if you want such a thing.

[-]

ghenriks@reddit

But we are talking about different markets

I stated at the outset that the embedded market is special (aka automotive)

And the add in market is special (aka current Tenstorrent)

But when you talk mainstream chips (aka what this Reddit post is about) standardization is all that matters

Yes, China and to a lesser extent the EU are interested in RISC-V. But not for your exotic unique extension reasons but for a standard conforming CPU to replace x64 or ARM in mainstream or HPC computing where the actual or threatened restriction of supply by the US is a problem

And those uses require LLVM and GCC support

[-]

qzrz@reddit

It doesn't really require LLVM and GCC support all that much, not sure if you are aware how those compilers work. Everything is done using bytecode, and then that is ultimately converted to machine code. So risc-v adding a "new" feature that exists on ARM isn't going to be all that difficult to implement for risc-v in LLVM. There's a reason LLVM can compile to so many different machine languages, what you are describing isn't an issue.

As well performance specific code still is written in assembly. For things like avx as the compiler simply isn't good at generating or determining that it could be used. Like the JSON parser that uses avx-512, you can't flick on the avx512 feature and expect it to just make the parser that much faster.

[-]

ghenriks@reddit

Your missing what I’m saying

I’m not saying support for RISC-V is an issue

I’m saying supporting X different variants of RISC-V is an issue as you then need access to X times the amount of RISC-V hardware for testing and bug fixing, it increases your code etc

The RISC-V proponents are essentially saying every RISC-V chip can be unique because it’s open source and thus everyone can do what they want

We already see what a mess this makes with the cheap ARM boards where some company in China makes a SOC, sort of hacks Linux support, doesn’t upstream anything and throws it onto the market with no support

This is why the serious RISC-V people are belatedly moving to a standards process resulting in RVA23. Because RISC-V isn’t going mainstream without a standard for the compilers and OS groups to support

(Which is different than the embedded stuff or an add-in card)

[-]

qzrz@reddit

Your missing what I’m saying

I’m not saying support for RISC-V is an issue

I’m saying supporting X different variants of RISC-V is an issue as you then need access to X times the amount of RISC-V hardware for testing and bug fixing, it increases your code etc

The RISC-V proponents are essentially saying every RISC-V chip can be unique because it’s open source and thus everyone can do what they want

Yes I know this is what you are saying, you are missing what I am saying: it already is like that. Every generation, product line, or otherwise all have their own feature sets that are all different. AMD creates their own instruction sets that are only on AMD. Same with Intel. This extends far past CPUs, into GPUs, as well as APUs and now with NPUs. The claim you are making contradicts reality. If you compile a program targeting a specific CPU like Zen 5, odds are that program isn't going to work on a Zen 4 CPU.

If someone makes a custom feature, they maintain it themselves, literally like it's done currently for CPUs and GPUs. This isn't some grave problem that has never happened before. Would you rather there be no market like for x64 for third party chip vendors because it is so locked down, there just simply aren't all these different chips cause it is literally just a duo/monopoly. That is not better.

This is why the serious RISC-V people are belatedly moving to a standards process resulting in RVA23. Because RISC-V isn’t going mainstream without a standard for the compilers and OS groups to support

This is literally the advantage of RISC-V. You have this base standard RISC-V that is already mainstream. It's in the main compilers used by Linux. There are popular distros that are releasing RISC-V versions. You can buy RISC-V hardware off the shelf as an individual at a low cost. Which, again, contradicts your argument. Support for RISC-V is already in the compilers, it's already there, it's already supported. Every RISC-V that maintains the bare minimum regardless of custom feature sets will be able to run every RISC-V binary.

Otherwise, you have what happens with ARM and Qualcomm. Where qualcomm made a custom ARM CPU using the custom designs from a company they bought. Qualcomm has the license to make custom CPU designs, and the company they bought also did from ARM. ARM still wanted them to stop selling the CPU, not only that, they wanted them to destroy the designs. Not even negotiate a contract with the correct terms. ARM obviously lost, but it shows the control they have over the CPUs, their manufacturers and wanted something so unreasonable.

[-]

ghenriks@reddit

Would you rather there be no market like for x64 for third party chip vendors because it is so locked down, there just simply aren't all these different chips cause it is literally just a duo/monopoly.

Look at reality. The market doesn't like uniqueness, it confuses people and given the danger of buying the wrong hardware they will simply buy whatever provides that safety of standardization.

Look at the struggles of ARM in the mainstream market, where most people avoid a Windows ARM machine because of the fear their software won't run. No such worries when choosing between AMD or Intel.

The only way a competitive market gets created for RISC-V (or ARM) is if the CPU's all follow a standard so that the OS of choice and the wanted software all run on that hardware without needing to be recompiled. Hence RVA23.

You can compete on price, cores, PCIe lanes, memory support, any number of areas. But binary compatibility is non-negotiable if you want a successful thriving market.

Which, again, contradicts your argument. Support for RISC-V is already in the compilers, it's already there

No it doesn't.

The Linux vendors are already saying going forward it will be RVA23 or nothing. They aren't going to repeat the support nightmare of the cheap ARM boards where every piece of hardware is unique.

Same thing with the compilers. They will support RVA23 but won't necessarily support any unique feature to a specific CPU - because the market doesn't like unique CPUs

You want to be unique then do so in the add on market.

Otherwise, you have what happens with ARM and Qualcomm

RISC-V won't be immune. It may not be a question of whether a license allows something or not, but making modern desktop/server/workstation/hpc class hardware involves a lot of patents and any RISC-V vendor will need to tread carefully or they also will be in court.

And then there is the fact that in the vacuum of no ARM International (because despite what RISC-V fans think ARM does provide value for that license fee) if you have RISC-V vendors stepping in and doing the same thing. Look at the licensing Tenstorrent is doing of their RISC-V IP, and they will if needed use the courts to enforce whatever license terms have been agreed to as will anyone else licensing RISC-V IP.

Because there is no free lunch. You either pay someone like Tenstorrent or ARM to do some of the work are you pay for your own employees to do it.

[-]

ghenriks@reddit

If you compile a program targeting a specific CPU like Zen 5, odds are that program isn't going to work on a Zen 4 CPU.

Now your just being silly, because unless you are using a niche OS like Arch Linux nobody compiles explicitly for Zen 4 or Zen 5 (which is why ironically doing so is a bad idea, because any differences aren't getting widespread testing).

AMD creates their own instruction sets that are only on AMD. Same with Intel.

Yep. And it has been so bad and the market has rejected it so much that they are actually now working together to move x64 forward together

https://www.servethehome.com/hell-freezes-over-amd-and-intel-come-together-ocp/

Why? Because the mainstream market wants standardization of their CPUs and not everyone doing their own thing.

The market spoke when it ignored AVX512 when Intel tried making it an Intel Server only feature, and it only gained acceptance when AMD implemented it.

Which is the point you are persistently ignoring. When it comes to CPU's the market does not want uniqueness, it wants something that "just works". Hence RISC-V belatedly realizing they need to standardize, because if they don't the market will ignore them.

GPUs, as well as APUs and now with NPUs.

Again, you keep bringing this up, but we are talking about CPU's and not all that other stuff.

[-]

moofunk@reddit

I posted Jim Keller's comment as a response to "why do people care about RISC-V". That's really all.

[-]

SecretTop1337@reddit

Honestly, I wouldn’t be surprised at all to see Apple announce their new Apple Silicon V chips based on RISC-V 10-15 years from now.

[-]

ghenriks@reddit

I won't say no, but I don't expect it and would be very surprised if it happened.

RISC-V doesn't offer anything meaningful to Apple that they don't already have with ARM.

The cost of bringing an M class chip to market - hiring expensive engineers, the software required, the patent licenses that would be required - mean the license fee Apple pays ARM isn't going to be a major cost.

Now add in the cost of moving the Apple ecosystem - extra engineers/developers to port and test the OS and all its libraries, write new documentation, the cost to all the 3rd party software providers - and you need a really significant reason to do the change.

[-]

neuroticnetworks1250@reddit

China is going all in on it. I keep hearing more news about RISC-V than even LoongArch nowadays. Nvidia is also porting CUDA to RISC-V.

[-]

Affectionate-Memory4@reddit

It's a much more open ISA than many others, which means developing your own chip is cheaper and more flexible. You aren't beholden to anyone licensing you the core like with ARM for example.

It's already quite widespread in the embedded space as well, being in a ton of MCUs and dedicated controllers for things like drives. It's also starting to appear in larger-scale chips by the likes of Alibaba, so there's a lot of interest in making better cores to close the gap with more established ISAs.