The DIY Mark I CPU

One of my lab courses focused on building a sequence of group projects with ever increasing complexity. Most of them ended up being games with a focus on an FPGA development board, a serial connection, and some custom software running on a desktop computer. The individual projects that have stuck around in my mind are:

The whole sequence of projects started out with a GAL+discrete logic based assignment. We were tasked with building up a system for a standard 4 way intersection with an set of pedestrian crossings and associated pedestrian crossing request button.

We had lookup tables in the GAL, counters, timers, logic to decode our state into which lights were on, binary to 7 segment decoder chips, etc. It was a lot. As you might be able to see what we might have needed the most was some more rigor in terms of our wiring job, but we managed to complete the task. The project was a combination of loosely planning things and organically patching any mistakes we had made while watching the system through a logic squid. It was remarkable how much physical devices slowed down development.

The subsequent projects took us one step back from 80s style of physically building out logic into the era of defining our systems in a hardware description language, namely VHDL. This sped things up considerably, though the tooling available to students was subpar at the time (or at least that was the case at my university), so I wanted to make another technological leap and move into software. That required us to have a CPU of some sort and the assignments were always about turning in the hardware description of a system, so it couldn’t be imported from an external project like OpenCores. I knew from my tinkering in open source software that the later projects would be either take less time or be more fun with a basic CPU that could be reused from project to project, so I set off and made one. Certainly it was creating something bespoke with no online resources, but at the time resources for VHDL were *sparse*.

The classes focused around state machines, so how much harder could it be to build up a programmable state machine? A computer or in our case a very very terrible minimal computer was born. The CPU itself was copied between projects with near zero changes and just enough custom peripherals were created per assignment to get the system over the finish line.

As mentioned before, the CPU was thoroughly an 8-bit system, 8-bit addressable memory, 8-bit program ROMS, 8-bit operands, and four 8-bit or less registers. Those registers were:

SR stored system flags such as the is-equal flag, the is-zero flag, and other application specific flags. REG is used to for general loading from memory, arithmetic operations, comparisons, and temporary storage. IDX is used for stack management, indirect memory access, and iteration. PC is used to track the current position in the system ROM, which determines the current instruction; In other systems this is referred to as an Instruction Pointer (IP).

Our instruction set can be summarized below:

R(ead), W(rite), .(nothing), V(alue), Ar(Address/RAM), Ap(Address/Program), ALU (PC-IDX-REG) i(ncrement ALU), d(ecrement ALU), F(ull ALU)

In total these 22 opcodes were in the final VHDL version of the CPU that I was able to locate (technically 23, but lspt and sidx are identical). No opcode encoding work was done, that was left to the VHDL generation tools, but opcodes could easily be 8 bits to fit with the overall theme of the project.

One challenge of working with this instruction set was that relative jumps are not in the instruction set which means that a list of destination addresses needed to be maintained. Most code modifications were painful if it shifted code by even one address, so the Mark I CPU even has an assembler, but I’ll get to that a bit later.

As mentioned before, the processor does not have relative jumps which makes program modifications tedious if we don’t have an assembler. The assembler itself is pretty trivial with most of the point being tracking the addresses of assembled instructions. In fact almost all of the meaningful bits of it can be seen in these yacc/lex snippets:

A program consists of a sequence of statements. Those statements are either labels for code to jump to, opcodes with optional arguments, definitions of constants, or definitions of functions which are printed as comments in the generated code. Easy enough for something as low level as an assembler, right?

So, what does a real program look like? Well, let’s look at a slightly modified assembly project. Before looking at the code this is from the project where a collection of analog values are read from an external chip, then transmitted over a serial connection to be displayed on a PC.

To start off, let’s look at some constants:

In this program the CPU has a few system peripherals:

In addition the stack that is used to store data which is sent to the PC is 0x21..0xF0, which should correspond to 103 8 bit values (in hex) and a null terminator.

In addition, there is a set of comments that indicate that the UART is connected to the CPU’s control line 0 to signal when data can be sent.

The beginning of the program initializes the array/stack which is used to store data which will be transmitted and then it establishes the main program flow. inputs are collected, the input is output to the computer, the system waits, and then it repeats the process.

Ignore the no-operation instructions here, but as the comments indicate data is read from the ADC peripheral. The data is converted into two bytes of hex-ascii (e.g. 0xfa), then stored on the stack. At the end we check to see if the stack pointer is at its maximal value with the test instruction and if it is at that value we go to the next stage, otherwise we keep gathering more input.

Now with output we’re getting to point we have something more complex. In the first 3 instructions we establish that we have a null terminated string starting at the constant address STACKP. We now want to send this string byte by byte to the UART. This is done by the send_loop. When a character is sent we have to wait for the UART to be ready for the next byte at which point we stay in the wait loop until the control line 0 indicates we can send the next character. When we do send the data it is moved from the TMP_SEND address to the UART_TX memory mapped device and we repeat the process until the full string has been sent.

Rewritten in C this looks like:

The delay routine is the last one it counts from 0 to 256 (more or less) and we can calculate how long this should take to execute. The processor runs at 50MHz with one instruction per cycle, one loop is 4 instructions (add+2x no-op+branch). So, 256*4+1+1 (for the initial load and final goto), so roughly 20 micro-seconds. Not much time at all.

The processor had its fair share of quirks and general limitations. While this is by no means a comprehensive list a few that were pain points at the time:

It’s pretty amazing looking back at the specs for the DE1 board. Those boards are still sold, but an updated revision. The newer revision is a heck of a lot more powerful than they used to be. Reading the spec sheet of the individual FPGA on my board I’ve got 18,752 logic elements and the new FPGA simply specifies 77k logic elements which gives me the sense that students aren’t running into those situations where they’ve exhausted every single logic unit on one of these boards while doing classwork. The newer board don’t even need the effort of building a custom CPU since they’ve got a built in ARM core. Heck, the ARM core has access to a full GB of RAM, which is remarkable compared to the 8MB of SDRAM on my board and the 256 bytes of address space of the Mark I CPU.

The Mark I CPU worked, it did its job and while I haven’t accomplished my personal goal of making a CPU from raw transistors it got me a decent part of the way there. If I do go all the way to transistors I’m guessing I’ll go down to 4 bits or have the pcb fab assemble the ocean of transistors. Overall it’s a fun space and simple instruction sets are really interesting. I don’t play around with them as much as I used to, but it is a delight to read through ISRs like the z80 or AVR. There’s a beauty to them that is lost in the pragmatic full instruction sets you see in x86 and arm.

So, I’ll leave this article here for now. I may well get back to it and edit it some more or extend it, but this has been sitting in my drafts folder long enough that I should put it up on my website before it collects another layer of dust.