Introduction

The worlds smallest 32 bit CPU with GCC toolchain.

The ZPU is a small CPU in two ways: it takes up very little resources and the architecture itself is small. The latter can be important when learning about CPU architectures and implementing variations of the ZPU where aspects of CPU design is examined. In academia students can learn VHDL, CPU architecture in general and complete exercises in the course of a year.

The current ZPU instruction set and architecture has not changed for the last couple of years and can be considered quite stable. There is a lot of discussion about various modifications to the ZPU architecture in the zylin-zpu mailing list, but currently no actual modifications are planned as the improvements that have been identified are relatively slight(<30% performance/size improvement).

There are a handful of implementations of the ZPU. Most of these usually have some strong points and there is some movement in the direction of consolidating improvements into a few officially recommended ZPU implementations.

For those that are interested in the Zylin ZPU, I recommend joining up on the zylin-zpu mailing list and participating in the discussion there. The zylin-zpu is a friendly place where people of different skills, hardware, software, tools meet to exchange ideas about the ZPU and microprocessor architecture in general.

Sincerely,

Øyvind Harboe
Zylin AS

License

The project includes HDL, GCC toolchain and eCos HAL.

The ZPU has a BSD license for the HDL and GPL for the rest. This allows users to implement any version of the ZPU they want in commercial products, but if improvements are done to the architecture as such, then they need to be contributed back.

Per Jan 1. 2008, Zylin has the Copyright for the ZPU, i.e. Zylin is free to decide that the ZPU shall have a BSD license for HDL + GPL for the rest.

Features

Status

• HDL works
• GCC toolchain works
• eCos HAL works

Architecture

Example:

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

Instruction set

A base set of instructions must be implemented in RTL, but the rest may be implemented as RTL or as microcode. This allows a tradeoff of core size vs code size and performance.

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

Core Implementations

zpu4 medium

Zealot

ZY2000

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. optimization for your application.

Reference Designs

TODO converge on a single IO structure for core implementations.

TODO re-org CVS to make it easy to keep appropriate SW, RTL(verilog and VHDL) , scripts, verification stuff together.

TODO provide FPGA scripts.

TODO provide FPGA scripts.

Common - RAM models

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.

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

Working with the tools and core

Xilinx ISE webpack is available for windows and linux
Altera Quartus web edition is windows only.
Lattice ispLEVER starter edition is windows only.

None appear to come with a standalone simulator anymore. Not sure if any built in simulators are worth looking at... never have been in the past.

Popular Simulation tools for this kind of project: Modelsim, GHDL, veriwell, cver, icarus, gtkwave... others?

TODO setup.sh script needs to detect linux/cygwin, and should have install path option.

$ cd zpu/zpu/sw     # path as appropriate
$ sh setup.sh       # untars the tool chain to ... TODO
$ . env.sh          # puts the tools in you path

Setup - Cygwin toolchain

GCC to RAM

The instructions are stored big endian. That is the first instruction is stored in the most significant byte, and the forth is in the least significant byte.

Generating VHDL BRAM initialization

$ zpu-elf-objcopy -O binary hello.elf hello.bin
$ java -classpath ../simulator/zpusim.jar com.zylin.zpu.simulator.tools.MakeRam hello.bin >hello.bram

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

TODO need to merge following with above.

The ZPU comes with a standard GCC toolchain and an instruction set simulator. This allows compiling, running & debugging simple test programs. The Simulator has some very basic peripherals defined: counter, timer interrupt and a debug output port.

Hello world example

$ cd zpu/sw/helloworld
$ zpu-elf-gcc -Os -phi hello.c -o hello.elf -Wl,--relax -Wl,--gc-sections
or ? TODO which one
$ zpu-elf-gcc -phi hello.c -o hello.elf 
$ zpu-elf-size hello.elf

HDL simulation (ZPU4)

For new users you will also find scripts in the zealot area that may be useful.

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.

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.

GDB simulation

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
   
   

   

Simulator

The ZPU simulator is integrated into the Zylin Embedded CDT plugin to ease debugging of ZPU applications:

Misc

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.

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 occur 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

$ zpu-elf-size *
   text    data     bss     dec     hex filename
  15761    1504   12060   29325    728d bin_sem0
  16907    1512   14436   32855    8057 bin_sem1
  17105    1524   30032   48661    be15 bin_sem2
  17186    1512   14436   33134    816e bin_sem3
  18986    1500   12036   32522    7f0a clock0
  15812    1504   13236   30552    7758 clock1
  25095    1972   13224   40291    9d63 clockcnv
  16437    1500   13224   31161    79b9 clocktruth
  15762    1504   12060   29326    728e cnt_sem0
  17124    1512   14436   33072    8130 cnt_sem1
  35947    1564   22512   60023    ea77 dhrystone
  16428    1500   13228   31156    79b4 except1
  15751    1504   12052   29307    727b flag0
  19145    1512   15624   36281    8db9 flag1
  20053    1516  102908  124477   1e63d fptest
  15998    1496   12092   29586    7392 intr0
  16080    1496   12200   29776    7450 kalarm0
  15327    1496   12036   28859    70bb kcache1
  15549    1496   13224   30269    763d kcache2
  18291    1500   12260   32051    7d33 kclock0
  16231    1500   13232   30963    78f3 kclock1
  16572    1496   13228   31296    7a40 kexcept1
  15618    1496   12060   29174    71f6 kflag0
  19287    1500   15624   36411    8e3b kflag1
  16887    1516   15628   34031    84ef kill
  16186    1496   12128   29810    7472 kintr0
  19724    1504   14516   35744    8ba0 klock
  18283    1500   14592   34375    8647 kmbox1
  15539    1496   12064   29099    71ab kmutex0
  16524    1504   15664   33692    839c kmutex1
  18272    1712   20348   40332    9d8c kmutex3
  18682    1608   20352   40642    9ec2 kmutex4
  15619    1496   14412   31527    7b27 ksched1
  15567    1496   12060   29123    71c3 ksem0
  17063    1500   14436   32999    80e7 ksem1
  15504    1496   13228   30228    7614 kthread0
  16167    1496   14412   32075    7d4b kthread1
  18281    1512   14580   34373    8645 mbox1
  20611    1508   14940   37059    90c3 mqueue1
  15672    1504   12064   29240    7238 mutex0
  16678    1516   15664   33858    8442 mutex1
  17694    1508   16868   36070    8ce6 mutex2
  18203    1720   20344   40267    9d4b mutex3
  16352    1508   14428   32288    7e20 release
  15890    1500   14412   31802    7c3a sched1
  44196    1612  286332  332140   5116c stress_threads
  17891    1524   16864   36279    8db7 sync2
  16943    1512   15644   34099    8533 sync3
  15467    1496   13064   30027    754b thread0
  16134    1496   14420   32050    7d32 thread1
  17560    1512   15636   34708    8794 thread2
  16279    1500   24028   41807    a34f thread_gdb
  17051    1504   20376   38931    9813 timeslice
  17146    1504   21564   40214    9d16 timeslice2
  37313    1512  422380  461205   70995 tm_basic

Code size ARM (non-thumb)

$ arm-elf-size *
   text    data     bss     dec     hex filename
  25204     692   16976   42872    a778 bin_sem0
  26644     700   22096   49440    c120 bin_sem1
  26996     712   55584   83292   1455c bin_sem2
  27008     700   22100   49808    c290 bin_sem3
  28992     688   16944   46624    b620 clock0
  25456     692   19532   45680    b270 clock1
  34572    1160   19520   55252    d7d4 clockcnv
  26224     688   19508   46420    b554 clocktruth
  25204     692   16976   42872    a778 cnt_sem0
  26888     700   22108   49696    c220 cnt_sem1
  44180     752   27416   72348   11a9c dhrystone
  26088     688   19520   46296    b4d8 except1
  25236     692   16968   42896    a790 flag0
  29532     700   24668   54900    d674 flag1
  29508     704  109652  139864   22258 fptest
  25932     684   17016   43632    aa70 intr0
  25824     684   17112   43620    aa64 kalarm0
  24728     684   16956   42368    a580 kcache1
  25168     684   19512   45364    b134 kcache2
  28112     688   17168   45968    b390 kclock0
  25976     688   19524   46188    b46c kclock1
  26372     684   19512   46568    b5e8 kexcept1
  25140     684   16968   42792    a728 kflag0
  29824     688   24660   55172    d784 kflag1
  26896     704   24656   52256    cc20 kill
  26088     684   17028   43800    ab18 kintr0
  30812     692   22176   53680    d1b0 klock
  28504     688   22260   51452    c8fc kmbox1
  24984     684   16984   42652    a69c kmutex0
  26504     692   24704   51900    cabc kmutex1
  28792     900   34892   64584    fc48 kmutex3
  29264     796   34896   64956    fdbc kmutex4
  25240     684   22084   48008    bb88 ksched1
  25044     684   16968   42696    a6c8 ksem0
  26988     688   22100   49776    c270 ksem1
  25028     684   19512   45224    b0a8 kthread0
  25996     684   22080   48760    be78 kthread1
  28552     700   22252   51504    c930 mbox1
  31324     696   22612   54632    d568 mqueue1
  25108     692   16980   42780    a71c mutex0
  26464     704   24700   51868    ca9c mutex1
  27624     696   27280   55600    d930 mutex2
  28596     908   34884   64388    fb84 mutex3
  26156     696   22100   48952    bf38 release
  25460     688   22084   48232    bc68 sched1
  56356     828   45892  103076   192a4 stress_threads
  27900     712   27288   55900    da5c sync2
  26760     700   24692   52152    cbb8 sync3
  24924     684   19356   44964    afa4 thread0
  25868     684   22084   48636    bdfc thread1
  27452     700   24680   52832    ce60 thread2
  26136     688   42704   69528   10f98 thread_gdb
  27212     692   34916   62820    f564 timeslice
  52728     700  123332  176760   2b278 tm_basic

Phi memory map

The ZPU architecture does not define a memory map as such, but the GCC + libgloss + ecos hal library uses the memory map below. "Phi" is just a three letter word for the particular memory layout below that came about while developing the ZPU.

Address	Type	Name	Description
0x080A0000	Write	ZPU enable	Bit [31:1] Not used Bit [0] Enable ZPU operations 0 ZPU is held in Idle mode 1 ZPU running
0x080A0004	Read/ Write	GPIO data	Bit [31:0] input data 31:0 Bit [31:0] output data 31:0
0x080A0008	Read/ Write	GPIO direction	Bit [31:0] data direction 31:0 0 output 1 input (default)
0x080A000C	Read/ Write	ZPU Debug channel / UART to ARM7 TX NOTE! ZPU side	Bit [31:9] Not used Bit [8] TX buffer ready (valid on ready) 0 TX buffer not ready (full) 1 TX buffer ready Bit [7:0] TX byte (valid on write)
0x080A0010	Read	ZPU Debug channel / UART to ARM7 RX NOTE! ZPU side	Bit [31:9] Not used Bit [8] RX buffer data valid 0 RX buffer not valid 1 RX buffer valid Bit [7:0] RX byte (when valid)
0x080A0014	Read/ Write	Counter(1)	Bit [0] Reset counter (valid for write) 0 N/A 1 Reset counter Bit [1] Sample counter (valid for write) 0 N/A 1 Sample counter Bit [31:0] Counter bit 31:0
0x080A0018	Read	Counter(2)	Bit [31:0] Counter bit 63:32
0x080A0020	Read / Write	Global_Interrupt_mask	Bit [31:1] Not used Bit [0] Global intr. Mask 0 Interrupts enabled 1 Interrupts disabled
0x080A0024	Write	UART_INTERRUPT_ENABLE	Bit [31:1] Not used Bit [0] Debug channel / UART RX interrupt enable 0 Interrupt disable 1 Interrupt enable
0x080A0028	Read Write	UART_interrupt	Bit [31:1] Not used Bit [0] Debug channel / UART RX interrupt pending (Read) 0 No interrupt pending 1 Interrupt pending Bit [0] Clear UART interrupt (Write) 0 N/A 1 Interrupt cleared
0x080A002C	Write	Timer_Interrupt_enable	Bit [31:1] Not used Bit [0] Timer interrupt enable 0 Interrupt disable 1 Interrupt enable
0x080A0030	Read / Write	Timer_interrupt	Bit [31:2] Not used Bit [0] Timer interrupt pending (Read) 0 No interrupt pending 1 Interrupt pending Bit [1] Reset Timer counter (Write) 0 N/A 1 Timer counter reset Bit [0] Clear Timer interrupt (Write) 0 N/A 1 Interrupt cleared
0x080A0034	Write	Timer_Period	Bit [31:0] Interrupt period (write) Number of clock cycles between timer interrupts NOTE! The timer will start at Timer_Periode value and count down to zero, and generate an interrupt
.0x080A0038	Read	Timer_Counter	Bit [31:0] Timer counter (read)

TODO

TODO list

Repository Re-org

zpu/bin         # scripts and toolchain?  Want toolchain installed with project.  Tidier when working in multi user / multi project environment
zpu/doc         # 
zpu/core/rtl    # RTL for the various core implementations.
zpu/core/sw     # crt0.s ?
zpu/common/rtl  # Re-use RTL such as RAM and UART
zpu/common/sim  # Re-use RTL and tools for regresion testing
zpu/common/sw   # ?
zpu/soc/minimal # Three levels of ref designs described above
       /basic 
       /board
zpu/soc/*/rtl   # top level, arbiter, etc
zpu/soc/*/sw    # helloworld, dmips, etc. makefile/ROMS
zpu/soc/*/sim   # regression test area. makefile/scripts
zpu/soc/*/fpga  # syn and par area. makefile/scripts
zpu/tools       # zip/tarball of tool chains, simulator

Next generation ZPU

Goals

1. Reduce minimum code size footprint, i.e. BRAM code overhead. Non-trivial usable applications in 4kBytes of BRAM (single BRAM block).
2. Reduce minimum FPGA logic footprint by 20% or more. Goal <300 LUT for 32 bit ZPU
3. Weed out unnecessary ZPU variations and merge in useful features to a few recommeneded ZPU implementations.
4. Will someone be willing to contribute a heavily pipelined ZPU? Performance goal of 10 DMIPS w/DRAM & cache. This ZPU could run a TCP/IP stack with relevant performance to compete with stripped down ARM7 type systems.

GCC changes

1. Add options that allow defining single entry for all unknown instructions. Precisely how unknown instructions are handled will be defined by the HDL implementation. Currently the GCC backend places relatively strict limitations on how unknown/emulated instructions are handled. This will allow HDL implementations to have sparser instruction set support. Also this can allow sparse implementations of emualted instructions. This is especially important to reduce minimal BRAM requirements for small applications.
2. GCC needs 4 "hard" registers. These are today mapped to memory. GCC will allow specifying what address to use or alternatively not to use memory mapped hard registers at all.
3. Strip away unused instructions from GCC and add options to GCC for not emitting more advanced instructions. This will e.g. convert MULT/DIV into function calls to libgcc and thus make it easier to determine that microcode is not needed.

Floating point support

Such control loops can be written in fixed point math, but that adds to the engineering effort and reduces clarity of the software implementation and the performance will probably be worse than for a hardware floating point version.

Pipelined floating point module

• 32 bit single precision floating point
• FADD => add two floats
• FMULT => multiply two floats
• FINT => convert float to int

1. One top level VHDL module for each of the operations above.
2. Integration into ZPU's are a separate problem that will not be addressed in this project.
3. add a memory mapped coprocessor interface to the above. This yields an example of a coprocessor which can be used for any custom calculations and allows interest to be gauged.

1. pipelined design where throughput is one operation per cycle with a fixed number of cycles delay.
2. there is no flow control or enable signal.

VHDL module interface