Last year, when I walked into the 2024 RISC-V summits in China and North America, the energy was high, but it felt like the message was still a bit cautious. RISC-V was emerging, but not yet central. Fast forward to 2025, and the tone has shifted. This year, the pressure is on. The question is no longer whether RISC-V can attract interest—it’s when it will truly deliver.
RISC-V has moved beyond curiosity. It’s become a geopolitical consideration, a business strategy, and for many teams, a serious engineering commitment. I’m heading into this year’s summit not just to learn, but to track signals:
Who’s building for real-world deployment?
Who’s scaling beyond microcontrollers?
And who’s ready to lead?
From Curiosity to Commitment
In 2024, much of the focus was on embedded and low-power use cases—MCUs, smart sensors, and edge AI. That’s where RISC-V has already made headway. But 2025 is asking more of the ecosystem.
This year’s official summit themes—AI/ML, datacenter, automotive, embedded, and security—are no longer just aspirational buzzwords. RISC-V International received over 220 technical submissions for the 2025 NA Summit, covering serious deployments and toolchain advances across these domains. It’s clear the ambition is to move from evaluation to production.
The major themes tell us something: RISC-V is no longer content with being good enough for the periphery. It wants to move into the core of computing.
I’ll be looking closely at progress in Linux-capable SoCs, multi-core server platforms, and accelerator-rich architectures. These are high-stakes arenas, and moving from “demo ready” to “production ready” is a massive leap.
Arm vs. RISC-V: Different Paths, Different Stakes
One of the most important conversations we need to have is how Arm and RISC-V are diverging—not just in licensing, but in philosophy.
Arm continues to control the stack tightly—centralized governance, paid IP, and high assurance. That approach has its advantages: predictability, stability, and a well-aligned toolchain. But it also comes with costs and constraints.
RISC-V, on the other hand, is betting on openness, extensibility, and global collaboration. Its ISA is a standard, not a product. That creates space for innovation—but also for fragmentation.
And as the 2025 NA Summit puts it, advancing RISC-V requires progress not just in silicon, but in upstream software, system integration, security tooling, and scalable platform support—areas where the entire community must collaborate.
For companies trying to decide where to place their long-term bets, this is no longer just a technical debate—it’s strategic. RISC-V still has to prove that it can offer the same level of ecosystem depth and reliability in domains like kernel integration, toolchain maturity, compatibility, and certification.
Software: The Quiet Decider in RISC-V’s Future
Back at the 2024 RISC-V North America Summit, I remember how we were one of the only software-focused companies with a booth. And that contrast stuck with me—hardware usually steals the show. But in the case of RISC-V, I believe optimized and upstream software support will be the real deciding factor.
I’ve seen this too often: a promising new SoC comes out, the specs look great on paper—but when you try to boot a Linux distro or run basic benchmarks, either it doesn’t work, or the performance is terrible. And there is no upstream support, and if there is, it’s woefully incomplete. Just a beautiful datasheet—and a long wait for commercialization because of insufficient software support. That’s the trap.
RISC-V isn’t just another ISA. It’s a growing, evolving ecosystem—and for that ecosystem to function, the software stack needs to be upstreamed and optimized for it to be ready. I’m talking about the full path: bootloaders, kernel ports, debuggers, SDKs, CI/CD support. Not just to get something running, but to make it performant, secure, sustainable, and maintainable.
If you’re building hardware today, software can’t be a checkbox at the end. It has to be part of the priority roadmap from the start. Otherwise, your chip might technically work—but it won’t ship. Or if it does, it may have a very limited usefulness in the market.
That’s exactly the space where RISCstar focuses. We work with silicon teams—and directly with device OEMs—and help lay the groundwork for reliable, supported, and production-ready platforms and products.
Because in this race, whoever gets the software right wins.
What I’ll Be Watching Closely
There are a few areas I’ll be paying especially close attention to at this year’s summits:
1. Datacenter and Linux-Class Platforms
– Are there any real breakthroughs in PCIe, virtualization, SMP scaling, or long-term support?
– Can anyone make a serious play in cloud or edge server markets?
2. Security and Platform Consistency
– With open standards come risks—how do we build trust across diverse implementations?
– What role will certification, secure boot, and trusted execution environments play?
3. Tooling and Developer Experience
– GCC and LLVM are just the start—what’s happening in CI/CD workflows, debug tools, profilers, and SDK-level support?
What We Do at RISCstar
At RISCstar Solutions, we bring our RISC software expertise, enabling, optimizing, and upstreaming kernel support for hardware and system partners every day to help them get RISC-V platforms from prototype to production. Whether it’s secure boot, OS bring-up, BSP development, upstream kernel support, resolving technical debt, or performance optimization—we don’t just study this ecosystem. We help build it.
If you want to compare notes, talk roadmap, or just explore what’s possible—we’d love to connect. We’re always open to meaningful collaboration, whether you’re early in your exploration or deep into deployment. RISCstar is also a sponsor at the upcoming Santa Clara summit, so if you are also attending, it is a great opportunity to chat in person.
Final Thought
RISC-V has had momentum for a while. But momentum alone isn’t enough anymore. 2025 might be the year we stop asking whether RISC-V is coming—and start asking who’s truly ready to build with it.
Let’s find out. Together.
This was a guest post on Embedded.com
1
