Riscv on Ampsand

RISC-V soft core 14: Measuring the board

Tue, 27 Oct 2026 14:00:00 +1100

Measuring the board

Part 14 of the RISC-V soft core series. Previously: The board arrives.

Part 13 ended with a list of things only the board can tell me. This part is the list I could get to: a scope on three signals, and a lot of bytes down the serial port. This might be the first part with no surprises, or a bunch of that’s what I thought bits.

I’ll say up front what is not here. I haven’t shown that the core meets 25 MHz on every path, and I haven’t looked at button bounce or the 7-segment flicker. Those are still to do, and maybe I will. This isn’t going to production, and with the signals I scoped and the serial soaks behind me I am fairly confident that what is supposed to happen is happening. As we know though … there are always edges.

RISC-V soft core 13: The board arrives

Fri, 23 Oct 2026 14:00:00 +1100

The board arrives

Part 13 of the RISC-V soft core series. Previously: The scanner, third time.

Twelve parts, and not one of them ran on a physical board. It has been said outright. The design had been built, placed, timing-checked and simulated three different ways, and never switched on. This part is the switching on. It did not go the way the simulators said it would, and the answer my friend was both software and hardware, perhaps the greyware.

RISC-V soft core 12: The scanner, third time

Mon, 19 Oct 2026 01:00:00 +1100

The scanner, third time

Part 12 of the RISC-V soft core series. Previously: Where it breaks.

The Larson scanner has been the series’ test program from the start, and this is its third appearance.

In part 1 it was the blinkenlights: eight LEDs, one bit shifted along in assembly, and the only thing worth looking at was the CPU going FETCH, EXECUTE, FETCH. In parts 6 and 8 it climbed the timing ladder: a delay loop, a polled deadline, then a timer interrupt with the CPU asleep in wfi between steps. The CPU stopped being the busy part.

RISC-V soft core 11: Where it breaks

Mon, 19 Oct 2026 00:45:00 +1100

Where it breaks

Part 11 of the RISC-V soft core series. Previously: What does a multiply cost?.

The point of this project was never only to build a CPU. It was to build one, make it run real code, and find out where it breaks. This post is that list. Some of the edges are bugs I found, and each of those has a story about how. Some are limits of the design, and they say what to build next. And one of them is bigger than all the others, and I will start there.

RISC-V soft core 10: What does a multiply cost?

Mon, 19 Oct 2026 00:40:00 +1100

What does a multiply cost?

Part 10 of the RISC-V soft core series. Previously: First C on the core.

The first C program had a line in it that looks harmless: a * b. On a modern laptop that is one instruction and a few clock cycles. On this core there is no instruction for it. The core is RV32E with no M extension, so no mul, no div and no rem. The compiler turns each *, / and % into a call to a library routine, a loop of shifts and adds that runs as ordinary code.

RISC-V soft core 9: First C on the core

Mon, 19 Oct 2026 00:35:00 +1100

First C on the core

Part 9 of the RISC-V soft core series. Previously: Sleeping, and measuring it.

Back in part 0 I said the reason for choosing RISC-V over a machine of my own design was that the compiler already exists. It was a promise I had not yet kept. Everything the core had run so far was assembly I wrote or generated for the tests.

This post is the first time a compiler’s output ran on it. It is also where the thing I built stops being a toy and starts being something you could write programs for.

RISC-V soft core 8: Sleeping, and measuring it

Mon, 19 Oct 2026 00:30:00 +1100

Sleeping, and measuring it

Part 8 of the RISC-V soft core series. Previously: One clock.

What should a processor do when it has nothing to do? The honest answer from the timing ladder in part 6 was: burn every clock. The final rung of that ladder sat in a loop of wfi and a jump back, and wfi was a no-op, so the CPU spun at full speed waiting for a timer that was not due.

RISC-V soft core 7: One clock

Mon, 19 Oct 2026 00:20:00 +1100

One clock, and why slow mode cannot do real time

Part 7 of the RISC-V soft core series. Previously: Time and interrupts.

For most of this project the core had two clocks. There was the board’s fast oscillator, which ran the UART, the display and the debouncers, and there was the CPU clock, which the front panel made by dividing the fast one and which it could stop, start and single step.

RISC-V soft core 6: Time and interrupts

Mon, 19 Oct 2026 00:15:00 +1100

Time and interrupts: a timer, some buttons, and the press that got lost

Part 6 of the RISC-V soft core series. Previously: When it goes wrong on purpose.

A trap is the program’s own fault. An interrupt is the outside world getting the processor’s attention, and the outside world does not wait for a convenient moment. It is the same mechanism with a different cause: the core stops what it is doing, remembers where it was, runs a handler, and goes back.

RISC-V soft core 5: When it goes wrong on purpose

Mon, 19 Oct 2026 00:10:00 +1100

When it goes wrong on purpose: traps

Part 5 of the RISC-V soft core series. Previously: Talking to the world.

Up to now, if the core was handed an instruction it did not understand, it treated it as a nop and carried on. That is the worst possible answer. A program that goes wrong should stop and say so, and the rest of the machine should be able to decide what to do about it.

RISC-V soft core 4: Talking to the world

Mon, 19 Oct 2026 00:05:00 +1100

Talking to the world: loads, stores and a boot menu

Part 4 of the RISC-V soft core series. Previously: Harvard by accident, von Neumann by choice.

So far the core can add, branch, load, store and light some LEDs. It cannot tell me anything. For that it needs a way to talk, and RISC-V gives you a surprisingly short answer about how: it has no input and output instructions at all. There is no IN and no OUT, as on an x86. The way you reach a device is the way you reach memory, with a load or a store to a particular address.

RISC-V soft core 3: Harvard by accident, von Neumann by choice

Sun, 18 Oct 2026 19:00:00 +1100

Harvard by accident, von Neumann by choice, and a store that runs the old word once

Part 3 of the RISC-V soft core series. Previously: Tests that can fail.

I was reading the memory map when I asked a question that sounds too simple to matter: so the map contains no ROM?

It did not. The map described the data side of the core, a block of RAM and a UART. The program lived somewhere else entirely, in a ROM on its own bus, addressed by the program counter. Loads and stores could not reach it. Instruction address 0 was a different place from data address 0.

RISC-V soft core 2: Tests that can fail

Sun, 18 Oct 2026 18:00:00 +1100

Tests that can fail, and a RAM that was never there

Part 2 of the RISC-V soft core series. Previously: A CPU you can watch.

A light that sweeps along a row of LEDs is a nice demo and a poor proof. It tells me that a handful of instructions work in one order. It says nothing about all the others, or about the edges of the ones I used. If this core is going to run real code I need to be able to trust it, and I need to know how much I can trust it.

RISC-V soft core 1: A CPU you can watch

Sun, 18 Oct 2026 16:00:00 +1100

A CPU you can watch, and a double beat that was not a pipeline

Part 1 of the RISC-V soft core series. Previously: Firmware.

Last time I said I wanted a processor I could watch think. This time we get one, from a blank page to a light that sweeps back and forth along a row of LEDs. The code below is from the first commit of the project. It has grown a lot since, but the shape is the same.

RISC-V soft core 0: Firmware

Sun, 18 Oct 2026 14:00:00 +1100

Firmware, “You keep using that word. I do not think it means what you think it means”

Part 0 of a series on building a RISC-V processor from scratch on an FPGA. Next: a CPU you can watch.

My job title has the word firmware in it, and so do most of the job ads I see that look like mine. If you read those ads, what they want is C and C++ on a microcontroller or a small microprocessor: bring up the board, write the drivers, talk to the peripherals, make it not fall over in the field. Additionally some RTOS, embedded Linux and build system expertise.