NVIDIA Defines RISC-V Requirements for CUDA and NVLink Fusion

NVIDIA Defines RISC-V Requirements for CUDA and NVLink Fusion

At a Hot Chips 2026 tutorial session, NVIDIA outlined the hardware and software requirements for integrating RISC-V server CPUs into the CUDA and NVLink Fusion ecosystems.

The presentation did not announce a specific RISC-V processor, nor did it provide performance or power figures for any potential CPU. Instead, NVIDIA focused on the platform standards required to make RISC-V a viable host architecture for GPU-accelerated servers.

Those requirements span CPU ISA compatibility, firmware standards, PCIe hardware coherency, peer-to-peer communication, high-bandwidth chip-to-chip interconnects, and the supporting software stack.

The broader message is clear: bringing RISC-V into CUDA is not simply an ISA-porting exercise. The entire server platform needs to meet a common set of compatibility and interoperability requirements.

🧩 What Does CUDA Require from RISC-V Server CPUs?

#

CUDA is NVIDIA’s parallel computing platform. In a typical CUDA workload, GPUs handle highly parallel computation while CPUs execute sequential control logic, scheduling, operating-system tasks, and other general-purpose processing.

NVIDIA currently supports x86 and Arm as host CPU architectures. Extending CUDA host support to RISC-V therefore requires more than compiler and software changes. The underlying server platform also needs standardized behavior.

NVIDIA’s requirements include:

RVA23 Provides the ISA Baseline

#

The RVA23 Profile is an important foundation for software compatibility.

Rather than allowing every RISC-V processor implementation to expose a different combination of ISA extensions, Profiles establish standardized combinations of required capabilities.

For a large software ecosystem such as CUDA, this reduces the risk that applications and system software will need to target the lowest common denominator across different RISC-V implementations.

The goal is straightforward: software should be able to run across RISC-V server CPUs from different vendors without extensive processor-specific adaptation.

Binary Compatibility Matters

#

Server software depends heavily on predictable platform behavior.

If RISC-V processors from different vendors implement substantially different instruction-set extensions, firmware interfaces, or system services, the same binary may not run consistently across platforms.

That is why NVIDIA’s requirements extend beyond the CPU ISA itself to include the RISC-V Server SoC and Platform specifications and Boot and Runtime Services.

Together, these standards provide a more consistent foundation for operating systems, drivers, CUDA libraries, and other host-side software.

⚙️ Firmware Standardization Is Equally Important

#

ISA compatibility represents only one layer of a server platform.

Operating systems, firmware, virtualization software, device drivers, and accelerator stacks also depend on standardized mechanisms for hardware discovery, system initialization, power management, and runtime services.

ACPI 6.6, approved by the UEFI Forum in 2025, added support for RISC-V. The RISC-V Boot and Runtime Services specification subsequently provided additional standardized interfaces for server boot and runtime environments.

The resulting software and firmware stack can be viewed as:

ISA → Firmware → Operating System → Drivers → CUDA Software Stack

This is an important distinction. Porting CUDA to RISC-V is not simply a matter of recompiling existing software for a new instruction set.

🔄 PCIe Hardware Coherency Becomes a Key Requirement

#

CUDA workloads frequently move data between host memory and device memory.

A typical processing pipeline can involve:

Host-to-Device Copy → Kernel Launch → Device-to-Host Copy → CPU Processing

Without hardware-level I/O coherency, software may need to perform additional cache flushes and invalidations to ensure that CPUs and devices observe consistent data.

Hardware coherency can reduce those software-level operations, simplify system implementation, and potentially lower data-access latency.

NVIDIA therefore identifies PCIe I/O coherency as an important requirement for RISC-V CUDA platforms.

For high-performance AI servers, this becomes particularly significant because CPU-GPU workloads often involve continuous data movement rather than isolated CPU and GPU operations.

🔗 PCIe P2P Enables More Efficient Multi-GPU Communication

#

Another important requirement is PCIe Peer-to-Peer (P2P) communication.

In a multi-GPU server, P2P allows one GPU to directly access another GPU’s device memory without first routing the data through host memory.

A simplified path looks like this:

GPU 0
  │
  │ PCIe P2P
  ▼
GPU 1
  │
  ▼
Device Memory

By bypassing unnecessary CPU and host-memory transfers, P2P can reduce data movement and improve efficiency when multiple GPUs cooperate on the same workload.

This capability is particularly relevant to AI training, inference, and other workloads that require frequent GPU-to-GPU communication.

Taken together, these requirements indicate that NVIDIA is targeting server-class RISC-V CPUs with comprehensive memory and I/O capabilities, rather than embedded or consumer-oriented RISC-V processors.

🚀 NVLink Fusion Raises the Interconnect Bar

#

PCIe provides a standardized path for connecting RISC-V CPUs to NVIDIA GPUs, but NVLink Fusion targets much tighter integration for high-density AI systems.

NVLink Fusion enables custom CPUs to connect to XPUs through NVLink C2C (Chip-to-Chip) technology while supporting high-bandwidth communication and CHI-based coherency.

The objective is to create a much tighter CPU-GPU connection in which processors and accelerators can access memory within a more unified architecture.

For custom CPU vendors, this introduces requirements beyond conventional PCIe connectivity.

What Additional Capabilities Does NVLink Fusion Require?

#

A CPU designed for NVLink Fusion must inherit the broader CUDA platform requirements while also providing significantly higher-bandwidth chip-to-chip connectivity.

NVIDIA describes the required C2C bandwidth as roughly equivalent to 88 PCIe lanes. The supporting software environment also needs components such as:

• DOCA networking and infrastructure software
• NCCL for multi-GPU communication
• High-bandwidth C2C connectivity
• CHI coherency
• CUDA ecosystem compatibility

As a result, NVLink Fusion is not simply another physical interface. It represents a broader CPU platform integration strategy spanning silicon, interconnects, memory coherency, and software.

🏭 Vera Rubin Illustrates NVIDIA’s Full-Stack Strategy

#

NVIDIA’s Vera Rubin AI Factory platform demonstrates this broader system-level approach.

The platform combines CPUs, GPUs, networking, storage, and scale-out interconnects across multiple chips and rack levels, ultimately forming systems such as the NVL72 full-rack platform.

This reflects NVIDIA’s broader direction for AI infrastructure: the CPU is increasingly becoming a tightly integrated component of the accelerator platform rather than simply a general-purpose processor sitting beside the GPU.

For RISC-V vendors, this means future participation in high-end NVIDIA AI systems will depend not only on CPU performance, but also on how effectively the CPU integrates with GPUs, memory, networking, and system-level interconnects.

🧠 SiFive Is a Publicly Disclosed RISC-V Partner

#

Among publicly announced RISC-V partners, SiFive has emerged as a notable example.

In January 2026, SiFive announced plans to integrate NVLink Fusion into its high-performance data-center RISC-V solutions, enabling coherent, high-bandwidth connections to NVIDIA GPUs and accelerators.

The announcement provides a concrete example of how RISC-V CPUs could eventually participate in NVIDIA’s accelerator ecosystem.

However, NVIDIA’s Hot Chips 2026 tutorial focused on platform requirements rather than announcing a specific RISC-V processor. No associated CPU performance, power, or commercial availability figures were disclosed in the presentation.

🧱 The Real Entry Barrier for RISC-V and CUDA

#

NVIDIA’s requirements reveal a layered path for RISC-V integration into the CUDA ecosystem:

RISC-V ISA
    ↓
RVA23 Profile
    ↓
BRS / Server SoC / Platform Standards
    ↓
ACPI and Standardized Firmware
    ↓
PCIe I/O Coherency
    ↓
PCIe P2P
    ↓
CUDA Host Software Stack
    ↓
NVLink C2C / CHI
    ↓
NVLink Fusion
    ↓
High-Density AI Servers

This makes the underlying strategy clear: ISA compatibility is only the starting point. Platform standardization is the larger challenge.

For RISC-V CPU vendors, these standards provide a defined path toward building GPU-accelerated server platforms. For NVIDIA, they create a more standardized gateway for incorporating future custom CPUs while maintaining interoperability across the CUDA ecosystem.

🏁 Conclusion

#

NVIDIA’s RISC-V requirements disclosed at Hot Chips 2026 signal a potential path for RISC-V to enter mainstream GPU-accelerated server infrastructure, but the challenge extends far beyond ISA support.

From RVA23, BRS, and server-platform specifications to ACPI, PCIe hardware coherency, P2P, NVLink C2C, CHI, and NVLink Fusion, NVIDIA is effectively defining a complete platform-level framework for RISC-V server CPUs.

The future of RISC-V and CUDA is therefore more likely to depend on CPU, GPU, memory, I/O, interconnect, firmware, and software working as one platform rather than simply porting CUDA software to a different instruction set architecture.

With companies such as SiFive pursuing NVLink Fusion-based solutions, RISC-V’s role in high-performance AI servers will be worth watching. Ultimately, real-world adoption will depend on CPU performance, interconnect bandwidth, software compatibility, multi-GPU scaling, system design, and overall platform efficiency.