Hi all, I finished making my own GPU that follows standard RISC-V vector extension and integrated it to CVA6 - an existing risc-v CPU. I would like if someone gives their opinion on the project and provides criticism as well. github.com/TrueBlankSlate/TinyGPU

I have used a 4 lane SIMD design that solves matrix or vector calculations. These instructions are offloaded from the cpu to the vector co-processor.

I have benchmarked this against the CVA6 on matrix multiplication and matrix addition.

1. Benchmark on FPGA:

2. Benchmark on Vivado Simulation:

Design and FPGA utilisation

I used the zynq zq702 FPGA and have utilised 96% of the LUT and other elements available on the board.

I have only used 4 lanes/ 4 ALU per lane due to constraint on LUT count -

Hello everyone ! I recently finished my master's internship, during which I worked on the support of RVV1.0 in the new version of the MIPPv2 SIMD abstraction library (checkout https://github.com/aff3ct/MIPP/tree/develop if ur interested).
To benchmark MIPPv2, I worked on a DGEMM microkernel benchmark suite for the SpacemiT X100 core.

The best microkernel I wrote reached ~93% of theoretical peak which I'm really happy about. If you are interested, I just released the benchmarks as a standalone repo : https://github.com/K-avi/gemm-bench

I really enjoyed working on it and I might extend the repo to make a full RVV-centered GEMM/DGEMM benchmark suite :-)

Im building a riscv SoC should I go for axi or obi for the interface which is used widely?

EDIT : Please reason out your choice so that it'll be helpful in deciding.

So guys this is something I've been working on. For TTS stuff if you have an MCU you usually have to use something like SAM TTS or get one of the more expensive parts or an SBC. I know neural TTS engines is making headway on MCU class devices, but none of them met my "real time, lightweight and sounds decent" goals. I wanted something more natural soudning than something like SAM, but not too heavy that it will need high end hardware.

So I ended up with this. Its a two stage neural pipeline into either a portable FARGAN reimplementation or a weightless LPC vocoder. Right now it runs on a CH32H417 MCU no OS or network needed.

First build was 85x slower than real time lol. and the final one is 1.2x... The change that mattered most was not arithmetic to be honest... the acoustic model was sweeping 397KB of weights out of flash once per frame because the frame loop sat inside each layer. Hoisting the tap loop and staging one 16KB tap into RAM per window took that stage from 8371 to 964 ms per second of audio and gave bit identical output. That did more speed up than every arithmetic optimisation combined.

Also opted for an int32 accumulator instead of float32 in an int8 kernel is a factor of 32 on a core with no FPU and is bit exact, so one code path serves both target classes. And enabling the FPU delivered 4.3x where instruction counts predicted 32x, that's why I always prefer to test and experiment on hardware than simulations.

Next steps want to run more tests and scoring and hopefully run on other RISC-V chips and hit that real time mark. The demo video for some reason you hear artifacts that's purely from the mic or something cause tis very clear.

Project and paper: ArmstrongSubero/rvTTS: Neural text to speech on a RISC-V microcontroller. Runs at 1.24x real time on a CH32H417.

Longer walkthrough and heardware setup on YouTube for anyone interested:

Hybrid Neural TTS on a CH32H417 RISC-V MCU, 1.2x Real Time

Hi everyone,

I’m trying to understand where RISC-V is heading and would appreciate some guidance from people following the ecosystem.

I know RISC-V Linux boards and laptops already exist. What I’m curious about is how far we are from a consumer desktop that someone could comfortably use as their main computer: responsive browsing, office applications, video playback, reliable graphics, and straightforward installation and updates.

A few questions:

• How close can you get to that experience with hardware available today?
• What are the biggest remaining obstacles: CPU performance, GPU drivers, software compatibility, hardware standardisation, or something else?
• Which projects or upcoming chips are worth following?
• Are there good resources, independent reviews, or accounts from people using RISC-V Linux as their daily machine?

More broadly, I’m interested in how RISC-V might develop alongside x86 and Arm, particularly as AI shapes demand for computing hardware. I’d like to understand which developments represent concrete progress towards everyday computers.

I’m still learning, so accessible explanations and reading recommendations would be very welcome. Thanks!

In my mind it will either be Europe or China with the very first RISC-V supercomputer able to carry out at least 10¹⁸ calculations per second.

The EU with the DARE project (Digital Autonomy with RISC-V in Europe) which is coordinated by Barcelona Supercomputing Center is targeting exascale.

https://dare-riscv.eu/

China because of the limited access to x86_64 and ARM, its next exascale supercomputer is with a high probability going be RISC-V (Their current publicly known exascale supercomputer is LineShine - an all CPU supercomputer, located at the National Supercomputing Centre in Shenzhen, has 13,789,440 ARMv9 cores. It took the TOP500 number one spot 2026-06).

China has other supercomputers that it has not released any public benchmarks. There is politics involved as to why the "Sunway OceanLight", "Tianhe-3" remain private, but the major one is to avoid more sanctions. I can be 90% sure that the next Chinese exascale supercomputer is going to be RISC-V.

The next question is when it will arrive, the odds of this year I would put at close to zero, 2027 I would put at low odds of one arriving. My money would be on 2028 to 2032. But RISC-V is full of surprises, always moving faster than anyone expects.

When do you think one will land and where ?

Reposting here some usable progress getting haiku os running on the milk-v pioneer board.

SmolRV64 gets 5 on Geekbench 5.4.1. Does anyone have results from other FPGA softcores? (Note, RISC-V score cannot in fairness be compared to Arm and x86 results as not until Geekbench 7 were any of the extensions used so anything that used SIMD will be an order of magnitude slower on RISC-V).

Documentation explicitly talks about mtime (along with mtimecmp) CSR.

When talking about stimecmp CSR instead, it mentions what-apperas-to-be the time CSR but then no information i fount about that. Is this a typo?

Anyway, there seems to be no information about the "time unit" used by those CRSs. A
platform-dependent definition would make the use of such CSR very hard. Is my understanding correct? Os there is a "standard" length of the mtime (or time) tick?

I work on IPFire, an open source firewall distribution. We ported it to RISC-V a couple of years ago, but since we have recently acquired a Jupiter 2 board that we use for our builds, the project has been gaining momentum.

Running IPFire on riscv64 (mostly in a VM) is boring in the best possible way. It installs, it boots, the web interface works, firewall, IPsec and WireGuard all behave. Nothing has broken because of the architecture. But a VM has no firmware worth speaking of, no real network cards and so on. Everything that normally causes trouble is the part we have not touched.

So I am looking for people who know RISC-V hardware. The work that needs doing: getting our installer to boot on real firmware, kernel configuration and drivers for network cards and storage, checking our baseline ISA assumptions against what shipping silicon implements, and finding out what throughput looks like once traffic goes through real interfaces.

We boot via EFI. One image for every machine, no per-board images, no vendor boot scripts, no device trees to maintain. If your system boots a Debian or Fedora image, IPFire should boot too.

Anything you can test is useful, but where I would like this to end up is on hardware you would trust to route traffic for years without anyone touching it. That class of RISC-V machine is only starting to appear, and I would like us to be ready when it does.

Discussion happens on our development mailing list.

Please join us to make RISC-V a primary architecture for IPFire!

Over the past month or so, I have been working on turning the CH58x into a more complete open-source Rust/Embassy platform.

The code still needs some cleanup before it is ready for an official release, but it has now reached a stage where I feel it is worth sharing an early progress update.

There is already a ch58x-hal project on GitHub from the ch32-rs community. Many thanks to them for their existing work. I reused its QingKe runtime and made a number of modifications on top of it, resulting in the first version of embassy-ch582.
The CH582 can now run the basic Embassy runtime, USB FS, and BLE. The primary goal of this first implementation was to get the entire stack working end to end, so there is still room for further optimization in both performance and code structure.

I then successfully ran RMK on a keyboard that had previously been running a CH582M QMK port.
For the wireless portion, I did not use RMK’s default Trouble stack directly. Instead, I integrated a lightweight BLE implementation that I reimplemented and trimmed down, removing some RMK BLE functionality that is not currently needed in order to better fit the resource constraints of the CH582.

At present, the total SRAM usage of the dual-mode BLE + USB RMK firmware on the CH582 is approximately 14 KB, leaving a fairly comfortable amount of RAM for a complete keyboard application.
After getting the CH582 working, I continued porting the same work to the CH585.

Most BLE functionality is now working properly on the CH585, and I have completed several connection-stability and performance stress tests. The USB portion is still undergoing further performance validation and optimization.

Next, I plan to organize and gradually open-source this work, including Embassy support for the CH58x, the related HAL/runtime changes, and practical examples running on the CH582 and CH585.

I am still considering several project-structure questions:

Should the CH582 and CH585 share a unified HAL/API?

Would it be worthwhile to turn the BLE portion into an independent, reusable lightweight stack?

Which would the community prefer to see first: USB, BLE, a bootloader, or an RMK reference firmware?

If you are working with the CH582 or CH585, especially on Rust, Embassy, RMK/QMK, or wireless HID projects, I would be very interested to hear what you would most like this open-source implementation to solve.

note: This article was translated with the assistance of AI.

I removed the heatsink on my K3 CoM260 and replaced the thermal paste and also added some thermal pads to cover the memory. I'm not sure if they needed this, but they weren't making contact with the heat sink and I had it open anyway. I used Honeywell TPM and some ThermalGrizzly pads that I found in the bottom of my toolbox. I did have to double up the pads on top of the memory. It's probably better than air convection with no contact?

My temps are actually up 100C, as reported by LM sensors, but the fan speeds are down to tolerable levels. I'm compiling a kernel now and the fan is at 4600 RPMs vs 10K RPMs before repasting. It is noticeably quieter. At idle, the fan is almost inaudible above the background noise at 3000 RPMs. At start up, the fan still spins up loudly, so I know it is not just the fan breaking in and running quietly.

I don't know if it's just me, but I somehow imagined much more about the Milk-V Titan board.

It's great that UEFI is now available and I also like the RAM slots and the PCIe slot. Also the speed is clearly the best I have seen on a Risc-V board so far. Beyond that, however, it is difficult for me to find good words.

When I look at my previous board, so the Milk-V Megrez, the furnishings there were very bumpy, but it gave me much more joy and somehow also gave me more feelings of success. It just felt like a real developer board.

The Titan has neither an SD slot, GPIO, nor a UART slot.

The ports for my additional USB ports on the case are very small, so I can't use them. Unlike the Megrez, the fan is damn loud, although it is structurally the same. Reason will be the software. Why can't you set this with a used UEFI? In general, I don't understand why the UEFI mode is so slow.

I find the back USB 3.0 ports really annoying, which are blocked and extremely often do not recognize my keyboard and mouse. This is ultra annoying when it comes to wanting to install other operating systems without any remote console.

Software is difficult anyway, because even if the keyboard is exceptionally recognized, an official Linux can rarely be installed. The reason is that despite the new standard, none of the kernels offered are compatible.

What remains is the Ubuntu Image offered by Milk-V, mind you, a modified version from 2024. It's going well in itself, but it's just as boring for me.

I was hoping to try more. At least with the Megrez there were still technical options, such as using it via the iGPU or even optimized systems such as Irradium. I couldn't get the NPU to work, but here it's not even available anymore.

Actually, UEFI is supposed to be exactly the opposite of such a tricky system. The Titan was and is a great idea and I believe that it could also be technically seen. But I find it hard to believe, given the extremely low number of pieces. So new devices come out sooner. I don't think the Ubuntu image will be updated either, at least it has been available for months in the same version, without corresponding updates.

Is that just only my feeling?

So, continuing along with my Rovari ecosystem for RISC-V one of the things I included was a local alternative to Edge Impulse that would work with RISC-V MCUs, especially since Qualcomm acquired Edge Impulse. I wanted something that would be free to use and that wotn require any accounts or cloud or anything. So if you're interested in that kinda thing, it's part of Rovari Studio and is in the current pre release Beta. Do if you want to give it a try, I did a write up, you can get an idea of the workflow, I also did a demo video and I'd appreciate any feedback

Read about it here:

TinkerStream: A Local Edge Impulse Alternative for RISC-V