← Back to Blog
RISC-V MCU

Automotive RISC-V Control Chips Get Two Competing Rulebooks: Quintauris RT-Europa and the China SAE Specification

RISC-V MCU

Standards, not cores, are what gate automotive adoption

For automotive control chips — body, gateway, chassis, powertrain, domain control — the binding constraint was never raw performance. It is the ability to prove, on paper and in silicon, that a part meets a functional-safety target and that the software above it behaves predictably. That is a specification problem, not a microarchitecture problem.

Two specifications are now converging on that problem from different directions, and engineering teams should be tracking both.

Track one: Quintauris RT-Europa

Quintauris — the RISC-V venture formed by Bosch, Infineon, NXP, Qualcomm, Nordic Semiconductor and STMicroelectronics — released RT-Europa in late 2025 and opened it for customer licensing in January 2026. It is described as the first RISC-V platform specification aimed specifically at automotive real-time control, and has been framed as a marker for RISC-V entering safety-critical automotive territory.

A "platform specification" in RISC-V terms sits above the ISA: it constrains not just which instructions exist, but the interrupt architecture, timer behaviour, memory-map expectations and boot/firmware interface, so that an RTOS or AUTOSAR stack can target a defined machine rather than one vendor's part.

Track two: the China SAE group standard

A parallel effort is running under the China Society of Automotive Engineers (中国汽车工程学会). The specification, titled 《基于RISC-V架构的汽车控制芯片技术规范》 ("Technical Specification for Automotive Control Chips Based on the RISC-V Architecture"), was proposed by the Electric Vehicle Industry Technology Innovation Strategic Alliance and registered as a project by China SAE. It is being jointly drafted by:

The effort has been admitted to China SAE's "group standard enhancement and leadership programme", and more than 30 organisations across OEMs, Tier 1s, chip design, base software, toolchains and research institutes are participating. A clause-by-clause review of the draft was held on August 27, 2026 at the Open-Source RISC-V Automotive Electronics Ecosystem Innovation Summit in Suzhou. The draft is the product of roughly one year of pre-research and five iterations.

Structurally the specification has four blocks:

  1. RISC-V core technical requirements
  2. Chip technical requirements
  3. Base software technical requirements
  4. Test methods

The technical dimensions named publicly are: instruction-set configuration, lockstep mechanism, hardware virtualisation, ASIL-D functional safety, and HSM (hardware security module).

Those five are exactly the list a control-chip engineer would write. Lockstep and ASIL-D are the safety floor; HSM covers secure boot, key storage and secure on-board communication; hardware virtualisation is what allows mixed-criticality consolidation — an ASIL-B infotainment stack and an ASIL-D control stack on one part without either able to take the other down; and ISA configuration is the anti-fragmentation clause, pinning down which extensions a compliant part must implement so that compilers and AUTOSAR stacks have a fixed target.

Company-reported volume figures

C*Core's automotive chip business was reported as follows for 2025, from its annual report: revenue of ¥127 million (approximately RMB 127M), up 82.32% year on year; more than 13 million automotive chips shipped during 2025; cumulative shipments past 25 million by the end of 2025. The company states it has built 12 automotive-grade product lines spanning domain control, ADAS processing, acoustic DSP, powertrain control, BMS, chassis-by-wire, body and gateway, V2X security, instrument and small-node control, airbag, mixed-signal and smart sensing, with AEC-Q100 qualification and ASIL-B / ASIL-D capability. First-half 2026 automotive electronics chip growth was reported as exceeding 100%.

All of these are company-reported and are reproduced as such; they have not been reconciled against audited filings for this draft.

What this means if you are selecting parts

Three practical consequences:

  1. Expect divergence, not convergence. Two specifications written by different consortia will not produce identical ISA subsets or identical lockstep models. If you ship globally, plan for two compliance targets rather than assuming one will absorb the other.
  2. Ask vendors which specification they claim compliance with, and in what version. "RISC-V" alone tells you nothing about whether the part implements the ISA subset your AUTOSAR or RTOS port expects.
  3. The supply argument is the durable one. Whatever the standards outcome, an open ISA with multiple independent IP sources, multiple foundry options and multiple qualification paths is structurally better for long-term availability and multi-source procurement than a single-licensor architecture. That is the reason to care, independent of where the specifications are written.

Sources

Verification notes