Part 11: RISC-V Softcore Processor

What this lecture covers

This lecture answers how to run actual software on an FPGA rather than hand-designed logic, by building an existing open-source RISC-V processor (FemtoRV, by Bruno Levy) for the iCEstick and writing a small C program for it. It covers installing the required toolchain on a Raspberry Pi running Linux, configuring FemtoRV's board-specific settings, and understanding how the processor talks to hardware peripherals through memory-mapped I/O addresses.

By the end you can build and upload the FemtoRV system-on-a-chip to the iCEstick, write a C program using its header-provided macros to control the LEDs and print to a serial console, and compile and upload firmware with make main.prog. The lecture sets a challenge to enable and test the buttons as inputs, and previews building a custom hardware peripheral next.

Key ideas

• RISC-V: an open instruction set architecture with no licensing fees, making it practical to implement and modify CPU designs on an FPGA for learning purposes.
• FemtoRV: a small RISC-V implementation by Bruno Levy aimed at learning and tinkering, chosen here (using its "quark" variant) because it fits the iCEstick's limited logic cells, unlike larger designs such as PicoRV32.
• System-on-a-chip (SOC) top level: the processor core is instantiated inside a top-level Verilog module (femtosoc.v) alongside program memory, RAM, and driver modules for peripherals like LEDs and buttons.
• Board configuration defines: a config header (for example rtl/configs/config_icestick.v) enables or disables peripherals and sets RAM size and program storage location, tailored to what fits on a given board.
• Program vs data memory: firmware is stored in external SPI flash and executed from there, while general-purpose RAM lives in the FPGA's block RAM.
• Memory-mapped I/O: peripherals like the LEDs don't exist as real memory; writing to a specific address (computed from an I/O base address plus a per-device bit offset) is intercepted by hardware and drives the corresponding driver.
• Toolchain build: this workflow requires building Yosys, Icarus Verilog, Project IceStorm, and nextpnr from source (in addition to a RISC-V compiler), and the lecture recommends Linux (a Raspberry Pi) since the available guides target it.

Walkthrough

Project overview and choosing FemtoRV (0:33)

The lecture compares available open RISC-V implementations for the iCE40, explaining that Claire Wolf's PicoRV32 needs more lookup tables than the iCEstick has to spare, while Bruno Levy's FemtoRV is built specifically for small boards. It tours the FemtoRV repository structure: RTL Verilog for the processor and SOC, device driver modules, and processor variants, noting the "quark" version (no interrupts) is used here.

Setting up the Raspberry Pi and cloning the repository (2:47)

Working over SSH on a Raspberry Pi, the lecture updates package lists and clones Bruno Levy's learn-fpga repository, following its iCEstick-specific tutorial for the rest of the installation.

Building Yosys, IceStorm, and nextpnr from source (3:44)

Even with apio's tools already installed, the lecture rebuilds Yosys, Icarus Verilog, Verilator, Project IceStorm, and nextpnr from source and installs them system-wide, since apio's copies aren't necessarily on the system path. It also adds a udev rule so Linux can talk to the iCEstick's FTDI chip over USB.

Configuring FemtoRV for the iCEstick (8:14)

In rtl/configs/config_icestick.v, unused peripherals (an IR receiver/transmitter, an OLED screen, an LED matrix) are commented out to save logic cells and I/O pins, the quark processor variant is selected, RAM size is set based on what's left after reserving space for processor registers, and firmware is configured to run from SPI flash rather than being preloaded into block RAM.

Memory-mapped I/O and writing the blinky program (13:27)

After building and uploading the SOC with make icestick, the lecture examines FemtoRV's header files to see how I/O addresses are computed from an I/O base address plus a per-device bit offset (for example, the LED address is 0x400004). A main.c program using the provided header's macros writes values to that address to turn LEDs on and off, uses a delay function, and prints text and CPU frequency over a serial connection.

Compiling, uploading, and the buttons challenge (19:40)

make main.prog compiles the C program for RISC-V and uploads it to SPI flash, and a serial terminal (picocom) at 115200 baud shows the printed output while the first two LEDs blink. The challenge is to enable button inputs by editing the SOC's Verilog and PCF file (using the SB_IO directive, since the -pullup PCF option doesn't work in this flow) and writing a C test program to read them.

Before you watch

• Complete Part 10 ("Metastability and Clock Domain Crossing") to finish the series' introductory portion before this soft-processor detour.
• Access to a Linux machine (the lecture uses a Raspberry Pi) is effectively required, since the FemtoRV toolchain build targets Linux.
• Basic C programming familiarity is assumed for writing the firmware.

Check your understanding

1. Why does the lecture choose FemtoRV's "quark" variant over a larger RISC-V implementation like PicoRV32?
2. Where does FemtoRV's program memory live versus its RAM, and why are they stored differently?
3. How is a memory-mapped I/O address like the LED driver's 0x400004 computed from the I/O base address and bit offset?
4. Why does the lecture rebuild Yosys and the other tools from source even if apio already installed them?
5. What change is needed to the PCF file and Verilog to enable button inputs, according to the challenge?