Ventus: a RISC-V vector GPGPU written in Chisel, with the toolchain to match

Ventus targets the gap between an instruction set and a GPU

Ventus is described in one line as a GPGPU processor supporting the RISC-V vector extension, developed with Chisel HDL. Read that carefully, because it excludes most of what people call a GPU project. There is no graphics pipeline here, no rasteriser, no display output. The target is a general purpose parallel processor for compute kernels, with vector instructions as the core of its execution model, and the design is written in a hardware description language that generates Verilog rather than in a low level HDL.

That combination puts it in a specific niche. Hardware researchers who want to study vector extensions, OpenCL offload mechanisms or instruction set design for accelerators are the audience, and the people who can actually use the project are the ones prepared to read architecture PDFs and run simulation cycles. A developer who wants to run a deep learning training job today is not the audience, and the repository does not pretend otherwise.

The intellectual output is documented in two places. The README asks users to cite an IEEE TVLSI 2025 paper on a RISC-V based GPGPU with vector capabilities for high performance computing, and an ICCD 2024 conference paper on Ventus as an open source GPGPU based on RISC-V and its vector extension. Slides from the ICCD 2024 talk sit in the docs directory. Reading the papers first is the sensible order for anyone evaluating this, because the README itself is a build guide rather than a design document.

The toolchain is four sibling repositories, not one

The most important practical fact about Ventus is that the processor repository is only the hardware half. The README states that a script in the ventus-llvm repository configures the complete software toolchain, including the instruction set simulator, the pocl fork and the driver, and it points at separate repositories for the isa-simulator and for pocl, both under the same organisation. The OpenCL C compiler based on LLVM was developed by Terapines, a separate company, which is a useful signal about how the pieces are divided.

So the data flow for a real kernel goes across several boundaries. An OpenCL C kernel is compiled by the LLVM based compiler, the driver and the pocl fork handle the runtime side of offload, the ISA simulator stands in for the hardware when you are not running RTL, and the RTL in this repository models the processor itself. The `sim-verilator/` directory holds a Verilator based simulation path, and the README recommends the separate ventus-env project for getting the whole toolchain together for simulation.

This structure is a real cost for a newcomer. There is no single installer, and the version alignment between the compiler, the simulator and the RTL is handled by scripts in another repository. It is also a strength for the intended user, because each component can be inspected and modified on its own, which is exactly what an academic hardware group wants when experimenting with an instruction set.

make init and a Java 19 or 21 host

Getting the repository into a buildable state is a short sequence, but it assumes a fairly heavy Linux environment. The documented dependencies for Ubuntu are below, and they cover a C and C++ toolchain, Verilator, LLVM with clang and lld, protobuf, antlr4, numactl, cmake, wget, make and git:

apt-get install gcc g++ make parallel wget cmake verilator git llvm clang lld protobuf-compiler antlr4 numactl

The project also documents an Arch Linux command and a nix-shell route, and the README notes a recommendation to use Java 17 or higher with the project tested under Java 19 and 21. There is also a Chinese tutorial for setting up WSL and the IDE from scratch, with the caveat that some of its commands are out of date but that it remains a useful reference, and a note that VS Code with the Scala Metals plugin can import the mill build.sc project configuration.

Cloning and preparing the submodules is then a two step operation:

git clone https://github.com/THU-DSP-LAB/ventus-gpgpu.git
make init

The init target is a recursive submodule update, and that matters because the dependencies directory in the repository tree points at external content. IDE support comes from make idea or make bsp, both of which drive mill.

make idea

make bsp # generate IDE bsp

The block-based project description uses mill rather than sbt, and the mill launcher is vendored in the repository tree, so the build does not depend on a globally installed build tool. The Scala Metals route is the one to take if you intend to write Chisel, since the alternative is to treat the repository as a black box and only consume generated Verilog.

make verilog produces GPGPU_top.v, and a second path targets FPGA

The build output people actually want is Verilog, and there are two ways to get it. The standard target runs the mill elaboration step for the project version 6.4.0 and writes a single top level file named GPGPU_top.v:

make verilog

The FPGA route is different in kind and produces a directory of files instead. The fpga-verilog target runs the Chisel main entry with a firtool pass to split the design into separate Verilog files, then runs a script to generate the memory files from a mem.conf description:

make fpga-verilog

The README says this is the output used for deploying Ventus on FPGA, and the generated files land in gen_fpga_verilog/. The underlying mill invocation pins the cross compile to the GPGPU_axi_adapter_top module and the target to chirrtl, and the memory split relies on firtool options including --repl-seq-mem and a memory configuration file.

The difference between the two paths is the one to hold on to. The single top level Verilog is the convenient artefact for feeding a simulator, and the split, memory included form is what you need when the design has to be taken to a board, because a full SoC will not fit through a single monolithic file into a vendor toolchain. Anyone planning to do actual FPGA work should expect to deal with the memory configuration file, since external memory behaviour is where a vector processor design most often breaks.

make test is deprecated and the simulator was rewritten

Here is the sharpest limitation in the project, and it is stated plainly in the README. The make test target is deprecated. The reason given is a limitation in chiseltest, and the response was to build a separate simulation framework based on Verilator, with details in the README inside the sim-verilator folder. The original target is still present in the Makefile and still points at mill running a test class, and it still writes a log into a test_run_dir directory, but the maintainers are telling you not to rely on it.

make test

The replacement is not just an implementation detail. A test framework written specifically for this design is what makes the RTL testable at scale, and the fact that the upstream chiseltest limitation forced the rewrite tells you the tests are custom rather than portable. The repository tree also carries a sim-verilator-nocache directory next to sim-verilator, which suggests a second configuration for cases where caching interferes.

Testcases for RTL simulation are supplied through a .metadata file and a .data file, and the README calls this a legacy method. The metadata file is a struct describing the kernel, with fields for the instruction start address, the kernel identifier, three dimensional workgroup dimensions, the number of threads per warp, the number of warps per workgroup, the CSR_KNL value and the local data share size. The .data file carries initialisation content for the memory buffers the kernel touches. If you are porting existing test cases, expect to read that struct layout carefully, because the field names are abbreviated and the meaning of the base address field is tied to the CSR configuration.

No releases, a permissive licence, and documentation in two languages

The repository has no GitHub releases, and the software toolchain is not distributed from here. The README directs users to opengpgpu.org.cn for the release versions of the toolchain, with the English line pointing at the same release page, and names that site as the project home page. The last push to the repository was on 2026-10-16, so the code is being changed even though there is no tagged artefact to download, which means version tracking is done through git rather than through release notes.

The licence is MulanPSL-2.0, and the repository carries LICENSE alongside LICENSE.Berkeley and LICENSE.apache plus a NOTICE file, which is the pattern used when third party components are bundled under their own terms. MulanPSL-2.0 is a permissive licence modelled on permissive open source practice, and for research and commercial hardware work it carries the usual obligations around retaining notices. Your own counsel should confirm how the bundled Berkeley and Apache licensed files sit with your particular use.

Documentation is split by language. The architecture whitepaper and the Chinese manual for the Ventus 2.0 design are both in the docs directory, and the Chinese manual is described as covering the changes needed to support OpenCL. The English README points at the whitepaper for the ISA and micro architecture. That means an English only reader gets the build guide and the paper, but the more detailed manual is Chinese, which is worth knowing before you commit to a schedule.

Editorial conclusion

Ventus is worth adopting if you are working on vector accelerators, OpenCL offload or open hardware instruction set design, because it gives you RTL, an instruction set simulator, a pocl based compiler path and published papers in one place. It is the wrong tool for application developers or for anyone expecting a packaged release, since the repository has no GitHub releases and the recommended path is a source build against a pinned set of sibling repositories. Before starting, check that your host has Java 19 or 21, that Verilator and the LLVM toolchain match the versions the build expects, and read the sim-verilator README, because the documented make test target is deprecated and the replacement framework is the one that matters.

Frequently asked questions

Official sources

1. Issues
2. License: MulanPSL-2.0
3. README
4. THU-DSP-LAB/ventus-gpgpu on GitHub