Zip Cpu

Description

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:

• A 32-bit CPU: All registers are 32-bits, addresses are 32-bits, instructions are 32-bits wide, etc.
• A RISC CPU. There is no microcode for executing instructions.
• A Load/Store architecture. (Only load and store instructions can access memory.)
• Wishbone compliant. All peripherals are accessed just like memory across this bus.
• A Von-Neumann architecture. (The instructions and data share a common bus.)
• A pipelined architecture, having stages for Prefetch, Decode, Read-Operand, Execute, and Write-back. The Execute stage is implemented by one of four blocks: an arithmetic/logic unit, a memory unit, a divide coprocessor and a floating point coprocessor (once completed). The last two blocks, the divide and floating point, will always be optional. There inclusion will be chosen based upon your implementation needs.

* 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.

Current Status

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.

Performance

I have a couple of performance measures to offer at this time. The first is that, in practice, this CPU can execute 0.4 instructions per clock in its test set. Of course, this is somewhat dependent upon the code that the CPU is executing, so your mileage may vary. Currently, memory issues prevent the ZipCPU from actually achieving one instruction per clock--but with the prefetch cache it can come close. As a second performance measure, a project exists here on OpenCores that fits the ZipCPU into a Spartan LX-4, albeit at a speed penalty. Of course, you might not find yourself needing all of these LUTs. As a third reference point, I am running it on a Basys-3 board hosting an Artix-7(35T) running at a 100 MHz clock, and on a XuLA2-LX25 board with an 80 MHz clock. Hopefully these measures are good enough for you. If not, why not build it and try it yourself?

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.

Packaged flavors

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!

Why build a custom CPU?

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.

GitHub

Due to the recent struggles to access OpenCores, the ZipCPU project is now also being hosted on GitHub. You may find that the GitHub release is more up to date than the version here in SVN on OpenCores.