RISC-V has won the embedded argument. So why are your buyers still asking if it's ready?

Amber circuit trace labelled RISC-V is ready runs from a chip, then breaks into gaps before an empty receiver, showing the RISC-V proof gap

The technical argument for RISC-V in embedded applications is over. I sat in on the RISC-V panel at Microelectronics 2026, with Andy Moore of RISC-V International, John Ronco of SiFive and Markus Willems of MIPS (now part of GlobalFoundries), and nobody on stage spent a minute defending whether RISC-V works. They talked about billions of chips shipped, automotive design wins, space processors, and Linux distributions that ran on new silicon within days.

Yet the people who sell RISC-V products still hear the same questions on every call. Are the tools ready? Won't all these custom extensions fragment the ecosystem? Who else is using it?

That gap sits in marketing and sales, not engineering, and the good news is most RISC-V companies can close it with material they already have. Below are six places where the panel showed the story exists, and what to do so your buyers hear it.

Arm has deprioritised Cortex-M. Are your buyers hearing that from you?

John Ronco ran product management for Arm's CPUs for years before he moved to SiFive, so his view of Arm's embedded roadmap is sound. On stage, he said Arm stopped developing its embedded roadmap about 18 months ago, which leaves anyone who wants an Arm embedded core "stuck with a legacy".

Arm’s take on this is more nuanced. Lionel Belnet, Arm's senior director of edge computing, told eeNews Europe in July that "it's not a priority to push the performance for Cortex-M" and that Cortex-A is "the next logical step". Either way, the direction is the same. Arm's effort is going into bigger cores, and the engineers who built their careers and devices on Cortex-M have noticed.

Part of what's happening is that the old split between microcontrollers and application processors has blurred. A microcontroller in 2026 often needs to run applications and some AI, which puts it closer to an applications processor from ten years ago. Cortex-M and Cortex-A don't share an instruction set, so Arm has two product lines to bridge. RISC-V uses the same base ISA from a small controller up to a many-core server, with extensions added for the workload.

A roadmap change like this is a trigger event. Engineering leads who never had a reason to look beyond Arm now have one, and their first move is a search, or more and more often a question to ChatGPT or Claude. If your website doesn't answer "what is the alternative to Arm Cortex-M?", an answer engine will answer it for you, and it will probably name a competitor.

What to do: write one page that answers the migration question directly. Cover what moving from Cortex-M to your core involves, what carries over, how long it takes and who has done it. Write it for the engineer, then give your sales team the link.

"Are the tools ready?" Where is your answer?

Markus Willems made the point that standardisation is what lets the ecosystem grow around RISC-V. Debuggers support it out of the box, and compilers are available from open source projects and from the vendors themselves. He has been in the industry for 25 years, and he said the growth of that community over the last five is the clearest sign of momentum he has seen. Vendors don't build tools for a market they don't believe in.

So the answer to "are the tools ready?" is yes. The problem is where that answer lives. On most RISC-V company websites, tool support is a row of partner logos or a line buried in a datasheet. The engineer evaluating you can't see which toolchain versions you support, which RTOS ports exist or which debug probes work. They ask your sales team instead, and your sales team answers the same question by hand, call after call.

What to do: build a tools and ecosystem page that names every compiler, debugger, RTOS and IDE you support, with versions and links. Then turn it into a one-page objection sheet for sales. Every question that page answers is one your sales people no longer have to field.

"Differentiation, not fragmentation" only works if you say it

John Ronco gave us the line of the session: "It's differentiation, not fragmentation." RISC-V lets every vendor build something different while keeping software compatible across vendors and chips. He said SiFive is committed to 100% standard RISC-V, with anything custom built on top and proposed to RISC-V International for standardisation. Markus Willems said MIPS takes the same position.

That position fits how RISC-V is meant to work. Extensions are designed in the open, then voted on and ratified by RISC-V International's working groups, and the ratified library now covers most of what a product needs. Profiles go further. If you build to one, you rarely need a custom extension at all.

Fragmentation is the fear buyers rarely say out loud. They see a vendor promoting its custom extensions and wonder whether their software will still run elsewhere, or whether they're swapping one lock-in for another. The flexibility RISC-V companies most like to talk about is exactly what triggers that worry.

What to do: lead with the standard. State which RISC-V profile each product supports and which ratified extensions it uses. If you offer custom extensions, present them as an option on a standard base, and say who maintains the software for them. One sentence on each product page answers an objection most buyers will never raise with you directly.

Billions of chips shipped. So where are your named customers?

The panel was full of proof. Billions of RISC-V chips are shipping. John Ronco pointed out that his own Samsung phone contains chips from three different vendors that use SiFive cores. GlobalFoundries bought MIPS in 2025, then acquired Synopsys's ARC processor business in 2026, and built both on RISC-V. Companies don't make acquisitions like that on a hunch.

All of that proof reached the audience as anecdotes from a stage. Much of RISC-V's success sits inside chips where the core is invisible to the end customer, and under NDAs that stop vendors naming who uses them. Answer engines can't cite a panel anecdote. They cite named case studies, published results and third-party coverage.

What to do: aim for one approved customer story each quarter. If the customer won't be named, anonymise the story but keep the numbers: the power saved, the time to first silicon, the software that ported. A specific anonymous story does more work than a famous logo with nothing behind it.

RVA23: the story progressive RISC-V companies need to tell now

RVA23 is a RISC-V profile: a fixed set of extensions that an application processor must support, so software can target one baseline and run on chips from different vendors. John Ronco compared it to Armv9. It matters because the software world has chosen it. Red Hat, Ubuntu and Android all treat RVA23 as the baseline they support. I find a closer comparison is the x86-64 microarchitecture levels. Each level is a named baseline that software can target, so code built for that level runs on any chip that meets it.

The panel showed how far that has come. Andy Moore ran his notes from a laptop built on an RVA23 chip. SiFive has announced a 32-core RVA23 server developer platform, and when it shared early units with Red Hat, Ubuntu and others, their response, in Ronco's words, was that "it just worked". Everything was running within days.

For RISC-V companies with RVA23 products, this advantage won't last long. Software buyers will soon treat RVA23 support as a checkbox. Today, few vendors explain what it means for the person buying: which operating systems run, what they no longer have to port and what it costs them to switch. The companies that explain it clearly first will own the search results for it.

What to do: publish an RVA23 page in plain language. Say what RVA23 is, what runs on your product today, your compliance status and what's on your roadmap. Write it so a software lead who has never touched RISC-V can follow it.

Edge AI: lead with programmability, not TOPS

Both panellists described the same trend: RISC-V cores built inside AI accelerators. The accelerator does the heavy lifting, and the RISC-V core handles everything around it, which keeps the design programmable when the models change. Markus Willems added that RISC-V can also run AI workloads natively, using the vector extensions available now and the matrix extensions being defined, with software stacks using IREE as their entry point.

He summed it up: "AI is not about hardware, sorry to say. AI is about the software." Moving data in and out efficiently, and giving developers one way to program the chip, matters more than the peak number on the spec sheet.

Most AI chip messaging still leads with TOPS, a number buyers can't compare across vendors and rarely trust. The panel pointed to a better selling point: a design that stays useful when next year's model looks nothing like this year's.

One caveat for buyers: the matrix extensions aren't ratified yet, and there may end up being two or three approaches. If a vendor's AI roadmap depends on matrix support, ask which approach they're backing and what happens if the standard goes another way.

What to do: rewrite your AI messaging around software, data movement and future proofing. Show the toolchain, show a model running and explain what happens when the model changes.

So is RISC-V now the default choice for embedded?

For new deeply embedded designs, the control processors and companion cores that no end customer ever programs, the panel made a strong case that it already is. For general-purpose microcontrollers, where developers pick the chip and its ecosystem, RISC-V is still earning that position, with Infineon and Microchip among the companies moving it forward.

It's worth being clear on terms. Every microcontroller is an embedded device, but not every embedded device is a microcontroller. When John Ronco talked about Arm's embedded roadmap, he meant Cortex-M. Plenty of RISC-V embedded processors now run Linux and AI inference on dies smaller than a microcontroller's was five years ago.

What stands between RISC-V and default status in the rest of embedded is visibility. The proof exists, but it sits in datasheets, partner logos and panel anecdotes, where buyers and answer engines can't find it. The RISC-V companies that move that proof onto their own websites, in plain language, will be the ones buyers find first.

If you want to see how your company looks to search engines and AI answer engines today, we run a free Signal Check: a scored audit of your SEO and AEO visibility, with the fixes ranked by impact.

Book a 30 minute call

I’m Dale Kaszycki, Co-founder of Latent and I’m a firm believer in not hiding your light under a bushel.