Research window: 2026-10-26 05:00 ~ 2026-10-27 05:00 (Beijing time, 24 hours).

Sources: Google News aggregation (16 query sets in Chinese and English, via proxy), Hacker News, Phoronix, CNX Software, LinuxGizmos, riscv.org, the openRuyi official news page and main repository, website checks of RISC-V International member companies (391 companies), and GitHub (pushes, commits, and release searches across organizations and key repositories including XiangShan / NEMU / difftest / GEM5 / XSCache, DAMO XuanTie, ESWIN, Sophgo, Nuclei, Espressif, SpacemiT and spacemit-robotics, Sipeed, revyos, openRuyi-Project, Radxa Linkr, and OpenHW).

In This Issue

  • Today’s Highlight: Onsemi Takes Over Codasip’s Low-End RISC-V Business for $14.5 Million (10-26)
  • I. Open-Source Community and Software Ecosystem
    • XiangShan: 35 Fixes Merged in One Batch, with TLB need_gpa and Vector Exceptions as the Main Threads (10-26)
    • NEMU: Event Encoding for the AME Matrix Extension and Fixes to Host FMA Exception Flags (10-26)
    • difftest Lands BOOM Support; GEM5 Adds Decode-Fusion Compression (10-26)
    • openRuyi: 46 Commits Merged in Bulk, Cloud-Native Stack Security Updates, and the Full Sequoia PGP Suite (10-26)
    • Open-Source EDA Pushes a Homegrown RV32I Core Toward GF180 Tapeout: The Full 78-Step LibreLane Flow (detected 10-26)
  • II. Product and Ecosystem Developments
    • SiFive Positions RISC-V as the Control Layer for AI Accelerators (10-26)
    • MIPS’s Full-Stack RISC-V Pivot: The Acies / Actus / Aegis Platforms and the S8200 Core (10-26)
    • Adafruit Metro ESP32-P4 Hydra: A UNO-Form-Factor Board with Dual RISC-V Cores (10-26)
  • III. Deep Dives on Domestic Teams
    • Sophgo: SG2044 Firmware Gains Signing Keys, Packaging Tools, and Full-Platform CI (10-26)
    • SpacemiT: K3 Buildroot Security Documentation Takes Shape; TEE Whitepaper and TA/CA Guides Committed (10-26)
    • Nuclei: Documentation Bumped to 2026.10-dev, Adding QEMU NICE/XEC and Trace Decoder (10-26)
  • IV. Special Section: Embodied Intelligence and Robotics
    • SpacemiT Robotics Stack Fills Gaps: Unitree Go2 Runs on K3; Humanoid Side Gains Voice Interaction and Video Streaming (10-26)
  • V. Summary and Trend Observations

Today’s Highlight: Onsemi Takes Over Codasip’s Low-End RISC-V Business for $14.5 Million

Date: 2026-10-26　Sources: Jon Peddie Research: Onsemi picks up Codasip’s low-end RISC-V business for $14.5 million (10-26), Codasip: Strategic Pivot and Divestiture Announcement (04-08)

Onsemi has completed its acquisition of Codasip’s low-end RISC-V processor business, for a transaction value of $14.5 million according to Czech business outlet e15, of which about 90% has already been paid.

  • Scope of the deal: It covers only 27 of Codasip’s roughly 260 employees, plus a license to the Studio processor design tool. Codasip retains ownership of Studio and most of its publicly funded projects.
  • Background: On 2026-04-08, Codasip announced a strategic pivot, divesting its low-end RISC-V processor design business and shifting to a CHERI-based “cyber resilience” security architecture; at the time, the announcement said only that the buyer was a US-listed semiconductor company and did not name it.
  • Domestic Czech scrutiny: Codasip had received EU and Czech national research funding, and in July of this year it publicly disclosed more than €119 million in grants and equity support (most of it not yet received), so the $14.5 million price has prompted discussion; the company’s line is that this is “reasonable restructuring” rather than a fire sale.
  • Competitive landscape: A direct rival has emerged in the CHERI direction, SCI Semiconductor, which closed £5 million (about $6.67 million) in financing in September 2026 and says it has a further £7.7 million in government contracts; Codasip CEO Ron Black told the CHERI Alliance that security requirements from defense and critical-infrastructure customers are stronger than demand for general-purpose core licensing.
  • Buyer rationale: The low-end RISC-V technology and team that Onsemi acquires can directly serve its automotive and industrial semiconductor businesses—consistent with its previous approach of assembling technology stacks through acquisitions and licensing.

Jon Peddie Research’s assessment is worth noting: basic processor cores are becoming hard to differentiate and monetize, with customers facing a growing array of commercial and open-source alternatives; the next phase of RISC-V will be shaped more by established semiconductor companies, with value shifting away from the instruction set itself toward differentiated products and system integration.

I. Open-Source Community and Software Ecosystem

1.1 XiangShan: 35 fixes reclaimed in one batch, with TLB need_gpa and vector exceptions as the main threads

Date: 2026-10-26　Source: XiangShan commit log (10-26, kunminghu-v3)

The Kunminghu V3 branch of the main XiangShan repo merged 35 commits in the window, all with commit timestamps of 10-26 16:32, while the original author dates span 2026-02-04 to 2026-09-17—a typical bulk reclamation from a long-lived branch, not new development on the day.

  • TLB/MMU group: four need_gpa-related commits—masking the robidx of need_gpa to avoid X-state (#6233), fixing lost need_gpa clears on non-final ports (#6251), matching need_gpa responses by translation stage (#6285), and adding a timeout-clear mechanism. Also reclaimed is an earlier fix for TLB freezing due to needGpa (#5610).
  • Vector and memory access: vlsu extends the guest physical address of vector exceptions to XLEN (#6432); on the Rob side, flushpipe for vector load/store needs a delay (#6244).
  • Virtualization and privilege: PMP checks for HLV/HLVX/HSV switch to SPVP mode (#6250), implicit G-stage reads under RVH ignore MXR (#6099), VS-stage PageCache is flushed on HFENCE.GVMA (#6082), and final physical execution permission checks for HLVX (#6017).
  • Reset and X-state governance: mtvec reset values (#5862, #5889), X-state caused by missing reset values in MemBlock/L2Top (#5838), LoadQueueRAR using RegEnable to avoid X (#5986), and CPU clock gating switched to pre-scan reset—this group accounts for a third of the batch.
  • New features and minor items: NewCSR enables CSR writes for PMM and CBIE (#6269); Debug adds LT/GE trigger matching for CBO-class instructions (#6447); hartIDDmodeWidth is parameterized (#5627).

Spreading the 35 commits out by theme shows this is a convergence-oriented merge: issues like X-state, reset values, and need_gpa timeouts do not affect functional demos and only surface under long-running, multi-core, and virtualization stress—items that must be cleared before tape-out. The earliest author date goes back to February, meaning some fixes sat in the branch for seven months before reaching mainline.

1.2 NEMU: event encoding for the AME matrix extension and a fix for host FMA exception flags

Date: 2026-10-26　Source: NEMU commit log (10-26), NEMU releases

The NEMU reference model saw 3 commits in the window, two on AME (matrix extension) and one a config-layer refactor.

  • AME semantic fix: fix(ame): encode MMA event types from mcfg semantics (#1269)—MMA event types were previously encoded by a fixed enum; they are now decoded from the semantics of the mcfg register, so event classification is correct when the matrix configuration changes.
  • Floating-point exception fidelity: fix(ame): preserve host FMA exception flags (#1268)—the AME path emulates with host FMA instructions and must faithfully return host floating-point exception flags to the guest; otherwise diff comparison would miss mismatches on the exception side.
  • Config-layer refactor: refactor(config): reduce duplication with shared config layers (#1259), extracting duplicated config items into shared layers.
  • Background: v2026.10.r8 and v2026.10.r9 were tagged back-to-back on 10-23 and 10-24; this batch is continued polishing after the tags. Over the past week NEMU’s focus has shifted from “adding features” to “making diff comparison more trustworthy.”

The value of a reference model lies entirely in “being wrong less often than the DUT.” Filling in details like host floating-point exception flags shows XiangShan’s verification has advanced to the stage of distinguishing “same numeric value but different exception flags.”

1.3 difftest lands BOOM support; GEM5 adds decode fusion compaction

Date: 2026-10-26　Source: difftest commit log (10-26), GEM5 commit log (10-26)

The differential verification framework and the GEM5 branch each have one directionally clear commit.

  • difftest integrates BOOM: feat(difftest): add BOOM DiffTest support (#998)—brings UC Berkeley’s BOOM out-of-order core into the same comparison framework. Notably, the 10-23 daily brief had just recorded that #995 only “wrote BOOM’s DiffTest integration into the docs”; four days later the code landed.
  • Build compatibility: #1003 in the same batch preserves C++11 build compatibility, avoiding raising the toolchain bar with new code.
  • GEM5 decode fusion: cpu-o3: Add optional decode fusion compaction (#1184)—adds optional decode fusion compaction to the out-of-order model, letting the front end compress fusable instruction pairs into one micro-op, closer to real front-end behavior.

difftest moving from “verifying only XiangShan” to “verifying other cores” means more than the project itself: a framework that can compare both NEMU and BOOM has a chance of being adopted by external teams as shared verification infrastructure. Adding decode fusion on the GEM5 side aligns the optimism of the performance model with what the hardware front end actually does—the gap between simulation and silicon often hides in exactly such optional knobs.

1.4 openRuyi: 46 commits merged in bulk, cloud-native stack security updates and the full Sequoia PGP suite

Date: 2026-10-26　Source: openRuyi main repo commit log (10-26), openRuyi official news page

The openRuyi main repo saw 46 commits in the window, with commit times concentrated on 10-26 and original author dates from 09-19 to 10-23—again a bulk merge.

  • Cloud-native stack security updates: nats-server to 2.15.1, moby to 29.9.2, etcd to 3.7.2, containerd to 2.4.2, fzf to 0.74.5, four of them tagged [security-fixes].
  • Java and signing stack: openjdk-latest to 27.0.1.0.2.1 (with source checksums refreshed after an upstream retag); the full Sequoia PGP component set added—sequoia-sq, sqv, sequoia-sop, sequoia-chameleon-gnupg, sequoia-git, sequoia-policy-config, sequoia-keystore-server, sq-cryptoki.
  • Rust dependency fill-in: rust-libgit2-sys-0.17, rust-git2-0.19, rust-interprocess-1, rust-to-method-1, rust-convert-case-0.6, rust-static-toml-1, rust-seq-macro-0.3.
  • Python and toolchain: the five-piece python-docker and python-sagemaker* set to 3.26/1.26/2.26, boto3/botocore to 1.43.115; plus capnproto, fwupd-efi, cc-switch-cli 5.11.1, go-gopkg-fatih-set.v0, and others.
  • Release cadence: the latest announcement on the official news page is still 2026.09 (released 9-30); no new release in the window, so this batch is ongoing maintenance after that release.

One main thread is clear: the main workload for RISC-V distributions right now is security debt, not new features. Without fixing CVEs in components like nats, etcd, and containerd, server scenarios are out of the question; pulling in the entire Sequoia suite (including a GnuPG compatibility layer like sequoia-chameleon-gnupg) means package signing and key management are to be rebuilt on a modern PGP stack rather than continuing to carry GnuPG’s legacy baggage.

1.5 Open-source EDA pushes a homegrown RV32I core toward GF180 tape-out: the full 78-step LibreLane flow

Date: 2026-10-26 (spotted via member-site sweep; event 11-11)　Source: RISC-V Association (Japan): RISC-V Day Tokyo 2026 Autumn logic design track agenda, RISC-V Association (Japan) homepage

The RISC-V Association (Japan) posted agenda details in October for RISC-V Day Tokyo 2026 Autumn (11-11, University of Tokyo Hongo Campus), including a 30-minute talk that publicly lays out a complete path to tape-out using a purely open-source toolchain.

  • Target and path: speaker Yoshiki Kurokawa (JASA Hardware Committee RISC-V WG) used LibreLane 3.1.0.dev2 to push the homegrown RV32I-compatible core SWC1 to the GF180 process, covering Verilator lint, Yosys synthesis, OpenROAD place/CTS/route, 9 signoff STA corners, dual DRC with Magic and KLayout, and netgen LVS—78 steps in total.
  • DFT is the new addition: two steps, scan FF replacement and scan chain creation, are inserted after synthesis (only the 5V library on GF180 has scan cells); the open-source ATPG Atalanta generates 14,148 test patterns in about 2 minutes with 97% fault coverage. After scan chain insertion the frequency drops from 50MHz to 19MHz, while the scan chain itself can run above 200MHz.
  • Pitfall log: the published 5V SRAM template passed per the README, but swapping in their own core failed repeatedly; the cause turned out to be building a 3.3V core with 5V cells—after switching to 3.3V cells, placement completed and STA predicted 50MHz.
  • Environment: WSL2 (Ubuntu 24.04) on Windows 11 plus Nix; Claude Code (Pro plan) was used for flow debugging and checking STA reports. SWC1 already taped out via Tiny Tapeout (IHP 130nm) in 2026-03, and while the chip is in fab it runs μT-Kernel and lwIP on FPGA.
  • Next talk in the same session: 12:40–13:10, Munetomo Maruyama’s “AI-Designed RISC-V: From Claude Code to Linux Boot.”

The technical substance here is not the conclusion “tape-out with open-source tools”—Tiny Tapeout proved that long ago—but adding DFT to the open-source flow: scan chains and ATPG have long been commercial EDA territory, and a hobbyist achieving 97% fault coverage on WSL2 shows the open-source flow’s weak spot is shifting from “can it tape out” to “can it be made testable.” For domestic teams doing teaching chips and MPW, this is a step list that can be compared against directly.

II. Product and Ecosystem Updates

2.1 SiFive positions RISC-V as the control layer for AI accelerators

Date: 2026-10-26　Source: Jon Peddie Research: SiFive makes the case for RISC-V as the control layer for custom AI accelerators (10-26), SiFive blog: Orchestrating Custom Accelerators with Intelligent Control Units (10-16)

SiFive proposes using Intelligence-series RISC-V processors as “accelerator control units” (ACUs), providing a programmable control layer between the host and custom accelerators. Jon Peddie Research devoted a full analysis to this idea on 10-26.

  • Problem statement: Hardwired state machines are hard to change when algorithms change; shared buses easily become bottlenecks; delegating low-level orchestration to the host CPU consumes compute and adds latency.
  • Solution: Use RISC-V cores with scalar and vector capabilities to handle data preparation and movement, dispatch of accelerator operations, and ancillary computation such as activation functions and data formatting, connecting directly to accelerators via coprocessor interfaces such as SSCI and VCIX; changes to control logic land in software/firmware without touching fixed-function hardware.
  • Model segmentation: X100 targets control-intensive, low-latency, and small-area use cases; X200/X300 offer greater vector bandwidth and compute.
  • Existing deployments: Google data centers already use X200 as AI compute hosts; another X100 has been licensed to an unnamed top-tier U.S. semiconductor company for industrial edge AI.
  • Commentary: JPR argues this confirms that “value is shifting from the ISA to system integration”—RISC-V does not need to replace Arm or x86 as the main processor; entering the control plane can secure a meaningful position just the same.

This is two sides of the same coin as today’s headline acquisition: general-purpose core licensing is depreciating, while “embedding cores into someone else’s system architecture” is appreciating. The ACU framing works because AI accelerator form factors are increasingly fragmented, and no one wants to modify a hardware state machine for every form factor.

2.2 MIPS’s full-stack RISC-V transformation: Acies/Actus/Aegis platforms and the S8200 core

Date: 2026-10-26　Source: EE Times China: From processor IP to physical AI platforms—MIPS’s full-stack RISC-V transformation (10-26), NeoTeo: MIPS’s RISC-V platforms: what Acies, Actus and Aegis do (10-26)

Having abandoned its proprietary instruction set, MIPS—following its acquisition by GlobalFoundries and the integration of Synopsys ARC processor IP—has redefined itself as “a provider of RISC-V-based IP and full-stack solutions for automotive electronics, edge AI, and high-performance networking.” The three platforms announced in September 2026 were dissected in depth by Chinese- and English-language media this week.

  • Acies-1 (inference-native): Based on Atlas S8200, supporting RVA23, the RVV vector extension, and VME; can run large models such as llama.cpp and Qwen as well as vision Transformers and VLA models; on the software side it uses the Atlas SDK and IREE-based MLIR, compatible with TensorFlow/PyTorch/ONNX; the hardware form factor is an easy-to-integrate M.2 PCIe, targeting robots, automation equipment, and edge agents.
  • Actus-1 (event-native): Based on Atlas M8500, with a real-time multithreaded architecture and FoC acceleration support, integrating the VPX vector coprocessor, delivered as a single-board computer, targeting motion control, sensor fusion, and predictive maintenance, compliant with ISO 26262 and ISO 21434.
  • Aegis-1 (security-native): Targeting mission-critical physical AI systems, supporting RISC-V Android and Linux development, capable of running agent workloads outside data centers, also designed to ISO 26262/21434, with the goal of shortening certification cycles for high-safety-level systems.
  • S8200 core: Integrates scalar, vector, and matrix engines; the company claims 4x higher TOPS/W energy efficiency than current products; samples have shipped to key customers, with the first silicon reference platforms expected in 2027; it coexists with the already-production NPX5/NPX6 dedicated NPUs.
  • Customer base: MIPS says its customers cover nine of the world’s twelve largest automakers, with Mobileye and Infineon both important customers.

MIPS’s path illustrates one thing: in the RISC-V era, “IP companies with historical baggage” are not without opportunity—drop the old ISA, keep the toolchain and customer relationships, and rebuild platform layering around “workload-native” design. Acies explicitly names VLA and robotics, making it the second international IP vendor this week to anchor RISC-V in physical AI.

2.3 Adafruit Metro ESP32-P4 Hydra: a UNO-form-factor dual-RISC-V-core development board

Date: 2026-10-26　Source: CNX Software: Adafruit Metro ESP32-P4 Hydra (10-26)

Adafruit has launched the Metro ESP32-P4 Hydra, packaging Espressif’s ESP32-P4 in an Arduino UNO form factor and adding an ESP32-C6 for wireless.

  • Main controller: ESP32-P4 (v1), dual-core 32-bit RISC-V high-performance cores at up to 360MHz (with AI instruction extensions and a single-precision FPU), plus a low-power RISC-V core at up to 40MHz; 16MB PSRAM, 16MB QSPI NOR; 2D pixel-processing accelerator and H.264/JPEG codec.
  • Wireless: ESP32-C6 module connected via SDIO, providing Wi-Fi 6, Bluetooth LE 5.3, and 802.15.4 (Thread/Zigbee; some firmware requires self-integration).
  • Interfaces: Raspberry Pi-compatible 2-lane MIPI DSI and CSI (22-pin, 0.5mm pitch), USB 2.0 high-speed OTG host port (480Mbps), microSD, UNO headers plus separate SPI headers, STEMMA QT, LiPo charging.
  • Positioning: HMI, camera, and IoT prototyping; TinyUF2 supports drag-and-drop firmware updates.

The ESP32-P4 ecosystem is moving from modules toward finished development boards with “standard form factor + full interfaces.” For teams building edge HMI and vision prototypes, the UNO form factor means existing shield inventories can be reused directly—this kind of engineering convenience often drives selection more than a few extra megahertz.

III. Deep Dive on Domestic Teams

3.1 Sophgo: SG2044 Firmware Adds Signing Keys, Packaging Tools, and Full-Platform CI

Date: 2026-10-26　Source: sophgo/sophgo-edk2 commit history (10-26, devel-sg2044)

Sophgo’s EDK2 firmware repository recorded 6 commits on the SG2044 branch (devel-sg2044) during the window, all authored on 10-26, focused on “making the firmware deliverable” rather than changing functionality.

  • Signing chain: Added the SOPHGO default RSA signing key (keys:), along with a firmware binary signing script under tools:, turning “can sign” into a reproducible in-repo step.
  • Packaging: Added a packaging tool for firmware.bin that stitches scattered images into a single firmware file; also provided envsetup.sh to support standalone firmware builds detached from the full EDK2 tree.
  • CI: Added builds for firmware.bin and firmware.img, and brought all SG2044 platforms into CI compilation to prevent any board variant from silently breaking after a merge.
  • Continuity: BIOS v2.1.1 was just released on 10-08; on 10-23 the bootloader repo zsbl completed its refactor to the eboot framework (covered in the previous issue). This batch of commits fills exactly the delivery-side gap left after that refactor.

The long-standing weakness of domestic high-performance RISC-V servers has never been the cores, but whether customers can safely flash the firmware. Only with signing keys, packaging tools, a standalone build environment, and full-platform CI all in place does firmware move from “developers can compile it” to “the production line can ship it.” There was no launch event for this step, but it determines whether the next batch of systems can ship.

3.2 SpacemiT: K3 Buildroot Security Docs Take Shape; TEE Whitepaper and TA/CA Guides Land

Date: 2026-10-26　Source: spacemit-com/docs-buildroot commit history (10-26)

SpacemiT’s K3 Buildroot documentation repository saw 10 commits during the window, adding a complete set of security documentation in one pass, plus a solution bring-up guide.

  • Security doc index and whitepaper: Added a master security documentation index, a security whitepaper, and a feature support matrix, with illustrations.
  • TEE core content: Added a TEE architecture and image guide, a TA (Trusted Application) and CA (Client Application) development guide with examples, and a TEE debugging guide.
  • Keys and storage: Added key management and secure storage guides; on the device side, added a description of “firmware layout after TEE introduction.”
  • Navigation and onboarding: Security entries are wired into the K3 Buildroot navigation; there is also a commit docs(device): add solution bring-up guidance (authored on 10-26).

The timing of this documentation set is noteworthy: once TEE enters the firmware layout, key injection, debug port policy, and the OTA chain of trust in mass production all change accordingly. Releasing the whitepaper, support matrix, and debugging guide together indicates that K3’s secure boot and trusted execution environment have passed internal validation and entered the external delivery phase.

3.3 Nuclei: Docs Bumped to 2026.10-dev, Adding QEMU NICE/XEC and Trace Decoder

Date: 2026-10-26　Source: Nuclei-Software/nuclei-tool-guide commit history (10-26)

Nuclei’s tool guide repository saw 7 commits during the window, bumping the documentation version to 2026.10-dev and explicitly marking it “in development.”

  • Simulation side: Added usage instructions for the QEMU NICE plugin, the use of soc-cfg on QEMU, and a chapter on using Nuclei XEC custom extensions on QEMU.
  • Debug side: Updated the OpenOCD documentation and added trace decoder instructions; also updated the Nuclei custom extension documentation.
  • Engineering side: CI now builds docs using a prebuilt docbuilder image, shortening the pipeline.

What Nuclei shipped here is “how to get extensions and tracing running on your own core.” Documenting custom extensions (XEC) and the QEMU NICE plugin together effectively spells out the loop of “write an extension — verify in simulation — trace in hardware”; for teams building dedicated SoCs on Nuclei cores, these two chapters are more frequently used than the core manual.

IV. Special Chapter on Embodied Intelligence and Robotics

4.1 SpacemiT Robotics Stack Fills Gaps: Unitree Go2 Runs on K3, Humanoid Side Adds Voice Interaction and Video Streaming

Date: 2026-10-26　Source: GitHub: spacemit-robotics/unitree-go2, humanoid_linglong, humanoid_common, omni-agent, realtime-link

Within the window, SpacemiT’s robotics organization spacemit-robotics had 5 repositories with pushes, totaling 9 commits. Together, the four workstreams amount to a stack-level gap-filling effort.

  • Third-party robot adaptation (new repo): The unitree-go2 repository is named “Go2 on SpacemiT K3”. Its README directly provides a startup script for running as root on the K3 board (SDK located at /root/spacemit_robot, using the new_bigcore configuration), and specifies that the robot must be placed in crouch pose Pose A before startup, and must be placed in that pose before power-on for auto-start on boot; the companion web console is accessed at go2-sdk.local:8082 on the same subnet. The 5 commits in the window include a ROS 2 application + ONNX policy + web control, as well as simplified SDK delivery, hardware lifecycle and camera frame synchronization, and hardened CI model downloads.
  • Humanoid side (Linglong): humanoid_linglong corresponds to Linglong L1 V1.4, with 28 degrees of freedom (left leg 6 + right leg 6 + head 2 + left arm 7 + right arm 7). It supports MuJoCo simulation and switching to the whole_body real-robot backend, standalone PC simulation, sim2sim cross-machine inference (PC simulation + K3 board-side RL inference), and K3 real-robot control of 28-axis motors plus parallel ankle joints / Forsense IMU. It also provides an Android App and a QR-code web page connected via the HMI service. This period adds a “static interaction and voice service” configuration.
  • Common layer: humanoid_common adds an operator voice client and static profile; omni-agent adds push-to-talk and interactive voice tools (#20).
  • Video streaming: realtime-link adds video transmission (#2), providing a single-header C ABI (libvideo_transmission.so), a reference UDP backend, and a board-side frame capture example based on the MPP codec and SDL2 display.

Taken together, the four workstreams extend from “our own robot can run” (Linglong) to “other vendors’ robots can also run” (Unitree Go2), and then add voice interaction and video return. For vendors building edge-side robotics platforms, replicable robot adaptation is worth more than a single-machine demo: existing quadruped robots like the Go2 are numerous and have relatively open SDKs, so using one as an external showcase for K3 demonstrates platform capability better than tuning another version of the humanoid. What calls for restraint is that these commits are all code and documentation within the repositories, with no third-party testing or mass-production deployment data seen.

V. Summary and Trend Observations

  • Valuation divergence at the IP layer has now shown up in transaction prices: Codasip’s low-end RISC-V business changed hands for $14.5 million with 27 people, while in the same period SiFive is selling an “accelerator control unit” and MIPS is building a “workload-native” platform. In the same week, three companies gave different answers to the same conclusion — general-purpose cores are no longer the center of value; what matters is whether they can be embedded into a customer’s system architecture.
  • Domestic teams are filling in the last mile of engineering: Sophgo’s firmware signing and packaging, SpacemiT’s TEE documentation system, and Nuclei’s extension and trace documentation — none of these make it into a launch event, yet all are prerequisites for “can it be mass-produced and delivered.” Getting this layer solid is more meaningful than releasing another spec sheet.
  • Open-source cores are entering a convergence phase: XiangShan batch-collected 35 fixes, with author dates spanning February to September, focused on X-states, reset values, and the TLB need_gpa; alongside NEMU adding floating-point exception flags and GEM5 adding decode fusion, activity on the verification side is denser than on the feature side. “The reference model is wrong less often than the DUT” is becoming an explicit goal.
  • Distro workloads are consumed by security debt: Of openRuyi’s 46 commits, cloud-native component updates tagged [security-fixes] and a full Sequoia PGP migration make up the bulk. For RISC-V servers to take on real workloads, the “non-architectural issues” — signing, keys, and middleware CVEs — must be cleared first.
  • The robotics stack is shifting from demos to reproducibility: SpacemiT brought the Unitree Go2 onto K3 and filled in voice and video transmission, moving from “our own humanoid can run” to “third-party models can be adapted.” This kind of work is a more convincing test of a platform than specs.
  • Limitations: The price, headcount, and payment ratio of the Onsemi acquisition of Codasip come from reporting by the Czech outlet e15 and Jon Peddie Research’s retelling; neither company has disclosed transaction terms. Codasip’s public funding figures are cited from its own statements. SiFive’s Google deployment and X100 licensee information come from SiFive blog posts and JPR’s retelling, without customer confirmation. MIPS’s S8200 efficiency multiple, the 2027 silicon reference platform timeline, and “nine of the top twelve automakers” are all company statements. The 35 XiangShan commits and 46 openRuyi commits were obtained by checking GitHub commit pages one by one; the separation of author dates from commit dates is characteristic of batch collection, and no project announcement explains the specific motivation. The commit contents for Sophgo, SpacemiT, and Nuclei are judged from commit titles and READMEs, without checking patches one by one. The process count, ATPG pattern count, and coverage in the LibreLane section come from the talk abstract; the event has not yet taken place, and the data awaits on-site verification. Most changes detected in the member website inspection are routine updates to university and institution homepages; only the meeting agenda of the RISC-V Association (Japan) constitutes substantive information. Also: the booth report on Zhongke Tongliang at CNCC 2026 (10-21 to 24, Chengdu) is a re-exhibition of the same batch of products (SmarCo AI workstation, 12-core RISC-V / 250 TOPS INT8 / 128GB unified memory), whose specs were already included in the 10-20 daily report and are not repeated in this issue; the report on Ruixin Gaoguang D35’s “12nm surpassing Nvidia’s 7nm” is a recirculation of 9-23 content and is likewise not repeated.

Appendix: Complete Source List

Source Verification Table

Source Verification Result
Google News aggregation (16 queries in Chinese and English, 24-hour window) Of 52 deduplicated candidates, 4 were substantive news items: the Onsemi/Codasip acquisition, the SiFive ACU analysis, MIPS’s three platforms (dual Chinese/English sources), and Adafruit Metro ESP32-P4 Hydra — all included. The Zhongke Tongliang CNCC report, XuanTie mass-production deep-water piece, Ruixin D35 “12nm beats NVIDIA 7nm,” foreign-media retrospective on T-Head C950, and S2C summit showcase were all follow-on coverage of existing content and were not re-listed per deduplication rules; Chinese queries for “Sophgo” and “ESWIN” still returned Hong Kong stock quotes and lock-up expiry releases, which were filtered out
Hacker News, Phoronix, CNX Software, LinuxGizmos, riscv.org One valid item from CNX (Adafruit Metro ESP32-P4 Hydra) included; no new RISC-V entries in the window from Phoronix, LinuxGizmos, riscv.org, or HN
GitHub organization and key repository checks (24-hour window) Pushes within the window: espressif 43, spacemit-com 9, spacemit-robotics 5, OpenXiangShan 5, sophgo 3, openhwfoundation 3, sipeed 3, Nuclei-Software 2, openRuyi-Project 2, XUANTIE-RV 1, revyos 1; eswincomputing (last 10-19) and radxa-linkr (10-21) had no pushes; no new commits on the default branches of the three openhwfoundation repos within the window (cva6’s master became read-only on 10-23), and uap only had bot-driven repository statistics refreshes
openRuyi dual-source 46 batched commits to the main repo (security updates, openjdk 27.0.1, Sequoia PGP suite, Rust/Python dependencies); the latest announcement on the official news page is still the 2026.09 release (published 9-30), with no new version in the window
XiangShan-family repositories (XiangShan/NEMU/difftest/GEM5/XSCache) XiangShan: 35 batched backfills (all committed at 10-26 16:32, author dates 02-04 to 09-17); NEMU: 3; difftest: 2 (BOOM support, C++11 compatibility); GEM5: 1 (decode fusion); XSCache had pushes but no commits on the default branch within the window (most recent 10-19)
Key repositories of DAMO XuanTie, Sophgo, SpacemiT XuanTie CubeSandbox had no new commits within the window (most recent 10-21), and it was the only repo pushed within the organization; Sophgo sophgo-edk2: 6 (signing, packaging, CI), sophon-demo: 1 (ResNet adapted to CV84X6 quad-core INT8 and re-tested), bootloader-riscv had no commits on the default branch within the window (most recent was the zsbl-to-eboot change on 10-23); SpacemiT docs-buildroot: 10, mpp: 2, ai-sdk submodule: 1, model-zoo-llm: 1 (extra request fields and cancellable streams)
Member website sweep (391 sites) Several page changes detected, of which only the RISC-V Association (Japan)’s RISC-V Day Tokyo 2026 Autumn agenda constituted substantive information and was included as 1.5; the rest were routine homepage updates from universities, institutions, and vendors (National and Kapodistrian University of Athens, NIT India, FAST-NUCES, RISE, PUCRS, Czestochowa University of Technology, SIAT CAS, SRI International, etc.), with no product, funding, or architecture announcements found; 70 sites failed to fetch (including ISCAS, Beijing Institute of Open Source Chip, Tencent, MediaTek, etc.), which is non-blocking
RISC-V International Foundation membership list 391 members (Premier 20 / Strategic 169 / Community 202), list refreshed by an automated task on the 5th of each month; not due this period
6th RISC-V China Summit official website and source repo The main event (10-18 to 20) and the Bay Area/Hong Kong Day (10-21) have concluded; the monitoring script reports no updates to the sitemap, 11 key pages, or the source repository, so there is no new summit-related content this period
Pending-inclusion queue The queue file for the day does not exist; a full-directory scan found no unarchived RISC-V sections, so there are no user-specified items this period