NVIDIA GPUs Pack 10-40 RISC-V Cores for Control Tasks
Each NVIDIA GPU includes 10-40 RISC-V cores for non-graphics control. Explaining the transition from Falcon.
NVIDIA’s current GPUs contain numerous RISC-V cores separate from the main graphics processing cores. According to reporting by Edwards at Solidot, more than 1 billion RISC-V cores in total were used in 2024 shipments alone. Depending on the model, each GPU carries 10 to 40 cores, used not for graphics but for auxiliary control tasks.
NVIDIA announced it used more than 1 billion RISC-V cores across its GPU products in 2024.
This fact cannot be captured by looking only at the balance of power among instruction sets. A GPU is both a massive parallel compute engine and a collection of many tiny controllers bundled together. The significance of this disclosure lies in showing that reality in numbers.
Cores for Auxiliary Processing, Not Graphics
The RISC-V cores are not involved in vertex processing or shading. They handle peripheral tasks such as managing power-up sequencing, adjusting clock signals, monitoring voltage and temperature, video encoding and decoding, and executing security functions. All run continuously behind the scenes, supporting product stability and safety.
Inside a GPU, the larger the compute resources, the more there is to control. Higher-end products have more power domains to monitor and more security partitions. The range of 10 to 40 per GPU naturally reflects differences in control load across product tiers.
This structure is not limited to a specific generation. According to the XDA Developers article cited by Solidot, it covers the entire 2024 GPU lineup. The fact that cores invisible in individual product spec sheets reached a scale of 1 billion per year carries weight. It shows that heterogeneous integration in chip design has become the norm rather than the exception.
Support for the instruction set also extends to the toolchain. For example, the extension support and faster linking covered in GNU Binutils 2.47 Released with RISC-V Extensions and Faster Linking directly affect development efficiency for such embedded uses. As the number of control cores grows, well-maintained build tools determine the pace of product development.
Shift from Proprietary Falcon Controllers
NVIDIA previously used a proprietary microcontroller called FAst Logic CONtroller, abbreviated as Falcon. It was first introduced with the G98 in 2005, and the number of units grew with each generation. By 2016, a single GPU die reportedly integrated more than 15 different Falcon engines.
The total number of Falcon cores used over 10 years reached about 3 billion. Applications ranged from video encoding and decoding to power management and security engines. Small controllers filling the gaps between large graphics circuits had accumulated to an enormous total.
Falcon was a 32-bit core and, according to surviving documentation, had no data cache. It was suited to simple sequential control and routine tasks, but struggled to keep up with growing functionality and more demanding security requirements. NVIDIA’s search for a replacement can be seen as a matter of design sustainability rather than raw performance.
Support on the system software side is also expanding. As shown in Linux 7.2 Enables UltraRISC RISC-V Support in Default Builds, support for the architecture is becoming a default build target. Even as control cores multiply, development continuity is preserved if kernels and base tools are in place.
Why NVIDIA Chose an Open Instruction Set
After evaluating multiple instruction sets, including Arm and MIPS, NVIDIA chose the open RISC-V. Open here means the specification is public with no licensing fees and extensions can be defined independently. The advantage is freedom from dependence on a specific vendor and the ability to adopt only the features needed for each product.
For control cores, ease of tuning for each use matters more than absolute compute performance. Security partitions demand verifiability, power management demands reliable responsiveness, and video processing demands efficient routine operations. Rather than covering everything with a single general-purpose core, it is more rational to share a base and vary it through extensions.
RISC-V includes a method for defining extensions in its specification and can start from a minimal configuration. The design philosophy is to remove unneeded instructions and add only necessary extensions. This fits well with the variation of 10 to 40 cores per chip. Even when core configurations differ by product tier, toolchains and verification methods can be shared.
The choice also makes sense from a supply-chain perspective. Maintaining a proprietary core incurs costs for toolchains and verification environments. Sharing specifications with an external ecosystem makes hiring and reuse easier. At a scale of 1 billion per year, even small differences in development efficiency have a large impact on total cost.
What Cumulative Shipment Scale Says About Design
The figure of more than 1 billion in the single year of 2024 is symbolic for RISC-V adoption. Apart from use in mobile devices and small computers, it revealed massive consumption for control inside GPUs. The open instruction set had already reached mass-production scale in places invisible to users.
The comparison with the cumulative total of about 3 billion in the Falcon era is also suggestive. Experience building up 3 billion proprietary cores may have pushed the shift to an open standard. It is reasonable to see it as the result of weighing the burden of maintaining a toolchain alone against the benefits of joining a shared ecosystem.
This change also relates to the definition of a GPU. A GPU is both an accelerator for graphics and matrix operations and an integrated component that ties together power, security, and video. If the number of control cores becomes an indicator of product tier, users will choose products not only on compute performance but on the quality of control.
The future focus is how much of the core configurations will be disclosed. So far, only the range of counts, an overview of uses, and the background of the transition have been shown. Specific configurations of each engine, interconnects, and update mechanisms have not been published. While security-related parts have disclosure limits, attention is on whether developer documentation will be expanded.
Editorial Opinion
On the short-term impact. We expect this disclosure to boost development demand for control cores over the next three to six months. Toolchains and verification environments will improve, and RISC-V experience will more often appear in hiring and design-contract requirements. Documentation on power management and security functions around GPUs will expand, and related companies will accelerate their responses.
On the long-term view. In the one- to three-year range, we expect heterogeneous integration inside accelerators to become standard design practice. Alongside performance competition among compute engines, reusability and verifiability of control cores will differentiate product value. The move to share open specifications will likely spread to other accelerators, making the cost of maintaining proprietary cores relatively heavier.
A question from the editors. The remaining issues are configuration transparency and verifiability. While we understand that details of security partitions cannot be disclosed, could update procedures and lifecycle management concepts be shared. As users enter an era of choosing products with control cores in mind, we believe the question is what information should be opened.
References
- “每个 英伟达 GPU 包含了 10-40 个 RISC-V 核心”, by (author unknown) — Solidot, 2026-09-20T16:41:20.000Z (ARR)
- Source URL: https://www.solidot.org/story?sid=85436
Frequently Asked Questions
- What do the RISC-V cores in NVIDIA GPUs do?
- Rather than graphics or parallel computing, they handle auxiliary tasks such as power management, temperature monitoring, video encoding and decoding, and security functions. Each product carries 10 to 40 cores, with higher-end products integrating more because there is more to control.
- How is it different from the earlier Falcon?
- Falcon was NVIDIA's proprietary 32-bit microcontroller with no data cache. It grew to more than 15 different engines on a single die, but became difficult to adapt to expanding functionality, leading to the shift to open and extensible RISC-V.
- Why was RISC-V chosen over Arm or MIPS?
- The reason is that its specification is open with few licensing constraints, allowing each product to adopt only needed extensions. Because configurations can vary while sharing toolchains and verification methods, it is well suited to mass production at a scale of 1 billion per year.
Comments