OpenCores
URL https://opencores.org/ocsvn/zipcpu/zipcpu/trunk

Subversion Repositories zipcpu

[/] [zipcpu/] [trunk/] [doc/] [src/] [spec.tex] - Diff between revs 23 and 24

Go to most recent revision | Show entire file | Details | Blame | View Log

Rev 23 Rev 24
Line 46... Line 46...
\documentclass{gqtekspec}
\documentclass{gqtekspec}
\project{Zip CPU}
\project{Zip CPU}
\title{Specification}
\title{Specification}
\author{Dan Gisselquist, Ph.D.}
\author{Dan Gisselquist, Ph.D.}
\email{dgisselq (at) opencores.org}
\email{dgisselq (at) opencores.org}
\revision{Rev.~0.1}
\revision{Rev.~0.2}
\begin{document}
\begin{document}
\pagestyle{gqtekspecplain}
\pagestyle{gqtekspecplain}
\titlepage
\titlepage
\begin{license}
\begin{license}
Copyright (C) \theyear\today, Gisselquist Technology, LLC
Copyright (C) \theyear\today, Gisselquist Technology, LLC
Line 68... Line 68...
You should have received a copy of the GNU General Public License along
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
with this program.  If not, see \hbox{<http://www.gnu.org/licenses/>} for a
copy.
copy.
\end{license}
\end{license}
\begin{revisionhistory}
\begin{revisionhistory}
 
0.2 & 8/19/2015 & Gisselquist & Still Draft, more complete \\\hline
0.1 & 8/17/2015 & Gisselquist & Incomplete First Draft \\\hline
0.1 & 8/17/2015 & Gisselquist & Incomplete First Draft \\\hline
\end{revisionhistory}
\end{revisionhistory}
% Revision History
% Revision History
% Table of Contents, named Contents
% Table of Contents, named Contents
\tableofcontents
\tableofcontents
% \listoffigures
\listoffigures
\listoftables
\listoftables
\begin{preface}
\begin{preface}
Many people have asked me why I am building the Zip CPU. ARM processors are
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
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
have better toolsets than the Zip CPU will ever have. OpenRISC is also
available. Why build a new processor?
available, RISC--V may be replacing it. Why build a new processor?
 
 
The easiest, most obvious answer is the simple one: Because I can.
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
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.
processor, and I want to be able to do it in a vendor independent fashion.
Line 131... Line 132...
 
 
For those who like buzz words, the Zip CPU is:
For those who like buzz words, the Zip CPU is:
\begin{itemize}
\begin{itemize}
\item A 32-bit CPU: All registers are 32-bits, addresses are 32-bits,
\item A 32-bit CPU: All registers are 32-bits, addresses are 32-bits,
                instructions are 32-bits wide, etc.
                instructions are 32-bits wide, etc.
\item A RISC CPU.  There is no microcode for executing instructions.
\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
\item A Load/Store architecture.  (Only load and store instructions
                can access memory.)
                can access memory.)
\item Wishbone compliant.  All peripherals are accessed just like
\item Wishbone compliant.  All peripherals are accessed just like
                memory across this bus.
                memory across this bus.
\item A Von-Neumann architecture.  (The instructions and data share a
\item A Von-Neumann architecture.  (The instructions and data share a
                common bus.)
                common bus.)
\item A pipelined architecture, having stages for {\bf Prefetch},
\item A pipelined architecture, having stages for {\bf Prefetch},
                {\bf Decode}, {\bf Read-Operand}, the {\bf ALU/Memory}
                {\bf Decode}, {\bf Read-Operand}, the {\bf ALU/Memory}
                unit, and {\bf Write-back}
                unit, and {\bf Write-back}.  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
\item Completely open source, licensed under the GPL.\footnote{Should you
        need a copy of the Zip CPU licensed under other terms, please
        need a copy of the Zip CPU licensed under other terms, please
        contact me.}
        contact me.}
\end{itemize}
\end{itemize}
 
 
Line 153... Line 160...
capabilities that I was never expecting to need.  These include:
capabilities that I was never expecting to need.  These include:
\begin{itemize}
\begin{itemize}
\item {\bf Extenal Debug:} Once placed upon an FPGA, some external means is
\item {\bf Extenal Debug:} Once placed upon an FPGA, some external means is
        still necessary to debug this CPU.  That means that there needs to be
        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
        an external register that can control the CPU: reset it, halt it, step
        it, and tell whether it is running or not.  Another register is placed
        it, and tell whether it is running or not.  My chosen interface
        similar to this register, to allow the external controller to examine
        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.
        registers internal to the CPU.
 
 
\item {\bf Internal Debug:} Being able to run a debugger from within
\item {\bf Internal Debug:} Being able to run a debugger from within
        a user process requires an ability to step a user process from
        a user process requires an ability to step a user process from
        within a debugger.  It also requires a break instruction that can
        within a debugger.  It also requires a break instruction that can
Line 167... Line 175...
        allowed to execute.  That way, upon a break, the debugger should
        allowed to execute.  That way, upon a break, the debugger should
        be able to jump back into the user process to step the instruction
        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
        that would've been at the break point initially, and then to
        replace the break after passing it.
        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 had a very
\item {\bf Prefetch Cache:} My original implementation had a very
        simple prefetch stage.  Any time the PC changed the prefetch would go
        simple prefetch stage.  Any time the PC changed the prefetch would go
        and fetch the new instruction.  While this was perhaps this simplest
        and fetch the new instruction.  While this was perhaps this simplest
        approach, it cost roughly five clocks for every instruction.  This
        approach, it cost roughly five clocks for every instruction.  This
        was deemed unacceptable, as I wanted a CPU that could execute
        was deemed unacceptable, as I wanted a CPU that could execute
Line 187... Line 201...
        purpose of the {\bf `trap'} instruction.  This instruction needs to
        purpose of the {\bf `trap'} instruction.  This instruction needs to
        place the CPU into supervisor mode (here equivalent to disabling
        place the CPU into supervisor mode (here equivalent to disabling
        interrupts), as well as handing it a parameter such as identifying
        interrupts), as well as handing it a parameter such as identifying
        which O/S function was called.
        which O/S function was called.
 
 
My initial approach to building a trap instruction was to create
My initial approach to building a trap instruction was to create an external
        an external peripheral which, when written to, would generate an
peripheral which, when written to, would generate an interrupt and could
        interrupt and could return the last value written to it.  This failed
return the last value written to it.  In practice, this approach didn't work
        timing requirements, however: the CPU executed two instructions while
at all: the CPU executed two instructions while waiting for the
        waiting for the trap interrupt to take place.  Since then, I've
trap interrupt to take place.  Since then, I've decided to keep the rest of
        decided to keep the rest of the CC register for that purpose so that a
the CC register for that purpose so that a write to the CC register, with the
        write to the CC register, with the GIE bit cleared, could be used to
GIE bit cleared, could be used to execute a trap.  This has other problems,
        execute a trap.
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
Modern timesharing systems also depend upon a {\bf Timer} interrupt
        to handle task swapping.  For the Zip CPU, this interrupt is handled
        to handle task swapping.  For the Zip CPU, this interrupt is handled
        external to the CPU as part of the CPU System, found in
external to the CPU as part of the CPU System, found in {\tt zipsystem.v}.
        {\tt zipsystem.v}.  The timer module itself is found in
The timer module itself is found in {\tt ziptimer.v}.
        {\tt ziptimer.v}.
 
 
 
\item {\bf Pipeline Stalls:} My original plan was to not support pipeline
\item {\bf Pipeline Stalls:} My original plan was to not support pipeline
        stalls at all, but rather to require the compiler to properly schedule
        stalls at all, but rather to require the compiler to properly schedule
        instructions so that stalls would never be necessary.  After trying
        all instructions so that stalls would never be necessary.  After trying
        to build such an architecture, I gave up, having learned some things:
        to build such an architecture, I gave up, having learned some things:
 
 
        For example, in  order to facilitate interrupt handling and debug
        For example, in  order to facilitate interrupt handling and debug
        stepping, the CPU needs to know what instructions have finished, and
        stepping, the CPU needs to know what instructions have finished, and
        which have not.  In other words, it needs to know where it can restart
        which have not.  In other words, it needs to know where it can restart
        the pipeline from.  Once restarted, it must act as though it had
        the pipeline from.  Once restarted, it must act as though it had
                never stopped.  This killed my idea of delayed branching, since
        never stopped.  This killed my idea of delayed branching, since what
                what would be the appropriate program counter to restart at?
        would be the appropriate program counter to restart at?  The one the
                The one the CPU was going to branch to, or the ones in the
        CPU was going to branch to, or the ones in the delay slots?  This
                delay slots?
        also makes the idea of compressed instruction codes difficult, since,
 
        again, where do you restart on interrupt?
 
 
        So I switched to a model of discrete execution: Once an instruction
        So I switched to a model of discrete execution: Once an instruction
        enters into either the ALU or memory unit, the instruction is
        enters into either the ALU or memory unit, the instruction is
        guaranteed to complete.  If the logic recognizes a branch or a
        guaranteed to complete.  If the logic recognizes a branch or a
        condition that would render the instruction entering into this stage
        condition that would render the instruction entering into this stage
Line 226... Line 245...
        instruction for example), then the pipeline stalls for one cycle
        instruction for example), then the pipeline stalls for one cycle
        until the conditional branch completes.  Then, if it generates a new
        until the conditional branch completes.  Then, if it generates a new
        PC address, the stages preceeding are all wiped clean.
        PC address, the stages preceeding are all wiped clean.
 
 
        The discrete execution model allows such things as sleeping: if the
        The discrete execution model allows such things as sleeping: if the
        CPU is put to "sleep", the ALU and memory stages stall and back up
        CPU is put to ``sleep,'' the ALU and memory stages stall and back up
        everything before them.  Likewise, anything that has entered the ALU
        everything before them.  Likewise, anything that has entered the ALU
        or memory stage when the CPU is placed to sleep continues to completion.
        or memory stage when the CPU is placed to sleep continues to completion.
        To handle this logic, each pipeline stage has three control signals:
        To handle this logic, each pipeline stage has three control signals:
        a valid signal, a stall signal, and a clock enable signal.  In
        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
        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
        is stalled.  This allows the pipeline to fill any time a later stage
        stalls.
        stalls.
 
 
 
        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.
 
 
\item {\bf Verilog Modules:} When examining how other processors worked
\item {\bf Verilog Modules:} When examining how other processors worked
        here on open cores, many of them had one separate module per pipeline
        here on open cores, many of them had one separate module per pipeline
        stage.  While this appeared to me to be a fascinating and commendable
        stage.  While this appeared to me to be a fascinating and commendable
        idea, my own implementation didn't work out quite so nicely.
        idea, my own implementation didn't work out quite so nicely.
 
 
Line 261... Line 286...
With that introduction out of the way, let's move on to the instruction
With that introduction out of the way, let's move on to the instruction
set.
set.
 
 
\chapter{CPU Architecture}\label{chap:arch}
\chapter{CPU Architecture}\label{chap:arch}
 
 
The Zip CPU supports a set of two operand instructions, where the first operand
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,
(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
where the first operand (always a register) is the source of the data to be
stored.
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 bit 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}
\section{Register Set}
The Zip CPU supports two sets of sixteen 32-bit registers, a supervisor
The Zip CPU supports two sets of sixteen 32-bit registers, a supervisor
and a user set.  The supervisor set is used in interrupt mode, whereas
and a user set as shown in Fig.~\ref{fig:regset}.
the user set is used otherwise.  Of this register set, the Program Counter (PC)
\begin{figure}\begin{center}
is register 15, whereas the status register (SR) or condition code register
\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
(CC) is register 14.  By convention, the stack pointer will be register 13 and
noted as (SP)--although the instruction set allows it to be anything.
noted as (SP)--although there is nothing special about this register other
 
than this convention.
The CPU can access both register sets via move instructions from the
The CPU can access both register sets via move instructions from the
supervisor state, whereas the user state can only access the user registers.
supervisor state, whereas the user state can only access the user registers.
 
 
The status register is special, and bears further mention.  The lower
The status register is special, and bears further mention.  The lower
8 bits of the status register form a set of condition codes.  Writes to other
10 bits of the status register form a set of CPU state and condition codes.
bits are preserved, and can be used as part of the trap architecture--examined
Writes to other bits of this register are preserved.
by the O/S upon any interrupt, cleared before returning.
 
 
 
Of the eight condition codes, the bottom four are the current flags:
Of the eight condition codes, the bottom four are the current flags:
                Zero (Z),
                Zero (Z),
                Carry (C),
                Carry (C),
                Negative (N),
                Negative (N),
Line 312... Line 350...
        This functionality was added to enable a userspace debugger
        This functionality was added to enable a userspace debugger
        functionality on a user process, working through supervisor mode
        functionality on a user process, working through supervisor mode
        of course.
        of course.
 
 
 
 
The eighth bit is a break enable bit.  This
The eighth bit is a break enable bit.  This controls whether a break
        controls whether a break instruction will halt the processor for an
instruction in user mode will halt the processor for an external debugger
        external debuggerr (break enabled), or whether the break instruction
(break enabled), or whether the break instruction will simply send send the
        will simply set the STEP bit and send the CPU into interrupt mode.
CPU into interrupt mode.  Encountering a break in supervisor mode will
        This bit can only be set within supervisor mode.
halt the CPU independent of the break enable bit.  This bit can only be set
 
within supervisor mode.
 
 
This functionality was added to enable an external debugger to
This functionality was added to enable an external debugger to
        set and manage breakpoints.
        set and manage breakpoints.
 
 
The ninth bit is reserved for a floating point enable bit.  When set, the
The ninth bit is reserved for a floating point enable bit.  When set, the
arithmetic for the next instruction will be sent to a floating point unit.
arithmetic for the next instruction will be sent to a floating point unit.
Such a unit may later be added as an extension to the Zip CPU.  If the
Such a unit may later be added as an extension to the Zip CPU.  If the
CPU does not support floating point instructions, this bit will never be set.
CPU does not support floating point instructions, this bit will never be set.
 
The instruction set could also be simply extended to allow other data types
 
in this fashion, such as two by 16--bit vector operations or four by 8--bit
 
vector operations.
 
 
The tenth bit is a trap bit.  It is set whenever the user requests a soft
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
interrupt, and cleared on any return to userspace command.  This allows the
supervisor, in supervisor mode, to determine whether it got to supervisor
supervisor, in supervisor mode, to determine whether it got to supervisor
mode from a trap or from an external interrupt or both.
mode from a trap or from an external interrupt or both.
 
 
The status register bits are shown below:
These status register bits are summarized in Tbl.~\ref{tbl:ccbits}.
\begin{table}
\begin{table}
\begin{center}
\begin{center}
\begin{tabular}{l|l}
\begin{tabular}{l|l}
Bit & Meaning \\\hline
Bit & Meaning \\\hline
9 & Soft trap, set on a trap from user mode, cleared when returing to user mode\\\hline
9 & Soft trap, set on a trap from user mode, cleared when returing to user mode\\\hline
Line 347... Line 389...
3 & V, or overflow bit.\\\hline
3 & V, or overflow bit.\\\hline
2 & N, or negative bit.\\\hline
2 & N, or negative bit.\\\hline
1 & C, or carry bit.\\\hline
1 & C, or carry bit.\\\hline
0 & Z, or zero bit. \\\hline
0 & Z, or zero bit. \\\hline
\end{tabular}
\end{tabular}
\end{center}
\caption{Condition Code / Status Register Bits}\label{tbl:ccbits}
\end{table}
\end{center}\end{table}
 
 
\section{Conditional Instructions}
\section{Conditional Instructions}
Most, although not quite all, instructions are conditionally executed.  From
Most, although not quite all, instructions are conditionally executed.  From
the four condition code flags, eight conditions are defined.  These are shown
the four condition code flags, eight conditions are defined.  These are shown
in Tbl.~\ref{tbl:conditions}.
in Tbl.~\ref{tbl:conditions}.
\begin{table}
\begin{table}
Line 362... Line 405...
3'h0 & None & Always execute the instruction \\
3'h0 & None & Always execute the instruction \\
3'h1 & {\tt .Z} & Only execute when 'Z' is set \\
3'h1 & {\tt .Z} & Only execute when 'Z' is set \\
3'h2 & {\tt .NE} & Only execute when 'Z' is not set \\
3'h2 & {\tt .NE} & Only execute when 'Z' is not set \\
3'h3 & {\tt .GE} & Greater than or equal ('N' not set, 'Z' irrelevant) \\
3'h3 & {\tt .GE} & Greater than or equal ('N' not set, 'Z' irrelevant) \\
3'h4 & {\tt .GT} & Greater than ('N' not set, 'Z' not set) \\
3'h4 & {\tt .GT} & Greater than ('N' not set, 'Z' not set) \\
3'h5 & {\tt .LT} & Less than ('N' not set) \\
3'h5 & {\tt .LT} & Less than ('N' set) \\
3'h6 & {\tt .C} & Carry set\\
3'h6 & {\tt .C} & Carry set\\
3'h7 & {\tt .V} & Overflow set\\
3'h7 & {\tt .V} & Overflow set\\
\end{tabular}
\end{tabular}
\caption{Conditions for conditional operand execution}\label{tbl:conditions}
\caption{Conditions for conditional operand execution}\label{tbl:conditions}
\end{center}
\end{center}
\end{table}
\end{table}
There is no condition code for less than or equal, not C or not V.  Using
There is no condition code for less than or equal, not C or not V.  Sorry,
these conditions will take an extra instruction.
I ran out of space in 3--bits.  Using these conditions will take an extra
(Ex: \hbox{\tt TST \$4,CC;} \hbox{\tt STO.NZ R0,(R1)})
instruction.  (Ex: \hbox{\tt TST \$4,CC;} \hbox{\tt STO.NZ R0,(R1)})
 
 
\section{Operand B}
\section{Operand B}
Many instruction forms have a 21-bit source "Operand B" associated with them.
Many instruction forms have a 21-bit source ``Operand B'' associated with them.
This Operand B is either equal to a register plus a signed immediate offset,
This Operand B is either equal to a register plus a signed immediate offset,
or an immediate offset by itself.  This value is encoded as shown in
or an immediate offset by itself.  This value is encoded as shown in
Tbl.~\ref{tbl:opb}.
Tbl.~\ref{tbl:opb}.
\begin{table}\begin{center}
\begin{table}\begin{center}
\begin{tabular}{|l|l|l|}\hline
\begin{tabular}{|l|l|l|}\hline
Bit 20 & 19 \ldots 16 & 15 \ldots 0 \\\hline
Bit 20 & 19 \ldots 16 & 15 \ldots 0 \\\hline
1'b0 & \multicolumn{2}{l|}{Signed Immediate value} \\\hline
1'b0 & \multicolumn{2}{l|}{20--bit Signed Immediate value} \\\hline
1'b1 & 4-bit Register & 16-bit Signed immediate offset \\\hline
1'b1 & 4-bit Register & 16--bit Signed immediate offset \\\hline
\end{tabular}
\end{tabular}
\caption{Bit allocation for Operand B}\label{tbl:opb}
\caption{Bit allocation for Operand B}\label{tbl:opb}
\end{center}\end{table}
\end{center}\end{table}
 
 
 
Sixteen and twenty bit immediates don't make sense for all instructions.  For
 
example, what is the point of a 20--bit immediate when executing a 16--bit
 
multiply?  Likewise, why have a 16--bit immediate when adding to a logical
 
or arithmetic shift?  In these cases, the extra bits are reserved for future
 
instruction possibilities.
 
 
\section{Address Modes}
\section{Address Modes}
The ZIP CPU supports two addressing modes: register plus immediate, and
The ZIP CPU supports two addressing modes: register plus immediate, and
immediate address.  Addresses are therefore encoded in the same fashion as
immediate address.  Addresses are therefore encoded in the same fashion as
Operand B's, shown above.
Operand B's, shown above.
 
 
A lot of long hard thought was put into whether to allow pre/post increment
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
and decrement addressing modes.  Finding no way to use these operators without
taking two or more clocks per instruction, these addressing modes have been
taking two or more clocks per instruction, these addressing modes have been
removed from the realm of possibilities.  This means that the Zip CPU has no
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.
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{Move Operands}
\section{Move Operands}
The previous set of operands would be perfect and complete, save only that
The previous set of operands would be perfect and complete, save only that
        the CPU needs access to non--supervisory registers while in supervisory
the CPU needs access to non--supervisory registers while in supervisory mode.
        mode.  Therefore, the MOV instruction is special and offers access
Therefore, the MOV instruction is special and offers access to these registers
        to these registers ... when in supervisory mode.  To keep the compiler
\ldots when in supervisory mode.  To keep the compiler simple, the extra bits
        simple, the extra bits are ignored in non-supervisory mode (as though
are ignored in non-supervisory mode (as though they didn't exist), rather than
        they didn't exist), rather than being mapped to new instructions or
being mapped to new instructions or additional capabilities.  The bits
        additional capabilities.  The bits indicating which register set each
indicating which register set each register lies within are the A-Usr and
        register lies within are the A-Usr and B-Usr bits.  When set to a one,
B-Usr bits.  When set to a one, these refer to a user mode register.  When set
        these refer to a user mode register.  When set to a zero, these refer
to a zero, these refer to a register in the current mode, whether user or
        to a register in the current mode, whether user or supervisor.
supervisor.  Further, because a load immediate instruction exists, there is no
        Further, because
move capability between an immediate and a register: all moves come from either
        a load immediate instruction exists, there is no move capability between
a register or a register plus an offset.
        an immediate and a register: all moves come from either a register or
 
        a register plus an offset.
This actually leads to a bit of a problem: since the MOV instruction encodes
 
which register set each register is coming from or moving to, how shall a
This actually leads to a bit of a problem: since the MOV instruction
compiler or assembler know how to compile a MOV instruction without knowing
        encodes which register set each register is coming from or moving to,
the mode of the CPU at the time?  For this reason, the compiler will assume
        how shall a compiler or assembler know how to compile a MOV instruction
all MOV registers are supervisor registers, and display them as normal.
        without knowing the mode of the CPU at the time?  For this reason,
Anything with the user bit set will be treated as a user register.  The CPU
        the compiler will assume all MOV registers are supervisor registers,
will quietly ignore the supervisor bits while in user mode, and anything
        and display them as normal.  Anything with the user bit set will
marked as a user register will always be valid.  (Did I just say that in the
        be treated as a user register.  The CPU will quietly ignore the
last paragraph?)
        supervisor bits while in user mode, and anything marked as a user
 
        register will always be valid.
 
 
 
\section{Multiply Operations}
\section{Multiply Operations}
While the Zip CPU instruction set supports multiply operations, they are not
The Zip CPU supports two Multiply operations, a
yet fully supported by the CPU.  Two Multiply operations are supported, a
 
16x16 bit signed multiply (MPYS) and the same but unsigned (MPYU).  In both
16x16 bit signed multiply (MPYS) and the same but unsigned (MPYU).  In both
cases, the operand is a register plus a 16-bit immediate, subject to the
cases, the operand is a register plus a 16-bit immediate, subject to the
rule that the register cannot be the PC or CC registers.  The PC register
rule that the register cannot be the PC or CC registers.  The PC register
field has been stolen to create a multiply by immediate instruction.  The
field has been stolen to create a multiply by immediate instruction.  The
CC register field is reserved.
CC register field is reserved.
Line 461... Line 510...
CMP(Sub) & \multicolumn{4}{l|}{4'h0}
CMP(Sub) & \multicolumn{4}{l|}{4'h0}
                & \multicolumn{4}{l|}{D. Reg}
                & \multicolumn{4}{l|}{D. Reg}
                & \multicolumn{3}{l|}{Cond.}
                & \multicolumn{3}{l|}{Cond.}
                & \multicolumn{21}{l|}{Operand B}
                & \multicolumn{21}{l|}{Operand B}
                & Yes \\\hline
                & Yes \\\hline
BTST(And) & \multicolumn{4}{l|}{4'h1}
TST(And) & \multicolumn{4}{l|}{4'h1}
                & \multicolumn{4}{l|}{D. Reg}
                & \multicolumn{4}{l|}{D. Reg}
                & \multicolumn{3}{l|}{Cond.}
                & \multicolumn{3}{l|}{Cond.}
                & \multicolumn{21}{l|}{Operand B}
                & \multicolumn{21}{l|}{Operand B}
        & Yes \\\hline
        & Yes \\\hline
MOV & \multicolumn{4}{l|}{4'h2}
MOV & \multicolumn{4}{l|}{4'h2}
Line 596... Line 645...
\end{tabular}
\end{tabular}
\caption{Zip CPU Instruction Set}\label{tbl:zip-instructions}
\caption{Zip CPU Instruction Set}\label{tbl:zip-instructions}
\end{center}\end{table}
\end{center}\end{table}
 
 
As you can see, there's lots of room for instruction set expansion.  The
As you can see, there's lots of room for instruction set expansion.  The
NOOP and BREAK instructions leave 24~bits of open instruction address
NOOP and BREAK instructions are the only instructions within one particular
space, minus the two instructions NOOP and BREAK.  The Subtract leaves half
24--bit hole.  Likewise, the subtract leaves half of its space open, since a
of its space open, since a subtract immediate is the same as an add with a
subtract immediate is the same as an add with a negated immediate.  This
negated immediate.
spaces are reserved for future enhancements.
 
 
\section{Derived Instructions}
\section{Derived Instructions}
The ZIP CPU supports many other common instructions, but not all of them
The ZIP CPU supports many other common instructions, but not all of them
are single instructions.  The derived instruction tables,
are single cycle instructions.  The derived instruction tables,
Tbls.~\ref{tbl:derived-1}, \ref{tbl:derived-2}, and~\ref{tbl:derived-3},
Tbls.~\ref{tbl:derived-1}, \ref{tbl:derived-2}, and~\ref{tbl:derived-3},
help to capture some of how these other instructions may be implemented on
help to capture some of how these other instructions may be implemented on
the ZIP CPU.  Many of these instructions will have assembly equivalents,
the ZIP CPU.  Many of these instructions will have assembly equivalents,
such as the branch instructions, to facilitate working with the CPU.
such as the branch instructions, to facilitate working with the CPU.
\begin{table}\begin{center}
\begin{table}\begin{center}
Line 615... Line 664...
Mapped & Actual  & Notes \\\hline
Mapped & Actual  & Notes \\\hline
\parbox[t]{1.4in}{ADD Ra,Rx\\ADDC Rb,Ry}
\parbox[t]{1.4in}{ADD Ra,Rx\\ADDC Rb,Ry}
        & \parbox[t]{1.5in}{Add Ra,Rx\\ADD.C \$1,Ry\\Add Rb,Ry}
        & \parbox[t]{1.5in}{Add Ra,Rx\\ADD.C \$1,Ry\\Add Rb,Ry}
        & Add with carry \\\hline
        & Add with carry \\\hline
BRA.Cond +/-\$Addr
BRA.Cond +/-\$Addr
        & Mov.cond \$Addr+PC,PC
        & \hbox{Mov.cond \$Addr+PC,PC}
        & Branch or jump on condition.  Works for 14 bit
        & Branch or jump on condition.  Works for 15--bit
                address offsets.\\\hline
                signed address offsets.\\\hline
BRA.Cond +/-\$Addr
BRA.Cond +/-\$Addr
        & \parbox[t]{1.5in}{LDI \$Addr,Rx \\ ADD.cond Rx,PC}
        & \parbox[t]{1.5in}{LDI \$Addr,Rx \\ ADD.cond Rx,PC}
        & Branch/jump on condition.  Works for
        & Branch/jump on condition.  Works for
        23 bit address offsets, but costs a register, an extra instruction,
        23 bit address offsets, but costs a register, an extra instruction,
        and setsthe flags. \\\hline
        and setsthe flags. \\\hline
Line 657... Line 706...
        & \parbox[t]{1.5in}{SUB \$1,SP \\\
        & \parbox[t]{1.5in}{SUB \$1,SP \\\
        MOV \$3+PC,R0 \\
        MOV \$3+PC,R0 \\
        STO R0,1(SP) \\
        STO R0,1(SP) \\
        MOV \$Addr+PC,PC \\
        MOV \$Addr+PC,PC \\
        ADD \$1,SP}
        ADD \$1,SP}
        & Jump to Subroutine. \\\hline
        & Jump to Subroutine. Note the required cleanup instruction after
 
        returning. \\\hline
JSR PC+\$Addr
JSR PC+\$Addr
        & \parbox[t]{1.5in}{MOV \$3+PC,R12 \\ MOV \$addr+PC,PC}
        & \parbox[t]{1.5in}{MOV \$3+PC,R12 \\ MOV \$addr+PC,PC}
        &This is the high speed
        &This is the high speed
        version of a subroutine call, necessitating a register to hold the
        version of a subroutine call, necessitating a register to hold the
        last PC address.  In its favor, this method doesn't suffer the
        last PC address.  In its favor, this method doesn't suffer the
Line 694... Line 744...
        & \parbox[t]{3in}{This CPU is designed for 32'bit word
        & \parbox[t]{3in}{This CPU is designed for 32'bit word
        length instructions.  Byte addressing is not supported by the CPU or
        length instructions.  Byte addressing is not supported by the CPU or
        the bus, so it therefore takes more work to do.
        the bus, so it therefore takes more work to do.
 
 
        Note also that in this example, \$Addr is a byte-wise address, where
        Note also that in this example, \$Addr is a byte-wise address, where
        all other addresses are 32-bit wordlength addresses.  For this reason,
        all other addresses in this document are 32-bit wordlength addresses.
 
        For this reason,
        we needed to drop the bottom two bits.  This also limits the address
        we needed to drop the bottom two bits.  This also limits the address
        space of character accesses using this method from 16 MB down to 4MB.}
        space of character accesses using this method from 16 MB down to 4MB.}
                \\\hline
                \\\hline
\parbox[t]{1.5in}{LSL \$1,Rx\\ LSLC \$1,Ry}
\parbox[t]{1.5in}{LSL \$1,Rx\\ LSLC \$1,Ry}
        & \parbox[t]{1.5in}{LSL \$1,Ry \\
        & \parbox[t]{1.5in}{LSL \$1,Ry \\
Line 739... Line 790...
        & \parbox[t]{3in}{This depends upon the peripheral base address being
        & \parbox[t]{3in}{This depends upon the peripheral base address being
        in R12.
        in R12.
 
 
        Another opportunity might be to jump to the reset address from within
        Another opportunity might be to jump to the reset address from within
        supervisor mode.}\\\hline
        supervisor mode.}\\\hline
RET & \parbox[t]{1.5in}{LOD \$-1(SP),R0 \\
RET & \parbox[t]{1.5in}{LOD \$-1(SP),PC}
        MOV \$-1+SP,SP \\
        & Note that this depends upon the calling context to clean up the
        MOV R0,PC}
        stack, as outlined for the JSR instruction.  \\\hline
        & An alternative might be to LOD \$-1(SP),PC, followed
 
        by depending upon the calling program to ADD \$1,SP. \\\hline
 
\end{tabular}
\end{tabular}
\caption{Derived Instructions, continued}\label{tbl:derived-2}
\caption{Derived Instructions, continued}\label{tbl:derived-2}
\end{center}\end{table}
\end{center}\end{table}
\begin{table}\begin{center}
\begin{table}\begin{center}
\begin{tabular}{p{1.4in}p{1.5in}p{3in}}\\\hline
\begin{tabular}{p{1.4in}p{1.5in}p{3in}}\\\hline
Line 789... Line 838...
        & While no extra registers are needed, this example
        & While no extra registers are needed, this example
        does take 3-clocks. \\\hline
        does take 3-clocks. \\\hline
TRAP \#X
TRAP \#X
        & LDILO \$x,CC
        & LDILO \$x,CC
        & This approach uses the unused bits of the CC register as a TRAP
        & This approach uses the unused bits of the CC register as a TRAP
        address.  If these bits are zero, no trap has occurred.  Unlike my
        address.  The user will need to make certain
        previous approach, which was to use a trap peripheral, this approach
 
        has no delay associated with it.  To work, the supervisor will need
 
        to clear this register following any trap, and the user will need to
 
        be careful to only set this register prior to a trap condition.
 
        Likewise, when setting this value, the user will need to make certain
 
        that the SLEEP and GIE bits are not set in \$x.  LDI would also work,
        that the SLEEP and GIE bits are not set in \$x.  LDI would also work,
        however using LDILO permits the use of conditional traps.  (i.e.,
        however using LDILO permits the use of conditional traps.  (i.e.,
        trap if the zero flag is set.)  Should you wish to trap off of a
        trap if the zero flag is set.)  Should you wish to trap off of a
        register value, you could equivalently load \$x into the register and
        register value, you could equivalently load \$x into the register and
        then MOV it into the CC register. \\\hline
        then MOV it into the CC register. \\\hline
Line 810... Line 854...
        of Rx. \\\hline
        of Rx. \\\hline
WAIT
WAIT
        & Or \$SLEEP,CC
        & Or \$SLEEP,CC
        & Wait 'til interrupt.  In an interrupts disabled context, this
        & Wait 'til interrupt.  In an interrupts disabled context, this
        becomes a HALT instruction.
        becomes a HALT instruction.
</TABLE>
 
\end{tabular}
\end{tabular}
\caption{Derived Instructions, continued}\label{tbl:derived-3}
\caption{Derived Instructions, continued}\label{tbl:derived-3}
\end{center}\end{table}
\end{center}\end{table}
\iffalse
\iffalse
\fi
\fi
Line 825... Line 868...
        ever changes.  Stalls are also created here if the instruction isn't
        ever changes.  Stalls are also created here if the instruction isn't
        in the prefetch cache.
        in the prefetch cache.
\item {\bf Decode}: Decode instruction into op code, register(s) to read, and
\item {\bf Decode}: Decode instruction into op code, register(s) to read, and
        immediate offset.
        immediate offset.
\item {\bf Read Operands}: Read registers and apply any immediate values to
\item {\bf Read Operands}: Read registers and apply any immediate values to
        them.  This stage will stall if any source operand is pending.
        them.  There is no means of detecting or flagging arithmetic overflow
 
        or carry when adding the immediate to the operand.  This stage will
 
        stall if any source operand is pending.
        A proper optimizing compiler, therefore, will schedule an instruction
        A proper optimizing compiler, therefore, will schedule an instruction
        between the instruction that produces the result and the instruction
        between the instruction that produces the result and the instruction
        that uses it.
        that uses it.
\item Split into two tracks: An {\bf ALU} which will accomplish a simple
\item Split into two tracks: An {\bf ALU} which will accomplish a simple
        instruction, and the {\bf MemOps} stage which accomplishes memory
        instruction, and the {\bf MemOps} stage which accomplishes memory
Line 839... Line 884...
                written to the register set.
                written to the register set.
        \item Condition codes are available upon completion
        \item Condition codes are available upon completion
        \item Issuing an instruction to the memory while the memory is busy will
        \item Issuing an instruction to the memory while the memory is busy will
                stall the bus.  If the bus deadlocks, only a reset will
                stall the bus.  If the bus deadlocks, only a reset will
                release the CPU.  (Watchdog timer, anyone?)
                release the CPU.  (Watchdog timer, anyone?)
 
        \item The Zip CPU currently has no means of reading and acting on any
 
        error conditions on the bus.
        \end{itemize}
        \end{itemize}
\item {\bf Write-Back}: Conditionally write back the result to register set,
\item {\bf Write-Back}: Conditionally write back the result to register set,
        applying the condition.  This routine is bi-re-entrant: either the
        applying the condition.  This routine is bi-re-entrant: either the
        memory or the simple instruction may request a register write.
        memory or the simple instruction may request a register write.
\end{enumerate}
\end{enumerate}
 
 
 
The Zip CPU does not support out of order execution.  Therefore, if the memory
 
unit stalls, every other instruction stalls.  Memory stores, however, can take
 
place concurrently with ALU operations, although memory writes cannot.
 
 
\section{Pipeline Logic}
\section{Pipeline Logic}
How the CPU handles some instruction combinations can be telling when
How the CPU handles some instruction combinations can be telling when
determining what happens in the pipeline.  The following lists some examples:
determining what happens in the pipeline.  The following lists some examples:
\begin{itemize}
\begin{itemize}
\item {\bf Delayed Branching}
\item {\bf Delayed Branching}
Line 989... Line 1040...
\end{itemize}
\end{itemize}
 
 
 
 
 
 
\chapter{Peripherals}\label{chap:periph}
\chapter{Peripherals}\label{chap:periph}
 
 
 
While the previous chapter describes a CPU in isolation, the Zip System
 
includes a minimum set of peripherals as well.  These peripherals are shown
 
in Fig.~\ref{fig:zipsystem}
 
\begin{figure}\begin{center}
 
\includegraphics[width=3.5in]{../gfx/system.eps}
 
\caption{Zip System Peripherals}\label{fig:zipsystem}
 
\end{center}\end{figure}
 
and described here.  They are designed to make
 
the Zip CPU more useful in an Embedded Operating System environment.
 
 
\section{Interrupt Controller}
\section{Interrupt Controller}
 
 
 
Perhaps the most important peripheral within the Zip System is the interrupt
 
controller.  While the Zip CPU itself can only handle one interrupt, and has
 
only the one interrupt state: disabled or enabled, the interrupt controller
 
can make things more interesting.
 
 
 
The Zip System interrupt controller module supports up to 15 interrupts, all
 
controlled from one register.  Bit~31 of the interrupt controller controls
 
overall whether interrupts are enabled (1'b1) or disabled (1'b0).  Bits~16--30
 
control whether individual interrupts are enabled (1'b0) or disabled (1'b0).
 
Bit~15 is an indicator showing whether or not any interrupt is active, and
 
bits~0--15 indicate whether or not an individual interrupt is active.
 
 
 
The interrupt controller has been designed so that bits can be controlled
 
individually without having any knowledge of the rest of the controller
 
setting.  To enable an interrupt, write to the register with the high order
 
global enable bit set and the respective interrupt enable bit set.  No other
 
bits will be affected.  To disable an interrupt, write to the register with
 
the high order global enable bit cleared and the respective interrupt enable
 
bit set.  To clear an interrupt, write a `1' to that interrupts status pin.
 
Zero's written to the register have no affect, save that a zero written to the
 
master enable will disable all interrupts.
 
 
 
As an example, suppose you wished to enable interrupt \#4.  You would then
 
write to the register a {\tt 0x80100010} to enable interrupt \#4 and to clear
 
any past active state.  When you later wish to disable this interrupt, you would
 
write a {\tt 0x00100010} to the register.  As before, this both disables the
 
interrupt and clears the active indicator.  This also has the side effect of
 
disabling all interrupts, so a second write of {\tt 0x80000000} may be necessary
 
to re-enable any other interrupts.
 
 
 
The Zip System currently hosts two interrupt controllers, a primary and a
 
secondary.  The primary interrupt controller has one interrupt line which may
 
come from an external interrupt controller, and one interrupt line from the
 
secondary controller.  Other primary interrupts include the system timers,
 
the jiffies interrupt, and the manual cache interrupt.  The secondary interrupt
 
controller maintains an interrupt state for all of the processor accounting
 
counters.
 
 
\section{Counter}
\section{Counter}
 
 
The Zip Counter is a very simple counter: it just counts.  It cannot be
The Zip Counter is a very simple counter: it just counts.  It cannot be
halted.  When it rolls over, it issues an interrupt.  Writing a value to the
halted.  When it rolls over, it issues an interrupt.  Writing a value to the
counter just sets the current value, and it starts counting again from that
counter just sets the current value, and it starts counting again from that
Line 1010... Line 1111...
Writing any non-zero value to the timer starts the timer.  If the high order
Writing any non-zero value to the timer starts the timer.  If the high order
bit is set when writing to the timer, the timer becomes an interval timer and
bit is set when writing to the timer, the timer becomes an interval timer and
reloads its last start time on any interrupt.  Hence, to mark seconds, one
reloads its last start time on any interrupt.  Hence, to mark seconds, one
might set the timer to 100~million (the number of clocks per second), and
might set the timer to 100~million (the number of clocks per second), and
set the high bit.  Ever after, the timer will interrupt the CPU once per
set the high bit.  Ever after, the timer will interrupt the CPU once per
second (assuming a 100~MHz clock).
second (assuming a 100~MHz clock).  This reload capability also limits the
 
maximum timer value to $2^{31}-1$, rather than $2^{32}-1$.
 
 
\section{Watchdog Timer}
\section{Watchdog Timer}
 
 
The watchdog timer is no different from any of the other timers, save for one
The watchdog timer is no different from any of the other timers, save for one
critical difference: the interrupt line from the watchdog
critical difference: the interrupt line from the watchdog
Line 1030... Line 1132...
 
 
This peripheral is motivated by the Linux use of `jiffies' whereby a process
This peripheral is motivated by the Linux use of `jiffies' whereby a process
can request to be put to sleep until a certain number of `jiffies' have
can request to be put to sleep until a certain number of `jiffies' have
elapsed.  Using this interface, the CPU can read the number of `jiffies'
elapsed.  Using this interface, the CPU can read the number of `jiffies'
from the peripheral (it only has the one location in address space), add the
from the peripheral (it only has the one location in address space), add the
sleep length to it, and write teh result back to the peripheral.  The zipjiffies
sleep length to it, and write the result back to the peripheral.  The zipjiffies
peripheral will record the value written to it only if it is nearer the current
peripheral will record the value written to it only if it is nearer the current
counter value than the last current waiting interrupt time.  If no other
counter value than the last current waiting interrupt time.  If no other
interrupts are waiting, and this time is in the future, it will be enabled.
interrupts are waiting, and this time is in the future, it will be enabled.
(There is currently no way to disable a jiffie interrupt once set, other
(There is currently no way to disable a jiffie interrupt once set, other
than to disable the register in the interrupt controller.)  The processor
than to disable the interrupt line in the interrupt controller.)  The processor
may then place this sleep request into a list among other sleep requests.
may then place this sleep request into a list among other sleep requests.
Once the timer expires, it would write the next Jiffy request to the peripheral
Once the timer expires, it would write the next Jiffy request to the peripheral
and wake up the process whose timer had expired.
and wake up the process whose timer had expired.
 
 
Indeed, the Jiffies register is nothing more than a glorified counter with
Indeed, the Jiffies register is nothing more than a glorified counter with
Line 1055... Line 1157...
O/S must also keep track of values written to the Jiffies register.  Thus,
O/S must also keep track of values written to the Jiffies register.  Thus,
when an `alarm' trips, it should be remoed from the list of alarms, the list
when an `alarm' trips, it should be remoed from the list of alarms, the list
should be sorted, and the next alarm in terms of Jiffies should be written
should be sorted, and the next alarm in terms of Jiffies should be written
to the register.
to the register.
 
 
 
\section{Manual Cache}
 
 
 
The manual cache is an experimental setting that may not remain with the Zip
 
CPU for very long.  It is designed to facilitate running from FLASH or ROM
 
memory, although the pipe cache really makes this need obsolete.  The manual
 
cache works by copying data from a wishbone address (range) into the cache
 
register, and then by making that memory available as memory to the Zip System.
 
It is a {\em manual cache} because the processor must first specify what
 
memory to copy, and then once copied the processor can only access the cache
 
memory by the cache memory location.  There is no transparency.  It is perhaps
 
best described as a combination DMA controller and local memory.
 
 
 
Worse, this cache is likely going to be removed from the ZipSystem.  Having used
 
the ZipSystem now for some time, I have yet to find a need or use for the manual
 
cache.  I will likely replace this peripheral with a proper DMA controller.
 
 
\chapter{Operation}\label{chap:ops}
\chapter{Operation}\label{chap:ops}
 
 
\chapter{Registers}\label{chap:regs}
\chapter{Registers}\label{chap:regs}
 
 
 
The ZipSystem registers fall into two categories, ZipSystem internal registers
 
accessed via the ZipCPU shown in Tbl.~\ref{tbl:zpregs},
 
\begin{table}[htbp]
 
\begin{center}\begin{reglist}
 
PIC   & {\tt 0xc0000000} & 32 & R/W & Primary Interrupt Controller \\\hline
 
WDT   & {\tt 0xc0000001} & 32 & R/W & Watchdog Timer \\\hline
 
CCHE  & {\tt 0xc0000002} & 32 & R/W & Manual Cache Controller \\\hline
 
CTRIC & {\tt 0xc0000003} & 32 & R/W & Secondary Interrupt Controller \\\hline
 
TMRA  & {\tt 0xc0000004} & 32 & R/W & Timer A\\\hline
 
TMRB  & {\tt 0xc0000005} & 32 & R/W & Timer B\\\hline
 
TMRC  & {\tt 0xc0000006} & 32 & R/W & Timer C\\\hline
 
JIFF  & {\tt 0xc0000007} & 32 & R/W & Jiffies \\\hline
 
MTASK  & {\tt 0xc0000008} & 32 & R/W & Master Task Clock Counter \\\hline
 
MMSTL  & {\tt 0xc0000008} & 32 & R/W & Master Stall Counter \\\hline
 
MPSTL  & {\tt 0xc0000008} & 32 & R/W & Master Pre--Fetch Stall Counter \\\hline
 
MICNT  & {\tt 0xc0000008} & 32 & R/W & Master Instruction Counter\\\hline
 
UTASK  & {\tt 0xc0000008} & 32 & R/W & User Task Clock Counter \\\hline
 
UMSTL  & {\tt 0xc0000008} & 32 & R/W & User Stall Counter \\\hline
 
UPSTL  & {\tt 0xc0000008} & 32 & R/W & User Pre--Fetch Stall Counter \\\hline
 
UICNT  & {\tt 0xc0000008} & 32 & R/W & User Instruction Counter\\\hline
 
Cache  & {\tt 0xc0100000} & & & Base address of the Cache memory\\\hline
 
\end{reglist}
 
\caption{Zip System Internal/Peripheral Registers}\label{tbl:zpregs}
 
\end{center}\end{table}
 
and the two debug registers showin in Tbl.~\ref{tbl:dbgregs}.
 
\begin{table}[htbp]
 
\begin{center}\begin{reglist}
 
ZIPCTRL & 0 & 32 & R/W & Debug Control Register \\\hline
 
ZIPDATA & 1 & 32 & R/W & Debug Data Register \\\hline
 
\end{reglist}
 
\caption{Zip System Debug Registers}\label{tbl:dbgregs}
 
\end{center}\end{table}
 
 
 
 
\chapter{Wishbone Datasheet}\label{chap:wishbone}
\chapter{Wishbone Datasheet}\label{chap:wishbone}
The Zip System supports two wishbone accesses, a slave debug port and a master
The Zip System supports two wishbone accesses, a slave debug port and a master
port for the system itself.  These are shown in Tbl.~\ref{tbl:wishbone-slave}
port for the system itself.  These are shown in Tbl.~\ref{tbl:wishbone-slave}
\begin{table}[htbp]
\begin{table}[htbp]
\begin{center}
\begin{center}
\begin{wishboneds}
\begin{wishboneds}
Revision level of wishbone & WB B4 spec \\\hline
Revision level of wishbone & WB B4 spec \\\hline
Type of interface & Slave, Read/Write, single words only \\\hline
Type of interface & Slave, Read/Write, single words only \\\hline
 
Address Width & 1--bit \\\hline
Port size & 32--bit \\\hline
Port size & 32--bit \\\hline
Port granularity & 32--bit \\\hline
Port granularity & 32--bit \\\hline
Maximum Operand Size & 32--bit \\\hline
Maximum Operand Size & 32--bit \\\hline
Data transfer ordering & (Irrelevant) \\\hline
Data transfer ordering & (Irrelevant) \\\hline
Clock constraints & Works at 100~MHz on a Basys--3 board\\\hline
Clock constraints & Works at 100~MHz on a Basys--3 board\\\hline
Line 1092... Line 1245...
and Tbl.~\ref{tbl:wishbone-master} respectively.
and Tbl.~\ref{tbl:wishbone-master} respectively.
\begin{table}[htbp]
\begin{table}[htbp]
\begin{center}
\begin{center}
\begin{wishboneds}
\begin{wishboneds}
Revision level of wishbone & WB B4 spec \\\hline
Revision level of wishbone & WB B4 spec \\\hline
Type of interface & Master, Read/Write, sometimes pipelined \\\hline
Type of interface & Master, Read/Write, single cycle or pipelined\\\hline
 
Address Width & 32--bit bits \\\hline
Port size & 32--bit \\\hline
Port size & 32--bit \\\hline
Port granularity & 32--bit \\\hline
Port granularity & 32--bit \\\hline
Maximum Operand Size & 32--bit \\\hline
Maximum Operand Size & 32--bit \\\hline
Data transfer ordering & (Irrelevant) \\\hline
Data transfer ordering & (Irrelevant) \\\hline
Clock constraints & Works at 100~MHz on a Basys--3 board\\\hline
Clock constraints & Works at 100~MHz on a Basys--3 board\\\hline
Line 1114... Line 1268...
                \end{tabular}\\\hline
                \end{tabular}\\\hline
\end{wishboneds}
\end{wishboneds}
\caption{Wishbone Datasheet for the CPU as Master}\label{tbl:wishbone-master}
\caption{Wishbone Datasheet for the CPU as Master}\label{tbl:wishbone-master}
\end{center}\end{table}
\end{center}\end{table}
I do not recommend that you connect these together through the interconnect.
I do not recommend that you connect these together through the interconnect.
 
Rather, the debug port of the CPU should be accessible regardless of the state
 
of the master bus.
 
 
The big thing to notice is that both the real time clock and the real time
You may wish to notice that neither the {\tt ERR} nor the {\tt RETRY} wires
date modules act as wishbone slaves, and that all accesses to the registers of
have been implemented.  What this means is that the CPU is currently unable
either module are 32--bit reads and writes.  The address bus does not offer
to detect a bus error condition, and so may stall indefinitely (hang) should
byte level, but rather 32--bit word level resolution.  Select lines are not
it choose to access a value not on the bus, or a peripheral that is not
implemented.  Bit ordering is the normal ordering where bit~31 is the most
yet properly configured.
significant bit and so forth.
 
 
 
\chapter{Clocks}\label{chap:clocks}
\chapter{Clocks}\label{chap:clocks}
 
 
This core is based upon the Basys--3 design.  The Basys--3 development board
This core is based upon the Basys--3 design.  The Basys--3 development board
contains one external 100~MHz clock, which is sufficient to run the ZIP CPU
contains one external 100~MHz clock, which is sufficient to run the ZIP CPU

powered by: WebSVN 2.1.0

© copyright 1999-2022 OpenCores.org, equivalent to Oliscience, all rights reserved. OpenCores®, registered trademark.