CUDA has run on exactly two CPU architectures for its entire life: x86-64 and aarch64. That changed at Hot Chips 2026, where Nvidia detailed plans to bring CUDA to RISC-V, the open, royalty-free instruction set architecture that has spread through embedded chips and academic processors but never cracked the server tier. The stakes are structural. CUDA’s architecture lock is arguably Nvidia’s deepest moat, so opening it to an ISA nobody has to license is a deliberate trade: Nvidia gains a path into custom silicon built by hyperscalers and chipmakers who want their own CPU cores next to Nvidia GPUs, and it risks normalizing an ecosystem it does not control the way it controls x86-64 and aarch64 tooling today.

Nvidia is not opening CUDA to any RISC-V chip. The company set a hardware bar that, per its own presentation, only a narrow slice of server-class silicon can currently clear. A compliant CPU must implement the RVA23 profile and follow RISC-V’s server SoC and server platform specifications, which cover reliability, availability, and serviceability (RAS) features and a dedicated security processor. Those two specs alone satisfy most of what Nvidia wants from a server-grade part.

Beyond the baseline spec, Nvidia added requirements it says are needed because CUDA cannot ship efficient code against a lowest-common-denominator target. Vector extension support is one example: without a guarantee that predication is available, Nvidia’s compilers have to fall back on branches instead, which the company wants to avoid on every supported platform, not just the fastest one.

ACPI support is the requirement Chips and Cheese analyst Chester Lam singles out as the hardest to clear. ACPI lets an operating system discover and manage hardware for power, performance, and thermal control, and RISC-V silicon largely lacked it when Nvidia began the CUDA port. The gap has narrowed on paper: the UEFI Forum added RISC-V ACPI support in 2025, and the RISC-V Boot and Runtime Services (BRS) specification, ratified the same year, folds ACPI in as well. Lam notes that aarch64’s own ACPI adoption stayed inconsistent for years after it appeared in that ecosystem’s standards, and expects RISC-V vendors to lag similarly.

Two more requirements target the CPU-GPU data path. Nvidia wants guaranteed PCIe coherency, so that a DMA transfer to or from the GPU never reads stale data sitting in a CPU cache, a scenario RISC-V’s server SoC spec only recommends rather than mandates. It also wants peer-to-peer PCIe support, so buffers moving between devices skip a detour through CPU memory. Nvidia has not published the complete list: it told the Hot Chips audience the requirements fit on two pages, without saying how dense those pages are.

A parallel track, NVLink Fusion, lets partners license Nvidia’s NVLink interconnect IP to pair a custom CPU (RISC-V included) with an Nvidia GPU, similar to how Mediatek’s CPU die connects to Nvidia silicon in the GB10 module. NVLink Fusion partners must clear every CUDA requirement plus support for Nvidia’s DOCA and NCCL frameworks, and Nvidia expects close engineering cooperation with any partner attempting it.

None of this is shipping yet. Nvidia is partnering with SiFive, which plans to demo a CUDA-capable RISC-V system at Hot Chips, and the CPU specifications Nvidia showed point to a high-core-count server part rather than anything a hobbyist board could match. Lam’s read, shared by this publication, is that essentially no RISC-V hardware on the market today qualifies, and that ACPI alone could keep the list of qualifying systems small for years.

Teams evaluating RISC-V for AI infrastructure should treat this as a server-only roadmap item, not a near-term option for existing boards, and should watch whether Nvidia relaxes the ACPI and PCIe coherency requirements before assuming broader RISC-V hardware will ever qualify.

Chester Lam reported this analysis for Chips and Cheese on August 24, 2026.