🖥️ PixelCore — Build a RISC-V CPU in Simulation · Part 2 · Beginner

Installing the Toolchain: Verilator, GTKWave & RISC-V GCC

Part two of PixelCore. With WSL2 in place, we install the tools that turn SystemVerilog into something you can run and see: Verilator (the simulator), GTKWave (the waveform viewer), the RISC-V GCC compiler, and VS Code wired into WSL.

In this part

What each tool in the toolchain does and why we need it.
Installing Verilator, GTKWave, and the RISC-V GCC compiler on Ubuntu.
Wiring up VS Code so you edit on Windows while everything builds on Linux.

Part 1 Part 2 Part 3

In Part 1 we set up WSL2 — a real Linux environment inside Windows. That was the foundation. Now we put the actual tools on top of it: the ones that take the SystemVerilog we’re about to write and turn it into something that runs, prints output, and draws waveforms you can inspect.

Here’s what we’re installing and why each one earns its place:

Verilator — the simulator. It compiles your SystemVerilog into a fast program you can run. This is the engine of the whole project.
GTKWave — the waveform viewer. When something misbehaves, this is how you see what every signal did, cycle by cycle. It’s your debugger.
RISC-V GCC — a C compiler that produces RISC-V machine code. Later, this is what lets us write C programs and run them on the CPU we build.
VS Code — the editor, wired into WSL so you get a comfortable Windows editor driving a Linux build underneath.

Everything below runs inside your Ubuntu terminal unless a label says otherwise. Every code block is marked with 🐧 Run in Ubuntu or 🪟 Run in Windows so there’s never any doubt about where a command belongs.

First, refresh the package list

Package managers keep a local catalogue of available software. Refresh it so you install current versions:

🐧 Run in Ubuntu:

sudo apt update

Enter your Linux password if prompted. (You don’t strictly need a full upgrade here — we did that in Part 1 — but update makes sure the installs below resolve correctly.)

The build essentials

Verilator works by translating your SystemVerilog into C++ and then compiling that into a binary. So before Verilator itself, we need a C++ compiler and the make build tool. We’ll also grab git for version control:

🐧 Run in Ubuntu:

sudo apt install -y build-essential git

🧠Wait — Verilator turns my Verilog into C++?

Yes, and it’s the clever trick that makes it so fast. Traditional simulators interpret your HDL like a script, event by event. Verilator instead compiles your synthesizable design into optimized C++, which becomes a native executable. The result runs orders of magnitude faster — fast enough to boot an operating system in simulation. That speed is exactly why we’ll be able to run whole C programs on our CPU later.

The trade-off: Verilator doesn’t support every feature of the language. SystemVerilog has two kinds of features — ones that describe real hardware (the stuff that could become an actual chip) and ones that only exist for simulation and testing. Verilator fully handles the real-hardware parts, plus the common testing tools, but skips a few obscure, simulation-only features that never become hardware anyway. Since our whole goal is to describe real hardware, we’re not giving up anything we need.

Verilator — the simulator

🐧 Run in Ubuntu:

sudo apt install -y verilator

Confirm it installed and check the version:

🐧 Run in Ubuntu:

verilator --version

GTKWave — the waveform viewer

🐧 Run in Ubuntu:

sudo apt install -y gtkwave

GTKWave reads VCD files (Value Change Dump — a log of what every signal did over time) and draws them as the classic digital timing diagram. When we simulate, our testbench will write a .vcd file, and GTKWave turns it into a picture you can scrub through.

RISC-V GCC — the compiler for your future CPU

🐧 Run in Ubuntu:

sudo apt install -y gcc-riscv64-unknown-elf

Check it:

🐧 Run in Ubuntu:

riscv64-unknown-elf-gcc --version

This is a cross-compiler: it runs on your PC but produces machine code for a different processor — a RISC-V one. That machine code is literally the stream of instructions our CPU will fetch and execute. We won’t touch it for a few parts yet, but installing it now means the toolchain is complete and waiting.

VS Code, wired into WSL

You can edit files with a terminal editor, but for a project this size you’ll want a real editor. The trick on Windows is to run VS Code on the Windows side while it reaches into your Linux environment — so you edit in comfort, but every file and build stays on the fast Linux filesystem.

🪟 On Windows — install VS Code (not inside Ubuntu). Download it from the official site and install it normally.
🪟 On Windows — install the WSL extension. Open VS Code, go to the Extensions panel (Ctrl+Shift+X), search for WSL (publisher: Microsoft), and install it.
🐧 In Ubuntu — open your project. Back in your Ubuntu terminal, cd into the project folder (so code . opens the right directory) and launch it:

🐧 Run in Ubuntu:
```
cd ~/pixelcore
code .
```
The first time, this downloads a small VS Code server into WSL automatically. Then VS Code opens with a WSL: Ubuntu badge in the bottom-left corner (its colour depends on your theme and VS Code version — often blue, sometimes green; the text is what matters). That badge means you’re editing Linux files with the full power of the Linux toolchain behind them.

The toolchain, at a glance

Everything you should now have, and how to confirm it:

Tool	Role	Verify with
build-essential	C++ compiler + `make` (Verilator’s backend)	`g++ --version`
Verilator	Simulates your SystemVerilog	`verilator --version` (want 5.x)
GTKWave	Views waveforms (`.vcd`)	`gtkwave --version`
RISC-V GCC	Compiles C → RISC-V machine code	`riscv64-unknown-elf-gcc --version`
git	Version control	`git --version`
VS Code + WSL	Editor connected to Linux	`WSL: Ubuntu` badge, bottom-left

If every command prints a version and VS Code shows the WSL: Ubuntu badge, your environment is complete. From here on, we stop installing and start building.

Where we’re headed next

The setup is basically done. In Part 3 we put the whole chain to work for the first time: we’ll write a small piece of real hardware in SystemVerilog — a counter — build a testbench for it, simulate it with Verilator, and open the result in GTKWave to watch the signals tick. It’s a tiny design, but it exercises the exact write → simulate → inspect loop we’ll use for every single part of the CPU. By the end of it, you’ll have seen your first hardware run.