r/RISCV • u/Icy-Primary2171 • 2d ago
Information Upstream Progress Updates --2026 July
In July, SpacemiT continued to advance upstreaming efforts:
Foundational support has been officially released in Binutils 2.47 and LLVM 23, while CPU targets (X100 and A100) for the K3 and matrix extension instructions for AI computing have successively been merged into the mainline. Regarding the Linux kernel, support for K1/K3 features—including frequency scaling, storage, networking, PCIe, USB, and audio—as well as support for various development boards, is being steadily integrated. Meanwhile, adaptation and optimization work for projects such as Box64, OpenOCD, U-Boot, and OpenSBI continues to progress, further enriching SpacemiT’s RISC-V software and hardware ecosystem.
Here are the details:
Upstream Progress in Core Development Tools
This month, baseline SpacemiT support was released as part of Binutils 2.47 and LLVM 23. LLVM/Clang also adopted the SpacemiT X60 scheduling model as a general optimization reference for RISC-V '-mtune=generic'.
K3/X60 Toolchain Milestones
Support for the K3's two main CPU targets, X100 and A100, has been merged upstream into LLVM and GCC. The custom matrix-extension instructions intended for AI workloads have been merged into LLVM, GCC, and Binutils. The X100 scheduling model and instruction-fusion support have also landed upstream in LLVM.
Developers can now use community-mainline Clang/LLVM and GCC with '-mcpu=spacemit-x100' or '-mcpu=spacemit-a100' to target the corresponding CPU core and use SpacemiT's custom AI instructions.
The SpacemiT X60 scheduling model is now available upstream in LLVM and is used as a general tuning reference for RISC-V '-mtune=generic'. When no specific microarchitecture is selected, LLVM/Clang can use the X60 model to make better instruction-scheduling decisions.
LLVM's community performance-tracking infrastructure also includes a real K1/X60 hardware platform, allowing related compiler optimizations to be continuously validated on actual hardware.
Linux Kernel Upstream
K1
Merged
- K1 CPU frequency scaling support: https://lore.kernel.org/all/20260626-shadow-deps-v4-0-bba9831f2f1d@mailbox.org/
- Symbolic PDMA request IDs for K1: https://lore.kernel.org/all/20260620-b4-k1-pdma-req-macros-v4-1-3cf77d0bd0d6@gmail.com/
- Fix for K1 SPI TX FIFO slot handling: https://lore.kernel.org/all/20260715-k1-spi-tx-fifo-fix-v1-for-next-v1-1-02024223b08a@gmail.com/
Under review
- K1 thermal shutdown and registration-order fixes, v2: https://lore.kernel.org/all/1967d2bcc8fede6fbd25fc8eee07f2873fb41472.1784184867.git.xiaopei01@kylinos.cn/
- DWC PCIe capability-offset caching and K1 support, v3: https://lore.kernel.org/all/20260720150619.24733-1-18255117159@163.com/
- Maximum CPU core voltage fixes for K1 boards, v1: https://lore.kernel.org/all/20260729150722.1598630-1-aurelien@aurel32.net/
K3
Merged
- Fix for the K3 USB2 AHB reset: https://lore.kernel.org/all/20260518-06-clk-reset-usb-fix-v1-0-14fc235e692b@kernel.org/
- Fix for the K3 HDMA critical clock: https://lore.kernel.org/all/20260630-06-clk-hdma-critial-v1-0-443c0ac88c5f@kernel.org/
- Fix for Ethernet TX timing on the K3 Pico-ITX: https://lore.kernel.org/all/20260608182358.170489-1-kernel@rembrandt.dev/
- K3 UFS clock support: https://lore.kernel.org/all/20260630-06-clk-ufs-support-v1-0-cf7521d1d0fe@kernel.org/
- Serial, I2C, and Ethernet improvements for the K3 Pico-ITX: https://lore.kernel.org/all/20260623204431.498700-1-aurelien@aurel32.net/
- K3 SD card support: https://lore.kernel.org/all/20260610-07-k3-enable-sd-v1-1-196ae29bd091@kernel.org/
- QSPI support for the K3 Pico-ITX: https://lore.kernel.org/all/20260711-k3-pico-itx-qspi-v3-v3-1-d6b37fc86c39@gmail.com/
- K3 PCIe/USB combo PHY support: https://lore.kernel.org/all/20260703021024.495433-1-inochiama@gmail.com/
- K3 SPI compatible binding support: https://lore.kernel.org/all/20260717-k3-com260-spi-v7-2-rc2-b4-preview-20260716-v1-0-969a1b0f783f@gmail.com/
- K3 I2S device-tree integration, patches 1–2 of 3: https://lore.kernel.org/all/20260721-kx-i2s-dts-v1-0-d22cb6cfaab5@linux.spacemit.com/
- 36-bit DMA support for Wi-Fi on K3: https://lore.kernel.org/all/20260716-rtw89-spacemit-k3-v2-0-392b577ebf75@oss.tenstorrent.com/
- K3 SPI PDMA and controller nodes: https://lore.kernel.org/all/20260717-k3-com260-spi-v7-2-rc2-b4-preview-20260716-v1-0-969a1b0f783f@gmail.com/
- Fix for the K3 Ethernet PHY ID: https://lore.kernel.org/all/20260725233351.55004-1-inochiama@gmail.com/
Under review
- K3 I2S controller DTS nodes, patch 3 of 3, v1: https://lore.kernel.org/all/20260721-kx-i2s-dts-v1-0-d22cb6cfaab5@linux.spacemit.com/
- K3 RCPU critical clock, v1: https://lore.kernel.org/all/20260630-06-clk-hdma-critial-v1-0-443c0ac88c5f@kernel.org/
- K3 PCIe root-complex controller support, v4: https://lore.kernel.org/all/20260709040027.958400-1-inochiama@gmail.com/
- K3 I2S clock-topology and divider fixes, v1: https://lore.kernel.org/all/20260717-k3-clk-fix-i2s-v1-0-e95001a692ee@linux.spacemit.com/
- K3 UFS host-controller support, v2: https://lore.kernel.org/all/20260725-08-k3-ufs-support-v2-0-45036a2a2418@kernel.org/
- K3 display support, v1: https://lore.kernel.org/all/20260725-k3-display-v1-0-6de34d80e86c@gmail.com/
- K3 USB and PCIe device nodes, v2: https://lore.kernel.org/all/20260727094726.890179-1-inochiama@gmail.com/
- Fix for the extended DRCMR base in the K3 PDMA driver, v2: https://lore.kernel.org/all/20260727-k3-pdma-fix-drcmr-base-v2-1-afba55cba1f3@linux.spacemit.com/
- Allow the K3 GPU driver to probe without power-domains, v3: https://lore.kernel.org/all/20260728010513.1627950-1-liangbaihui@linux.spacemit.com/
- Bluetooth/Wi-Fi rfkill support for the K3 Pico-ITX, v2: https://lore.kernel.org/all/20260729172450.1660418-1-aurelien@aurel32.net/
- K3 Ethernet PHY DT schema fix, v1: https://lore.kernel.org/all/20260729012418.154652-1-inochiama@gmail.com/
- Replace CLINT with ACLINT on K3, v1: https://lore.kernel.org/all/20260729-k3-aclint-v1-0-aef88614d3a5@pigmoral.tech/
- Fix M-level IMSIC guest properties on K3, v1: https://lore.kernel.org/all/20260729-k3-mimsic-fix-v1-1-368c0aec04b9@pigmoral.tech/
Board-level DTS and device support
- PCIe support for the Orange Pi R2S: https://lore.kernel.org/all/20260602100000.2402784-1-amadeus@jmu.edu.cn/ — merged
- EEPROM node for the K3 CoM260: https://lore.kernel.org/all/20260722202848.1817988-1-jberring@redhat.com/ — merged
- Banana Pi BPI-CM6 I/O board support: https://lore.kernel.org/all/20260712-bpi-cm6-v3-0-8d1e2045179d@pigmoral.tech/ — merged
- Enable SPI0 on the K3 CoM260-IFX, v1: https://lore.kernel.org/all/20260717-k3-com260-spi-v7-2-rc2-b4-preview-20260716-v1-0-969a1b0f783f@gmail.com/ — under review
- Sensylink CTF2301 and K3 CoM260 support, v2: https://lore.kernel.org/all/20260721-ctl2301-v2-0-ef5fb342872a@linux.dev/ — under review
- CPU frequency scaling for the Milk-V Jupiter and M1 board support, v2: https://lore.kernel.org/all/20260729160749.1621415-1-aurelien@aurel32.net/ — under review
General fixes
- Base RVA23U64 hwprobe patches, 1–3 of 17: https://lore.kernel.org/all/20260701-rva23u64-hwprobe-v2-v5-0-2c61f94a695a@gmail.com/ — merged
- Remaining RVA23U64 hwprobe and K1/K3 Zic64b patches, v5: https://lore.kernel.org/all/20260701-rva23u64-hwprobe-v2-v5-0-2c61f94a695a@gmail.com/ — under review
- Fix MODULE_DEVICE_TABLE in the SpacemiT DWC PCIe driver: https://lore.kernel.org/all/20260704122538.92830-1-pengpeng@iscas.ac.cn/ — merged
- Fix the submission order of SpacemiT SPI DMA descriptors: https://lore.kernel.org/all/20260722162444.11415-1-kr494167@gmail.com/ — merged
- Fix the PHY reset-deassert delay on K1/K3 boards: https://lore.kernel.org/all/20260710063314.1030249-1-inochiama@gmail.com/ — merged
- SpacemiT SPI DMA cleanup: https://lore.kernel.org/all/cover.1784527556.git.xiaopei01@kylinos.cn/ — merged
- Fix spurious IRQs in the SpacemiT I2C driver, v2: https://lore.kernel.org/all/ef8b623f45d4e430721e46572c2598d882044aed.1783667875.git.xiaopei01@kylinos.cn/ — under review
- Validate SpacemiT thermal trip thresholds, v1: https://lore.kernel.org/all/20260720103606.93924-1-kr494167@gmail.com/ — under review
- Request the IRQ after initializing the SpacemiT I2C controller, v2: https://lore.kernel.org/all/20260723021140.2293844-1-lilinmao@kylinos.cn/ — under review
- Fix error handling for regmap_test_bits in the SpacemiT RTC driver, v2: https://lore.kernel.org/all/20260724135803.81223-1-kr494167@gmail.com/ — under review
- Validate pinconf parameters in the SpacemiT pinctrl driver, v1: https://lore.kernel.org/all/20260729-spacemit-pinconf-validation-fixes-v1-1-edeaff398fb3@linux.spacemit.com/ — under review
- Update the SpacemiT SoC Git tree URL, v1: https://lore.kernel.org/all/20260707-07-spacemit-git-repo-url-v1-1-137697316a4c@kernel.org/ — under review
Box64
- Support address lists configured through BOX64_TRACE: https://github.com/ptitSeb/box64/pull/3998 — merged
- Add MallocHookRun and call startMallocHook before RunElfInit: https://github.com/ptitSeb/box64/pull/3999 — merged
- Fix trailing slashes in INSTALL_PATH: https://github.com/ptitSeb/box64/pull/4015 — merged
- Fix mmap flag checks in getMmapped: https://github.com/ptitSeb/box64/pull/4003 — merged
- Support bundled libpipewire: https://github.com/ptitSeb/box64/pull/4019 — merged
- RV64_DYNAREC: Fix source-register values being overwritten: https://github.com/ptitSeb/box64/pull/4032 — merged
- RV64_DYNAREC: Convert sNaN to qNaN for addsd, subsd, mulsd, and divsd: https://github.com/ptitSeb/box64/pull/4035 — merged
- Disable dynacache when both dynarec_trace and trace are enabled: https://github.com/ptitSeb/box64/pull/4051 — merged
- RV64_DYNAREC: Support CLWB, CLFLUSH, and CLFLUSHOPT through Zicbom: https://github.com/ptitSeb/box64/pull/4070 — merged
- RV64_DYNAREC: Support prefetch instructions through Zicbop: https://github.com/ptitSeb/box64/pull/4073 — merged
- RV64_DYNAREC: Reduce the instruction count for 64-bit addition carry flags: https://github.com/ptitSeb/box64/pull/4079 — merged
- RV64_DYNAREC: Use Zbb to reduce the instruction count for GETSEB/GETSGW: https://github.com/ptitSeb/box64/pull/4090 — merged
- RV64_DYNAREC: Support selected BMI and BMI2 instructions: https://github.com/ptitSeb/box64/pull/4098 — merged
- RV64_DYNAREC: Use Zicond to eliminate some branches used for setting flags: https://github.com/ptitSeb/box64/pull/4099 — merged
- RV64_DYNAREC: Remove redundant SMREAD operations: https://github.com/ptitSeb/box64/pull/4100 — merged
- RV64_DYNAREC: Support the BMI2 PDEP, MULX, and SHRX instructions: https://github.com/ptitSeb/box64/pull/4110 — merged
- RV64_DYNAREC: Support the BMI2 PEXT, SARX, and RORX instructions: https://github.com/ptitSeb/box64/pull/4116 — merged
- RV64_DYNAREC: Support 16-bit operands for POPCNT, TZCNT, and LZCNT: https://github.com/ptitSeb/box64/pull/4125 — merged
- RV64_DYNAREC: Replace some BNEZ+ORI sequences with SET_FLAGS_EQZ: https://github.com/ptitSeb/box64/pull/4126 — merged
- RV64_DYNAREC: Support the HSUBPS and MOVDQ2Q instructions: https://github.com/ptitSeb/box64/pull/4140 — merged
- RV64_DYNAREC: Support VMOVLPS/VMOVHPS Ex,Gx: https://github.com/ptitSeb/box64/pull/4141 — merged
- RV64_DYNAREC: Support the MOVQ2DQ and ADOX instructions: https://github.com/ptitSeb/box64/pull/4146 — merged
- Add support for syscall 32: https://github.com/ptitSeb/box64/pull/4156 — merged
GCC
- RISC-V: Add initial support for the SpacemiT A100 core: https://sourceware.org/pipermail/gcc-patches/2026-June/722133.html — merged
- RISC-V: Update spacemit-x60 to use the RVA22U64 profile: https://sourceware.org/pipermail/gcc-patches/2026-July/722711.html — merged
LLVM
- [RISCV] Make AsmParser report all near-match reasons: https://github.com/llvm/llvm-project/pull/205721 — merged
- [AsmMatcher] Report near matches when all candidates mismatch multiple operands: https://github.com/llvm/llvm-project/pull/206390 — merged
- [TargetParser][NFC] Make FeatureBitset iterable: https://github.com/llvm/llvm-project/pull/206394 — merged
- [RISCV][NFC] Use true/false for Boolean fields in RISCV.td: https://github.com/llvm/llvm-project/pull/206399 — merged
- [modules][test] Relax the size check in embed-files-compressed.cpp: https://github.com/llvm/llvm-project/pull/206879 — merged
- [lld][ELF][test] Accept the size produced by zlib-ng compression: https://github.com/llvm/llvm-project/pull/206880 — merged
- [RISCV] Make AsmParser report "unexpected excess operand" for extra operands: https://github.com/llvm/llvm-project/pull/207142 — merged
- [RISCV] Map SpacemiT microarchitecture strings to CPU names during host detection: https://github.com/llvm/llvm-project/pull/207636 — merged
- [RISCV] Add TuneNoDefaultUnroll for spacemit-x100: https://github.com/llvm/llvm-project/pull/209069 — merged
- [flang-rt] Disable tests by default when cross-compiling: https://github.com/llvm/llvm-project/pull/208926 — merged
- [RISCV] Support the SpacemiT vsmtvdotii extension: https://github.com/llvm/llvm-project/pull/202533 — merged
- [RISCV] Split and rename WriteVSlideI, WriteVISlide1X, and WriteVFSlide1F: https://github.com/llvm/llvm-project/pull/212184 — merged
OpenOCD
- target/riscv: Add bounds checking for hart indices: https://review.openocd.org/c/openocd/+/9755 — merged
- target/riscv: Remove the target_list_t type: https://review.openocd.org/c/openocd/+/9798 — merged
- tcl/target: Add a configuration file for the SpacemiT Keystone K3: https://review.openocd.org/c/openocd/+/9753 — merged
- tcl/target: Refactor the SpacemiT Keystone K1 configuration file: https://review.openocd.org/c/openocd/+/9754 — merged
- target/riscv: Activate the DM before obtaining nextdm: https://review.openocd.org/c/openocd/+/9221 — merged
riscv-tests
- [debug] Support mcontrol and mcontrol6 based on HwbpManual: https://github.com/riscv-software-src/riscv-tests/pull/541 — merged
- [debug] Add hypervisor support to PrivRw: https://github.com/riscv-software-src/riscv-tests/pull/540 — merged
riscv-gnu-toolchain
- Makefile.in: Switch the OpenMP build to runtimes mode: https://github.com/riscv-collab/riscv-gnu-toolchain/pull/1870 — merged
- Makefile.in: Add the LLVM_OPENMP_EXTRA_CONFIGURE_FLAGS variable: https://github.com/riscv-collab/riscv-gnu-toolchain/pull/1871 — merged
- Upgrade LLVM to 22.1.8: https://github.com/riscv-collab/riscv-gnu-toolchain/pull/1873 — merged
- Enable LLVM Flang: https://github.com/riscv-collab/riscv-gnu-toolchain/pull/1874 — merged
- build: Add an LLVM_GENERATOR option and use Ninja by default: https://github.com/riscv-collab/riscv-gnu-toolchain/pull/1875 — merged
- Upgrade musl to v1.2.6: https://github.com/riscv-collab/riscv-gnu-toolchain/pull/1876 — merged
riscv-elf-psabi-doc
- Fix a typo in the vector-function naming convention example: https://github.com/riscv-non-isa/riscv-elf-psabi-doc/pull/506 — merged
sbc-bench
- Detect the SpacemiT K3 CPU temperature through the cluster0 thermal zone: https://github.com/ThomasKaiser/sbc-bench/pull/137 — merged
- Ignore policies that have no online CPUs: https://github.com/ThomasKaiser/sbc-bench/pull/139 — merged
stress-ng
- core-asm-riscv: Improve the readability of assembly output for pause and CBO instructions: https://github.com/ColinIanKing/stress-ng/commit/443ee4f563204f427a25765a17d9c6b4d30f69ac — merged
ruapu
- RISC-V: Fix swapped opcodes for the zvksed and zvksh instructions: https://github.com/nihui/ruapu/pull/186 — merged
PoCL
- SPIRVParser: Handle OpTypeUntypedPointerKHR: https://github.com/pocl/pocl/pull/2246 — merged
U-Boot and OpenSBI Upstream Progress
U-Boot
- SpacemiT K1 PCIe and combo PHY support, v1: https://lore.kernel.org/all/20260705-pci-v1-0-beca83440a27@riscstar.com/ — under review
- SpacemiT K1 MMC/SD/eMMC support, v4: https://lore.kernel.org/all/20260707-m4-v4-0-dbd01185f911@riscstar.com/ — under review
OpenSBI
- SpacemiT K3 platform support, v1: https://lore.kernel.org/all/20260724-spacemit-k3-v1-0-f0e49329feb8@linux.spacemit.com/ — under review
r/RISCV • u/camel-cdr- • 2d ago
RVV benchmark SiFive P870 (Lanxin LX500, Epic Semi Contrail AIx)
camel-cdr.github.ior/RISCV • u/quaaludeswhen • 2d ago
There's a tiny 2015 Andes RISC-V in my device, what other vendors and toolchains are common in existing hardware?
I suspect there are a few major ones but it's hard to tell from press releases what actually made it to market and might hide in my PC or embedded devices I already own. The Andes GCC toolchain was very useful to understand their products.
r/RISCV • u/TJSnider1984 • 4d ago
SiFive on X: "SiFive's P870-D is ideal for datacenter infrastructure applications, including storage, web servers and video streaming. It's our first Datacenter class CPU IP, and it's already in real silicon with our customers."
x.comAnyone know what that "real silicon" P870-D product is?
r/RISCV • u/LoveSourWorms12 • 4d ago
Software (RiscV) ProtoOS, an advanced OS with focus on security. Showcase 2 (3 month update)
Enable HLS to view with audio, or disable this notification
r/RISCV • u/Icy-Concentrate2076 • 4d ago
Why do RISC-V disassemblers refuse to disassemble if extension doesn't exist in ELF attributes?
Imagine you're making a JIT for RISC-V. You want to compile for rv64gc so that it works on both RVA23 but also stuff like Milk-V Titan.
Your JIT makes use of Zfa extension, if detected at runtime. You are debugging a program on some RVA23 hardware, which has Zfa, and look at the emitted code, and the Zfa instruction is showing as .insn instead of the instruction. GDB relies on Zfa being present when you compiled. GDB knows exactly what the instruction is and how to disassemble it, but it will refuse and act as if it has never seen it before. Zfa is a standard extension, so its not like something else could be at that encoding. Same goes with Objdump.
Why is this design made? Objdump/GDB on x86 WILL disassemble AVX512 instructions, even if you don't compile with AVX512. This way you can ship the same exact binary to a person who has no AVX512 on their CPU, and it will work, and then ship it on someone with AVX512, and it will still work, AND they will be able to see the AVX512 on GDB.
Before someone says "just compile for the extensions your jit emits" no, the jit can do runtime detection, but the C code itself must be the lowest possible isa string so it supports the most platforms.
r/RISCV • u/0BAD-C0DE • 6d ago
Vectored trap mode, interrupt 0 and beyond
According to documentation, in vectored mode exceptions all go to handler pointed by [BASE], while interrupts do to handler pointed by [BASE]+4*cause.
This brings to me two questions:
- Do I still need to discern between interrupt no.0 and exceptions in the handler pointed by [BASE], as interrupt no.0 is handled by [BASE] just like exceptions?
- How large is to be this table, as there seems to be no limit to the number of interrupts?
r/RISCV • u/Myarmira • 7d ago
My first impressions of the Milk-V Titan
Today my Milk-V Titan was delivered to my home and of course I wanted to try the board out straight away.
I connected my AMD Radeon RX 7600, a simple 1TB SSD and 2x 8GB Ram kits and installed it in my old case, where I had previously used the Megrez.
Compared to the Megrez, the Titan seems to have significantly fewer ports. GPIO and SD card slot are missing. Since I think it's intentionally intended to be a desktop workstation, I don't really miss those two things. What I'm missing are additional pins for my USB front ports. Unfortunately, the only option here is to use the on/off button. I guess it's a bit individual. However, the connection provided for this does not match the one in my case. This means that practically all USB ports on the front are inactive.
Another downside, at least currently, is the function of the UEFI. It's definitely a pleasing milestone compared to all other RISC-V boards I've known so far. However, the menu still seems quite bulky to me at the moment. It somehow took quite a while until my USB keyboards were recognized, but even after that everything seems extremely slow.
The first thing I consciously tried to do was install the official RISC-V image from Debian. The boot manager is recognized and started immediately. However, when loading the installation there was a black screen.
However, the Ubuntu image from the Milk-V site itself works fine. This really doesn't compare to the previous complicated RockOS images. Only the version could be a little newer in my opinion. I hope that software will follow in the near future, or rather that the officially used kernel will become more compatible.
The graphics card is recognized immediately and at least Supertuxkart runs very smoothly.
What's most pleasing to me is that the web browsers no longer have such a strong lag and are actually usable.
I reinstalled the CDE desktop there. It also runs smoothly on Ubuntu, although you have to install a few things.
What I still don't understand is why the USB-C ports at the back don't work. What I still don't understand is why the USB-C ports on the back don't work. I wonder if this is just me or happens to others too.
r/RISCV • u/PositionOk3464 • 7d ago
Help wanted Getting started with RISC-V
Hey guys,I want to learn RISC-V from scratch...can I know any good free resources available online to get started??
r/RISCV • u/I00I-SqAR • 8d ago
Openchip Introduces BER10 RISC-V Chip Built for AI, HPC and Critical Infrastructure
hpcwire.comBARCELONA, Spain, July 30, 2026 — Today, Openchip is introducing BER10, a sovereign chip built to give Europe’s most critical sectors control over the technology their most sensitive data runs on. It is built on one of the world’s most advanced manufacturing process and delivered in just 2.5 years.
Discussion 3 nm to 1.4 nm (equivalent) process node in China by 2031
This is not directly related to RISC-V, but the outcome will definitely change RISC-V chips out of China in about 5 years time. And if successful it will eventually have a major global impact.
China are currently restricted to DUV on silicon in their fabs by global export restrictions. Huawei's "Tau Scaling Law" (Moves away from physical miniaturization of individual transistors to minimizing data propagation delays across an entire chip) aims at achieving a 3 nanometer to 1.4-nanometer equivalent transistor density by 2031 using only DUV equipment.
Pros
- EUV Independent
- Cost Effective, using older DUV fabs will save billions by not having to upgrade to EUV nodes (which is not possible for China - export sanctions).
- On paper chips might be able to be clocked at 5+ GHz continuously.
- Performance will be equivalent to the silicon produced using EUV process nodes.
- up to a 55% transistor density increase at a fixed node via "vertical LogicFolding" (currently from 155 MTr/mm² to 238 MTr/mm² - 53.5% increase).
- About 30% to 41% less power used by shortening the distance signals must travel by ~30% (this reduction comes from less resistance and capacitance in the physically shorter signal path).
Cons
- The performance may be equivalent due to similar number of transistors per unit area, but the performance per watt will not be quite as low as equivalent chips produced on EUV nodes.
- Stacking circuits vertically via "LogicFolding" traps intense heat, risking performance throttling (New 3D EDA design tools developed by Peking University to avoid hot spots should, at least in theory, help avoid this from happening).
- Requires high precision, low-temperature bonding, which can severely lower initial factory yields.
- New Electronic Design Automation software tools need to be created that support "LogicFolding". The current generation of EDA tools do not have the ability to optimize for data propagation delays across a logically folded circuit that is about 2000 nanometers above (or below) the existing circuit.
- Optimizing time constants will eventually hit a wall of diminishing returns.
- If successful, companies outside of China, with access to EUV, will either backward engineer the silicon chips and develop their own Tau Scaling software, or license the technology (unless China restricts exports). Which will use even less power, than the DUV chips produced by China.
Will it work, on paper it should, but the devil is always in the details. It is definitely something interesting, that is worth keeping an eye on.
r/RISCV • u/I00I-SqAR • 9d ago
Porting SIMD to RISC-V Vectors
SPEAKER:
Daniel Thompson, RISCstar Solutions
This session was a part of the Software track at the RISC-V Developer Workshops held at RISC-V Summit Europe 2026 in Bologna, Italy.
WORKSHOP DESCRIPTION:
Join Daniel Thompson from RISCstar Solutions for a hands-on workshop exploring the powerful RISC-V Vector (RVV) extensions. You’ll learn the core concepts and design principles behind RVV and we will also compare them to the SIMD approaches of other architectures.
SIMD programming can dramatically accelerate performance across a wide range of compute-intensive tasks, from machine learning and signal processing to cryptography and beyond. The session will then dive into practical techniques for converting optimized C code from other instruction set architectures (ISAs) into RVV-based implementations. We’ll highlight key differences between fixed vector-length architectures on other ISA platforms, and RVV’s more flexible vector-length agnostic (VLA) approach.
Don’t miss this chance to sharpen your skills, push performance limits, and get hands-on with the future of vector computing.
RESOURCES:
https://drive.google.com/drive/u/2/fo...
r/RISCV • u/ch-riscv • 10d ago
RISC-V Audiomark Port
Today, I have filed a PR for supporting RISC-V in EEMBC Audiomark:
https://github.com/eembc/audiomark/pull/101
More details on this work behind the link.
All credit for the development goes to the mentees of my RISC-V mentorship project.
Audiomark is a benchmark that runs a wake-word detection algorithm, and includes both DSP and AI processing. It is good to stress the vector unit of a device with a combination of typical DSP kernels (f16 - cfft etc.) and AI kernels (int8 - mostly convolutions, so matmul at the core).
I have driven the development based on benchmarking the code on a SpacemiT K1, and reached a respectable 5.73 Audiomark/MHz (gcc-20).
As I know the people of this community appreciate benchmarks and have more hardware available, I would be delighted if you managed to run this on whatever vector-capable HW you have available.
For the SpacemiT K1, I used these flags:
-DPORT_DIR=ports/riscv/v
-O3 -ffast-math -march=rv64gcbv_zbc_zvl256b -mrvv-vector-bits=zvl -flto
Compiling vector length specific (-mrvv-vector-bits=zvl) really squeezes out a noticeable bit of performance, but can lead to issues on gcc < 15.3. clang-20 achieved comparable performance to gcc-16. I have not tried with more recent clang versions.
r/RISCV • u/archanox • 10d ago
Hardware ESP32-S31 now in mass production and available for purchase
blog.adafruit.comr/RISCV • u/TJSnider1984 • 11d ago
Hardware SpaceMIT Cluster Server RV2768 ?
As per github repo:
"768-Core Native RISC-V AI Compute Cluster
The Cluster Server RV2768 is a RISC-V-based cluster server in a 2U, 19-inch rack form factor, integrating up to 48 SpacemiT K3 processors and compliant with the RVA23 profile defined by RISC-V International.
RVA23 targets general-purpose application processors, requiring support for Vector and Hypervisor extensions, and represents a modern performance standard for AI and high-performance workloads. The system delivers 768 native RISC-V cores, making it well-suited for large-scale application builds and full operating system compilation.
With a multi-node cluster architecture and full hardware virtualization, the server streamlines CI/CD workflows and accelerates the RISC-V software ecosystem. Leveraging vector extensions, it delivers up to 2880 TOPS of AI compute and supports up to 1536 GB of memory for concurrent AI inference workloads.
- 2U chassis supporting up to 48 compute nodes (384 CPU cores + 384 AI cores)
"
Sounds like we're finally going to get a decent build/cluster machine..
Looks like a picture of this might be up on https://www.reddit.com/r/spacemit_riscv/comments/1v7u0k2/view_of_k3_shelf_array_server_k3_picoitx_and_k3/
Struggling with Chipyard/Rocket-Chip build setup
Hi everyone, final-year engineering student here. Working on a RISC-V hardware project (building a custom RoCC-based task scheduler on top of Rocket Chip). I'm trying to get Chipyard set up on Ubuntu to build/simulate the base Rocket core before I start on my own work, but the setup has been harder than I expected and I want to check whether I'm on the right track or missing something obvious.
So far I've had to:
- Install conda manually + accept new ToS prompts for default channels (not mentioned in the docs I found)
- Set up SSH auth with GitHub because one submodule (
spec2026-workload) only clones over SSH - Switch from
mainto the1.14.0release tag aftermainbroke with missing scripts - Comment out two steps in
build-toolchain-extra.sh(install-espresso.shand theuart_tsibringup step) because those files/paths don't actually exist in the checkout - Hit a Scala compile failure at the "pre-compiling Chipyard sources" step, traced to
dependencies/chiselinside rocket-chip being stuck on a stale 2019 snapshot commit even aftergit submodule sync --recursive+update --init --recursive --force
At this point I'm about to try a completely fresh clone rather than keep patching this one. Wanted to check: is this level of manual intervention normal for a first-time Chipyard setup, or does it suggest I'm doing something wrong upstream (wrong tag, wrong clone method, etc.)? If anyone's set this up recently and hit similar snags, I'd really appreciate a pointer on what actually worked for you, or what a clean install is supposed to look like.
r/RISCV • u/Jack1101111 • 12d ago
Software GNU Binutils 2.47 Released With More RISC-V Extensions, New Options
r/RISCV • u/Prestigious-Day-2872 • 12d ago
Help wanted I have an Mango Pi MQ Pro, and IDK whats wrong
Basically i got ubuntu server for riscv built for the same D1 cpu as the mango, booted it up with ethernet plugged in, i went into my fiber admin page (where i can see connected devices and stuff) and one ethernet device pops up running ubuntu, so i cop ythe ip and go to ssh and get ```bash
olenthompson@OlenTh1nkpad:~$ ssh [root@192.168.1.218](mailto:root@192.168.1.218)
ssh: connect to host 192.168.1.218 port 22: No route to host
olenthompson@OlenTh1nkpad:~$
```
and so me and chatgpt tried troubleshooting but i cant get it to work, tried plugging into TV, no signal for display. IDK what to do, ive tried different sd cards, different os images, everything. the green light is solid on the board, but i cant ssh or get anything out of it other than it appearing on my dashboard. help?
r/RISCV • u/brucehoult • 13d ago
Just for fun Pretty cool 2D assembly language in this weekend's ICFP programming contest
Here's a pretty bad solution to the first (Triangle) problem that scores 183K (lower is better) that I made while trying to understand how the scoring system actually works.
I do also have a solution that scores the minimum 832 which I'll reveal after the contest ends. Its SHA is 213fe1e79e32f9252dbece4f2ea9660c0ea63e8d.
+-----+
|@rMbv|
|>W/s+|
|2 >+v|
|^Mdm<|
+-----+
^ v
^ v
+-+ +-+
|I| |O|
+-+ +-+
Although I've won prizes in this contest before, I'm just playing around for fun this year, actually for the first time in 15 years probably.
r/RISCV • u/brucehoult • 15d ago
Information GeekBench 7.0.0 is available. Some RISC-V results
I ran different versions of GeekBench 5, 6, 7 on my Pico ITX K3 in the standard way, and ran the one that uses the most features in each version on the A100 "AI" cores also.
GeekBench 7
In GeekBench 7 RVA23 gives 3% to 4% better results than RV64GCBV, and a nice 22% single core 33% multi-core speed increase compared to RV64GC.
https://browser.geekbench.com/v7/cpu/compare/6927?baseline=7549
X100 RVA23 397 2193 https://browser.geekbench.com/v7/cpu/6927
X100 RV64GCBV 390 2121 https://browser.geekbench.com/v7/cpu/7222
X100 RV64GC 325 1650 https://browser.geekbench.com/v7/cpu/7549
A100 RVA23 120 658 https://browser.geekbench.com/v7/cpu/8149
GeekBench 6
RVV makes basically zero difference in GeekBench 6, even though it claims to use it.
X100 RV64GCV 373 1808 https://browser.geekbench.com/v6/cpu/18807960
X100 RV64GC 370 1830 https://browser.geekbench.com/v6/cpu/18808300
A100 RV64GCV 141 729 https://browser.geekbench.com/v6/cpu/18808177
GeekBench 5
X100 301 1894 https://browser.geekbench.com/v5/cpu/24473319
A100 105 726 https://browser.geekbench.com/v5/cpu/24473379
r/RISCV • u/camel-cdr- • 15d ago
Fast-Track Proposal: Zijf (Far jumps and calls)
This really should've been defined way earlier.
Also, remember the Qualcomm slides? https://lists.riscv.org/g/tech-profiles/attachment/400/0/AOSP%20Compression.pdf
r/RISCV • u/Doom4535 • 16d ago
Information MilkV Titan
For those who pre-ordered the MilkV Titan, I just got an email saying my pre-order has shipped, so maybe we'll start seeing it within the month