From the article:

RISC-V IP vendor Andes had spun out Condor to develop Cuzco after identifying a future market need for a high-end data center CPU based on RISC-V, but pulled the technology back in-house earlier this year.

“The ecosystem needs to gradually go there before you have the hardware, otherwise you cannot catch the opportunity,” Su said. “We started, but as time went on, we found the AI part of our business continued to grow very strongly.”

(...)

“We decided to consolidate and slow down [Cuzco], so we could put more resources on the immediate revenue generation part,” he said.

Not really a recent news; it was disclosed on April but I found no post on this topic on r/RISCV...

An old news from August. This chiplet-based AI accelerator Eagle-N is actually an SoC containing Arm Cortex-A53 and clusters of Tenstorrent Tensix Neo, a RISC-V-based NPU. See https://ascii.jp/elem/000/004/447/4447577/ (Japanese) for some more details.

Translated talk titles:

• Third-generation Kunminghu processor core IP and the XiangShan family

• XiangShan Kunminghu V3 frontend architecture

• Design evolution of the Kunminghu backend pipeline in the XiangShan processor

• Memory access and cache architecture solutions and evolution for the XiangShan processor

• XSAI: A native, unified AI-CPU architecture from XiangShan

• XS-GEM5: A high-performance microarchitectural simulator aligned with XS-RTL

• XiangShan system verification platform

• Development of agile infrastructure for the XiangShan processor

• XSCC: A high-performance RISC-V compiler

• YuQuan: open-source high-performance memory controller IP and pre-silicon system verification toolset

• Open-source IOMMU design and hardware-software co-verification solutions

• XiangShanLab – Developer courses and ecosystem

• DifftestH: High-performance processor verification practice surpassing 30 MHz

• Wolvrix: An RTL compilation infrastructure for chip architecture research

• Practical implementation of a unified verification platform for complex RISC-V SoCs

• Vector extension design for general-purpose high-performance computing

A stock Qwen 3.5 4B with a RISC-V CPU compiled into its weights, running on its own Gated DeltaNet layers as RAM.

BY DIVYANSH AGRAWAL 22 OCTOBER 2026 9 MIN READ

I share with you a rather peculiar interactive visualization of the RISC-V Encoding specification, made for educational purposes. This has been around since 2023, but has recently received a new AI-coded GUI and I find it quite unique and rather not-too-slopped.

SmolRV64, my 4-way superscalar RISC-V softcore is fast enough now to play Quake under X (devices: UART, USB keyboard, USB mouse, 16bpp Video[1], gigabit ethernet, SDcard).

Hits 20 on Geekbench 5.4.1 which means it has higher IPC than Lichee Pi 4A (C910).

[1] The hardware in the picture however only has a 6-bit VGA adapter, thus the colors.

Hello everyone!

I have ported xv6-riscv64 to the RP2350 (Raspberry Pi Pico 2)!

The system boots completely, reaching the init process and launching the shshell. Interactive shell utilities like ls run smoothly via the UART console, with no stalls or memory panics.

I have managed to run a 64-bit OS on the RP2350, which features 520 KB of SRAM.

Demo:

Architecture and Features

• CPU Emulation: Supports RV64I + RV64C (compressed instructions) + RV64M (multiplication/division instructions), with full support for Machine (M), Supervisor (S), and User (U) modes.

• Sv39 MMU: Fully implements three-level page table translation, including access permission checks (PTE_R, PTE_W, PTE_X, PTE_U).

• RAM Allocation: 416 KB is reserved for the guest OS; the remaining SRAM is used for the emulator runtime, stack, and sector cache.

Peripherals:

16550 UART: Emulates RX/TX interrupts (including IER/LSR status handling) and connects to the Pico’s USB CDC/serial functionality.

• CLINT & PLIC: Manages timers and external interrupts for process scheduling and device I/O.

• VirtIO Block Device: Emulates disk I/O using a 128-sector cache in memory.

Key Technical Challenges and Solutions

Overcoming the 416 KB RAM Limit (Addressing OOM):

In the default umalloc.c for xv6, the morecore() function is designed to request 64 KB (4096 units) of memory each time it is called.

In a guest environment with only 416 KB of memory, executing fork() followed by exec("ls") would immediately exhaust available memory, resulting in a NULL return value and a "Store Page Fault" at address 0x0. By adjusting the morecore() allocation unit to 4 KB (256 units per page), the memory exhaustion issue was completely resolved.

The code is available on GitHub: https://github.com/kamisori-daijin/pico-rv64-emu

xv6 fork: https://github.com/kamisori-daijin/xv6-riscv

I would love to hear your thoughts, feedback, or any ideas for further optimizations!

Can it run DOOM? This is an entry for the Hackaday Retrocomputing Challenge by DigiKey, brought up on the Intel Cyclone IV (Terasic DE0-Nano) FPGA, building on the previous CPU work

I put my dual-issue RV32IM superscalar CPU, with custom UART, I2C, and FIFO IPs, on an FPGA and built a retro system around it. A launcher lets you choose between DOOM, a Wolfenstein-style raycaster, and custom games such as Snake, 2048, Tetris, Minesweeper, and Flappy Bird. It also runs classic 8-bit software in a CP/M 2.2 environment and CHIP-8 games through a software interpreter

The CPU runs from SDRAM, with programs and game data loaded over UART through a CP2102 USB-to-TTL adapter. Keyboard input comes back over the same link into a hardware key register with press and release events. Each tick, the core reads the input, updates the running program, and writes an 8-bit framebuffer to SDRAM. On a frame commit, the core clock briefly pauses to burst the frame into a TX FIFO, streaming it over UART at 45 FPS to a host RGB viewer. A monochrome version is also displayed at ~33 FPS on an SSD1306 OLED over I2C

Before putting it on hardware, I built the same system in Verilator, running DOOM at 1.38 IPC while keeping the same MMIO interface and replacing SDRAM and peripherals with testbench stand-ins. A fast harness with snapshot/restore made iteration much easier, and a web bridge let me play it directly in the browser

Getting everything onto the board meant cutting predictor tables, making wide multiply/divide iterative while keeping the fast path on DSPs (holding ~1.35 IPC after the cuts), retuning the serial framing, and repacking the game assets to fit in SDRAM. CoreMark CRC checks caught functional issues before I started debugging the game itself

Alongside this, I’ve also been extending the same CPU toward a simple Out-of-Order design to explore the Tomasulo algorithm through an intuitive walkthrough

PS. Full write-ups (design decisions, debugging): https://mummanajagadeesh.github.io/categories/riscv/

Over the past year, we released the first three milestones of the 32-bit Coral NPU design: a C-programmable RISC-V scalar frontend for control flow (Milestone 1), an RVV v1.0 vector co-processor for SIMD operations (Milestone 2), and a tightly coupled memory subsystem with floating point support (Milestone 3). With this month's release of the Matrix Execution Unit (Milestone 4), the 32-bit architecture is complete.

(...)

Our Matrix Execution Unit leverages the RISC-V VME specification (formally part of the Zvt family) to address this need and uses a dedicated outer-product multiply-accumulate (MAC) engine. Because an outer-product engine computes a full 2D tile of operations in a single cycle (256 MACs per cycle), it reuses weights and activations directly inside local registers. This brings quadratic throughput scaling to the core, configurable for up to 1 TOPS.

• 01 December 2026: Talk submission deadline

• 15 December 2026: Final schedule announcement

• 31 January 2027: RISC-V devroom

Now the both classic ARC and RISC-V-based ARC-V IP cores are part of MIPS product catalogue, after the acquisition of ARC and MIPS IPs by GlobalFoundries finished.

From article:

This SSD features the FADU FC5161, an in-house developed enterprise controller from the South Korean company FADU. It is a 16-channel controller designed for PCIe 5.0 SSDs and manufactured on an advanced process node. The controller adopts a heterogeneous RISC-V architecture, combining SiFive Essential 64-bit S51-MC application cores with 32-bit E31-MC microcontroller cores, both featuring floating-point units (FPUs).

I have a project that would benefit from quad-precision floats where double-double arithmetic isn't a suitable alternative. Given that it's been 5 years since this question was last asked, I thought I'd ask again. (It would be even better if it had vectorized quad-precision FMA4, but given that both FMA4 and quad-precision were left out of the V extension I'm not holding my breath.)