Created: Jan 25, 2011
Updated: Jun 11, 2015
SVN Updated: Jan 15, 2014
Other project properties
Development status: Mature
WishBone Compliant: No
This project is in the middle of a major refactor, being conducted in a new GitHub repository . The refactor involves rewriting from scratch the most intractably messy parts of the RTL (the cache and memory controller and parts of the CPU), going to a 4-stage pipeline, implementing Wishbone as the main bus interface, implementing a generic COP2 interface and a few other changes. The aim is to make the core actually useable. In particular, the CPU monitor in the TB is being rewritten from scratch, as the current version is just too unmaintainable. Eventually the project will be backported here. ETA is around the end of Summer 2015. In short, I wouldn't recommend paying much attention to version of the core...
This is a MIPS-I compatible CPU, aiming at compatibility with IDT’s R3000 MIPS derivative.
|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).|
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!
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 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 :)
Synthesis ResultsThese 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.
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.