The worlds smallest 32 bit CPU with GCC toolchain

This CPU is finding a new home at www.opencores.org, please contact me if you are willing and able to help in shaping up the www.opencores.org pages.

The HDL, GCC toolchain and eCos HAL are actually done. Mainly I could need a hand with writing up docs/web pages/examples/bug reports.

The ZPU has a BSD license for the HDL and GPL for the rest(source files are sadly out of date here, patches gladly accepted!). This allows deployments to implement any version of the ZPU they want without running into commercial problems, but if improvements are done to the architecture as such, then they need to be contributed back.

One strength of the ZPU is that it is tiny and therefore easy to implement from scratch to suit specialized needs and optimizations.

Getting started - FPGA

You'll find a working simulation script in hdl/example/simzpu_small.do and hdl/example_medium/simzpu_medium.do, which show simulation of the small(zpu_core_small.vhd) and medium sized ZPU(zpu_core.vhd). hdl/example/simzpu_interrupt.do shows use of interrupts.

When implementing the ZPU, copy the following files and modify them to your needs:

1. hdl/example/zpu_config.vhd - set up RAM size here
2. hdl/example/helloworld.vhd - dual port BRAM implementation.

Generating VHDL BRAM initialization

Build another test application for example simulation

cd zpu/roadshow/roadshow/dhrystone
sh build.sh
cd zpu/hdl/example
gcc zpuromgen.c
$ ./a
Usage: ./a binary_file
./a ../../roadshow/roadshow/dhrystone/dhrystone.bin >app.txt

Copy and paste app.txt into helloworld.vhd.

Running example simulation

1. cd c:/<installfolder>/hdl/example
2. do zpusim_small.do

After running the hello world simulation (see zpusim.do), two files are written to the hdl/example directory:

1. log.txt - contains the "Hello world!" text written to the debug channel/simplified UART.
2. trace.txt - a trace file for the CPU. The instruction set simulator has the capability of taking this file as input in order to verify that the HDL implementation matches the instruction set simulator. When a mismatch is found, the GDB debugger will break. Very handy for debugging custom ZPU implementations.

HDL Directories & files

• example - contains example files & working ZPU. Start here.
• wishbone - contains wishbone interface for the ZPU
• zpu3 - if you are interested in developing ZPU cores and not only using them, then this directory contains various stuff of more or less historical interest.
• zpu4 - if you are interested in developing ZPU cores and not only using them, then this is the active development version. You'll also want to copy out the files you need from this folder to your own project.

Getting started - software

Installing

1. Install Cygwin. http://www.cygwin.com
2. Install Java
3. Start Cygwin bash
4. cd zpu/sw
5. sh setup.sh
6. /tmp/zpu/install/bin now has the .exe files for the GCC toolchain & GDB
7. Optionally you may set up PATH variables to point to /tmp/zpu/install/bin
   source env.sh

Hello world example

cd zpu/sw/helloworld
../install/bin/zpu-elf-gcc -phi hello.c -o hello.elf


Running the hello world example in GDB

1. cd zpu/sw/helloworld
2. Launch the simulator from a seperate bash shell:

   java -classpath ../simulator/zpusim.jar -Xmx512m com.zylin.zpu.simulator.Phi 4444

   

3. Launch GDB:

   ../install/bin/zpu-elf-gdb hello.elf

4. Connect to target, load and run application:

   (gdb) target remote localhost:4444
(gdb) load
(gdb) continue


   

Architecture introduction

Example:

The choice of opcodes is intimately tied to the GCC toolchain capabilities.

Instruction set

Custom startup code (aka crt0.s)

Implementing a ZPU can be done without understanding the toolchain in detail, i.e. using exclusively HDL skills and only a rudimentary understanding of standard GCC/GDB usage is sufficient.

A few tips:

• Run zpu_core.vhd or zpu_core_small.vhd and generate an instruction trace from ModelSim or similar. To check that you own implementation is correctly implemented, verify that the instruction trace for the new and old ZPU implementations match. This gives you a simple way to do regression tests as you develop your ZPU.
• To improve performance, you can add more instructions. The EMULATE instructions are optional in HDL since they will be emulated in software if they are not implemented in HDL. This allows you to run the ZPU executables unmodified regardless of which EMULATE instructions you implement.
• Run the DMIPS test to measure your overall performance
• Run the histogram.perl script on the instruction trace to generate histograms of the instructions. Profiling is essential to making the right choices w.r.t. optimisation for your application.

Vectors

Phi memory map

Interrupts

To trigger an interrupt, the interrupt signal must be asserted. The ZPU does not define any interrupt disabling mechanism, this must be implemented by the interrupt controller and controlled via memory mapped IO.

Interrupts are masked when the IDIM flag is set, i.e. with consequtive IM instructions.

The ZPU has an edge triggered interrupt. As the ZPU notices that the interrupt is asserted, it will execute the interrupt instruction. The interrupt signal must stay asserted until the ZPU acknowledges it.

When the interrupt instruction is executed, the PC will be pushed onto the stack and the PC will be set to the interrupt vector address (0x20).

Note that the GCC compiler requires three registers r0,r1,r2,r3 for some rather uncommon operations. These 32 registers are mapped to memory locations 0x0, 0x4, 0x8, 0xc. The default interrupt vector at address 0x20 will load the value of these memory locations onto the stack, call _zpu_interrupt and restore them.

It uses a BRAM (dual port RAM w/read/write to both ports) as data & code storage and is implemented as a simple state machine.

Essentially it has three states:

1. Fetch - starts fetch of next instruction
2. FetchNext - sets up operands for execute cycle
3. Decode - decodes instruction
4. Execute - well.. executes instruction

Speeding up the ZPU

Performance tips

1. Profile. Create a small sample and run in a simulator that is as close to the real deployment as possible. zpu4/core/histogram.perl is a script that will tell you which instructions take the most time.
2. Using the profile output, decide on which emulated instructions that it makes sense to implement in HDL for your particular application. Modifying zpu_core_small.vhd is not particularly hard. Most instructions can be transliterated into zpu_core_small.vhd from zpu_core.vhd without too much problem.
3. The memory subsystem may well turn out to be where you should concentrate your efforts.

Toying around with the architecture

• There is a DMIPS program you can use to measure the performance of the ZPU in lieu of profiling a real application. The latter is obviously a superior solution.
• Again: use histogram.perl to figure out which instructions you should add in HDL.
• Tinker a bit with Fmax to find the maximum speed rating for your design.
• zpu_core_small.vhd should be ca. 1 DMIPS and zpu_core.vhd should yield about 5-10 DMIPS before adding instructions runs out of steam.

Achieving above 50-100 DMIPS with the current ZPU architecture is probably a non-starter and a more conventional RISC design makes more sense here.

The point is that characters(bytes) are sent to/from the ZPU via some terminal.

The ZPU defines in the memory map a UART / debug channel. This should be implemented by some suitable debug channel for the device in which the ZPU is implemented.

It performs better(despite having less memory bandwidth than zpu_core_small.vhd) since it implements many more instructions.

Compiling hello world program with the ZPU GCC toolchain

Installation

1. Install Cygwin. http://www.cygwin.com
2. Start Cygwin bash
3. unzip zputoolchain.zip
4. Add install/bin from zputoolchain.zip to PATH.
   export PATH=$PATH:/install/bin

Hello world example

Fast-READ only implementation.

32-bit only access

Fast sequential read access - Uses low-clock approach

Version

Timing overview

Simple timing overview, with one nonsequential access to address 0x0, followed by a sequential access to address 0x4. This simulation was done with Xilinx tools, after post-routing, and using a ZPU to access the SPI

Zealot: Implementing in FPGAs

1. Since the ZPU GCC toolchain supports standard ANSI C, it is easy to stumble across functionality that takes up a lot of space. E.g. the standard printf() function is a beast. Some compilers drop e.g. floating point support from the printf() function and thus boast a "smaller" printf() when in fact they have a non-standard printf(). newlib has a standard printf() function and an alternative iprintf() function that works only on integers.
2. The ZPU ships with default startup code that works across various configurations of the ZPU, so be warned that there is some overhead that will not occurr in the final application(anywhere between 1-4kBytes).
3. Compilation and linker options matter. The ZPU benefits greatly from the "-Wl,--relax -Wl,--gc-sections" options which is not used by all architectures(e.g. GCC ARM does not implement/need -Wl,--relax).

Small code example

Even smaller code example

Compiling eCos tests

Code size ZPU

Code size ARM (non-thumb)

The plan is to update zpu_core.vhd and zpu_core_small.vhd as examples/reference, and to open up for innovation in the HDL implementation.

Download source code

The simplest way to get the ZPU HDL source and tools is to check it out from CVS:

cvs -d :pserver:anonymous@cvs.opencores.org:/cvsroot/anonymous co zpu/zpu

Start by reading zpu/zpu/hdl/index.html

Creating a patch

Getting help - mailing list