Subversion Repositories zipcpu

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

%%

%% Filename:    spec.tex

%%

%% Project:     ZipCPU -- a small, lightweight, RISC CPU soft core

%%

%% Purpose:     This LaTeX file contains all of the documentation/description

%%              currently provided with this ZipCPU soft core.  It supersedes

%%              any information about the instruction set or CPUs found

%%              elsewhere.  It's not nearly as interesting, though, as the PDF

%%              file it creates, so I'd recommend reading that before diving

%%              into this file.  You should be able to find the PDF file in

%%              the SVN distribution together with this PDF file and a copy of

%%              the GPL-3.0 license this file is distributed under.  If not,

%%              just type 'make' in the doc directory and it (should) build

%%              without a problem.

%%

%%

%% Creator:     Dan Gisselquist

%%              Gisselquist Technology, LLC

%%

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

%%

%% Copyright (C) 2015, Gisselquist Technology, LLC

%%

%% This program is free software (firmware): you can redistribute it and/or

%% modify it under the terms of  the GNU General Public License as published

%% by the Free Software Foundation, either version 3 of the License, or (at

%% your option) any later version.

%%

%% This program is distributed in the hope that it will be useful, but WITHOUT

%% ANY WARRANTY; without even the implied warranty of MERCHANTIBILITY or

%% FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License

%% for more details.

%%

%% You should have received a copy of the GNU General Public License along

%% with this program.  (It's in the $(ROOT)/doc directory, run make with no

%% target there if the PDF file isn't present.)  If not, see

%% <http://www.gnu.org/licenses/> for a copy.

%%

%% License:     GPL, v3, as defined and found on www.gnu.org,

%%              http://www.gnu.org/licenses/gpl.html

%%

%%

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

%

%

%

% From TI about DSPs vs FPGAs:

%       www.ti.com/general/docs/video/foldersGallery.tsp?bkg=gray

%       &gpn=35145&familyid=1622&keyMatch=DSP Breaktime Episode Three

%       &tisearch=Search-EN-Everything&DCMP=leadership

%       &HQS=ep-pro-dsp-leadership-problog-150518-v-en

%

%       FPGA's are annoyingly faster, cheaper, and not quite as power hungry

%       as they used to be.

%

%       Why would you choose DSPs over FPGAs?  If you care about size,

%       if you care about power, or happen to have a complicated algorithm

%       that just isn't simply doing the same thing over and over

%

%       For complex algorithms that change over time.  Each have their strengths

%       sometimes you can use both.

%

%       "No assembly required" -- TI tools all C programming, very GUI based

%       environment, very little optimization by hand ...

%

%

% The FPGA's Achille's heel: Reconfigurability.  It is very difficult, although

% I'm sure major vendors will tell you not impossible, to reconfigure an FPGA

% based upon the need to process time-sensitive data.  If you need one of two

% algorithms, both which will fit on the FPGA individually but not together,

% switching between them on the fly is next to impossible, whereas switching

% algorithm within a CPU is not difficult at all.  For example, imagine

% receiving a packet and needing to apply one of two data algorithms on the

% packet before sending it back out, and needing to do so fast.  If both

% algorithms don't fit in memory, where does the packet go when you need to

% swap one algorithm out for the other?  And what is the cost of that "context"

% swap?

%

%

\documentclass{gqtekspec}

\usepackage{import}

\usepackage{bytefield}  % Install via apt-get install texlive-science

% \graphicspath{{../gfx}}

\project{ZipCPU}

\title{Specification}

\author{Dan Gisselquist, Ph.D.}

\email{dgisselq (at) ieee.org}

\revision{Rev.~1.1}

\definecolor{webred}{rgb}{0.5,0,0}

\definecolor{webgreen}{rgb}{0,0.4,0}

\hypersetup{

        ps2pdf,

        pdfpagelabels,

        hypertexnames,

        pdfauthor={Dan Gisselquist},

        pdfsubject={ZipCPU},

        anchorcolor= black,

        colorlinks = true,

        linkcolor  = webred,

        citecolor  = webgreen

}

\begin{document}

\pagestyle{gqtekspecplain}

\titlepage

\begin{license}

Copyright (C) \theyear\today, Gisselquist Technology, LLC

This project is free software (firmware): you can redistribute it and/or

modify it under the terms of  the GNU General Public License as published

by the Free Software Foundation, either version 3 of the License, or (at

your option) any later version.

This program is distributed in the hope that it will be useful, but WITHOUT

ANY WARRANTY; without even the implied warranty of MERCHANTIBILITY or

FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License

for more details.

You should have received a copy of the GNU General Public License along

with this program.  If not, see \hbox{$<$http://www.gnu.org/licenses/$>$} for

a copy.

\end{license}

\begin{revisionhistory}

2.0 & 1/18/2017 & Gisselquist & Switched from 32--bit to 8--bit bytes.\\\hline

1.1 & 11/28/2016 & Gisselquist & Moved the ZipSystem address to {\tt 0xff000000} base.\\\hline

1.0 & 11/4/2016 & Gisselquist & Major rewrite,

                        includes compiler info\\\hline

0.91& 7/16/2016 & Gisselquist & Described three more CC bits\\\hline

0.9 & 4/20/2016 & Gisselquist & Modified ISA: LDIHI replaced with MPY,

        MPYU and MPYS replaced with MPYUHI, and MPYSHI respectively.  LOCK

        instruction now permits an intermediate ALU operation. \\\hline

0.8 & 1/28/2016 & Gisselquist & Reduced complexity early branching \\\hline

0.7 & 12/22/2015 & Gisselquist & New Instruction Set Architecture \\\hline

0.6 & 11/17/2015 & Gisselquist & Added graphics to illustrate pipeline discussion.\\\hline

0.5 & 9/29/2015 & Gisselquist & Added pipelined memory access discussion.\\\hline

0.4 & 9/19/2015 & Gisselquist & Added DMA controller, improved stall information, and self--assessment info.\\\hline

0.3 & 8/22/2015 & Gisselquist & First completed draft\\\hline

0.2 & 8/19/2015 & Gisselquist & Still Draft, more complete \\\hline

0.1 & 8/17/2015 & Gisselquist & Incomplete First Draft \\\hline

\end{revisionhistory}

% Revision History

% Table of Contents, named Contents

\tableofcontents

\listoffigures

\listoftables

\begin{preface}

Many people have asked me why I am building the ZipCPU. ARM processors are

good and effective.  Xilinx makes and markets Microblaze, Altera Nios, and both

have better toolsets than the ZipCPU will ever have. OpenRISC is also

available, RISC--V 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 of things that I would like to do with

a processor, and I want to be able to do them in a vendor independent fashion.

First, I would like to be able to place this processor inside an FPGA.  Without

paying royalties, ARM is out of the question.  I would then like to be able to

generate Verilog code, both for the processor and the system it sits within,

that can run equivalently on both Xilinx, Altera, and Lattice 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? Because the ZipCPU has different goals.  OpenRISC is designed

to be a full featured CPU.  The ZipCPU was designed to be a simple, resource

friendly, CPU.  The result is that it is easy to get a ZipCPU program running

on bare hardware for a special purpose application--such as what FPGAs were

designed for, but getting a full featured

Linux distribution running on the ZipCPU may just be beyond my grasp.  Further,

the OpenRISC ISA is very complex, defining over 200~instructions--even though

it has never been fully implemented.  The ZipCPU on the other hand has only

a small handful of instructions, and all but the Floating Point instructions

have already been fully implemented.

My final reason is that I'm building the ZipCPU as a learning experience. The

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

To summarize: Because I can, because it is open source, because it is light

weight, and as an exercise in learning.

\end{preface}

\chapter{Introduction}

\pagenumbering{arabic}

\setcounter{page}{1}

The goal of the ZipCPU was to be a very simple CPU.   You might think of it as

a poor man's alternative to the OpenRISC architecture.  You might also think of

it as an Open Source microcontroller.

For this reason, all instructions have been designed to be as simple as

possible, and the base instructions are all designed to be executed in one

instruction cycle per instruction, barring pipeline stalls.\footnote{The

exceptions to this rule are the multiply, divide, and load/store instructions.

Once the floating point unit is built, I anticipate these will also be

exceptions to this rule.}  Indeed, even the bus has been simplified to a

constant 32-bit width, with no option for more or less.  This has resulted in

the choice to drop push and pop instructions, pre-increment and post-decrement

addressing modes, the integrated memory management unit (MMU), and

more.\footnote{A not--so integrated MMU is currently under development.}

For those who like buzz words, the ZipCPU is:

\begin{itemize}

\item A 32-bit CPU: All registers are 32-bits, addresses are 32-bits,

                instructions are 32-bits wide, etc.

\item A RISC CPU.  There is no microcode for executing instructions.  All

        instructions are designed to be completed in one clock cycle.

\item A Load/Store architecture.  (Only load and store instructions

                can access memory.)

\item Wishbone compliant.  All peripherals are accessed just like

                memory across this bus.

\item A Von-Neumann architecture.  The instructions and data share a

                common bus.

\item A pipelined architecture, having stages for {\bf Prefetch},

        {\bf Decode}, {\bf Read-Operand}, a combined stage containing

        the {\bf ALU}, {\bf Memory}, {\bf Divide}, and {\bf Floating Point}

        units, and then the final {\bf Write-back} stage.

                See Fig.~\ref{fig:cpu}

\begin{figure}\begin{center}

\includegraphics[width=3.5in]{../gfx/cpu.eps}

\caption{ZipCPU internal pipeline architecture}\label{fig:cpu}

\end{center}\end{figure}

                for a diagram of this structure.

\item Completely open source, licensed under the GPL.\footnote{Should you

        need a copy of the ZipCPU licensed under other terms, please

        contact me.}

\end{itemize}

The ZipCPU also has one very unique feature: the ability to do pipelined loads

and stores.  This allows the CPU to access on-chip memory at one access per

clock, minus any stalls for the initial access.

\section{Characteristics of a SwiC}

This section might also be called {\em the ZipCPU philosophy}.  It discusses

the basis for the ZipCPU design decisions, and why a low logic count CPU

is or can be a good thing.

Many other FPGA processors have been defined to be good Systems on a Chip, or

SoC's.  The entire goal of such designs, then, is to provide an interface

to the processor and its external environment.  This is not the case with the

ZipCPU.  Instead, we shall define a new concept, that of a soft core internal to

an FPGA, as a ``System within a Chip,'' or a SwiC.  SwiCs have some very

unique properties internal to them that have influenced the design of the

ZipCPU.  Among these are the bus, memory, and available peripherals.

Many other approaches to soft core CPU's employ a Harvard architecture.

This allows these other CPU's to have two separate bus structures: one for the

program fetch, and the other for the memory.  Indeed, Xilinx's proprietary

Microblaze processor

goes so far as to support four busses: two for cacheable memory, and two for

peripherals, with each of those split between instructions and data.  The

ZipCPU on the other hand is fairly unique in its approach because it uses a

Von Neumann architecture, requiring only one bus within any FPGA.  This

structure was chosen for its simplicity.  Having only the one bus helps to

minimize real-estate, logic, and the number of wires that need to be passed

back and forth, while maintaining a high clock speed.  The disadvantage is

that both prefetch and memory access units need to contend for time on the

same bus.

Soft core's within an FPGA have an additional characteristic regarding

memory access: it is slow.  While memory on chip may be accessed at a single

cycle per access, small FPGA's often have only a limited amount of memory on

chip.  Going off chip, however, is expensive.  Two examples will prove this

point.  On

the XuLA2 board, Flash can be accessed at 128~cycles per 32--bit word,

or 64~cycles per subsequent word in a pipelined architecture.  Likewise, the

SDRAM chip on the XuLA2 board allows a 6~cycle access for a write, 10~cycles

per read, and 2~cycles for any subsequent pipelined access read or write.

Either way you look at it, this memory access will be slow and this doesn't

account for any logic delays should the bus implementation logic get

complicated.

As may be noticed from the above discussion about memory speed, a second

characteristic of memory is sequential memory accesses may be optimized for

minimal delays (pipelined), and that pipelined memory access is faster than

non--pipelined access.  Therefore, a SwiC soft core should support pipelined

operations, but it should also allow a higher priority subsystem to get access

to the bus (no starvation).

As a further characteristic of SwiC memory options, on-chip cache's are

expensive.  If you want to have a minimum of logic, cache logic may not be

the highest on the priority list.  Any SwiC capable processor must be able

to either be built without caches, or to scale up or down the logic required

by any cache.

In sum, memory is slow.  While one processor on one FPGA may be able to fill

its pipeline, the same processor on another FPGA may struggle to get more than

one instruction at a time into the pipeline.  Any SwiC must be able to deal

with both cases: fast and slow memories.

A final characteristic of SwiC's within FPGA's is the peripherals.

Specifically, FPGA's are highly reconfigurable.  Soft peripherals can easily

be created on chip to support the SwiC if necessary.  As an example, a simple

30-bit peripheral could easily support reversing 30-bit numbers: a read from

the peripheral returns its bit--reversed address.  This is cheap within an

FPGA, but expensive in instructions.  Reading from another 16--bit peripheral

might calculate a sine function, where the 16--bit address internal to the

peripheral was the angle of the sine wave.

Indeed, anything that must be done fast within an FPGA is likely to already

be done--elsewhere in the fabric.  Further, the application designer gets to

choose what tasks are so important they need fabric dedicated to them, and which

ones can be done more slowly in a CPU.  This leaves the CPU with the simple role

of solely handling sequential tasks, and tasks that need a lot of state.

This means that the SwiC needs to live within a very unique environment,

separate and different from the traditional SoC.  That isn't to say that a

SwiC cannot be turned into a SoC, just that this SwiC has not been designed

for that purpose.  Indeed, some of the best examples of the ZipCPU are

System on a Chip examples.

\section{Scope}\label{sec:limits}

The ZipCPU is itself nothing more than a CPU that can be placed within a

larger design.  It is not a System on a Chip, but it can be used to create

a system on a chip.  As a result, this document will not discuss more than a

small handful of CPU--related peripherals, as the actual peripherals used

within a design will vary from one design to the next.  Further, because

control access will vary from one environment to the next, this document will

not discuss any host control programs, leaving those to be discussed and defined

together with the environments the ZipCPU is placed within.

\chapter{CPU Architecture}\label{chap:arch}

This chapter describes the general architecture of the ZipCPU.  It first

discusses

the configuration options to the CPU and then breaks into two threads. These

last two threads are a discussion of the internals of the ZipCPU, such as its

instruction set architecture and the details and consequences of it, and then

the external architecture describing how the ZipCPU fits into the systems

surrounding it, and what those systems must do to support it.  Specifically,

the external architecture section will discuss both the ZipSystem, the

peripherals provided by it, as well as the debug interface.

\section{Build Options/defines}\label{ssec:build-options}

One problem with a simple goal such as being light on logic, is that some

architectures have some needs, others have other needs.  What is light logic

in some architectures might consume all the available logic in others.

As an example, the CMod~S6 board built by Digilent uses a very spare Xilinx

Spartan~6 LX4 FPGA.  This FPGA doesn't have enough look up tables (LUTs) to

support pipelined mode, whereas another project running on a XuLA2 LX25 board

made by Xess, having a Spartan~6 LX25 on board, has more than enough logic

to support a pipelined mode.   Very quickly it becomes clear that LUTs can be

traded for performance.

To make this possible, the ZipCPU has both a configuration file as well as a

set of parameters that it can be built with.  Often, those parameters can

override the configuration file, but not all configuration file changes can

be overridden.  Several options are available within the configuration file,

such as making the Zip CPU pipelined or not, able to handle a faster clock

with more stalls or a slower clock with no stalls, etc.

The {\tt cpudefs.v} file encapsulates those control options.  It contains a

series of {\tt `define} statements that can either be commented or left

active.  If active, the option is considered to be in effect.  The number of

LUTs the Zip CPU uses varies dramatically with the options defined in this file.

This section will outline the various configuration options captured by this

file.

The first couple of options control the Zip CPU instruction set, and how

it handles various instructions within the set:

{\tt OPT\_MULTIPLY} controls whether or not the multiply is built and included

in the ALU by default, and if it is which of several multiply options is

selected.  Unlike many of the defines that follow within {\tt cpudefs.v} that

are either defined or not, this option requires a value.  A value of zero means

no multiply support, whereas a value of one, two, or three, means that a

multiply will be included that takes one, two, or three clock cycles to

complete.  The option, however, only controls the default value that the

{\tt IMPLEMENT\_MPY} parameter to the CPU, having the same interpretation, is

given.  Because this is just the default value, it can easily be overridden

upon instantiation.  If the {\tt IMPLEMENT\_MPY} parameter is set to zero,

then any attempt to execute a multiply instruction will cause an illegal

instruction exception.

{\tt OPT\_DIVIDE} controls whether or not the divide instruction is built and

included into the ZipCPU by default.  Set this option and the

{\tt IMPLEMENT\_DIVIDE} parameter will have a default value of one, meaning that

unless it is overridden with zero, the divide unit will be included.    If the

divide is not included, then any attempt to use a divide instruction will

create an illegal instruction exception that will send the CPU into supervisor

mode.

{\tt OPT\_IMPLEMENT\_FPU} will (one day) control whether or not the floating

point unit (once I have one) is built and included into the ZipCPU by default.

This option sets the {\tt IMPLEMENT\_FPU} parameter to one, so alternatively

it can be set and adjusted upon instantiation.  If the floating point unit is

not included then, as with the multiply and divide, any floating point

instruction will result in an illegal instruction exception that will send the

CPU into supervisor mode.

{\tt OPT\_SINGLE\_FETCH} controls whether or not the prefetch has a cache, and

whether or not it can issue one instruction per clock.  When set, the

prefetch has no cache, and only one instruction is fetched at any given time.

This effectively sets the CPU so that only one instruction is ever

in the pipeline at a time, and hence you may think of this as a ``no

pipeline'' option.  However, since the pipeline uses so much area on the FPGA,

this is an important option to use in trimming down used logic if necessary.

Hence, it needs to be maintained for that purpose.  Be aware, though, setting

this option will disable all pipelining, and therefore will drop your

performance by a factor of 8x or even more.

I recommend only defining or enabling this option if you {\em need} to,

such as if area is tight and speed isn't as important.  Otherwise, leave the

option undefined since the pipelined options have a much better speed

performance.

The next several options are pipeline optimization options.  They make no

sense in a single instruction fetch mode, hence they are all disabled if

{\tt OPT\_SINGLE\_FETCH} is defined.

{\tt OPT\_PIPELINED} is the natural result and opposite of using the single

instruction fetch unit.  It is an internal parameter that doesn't need user

adjustment, but if you look through the {\tt cpudefs.v} file you may see

and notice it.  If you have not set the {\tt OPT\_SINGLE\_FETCH} parameter,

{\tt cpudefs.v} will set the {\tt OPT\_PIPELINED} option.  This is more for

readability than anything else, since {\tt OPT\_PIPELINED} makes more

intuitive readability sense than {\tt OPT\_SINGLE\_FETCH}.  In other words,

define or comment out {\tt OPT\_SINGLE\_FETCH}, and let {\tt OPT\_PIPELINED} be

taken care of automatically.

Assuming you have chosen not to define {\tt OPT\_SINGLE\_FETCH},

{\tt OPT\_TRADITIONAL\_PFCACHE} allows you to switch between one of two

prefetch cache modules.  If enabled (recommended), a more traditional cache

will be implemented in the CPU.  This more traditional cache reduces

the stall count tremendously over the alternative pipeline cache, and its

LUT usage is quite competitive.  As there is little downside to defining

this option if pipelining is enabled, I would recommend including it.

The alternative prefetch and cache, sometimes called the pipeline cache, tries

to read instructions ahead of where they are needed, while maintaining what it

has read in a cache.  That cache is cleared anytime you jump outside of its

window, and it often competes with the CPU for access to the bus.  These

two characteristics make this alternative bus often less than optimal.

{\tt OPT\_EARLY\_BRANCHING} is an attempt to execute a {\tt BRA} (branch or

jump) statement as early

in the pipeline as possible, to avoid as many pipeline stalls on a branch as

possible.  As an example, if you have {\tt OPT\_TRADITIONAL\_PFCACHE} defined

as well, then branches within the cache will only cost a single stall cycle.

Indeed, using early branching, a {\tt BRA} instruction can be used as the

compiler's branch prediction optimizer: {\tt BRA}'s barely stall, while

branches on conditions will always suffer about 6~stall cycles.  Setting

this option causes the parameter, {\tt EARLY\_BRANCHING}, to be set to one,

so it can be overridden upon instantiation.

Given the performance benefits achieved by early branching, setting this flag

is highly recommended.

{\tt OPT\_PIPELINED\_BUS\_ACCESS} controls whether or not memory

instructions can take advantage of the pipelined wishbone bus.  To be

eligible, the operations to be pipelined must be adjacent, must be all

loads or all stores, and the addresses must all use the same base

address register and either have identical immediate offsets, or immediate

offsets that increase by one for each instruction.  Further, the

string of load (or store) instructions must all have the same conditional

(if any).  Currently, this approach and benefit is most effectively used

when saving registers to or restoring registers from the stack at the

beginning/end of a procedure, when using assembly optimized programs, or

when doing a context swap.

I recommend setting this flag, for performance reasons, especially if your

wishbone bus implementation can handle pipelined bus accesses.  The logic

impact of this setting is minimal, the performance impact can be significant.

{\tt OPT\_CIS} includes within the instruction set the Very Long Instruction

Word packing, which packs up to two instructions within each instruction word.

Non--packed instructions will still execute as normal, this just enables the

decoding and running of packed instructions.

The two next options, {\tt INCLUDE\_DMA\_CONTROLLER} and

{\tt INCLUDE\_ACCOUNTING\_COUNTERS}

control whether the DMA controller is included in the ZipSystem, and

whether or not the eight accounting timers are also included.  Set these to

include the respective peripherals, comment them out not to.  These only

affect the ZipSystem implementation, and not any ZipBones implementations.

Finally, if you find yourself needing to debug the core and specifically

needing to get a trace from the core to find out why something specifically

failed, you may find it useful to define {\tt DEBUG\_SCOPE}.  This will add a

32--bit debug output from the core, as the last argument to the core, to the

ZipSystem, or even to ZipBones.  The actual definition and composition of

this debugging bit--field changes from one implementation to the next,

depending upon needs and necessities, so please look at the code at the

bottom of {\tt zipcpu.v} for more details.

That ends our discussion of CPU options, but there remain several

implementation parameters that can be defined with the CPU as well.  Some of

these, such as {\tt IMPLEMENT\_MPY}, {\tt IMPLEMENT\_DIVIDE},

{\tt IMPLEMENT\_FPU}, and {\tt EARLY\_BRANCHING} have already been discussed.

The remainder shall be discussed quickly here.

The {\tt RESET\_ADDRESS} parameter controls what address the CPU attempts to

fetch its first instruction from upon any CPU reset.  The default value is

not likely to be particularly useful, so overriding the default is recommended

for every implementation.

The {\tt ADDRESS\_WIDTH} parameter can be used to trim down the width of

addresses used by the CPU.  For example, although the Wishbone Bus definition

used by the CPU  has 30--address lines, particular implementations may have

fewer.  By setting this value to the actual number of wires in the address

bus, some logic can be spared within the CPU.  The default is also the maximum,

a 30--bit address width.  Two additional bits are used internally by the CPU

to create the appearance of an 8--bit bus, by using the wishbone select lines.

The {\tt LGICACHE} parameter specifies the log base two of the instruction

cache size.  If no instruction cache is used, this option has no effect.

Otherwise it sets the size of the instruction cache to be

$2^{\mbox{\tiny\tt LGICACHE}}$ words.  The traditional prefetch cache, if used,

will split this cache size into up to thirty two separate cache lines.

The {\tt IMPLEMENT\_LOCK} parameter controls whether or not the {\tt LOCK}

instruction is implemented.  If set to zero, the {\tt LOCK} instruction will

cause an illegal instruction exception, otherwise it will be implemented if

pipelining is enabled.

Other parameters are defined within the ZipSystem parent module, and affect

the performance of the system as a whole.

The {\tt START\_HALTED} parameter, if set to non--zero, will cause the

CPU to be halted upon startup.  This is useful for debugging, since it prevents

the CPU from doing anything without supervision.  Of course, once all pieces

of your design are in place and proven, you'll probably want to set this to

zero, so that the CPU will then start up immediately upon power up.

The {\tt EXTERNAL\_INTERRUPTS} parameter controls the number of interrupt

wires coming into the CPU.  This number must be between one and sixteen,

or if the performance counters are disabled, between one and twenty four.

\section{Internal Architecture}\label{sec:internals}

This section discusses the general architecture of the CPU itself, separated

from its environment.  As such, it focuses on the instruction set layout

and how those instructions are implemented.

\subsection{Register Set}

Fundamental to the understanding of the ZipCPU is its register set, and the

performance model associated with it.

The ZipCPU register set contains two sets of sixteen 32-bit registers, a

supervisor and a user set as shown in Fig.~\ref{fig:regset}.

\begin{figure}\begin{center}

\begin{tabular}{|c|c|c|c|c|}

\multicolumn{2}{c}{Supervisor Register Set} &

        \multicolumn{1}{c}{} &

        \multicolumn{2}{c}{User Register Set} \\

\multicolumn{2}{c}{\#'s 0-15} & \multicolumn{1}{c}{} &

        \multicolumn{2}{c}{\#'s 16-31} \\\hline\hline

sR0(LR) & sR8   && uR0(LR) &    uR8     \\\cline{1-2}\cline{4-5}

sR1     & sR9   && uR1  &       uR9     \\\cline{1-2}\cline{4-5}

sR2     & sR10  && uR2  &       uR10    \\\cline{1-2}\cline{4-5}

sR3     & sR11  && uR3  &       uR11    \\\cline{1-2}\cline{4-5}

sR4     & sR12(FP)&& uR4&       uR12(FP)\\\cline{1-2}\cline{4-5}

sR5     & sSP   && uR5  &       uSP     \\\cline{1-2}\cline{4-5}

sR6     & sCC   && uR6  &       uCC     \\\cline{1-2}\cline{4-5}

sR7     & sPC   && uR7  &       uPC     \\\hline\hline

\multicolumn{2}{c}{Interrupts Disabled} &

        \multicolumn{1}{c}{} &

        \multicolumn{2}{c}{Interrupts Enabled} \\

\end{tabular}

\caption{ZipCPU Register File}\label{fig:regset}

\end{center}\end{figure}

The supervisor set is used when interrupts are disabled, whereas the user set

is used any time interrupts are enabled.  This choice makes it easy to set up

a working context upon any interrupt, as the supervisor register set remains

what it was when interrupts were enabled.  This sets up one of two modes

the CPU can run within: a {\em supervisor mode}, which runs with interrupts

disabled using the supervisor register set, and {\em user mode}, which runs

with interrupts enabled using the user register set.

This separation is so fundamental to the CPU that it is impossible to enable

interrupts without switching to the user register set.   Further, on any

interrupt, exception, or trap, the CPU simply clears the pipeline and switches

instruction sets.

In each register set, the Program Counter (PC) is register 15, whereas

the status register (SR) or condition code register (CC) is register 14.  All

other registers are identical in their hardware functionality.\footnote{Jumps

to {\tt R0}, an instruction used to implement a return from a subroutine, may

be optimized in the future within the early branch logic.} By convention, the

stack pointer is register 13 and noted as (SP).  Beyond this convention,

word accesses to offsets of the stack pointer are compressed when using the

CIS instruction set.  Also by convention, if the compiler needs a frame

pointer it will be placed into register~12, and may be abbreviated by FP.

Finally, by convention, R0 will hold a subroutine's return address, sometimes

called the link register (LR).

When the CPU is in supervisor mode, instructions can access both register sets

via the {\tt MOV} instruction, whereas when the CPU is in user mode, {\tt MOV}

instructions will only offer access to user registers.  We'll discuss this

further in subsection.~\ref{sec:isa-mov}.

\subsection{The Status Register, CC}

The status register (CC) is special, and bears further mention.  As shown in

Fig.~\ref{tbl:cc-register},

\begin{table}\begin{center}

\begin{bitlist}

31\ldots 23 & R & Reserved for future uses\\\hline

22\ldots 16 & R/W & Reserved for future uses\\\hline

15 & R & Reserved for MMU exceptions\\\hline

14 & W & Clear I-Cache command, always reads zero\\\hline

13 & R & CIS instruction phase (1 for first half)\\\hline

12 & R & (Reserved for) Floating Point Exception\\\hline

11 & R & Division by Zero Exception\\\hline

10 & R & Bus-Error Flag\\\hline

9 & R & Trap Flag (or user interrupt).  Cleared on return to userspace.\\\hline

8 & R & Illegal Instruction Flag\\\hline

7 & R/W & Break--Enable (sCC), or user break (uCC)\\\hline

6 & R/W & Step\\\hline

5 & R/W & Global Interrupt Enable (GIE)\\\hline

4 & R/W & Sleep.  When GIE is also set, the CPU waits for an interrupt.\\\hline

3 & R/W & Overflow\\\hline

2 & R/W & Negative.  The sign bit was set as a result of the last ALU instruction.\\\hline

1 & R/W & Carry\\\hline

\end{bitlist}

\caption{Condition Code Register Bit Assignment}\label{tbl:cc-register}

\end{center}\end{table}

the lower sixteen bits of the status register form a set of CPU state and

condition codes.  The other bits are reserved for future uses.

Of the condition codes, the bottom four bits are the current flags:

                Zero (Z),

                Carry (C),

                Negative (N),

                and Overflow (V).

These flags maintain their usual definition from other CPUs that use them, for

all but the shift right instructions.  On those instructions that set the flags,

these flags will be set based upon the output of certain instructions.  If the

result is zero, the Z (zero) flag will be set.  If the high order bit is set,

the N (negative) flag will be set.  If the instruction caused a bit to fall off

the end, the carry bit will be set.  In comparisons, this is equivalent to a

less--than unsigned comparison.  Finally, if the instruction causes a signed

integer overflow, the V (overflow) flag will be set afterwards.

We'll walk through the next many bits of the status register in order from

least significant to most significant.

\begin{enumerate}

        \setcounter{enumi}{3}

\item The next bit is a sleep bit.  Set this bit to one to disable instruction

        execution and place the CPU to sleep, or to zero to keep the pipeline

        running.  Setting this bit will cause the CPU to wait for an interrupt

        (if interrupts are enabled), or to completely halt (if interrupts are

        disabled).  This leads to the {\tt WAIT} and {\tt HALT} opcodes

        which will be discussed more later.  In order to prevent users from

        halting the CPU, only the supervisor is allowed to both put the CPU to

        sleep and disable interrupts.  Any user attempt to do so will simply

        result in a switch to supervisor mode.

\item The sixth bit is a global interrupt enable bit (GIE).  This bit also

        forms the top, or fifth, bit of any register address.  When this

        sixth bit is a `1' interrupts will be enabled, else disabled.  When

        interrupts are disabled, the CPU will be in supervisor mode, otherwise

        it is in user mode.  Thus, to execute a context switch, one only

        need enable or disable interrupts.  (When an interrupt line goes

        high, interrupts will automatically be disabled, as the CPU goes

        and deals with its context switch.)  Special logic has been added to

        keep the user mode from setting the sleep register and clearing the

        GIE register at the same time, with clearing the GIE register taking

        precedence.

        Whenever read, the supervisor CC register will always have this bit

        cleared, whereas the user CC register will always have this bit set.

\item The seventh bit is a step bit in the user CC register, and zero in the

        supervisor CC director.  This bit can only be set from supervisor

        mode.  After setting this bit, should the supervisor mode process switch

        to user mode, it would then accomplish one instruction in user mode

        before returning to supervisor mode.  This bit has no effect

        on the CPU while in supervisor mode.

        This functionality was added to enable a userspace debugger

        functionality on a user process, working through supervisor mode

        of course.

        The CPU can be stepped in supervisor mode.  Doing so requires the

        CPU debug functionality, not the step bit.

\item The eighth bit is a break enable bit.  When applied to the supervisor CC

        register, this controls whether a break instruction in user mode will

        halt the processor for an external debugger (break enabled), or

        whether the break instruction will simply send send the CPU into

        interrupt mode.  This bit can only be set within supervisor mode.

        However, when applied to the user CC register, from supervisor mode,

        this bit will indicate whether or not the reason the CPU entered

        supervisor mode was from a break instruction or not.  This break

        reason bit is automatically cleared upon any transition to user mode,

        although it can also be cleared by the supervisor writing to the

        user CC register.

        Encountering a break in supervisor mode will halt the CPU independent

        of the break enable bit.

        This functionality was added to enable a debugger to set and manage

        breakpoints in a user mode process.

\item The ninth bit is an illegal instruction bit.  When the CPU tries to

        execute either a non-existent instruction, or an instruction from

        an address that produces a bus error, the CPU will (if implemented)

        switch to supervisor mode while setting this bit.  The bit will

        automatically be cleared upon any return to user mode.

\item The tenth bit is a trap bit.  It is set whenever the user requests a

        soft interrupt, and cleared on any return to userspace command.  This

        allows the supervisor, in supervisor mode, to determine whether it got

        to supervisor mode from a trap, from an external interrupt or both.

\item The eleventh bit is a bus error flag.  If the user program encountered

        a bus error, this bit will be set in the user CC register and the CPU

        will switch to supervisor mode.  The bit may be cleared by the

        supervisor, otherwise it is automatically cleared upon any return to

        user mode.  If the supervisor encounters a bus error, this bit will be

        set in the supervisor CC register and the CPU will halt.  In that

        case, either a CPU reset or a write to the supervisor CC register will

        clear this register.

\item The twelfth bit is a division by zero exception flag.  This operates

        in a fashion similar to the bus error flag.  If the user attempts

        to use the divide instruction with a zero denominator, the system

        will switch to supervisor mode and set this bit in the user CC

        register.  The bit is automatically cleared upon any return to user

        mode, although it can also be manually cleared by the supervisor.  In

        a similar fashion, if the supervisor attempts to execute a divide by

        zero, the CPU will halt and set the zero exception flag in the

        supervisor's CC register.  This will automatically be cleared upon any

        CPU reset, or it may be manually cleared by the external debugger

        writing to this register.

\item The thirteenth bit will operate in a similar fashion to both the bus

        error and division by zero flags, only it will be set upon a (yet to

        be determined) floating point error.

\item In the case of CIS instructions, if an exception occurs after the first

        instruction but before the second, the fourteenth bit of the CC

        register will be set to indicate this fact.  This can be combined with

        the user PC to the address of the half-word where the fault occurred.

\item The fifteenth bit references a clear cache bit.  The supervisor may

        write a one to this bit in order to clear the CPU instruction cache.

        The bit always reads as a zero.

\item Last, but not least, the sixteenth bit is reserved for a page not found

        memory exception to be created by the memory management unit.

\end{enumerate}

Some of the upper bits have been temporarily assigned to indicate CPU

capabilities.  This is not a permanent feature, as these upper bits officially

remain reserved.

\subsection{Instruction Format}\label{sec:isa-fmt}

All ZipCPU instructions fit in one of the formats shown in

Fig.~\ref{fig:iset-format}.

\begin{figure}\begin{center}

\begin{bytefield}[endianness=big]{32}

\bitheader{0-31}\\

\begin{leftwordgroup}{Standard}\bitbox{1}{0}\bitbox[tlr]{4}{}

                \bitbox[lrt]{5}{OpCode}

                \bitbox[lrt]{3}{}

                \bitbox{1}{0}

                \bitbox{18}{18-bit Signed Immediate} \\

\bitbox{1}{0}\bitbox[lr]{4}{DR}

                \bitbox[lrb]{5}{}

                \bitbox[lr]{3}{Cnd}

                \bitbox{1}{1}

                \bitbox{4}{BR}

                \bitbox{14}{14-bit Signed Immediate}\end{leftwordgroup} \\

\begin{leftwordgroup}{MOV}\bitbox{1}{0}\bitbox[lr]{4}{}

                \bitbox[lrt]{5}{5'hf}

                \bitbox[lrb]{3}{}

                \bitbox{1}{A}

                \bitbox{4}{BR}

                \bitbox{1}{B}

                \bitbox{13}{13-bit Signed Immediate}\end{leftwordgroup} \\

\begin{leftwordgroup}{LDI}\bitbox{1}{0}\bitbox[lrb]{4}{}

                \bitbox{4}{4'hc}

                \bitbox{23}{23-bit Signed Immediate}\end{leftwordgroup} \\

\begin{leftwordgroup}{NOOP}\bitbox{1}{0}\bitbox{3}{3'h7}

                \bitbox{1}{}

                \bitbox{2}{11}

                \bitbox{3}{xxx}

                \bitbox{22}{Ignored}

                \end{leftwordgroup} \\

\end{bytefield}

\caption{Zip Instruction Set Format}\label{fig:iset-format}

\end{center}\end{figure}

The basic format is that some operation, defined by the OpCode, is applied

if a condition, Cnd, is true in order to produce a result which is placed in

the destination register (DR).

There are three basic exceptions to this general instruction model.  The

first is the {\tt MOV} instruction, which steals bits~13 and~18

to allow supervisor access to user registers.  In supervisor mode, these

are set to one to reference user registers, zero otherwise.  They are ignored

in user mode.  The second exception is the load 23--bit

signed immediate instruction ({\tt LDI}), in that it accepts no conditions and

uses only a 4-bit opcode.  The last exception is the {\tt NOOP} instruction

group, containing the {\tt BREAK}, {\tt LOCK}, {\tt SIM}, and {\tt NOOP}

opcodes.  These instructions ignore their register and immediate settings.

Further, the immediate bits used by these opcodes are available for simulation

or debug facilities, but otherwise ignored by the CPU.

\subsection{Instruction OpCodes}\label{sec:isa-opcodes}

With a 5--bit opcode field, there are 32--possible instructions as shown in

Tbl.~\ref{tbl:iset-opcodes}.

\begin{table}\begin{center}

\begin{tabular}{|l|l|l|l|c|} \hline \rowcolor[gray]{0.85}

OpCode & & A-Reg & Instruction &Sets CC \\\hline\hline

5'h00 & {\tt SUB} & \multicolumn{2}{l|}{Subtract} &   \\\cline{1-4}

5'h01 & {\tt AND} & \multicolumn{2}{l|}{Bitwise And} &   \\\cline{1-4}

5'h02 & {\tt ADD} & \multicolumn{2}{l|}{Add two numbers} &   \\\cline{1-4}

5'h03 & {\tt OR}  & \multicolumn{2}{l|}{Bitwise Or} & Y \\\cline{1-4}

5'h04 & {\tt XOR} & \multicolumn{2}{l|}{Bitwise Exclusive Or} &   \\\cline{1-4}

5'h05 & {\tt LSR} & \multicolumn{2}{l|}{Logical Shift Right} &   \\\cline{1-4}

5'h06 & {\tt LSL} & \multicolumn{2}{l|}{Logical Shift Left} &   \\\cline{1-4}

5'h07 & {\tt ASR} & \multicolumn{2}{l|}{Arithmetic Shift Right} &   \\\hline

5'h08 & {\tt BREV} & \multicolumn{2}{l|}{Bit Reverse B operand into result}&  \\\cline{1-4}

5'h09 & {\tt LDILO} & \multicolumn{2}{l|}{Load Immediate Low} & N\\\hline

5'h0a & {\tt MPYUHI} & \multicolumn{2}{l|}{Upper 32 of 64 bits from an unsigned 32x32 multiply} &  \\\cline{1-4}

5'h0b & {\tt MPYSHI} & \multicolumn{2}{l|}{Upper 32 of 64 bits from a signed 32x32 multiply} & Y \\\cline{1-4}

5'h0c & {\tt MPY} & \multicolumn{2}{l|}{32x32 bit multiply} & \\\hline

5'h0d & {\tt MOV} & \multicolumn{2}{l|}{Move OpB into Ra} & N \\\hline

5'h0e & {\tt DIVU} & R0-R13 & Divide, unsigned & Y \\\cline{1-4}

5'h0f & {\tt DIVS} & R0-R13 & Divide, signed &  \\\hline\hline

%

5'h10 & {\tt CMP} & \multicolumn{2}{l|}{Compare (Ra-OpB) to zero} & Y \\\cline{1-4}

5'h11 & {\tt TST} & \multicolumn{2}{l|}{Test (AND w/o setting result)} &   \\\hline

5'h12 & {\tt LW} & \multicolumn{2}{l|}{Load a 32-bit word from memory (OpB) into Ra} & \\\cline{1-4}

5'h13 & {\tt SW} & \multicolumn{2}{l|}{Store a 32-bit word from Ra into memory at (OpB)} &  \\\cline{1-4}

5'h14 & {\tt LH} & \multicolumn{2}{l|}{Load 16-bits from memory (opB) into Ra, clear upper 16 bits} & N \\\cline{1-4}

5'h15 & {\tt SH} & \multicolumn{2}{l|}{Store the lower 16-bits of Ra into memory at (OpB)} &  \\\cline{1-4}

5'h16 & {\tt LB} & \multicolumn{2}{l|}{Load 8-bits from memory (OpB) into Ra, clear upper 24 bits} & \\\cline{1-4}

5'h17 & {\tt SB} & \multicolumn{2}{l|}{Store the lower 8-bits of Ra into memory at (OpB)} &  \\\hline\hline

5'h18/9 & {\tt LDI} & \multicolumn{2}{l|}{Load 23--bit signed immediate} & N \\\hline\hline

5'h1a & {\tt FPADD} & R0-R13 & Floating point add &  \\\cline{1-4}

5'h1b & {\tt FPSUB} & R0-R13 & Floating point subtract &   \\\cline{1-4}

5'h1c & {\tt FPMPY} & R0-R13 & Floating point multiply & Y \\\cline{1-4}

5'h1d & {\tt FPDIV} & R0-R13 & Floating point divide &   \\\cline{1-4}

5'h1e & {\tt FPI2F} & R0-R13 & Convert integer to floating point &   \\\cline{1-4}

5'h1f & {\tt FPF2I} & R0-R13 & Convert floating point to integer &   \\\hline\hline

5'h1c & {\tt BREAK} &None(15)&& \\\cline{1-4}

5'h1d & {\tt LOCK} &None(15)&& N\\\cline{1-4}

5'h1e & {\tt SIM}  &None(15)&&\\\cline{1-4}

5'h1f & {\tt NOOP} &None(15)&&\\\hline

\end{tabular}

\caption{ZipCPU OpCodes}\label{tbl:iset-opcodes}

\end{center}\end{table}

%

\subsection{Conditional Instructions}\label{sec:isa-cond}

Most, although not quite all, instructions may be conditionally executed.

The 23--bit load immediate instruction, together with the {\tt NOOP},

{\tt BREAK}, and {\tt LOCK} instructions are the exceptions to this rule.

All other instructions may be conditionally executed.

From the four condition code flags, eight conditions are defined, as shown in

Tbl.~\ref{tbl:conditions}.

\begin{table}\begin{center}

\begin{tabular}{l|l|l}

Code & Mnemonic & Condition \\\hline

3'h0 & None & Always execute the instruction \\

3'h1 & {\tt .Z} & Only execute when `Z' is set \\

3'h2 & {\tt .LT}& Less than (`N' set) \\

3'h3 & {\tt .C} & Carry set (Also known as less-than unsigned) \\

3'h4 & {\tt .V} & Overflow set\\

3'h5 & {\tt .NZ}& Only execute when `Z' is not set \\

3'h6 & {\tt .GE}& Greater than or equal (`N' not set) \\

3'h7 & {\tt .NC}& Not carry (also known as greater-than or equal, unsigned) \\

\end{tabular}

\caption{Conditions for conditional operand execution}\label{tbl:conditions}

\end{center}\end{table}

There are no condition codes for either less than or equal or greater than,

whether signed or unsigned.  In a similar fashion, there is no condition

code for not V---there just wasn't enough space in 3--bits.  Ways of handling

non--supported conditions are discussed in Sec.~\ref{sec:in-mcond}.

With the exception of \hbox{\tt CMP} and \hbox{\tt TST} instructions,

conditionally executed instructions will not further adjust the condition

codes.  Conditional \hbox{\tt CMP} or \hbox{\tt TST} instructions will adjust

conditions whenever they are executed.  In this way, multiple conditions may

be evaluated without branches, creating a sort of logical and--but only if all

the conditions are the same.  For example, to do something if \hbox{\tt R0} is

one and \hbox{\tt R1} is two, one might try code such as

Tbl.~\ref{tbl:dbl-condition}.

\begin{table}\begin{center}

\begin{tabular}{l}

        {\tt CMP 1,R0} \\

        {\em ; Condition codes are now set based upon R0-1} \\

        {\tt CMP.Z 2,R1} \\

        {\em ; If R0 $\neq$ 1, conditions are unchanged, {\tt Z} is still false.} \\

        {\em ; If R0 $=$ 1, conditions are now set based upon R1-2.} \\

        {\em ; Now some instruction could be done based upon the conjunction} \\

        {\em ; of both conditions.} \\