Loading repository data…
Loading repository data…
Johnlon / repository
Home Brew 8 Bit CPU Hardware Implementation including a Verilog simulation, an assembler, a "C" Compiler and this repo also contains my research and learning. See also the Hackaday.IO project. https://hackaday.io/project/166922-spam-1-8-bit-cpu
A transparent discovery signal based on current public GitHub metadata.
This score does not audit code, security, maintainers, documentation quality, or suitability. Verify the repository and its current documentation before adoption.
An 8 bit home brew CPU built using 1970's logic chips.
This project is currently in it's 3rd incarnation.
Status: May 2022 - this project is still live but I've been spending a bunch of time trying to port one or other C compiler to SPAM-1. Tried LLVM and it's too hard and wasted a lot of time. Currently having a lot more success with VBCC. My own SpamCC language and compiler is cool but there is something special about being able to compile and use other people's code! I also have Gamepad input hardware almost integrated but that's held up by the compiler work.
VBCC port : https://github.com/Johnlon/spam-1-vbcc/tree/main/demo contains example test programs.
I'm currently working on what I hope is the final version.
This version has a 48 bit instruction word spread across 6 ROM's. It's 48 bit instruction is read in a single clock cycle to avoid having to introduce instruction registers and complex decoding logic, plus one instruction per clock cycle is faster than fetching a multibyte instruction from 8 bit memory.
The other big change is that I've included a bunch of features that are intended for exploration and learning such as including different design patterns for registers including common 8 bit flipflops for some registers plus a 74HCT670 based register file for other registers, and also by having 5 buses!
See Previous Versions of the architecture.
A bit of fun!
I started working life in 1986 as a hardware engineer but quickly switched to software. As a teenager I'd been fascinated with discrete electronics and then later on with integrated circuits and built many little home projects; nothing too exciting as we didn't have the resources (ie ££) back then.
Recently, like many other folk, I came across Ben Eater's series of YT videos and also videos of quite a few others that inspired me to have a go at building my own CPU. Back in 1980 even the relatively few parts needed would probably have been beyond my means, but not anymore !!
However, back in the 1980's I would have been building more or less blind. I still don't have an oscilloscope but what I do have is a Verilog simulator. (Update 2020: bought a 2 channel oscilloscope, a Siglent "SDS1102CML+" Dual-Channel Bench Oscilloscope 100 MHz for £283 inc VAT and delivery)
Back at the start of this project I spent a few weeks getting to know Logisim Evolution and having spent hours trying to figure out the fine details of my simulated processor it's clear that if I had attempted to build a CPU back in 1980 then I'd have fallen flat on my face. It's been a great learning experience, if frustrating at times.
So I've decided to build an 8 bit CPU for myself, for the sheer joy and nostalgia, sweat and tears (almost literally).
Gradually, I've extended the design extensively and have chosen to simulate the whole thing in Verilog (thanks to advice from Warren Toomey) using accurate propagation delays to hopefully tease out timing errors (I don't own an oscilloscope!).
Leaning verilog and reworking most of the design has taken months, but as of June 2020, I've finalised the verilog and will have a go at writing various programs to prove out the design and test it's capabilities.
:star: In the very early stage of my learning I wrote an assembler in Google Sheets. I was looking to see what could be done without installing tools python or perl or whatever first!
However, further development of the design really required more powerful tooling such as Icarus Verilog as well as Scala/Python after all.
My development environment is still pretty accessible as I use Windows 10 running the Windows Subsystem for Linux. So I have a full Linux environment without the need to install a virtualisation software like VirtualBox and it all just works very sweet. The integration between Windows 10 and WSL is brilliant, and I use the same environment for all opensource coding I do these days. I wish I could use it at work frankly.
I will at some point do a video on setting up the tooling as it's generally useful I feel and shouldn't put folk off trying this kind of thing themselves. I use VSCode for the verilog development and documentation because VSCode has free plugins for Verilog. I use IntelliJ professionally, but the verilog plugins for intelliJ are commercial only so no thanks to that. I'll include the VSCode setup in whatever video I do and I'll probably write it up here and/or in the Hackaday project.
Five Single buses
8 bits data
16 8 bits address
48 24 16 bit instruction
8 bit ALU - full complement of arithmetic and logical ops (approx 32) and magnitude comparisons
Harvard style separate RAM and program ROM (for no particular reason - could have been all RAM or a single address space)
Fetch/Decode on one edge of clock and Execute on the other.
Uses a horizontal microcode style of instructions. I like the idea of this scheme, as it's rather like a mechanical music box.
Registers
Addressing modes are:
All instructions have the same form T = A ALUOP B, for example MARHI = REGA + REGB.
So the entire instruction set is phrased around moving data from device to device and all data transfers go via the ALU.
Therefore, this isn't any of the usual accumulator or stack or register based arch (As far as I understand them) because
ALU operations can involve registers or any RAM location or an immediate value from the ROM.
I'm not sure what class of device that makes this. Again, it's not strictly load/store either as the RAM and ROM values can be used directly in all ops.
Even jumps follow the same form as al other instructions eg PC = REGA + $23
All instructions are conditional using a scheme similar to the ARM processors.
Therefore, there is no need for specialised conditional jump instructions, and a conditional jump is simply a conditional assignment to the Program Counter.
The Assembler for a jump that is conditional on Carry having been set could be PC = REGC + REGD _C where the '_C' signals which flag must be set for the operation to execute..
This is a Harvard stye of CPU.
Any instruction may be made conditional on the state of one of the processor status flags. This allows for some convenient programming patterns and allows for more symmetry, which appeals to me. The conditions include all of the ALU status flag outputs but also the UART ready for RX and TX flags.
All operations go via the ALU.
In the diagram below you can see the ALU has two input busses labelled A and B (but L and R in older docs) that provides the two operands to the ALU and additionally a carry-in status flag. The ALU input busses each carry a value from one of the devices in the CPU and the output of the ALU is looped back to the writable devices in the CPU.
The instruction must also encode the particular ALU operation that will be used, the address mode and condition control.
The instruction can apply a 16 bit address directly to the RAM so that a given instruction can either read or write and RAM address in each operation.
Alternatively the pair of MARLO and MARHI registers can be loaded with a 16 bit RAM address which for example is useful for indexing into arrays, allowing a read or write at that location.
The addressing modes also include the ability to apply an 8 but immediate value to the ALU "B" bus on any operation.
This is not a microcoded arch. See BTW my thoughts on microcode.
The earliest design for SPAM1 used Horizonal Microcoding with a distinct control line directly from the program ROM to each device, with no multiplexing or decode logic at all. This design had three 8 bit wide ROM's for the program memory, giving 24 potential individual control lines (or 2x8 control lines plus 8 bits immediate, or 8 bits control and 16 bits immediate depending on what I wanted to achieve). I didn't know the name for such an architecture but I have since found this pattern is known as Horizontal microcoding
I felt at the time that using three ROM's for the program memory was excessive and moved to a model whereby I had two ROM's instead. Well that lasted to about 5 minutes.
The final design has an instruction that is 48 bits wide. The program is stored in ROM and is 48 bits, organised over six 8 bit ROMs.
Every instruction is of the form T = A OP B [optional control flag] . BTW If you are interested in the original design of this instruction set arch then see the Original Design Branch.
The instruction encodes the source and target devices, the ALU operation, the addressing mode, the optional immediate value and direct address, plus the condition flags as shown below.
The devices on the ALU input busees A and B, as well as the devices on the ALU result bus are identified using the id's shown below.
Breadbo