The original goal of the ZIP CPU was to be a very simple CPU. You might think of it as a poor man's alternative to the OpenRISC architecture. For this reason, all instructions have been designed to be as simple as possible, they all work on 32--bit operands, and all of the ALU instructions are designed to be executed in one instruction cycle per instruction, barring pipeline stalls.* This has resulted in the choice to drop push and pop instructions, pre-increment, post-decrement and indexed addressing modes, and more.
In bare bullet form, the Zip CPU is:
* The Multiply instruction now takes 2 clocks. The divide instruction(s) take about 33 clocks, and the floating point instructions (when finally implemented) will also take more than 1 clock.
The ZipCPU now has GCC support! This means that you'll find a port here of both GCC and binutils sufficient to write non-floating point code with the ZipCPU. (The floating point emulation library has not yet been built, and I haven't built the floating point co-processor ... yet.)
20160413 Update: The ZipCPU is now running a minimal operating system. This includes pre-emptive multitasking, interrupt processing, and more. In particular, there is a test application running four tasks on the CPU: one user program in this operating system processes the GPS NMEA stream from a Digilent GPS module connected to a Basys-3 development board. Another user program processes mouse interaction, and sends characters to a serial port display process. This latter process unpacks the bytes sent to it, and sends them one by one over a SPI port to control a two-line LCD display. (The Basys board code is not currently part of any Open project, sadly enough ... although with enough sweetener I might be convinced to change that ...) The last user task is perhaps better characterized as a system task, but it is the idle task that just shuts down the CPU when not in use.
The "O/S", if you choose to encourage me by calling it that, has since been posted within the CMod-S6 SoC project. There you can see the basics of some pieces of an O/S, although it doesn't include any memory (or device) protections. Still, for less than 3k lines of code, it'd be a worthy endeavor to take a peek at.
20161206 Update: GCC support has now been upgraded to GCC 6.2.0.
20170211 Update: The ZipCPU on GitHub now has a branch that supports 8-bit bytes. GCC Compiler and assembler modifications have been made, and the new core currently runs newlib and hello world in simulation. Currently working on getting newlib running on hardware.
20161206 Update: Several performance measures were presented as part of ORCONF 2016. The presentation is now found in the documents directory, and on video on youtube.
As created, the Zip CPU has no peripherals. It is simply a set of pipeline stages implementing a CPU. Options exist to remove much of the pipeline logic, the prefetch cache, the divide or floating point units, which put together can either make the CPU fit in very small places, or equivalently make the CPU very fast, all dependent upon your needs.
Because the CPU alone is so very bare, the Zip CPU ships with a minimalist set of peripherals, which when put together become the Zip System. Still, the ZipSystem is not designed to be a System on a Chip (SoC), but rather a System within a Chip (SwiC). Thus, should you wish to make a complete system from the ZipSystem, you will probably still wish to add other peripherals such as a UART, clock, memory controller, or more (not included). While these might be included with the ZipCPU, we expect that you will wish to tailor your CPU to your environment, especially if you are looking for a small and simple CPU.
Some users, such as those trying to keep and maintain a minimal FPGA footprint, may not wish to have all of the extra baggage found in the Zip System. Perhaps they only wish to have some (or none) of these peripherals, and wish to handle the bus interconnect themselves. For these interested parties a bare version of just the Zip Bones is available. We have used this approach successfully to place the Zip CPU into some very small FPGA's.
Of course, given the RTL availability under the GPL, you are more than welcome to build and try out your own interface to the Zip CPU if you so choose!
Many people have asked me why I am building the Zip CPU. ARM processors are good and effective. Xilinx makes and markets Microblaze, Altera Nios, and both have better toolsets than the Zip CPU will ever have. OpenRISC is also available, RISC-V is arguably better and may be replacing it. Why build a new processor?
The easiest, most obvious answer is the simple one: Because I can.
There's more to it, though. There's a lot that I would like to do with a processor, and I want to be able to do it in a vendor independent fashion. I would like to be able to generate Verilog code that can run equivalently on both Xilinx and Altera chips, and that can be easily ported from one manufacturer's chipsets to another. Even more, before purchasing a chip or a board, I would like to know that my soft core works. I would like to build a test bench to test components with, and Verilator is my chosen test bench. This forces me to use all Verilog, and it prevents me from using any proprietary cores. For this reason, Microblaze and Nios are out of the question.
Why not OpenRISC? That's a hard question. The OpenRISC team has done some wonderful work on an amazing processor, and I'll have to admit that I am envious of what they've accomplished. The OpenRISC processor, however, is complex and hefty at about 4,500 LUTs. It has a lot of features of modern CPUs within it that ... well, let's just say it's not the little guy on the block. The Zip CPU is designed to be lighter weight, costing only about 2,300 LUTs with no peripherals, and 3,200 LUTs with some very basic peripherals.
My final reason is that I'm building the Zip CPU as a learning experience. The Zip CPU has allowed me to learn a lot about how CPUs work on a very micro level. For the first time, I am beginning to understand many of the Computer Architecture lessons from years ago. Better still, and thanks to Dr. Sauerman's wonderful Embedded Operating System Book, I have even choose to apply these concepts towards building my own Operating System.
To summarize: Because I can, because it is open source, because it is light weight, and as an exercise in learning.