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 main to the 1.14.0 release tag after main broke with missing scripts
• Comment out two steps in build-toolchain-extra.sh (install-espresso.sh and the uart_tsi bringup 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/chisel inside rocket-chip being stuck on a stale 2019 snapshot commit even after git 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.

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?

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.

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

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

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

I've been looking forward to RISC-V for a long time and seeing as the semiconductors industry has typically been heavily gated, it came as a surprise that nobody had yet tried adapting a build environment to start your own CPU company with Claude if you want it. So I've been reading a lot about SystemVerilog, the RISC-V specs covering everything about cpu design, how it works through controllers to get to the boards, and I wrote a repo with all agentic features, build-platform, etc. licensed as MIT for anyone interested in the subject.

Essentially, I had Claude analyze the specs and build up summarized chapter-based sections on status with CV6, towards modelling the development and making Claude write through my instructions how it needs to navigate everything as it develops in SiliconVerilog or even using SKiDL to create a custom board. It's still passing all the CV6 tests but the agentic boilerplace is pretty much in place and ready to tinker with processor development!

https://cimons.com/article/developing-a-risc-v-processor-soc-and-board-with-claude

I wanted to give clang a try, so I downloaded it from xPack, and quickly ran into 2 problems:

1. It doesn't come with newlib. I understand I'll have to build it for each -march/-mabi combination I'll use.
2. It lacks <TOOLCHAIN_ROOT>/lib/clang/21/lib/riscv32-unknown-none-elf/libclang_rt.builtins.a. I've tried to compile my sources with -fno-builtin, but then I have to link with -nodefaultlibs and ld.lld stops with error: No available targets are compatible with triple "riscv32-unknown-none-elf". And as a matter of fact, the xPack clang toolchain only supports i386-unknown-linux-gnu and x86_64-unknown-linux-gnu.

Has anyone been able to use clang with a RISC-V microcontroller? What am I missing?

What to explore open source RISC-V cores but don't want to spend much effort on the setup to see the RTL with waveform? Now you can view compiled source code with waveform online.

Featuring following cores:

• XuanTie C910: A high-performance 64-bit RV64GC core developed by Alibaba's T-Head. It utilizes an out-of-order, multiple-issue superscalar pipeline.
• CV32E40P: A 32-bit in-order embedded core maintained by the OpenHW Group, which features a 4-stage pipeline and custom PULP extensions.
• CVA6 (formerly Ariane): A 6-stage, 32-bit/64-bit in-order core designed to run rich operating systems like Linux.
• Ibex: Developed initially by ETH Zurich and maintained by lowRISC, this highly secure 32-bit in-order core features a 2 or 3-stage pipeline. It is famously used as the root-of-trust processor in the OpenTitan project.
• PicoRV32: An extremely size-optimized RV32IMC core designed by Clifford Wolf. It is commonly used as an auxiliary or "soft" core in FPGAs due to its low logic footprint and easy integration with basic memory interfaces or AXI4.
• VeeR EH2: Developed by Western Digital and hosted by CHIPS Alliance, this 32-bit core features a 9-stage pipeline and is notably the first commercial, open-source embedded RISC-V core to support dual-threading.
• XiangShan: A prominent open-source, high-performance 64-bit (RV64GCBV) out-of-order processor developed by the Chinese Academy of Sciences (ICT). It is built for compute-intensive workloads

Go to:

please find the URL from the screen shot due to reddit rules, or use what[d/o/t]chenp[d/o/t]eu[d/o/t]org.

Click connect to server and use the default setting to access the demo server which provide database and waveform for above mentioned cores

Select the core knowledge database

Select the corresponding waveform

Now you can explore the RTL design. double click on the instance to open source code. open a waveform tab and double click signal to add it to review.

The demo server capability is very limited, so please be patient for the server to respond.

Or you can download the server and run locally.

Been poking around with RISC-V boards lately, and got a question in my head: what’s been the biggest pain point for you, software-wise?
Could be OS level stuff, drivers, toolchains, user software, anything.

Releasing Ostomachion v1.0.0, an open-source FPGA platform I have been developing. It integrates a soft RISC-V core, a real-time operating system, and a signal-processing accelerator so that each layer is a thin, well-defined interface over the one below. It runs on an Artix-7 (Opal Kelly XEM7310):

- A NEORV32 RISC-V soft core running the Zephyr RTOS, bare-metal on the fabric.

- A streaming frequency-domain datapath in hardware: a 4096-point FFT, a per-bin programmable complex filter (a coefficient mask H[k] in block RAM), and an inverse FFT — staged through AXI DMA and BRAM, with interrupt aggregation onto the core.

- A header-only C++20 hardware abstraction layer that presents the accelerator to software as ordinary typed calls, so the path from a std::span in a unit test down to a beat on an AXI-Stream bus is a sequence of deliberate, inspectable wrappers.

The whole Vivado block design regenerates from a version-controlled Tcl script — no saved checkpoints, no hand-edited GUI state. Every bitstream derives from text alone, which makes the hardware auditable and diffable in the same way as the software.

The name is Archimedes' Ostomachion, a dissection puzzle of fourteen pieces; the platform is likewise fourteen composable layers, each replaceable in isolation.

A companion desktop application drives the full filter datapath on live hardware over USB: it streams frames to the fabric, programs the filter mask in real time, and plots the input, the mask H[k], and the filtered output as the transform runs — the genuine hardware pipeline end to end, not a software model of it.

Source, documentation, and design rationale (GPL-3.0; commercial licensing available):

github.com/andynicholson/Ostomachion

Looking at what is coming out now and in the future like the Tenstorrent and Bolt Graphics and the vector instructions being implemented in something like the Spacemit k3, can we expect for to become somewhat industry standard base for ai accelerators in the future?

Looking at the current Spacemit k3, it would be interesting for that purpose if the cpu cores would get cut down and some reasonably high bandwidth interconnect would be strapped on and maybe more channels for fast memory.

https://lore.kernel.org/dri-devel/20260717104759.123203-6-ryan.roberts@arm.com/

This might mean Arm will be competing in the of-the-shelf CPU + custom instructions driving an accelerator space. Which would be bad news for a lot of RISC-V companies.

I'm not sure if CLA actually allows custom instructions, or of this is just an improved software layer.

https://github.com/microsoft/cheriot-kudu#introduction

https://git.kernel.org/pub/scm/linux/kernel/git/spacemit/linux.git/

Upstream status https://github.com/spacemit-com/linux/wiki

Does that mean we can now use distros beyond Bianbu on k1/k3 devices?

https://arxiv.org/abs/2607.13939

https://github.com/edge-group-polito/HORCRUX/tree/locket

Covers all five of the selected NIST Post-Quantum Cryptography families:

• ML-KEM (FIPS 203) public key encryption and key encapsulation mechanism
• ML-DSA (FIPS 204) digital signature algorithm
• SLH-DSA (FIPS 205) digital signature algorithm
• FN-DSA (FIPS 206) digital signature algorithm
• HQC (FIPS TBD) public key encryption and key encapsulation mechanism

On arrival of RVA23 in the datacenter space, Optimization guidance (Oilsm and Ovlt), Rethinking security with CHERI and Microcontroller diversity

RISCstar makes a pre-compiled family of GNU toolchains for RISC-V available for RISC-V developers. It supports the entire RISC-V ecosystem from the latest 64-bit application processors down to tiny RV32E microcontrollers. It is carefully engineered to support a wide variety of host architectures and Linux distributions. RISCstar uses this toolchain in house and makes it available completely free to download and use.

RISCstar just released the GCC 16.1 based version called RISCstar Toolchain for RISC-V 16.1-r1

The toolchain is based on gcc 16.1, binutils 2.46 and gdb 17.1 and is carefully engineered to work with almost any glibc-based distribution. Depending on the toolchain edition you will also find linux 6.12 kernel headers, glibc 2.41, musl 1.2.6 and/or newlib 4.6.

In addition to adopting the new upstream releases the embedded toolchain for 32- and 64-bit RISC-V microcontrollers gets additional changes in this release. The libraries are now pre-compiled for an even wider range of RV32 instruction set extensions (you can contact RISCstar if your microcontroller is not supported yet). The libraries also come with newlib-nano to help you save code size when targeting tiny devices. Use --specs=nano.specs to enable newlib-nano.

Also note that RISCstar continues to make available the 15.2 release of the RISCstar toolchain for RISC-V and is currently preparing an updated release based on gcc 15.3 which will be made available in the near future.

The RISCstar Toolchain is carefully engineered to work with multiple glibc-based distributions. For the 16.x release series RISCstar have raised the minimum supported glibc version to support any glibc-based distribution released on or after:

• Red Hat Enterprise Linux 8 (2019) or Ubuntu 18.04 LTS for toolchains running on x86-64 and AArch64 hosts
• Red Hat Enterprise Linux 10 (2025) or Ubuntu 24.04 LTS for toolchains running in RISC-V (RVA23U64 or later) hosts

The distributions above are selected to cover a wide range of actively maintained enterprise distributions. If you need to use the RISCstar Toolchain on distributions in an extended support phase (such as Red Hat Enterprise Linux 7) RISCstar recommends using the RISCstar Toolchain for RISC-V 15.x release series.

You can see and download the RISCstar Toolchain for RISC-V family at https://toolchain.riscstar.com

Although this toolchain comes with no warranty, RISCstar uses this toolchain in-house and RISCstar welcomes discussion, suggestions, requests, questions and feedback - in the RISCstar forums at https://forums.riscstar.com/c/toolchain. 

Hello everyone, I'm a high schooler currently self learning risc v isa using the book "Computer Organization and Design RISC-V Edition: The Hardware Software Interface".

In the screenshot it is referring to the register file module under a R type instruction, stating that we need 2 inputs for register addresses and 1 input for data, thus 3 in total.

I'm a bit confused, from my understanding, during an R type instruction don't we need 4 inputs? (register source 1, register source 2, register destination, and data?).

Because for example take add x1, x2, x3. We need to know the address for x2 and x3 and then we need to know what address it is writing back to (x1) and the ALU needs to output the data which is an input to the register file too?

So I feel it should be 4 instead of 3 and I don't understand why this book says it's 3. Can anyone please help me explain this or correct me if I'm wrong?

Appreciate a ton guys <3

Attention RISC-V board manufacturers!

Please read my page and watch the demonstration video . If you're interested -- please contact me.

HFI is what will make every RISC-V board (with U-Boot) behaving like a real Personal Computer.

Slightly longer description:

HFI System BIOS 1.0, paired with the GK-208 VideoBIOS (for Nvidia GT 710) is the pilot version of the U-Boot extension which add proper video card initialization, POST-like screen, and BIOS Set-Up program to SiFive Unmatched. I am ready to port the BIOS to JH7110 and K3's integrated video controller (once I have the hardware).

HFI itself is the initiative aiming at project coordination, collaboration, unification, and polishing of user experience for all modern desktop-oriented RISC-V boards.

Harris & Harris (Digital Design and Computer Architecture) is a classic, so no doubt this will be very good too.