Subversion Repositories zipcpu

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

%%

%% Filename:    spec.tex

%%

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

%%

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

%%              currently provided with this Zip CPU 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 achilles 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{Zip CPU}

\title{Specification}

\author{Dan Gisselquist, Ph.D.}

\email{dgisselq (at) opencores.org}

\revision{Rev.~0.9}

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

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

\usepackage[dvips,ps2pdf,colorlinks=true,

        anchorcolor=black,pdfpagelabels,hypertexnames,

        pdfauthor={Dan Gisselquist},

        pdfsubject={Zip CPU}]{hyperref}

\hypersetup{

        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}

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

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 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. I would like to port binutils to the

Zip CPU, as I would like to port GCC and GDB. They are way ahead of me. 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 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.

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 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, and the base instructions are all designed to be executed in one

instruction cycle per instruction, barring pipeline stalls.  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, and more.

For those who like buzz words, the Zip CPU 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{Zip CPU 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 Zip CPU licensed under other terms, please

        contact me.}

\end{itemize}

The Zip CPU 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 a stall for the initial access.

\section{Characteristics of a SwiC}

Here, we shall define 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 Zip CPU.  Among these are the bus,

memory, and available peripherals.

Most 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.  The Zip CPU is fairly unique in

its approach because it uses a von Neumann architecture.  This was done for

simplicity.  By using a von Neumann architecture, only one bus needs to be

implemented within any FPGA.  This helps to minimize real-estate, while

maintaining a high clock speed.  The disadvantage is that it can severely

degrade the overall instructions per clock count.

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 that all memory accesses may be 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.

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 it's 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.  This leaves the CPU with the simple role

of solely handling sequential 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.

\section{Lessons Learned}

Now, however, that I've worked on the Zip CPU for a while, it is not nearly

as simple as I originally hoped.  Worse, I've had to adjust to create

capabilities that I was never expecting to need.  These include:

\begin{itemize}

\item {\bf External Debug:} Once placed upon an FPGA, some external means is

        still necessary to debug this CPU.  That means that there needs to be

        an external register that can control the CPU: reset it, halt it, step

        it, and tell whether it is running or not.  My chosen interface

        includes a second register similar to this control register.  This

        second register allows the external controller or debugger to examine

        registers internal to the CPU.

\item {\bf Internal Debug:} Being able to run a debugger from within

        a user process requires an ability to step a user process from

        within a debugger.  It also requires a break instruction that can

        be substituted for any other instruction, and substituted back.

        The break is actually difficult: the break instruction cannot be

        allowed to execute.  That way, upon a break, the debugger should

        be able to jump back into the user process to step the instruction

        that would've been at the break point initially, and then to

        replace the break after passing it.

        Incidentally, this break messes with the prefetch cache and the

        pipeline: if you change an instruction partially through the pipeline,

        the whole pipeline needs to be cleansed.  Likewise if you change

        an instruction in memory, you need to make sure the cache is reloaded

        with the new instruction.

\item {\bf Prefetch Cache:} My original implementation, {\tt prefetch}, had

        a very simple prefetch stage.  Any time the PC changed the prefetch

        would go and fetch the new instruction.  While this was perhaps this

        simplest approach, it cost roughly five clocks for every instruction.

        This was deemed unacceptable, as I wanted a CPU that could execute

        instructions in one cycle.

        My second implementation, {\tt pipefetch}, attempted to make the most

        use of pipelined memory.  When a new CPU address was issued, it would

        start reading

        memory in a pipelined fashion, and issuing instructions as soon as they

        were ready.  This cache was a sliding window in memory.  This suffered

        from some difficult performance problems, though.  If the CPU was

        alternating between two diverse sections of code, both could never be

        in the cache at the same time--causing lots of cache misses.  Further,

        the extra logic to implement this window cost an extra clock cycle

        in the cache implementation, slowing down branches.

        The Zip CPU now has a third cache implementation, {\tt pfcache}.  This

        new implementation takes only a single cycle per access, but costs a

        full cache line miss on any miss.  While configurable, a full cache

        line miss might mean that the CPU needs to read 256~instructions from

        memory before it can execute the first one of them.

\item {\bf Operating System:} In order to support an operating system,

        interrupts and so forth, the CPU needs to support supervisor and

        user modes, as well as a means of switching between them.  For example,

        the user needs a means of executing a system call.  This is the

        purpose of the {\bf `trap'} instruction.  This instruction needs to

        place the CPU into supervisor mode (here equivalent to disabling

        interrupts), as well as handing it a parameter such as identifying

        which O/S function was called.

My initial approach to building a trap instruction was to create an external

peripheral which, when written to, would generate an interrupt and could

return the last value written to it.  In practice, this approach didn't work

at all: the CPU executed two instructions while waiting for the

trap interrupt to take place.  Since then, I've decided to keep the rest of

the CC register for that purpose so that a write to the CC register, with the

GIE bit cleared, could be used to execute a trap.  This has other problems,

though, primarily in the limitation of the uses of the CC register.  In

particular, the CC register is the best place to put CPU state information and

to ``announce'' special CPU features (floating point, etc).  So the trap

instruction still switches to interrupt mode, but the CC register is not

nearly as useful for telling the supervisor mode processor what trap is being

executed.

Modern timesharing systems also depend upon a {\bf Timer} interrupt

to handle task swapping.  For the Zip CPU, this interrupt is handled

external to the CPU as part of the CPU System, found in {\tt zipsystem.v}.

The timer module itself is found in {\tt ziptimer.v}.

\item {\bf Bus Errors:} My original implementation had no logic to handle

        what would happen if the CPU attempted to read or write a non-existent

        memory address.  This changed after I needed to troubleshoot a failure

        caused by a subroutine return to a non-existent address.

        My next problem bus problem was caused by a misbehaving peripheral.

        Whenever the CPU attempted to read from or write to this peripheral,

        the peripheral would take control of the wishbone bus and not return

        it.  For example, it might never return an {\tt ACK} to signal

        the end of the bus transaction.  This led to the implementation of

        a wishbone bus watchdog that would create a bus error if any particular

        bus action didn't complete in a timely fashion.

\item {\bf Pipeline Stalls:} My original plan was to not support pipeline

        stalls at all, but rather to require the compiler to properly schedule

        all instructions so that stalls would never be necessary.  After trying

        to build such an architecture, I gave up, having learned some things:

        First, and ideal pipeline might look something like

        Fig.~\ref{fig:ideal-pipeline}.

\begin{figure}

\begin{center}

\includegraphics[width=4in]{../gfx/fullpline.eps}

\caption{An Ideal Pipeline: One instruction per clock cycle}\label{fig:ideal-pipeline}

\end{center}\end{figure}

        Notice that, in this figure, all the pipeline stages are complete and

        full.  Every instruction takes one clock and there are no delays.

        However, as the discussion above pointed out, the memory associated

        with a SwiC may not allow single clock access.  It may be instead

        that you can only read every two clocks.  In that case, what shall

        the pipeline look like?  Should it look like

        Fig.~\ref{fig:waiting-pipeline},

\begin{figure}\begin{center}

\includegraphics[width=4in]{../gfx/stuttra.eps}

\caption{Instructions wait for each other}\label{fig:waiting-pipeline}

\end{center}\end{figure}

        where instructions are held back until the pipeline is full, or should

        it look like Fig.~\ref{fig:independent-pipeline},

\begin{figure}\begin{center}

\includegraphics[width=4in]{../gfx/stuttrb.eps}

\caption{Instructions proceed independently}\label{fig:independent-pipeline}

\end{center}\end{figure}

        where each instruction is allowed to move through the pipeline

        independently?  For better or worse, the Zip CPU allows instructions

        to move through the pipeline independently.

        One approach to avoiding stalls is to use a branch delay slot,

        such as is shown in Fig.~\ref{fig:brdelay}.

\begin{figure}\begin{center}

\includegraphics[width=4in]{../gfx/bdly.eps}

\caption{A typical branch delay slot approach}\label{fig:brdelay}

\end{center}\end{figure}

        In this figure, instructions

        {\tt BR} (a branch), {\tt BD} (a branch delay instruction),

        are followed by instructions after the branch: {\tt IA}, {\tt IB}, etc.

        Since it takes a processor a clock cycle to execute a branch, the

        delay slot allows the processor to do something useful in that

        branch.  The problem the Zip CPU has with this approach is, what

        happens when the pipeline looks like Fig.~\ref{fig:brbroken}?

\begin{figure}\begin{center}

\includegraphics[width=4in]{../gfx/bdbroken.eps}

\caption{The branch delay slot breaks with a slow memory}\label{fig:brbroken}

\end{center}\end{figure}

        In this case, the branch delay slot never gets filled in the first

        place, and so the pipeline squashes it before it gets executed.

        If not that, then what happens when handling interrupts or

        debug stepping: when has the CPU finished an instruction?

        When the {\tt BR} instruction has finished, or must {\tt BD}

        follow every {\tt BR}?  and, again, what if the pipeline isn't

        full?

        These thoughts killed any hopes of doing delayed branching.

        So I switched to a model of discrete execution: Once an instruction

        enters into either the ALU or memory unit, the instruction is

        guaranteed to complete.  If the logic recognizes a branch or a

        condition that would render the instruction entering into this stage

        possibly inappropriate (i.e. a conditional branch preceding a store

        instruction for example), then the pipeline stalls for one cycle

        until the conditional branch completes.  Then, if it generates a new

        PC address, the stages preceding are all wiped clean.

        This model, however, generated too many pipeline stalls, so the

        discrete execution model was modified to allow instructions to go

        through the ALU unit and be canceled before writeback.  This removed

        the stall associated with ALU instructions before untaken branches.

        The discrete execution model allows such things as sleeping, as

        outlined in Fig.~\ref{fig:sleeping}.

\begin{figure}\begin{center}

\includegraphics[width=4in]{../gfx/sleep.eps}

\caption{How the CPU halts when sleeping}\label{fig:sleeping}

\end{center}\end{figure}

        If the

        CPU is put to ``sleep,'' the ALU and memory stages stall and back up

        everything before them.  Likewise, anything that has entered the ALU

        or memory stage when the CPU is placed to sleep continues to completion.

        To handle this logic, each pipeline stage has three control signals:

        a valid signal, a stall signal, and a clock enable signal.  In

        general, a stage stalls if it's contents are valid and the next step

        is stalled.  This allows the pipeline to fill any time a later stage

        stalls, as illustrated in Fig.~\ref{fig:stacking}.

\begin{figure}\begin{center}

\includegraphics[width=4in]{../gfx/stacking.eps}

\caption{Instructions can stack up behind a stalled instruction}\label{fig:stacking}

\end{center}\end{figure}

        However, if a pipeline hazard is detected, a stage can stall in order

        to prevent the previous from moving forward.

        This approach is also different from other pipeline approaches.

        Instead of keeping the entire pipeline filled, each stage is treated

        independently.  Therefore, individual stages may move forward as long

        as the subsequent stage is available, regardless of whether the stage

        behind it is filled.

\end{itemize}

With that introduction out of the way, let's move on to the instruction

set.

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

The Zip CPU supports a set of two operand instructions, where the second operand

(always a register) is the result.  The only exception is the store instruction,

where the first operand (always a register) is the source of the data to be

stored.

\section{Simplified Bus}

The bus architecture of the Zip CPU is that of a simplified WISHBONE bus.

It has been simplified in this fashion: all operations are 32--bit operations.

The bus is neither little endian nor big endian.  For this reason, all words

are 32--bits.  All instructions are also 32--bits wide.  Everything has been

built around the 32--bit word.

\section{Register Set}

The Zip CPU supports two sets of sixteen 32-bit registers, a supervisor

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

\begin{figure}\begin{center}

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

\caption{Zip CPU Register File}\label{fig:regset}

\end{center}\end{figure}

The supervisor set is used in interrupt mode when interrupts are disabled,

whereas the user set is used otherwise.  Of this register set, the Program

Counter (PC) is register 15, whereas the status register (SR) or condition

code register

(CC) is register 14.  By convention, the stack pointer will be register 13 and

noted as (SP)--although there is nothing special about this register other

than this convention.  Also by convention register~12 will point to a global

offset table, and may be abbreviated as the (GBL) register.

The CPU can access both register sets via move instructions from the

supervisor state, whereas the user state can only access the user registers.

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

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

\begin{table}\begin{center}

\begin{bitlist}

31\ldots 13 & R/W & Reserved for future uses\\\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, or user interrupt, Flag.  Cleared on return to userspace.\\\hline

8 & R & Illegal Instruction Flag\\\hline

7 & R/W & Break--Enable\\\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 11~bits of the status register form

a set of CPU state and condition codes.  Writes to other bits of this register

are preserved.

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

                Zero (Z),

                Carry (C),

                Negative (N),

                and Overflow (V).

On those instructions that set the flags, these flags will be set based upon

the output of the instruction.  If the result is zero, the Z flag will be set.

If the high order bit is set, the N flag will be set.  If the instruction

caused a bit to fall off the end, the carry bit will be set.  Finally, if

the instruction causes a signed integer overflow, the V flag will be set

afterwards.

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

The sixth bit is a global interrupt enable bit (GIE).  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.

The seventh bit is a step bit.  This bit can be set from supervisor mode only.

        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.  Then, upon return to supervisor

        mode, this bit will be automatically cleared.  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 eighth bit is a break enable bit.  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.  Encountering a break in supervisor mode will

halt the CPU independent of the break enable bit.  This bit can only be set

within supervisor mode.

% Should break enable be a supervisor mode bit, while the break enable bit

% in user mode is a break has taken place bit?

%

This functionality was added to enable an external debugger to

        set and manage breakpoints.

The ninth bit is an illegal instruction bit.  When the CPU

tries to execute either a non-existant 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.

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 or from an external interrupt or both.

\section{Instruction Format}

All Zip CPU 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{4}{DR}

                \bitbox[lrt]{5}{OpCode}

                \bitbox[lrt]{3}{Cnd}

                \bitbox{1}{0}

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

\bitbox{1}{0}\bitbox{4}{DR}

                \bitbox[lrb]{5}{}

                \bitbox[lrb]{3}{}

                \bitbox{1}{1}

                \bitbox{4}{BR}

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

\begin{leftwordgroup}{MOV}\bitbox{1}{0}\bitbox{4}{DR}

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

                \bitbox[lrt]{3}{Cnd}

                \bitbox{1}{A}

                \bitbox{4}{BR}

                \bitbox{1}{B}

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

\begin{leftwordgroup}{LDI}\bitbox{1}{0}\bitbox{4}{DR}

                \bitbox{4}{4'hb}

                \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} \\

\begin{leftwordgroup}{VLIW}\bitbox{1}{1}\bitbox[lrt]{4}{DR}

                \bitbox[lrt]{5}{OpCode}

                \bitbox[lrt]{3}{Cnd}

                \bitbox{1}{0}

                \bitbox{4}{Imm.}

                \bitbox{14}{---} \\

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

                \bitbox[lrb]{5}{}

                \bitbox[lr]{3}{}

                \bitbox{1}{1}

                \bitbox{4}{BR}

                \bitbox{14}{---}        \\

\bitbox{1}{1}\bitbox[lrb]{4}{}

                \bitbox{4}{4'hb}

                \bitbox{1}{}

                \bitbox[lrb]{3}{}

                \bitbox{5}{5'b Imm}

                \bitbox{14}{---}        \\

\bitbox{1}{1}\bitbox{9}{---}

                \bitbox[lrt]{3}{Cnd}

                \bitbox{5}{---}

                \bitbox[lrt]{4}{DR}

                \bitbox[lrt]{5}{OpCode}

                \bitbox{1}{0}

                \bitbox{4}{Imm}

                \\

\bitbox{1}{1}\bitbox{9}{---}

                \bitbox[lr]{3}{}

                \bitbox{5}{---}

                \bitbox[lr]{4}{}

                \bitbox[lrb]{5}{}

                \bitbox{1}{1}

                \bitbox{4}{Reg} \\

\bitbox{1}{1}\bitbox{9}{---}

                \bitbox[lrb]{3}{}

                \bitbox{5}{---}

                \bitbox[lrb]{4}{}

                \bitbox{4}{4'hb}

                \bitbox{1}{}

                \bitbox{5}{5'b Imm}

                \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, or DR.  The load 23--bit signed immediate instruction

(LDI) is different in that it accepts no conditions, and uses only a 4-bit

opcode.

This is actually a second version of instruction set definition, given certain

lessons learned.  For example, the original instruction set had the following

problems:

\begin{enumerate}

\item No opcodes were available for divide or floating point extensions to be

        made available.  Although there was space in the instruction set to

        add these types of instructions, this instruction space was going to

        require extra logic to use.

\item The carveouts for instructions such as NOOP and LDIHI/LDILO required

        extra logic to process.

\item The instruction set wasn't very compact.  One bus operation was required

        for every instruction.

\item While the CPU supported multiplies, they were only 16x16 bit multiplies.

\end{enumerate}

This second version was designed with two criteria.  The first was that the

new instruction set needed to be compatible, at the assembly language level,

with the previous instruction set.  Thus, it must be able to support all of

the previous menumonics and more.  This was achieved with the sole exception

that instruction immediates are generally two bits shorter than before.

(One bit was lost to the VLIW bit in front, another from changing from 4--bit

to 5--bit opcodes.)  Second, the new instruction set needed to be a drop--in

replacement for the decoder, modifying nothing else.  This was almost achieved,

save for two issues: the ALU unit needed to be replaced since the OpCodes

were reordered, and some condition code logic needed to be adjusted since the

condition codes were renumbered as well.  In the end, maximum reuse of the

existing RTL (Verilog) code was achieved in this upgrade.

As of this second version of the Zip CPU instruction set, the Zip CPU also

supports a very long instruction word (VLIW) set of instructions.   These

instruction formats pack two instructions into a single instuction word,

trading immediate instruction space to do this, but in just about all other

respects these are identical to two standard instructions.  Other than

instruction format, the only basic difference is that the CPU will not switch

to interrupt mode in between the two instructions.  Likewise a new job given

to the assembler is that of automatically packing as many instructions as

possible into the VLIW format.  Where necessary to place both VLIW instructions

on the same line, they will be separated by a vertical bar.

One belated change to the instruction set violates some of the above

principles.  This latter instruction set change replaced the {\tt LDIHI}

instruction with a 32--bit multiply instruction {\tt MPY}, and then changed

the two 16--bit multiply instructions {\tt MPYU} and {\tt MPYS} for

{\tt MPYUHI} and {\tt MPYSHI} respectively.  This creates a 32--bit

multiply capability, while removing the 16--bit multiply that wasn't very

useful. Further, the {\tt LDIHI} instruction was being used primarily by the

assembler and linker to create a 32--bit load immediate pair of instructions.

This instruction set combination, {\tt LDIHI} followed by {\tt LDILO} was

replaced with an equivalent instruction set, {\tt BREV} followed by {\tt LDILO},

save that linking has been made more complicated in the process.

\section{Instruction 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|c|} \hline \rowcolor[gray]{0.85}

OpCode & & Instruction &Sets CC \\\hline\hline

5'h00 & SUB & Subtract &   \\\cline{1-3}

5'h01 & AND & Bitwise And &   \\\cline{1-3}

5'h02 & ADD & Add two numbers &   \\\cline{1-3}

5'h03 & OR  & Bitwise Or & Y \\\cline{1-3}

5'h04 & XOR & Bitwise Exclusive Or &   \\\cline{1-3}

5'h05 & LSR & Logical Shift Right &   \\\cline{1-3}

5'h06 & LSL & Logical Shift Left &   \\\cline{1-3}

5'h07 & ASR & Arithmetic Shift Right &   \\\hline

5'h08 & MPY & 32x32 bit multiply & Y \\\hline

5'h09 & LDILO & Load Immediate Low & N\\\hline

5'h0a & MPYUHI & Upper 32 of 64 bits from an unsigned 32x32 multiply &  \\\cline{1-3}

5'h0b & MPYSHI & Upper 32 of 64 bits from a signed 32x32 multiply & Y \\\cline{1-3}

5'h0c & BREV & Bit Reverse &  \\\cline{1-3}

5'h0d & POPC& Population Count &  \\\cline{1-3}

5'h0e & ROL & Rotate left &   \\\hline

5'h0f & MOV & Move register & N \\\hline

5'h10 & CMP & Compare & Y \\\cline{1-3}

5'h11 & TST & Test (AND w/o setting result) &   \\\hline

5'h12 & LOD & Load from memory & N \\\cline{1-3}

5'h13 & STO & Store a register into memory &  \\\hline\hline

5'h14 & DIVU & Divide, unsigned & Y \\\cline{1-3}

5'h15 & DIVS & Divide, signed &  \\\hline\hline

5'h16/7 & LDI & Load 23--bit signed immediate & N \\\hline\hline

5'h18 & FPADD & Floating point add &  \\\cline{1-3}

5'h19 & FPSUB & Floating point subtract &   \\\cline{1-3}

5'h1a & FPMPY & Floating point multiply & Y \\\cline{1-3}

5'h1b & FPDIV & Floating point divide &   \\\cline{1-3}

5'h1c & FPCVT & Convert integer to floating point &   \\\cline{1-3}

5'h1d & FPINT & Convert to integer &   \\\hline

5'h1e & & {\em Reserved for future use} &\\\hline

5'h1f & & {\em Reserved for future use} &\\\hline

5'h18 & & NOOP (A-register = PC)&\\\cline{1-3}

5'h19 & & BREAK (A-register = PC)& N\\\cline{1-3}

5'h1a & & LOCK (A-register = PC)&\\\hline

\end{tabular}

\caption{Zip CPU OpCodes}\label{tbl:iset-opcodes}

\end{center}\end{table}

%

Of these opcodes, the {\tt BREV} and {\tt POPC} are experimental, and may be

replaced later, and two floating point instruction opcodes are reserved for

future use.

\section{Conditional Instructions}

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 only exception to this rule.

From the four condition code flags, eight conditions are defined for standard

instructions.  These are shown in Tbl.~\ref{tbl:conditions}.

\begin{table}\begin{center}

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

Code & Mneumonic & Condition \\\hline

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

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

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

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

3'h4 & {\tt .GT} & Greater than ('N' not set, 'Z' not set) \\

3'h5 & {\tt .GE} & Greater than or equal ('N' not set, 'Z' irrelevant) \\

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

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

\end{tabular}

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

\end{center}\end{table}

There is no condition code for less than or equal, not C or not V---there

just wasn't enough space in 3--bits.  Conditioning on a non--supported

condition is still possible, but it will take an extra instruction and a

pipeline stall.  (Ex: \hbox{\em (Stall)}; \hbox{\tt TST \$4,CC;} \hbox{\tt

STO.NZ R0,(R1)}) As an alternative, it is often possible to reverse the

condition, and thus recovering those extra two clocks.  Thus instead of

\hbox{\tt CMP Rx,Ry;} \hbox{\tt BNC label} you can issue a

\hbox{\tt CMP 1+Ry,Rx;} \hbox{\tt BC label}.

Conditionally executed instructions will not further adjust the

condition codes, with the exception of \hbox{\tt CMP} and \hbox{\tt TST}

instructions.   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.  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.} \\

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

        {;\em Now do something based upon the conjunction of both conditions.} \\

        {;\em While we use the example of a STO, it could be any instruction.} \\

        {\tt STO.Z R0,(R2)} \\

\end{tabular}

\caption{An example of a double conditional}\label{tbl:dbl-condition}

\end{center}\end{table}

In the case of VLIW instructions, only four conditions are defined as shown

in Tbl.~\ref{tbl:vliw-conditions}.

\begin{table}\begin{center}

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

Code & Mneumonic & Condition \\\hline

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

2'h1 & {\tt .LT} & Less than ('N' set) \\

2'h2 & {\tt .Z} & Only execute when 'Z' is set \\

2'h3 & {\tt .NZ} & Only execute when 'Z' is not set \\

\end{tabular}

\caption{VLIW Conditions}\label{tbl:vliw-conditions}

\end{center}\end{table}

Further, the first bit is given a special meaning.  If the first bit is set,

the conditions apply to the second half of the instruction, otherwise the

conditions will only apply to the first half of a conditional instruction.

Of course, the other conditions are still available by mingling the

non--VLIW instructions with VLIW instructions.

\section{Operand B}

Many instruction forms have a 19-bit source ``Operand B'' associated with them.

This ``Operand B'' is shown in Fig.~\ref{fig:iset-format} as part of the

standard instructions.  This Operand B is either equal to a register plus a

14--bit signed immediate offset, or an 18--bit signed immediate offset by

itself.  This value is encoded as shown in Tbl.~\ref{tbl:opb}.

\begin{table}\begin{center}

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

\bitheader{0-18}  \\

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

\bitbox{1}{1}\bitbox{4}{Reg}\bitbox{14}{14-bit Signed Immediate}

\end{bytefield}

\caption{Bit allocation for Operand B}\label{tbl:opb}

\end{center}\end{table}

Fourteen and eighteen bit immediate values don't make sense for all

instructions.  For example, what is the point of an 18--bit immediate when

executing a 16--bit multiply?  Or a 16--bit load--immediate?  In these cases,

the extra bits are simply ignored.

VLIW instructions still use the same operand B, only there was no room for any

instruction plus immediate addressing.  Therefore, VLIW instructions have either

a register or a 4--bit signed immediate as their operand B.  The only exception

is the load immediate instruction, which permits a 5--bit signed operand

B.\footnote{Although the space exists to extend this VLIW load immediate

instruction to six bits, the 5--bit limit was chosen to simplify the

disassembler.  This may change in the future.}

\section{Address Modes}

The Zip CPU supports two addressing modes: register plus immediate, and

immediate address.  Addresses are therefore encoded in the same fashion as

Operand B's, shown above.  Practically, the VLIW instruction set only offers

register addressing, necessitating a non--VLIW instruction for most memory

operations.

A lot of long hard thought was put into whether to allow pre/post increment

and decrement addressing modes.  Finding no way to use these operators without

taking two or more clocks per instruction,\footnote{The two clocks figure

comes from the design of the register set, allowing only one write per clock.

That write is either from the memory unit or the ALU, but never both.} these

addressing modes have been

removed from the realm of possibilities.  This means that the Zip CPU has no

native way of executing push, pop, return, or jump to subroutine operations.

Each of these instructions can be emulated with a set of instructions from the

existing set.

\section{Modifying Conditions}

A quick look at the list of conditions supported by the Zip CPU and listed

in Tbl.~\ref{tbl:conditions} reveals that the Zip CPU does not have a full set

of conditions.  In particular, only one explicit unsigned condition is