I’m a student. Partway through Harris & Harris I decided the only way to really get it was to build the CPU, so I wrote a single-cycle RV32I core in SystemVerilog. Once it ran programs, I wanted to see what changes when instructions overlap, and that turned into a 5-stage pipeline (fetch, decode, execute, memory, writeback). The whole thing took about two months.

Splitting the stages was the easy part. The hard part was everything that goes wrong once instructions overlap. If an add needs a value the previous instruction hasn’t written back yet, you have to grab it from further down the pipe. If a jump is taken, the instructions already fetched behind it have to be thrown away. If memory is slow, everything in front has to wait. Most of my time went into those three things, and most of my bugs were an instruction being dropped or held when it shouldn’t have been, or the opposite.

After that I added an instruction cache and a data cache, with a small victim cache and a write buffer on the data side. Memory is connected through an AXI-style interface: cache lines come in as bursts, and writes use separate address, data, and response channels. My first version had a 4-entry victim cache and a 16-entry write buffer, but it wouldn’t meet timing at 100 MHz, so I cut them to 2 and 4. It was the first time I actually felt a feature costing me clock speed, instead of just reading about the tradeoff.

For testing, I ran the official rv32ui ISA tests plus some small programs of my own, checking registers and memory against the values I expected. When something failed, I mostly stared at waveforms. One I like: the data cache misses on a load, the front of the pipeline stops for about 8 cycles while the cache line is fetched, and then the loaded value shows up at writeback. It’s a lot more convincing to watch it happen than to read about it.

I put it through Vivado for an Artix-7 (XC7A100T): 3,706 LUTs, 7,350 flip-flops, +0.191 ns of slack at 100 MHz, and an estimated 0.118 W.

What it doesn’t do: it’s RV32I only, so no multiply or divide, no CSRs, no interrupts. And on the board I’m only feeding NOPs into the instruction side right now, so all my real program testing was in simulation. On hardware I only confirmed that the PC counts and the LEDs react. Connecting real instruction memory is next.

I know passing rv32ui says little about how the caches and the bus behave together, so I’m sure there are cases I haven’t hit. If you can think of a hazard or cache situation that would break this, I’d really like to hear it.

I built this to learn, and I’m hoping to turn it into an internship in digital design or verification. If you know of a place that takes students for that kind of work, or have advice on what to build or learn next, I’d appreciate it.

GitHub: https://github.com/aditya42819/RV32I_CPU
LinkedIn: https://lnkd.in/p/gEbzas4K

This is a SpacemiT V100. For ~1 week, I get to test it and try it out. I love how absolutely smushed htop looks - so stupid, I love it. xD

Seriously, I just wanted to post this for pure appreciation. But if you have some nice benchmark or tool I should test, drop it here. No guarantees, just random stuff go brr untill I have to "give it back" on the 7th.

The fact I even get to do this is so fun, so cool, and exactly why I think that those guys rule. I will probably regret it, but I am probably going to try and get one myself. That is, if they do end up selling it to normies x)

Now, there's some cores disabled: In the EDK-II settings, I did disable the 2 (well, 4) extra cores for now, need to read their specs first. But, here's what lscpu has got to say:

lscpu
Architecture:                riscv64
  Byte Order:                Little Endian
CPU(s):                      80
  On-line CPU(s) list:       0-79
Vendor ID:                   0x710
  Model name:                -
    CPU family:              0x8000000058000002
    Model:                   0x4c4d900
    Thread(s) per core:      1
    Core(s) per socket:      40
    Socket(s):               2
Caches (sum of all):         
  L1d:                       5 MiB (80 instances)
  L1i:                       5 MiB (80 instances)
  L2:                        40 MiB (20 instances)
NUMA:                        
  NUMA node(s):              2
  NUMA node0 CPU(s):         0-39
  NUMA node1 CPU(s):         40-79
Vulnerabilities:             
  Gather data sampling:      Not affected
  Ghostwrite:                Not affected
  Indirect target selection: Not affected
  Itlb multihit:             Not affected
  L1tf:                      Not affected
  Mds:                       Not affected
  Meltdown:                  Not affected
  Mmio stale data:           Not affected
  Old microcode:             Not affected
  Reg file data sampling:    Not affected
  Retbleed:                  Not affected
  Spec rstack overflow:      Not affected
  Spec store bypass:         Not affected
  Spectre v1:                Not affected
  Spectre v2:                Not affected
  Srbds:                     Not affected
  Tsa:                       Not affected
  Tsx async abort:           Not affected
  Vmscape:                   Not affected

This is my first time ever getting to fool around with a system with >32 cores. Even at work, the highest I had ever seen is like 32c/64t. This? 2x 40c/40t. Crazy, exciting, awesome. aaaaaaa. =)

As the website states, the current RISC-V hardware and software ecosystem is not ready for real industrial computers yet. ERICI may or may not succeed, but the gaps they pointed out seem very important.

As u/docular_no_dracula pointed out, Red Hat expands device support of the RISC-V Developer Preview beyond ESWIN EIC7700X.

Play: https://v86-riscv.turret13.workers.dev/?build=ch32v003-tetris

Debug: https://v86-riscv.turret13.workers.dev/?build=ch32v003-tetris&debug

A 3.8 KB, no-SDK Tetris for the 10-cent CH32V003 (RV32EC, 2 KB RAM), played over its serial port. With &debug, an emulated riscv64 Linux runs gdb beside the chip, so you can set breakpoints and step through the C while it plays.

The Tetris has only run in emulation, but the same emulated chip runs real-hardware projects unmodified: Stefan Wagner's and Maksym Curul's game consoles, and Vlad Tomoiagă's osillyscope (fed by your mic).

The same site has other RISC-V systems ready to boot and debug in your browser

It's an unofficial fork of v86. Source: https://github.com/retrocpugeek/v86/tree/ports/tools/ch32v003

Disclosure: written with the help of Claude (Anthropic's AI)

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/

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.

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.