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

Sources: Google News aggregation (12 supplementary queries in Chinese and English, via proxy), Hacker News, Phoronix, CNX Software, LinuxGizmos, LWN, arXiv, the official riscv.org blog, the openRuyi official news page and main repository, website inspections of RISC-V International member companies (391 companies), the riscv100.top leaderboard inspection, as well as commit and release searches across organizations and key repositories on GitHub including XiangShan/NEMU/difftest/XSCache, CORE-V CVW/cvfpu/CVA6, DAMO XuanTie, ESWIN, Sophgo, Nuclei, Espressif, SpacemiT and spacemit-robotics, Sipeed, revyos, openRuyi-Project, and Radxa Linkr.

Issue Index

  • Today’s Focus: Andes slows down high-end RISC-V CPU Cuzco; AI business already accounts for half its revenue (11-02)
  • RISC-V 100 Leaderboard Updates
    • Backfilled 07-30 record: XSCC 1.1 on SpacemiT K3 X100, SPEC CPU2026 Rate int 0.9, fp 1.07 (11-03 inspection)
    • What’s New adds a “Hardware Comparison” page; three Upcoming items still Preparing (11-03 inspection)
  • I. Open Source Community and Software Ecosystem
    • XiangShan restores out-of-order CSRR execution to backend decode (11-02)
    • XiangShan TAGE bankIdx switches to history bits, making all 2048 slots across four banks usable (11-02)
    • XiangShan precomputes BPU s2/s3 override conditions, compressing the final-stage logic of the next-PC path (11-02)
    • XiangShan points the XSCache submodule to the version fixing “late hints” (11-02)
    • difftest preserves asynchronous AME checker state during squash replay (11-02)
    • NEMU routes matrix accesses through the shared TLB optimization path; CI switches to reusing performance comments (11-02)
    • CORE-V CVW three commits: reload DTLB after sfence.vma, clean up unfinished CLINT code, collect functional coverage with Verilator and VCS (11-02 to 11-03)
    • CORE-V cvfpu fixes FFLARNC with a named clear signal (11-02)
    • openRuyi fixes the ninja link command in clang-wrap; mtools patches CVE-2026-118384 (11-02)
    • KU Leuven open-sources the first DMP implementation on a RISC-V core, proposes SecDMP defense (11-03)
    • riscv100.top launches the “Hardware Comparison” page (11-03)
  • II. Product and Ecosystem Updates
    • Europe launches the ERICI industrial computing initiative to turn RVA23 into an “industrial computer” (11-02)
  • III. Deep Dive on Domestic Teams
    • Nuclei creates new T0 Chiplet dual-SDK repos; tool guide follows the 2026.10 release (11-02)
    • SpacemiT docs-ros adds ROS 2 installation instructions for Ubuntu 26.04 (11-02)
    • Sophgo SG2044 EDK2 disables PCIe ECRC checking by default (11-02)
    • DAMO XuanTie and ESWIN: no new organization-level development within the window (11-03)
  • IV. Special Chapter on Embodied Intelligence and Robotics
    • SpacemiT merges three repos on the same day: G1 hardware deployment and ONNX motion mode go live (11-02)
    • humanoid_common supports online policy switching and asynchronous SONIC planning (11-02)
    • control_whole_body uses a triangular table for coupled mapping, adds startup feedback recovery (11-02)
  • V. Summary and Trend Observations
  • Appendix: Complete Source List and Source Verification Table

Today’s Focus: Andes slows down high-end RISC-V CPU Cuzco; AI business already accounts for half its revenue (11-02)

EE Times reported from Taipei on November 2 that Andes CTO Charlie Su confirmed the company has slowed development of its high-end RISC-V CPU IP “Cuzco,” shifting engineering resources toward its faster-growing AI business. Cuzco was originally a project of Condor, the company Andes spun off specifically for data-center-class high-end cores; it was unveiled at Hot Chips 2025 and was brought back in-house earlier this year. Su’s position is that the ecosystem must reach that point before the hardware has a chance, and the AI line is growing so fast that resources can only be pushed first to where revenue is generated immediately.

On the numbers: Andes’ AI business currently accounts for half of revenue, grew 30% last year, and is expected to grow 50% this year. Its in-house deep learning accelerator is modest—about 4 TOPS (1 GHz) with its own compiler; the bulk of AI revenue comes from AI chip companies using Andes CPU cores for control, orchestration, and data movement, with customers including Meta, d-Matrix, Fractile, and Axelera. These licenses are mostly custom cores with extremely tight delivery schedules, which is also why internal resources were pulled away.

Cuzco has not been cancelled. Su said it will still become a product, possibly under a different name, but the timeline is stretched, and the company will “do it slowly while waiting for a signal worth accelerating for.” He laid out the logic of the IP business fairly plainly: the core contributing the most revenue today was designed over a decade ago, and customers may iterate on the same core for more than ten years, so “getting it right and reusable” matters more than being first. Near-term priorities are controller cores for the storage market (10 customers already in volume production with small controller cores), automotive, and robotics. Another backdrop is that Arm’s launch of its own high-end CPU silicon changed the business model; Su believes this has instead damaged customer trust, which benefits IP suppliers like Andes.

A judgment worth noting: this news runs counter to the narrative that “RISC-V is charging toward high-end data center,” but it is not contradictory—development of high-end cores has not stopped; only the commercial cadence is now set by market momentum rather than the roadmap. What is actually paying is AI edge and control plane. For domestic teams working on high-end RISC-V cores, this is a realistic reference point on “who pays first.”

Date: 2026-11-02　Source: EE Times: Andes Waits For Market Momentum For Cuzco CPU

RISC-V 100 Leaderboard Updates

This inspection is only one day after the last, and the script judged it a significant change, so per the criteria it is placed near the front of the main text.

New leaderboard entries (one each for Cross-arch · SPEC CPU2026 and the RISC-V channel · SPEC CPU2026): 07-30 XiangShan compiler team (XSCC) / SpacemiT XSCC 1.1 on SpacemiT K3 X100 2.4GHz int 0.9, fp 1.07 (rate/ref, Completed); versus the platform’s previous record (05-31, LLVM 22.1.0), int +2.3%, fp +9.2%. This record is dated 07-30, far earlier than this inspection date; it is a backfilled entry and should not be read as a new result of the day, nor should architectural improvements be inferred from it—it belongs to a different leaderboard surface from yesterday’s backfilled 10-17 CPU2006 speed record (XSCC 2.0 on XiangShan KMHv3 RTL 3GHz, int 68.41, fp 76.95), and does not constitute a top-spot replacement.

What’s New adds two items: SpacemiT K3 X100 XSCC 1.1 SPEC CPU2026 Rate (corresponding to the leaderboard record above; described together and not counted separately), Hardware Comparison Now Available (site feature announcement, see Section I).

Three Upcoming items remain Preparing: AWS Graviton5 NeoverseV3 (SPEC2006/2017/2026), SpaceMiT K3 X100 (Vectorization/IME), GCC 16 SPEC CPU testing. No additions or removals among committee members.

Date: 2026-11-03　Source: riscv100.top Cross-arch SPEC CPU2026, riscv100.top RISC-V channel SPEC CPU2026, riscv100.top homepage

I. Open-Source Community and Software Ecosystem

XiangShan Restores Out-of-Order CSRR Execution to the Backend Decoder (11-02)

PR #6779 restores out-of-order execution for CSRR-class instructions. The background: after XiangShan’s backend added a new decode unit, the earlier out-of-order CSRR implementation was dropped, so CSR reads and writes that could previously issue in parallel fell back to serial execution, slowing every path that depends on CSRs. The direct purpose of this change is to reconnect it to the new decode pipeline.

The author also flags an omission: in the pseudo-decode channel, CSRRVL and CSRRVLENB are special-cased only when they appear in CSRR form, while CSRRSI/CSRRC/CSRRCI — forms that also read and write the vector length register — are not covered. Gaps of this “only one encoding form handled” kind are common in vector code, because compilers often serialize vsetvl into a string of CSRRSI rather than CSRR.

Date: 2026-11-02　Source: XiangShan #6779

XiangShan TAGE bankIdx Now Uses History Bits, Making All 2048 Slots Across Four Banks Usable (11-02)

PR #6771 changes how the TAGE branch predictor is indexed. Previously the bank was determined solely by PC, meaning a given history segment could only ever land in one bank’s 512 entries, wasting the capacity of the other three banks for that history. After the change, history participates in both bank and set selection, so in theory all 2048 slots across the four banks become usable.

The measured results are stated with restraint: astar, xalancbmk, and gobmk show clear gains, while libquantum regresses because the new structure is more prone to bank conflicts; the author leaves that for follow-up. The value of this change lies in exposing an often-overlooked capacity accounting — no matter how large the predictor table, if indexing uses only one dimension, the effective usable capacity gets fragmented by the structure.

Date: 2026-11-02　Source: XiangShan #6771

XiangShan Precomputes BPU s2/s3 Override Conditions, Compressing the Final Stage of the Next-PC Path (11-02)

PR #6753 is a pure timing optimization. It precomputes each branch candidate’s s2/s3 override condition ahead of time, then selects the result using the one-hot mask of the “first taken branch”; at the same time, the s2 taken result is precomputed for each of TAGE’s two possible outcomes, so the late-arriving TAGE prediction only handles the final selection stage.

The effect is to reduce logic depth after the late signal on the tightest path, next-PC, while prediction behavior stays unchanged. Changes like this don’t show up in performance numbers, but they set the frequency ceiling — a continuation of XiangShan’s recent line of “clearing out high-frequency timing blockages first.”

Date: 2026-11-02　Source: XiangShan #6753

XiangShan Points XSCache Submodule at the Version Fixing “late hints” (11-02)

PR #6803 changes only a single submodule pointer, bumping XSCache from e9488ae to a041f07, with the commit message “swap out arbiter to fix late hints issue.” Pointer-only commits like this are easy to miss in a daily digest, but they often mean a cross-repo fix has landed — late hints on the cache side directly affect prefetch effectiveness, and this is work on the same line as this issue’s refactor of the XiangShan frontend prefetch queue.

Date: 2026-11-02　Source: XiangShan #6803

difftest Preserves Asynchronous AME Checker State Across Squash Replay (11-02)

PR #987 fixes state loss in matrix-extension checking during replay. The change snapshots and restores three things around a squash-induced replay: the matrix software ROB, pending msync events, and the reference-side AME state; it also threads the AME commit sequence number through asynchronous MMA checking to distinguish “errors in this packet” from “failures left over from earlier,” and drains pending checks at the replay boundary.

One engineering detail worth noting: on replay it resets queued checks and retained errors but does not replace the backend — the CUDA service and result pool stay alive so that the LightSSS subprocess already started in the parent process can reconnect. This is a prerequisite for turning matrix checking from “one-shot batch processing” into “interruptible and resumable.”

Date: 2026-11-02　Source: difftest #987

NEMU Routes Matrix Accesses Through the Shared TLB Optimization Path; CI Switches to Reusing Performance Comments (11-02)

PR #1275 extends PERF_OPT_SHARE shared-cache eligibility determination and PBMT checks to matrix accesses, while retaining the existing SLOW and two-stage translation fallback paths; matrix hits now go through the common physical access handler to preserve permission checks, AMU events, and delayed data movement. In other words, matrix memory access is no longer a bypass but is wired into the same TLB accounting as ordinary memory access.

PR #1276 is a CI improvement: performance result comments now update the same comment (located via a hidden marker) and are serialized per PR branch, avoiding duplicate comment spam from concurrently finishing CI runs. For developers reading performance regressions every day, this is more useful than another new feature.

Date: 2026-11-02　Source: NEMU #1275, NEMU #1276

CORE-V CVW Three PRs: Reload DTLB After sfence.vma, Clean Up Unfinished CLINT Code, Collect Functional Coverage in Verilator and VCS (11-02 to 11-03)

Three merged PRs cover both verification and implementation. PR #2019 changes the holdaccess test: after each sfence.vma, the data page is reloaded into the DTLB, so the test covers the real “reload after invalidation” path rather than getting lucky with a stale entry. PR #2034 removes unfinished timereg code in CLINT, the unused TIMECLK, and a batch of outdated TODO/Hack comments — 24 files, +39/−155 — debt reduction. PR #2009 lets wsim collect functional coverage on both the Verilator and VCS simulators — this matters more for open-source cores than it appears: only when functional coverage is reproducible across simulators do coverage numbers become comparable.

Date: 2026-11-02 to 2026-11-03　Source: CVW #2019, CVW #2034, CVW #2009

CORE-V cvfpu Fixes FFLARNC With Named Clear Signals (11-02)

PR #187 comes from the BSC side and changes the FFLARNC (floating-point flag clear) wiring in the 64-bit multi-mode divide/square-root unit: instead of relying on implicit positional correspondence, it switches to named clear signals to avoid miswiring in parameterized instances. Fixes like this bring no performance change, but they directly affect the correctness of floating-point exception flags — the kind of problem verification tends to miss and silicon makes hard to debug.

Date: 2026-11-02　Source: cvfpu #187

Seven commits in the openRuyi main repo during this window. The most substantive bumps clang-wrap to 20261102, fixing a defect where the native link command did not support ninja-build when building libical — build failures of such packages on RISC-V are often misdiagnosed as “upstream doesn’t support it,” when the real cause is command assembly in the wrapper layer. There is also mtools bumped to 4.0.50 for CVE-2026-118384, plus six Go ecosystem specs added in one go (Volcengine ve-tos SDK, Tencent Cloud cos-go-sdk and tencentcloud-sdk-go, go-httpheader, etc.), indicating that its cloud-native and storage stack is being filled in layer by layer along dependencies.

Date: 2026-11-02　Source: openRuyi commit log, clang-wrap 20261102, mtools 4.0.50

KU Leuven Ships First Open-Source DMP Implementation on a RISC-V Core, Proposes SecDMP Defense (11-03)

The paper from KU Leuven DistriNet and EURECOM (accepted at NDSS 2027, 32-page extended version) addresses side channels in data memory-dependent prefetchers (DMPs). DMPs have entered mainstream desktop and server CPUs; they prefetch based on pointer-like values in memory contents, which yields performance gains but encodes secrets into microarchitectural state — even constant-time code hardened against Spectre is not immune.

The paper first presents a taxonomy of DMP leaks and new attacks, then implements the first open-source DMP on a RISC-V processor, empirically showing that the only existing defense that “tries to preserve DMP performance” fails against the entire class of leaks; it then proposes SecDMP: requiring secrets to be marked in memory, ensuring the DMP never encodes those secrets into the microarchitecture, and formally proving that its leakage does not exceed “a baseline without a DMP,” all without sacrificing performance on public data. The hardware cost is no more than 0.5% area on the RISC-V research core. The value to the open-source core community is that optimizations like DMP are moving from big-vendor proprietary designs to configurable cores, so security design must enter the RTL early rather than being patched in after tapeout.

Date: 2026-11-03　Source: arXiv:2610.37454 SecDMP (extended version), paper HTML version

riscv100.top Launches “Hardware Comparison” Page (11-03)

The leaderboard site’s What’s New shows “Hardware Comparison Now Available,” adding a cross-hardware comparison view. This is ecosystem and community promotion rather than new measurement results: the Upcoming section still holds three “Preparing” entries — AWS Graviton5 NeoverseV3 (SPEC2006/2017/2026), SpaceMiT K3 X100 vectorization and IME tests, and GCC 16 SPEC CPU tests — and how much data the comparison page can fill depends on when these three produce results.

Date: 2026-11-03　Source: riscv100.top homepage

II. Product and Ecosystem News

Europe Launches ERICI Industrial Computing Initiative to Turn RVA23 into an “Industrial Computer” (11-02)

An initiative called ERICI (European RISC-V Industrial Computing Initiative) appeared on Hacker News, launched by Yuri Zaporozhets of Germany and positioned as non-commercial industry collaboration. Its problem statement is direct: RVA23 silicon has arrived, but the “industrial computer” has not — board vendors wait for software, software waits for boards, customers wait for both, and this cycle must be broken by an open reference stack running on real hardware.

The reference stack is split by layer: firmware does initialization and POST, then hands off to a UEFI bootloader; gRouvr is loaded like a kernel, uses CPIO to package each partition’s kernel and initramfs, then allocates CPU, memory, devices, and their respective device trees to real-time partitions and Linux partitions, which run in parallel and isolated on the same SoC. The licensing is explicit: HFI BIOS under GPL-2.0 (based on U-Boot), mr-bml under GPL-3.0, and gRouvr and QSOE under Apache 2.0. The partitioning stack has been demonstrated on the SpacemiT K3 PicoITX board, with QSOE running as a gRouvr guest and logging in successfully.

It also honestly lists the gaps: available RVA23 machines (Firefly AIBOX-K3, Milk-V Jupiter2) are mostly “not specified” on wide-voltage input, −40 to 85°C, fieldbus and real-time I/O, DIN-rail mounting, industrial EMC and safety certification, and 10–15 year long-term supply, and the partitioning software stack has yet to reach products. This approach — “define the interfaces between layers first, then verify layer by layer that they boot together” — is worth comparing with domestic approaches to RISC-V industrial and automotive-grade systems.

Date: 2026-11-02　Source: ERICI official site, Hacker News discussion

III. Deep Dive into Domestic Teams

Nuclei Creates Two New T0 Chiplet SDK Repos, Tool Guide Follows Up with 2026.10 Release (11-02)

On the afternoon of November 2, Nuclei created two new repositories: nuclei-t0-sdk (described as Nuclei Ecosystem T0 Chiplet Baremetal/RTOS SDK) and nuclei-t0-linuxsdk (T0 Chiplet Linux SDK). Both are currently empty repos with zero commits. The empty repos themselves carry limited information, but the simultaneous launch of two SDKs—”baremetal/RTOS” and “Linux”—both named after T0 Chiplet, indicates that its next-stage product line will treat the chiplet-form T0 as an independent platform on which to build out the software stack, rather than folding it into the SDKs of existing cores.

On the same day, nuclei-tool-guide had three documentation commits, all pointing to the 2026.10 release: a libncrt documentation update with additions to the toolchain changelog, an xlmodel documentation update, and a changelog entry for the clang -pg _mcount issue. Quarterly toolchain releases with documentation keeping pace have been Nuclei’s fairly steady rhythm over the past two years.

Date: 2026-11-02　Source: nuclei-t0-sdk, nuclei-t0-linuxsdk, nuclei-tool-guide commits

SpacemiT docs-ros Adds ROS 2 Installation Instructions for Ubuntu 26.04 (11-02)

PR #224 added an Ubuntu 26.04 section to the K3 ROS 2 installation documentation: Bianbu signing keys and ROS 2 repository configuration, APT package pinning and index refresh commands, and prerequisites for network and time synchronization on Bianbu. Such documentation looks trivial but is in practice the first hurdle robot developers hit during deployment—a misconfigured repository or unsynchronized time will directly cause ROS 2 node discovery to fail.

Date: 2026-11-02　Source: docs-ros #224

Sophgo SG2044 EDK2 Disables PCIe ECRC Checking by Default (11-02)

Sophgo changed the PcieInitPei module of the SG2044 platform EDK2 to neither generate nor check ECRC by default, a 20-line change. ECRC is the PCIe transaction-layer end-to-end CRC and should in theory be enabled, but on real combinations of boards and riser cards, endpoints that do not implement it or implement it inconsistently can cause enumeration failures and link anomalies, so many platforms disable it by default. This change is an engineering trade-off that prioritizes compatibility, and it also indirectly indicates that the SG2044 system ecosystem is still in its adaptation phase.

Date: 2026-11-02　Source: edk2-platforms commit

DAMO XuanTie and ESWIN: Zero New Organization-Level Development Within the Window (11-03)

DAMO XuanTie (XUANTIE-RV, 73 repos) and ESWIN Computing (eswincomputing, 17 repos) had no pushes within the window, with their most recent commits stopping in late October and around 10-19, respectively. XuanTie’s public activity over the past two weeks has centered on products and roadmaps (6 billion units shipped, the E908A automotive-grade core, and C950A planning), with no corresponding changes in its open-source repos; this state of “active on the commercial side, silent on the open-source side” is normal for IP vendors and should not be over-interpreted.

Date: 2026-11-03　Source: XUANTIE-RV, eswincomputing

IV. Embodied Intelligence and Robotics Special Chapter

SpacemiT’s three repos merged on the same day: G1 hardware deployment and ONNX motion modes go live (11-02)

At 14:30 on November 2, three repos under spacemit-robotics completed their merges in the same minute, all authored by beililcj—clearly a coordinated set of changes. Among them, humanoid_unitree_g1 #13 is the heaviest: 54 files, +6087/−141. On the config side, g1_hardware.yaml (467 lines) was added and g1.yaml was expanded to 505 lines of changes; the docs gained four new pieces covering hardware deployment, gamepad, phone teleoperation, and voice prompts; the scripts side added real-time configuration, systemd service installation, calibration records, and a set of launch scripts (sim-to-real, driver, HMI, TUI); and tests cover startup retries, driver lock conflicts, gamepad binding, waist damping, and the pretrained entry point.

Functionally, the most notable item is that ONNX policies are organized into “motion modes” that can be switched online: the default LocoMode walking, an explicit dance trigger, and SONIC planning with the calm reference pose are all wired in through the same mode control, with voice prompts and phone-side control aligned accordingly. This means G1 has gone from “can run one policy” to “can switch between multiple policies and play motions by mode”—a necessary step toward productization.

Date: 2026-11-02　Source: humanoid_unitree_g1 #13

humanoid_common supports online policy switching and asynchronous SONIC planning (11-02)

humanoid_common #26 is the common layer for the above set of changes: 38 files, +2269/−71. The core is wiring together the behavior state machine (two states, HOME and RL), the policy adapters (history-actor, joint trajectory, stance motion, SONIC planner), and state reporting from the transport executor, so that “switching policies online” becomes a normal state-machine transition rather than a process restart.

Two design trade-offs are worth noting: first, “mode selection” is separated from “motion playback” to avoid triggering a motion while selecting a mode; second, observations for timed motions start from frame 0, no longer dropping the initial frame. There are also several fixes to gamepad configuration, the web client, and power-loss handling, including allowing manual power-off when state is stale—exactly the kind of boundary condition that most often breaks when moving from the lab to the field.

Date: 2026-11-02　Source: humanoid_common #26

control_whole_body uses triangle tables for coupling mapping, adds startup feedback recovery (11-02)

control_whole_body #9 adds a triangle table module (triangle_table.cpp/h, 185 lines) for coupling mapping over the calibration grid: the triangle containment tolerance is scaled by cell area to ensure interpolation does not jump on an ordered calibration grid. It also adds three fixes—passive damping hold, waiting for feedback at startup, and ordered interpolation—plus three new test groups: core, table configuration, and table mapping.

Organizing calibration data as “table + triangulation” rather than a simple lookup is meant to preserve continuous interpolation in joints with strong nonlinear coupling; combined with startup feedback recovery, it addresses the safety issue of commands and measured positions disagreeing at power-on. This layer is inconspicuous, but it determines whether the whole machine can stand stably under non-ideal calibration.

Date: 2026-11-02　Source: control_whole_body #9

V. Summary and Trend Observations

Today’s information clusters in three places, pointing at different layers.

First, business cadence is overriding roadmaps. Andes slowing its high-end Cuzco core and shifting resources toward its AI business, which already accounts for half of revenue, is a rare “deliberate slowdown” sample in this round of the RISC-V industry. It reminds teams building high-end cores: when ecosystem and customer budgets aren’t there, good performance numbers don’t convert into orders—the compounding in the IP business comes from reusability, not first-mover launches.

Second, progress on open-source cores still comes in a “small and dense” form. XiangShan landed four patches in a day (CSRR out-of-order execution, TAGE index dimensions, BPU timing, XSCache pointers), CVW three (DTLB reload tests, CLINT debt reduction, dual-simulator functional coverage), and NEMU and difftest each fixed one state-consistency issue related to matrix extensions. No single patch is large, but the direction is consistent: making state management solid along the two new paths of out-of-order execution and matrix extensions.

Third, the robotics stack is filling in the “deployment” segment. SpacemiT’s three repos merged on the same day, and the focus is not new algorithms but hardware deployment, online policy switching, calibration table mapping, and startup recovery—the necessary pieces for turning lab policies into deliverable products. Seen alongside ERICI’s efforts in Europe to turn RVA23 into an industrial computer, RISC-V’s next phase of growth looks less like “can it run” and more like “can it run stably on site over the long term.”

On the leaderboard side, this issue contains only supplementary entries and site feature updates, and should not be read as a performance jump; of 391 member company website inspections, 93 had homepage content changes, all routine marketing and news-slot updates with no substantive product, funding, or architecture developments.

Appendix: Complete Source List

Source Verification Table

Source Verification Result
Google News (27 routine queries + 12 supplementary queries, via proxy) 3 substantive new items in the window: Andes Cuzco (EE Times), ERICI initiative (HN cross-link), SecDMP (KU Leuven); the XuanTie 6-billion-unit figure is second-hand recirculation of old news from the 10-19 summit, already covered on 10-20, not repeated
Hacker News 1 valid item: ERICI European RISC-V Industrial Computing Initiative
Phoronix, CNX Software, LinuxGizmos, LWN LinuxGizmos’ ESP32-P4 compute module is a follow-up repost of a product reported in June, with no new developments in the window, not included; no RISC-V-specific hits from the other sources
arXiv 1 item: SecDMP (NDSS 2027, first open-source DMP implementation on a RISC-V core)
riscv.org official blog No new posts
openRuyi official news page Latest is still the 2026.09 edition (9-30); the October edition has not been released
openRuyi main repo 7 commits: clang-wrap 20261102, mtools 4.0.50 security fix, six Go ecosystem specs
riscv100.top inspection Notable: SPEC CPU2026 backfilled with two 07-30 records (cross-architecture and RISC-V channels), What’s New adds a hardware comparison page, all three Upcoming items still Preparing, no committee changes
RISC-V member company website inspection 391 companies inspected (68 failed to fetch), 93 homepages changed, all marketing and news-slot updates, no substantive product, funding, or architecture developments
Key GitHub repositories XiangShan 4, difftest 1, NEMU 2, XSCache 0 (submodule pointer updated from the XiangShan side), CVW 3, cvfpu 1, CVA6 0, openRuyi 7, SpacemiT 4, spacemit-robotics 3, Nuclei 3, Sophgo 4
DAMO XuanTie, ESWIN Zero organization-level pushes in the window
Espressif, Sipeed, revyos, Radxa Linkr esp-idf 7 (on the RISC-V side, PMP/PMA header relocation for rvsleep and a C5 HTTP service fix); MaixPy 1 documentation fix; revyos only branch and tag pushes; Radxa Linkr no pushes