Ion - MIPS(tm) compatible CPU

WARNING

This project is has been canceled after years of neglect. It has been cloned in a new GitHub repository and any further development, if there is any, will happen there. This one will remain frozen as long as OpenCores allows me to keep it.

The CPU as it stands is not complete, lacking some important features (see 'Status' section below). The RTL is too messy and poorly documented to warrant further development without a serious refactor. I don't think it's a good starting point for any new project and don't encourage branching.

Also, if you are checking this out as a potential employer, I suggest you look instead at the GitHub version (which is far cleaner even if it is unfinished) and my other pet projects.

Overview

This is a MIPS-I compatible CPU, aiming at compatibility with IDT’s R3000 MIPS derivative.

Key features:

1.	Binary compatible to R3000 series of CPUs.
2.	Kernel/user mode operation as per the architecture definition.
3.	Exception handling compatible to MIPS-I standard.
4.	4KB direct-mapped code cache.
5.	4KB direct-mapped, writethrough data cache.
6.	Simplified CP0, mostly compatible to R3000.
7.	All unimplemented opcodes trigger the proper traps.
8.	Includes minimalistic memory handler with interfaces for external SRAM (or FLASH) on 8- and 16-bit data bus.
9.	Size and speed comparable to other free MIPS cores.
10.	Fully synchronous (rising clock edge only). No latches.
11.	Source HDL is fully vendor independent (Only tested on Xilinx and Altera synthesis tools).

This project inherits heavily from Steve Rhoads' Plasma, though it is not meant as a replacement or improvement -- the name of this project attempts to convey that idea.
Besides using Plasma as a benchmark and model, I have used parts of Plasma in this project. This includes the multiplier/divider unit and the software simulator, both of which have been extensively modified -- details are covered in the source comments and the documentation.


Please see the included documentation (/doc/ion_project.pdf) for a more detailed explaination of the core features and its current status.


The project ships with a few demos, including a port of Adventure for a bare-metal system and a SD card bootloader.


While this project may eventually produce a useful MIPS CPU core, and is not bad in area and clock rate performance, the real reason I took all this trouble is that it's lots of fun :)

Important:

While the core can already run almost any arbitrary code, it is not mature enough to be of any immediate use in real-life applications. If you are looking for a mature, well supported and well tested MIPS core, you need to look elsewhere.
There's already quite a few MIPS cores out there to choose from, including some in OpenCores.

Feedback:

Though I don't expect this core to be used at all at this early stage, you can contact me with any doubt and/or correction. Bear in mind that neither the source code nor the documentation have ever been reviewed -- all criticism and feedback is welcome!

Status

The core is still a work in progress. The main missing features are these, in order of priority:

1.	Real documentation (specs doc & data sheet) missing.
2.	Logic is too messy, specially the cache-cpu interface. It needs a refactor.
3.	Hardware interrupts not implemented.
4.	Memory handler does not support dynamic RAM.
5.	Integration with MIPS toolchains is poor -- cannot yet use a standard libc.
6.	Caches are not configurable or parametrizable.

I have found much more trouble than I expected setting up a toolchain for this core. All the MIPS toolchains generally available (and, most importantly, all the libc libraries) target the MIPS32 architecture.
I have been able to temporarily overcome this problem by emulating the most common mips32-only opcodes (in trap routines) but clearly I need to set up a proper toolchain if this project is to be of any practical use. I may have painted myself into a corner by choosing the mips-I architecture...

Another thing holding me back is the lack of a suitable FPGA platform for development (one with sufficient memory, for instance).

In short, this being a leisure project, I will complete the work as time permits. Don't hold your breath :)

Performance

Synthesis Results

These are the synthesis results for the current revision of the core using Altera and Xilinx tools:

Device	Synthesis Options	Clock Rate	Area (excluding memory blocks)
Altera Cyclone-2 (-7)	Balanced	50 MHz	2349 LEs
Xilinx Spartan-3 (-5)	Speed	51 MHz	3173 LUTs	Xilinx Virtex-5 (-1)	Speed	104 MHz	2017 LUTs

These results include the CPU core with its default cache and a small, hardwired UART. They have been obtained with Quartus-2 11.1 sp2 and Xilinx ISE WebPack 14.3. The synthesis has been performed unconstrained and the results must be considered illustrative only.


I haven't yet ported any standard benchmark but anyway the system is not geared towards performance (the cache in particular is too simple) so speed results will not be outstanding.

Updates

Last 'known good' revision is rev. 242.

With 'known good' I mean it has been checked out and all the code samples have been simulated and run on real hardware.

I use to commit changes piecemeal, so any given revision may contain inconsistent files. You are advised to checkout the last known good revision of the project through SVN, instead of using the download link. Just in case you catch me in the middle of a multi-commit update.

Revision 250 has been tried on the development board but not verified on simulation.

Revisions:

November 15 2012 -- rev. 250

Added a new demo, a bootloader that can load a binary from the DE-1 SD card onto RAM and run it from there. Already tested with a new version of the Adventure demo (precompiled binary included).
There is also a port of Elm-Chan's FAT32 library, modified to work on a bit-banged interface.
And a new link script meant for applications that run from RAM at address 0x0. The only demo using it right now is Adventure, that can now be compiled to run from flash of from RAM via the SD card.

November 15 2012 -- rev. 242

Fixed an erratic behavior detected in the 'Hello World' demo: sometimes, the system crashed immediately after reset.
The problem has been traced to a corner condition in the cache-cpu interface logic that is briefly explained in the bugtracker page.

The fix involves a minor change in the I-Cache logic interfacing the CPU: the CPU will not load its IR with a code word from the cache unless it knows the code word is valid, which will only happen after the first code refill (the first after a reset).

Also fixed a few loose ends: the test bench had not been updated for some of the latest changes in the mini-SoC, so the simulation has been broken for I don't know how long...
Anyway, the logic is way too messy and could use some refactoring.

June 20 2012 -- rev. 231

Created new SoC entity built around the CPU and a hardwired UART. Good enough as a demonstration platform.
This SoC module replaces an earlier MCU module which was similar but more complex and difficult to set up.
Added new tool for VHDL package generation, used to configure the simulation and the synthesis, including the initialization of the simulated and inferred memories. This new tool is now used in all software samples.

These changes have entailed some major reorganization of the code; this revision has been checked out and tested but if you encounter any trouble, please revert to revision 214!

Note: A long list of updates, dating back to the start of the project, used to be present in this page but was lost in a page editing accident as of revision 231. For details on earlier revisions please refer to the SVN logs.