Lightweight 8080 compatible core

Status

The core has already executed some quite large pieces of original code in hardware, including the Microsoft Altair 4K Basic and some parts of CP/M. Interrupt response has been simulated and tested in real hardware.

Yet, that does not guarantee that there aren't any bugs left. The core is essentially finished but the project will remain in 'alpha' state until it passes an exhaustive functional test bench and/or it boots CP/M.

Development Log

Update, 3-30-2012:
Major reorganization in the VHDL part of the project.

The simulation test bench has been simplified for easier maintenance; the present version uses an auxiliary tool to build a VHDL constant from HEX object code files.
The source code for the test benches has been moved to a separate 'sw' directory and build batch files have been included for easier use.

A VHDL SoC has been added that may be useful as an usage example for the core or as the starting point for a real application. The core includes a new UART and an interrupt controller; the components are commented but otherwise are lacking documentation, something that will be fixed ASAP.

A specifications document for the CPU core, valid for both Verilog and VHDL versions, has been added.

Update, 3-16-2012:
Moti Litochevski has kindly contributed a Verilog version of the core. The Verilog version comes complete with a number of support modules, including an UART and an interrupt controller, which have been integrated into a SoC.

Moti has also contributed a port of the Small C compiler tailored to this core, together with support tools (assembler, object code to verilog conversion script, etc.).

These new developments warrant a reorganization of the project, including improved documentation for a start. We will update the project contents and the project page as time permits. For the time being this brief note will have to suffice...

Update, 2-12-2012:
I have fixed a nasty bug in the logic instructions (XR*, AN*, OR*). They all should clear flags AC and CY but didn't. I fixed this behaviour for the XOR instructions years ago but failed to notice that it was a bug common to all logic instructions (Thanks to Moti Litochevski for the bug report!).
I have committed a general fix that does not increment the LUT count, by using one of the reserved microcode bits.
This bug, and the previous XOR one, have been so easy to fix that I didn't bother to add them to the bugtracker. Maybe I should have, otherwise the project will seem less buggy that it really is :)
I have modified the test bench to test the CY behavior, but the AC behavior remains unchecked. The project needs a real test bench.

Update, 7-10-2010:
I have put together a little Altair 4K Basic Demo, ready to run on a Cyclone-2 DE-1 board (pin declaration file included).
All you need to do is hook a terminal to the board (19200/8-N-1) and you'll be able to run a minimalistic Basic with floating point support. The Altair Basic documentation is not included but is widely available.
The demo includes only 4K bytes of internal FPGA RAM (initialized with the 4K basic code) and a serial port. It is not an emulation of the whole Altair, nor would it be a good starting point for one: all the demo files other than the CPU core are very rough and the resulting RTL is not as efficient as it might be.

But at least the Basic demo makes a good confidence-builder: I am now almost certain no bugs remain in the core :) Of course I can't be sure until I do a proper test bench, and thus the core remains in 'unfinished' state.

Since the demo only uses internal FPGA resources, an external clock input and a serial interface, it should be easily portable to other development boards. All the demo logic is clocked at 50MHz; if you change this you'll need to edit some parameters in the serial port source files too.


I have noticed that the microcode ALU operation encoding table in the documentation is wrong; the real values are those shown in the perl script. I plan to fix it as soon as I have a long enough stretch of spare time.


Update, 7-10-2010:
Bug fix: The XOR instructions were not updating the flags properly; I only caught this error while setting up the 4K basic demo, it slipped undetected by the main test bench and a lot of original code I've been running. The fix has increased the LUT count by 3 or 4 so the figures quoted above are no longer fully valid.


Update, 7-23-2009:
Interrupt response has been fixed, and the interrupt simulation test bench updated accordingly. The interrupt line has already been tested in hardware (used for single-stepping CP/M code).


Update, 8-18-2008:
A microcode bug has been found in INR M that the test bench (and other code I've been running on it) did not catch. I've just checked in a corrected version (Thanks to Tomasz Olszewski for the accurate bug report!). See the bug report in the tracker for the details. The project needs a much stronger test bench before upgrading to beta status.


Summary (8-28-2008):
The core has executed a functional test and some original code in hardware. Exhaustive tests, execution of large original software and interrupt response demo in hardware still to be done.


The core has passed a functional test, the 'Kelly Smith test', both in simulation and in hardware. Though the Kelly test is by no means exhaustive, I am now pretty confident that the design is sound and no big errors are going to show up (I do expect to find microcode bugs yet).

The Kelly Smith test is a 8080 CPU test created in 1980 which tests for most flags, modes and instructions (excludes i/o, interrupt response and does not test all postconditions of all instructions). Though it is not an exhaustive test, it is quite complete and has been an invaluable help in the development.

I have used the Kelly test version found in http://opencores.org/project,cpu8080 (Scott Moore's cpu8080 core site), slightly modified to fit my hardware set up. Besides, I have built a small simulation-only test bench (vhdl/test/light8080_tb0.vhdl) which includes the Kelly tests and can be used as a regression test of sorts.

The core has executed the kelly tests test code on two hardware incarnations: a Spartan 3 and a Cyclone 2, both at 50MHz (sources similar to simulation test bench, not included). In both cases they worked at first trial without glitches or funny behaviours. Yet, there was at least one hidden bug which I only detected after running the scs-1 monitor (a microcode bug).

I have been tinkering with the core a bit and there seems to be nothing wrong with it. Therefore I think I can put the project in 'alpha' status.