Fpga 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.

Simulator 4: The tick that was 25 times too fast

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

The tick that was 25 times too fast, and a simulator that found it by accident

Part 4 of the simulator thread. Previously: A second opinion. The other thread is the RISC-V soft core series.

By the time I had two simulators I thought I had the design well covered. The Alchitry simulator ran the Lucid, and Yosys ran the Verilog, and I had checked them against a model and against each other. Then I ran a third one, for fun, and it found something neither of them could.

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.

Simulator 3: A second opinion

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

A second opinion, and a mutation that failed for the wrong reason

Part 3 of the simulator thread. Previously: A simulator that lies. The other thread is the RISC-V soft core series.

If the main simulator is a sample and not a verdict, I need a second one. Not a copy of the first, which would share its faults, but a simulator that gets things wrong in different places, or not at all.

Simulator 2: A simulator that lies

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

A simulator that lies, and a mutation that should not have failed

Part 2 of the simulator thread. Previously: Why the IDE simulates at 284 Hz. The other thread is the RISC-V soft core series.

In part 2 of the CPU series I said to break your design on purpose and watch the right test fail. This is the story of a break where the test failed and my reasoning said it should not have.

Simulator 1: Why the IDE simulates at 284 Hz

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

284 clocks a second, and the wrong place to look

Part 1 of the simulator thread. Previously: The simulator I use. The other thread is the RISC-V soft core series.

The IDE’s board view has a little readout in the corner. It said Running at 284 Hz, in red, because it wanted 1 kHz and could not get there. The board’s clock was 100 MHz, so the simulator was running the design more than three hundred thousand times slower than the real thing, and the Larson scanner crawled across the LEDs.

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.

Simulator 0: The simulator I use

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

The simulator I use, with the lid off

Part 0 of a second thread alongside the RISC-V soft core series. It runs in parallel: the CPU posts say what the machine does, these say how I watch it.

Series: RISC-V soft core and Simulator. Part 0 of the simulator thread, so no previous part. The first CPU post is A CPU you can watch.

The RISC-V posts show a lot of pictures of an FPGA board. None of them are the board yet. They are a simulator, and since I keep leaning on it I should say what it is, what is mine, and what is not.

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.