Research window: 2026-11-05 05:00 ~ 2026-11-06 05:00 (Beijing time, 24 hours).

Sources: Google News aggregation (20+ query sets in Chinese and English, via proxy), Hacker News, Phoronix, CNX Software, LinuxGizmos, the openRuyi official news page and main repository, website inspections of RISC-V International member companies (391), riscv100.top leaderboard inspection, WeChat official accounts and vendor websites, as well as commit and release searches across GitHub organizations and key repositories including XiangShan/NEMU/GEM5/XSCache/difftest, CORE-V CVW/CVA6/cv-hpdcache, DAMO XuanTie, ESWIN, Sophgo, Nuclei, Espressif, SpacemiT and spacemit-robotics, Sipeed, revyos, openRuyi-Project, and Radxa Linkr.

In This Issue

  • Today’s Highlight: SpacemiT open-sources the RVISA virtual ISA specification working draft, with the first round adding three mapping sets—IME/VME/AME—and blocked MMA (repo created 11-04, commits 11-05)
  • Today’s Highlight: Quintauris releases EM-Altair, an MCU-class RISC-V standardized platform using RV32IM as its baseline for binary compatibility (released 11-03, reported 11-05)
  • I. Open-Source Community and Software Ecosystem
    • openRuyi adds 20 document-format import libraries in one batch, pointing to the office-suite dependency closure (11-05)
    • CORE-V CVW merges 11 commits: Ubuntu 26.04 installation fix, AMO read-path timing, branch-prediction missing signal (11-05/11-06)
    • XiangShan fixes store merging under speculative prefetch in MissQueue; six GEM5 commits focus on evaluation infrastructure (11-05)
    • P4 Launcher delivers a PC-like experience with loadable applications on ESP32-P4, with 21 PAPP apps (11-05)
  • II. Product and Ecosystem Developments
    • HPMicro’s second Ecosystem Conference set for November 21 in Shenzhen; 14 agenda items tie RISC-V MCU and AI together (11-04)
    • Zijing M100 selected as a “China Chip” RISC-V ecosystem promotion demonstration case; the ecosystem account for automotive-grade MCUs is priced separately (11-05)
    • India’s MeitY sets a 24-month self-developed GPU goal and pushes commercialization of two RISC-V CPUs, SHAKTI and VEGA (reported 11-05)
  • III. Deep Dive on Domestic Teams
    • SpacemiT robotics SDK completes three repositories: manipulation and dice_arena enter the manifest, K3 robotic-arm manual updated in sync (11-05)
    • Sophgo adds 2-core/3-core bmodels and stress tests for Qwen3.5-0.8B: TPS 51.89 and 55.20 (11-05)
    • Nuclei tool guide adds rvtrace and Hummingbird debugger troubleshooting (11-05)
    • Espressif esp-riscv-trace lands in CI and pre-commit; trace decoding split into a separate repository (11-05/11-06)
  • IV. Embodied Intelligence and Robotics Special Chapter
    • SpacemiT manipulation component: device exclusivity, in-position determination, timeout, and fault locking folded into device sessions (11-05)
    • dice_arena runs the full dice-game pipeline with K3 plus Nero seven-axis plus Revo2 dexterous hand (11-05)
    • humanoid line adds standing policy and navigation: LingLong SuperMimic and G1’s RGBD SLAM/Nav2 (11-05)
  • V. Summary and Trend Observations
  • Supplementary Observations (riscv100.top and member website inspections)
  • Appendix: Complete Source List and Source Verification Table

Today’s Focus: SpacemiT Open-Sources RVISA Virtual ISA Specification Working Draft, First Round Adds IME/VME/AME Mapping Sets and Blocked MMA (repo created 11-04, commits 11-05)

SpacemiT has opened a new repository on GitHub, spacemit-com/rvisa, proposing RVISA (RISC-V Virtual ISA), which defines a virtual instruction notation layer for RISC-V scalar, vector, and matrix computation. The repository was created on November 4, and three substantive commits landed in a single day on November 5: first the MkDocs documentation site and Pages publishing workflow, then example source forms of the RVISA notation and the first batch of IME/VME/AME mappings, and finally PR #2 defining programmer-expressible tile layouts and blocked matrix multiply (blocked MMA). The current specification version is 0.2.0.

RVISA’s positioning is stated fairly clearly: it deliberately sits above NVIDIA PTX and below cuTile. Upward, it is not bound to any front-end language, and source-language front-end implementations are explicitly excluded from this version’s scope; downward, it does not directly specify any chip’s instruction encoding, but instead makes “target mappings” into versioned profiles that declare, item by item, which register classes, register groups, and instruction sequences they map to, along with the corresponding upstream revision number and validation evidence for that profile. The notation form follows the RVV Intrinsics approach to express typed operations, operand roles, and register-group constraints; tiles range from one-dimensional to N-dimensional, reshape and axis permutation must preserve element positions, and layouts are derived from linear layouts.

What best illustrates the problem it aims to solve is the “expressibility requirement”: any optimization of an RVISA tile computation must be writable by the programmer at the notation level. This constraint targets precisely the most common failure mode when matrix extensions land—the compiler quietly does its own vectorization, the programmer can neither see nor change it, and switching to another chip means rewriting everything. RVISA attempts to make this layer explicit, so that the same notation runs different mapping profiles on different implementations while semantics stay consistent.

Maturity needs to be stated clearly: the specification status file itself says this is a working draft, not an approved RISC-V International specification. The core model, type and operand rules, tile layouts and optimization, and key operation signatures already give concrete contracts, but the target mapping profiles are registered only as drafts, with no implementation-consistency evidence yet established; the MLIR dialect is marked TBD; the reference payload consists only of source forms in .rvisa notation and cannot be compiled or executed; and the executable conformance tooling is likewise TBD. The repository also contains three draft RFCs, 0001 through 0003, covering the instruction and register mapping contract, the core type and operation contract, and programmer-expressible tile layouts, respectively.

Placed in today’s industry coordinates, this is two expressions of the same logic as what Quintauris is doing on the MCU side in the same batch: the fragmentation brought by open instruction sets must ultimately be converged by some stable “software target” layer. On the MCU side, convergence happens on binary compatibility and interrupt semantics; on the AI matrix side, it happens on virtual notation and mapping contracts. The difference is that EM-Altair is backed by a joint venture of six major automotive and embedded vendors, whereas RVISA is currently a working draft led by a single vendor—whether it is picked up by upstream matrix-extension discussions will depend on whether anyone subsequently fills in implementation evidence for the IME, VME, and AME lines in that mapping table.

Date: repo created 2026-11-04, commits 2026-11-05　Source: spacemit-com/rvisa repository, specification status page

Today’s Focus: Quintauris Releases EM-Altair, an MCU-Class RISC-V Standardized Platform with RV32IM as the Baseline for Binary Compatibility (released 11-03, reported 11-05)

On November 3, Quintauris released EM-Altair, which it describes as a standardized embedded platform for microcontroller-class RISC-V systems. It does not define new cores; instead, it defines a set of hardware, firmware, and runtime requirements that “compliant implementations must behave consistently against”: four layers covering the ISA profile, privileged architecture, boot and runtime services, and security services. Vendors can implement their own microarchitectures, but software faces the same target. Chief Product Officer Angel Berrio Moreno put it as “the same binary, the same interrupt behavior, the same security assumptions.”

In concrete terms, EM-Altair uses RV32IM as its baseline, paired with a clearly bounded set of mandatory and optional extensions, fixing interrupt, atomic operation, CSR behavior, and memory ordering rather than leaving them a moving target. The interrupt portion specifies a bounded, high-throughput architecture aimed at hard real-time workloads; isolation uses PMP covering machine mode and optional user mode to separate trusted from untrusted code; security practices align with ASIL-B equivalent requirements and reserve security hooks for firmware integrity and device protection. The target scenarios are stated plainly: body electronics, zonal and cockpit controllers, EV energy management, as well as industrial control loops, IoT sensor nodes, and wearables.

The accompanying tool is QNTAF, Quintauris’s own verification and certification framework. Per the official description, vendors can run benchmark, conformance, and security test suites on three target types—cloud, simulator, and FPGA—wire these tests into CI/CD, and generate the traceable artifacts required for certification. The specification and tools are open to SoC vendors, RTOS developers, and OEMs. Quintauris was founded in 2023 as a joint venture by Bosch, Infineon, Nordic, NXP, Qualcomm, and STMicroelectronics, and does three things: profiles, reference architectures, and software components.

This news is worth reading alongside Infineon’s November 4 release of AURIX RC1. Infineon is a founding member of Quintauris, and AURIX RC1 merges the AURIX and TRAVEO T2G product lines onto a single RISC-V base, while EM-Altair provides precisely the common execution environment on top of that base—chipmakers do the implementation, the joint venture does conformance, and RTOSes and compilers need only adapt once to a single target. For domestic teams working on automotive-grade and industrial RISC-V, this means two things are happening at once: the barrier to foundational software is falling (AUTOSAR, RTOS, and toolchains no longer need to be rebuilt by each vendor), while the barrier to entry is rising (customers will ask “does it comply with a given profile?”).

Date: released 2026-11-03, reported 2026-11-05　Source: Quintauris release, New Electronics report

I. Open-Source Community and Software Ecosystem

openRuyi Adds 20 Document-Format Import Libraries in One Batch, Pointing to the Office Suite Dependency Closure (11-05)

At 19:59 on November 5, a single account pushed 20 SPECS directories into the openRuyi main repository under the same timestamp, all of them document-format import libraries: libvisio (Visio), libwpd/libwpg (WordPerfect), libwps (Works), libzmf (Zoner), libabw (AbiWord), libcdr (CorelDRAW), libe-book, libepubgen, libetonyek (Apple iWork), libfreehand (FreeHand), liblangtag, libmspub (Publisher), libmwaw, libodfgen, liborcus, libpagemaker, libqxp (QuarkXPress), libstaroffice, plus the underlying mdds and liborcus.

These packages are not scattered one-offs but the same family of libraries (the librevenge family) that LibreOffice’s document-format import filters depend on, together with their underlying data-structure dependencies. Landing them all at once within the same second indicates that what is being done is closing out the dependency closure rather than filling in packages piecemeal—either paving the way for introducing the office suite as a whole, or converting the existing software stack’s build dependencies from temporary workarounds into formal packaging. It should be noted that the latest items on the openRuyi official news page are still the two from October 2026 (the Ruyi Firmware solution and RISC-V ecosystem public infrastructure); the November release has not yet been published, so today’s item can only be counted as repository-side progress and must not be written up as a distribution release.

On the same day, openRuyi’s clang-wrap repository had a commit “fix LLVM IR handling in compiler and package builds,” consistent with the packaging work direction of the main repository.

Date: 2026-11-05　Source: openRuyi-Project/openRuyi main repository, openRuyi official news page

CORE-V CVW Merges 11 Commits: Ubuntu 26.04 Install Fix, AMO Read-Path Timing, Branch-Prediction Missing Signal (11-05/11-06)

CORE-V Wally (cvw) merged 11 commits today, which can be divided into three groups. The build-and-test-infrastructure group: fixing the custom install script under Ubuntu 26.04 (#2061), rebuilding buildroot (#2039), adjusting the compilation options for the Embench speed test (#2031), and adjusting the CoreMark compilation options (#2024). The microarchitectural-timing group: timing convergence of the AMO read path (#2020), latched register file (#2050), AMO bus atomic operations for the HPTW (#2046), and simultaneous RAS updates (#2041). The correctness group: fixing the branch-prediction missing signal and configuration errors, cleaning up extra lint errors, and finally closing out with the merge of #2076 (November 6, 00:41).

The notable proportion is that half the commits fall on the three things “can install, can build, can run benchmarks.” CVW is a teaching- and research-oriented core, but recently it has been treating Ubuntu 26.04 compatibility, buildroot rebuilding, and CoreMark/Embench compilation options as serious matters; this pace is closer to the engineering quality of preparing for tape-out and external delivery, not merely RTL for publishing papers.

Date: 2026-11-05, 2026-11-06　Source: openhwfoundation/cvw

XiangShan Fixes Store Merging Under Speculative Prefetch in MissQueue; Six GEM5 Commits Focus on Evaluation Infrastructure (11-05)

The XiangShan main repository had one commit today: fixing the issue where MissQueue still merges stores when a prefetch miss is in a speculative state (#6842). This is a correctness fix rather than a performance change—merging a store with a not-yet-determined prefetch means that once the prefetch is cancelled, the ownership of the written-back data goes wrong.

On the GEM5 side there were six commits, clearly oriented toward evaluation infrastructure: wiring google trace and cbp trace into CI (#1272), adding a statistical PMU for Fetch Block Size (#1291), updating the SPEC06 RVV checkpoint profile and aligning the scalar floating-point portion, adding an optional switch to the weekly performance task (#1300), adding a survey document on hardware prefetch algorithms (#1302), and having cpu-o3 filter resolve inputs using “oldest same-cycle squash” (#1282).

Looking at these two items together with the leaderboard changes on riscv100.top since October, the recent focus of the XiangShan line is “fix the measurement methodology first”: the checkpoint profile determines which segment of the workload is reproduced, the trace determines what granularity can be traced, the PMU determines whether the performance numbers can be broken down and explained, and the weekly performance task determines how often these numbers come out. Scores only have comparative value when built on a reproducible measurement methodology.

Date: 2026-11-05　Source: OpenXiangShan/XiangShan, OpenXiangShan/GEM5

P4 Launcher Delivers a PC-Like Experience for Loadable Apps on ESP32-P4, with 21 PAPP Apps (11-05)

Developer Gil Tal has released P4 Launcher, an open-source application platform for ESP32-P4 development boards with touchscreens. It boots directly into its own interface; apps are stored as .papp files on a microSD card and loaded into PSRAM at startup, so adding or removing apps only requires copying files to the card—no need to reflash firmware or reboot the device. There are currently 21 PAPP apps, mostly emulators and games: Neo Geo and Atari 2600 emulators, Doom, Quake, Duke Nukem 3D, OpenTyrian, plus a clock and a file manager.

In implementation, the interface is based on LVGL, with a compositor responsible for scaling the UI to different resolutions; the audio engine supports up to 8 channels at 4 to 192 kHz; up to four input devices can be connected for multiplayer gaming, with support for PS3 and Nintendo controllers; firmware can be updated from the microSD card or GitHub, and a new version that fails to boot automatically rolls back. The project also provides an SDK for developers to write their own PAPP apps, along with two compatibility layers: one reimplements the odroid_* interfaces, and the other implements the old PAPP v1 service table—the latter is precisely why old code like Doom and Quake can run on the original glue layer. The code is based on ESP-IDF v5.5.2 and has been adapted for Guition’s 4.3-inch and 7-inch boards as well as the M5Stack Tab5.

The value of such a project is not “it can play games,” but that it has made the whole set of conventions for app packaging, loading, updating, and rollback work on an MCU. The ESP32-P4 is Espressif’s high-performance RISC-V model (dual-core HP plus an LP core), and PSRAM bandwidth, display, and audio subsystems are exactly the pressure points for this kind of workload; a mature application-container convention says more about platform usability than running one more emulator.

Date: 2026-11-05　Source: CNX Software report, giltal/ESP32_P4_Launcher

II. Product and Ecosystem Updates

HPMicro’s Second Ecosystem Conference Set for November 21 in Shenzhen, with 14 Sessions Tying RISC-V MCUs to AI (11-04)

HPMicro has confirmed that its second HPMicro Ecosystem Conference (HPMicro Semiconductor Ecosystem Day) will be held on November 21 (Saturday) from 9:30 to 17:00 at the Westin Shenzhen Nanshan, under the theme “AI Empowers Chips, Developers Build the Ecosystem Together.” The event is by registration and invitation only; attendees must scan a QR code to register in advance and confirm via an official HPMicro email reply. The conference was first previewed in mid-October at the 6th RISC-V China Summit (Shenzhen), and HPMicro positions it as the primary platform for exchange and collaboration within the high-performance RISC-V MCU ecosystem.

The agenda lays out the “RISC-V MCU plus AI” thread very directly. The morning opens with products and toolchains: Qian Jianghao, HPMicro’s Software Director, speaks on “Embracing AI Agentic / Vibe Coding, Making Embedded Development Vibe Too,” followed by HPMicro’s RISC-V MCU product matrix and multi-scenario applications; Sheng Lei, SEGGER China’s Technical Director, covers toolchain support from R&D to mass production; Li Zhenhong, a senior engineer at RT-Thread, discusses RT-Thread’s hardware-software co-adaptation and engineering practice on the HPM6750; then HPMicro presents an end-to-end DC arc detection development platform, and Ling Guoxiong, a DFM technical engineer at Huaqiu, explains how upfront DFM can compress prototyping cycles to 48 hours. The afternoon shifts to solutions and hands-on developer sessions: drone flight control and ESCs, AI-enhanced speech recognition plus vision plus motion control, applications of the cherry suite on HPM chips, PocketJS on HPMicro, a hands-on session on AI-assisted HPM SDK application development, a field report on the open-source HelixLink implementation, and finally a Q&A on common issues and a live raffle.

What is more noteworthy than the number of sessions is the composition of the agenda: of the 14 sessions, only 3 feature HPMicro itself presenting products; the rest come from a toolchain vendor (SEGGER), an open-source RTOS (RT-Thread), a manufacturing service (Huaqiu DFM), and community developers (Sakumisu, Half Sweet, RCSN, HelixLink). For an MCU vendor, this ratio is itself a signal of ecosystem maturity—it turns “ecosystem” from its own SDK documentation into reports from others delivering work on its chips.

This aligns with last week’s developments: in late October to early November, HPMicro pushed 12 RT-Thread BSP repositories to v1.13.0 in a unified batch within 13 minutes, and opened a new BSP repository for the HPM5100EVK; the HPM5100EVK also appears in this conference’s raffle prize list. On the chip side, the HPM5100/HPM6E8Y and HPM5300EVK have also been listed in the body layer and cerebellum layer selections of the RV-EAI embodied intelligence open solution. In other words, the conference agenda and HPMicro’s repository activity over the past two weeks point in the same direction: pushing RISC-V MCUs from “having chips and an SDK” to “having third parties continuously delivering on its platform.”

This is the first time a domestic RISC-V MCU vendor has put “AI-assisted development” at the center of its ecosystem conference (the opening session is on Vibe Coding), and it has also scheduled talks from third-party toolchains and open-source RTOS ahead of its own product talks. The value of such an ecosystem conference is judged not by the number of sessions but by how many third-party projects, after the event, write “supports HPM” into their release notes. There were no new developments during this issue’s window; this item is a preview of the event schedule rather than a report of an event already held.

Date: 2026-11-04　Sources: WeChat Official Account: HPMicro RISC-V MCU Developer Ecosystem Day Event to Be Held Soon in Shenzhen, 52solution reprint of the same topic, 6th RISC-V China Summit report (previewing the event)

Cercis M100 Selected as a “China Chip” RISC-V Ecosystem Promotion Demonstration Case, Putting a Separate Price on the Ecosystem Ledger for Automotive-Grade MCUs (11-05)

Changsha Evening News reported on November 5 that the results of the 21st “China Chip” outstanding product solicitation for 2026 have been announced, and the Cercis M100 automotive-grade RISC-V MCU, independently developed by Hunan Cercis Semiconductor, was selected as a “RISC-V Ecosystem Promotion Demonstration Case.” The solicitation is guided by the Ministry of Industry and Information Technology and hosted by the China Center for Information Industry Development; the newly established “RISC-V Ecosystem Promotion Demonstration Case” category focuses on selecting projects with demonstration value in technology implementation, ecosystem adaptation, upstream-downstream joint promotion, and large-scale adoption.

The Cercis M100 is built on a foundation laid by a team incubated at Great Wall Motor’s Technology Center: it is China’s first automotive-grade MCU designed on an open-source RISC-V core, entered mass production and vehicle deployment on December 18, 2025, and is mainly used in body control scenarios such as combination headlights, ambient lighting, and combination switches; as of October 9 this year, cumulative shipments have exceeded 10 million units. The company says it has developed more than 15 core IPs in-house, possesses a complete MCAL, low-level driver SDK, real-time operating system, and development/debugging environment, and has passed ISO 26262 ASIL-D process certification, ASIL-B product certification, ASPICE, and AEC-Q100. Its product line has expanded to the M100/M200/M300 and companion power driver chips; the M200 is planned for tape-out in Q4 this year (40nm process), targeting combination instrument clusters, T-BOX, gateways, BCM, and more; and the E100 cerebellum control chip for embodied intelligence is in development.

The highlight here is not the chip’s specifications but the award criteria: making “ecosystem promotion” a separate award category means the review process has begun to price “upstream-downstream joint adaptation and large-scale adoption,” rather than comparing only performance and process. For a domestic automotive-grade RISC-V team that only entered vehicle deployment at the end of 2025 and only passed 10 million units this October, the sample value of this path outweighs the award itself.

Date: 2026-11-05　Sources: Changsha Evening News report (Sohu reprint), Cercis Semiconductor official website

India’s MeitY Sets a 24-Month Target for Homegrown GPUs and Pushes Commercialization of the SHAKTI and VEGA RISC-V CPUs (Reported 11-05)

On November 5, Tom’s Hardware cited an ETGovernment interview (published November 4) with S. Krishnan, Secretary of India’s Ministry of Electronics and Information Technology (MeitY): under the “India Semiconductor Mission 2.0” framework, India plans to produce a homegrown GPU chip in about 24 months. The mission was approved by the cabinet in July 2026, with a scale of about $15 billion and a 12-year duration. Krishnan divides the AI hardware ecosystem into five layers—energy, accelerator chips, computing infrastructure and servers, AI models, and applications—and says Indian companies VVDN, Kaynes, and Avalon are already manufacturing servers, while the Centre for Development of Advanced Computing (C-DAC)’s in-house Rudra server series has been licensed by the government to local manufacturers.

Directly relevant to RISC-V is another statement: India is simultaneously pushing commercialization of its two in-house processors, SHAKTI and VEGA. Both are based on the open RISC-V instruction set and are CPU designs, separate from the aforementioned GPU goal. The verifiable progress available is C-DAC’s VEGA ET301—32-bit, up to 100MHz, 26KB SRAM—used in the Aries 3.0 development board launched in 2024, positioned for light loads such as sensing, wearables, and IoT; at the SEMICOM India event on September 26 this year, the government showcased a water-surface cleaning robot based on SHAKTI and a digital telescope and forest environment monitoring project based on VEGA. The Design Linked Incentive (DLI) scheme has supported 24 companies, covering microcontrollers, drone flight control, smart meters, and surveillance camera chips.

The need for restraint is also clear: the GPU goal has not disclosed manufacturing partners, chip suppliers, or architecture licensing details, and is a policy declaration and roadmap; the verifiable part is the commercialization path of SHAKTI and VEGA, and their existing products (100MHz-class 32-bit MCUs) are still far from “AI acceleration.” India’s semiconductor market is currently about $50 billion, with official expectations of approaching $100 billion by 2030.

Date: Reported 2026-11-05 (interview published 11-04)　Sources: Tom’s Hardware report, ETGovernment interview

III. Deep Dive into Domestic Teams

SpacemiT Robotics SDK Completes Three Repos: manipulation and dice_arena Added to Manifest, K3 Robotic Arm Manual Synced (11-05)

The spacemit-robotics organization today filled in a layer of the robotics SDK’s component stack: the manifest repo pushed three commits in a row (#29 adding manipulation and dice_arena, #30 switching pyagxarm to track main, #31 making integrated control projects uniformly track main), formally wiring the two new components into the SDK’s repo list. Both newly added repos are brand new—manipulation’s first commit landed on October 30, dice_arena’s first on November 4, and on November 5 alone they pushed 16 and 18 commits respectively.

Supporting docs followed the same day: spacemit-com/docs-ros pushed three commits, adding a deb usage guide for the Orbbec camera (#225) and guides for robotic arm operation and the dice game on K3 (#227, #228), with the latter two also specifically reordering the robotic arm section.

Taken together, these three developments show that SpacemiT’s K3 is more than “a board that runs ROS 2”: the manifest determines which components belong to the SDK, the docs determine whether developers can follow along, and the components determine whether hardware actions can be reused. All three advancing on the same day signals that the robotics line is shifting from one-off demos to deliverables with versions, manifests, and manuals.

Date: 2026-11-05　Source: spacemit-robotics/manifest, spacemit-robotics/manipulation, spacemit-robotics/dice_arena, spacemit-com/docs-ros

Sophgo Adds 2-Core/3-Core bmodels and Stress Tests for Qwen3.5-0.8B: TPS 51.89 and 55.20 (11-05)

Sophgo’s sophon-demo Qwen3.5 example was updated today, adding 2-core and 3-core variants of the 0.8B model on the CV84X6 platform: the download script download_bmodel.sh gains the corresponding bmodels, and the README’s model directory tree, build instructions (--num_core 2/3), and performance table each gain two rows. The figures given by the author are averages from 20 serial stress-test rounds: 2-core first token 0.868s, TPS 51.89; 3-core first token 0.681s, TPS 55.20.

These two numbers are more useful than peak compute. Going from 2 to 3 cores cuts first-token time by 21.5% while throughput rises only 6.4%—the speedup ratio is far below the core-count ratio, indicating the bottleneck lies mainly in weight movement and scheduling rather than matrix compute; for those deploying small models on edge devices, this directly determines whether to add cores or change the data layout. Sophgo also had LLM-TPU merge #184 and a cleanup in bootloader-riscv removing an unused packaging script the same day.

Date: 2026-11-05　Source: sophgo/sophon-demo, sophgo/LLM-TPU

Nuclei Tool Guide Adds rvtrace and Hummingbird Debugger Troubleshooting (11-05)

Nuclei’s nuclei-tool-guide merged #81 today, adding rvtrace documentation and Hummingbird debugger troubleshooting content to the OpenOCD chapter, authored by wangyanwen. The change is small, but the direction is worth noting: RISC-V instruction trace was previously seen mostly on high-end cores and dedicated probes, and is now starting to appear as a “standard chapter in the tool guide” within a RISC-V MCU vendor’s documentation system. For teams working on real-time control and safety certification, whether usable trace can be obtained directly determines whether problems can be localized to the instruction level.

Date: 2026-11-05　Source: Nuclei-Software/nuclei-tool-guide

Espressif esp-riscv-trace Lands CI and Pre-commit, Trace Decoding Split into Its Own Repo (11-05/11-06)

Espressif’s esp-riscv-trace repo pushed 4 commits today: adding a GitLab CI pipeline, adding pre-commit configuration, updating GitHub workflows, and finally merging the ci/pre_commit_and_pipelines branch into master (November 6, 04:03). The repo was created back on August 26; at the top level is a Python package named esp_riscv_trace, along with a ci directory, pyproject, and LICENSE, indicating it handles trace data decoding and tooling support rather than RTL.

The same day arduino-esp32 had two commits (network layer IPv6 DNS configuration support #13040, clarifying Wire slave onRequest usage #13067). Splitting trace decoding into a standalone repo with dual CI (GitHub and GitLab) and pre-commit checks is a signal that Espressif is delivering this capability as an independent component—chip support for trace is only the first step; being able to decode it into something human-readable is what makes it usable.

Date: 2026-11-05, 2026-11-06　Source: espressif/esp-riscv-trace, espressif/arduino-esp32

IV. Embodied Intelligence and Robotics Special Chapter

SpacemiT manipulation component: device exclusivity, arrival detection, timeouts, and fault locking folded into the device session (11-05)

manipulation is the robotic arm control component in the SpacemiT robotics SDK, and what it does is “unified control of robotic arms and end effectors”: select hardware via device configuration, issue actions through the same set of commands or C++/Python interfaces, and provide kinematics, hand-eye calibration, and device utilities. It currently ships with three drivers: the software-simulated mock_device; agx_nero_revo2, corresponding to the AgileX Nero seven-axis with an optional Revo2 right hand (Revo2 has no position feedback); and so101, five-axis with an optional stock gripper, plus a servo calibration tool.

Its architectural trade-offs are stated very explicitly. C++ applications link the component library directly and use DeviceSession in-process; command-line and Python applications go through DeviceClient, which launches the local process manipulation-device serve and issues requests over JSONL; YAML waypoint tasks are executed by manipulation-device run. The device session uniformly handles device exclusivity, arrival detection, cancellation, timeouts, and fault locking. The driver layer is responsible only for model protocols and unit conversion; kinematics and hand-eye calibration take models from device.yaml and descriptions/, with no hardcoded models; to add a new device, implement Arm and EndEffector and register them.

Most worth noting is that passage: “the component does not auto-enable, does not auto-clear errors, does not auto-home, does not auto-retry.” In embodied intelligence projects, the easiest place to cut corners is letting middleware make decisions for people—and once these four things are done automatically, on-site personnel lose the basis for judgment when problems arise. Putting the safety boundary at the session layer rather than the driver layer is the restraint that robotics middleware ought to have.

Date: 2026-11-05　Source: spacemit-robotics/manipulation

dice_arena runs the full dice-game pipeline with K3 plus Nero seven-axis plus Revo2 dexterous hand (11-05)

dice_arena is a comprehensive demo on the same SDK: visual cup grasping, cup shaking and placing, hand-eye calibration, dice recognition, voice announcements, and a web game. The hardware list is written concretely—a SpacemiT K3 development board as the main controller, an AgileX Nero seven-axis robotic arm connected via a USB-CAN adapter (SocketCAN, 1Mbps), a Revo2 right-hand dexterous hand mounted at the end effector (six control channels, sharing the controller connection with the arm), an Intel RealSense D435i for cup grasping and calibration, a top-down USB camera for dice recognition (Logitech C920 by default, MJPEG), plus a ChArUco calibration board, a speaker, and green cups.

On the software side, dice-arena serve starts video forwarding, local voice, and the game backend; the backend runs a state machine (rule explanation, cup grasping, cup shaking, cup placing, visual judgment, result gesture, return to HOME), invoking each component by slot; cup grasping is handled by CupApplication, which recognizes the cup body from RealSense images, solves the inverse kinematics, and checks the path, with actions issued via manipulation’s DeviceClient; recognition is performed by vision_yolov8_objdetect inferring on the SpacemiT EP, with the feed pushed to MediaMTX over RTSP and played in the browser via WebRTC; voice is synthesized by tts_moss_nano calling the local MOSS-TTS and played through PipeWire on the board.

What is truly valuable is the failure handling: the task policy library libcup_task.so checks stage ordering via a C ABI; once an action is issued, a failure locks it, and states requiring manual intervention are written to task_state.json; after a program restart it still refuses to move until on-site personnel have dealt with it and run dice-arena reset. The thing most easily omitted in embodied intelligence demos is exactly this state machine—and it is precisely the part that can least be omitted in mass production.

Date: 2026-11-05　Source: spacemit-robotics/dice_arena

humanoid line adds standing policy and navigation: LingLong SuperMimic and G1’s RGBD SLAM/Nav2 (11-05)

humanoid_linglong had two commits today: #22 adds LingLong’s SuperMimic standing policy configuration, and #21 adds gripper models and manipulation task scene setup. The former plugs an already-trained standing policy into the configuration system; the latter fills in the grasping-side models and scenes—one line handles “staying on its feet,” the other handles “getting a grip.”

ros2_humanoid had one commit the same day, adding RGBD SLAM and Nav2 navigation configuration to the humanoid platform G1. Compared with the similar commit on November 4, this time two complete sets of configuration went into the repo together rather than a single-point parameter tweak. Standing policy, navigation stack, and gripper scenes advanced in the same afternoon, indicating that this line is filling in foundational capabilities rather than piling up demo videos—what really holds humanoid robots back is often precisely standing stability and autonomous mobility.

Date: 2026-11-05　Source: humanoid_linglong, ros2_humanoid

V. Summary and Trend Observations

There are two main threads today—one about abstraction layers, one about standardization—converging on the same question.

SpacemiT’s RVISA provides a layer of virtual instruction notation on the AI matrix side, writing “the optimizations a programmer can express” as hard constraints, then mapping them to the three still-in-progress matrix extensions IME, VME, and AME via versioned mapping profiles; Quintauris’s EM-Altair provides a binary-compatible execution environment on the MCU side, fixing interrupts, atomics, CSRs, and memory ordering into a set of behaviors that a compliant implementation must follow. Both are answering who should converge the fragmentation brought by open instruction sets: rather than letting chip vendors each interpret the spec their own way, insert a stable software target between spec and implementation. The difference lies in governance structure—one is a joint venture of six major vendors, the other a working draft from a single vendor.

The focus of domestic vendors’ moves continues to shift from “chips and boards” toward “components and specs.” In a single day SpacemiT advanced the RVISA spec, three robotics SDK repositories, and the K3 robotic arm manual; Sophgo provided end-to-end stress-test numbers for 2-core and 3-core rather than peak compute; Zijing turned “ecosystem promotion” into a case that can be submitted for recognition. What these three have in common is that they are all filling in the “can others actually use it” side, rather than shipping another chip with higher specs.

Automotive-grade remains the biggest battleground, and today shows three layers advancing simultaneously: the chip layer (Infineon AURIX RC1, 11-04), the platform spec layer (Quintauris EM-Altair), and the ecosystem case layer (Zijing M100 selected as a China Chip demonstration case). These three layers are not in competition but are different positions along the same industry chain doing the same thing—turning open instruction sets into deliverable automotive-grade products.

On the benchmarking side, the pattern continues of “solidifying the measurement method first.” Five of GEM5’s six commits today are infrastructure such as checkpoints, traces, PMUs, and weekly performance tasks; riscv100.top’s comparison view yesterday and today’s leaderboard rollback are the same kind of phenomenon: the leaderboard is still in a settling period, and the comparability of the numbers deserves more attention than the numbers themselves.

Supplementary Observations (riscv100.top and member website inspection)

riscv100.top had no new scores today. The “SpacemiT K3 X100 XSCC 2.0 SPEC CPU2026 Rate” appearing in the homepage What’s New corresponds to the October 10 record (already reported as a backfill on November 4); it reappeared in the list after the homepage list was reordered and is not new data. The 39 “leaderboard entries dropped” reported by the script are also not real drops—they are all comparison rows generated by the Run Comparison view launched on November 5, which disappeared from the six leaderboard pages today; this report does not count them as score changes. The three Upcoming items remain in Preparing: AWS Graviton5 NeoverseV3 (SPEC2006/2017/2026), SpaceMiT K3 X100 (Vectorization/IME), and GCC 16 SPEC CPU Testing. There were no additions or removals among committee members.

The member website inspection covered 391 sites, 92 of which had page changes; on review, all were homepage marketing content updates, involving Google, National University of Singapore, StarFive, Infineon, Renesas, and others, with no substantive developments such as new products, financing, partnerships, or architecture launches, so they are not included in this issue.

Date: 2026-11-06 inspection　Source: riscv100.top homepage, RISC-V channel SPEC CPU2026

Appendix: Full Source List

Full Source List

Source Verification Table

Source Verification Result
Google News aggregation (20+ queries in Chinese and English) 6 valid new items within the window: India GPU/SHAKTI/VEGA, Quintauris EM-Altair, Cercis M100 selected as a China Chip case, P4 Launcher, SpacemiT RVISA-related discussion, and follow-up reprints on Infineon AURIX RC1 (this item was already featured as a top story on 11-04 and is not counted again in this issue)
Hacker News / Phoronix / CNX / LinuxGizmos One CNX item on P4 Launcher (included); no RISC-V-specific hits from Phoronix or LinuxGizmos within the window
GitHub organizations and key repositories check Anonymous API quota exhausted; switched to Atom feed coverage of 12 organizations and 103 repositories: 26 repositories hit within the window. Active ones: openRuyi (20 commits), rt-thread (20 commits, not RISC-V-specific and not counted), three spacemit-robotics repos (36 commits), spacemit-com’s rvisa and docs-ros (6 commits), CORE-V cvw (11 commits), XiangShan and GEM5 (7 commits), Sophgo, Nuclei, Espressif, Sipeed
openRuyi dual-source check The latest items on the official news page are two from 2026-10 (Ruyi Firmware, ecosystem public infrastructure); no November release yet; 20 SPECS commits within the window in the main repository (bulk completion of the documentation import library), plus one build fix in clang-wrap
riscv100.top inspection No new results: the K3 X100 entry under What’s New corresponds to an old 10-10 record; the 39 “delisted” entries are due to rows disappearing from the comparison view table; the three Upcoming items remain Preparing, with no additions or removals by the committee
Member official website inspection 391 sites crawled, 92 with page changes, all marketing page updates with no substantive developments; 67 failed to crawl (Alibaba, Institute of Software CAS, MediaTek, etc.), which does not block the conclusions
WeChat official accounts and vendor websites HPMicro ecosystem conference (user-specified queue item, included); Cercis Semiconductor official website used to verify product line and certification information