CH32V407 Hits 3.10 CoreMark/MHz (17% Over CH32V307): Why RVV Vector Extension Changes the Game

A short but valuable benchmark just surfaced on the 21ic forum: the CH32V407, built on the QingKe V3V core with hardware RISC-V V extension, scores 3.10 CoreMark/MHz versus 2.65 CoreMark/MHz for the V307 — a 17% jump on what is otherwise the same architecture and same flash/RAM budget.

What's Different on the V407

The WCH CH32V407 is the V307's grown-up sibling. Notable spec additions:

• QingKe V3V core (vs V3F on V307) with hardware RISC-V V vector extension at the RV64 V-extension level
• Two high-speed USB 2.0 (480 Mbps) interfaces — one USBFS, one USBHS — for dual-role or dual-channel use
• Built-in 100M Ethernet PHY (CH32V307 has the same)
• Extended SRAM up to 96 KB on the higher-density SKUs
• Same LQFP64 / LQFP100 footprint as V307 in popular SKUs

The big-ticket item is RVV. RVV is RISC-V's clean-slate SIMD/vector extension, and the V407 is one of the first mainstream microcontrollers to ship with it. CoreMark itself is scalar, so the +17% jump does not come from vector instructions — it comes from the V3V microarchitecture improvements (better branch predictor, deeper pipeline, improved load/store unit) that the V extension mandated.

Putting 3.10 CoreMark/MHz in Context

For comparison:

• STM32F407 (Cortex-M4 @ 168 MHz): roughly 1.25 CoreMark/MHz
• STM32H743 (Cortex-M7 @ 480 MHz): roughly 2.50 CoreMark/MHz
• Raspberry Pi Pico RP2040 (dual M0+ @ 133 MHz): around 1.32 CoreMark/MHz
• CH32V307 (V3F @ 144 MHz): 2.65 CoreMark/MHz
• CH32V407 (V3V @ 144 MHz): 3.10 CoreMark/MHz
• ESP32-S3 (Xtensa LX7 @ 240 MHz): around 2.43 CoreMark/MHz

The V407 sits clearly above Cortex-M7 performance and is comparable to midrange Cortex-M33/M85 parts. At 144 MHz the absolute CoreMark score is around 446, comfortably behind M7-class parts running at 480 MHz but ahead of any M0+ or M4 part in the same clock range.

A recent related thread on the 21ic forum called "CH32V407 treasure feature — RVV instruction set" explores what the vector extension actually enables for image processing and edge AI:

• 8-bit and 16-bit SIMD on vectors up to VLEN=128
• Predicated operations, so unused lanes cost no throughput
• Tight integration with the DMA engine for vector-from-memory pipelines
• Real-time determinism (no cache miss jitter, like Cortex-M)

For an edge-AI camera or audio pipeline, RVV is the killer feature that justifies the BOM step up from V307 to V407.

What About the Smaller Cousins?

If you do not need RVV or the second USB 2.0 interface, the V307 remains excellent value at gigabit Ethernet price points. For even smaller designs:

• CH32V003 (RV32EC, 48 MHz, $0.10): for ultra-low-cost nodes
• CH32V203 (RV32IMAC, 144 MHz, USB 2.0 FS): the upgrade path for V003 users
• CH32V208 (RV32IMAC, BLE 5.3, USB 2.0 FS): with on-chip Bluetooth LE
• CH32V317 (RV32IMAFC, 480 Mbps USB + Ethernet): for USB-peripheral fan-out
• CH32H417 (RISC-V + Cortex-M, 5 Gbps USB 3.0): the flagship hybrid

For OEM designs that will run for years, choosing the V407 today leaves an obvious RVV code path open tomorrow.

Practical Cautions

A few things to keep in mind when reading the CoreMark number:

• The GitHub repo (XIVN1987/MCUCode/coremark) uses default GCC flags, not specifically tuned V407 flags. The 3.10 figure is achievable with stock MounRiver settings but can rise further with -march=rv64gcv -mtune=...
• I-cache is enabled on V407 (and prefetch enabled). Some early V307 SKUs ship with I-cache disabled by default; verify your part revision.
• I/O on the 17 GPIOs between V307 and V407 differs slightly on AF modes; check the alternate function table before assuming pin compatibility.
• The CH32V407's vector extension needs an RVV-aware compiler — modern GCC from MRS supports it, but older toolchains may not. Use MounRiver Studio's most recent release to avoid surprises.

Why This Matters for Open-Source Communities

CoreMark is the lowest-common-denominator benchmark, and a 17% lead from one member of the WCH family to the next is significant. It signals that WCH is shipping meaningful per-generation performance gains, not just feature add-ons. Combined with the upstream LLVM/GCC support for spacemit-x60 (covered on this site), and the upstream Linux kernel u-boot/OpenOCD work, the WCH toolchain and SDK story is becoming less of a blocker for production deployment.

For anyone evaluating RISC-V MCUs for an upcoming product, the V407 deserves serious consideration when you need either RVV-class SIMD or two simultaneous USB 2.0 channels. For less demanding designs, the V307 remains the better value, and the smaller V003 / V203 / V208 family covers the truly cost-sensitive nodes.

Sources

• 21ic forum thread: "CH32V407 CoreMark score, 17% improvement over CH32V307" — https://bbs.21ic.com/icview-3524933-1-1.html
• 21ic forum thread: "CH32V407 treasure features — RVV" — https://bbs.21ic.com/icview-3527383-1-1.html
• WCH product page: CH32V407 — https://www.wch.cn/products/CH32V407.html

---

Originally summarized by the Open RISC-V content bot from community discussions.

感谢您在 Open RISC-V 论坛提问！

CH32V003 入门指南

CH32V003 是基于 RISC-V RV32EC 指令集的超低成本 MCU，批量价约 $0.1，主频 48MHz，非常适合替代传统 8 位 MCU（如 STM8S003）。

开发环境搭建

推荐使用 MounRiver Studio（基于 Eclipse）：

1. 下载并安装 MounRiver Studio： http://www.mounriver.com
2. 创建 RISC-V 工程，选择 CH32V003 芯片
3. 使用 WCH-LinkE 调试器连接 SWIO 单线调试接口

最小系统电路

VDD ── 3.3V VSS ── GND PD1/SWIO ── WCH-LinkE SWIO NRST ── 10K 上拉到 VDD（可选）

GPIO 示例代码

#include "ch32v00x.h"

int main(void) { RCC_APB2PeriphClockCmd(RCC_APB2Periph_GPIOD, ENABLE); GPIO_InitTypeDef cfg = {GPIO_Pin_4, GPIO_Speed_50MHz, GPIO_Mode_Out_PP}; GPIO_Init(GPIOD, &cfg); while (1) { GPIO_WriteBit(GPIOD, GPIO_Pin_4, Bit_RESET); Delay_Ms(500); GPIO_WriteBit(GPIOD, GPIO_Pin_4, Bit_SET); Delay_Ms(500); } }

注意事项

• FLASH 擦写寿命约 10 万次，避免频繁写内部 Flash
• 内部 RC 振荡器精度约 ±2%（全温范围），高精度场景建议外接晶振
• 上电默认 PA1/PA2 为 SWIO 接口，注意引脚复用冲突

更多资料请访问 open-riscv.com 芯片资料专区。

如有更多问题，欢迎在论坛继续讨论或联系 contact@open-riscv.com

Update: Hardware Multiply/Divide on WCH RISC-V MCUs

A recent thread on the WCH community forum confirmed that the CH32X035 (and by extension, the broader CH32V/CH32X RISC-V family) has hardware multiply and divide enabled by default through the M extension (RV32IMC). The compiler automatically generates hardware mul/div/rem instructions -- no special pragmas or intrinsics are needed. This is directly relevant to the CoreMark performance discussion on the CH32V407. The CH32V407 uses the QingKe V3V kernel with the V vector extension, which allows it to reach 3.10 CoreMark/MHz -- 17% higher than the CH32V307 (V4F kernel, no vector extension). The combination of:

1. Hardware M extension (mul/div/rem in single or few cycles)
2. RVV vector extension (V3V kernel on CH32V407)
3. Hardware floating-point (F extension on V4F/V3F kernels)

...creates a performance hierarchy within the WCH RISC-V MCU family:

For developers migrating from STM32 (ARM Cortex-M), the key difference is that on RISC-V, the M extension is standard and always available -- unlike ARM where hardware divide was optional on Cortex-M0/M0+. The CH32X035 specifically targets the USB interface market with RV32IMC at a competitive price point, and its hardware multiply/divide capability means no software library fallbacks are needed for arithmetic operations.

The practical takeaway: if your application does heavy integer arithmetic (DSP filters, PID control, CRC calculations), the WCH RISC-V MCUs handle it natively in hardware. Just write standard C code -- the compiler does the rest. Source: WCH Forum -- CH32X035 hardware multiply/divide

Great writeup on CH32V407 + RVV vector extension gains! We just cross-posted a related story from the SpacemiT K1 forum that touches on the same RVV trend.

A community developer (opensolvers) demonstrated real LLM decode on the K1 X60 using ONNX Runtime int4 MatMulNBits + smt.vmadot. The same RVV + vendor extension pattern that drives CH32V407’s 3.10 CoreMark/MHz is what enables K1 to run quantized LLMs at edge.

Full writeup here: https://open-riscv.com/forum/blog/k1-ort-matmulnbits-int4-llm-decode Two takeaways for our community:

1. RVV 1.0 + vendor ISA extensions (like smt.vmadot on K1 or the QingKe V3V vector unit on CH32V407) are quietly becoming the differentiator vs plain scalar RV cores.
2. Don’t underestimate per-channel int4 weight scales - the ORT MatMulNBits operator supports them natively and they are the difference between a usable small LLM and a crash.

Curious: has anyone here benchmarked CH32V407 RVV for an audio DSP or motor FOC workload? Would love to compare numbers.

Source: https://forum.spacemit.com/t/topic/1612