%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
%%
|
%%
|
%% Filename: spec.tex
|
%% Filename: spec.tex
|
%%
|
%%
|
%% Project: Zip CPU -- a small, lightweight, RISC CPU soft core
|
%% Project: Zip CPU -- a small, lightweight, RISC CPU soft core
|
%%
|
%%
|
%% Purpose: This LaTeX file contains all of the documentation/description
|
%% Purpose: This LaTeX file contains all of the documentation/description
|
%% currently provided with this Zip CPU soft core. It supercedes
|
%% currently provided with this Zip CPU soft core. It supersedes
|
%% any information about the instruction set or CPUs found
|
%% any information about the instruction set or CPUs found
|
%% elsewhere. It's not nearly as interesting, though, as the PDF
|
%% elsewhere. It's not nearly as interesting, though, as the PDF
|
%% file it creates, so I'd recommend reading that before diving
|
%% file it creates, so I'd recommend reading that before diving
|
%% into this file. You should be able to find the PDF file in
|
%% 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 SVN distribution together with this PDF file and a copy of
|
%% the GPL-3.0 license this file is distributed under. If not,
|
%% the GPL-3.0 license this file is distributed under. If not,
|
%% just type 'make' in the doc directory and it (should) build
|
%% just type 'make' in the doc directory and it (should) build
|
%% without a problem.
|
%% without a problem.
|
%%
|
%%
|
%%
|
%%
|
%% Creator: Dan Gisselquist
|
%% Creator: Dan Gisselquist
|
%% Gisselquist Technology, LLC
|
%% Gisselquist Technology, LLC
|
%%
|
%%
|
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
%%
|
%%
|
%% Copyright (C) 2015, Gisselquist Technology, LLC
|
%% Copyright (C) 2015, Gisselquist Technology, LLC
|
%%
|
%%
|
%% This program is free software (firmware): you can redistribute it and/or
|
%% 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
|
%% 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
|
%% by the Free Software Foundation, either version 3 of the License, or (at
|
%% your option) any later version.
|
%% your option) any later version.
|
%%
|
%%
|
%% This program is distributed in the hope that it will be useful, but WITHOUT
|
%% This program is distributed in the hope that it will be useful, but WITHOUT
|
%% ANY WARRANTY; without even the implied warranty of MERCHANTIBILITY or
|
%% ANY WARRANTY; without even the implied warranty of MERCHANTIBILITY or
|
%% FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
|
%% FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
|
%% for more details.
|
%% for more details.
|
%%
|
%%
|
%% 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. (It's in the $(ROOT)/doc directory, run make with no
|
%% 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
|
%% target there if the PDF file isn't present.) If not, see
|
%% <http://www.gnu.org/licenses/> for a copy.
|
%% <http://www.gnu.org/licenses/> for a copy.
|
%%
|
%%
|
%% License: GPL, v3, as defined and found on www.gnu.org,
|
%% License: GPL, v3, as defined and found on www.gnu.org,
|
%% http://www.gnu.org/licenses/gpl.html
|
%% http://www.gnu.org/licenses/gpl.html
|
%%
|
%%
|
%%
|
%%
|
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
\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.2}
|
\revision{Rev.~0.3}
|
\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
|
|
|
This project is free software (firmware): you can redistribute it and/or
|
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
|
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
|
by the Free Software Foundation, either version 3 of the License, or (at
|
your option) any later version.
|
your option) any later version.
|
|
|
This program is distributed in the hope that it will be useful, but WITHOUT
|
This program is distributed in the hope that it will be useful, but WITHOUT
|
ANY WARRANTY; without even the implied warranty of MERCHANTIBILITY or
|
ANY WARRANTY; without even the implied warranty of MERCHANTIBILITY or
|
FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
|
FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
|
for more details.
|
for more details.
|
|
|
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.3 & 8/22/2015 & Gisselquist & First completed draft\\\hline
|
0.2 & 8/19/2015 & Gisselquist & Still Draft, more complete \\\hline
|
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, RISC--V may be replacing it. 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.
|
I would like to be able to generate Verilog code that can run equivalently
|
I would like to be able to generate Verilog code that can run equivalently
|
on both Xilinx and Altera chips, and that can be easily ported from one
|
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
|
manufacturer's chipsets to another. Even more, before purchasing a chip or a
|
board, I would like to know that my chip works. I would like to build a test
|
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
|
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
|
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.
|
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
|
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
|
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
|
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
|
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
|
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
|
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
|
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
|
about 2,300 LUTs with no peripherals, and 3,200 LUTs with some very basic
|
peripherals.
|
peripherals.
|
|
|
My final reason is that I'm building the Zip CPU as a learning experience. The
|
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
|
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
|
level. For the first time, I am beginning to understand many of the Computer
|
Architecture lessons from years ago.
|
Architecture lessons from years ago.
|
|
|
To summarize: Because I can, because it is open source, because it is light
|
To summarize: Because I can, because it is open source, because it is light
|
weight, and as an exercise in learning.
|
weight, and as an exercise in learning.
|
|
|
\end{preface}
|
\end{preface}
|
|
|
\chapter{Introduction}
|
\chapter{Introduction}
|
\pagenumbering{arabic}
|
\pagenumbering{arabic}
|
\setcounter{page}{1}
|
\setcounter{page}{1}
|
|
|
|
|
The original goal of the ZIP CPU was to be a very simple CPU. You might
|
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.
|
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
|
For this reason, all instructions have been designed to be as simple as
|
possible, and are all designed to be executed in one instruction cycle per
|
possible, and are all designed to be executed in one instruction cycle per
|
instruction, barring pipeline stalls. Indeed, even the bus has been simplified
|
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
|
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
|
resulted in the choice to drop push and pop instructions, pre-increment and
|
post-decrement addressing modes, and more.
|
post-decrement addressing modes, and more.
|
|
|
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. All
|
\item A RISC CPU. There is no microcode for executing instructions. All
|
instructions are designed to be completed in one clock cycle.
|
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}. See Fig.~\ref{fig:cpu}
|
unit, and {\bf Write-back}. See Fig.~\ref{fig:cpu}
|
\begin{figure}\begin{center}
|
\begin{figure}\begin{center}
|
\includegraphics[width=3.5in]{../gfx/cpu.eps}
|
\includegraphics[width=3.5in]{../gfx/cpu.eps}
|
\caption{Zip CPU internal pipeline architecture}\label{fig:cpu}
|
\caption{Zip CPU internal pipeline architecture}\label{fig:cpu}
|
\end{center}\end{figure}
|
\end{center}\end{figure}
|
for a diagram of this structure.
|
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}
|
|
|
Now, however, that I've worked on the Zip CPU for a while, it is not nearly
|
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
|
as simple as I originally hoped. Worse, I've had to adjust to create
|
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 External 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. My chosen interface
|
it, and tell whether it is running or not. My chosen interface
|
includes a second register similar to this control register. This
|
includes a second register similar to this control register. This
|
second register allows the external controller or debugger to examine
|
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
|
be substituted for any other instruction, and substituted back.
|
be substituted for any other instruction, and substituted back.
|
The break is actually difficult: the break instruction cannot be
|
The break is actually difficult: the break instruction cannot be
|
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
|
Incidentally, this break messes with the prefetch cache and the
|
pipeline: if you change an instruction partially through the pipeline,
|
pipeline: if you change an instruction partially through the pipeline,
|
the whole pipeline needs to be cleansed. Likewise if you change
|
the whole pipeline needs to be cleansed. Likewise if you change
|
an instruction in memory, you need to make sure the cache is reloaded
|
an instruction in memory, you need to make sure the cache is reloaded
|
with the new instruction.
|
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
|
instructions in one cycle. I therefore have a prefetch cache that
|
instructions in one cycle. I therefore have a prefetch cache that
|
issues pipelined wishbone accesses to memory and then pushes
|
issues pipelined wishbone accesses to memory and then pushes
|
instructions at the CPU. Sadly, this accounts for about 20\% of the
|
instructions at the CPU. Sadly, this accounts for about 20\% of the
|
logic in the entire CPU, or 15\% of the logic in the entire system.
|
logic in the entire CPU, or 15\% of the logic in the entire system.
|
|
|
|
|
\item {\bf Operating System:} In order to support an operating system,
|
\item {\bf Operating System:} In order to support an operating system,
|
interrupts and so forth, the CPU needs to support supervisor and
|
interrupts and so forth, the CPU needs to support supervisor and
|
user modes, as well as a means of switching between them. For example,
|
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
|
the user needs a means of executing a system call. This is the
|
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 an external
|
My initial approach to building a trap instruction was to create an external
|
peripheral which, when written to, would generate an interrupt and could
|
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
|
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
|
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
|
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
|
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,
|
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
|
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
|
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
|
to ``announce'' special CPU features (floating point, etc). So the trap
|
instruction still switches to interrupt mode, but the CC register is not
|
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
|
nearly as useful for telling the supervisor mode processor what trap is being
|
executed.
|
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 {\tt zipsystem.v}.
|
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}.
|
The timer module itself is found in {\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
|
all 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 what
|
never stopped. This killed my idea of delayed branching, since what
|
would be the appropriate program counter to restart at? The one the
|
would be the appropriate program counter to restart at? The one the
|
CPU was going to branch to, or the ones in the delay slots? This
|
CPU was going to branch to, or the ones in the delay slots? This
|
also makes the idea of compressed instruction codes difficult, since,
|
also makes the idea of compressed instruction codes difficult, since,
|
again, where do you restart on interrupt?
|
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
|
possibly inappropriate (i.e. a conditional branch preceeding a store
|
possibly inappropriate (i.e. a conditional branch preceding a store
|
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 preceding 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
|
This approach is also different from other pipeline approaches. Instead
|
of keeping the entire pipeline filled, each stage is treated
|
of keeping the entire pipeline filled, each stage is treated
|
independently. Therefore, individual stages may move forward as long
|
independently. Therefore, individual stages may move forward as long
|
as the subsequent stage is available, regardless of whether the stage
|
as the subsequent stage is available, regardless of whether the stage
|
behind it is filled.
|
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.
|
|
|
As an example, the decode module produces a {\em lot} of
|
As an example, the decode module produces a {\em lot} of
|
control wires and registers. Creating a module out of this, with
|
control wires and registers. Creating a module out of this, with
|
only the simplest of logic within it, seemed to be more a lesson
|
only the simplest of logic within it, seemed to be more a lesson
|
in passing wires around, rather than encapsulating logic.
|
in passing wires around, rather than encapsulating logic.
|
|
|
Another example was the register writeback section. I would love
|
Another example was the register writeback section. I would love
|
this section to be a module in its own right, and many have made them
|
this section to be a module in its own right, and many have made them
|
such. However, other modules depend upon writeback results other
|
such. However, other modules depend upon writeback results other
|
than just what's placed in the register (i.e., the control wires).
|
than just what's placed in the register (i.e., the control wires).
|
For these reasons, I didn't manage to fit this section into it's
|
For these reasons, I didn't manage to fit this section into it's
|
own module.
|
own module.
|
|
|
The result is that the majority of the CPU code can be found in
|
The result is that the majority of the CPU code can be found in
|
the {\tt zipcpu.v} file.
|
the {\tt zipcpu.v} file.
|
\end{itemize}
|
\end{itemize}
|
|
|
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 second 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}
|
\section{Simplified Bus}
|
The bus architecture of the Zip CPU is that of a simplified WISHBONE 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.
|
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
|
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
|
are 32--bits. All instructions are also 32--bits wide. Everything has been
|
built around the 32--bit word.
|
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 as shown in Fig.~\ref{fig:regset}.
|
and a user set as shown in Fig.~\ref{fig:regset}.
|
\begin{figure}\begin{center}
|
\begin{figure}\begin{center}
|
\includegraphics[width=3.5in]{../gfx/regset.eps}
|
\includegraphics[width=3.5in]{../gfx/regset.eps}
|
\caption{Zip CPU Register File}\label{fig:regset}
|
\caption{Zip CPU Register File}\label{fig:regset}
|
\end{center}\end{figure}
|
\end{center}\end{figure}
|
The supervisor set is used in interrupt mode when interrupts are disabled,
|
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
|
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
|
Counter (PC) is register 15, whereas the status register (SR) or condition
|
code register
|
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 there is nothing special about this register other
|
noted as (SP)--although there is nothing special about this register other
|
than this convention.
|
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
|
10 bits of the status register form a set of CPU state and condition codes.
|
10 bits of the status register form a set of CPU state and condition codes.
|
Writes to other bits of this register are preserved.
|
Writes to other bits of this register are preserved.
|
|
|
Of the eight condition codes, the bottom four are the current flags:
|
Of the condition codes, the bottom four bits are the current flags:
|
Zero (Z),
|
Zero (Z),
|
Carry (C),
|
Carry (C),
|
Negative (N),
|
Negative (N),
|
and Overflow (V).
|
and Overflow (V).
|
|
|
The next bit is a clock enable (0 to enable) or sleep bit (1 to put
|
The next bit is a clock enable (0 to enable) or sleep bit (1 to put
|
the CPU to sleep). Setting this bit will cause the CPU to
|
the CPU to sleep). Setting this bit will cause the CPU to
|
wait for an interrupt (if interrupts are enabled), or to
|
wait for an interrupt (if interrupts are enabled), or to
|
completely halt (if interrupts are disabled).
|
completely halt (if interrupts are disabled).
|
|
|
The sixth bit is a global interrupt enable bit (GIE). When this
|
The sixth bit is a global interrupt enable bit (GIE). When this
|
sixth bit is a `1' interrupts will be enabled, else disabled. When
|
sixth bit is a `1' interrupts will be enabled, else disabled. When
|
interrupts are disabled, the CPU will be in supervisor mode, otherwise
|
interrupts are disabled, the CPU will be in supervisor mode, otherwise
|
it is in user mode. Thus, to execute a context switch, one only
|
it is in user mode. Thus, to execute a context switch, one only
|
need enable or disable interrupts. (When an interrupt line goes
|
need enable or disable interrupts. (When an interrupt line goes
|
high, interrupts will automatically be disabled, as the CPU goes
|
high, interrupts will automatically be disabled, as the CPU goes
|
and deals with its context switch.) Special logic has been added to
|
and deals with its context switch.) Special logic has been added to
|
keep the user mode from setting the sleep register and clearing the
|
keep the user mode from setting the sleep register and clearing the
|
GIE register at the same time, with clearing the GIE register taking
|
GIE register at the same time, with clearing the GIE register taking
|
precedence.
|
precedence.
|
|
|
The seventh bit is a step bit. This bit can be
|
The seventh bit is a step bit. This bit can be
|
set from supervisor mode only. After setting this bit, should
|
set from supervisor mode only. After setting this bit, should
|
the supervisor mode process switch to user mode, it would then
|
the supervisor mode process switch to user mode, it would then
|
accomplish one instruction in user mode before returning to supervisor
|
accomplish one instruction in user mode before returning to supervisor
|
mode. Then, upon return to supervisor mode, this bit will
|
mode. Then, upon return to supervisor mode, this bit will
|
be automatically cleared. This bit has no effect on the CPU while in
|
be automatically cleared. This bit has no effect on the CPU while in
|
supervisor mode.
|
supervisor mode.
|
|
|
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 controls whether a break
|
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
|
instruction in user mode will halt the processor for an external debugger
|
(break enabled), or whether the break instruction will simply send send the
|
(break enabled), or whether the break instruction will simply send send the
|
CPU into interrupt mode. Encountering a break in supervisor mode will
|
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
|
halt the CPU independent of the break enable bit. This bit can only be set
|
within supervisor mode.
|
within supervisor mode.
|
|
|
% Should break enable be a supervisor mode bit, while the break enable bit
|
% Should break enable be a supervisor mode bit, while the break enable bit
|
% in user mode is a break has taken place bit?
|
% in user mode is a break has taken place bit?
|
%
|
%
|
|
|
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
|
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
|
in this fashion, such as two by 16--bit vector operations or four by 8--bit
|
vector operations.
|
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.
|
|
|
These status register bits are summarized in Tbl.~\ref{tbl:ccbits}.
|
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 returning to user mode\\\hline
|
8 & (Reserved for) Floating point enable \\\hline
|
8 & (Reserved for) Floating point enable \\\hline
|
7 & Halt on break, to support an external debugger \\\hline
|
7 & Halt on break, to support an external debugger \\\hline
|
6 & Step, single step the CPU in user mode\\\hline
|
6 & Step, single step the CPU in user mode\\\hline
|
5 & GIE, or Global Interrupt Enable \\\hline
|
5 & GIE, or Global Interrupt Enable \\\hline
|
4 & Sleep \\\hline
|
4 & Sleep \\\hline
|
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}
|
\caption{Condition Code / Status Register Bits}\label{tbl:ccbits}
|
\caption{Condition Code / Status Register Bits}\label{tbl:ccbits}
|
\end{center}\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}
|
\begin{center}
|
\begin{center}
|
\begin{tabular}{l|l|l}
|
\begin{tabular}{l|l|l}
|
Code & Mneumonic & Condition \\\hline
|
Code & Mneumonic & Condition \\\hline
|
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' 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. Sorry,
|
There is no condition code for less than or equal, not C or not V. Sorry,
|
I ran out of space in 3--bits. Using these conditions will take an extra
|
I ran out of space in 3--bits. Using these conditions will take an extra
|
instruction and a pipeline stall. (Ex: \hbox{\em (Stall)}; \hbox{\tt TST \$4,CC;} \hbox{\tt STO.NZ R0,(R1)})
|
instruction and a pipeline stall. (Ex: \hbox{\em (Stall)}; \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|}{20--bit 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
|
Sixteen and twenty bit immediate values don't make sense for all instructions.
|
example, what is the point of a 20--bit immediate when executing a 16--bit
|
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
|
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
|
or arithmetic shift? In these cases, the extra bits are reserved for future
|
instruction possibilities.
|
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,\footnote{The two clocks figure
|
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.
|
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
|
That write is either from the memory unit or the ALU, but never both.} these
|
addressing modes have been
|
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
|
Each of these instructions can be emulated with a set of instructions from the
|
existing set.
|
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 mode.
|
the CPU needs access to non--supervisory registers while in supervisory mode.
|
Therefore, the MOV instruction is special and offers access to these registers
|
Therefore, the MOV instruction is special and offers access to these registers
|
\ldots when in supervisory mode. To keep the compiler simple, the extra bits
|
\ldots when in supervisory mode. To keep the compiler simple, the extra bits
|
are ignored in non-supervisory mode (as though they didn't exist), rather than
|
are ignored in non-supervisory mode (as though they didn't exist), rather than
|
being mapped to new instructions or additional capabilities. The bits
|
being mapped to new instructions or additional capabilities. The bits
|
indicating which register set each register lies within are the A-Usr and
|
indicating which register set each register lies within are the A-Usr and
|
B-Usr bits. When set to a one, these refer to a user mode register. When set
|
B-Usr bits. When set to a one, these refer to a user mode register. When set
|
to a zero, these refer to a register in the current mode, whether user or
|
to a zero, these refer to a register in the current mode, whether user or
|
supervisor. Further, because a load immediate instruction exists, there is no
|
supervisor. Further, because a load immediate instruction exists, there is no
|
move capability between an immediate and a register: all moves come from either
|
move capability between an immediate and a register: all moves come from either
|
a register or a register plus an offset.
|
a register or a register plus an offset.
|
|
|
This actually leads to a bit of a problem: since the MOV instruction encodes
|
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
|
which register set each register is coming from or moving to, how shall a
|
compiler or assembler know how to compile a MOV instruction without knowing
|
compiler or assembler know how to compile a MOV instruction without knowing
|
the mode of the CPU at the time? For this reason, the compiler will assume
|
the mode of the CPU at the time? For this reason, the compiler will assume
|
all MOV registers are supervisor registers, and display them as normal.
|
all MOV registers are supervisor registers, and display them as normal.
|
Anything with the user bit set will be treated as a user register. The CPU
|
Anything with the user bit set will be treated as a user register. The CPU
|
will quietly ignore the supervisor bits while in user mode, and anything
|
will quietly ignore the supervisor bits while in user mode, and anything
|
marked as a user register will always be valid. (Did I just say that in the
|
marked as a user register will always be valid. (Did I just say that in the
|
last paragraph?)
|
last paragraph?)
|
|
|
\section{Multiply Operations}
|
\section{Multiply Operations}
|
The Zip CPU supports two Multiply operations, a
|
The Zip CPU supports two Multiply operations, 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.
|
|
|
\section{Floating Point}
|
\section{Floating Point}
|
The ZIP CPU does not support floating point operations. However, the
|
The ZIP CPU does not support floating point operations. However, the
|
instruction set reserves two possibilities for future floating point
|
instruction set reserves two possibilities for future floating point
|
operations.
|
operations.
|
|
|
The first floating point operation hole in the instruction set involves
|
The first floating point operation hole in the instruction set involves
|
setting the floating point bit in the CC register. The next instruction
|
setting the floating point bit in the CC register. The next instruction
|
will simply interpret its operands as floating point instructions.
|
will simply interpret its operands as floating point instructions.
|
Not all instructions, however, have floating point equivalents. Further, the
|
Not all instructions, however, have floating point equivalents. Further, the
|
immediate fields do not apply in floating point mode, and must be set to
|
immediate fields do not apply in floating point mode, and must be set to
|
zero. Not all instructions make sense as floating point operations.
|
zero. Not all instructions make sense as floating point operations.
|
Therefore, only the CMP, SUB, ADD, and MPY instructions may be issued as
|
Therefore, only the CMP, SUB, ADD, and MPY instructions may be issued as
|
floating point instructions. Other instructions allow the examining of the
|
floating point instructions. Other instructions allow the examining of the
|
floating point bit in the CC register. In all cases, the floating point bit
|
floating point bit in the CC register. In all cases, the floating point bit
|
is cleared one instruction after it is set.
|
is cleared one instruction after it is set.
|
|
|
The other possibility for floating point operations involves exploiting the
|
The other possibility for floating point operations involves exploiting the
|
hole in the instruction set that the NOOP and BREAK instructions reside within.
|
hole in the instruction set that the NOOP and BREAK instructions reside within.
|
These two instructions use 24--bits of address space. A simple adjustment
|
These two instructions use 24--bits of address space. A simple adjustment
|
to this space could create instructions with 4--bit register addresses for
|
to this space could create instructions with 4--bit register addresses for
|
each register, a 3--bit field for conditional execution, and a 2--bit field
|
each register, a 3--bit field for conditional execution, and a 2--bit field
|
for which operation. In this fashion, such a floating point capability would
|
for which operation. In this fashion, such a floating point capability would
|
only fill 13--bits of the 24--bit field, still leaving lots of room for
|
only fill 13--bits of the 24--bit field, still leaving lots of room for
|
expansion.
|
expansion.
|
|
|
In both cases, the Zip CPU would support 32--bit single precision floats
|
In both cases, the Zip CPU would support 32--bit single precision floats
|
only.
|
only.
|
|
|
The current architecture does not support a floating point not-implemented
|
The current architecture does not support a floating point not-implemented
|
interrupt. Any soft floating point emulation must be done deliberately.
|
interrupt. Any soft floating point emulation must be done deliberately.
|
|
|
\section{Native Instructions}
|
\section{Native Instructions}
|
The instruction set for the Zip CPU is summarized in
|
The instruction set for the Zip CPU is summarized in
|
Tbl.~\ref{tbl:zip-instructions}.
|
Tbl.~\ref{tbl:zip-instructions}.
|
\begin{table}\begin{center}
|
\begin{table}\begin{center}
|
\begin{tabular}{|l|l|l|l|l|l|l|l|l|l|l|l|l|l|l|l|l|l|l|l|l|l|l|l|l|l|l|l|l|l|l|l|l|c|}\hline
|
\begin{tabular}{|l|l|l|l|l|l|l|l|l|l|l|l|l|l|l|l|l|l|l|l|l|l|l|l|l|l|l|l|l|l|l|l|l|c|}\hline
|
Op Code & \multicolumn{8}{c|}{31\ldots24} & \multicolumn{8}{c|}{23\ldots 16}
|
Op Code & \multicolumn{8}{c|}{31\ldots24} & \multicolumn{8}{c|}{23\ldots 16}
|
& \multicolumn{8}{c|}{15\ldots 8} & \multicolumn{8}{c|}{7\ldots 0}
|
& \multicolumn{8}{c|}{15\ldots 8} & \multicolumn{8}{c|}{7\ldots 0}
|
& Sets CC? \\\hline
|
& Sets CC? \\\hline
|
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
|
TST(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}
|
& \multicolumn{4}{l|}{D. Reg}
|
& \multicolumn{4}{l|}{D. Reg}
|
& \multicolumn{3}{l|}{Cond.}
|
& \multicolumn{3}{l|}{Cond.}
|
& A-Usr
|
& A-Usr
|
& \multicolumn{4}{l|}{B-Reg}
|
& \multicolumn{4}{l|}{B-Reg}
|
& B-Usr
|
& B-Usr
|
& \multicolumn{15}{l|}{15'bit signed offset}
|
& \multicolumn{15}{l|}{15'bit signed offset}
|
& \\\hline
|
& \\\hline
|
LODI & \multicolumn{4}{l|}{4'h3}
|
LODI & \multicolumn{4}{l|}{4'h3}
|
& \multicolumn{4}{l|}{R. Reg}
|
& \multicolumn{4}{l|}{R. Reg}
|
& \multicolumn{24}{l|}{24'bit Signed Immediate}
|
& \multicolumn{24}{l|}{24'bit Signed Immediate}
|
& \\\hline
|
& \\\hline
|
NOOP & \multicolumn{4}{l|}{4'h4}
|
NOOP & \multicolumn{4}{l|}{4'h4}
|
& \multicolumn{4}{l|}{4'he}
|
& \multicolumn{4}{l|}{4'he}
|
& \multicolumn{24}{l|}{24'h00}
|
& \multicolumn{24}{l|}{24'h00}
|
& \\\hline
|
& \\\hline
|
BREAK & \multicolumn{4}{l|}{4'h4}
|
BREAK & \multicolumn{4}{l|}{4'h4}
|
& \multicolumn{4}{l|}{4'he}
|
& \multicolumn{4}{l|}{4'he}
|
& \multicolumn{24}{l|}{24'h01}
|
& \multicolumn{24}{l|}{24'h01}
|
& \\\hline
|
& \\\hline
|
{\em Rsrd} & \multicolumn{4}{l|}{4'h4}
|
{\em Rsrd} & \multicolumn{4}{l|}{4'h4}
|
& \multicolumn{4}{l|}{4'he}
|
& \multicolumn{4}{l|}{4'he}
|
& \multicolumn{24}{l|}{24'bits, but not 0 or 1.}
|
& \multicolumn{24}{l|}{24'bits, but not 0 or 1.}
|
& \\\hline
|
& \\\hline
|
LODIHI & \multicolumn{4}{l|}{4'h4}
|
LODIHI & \multicolumn{4}{l|}{4'h4}
|
& \multicolumn{4}{l|}{4'hf}
|
& \multicolumn{4}{l|}{4'hf}
|
& \multicolumn{3}{l|}{Cond.}
|
& \multicolumn{3}{l|}{Cond.}
|
& 1'b1
|
& 1'b1
|
& \multicolumn{4}{l|}{R. Reg}
|
& \multicolumn{4}{l|}{R. Reg}
|
& \multicolumn{16}{l|}{16-bit Immediate}
|
& \multicolumn{16}{l|}{16-bit Immediate}
|
& \\\hline
|
& \\\hline
|
LODILO & \multicolumn{4}{l|}{4'h4}
|
LODILO & \multicolumn{4}{l|}{4'h4}
|
& \multicolumn{4}{l|}{4'hf}
|
& \multicolumn{4}{l|}{4'hf}
|
& \multicolumn{3}{l|}{Cond.}
|
& \multicolumn{3}{l|}{Cond.}
|
& 1'b0
|
& 1'b0
|
& \multicolumn{4}{l|}{R. Reg}
|
& \multicolumn{4}{l|}{R. Reg}
|
& \multicolumn{16}{l|}{16-bit Immediate}
|
& \multicolumn{16}{l|}{16-bit Immediate}
|
& \\\hline
|
& \\\hline
|
16-b MPYU & \multicolumn{4}{l|}{4'h4}
|
16-b MPYU & \multicolumn{4}{l|}{4'h4}
|
& \multicolumn{4}{l|}{R. Reg}
|
& \multicolumn{4}{l|}{R. Reg}
|
& \multicolumn{3}{l|}{Cond.}
|
& \multicolumn{3}{l|}{Cond.}
|
& 1'b0 & \multicolumn{4}{l|}{Reg}
|
& 1'b0 & \multicolumn{4}{l|}{Reg}
|
& \multicolumn{16}{l|}{16-bit Offset}
|
& \multicolumn{16}{l|}{16-bit Offset}
|
& Yes \\\hline
|
& Yes \\\hline
|
16-b MPYU(I) & \multicolumn{4}{l|}{4'h4}
|
16-b MPYU(I) & \multicolumn{4}{l|}{4'h4}
|
& \multicolumn{4}{l|}{R. Reg}
|
& \multicolumn{4}{l|}{R. Reg}
|
& \multicolumn{3}{l|}{Cond.}
|
& \multicolumn{3}{l|}{Cond.}
|
& 1'b0 & \multicolumn{4}{l|}{4'hf}
|
& 1'b0 & \multicolumn{4}{l|}{4'hf}
|
& \multicolumn{16}{l|}{16-bit Offset}
|
& \multicolumn{16}{l|}{16-bit Offset}
|
& Yes \\\hline
|
& Yes \\\hline
|
16-b MPYS & \multicolumn{4}{l|}{4'h4}
|
16-b MPYS & \multicolumn{4}{l|}{4'h4}
|
& \multicolumn{4}{l|}{R. Reg}
|
& \multicolumn{4}{l|}{R. Reg}
|
& \multicolumn{3}{l|}{Cond.}
|
& \multicolumn{3}{l|}{Cond.}
|
& 1'b1 & \multicolumn{4}{l|}{Reg}
|
& 1'b1 & \multicolumn{4}{l|}{Reg}
|
& \multicolumn{16}{l|}{16-bit Offset}
|
& \multicolumn{16}{l|}{16-bit Offset}
|
& Yes \\\hline
|
& Yes \\\hline
|
16-b MPYS(I) & \multicolumn{4}{l|}{4'h4}
|
16-b MPYS(I) & \multicolumn{4}{l|}{4'h4}
|
& \multicolumn{4}{l|}{R. Reg}
|
& \multicolumn{4}{l|}{R. Reg}
|
& \multicolumn{3}{l|}{Cond.}
|
& \multicolumn{3}{l|}{Cond.}
|
& 1'b1 & \multicolumn{4}{l|}{4'hf}
|
& 1'b1 & \multicolumn{4}{l|}{4'hf}
|
& \multicolumn{16}{l|}{16-bit Offset}
|
& \multicolumn{16}{l|}{16-bit Offset}
|
& Yes \\\hline
|
& Yes \\\hline
|
ROL & \multicolumn{4}{l|}{4'h5}
|
ROL & \multicolumn{4}{l|}{4'h5}
|
& \multicolumn{4}{l|}{R. Reg}
|
& \multicolumn{4}{l|}{R. Reg}
|
& \multicolumn{3}{l|}{Cond.}
|
& \multicolumn{3}{l|}{Cond.}
|
& \multicolumn{21}{l|}{Operand B, truncated to low order 5 bits}
|
& \multicolumn{21}{l|}{Operand B, truncated to low order 5 bits}
|
& \\\hline
|
& \\\hline
|
LOD & \multicolumn{4}{l|}{4'h6}
|
LOD & \multicolumn{4}{l|}{4'h6}
|
& \multicolumn{4}{l|}{R. Reg}
|
& \multicolumn{4}{l|}{R. Reg}
|
& \multicolumn{3}{l|}{Cond.}
|
& \multicolumn{3}{l|}{Cond.}
|
& \multicolumn{21}{l|}{Operand B address}
|
& \multicolumn{21}{l|}{Operand B address}
|
& \\\hline
|
& \\\hline
|
STO & \multicolumn{4}{l|}{4'h7}
|
STO & \multicolumn{4}{l|}{4'h7}
|
& \multicolumn{4}{l|}{D. Reg}
|
& \multicolumn{4}{l|}{D. Reg}
|
& \multicolumn{3}{l|}{Cond.}
|
& \multicolumn{3}{l|}{Cond.}
|
& \multicolumn{21}{l|}{Operand B address}
|
& \multicolumn{21}{l|}{Operand B address}
|
& \\\hline
|
& \\\hline
|
SUB & \multicolumn{4}{l|}{4'h8}
|
SUB & \multicolumn{4}{l|}{4'h8}
|
& \multicolumn{4}{l|}{R. Reg}
|
& \multicolumn{4}{l|}{R. Reg}
|
& \multicolumn{3}{l|}{Cond.}
|
& \multicolumn{3}{l|}{Cond.}
|
& \multicolumn{21}{l|}{Operand B}
|
& \multicolumn{21}{l|}{Operand B}
|
& Yes \\\hline
|
& Yes \\\hline
|
AND & \multicolumn{4}{l|}{4'h9}
|
AND & \multicolumn{4}{l|}{4'h9}
|
& \multicolumn{4}{l|}{R. Reg}
|
& \multicolumn{4}{l|}{R. Reg}
|
& \multicolumn{3}{l|}{Cond.}
|
& \multicolumn{3}{l|}{Cond.}
|
& \multicolumn{21}{l|}{Operand B}
|
& \multicolumn{21}{l|}{Operand B}
|
& Yes \\\hline
|
& Yes \\\hline
|
ADD & \multicolumn{4}{l|}{4'ha}
|
ADD & \multicolumn{4}{l|}{4'ha}
|
& \multicolumn{4}{l|}{R. Reg}
|
& \multicolumn{4}{l|}{R. Reg}
|
& \multicolumn{3}{l|}{Cond.}
|
& \multicolumn{3}{l|}{Cond.}
|
& \multicolumn{21}{l|}{Operand B}
|
& \multicolumn{21}{l|}{Operand B}
|
& Yes \\\hline
|
& Yes \\\hline
|
OR & \multicolumn{4}{l|}{4'hb}
|
OR & \multicolumn{4}{l|}{4'hb}
|
& \multicolumn{4}{l|}{R. Reg}
|
& \multicolumn{4}{l|}{R. Reg}
|
& \multicolumn{3}{l|}{Cond.}
|
& \multicolumn{3}{l|}{Cond.}
|
& \multicolumn{21}{l|}{Operand B}
|
& \multicolumn{21}{l|}{Operand B}
|
& Yes \\\hline
|
& Yes \\\hline
|
XOR & \multicolumn{4}{l|}{4'hc}
|
XOR & \multicolumn{4}{l|}{4'hc}
|
& \multicolumn{4}{l|}{R. Reg}
|
& \multicolumn{4}{l|}{R. Reg}
|
& \multicolumn{3}{l|}{Cond.}
|
& \multicolumn{3}{l|}{Cond.}
|
& \multicolumn{21}{l|}{Operand B}
|
& \multicolumn{21}{l|}{Operand B}
|
& Yes \\\hline
|
& Yes \\\hline
|
LSL/ASL & \multicolumn{4}{l|}{4'hd}
|
LSL/ASL & \multicolumn{4}{l|}{4'hd}
|
& \multicolumn{4}{l|}{R. Reg}
|
& \multicolumn{4}{l|}{R. Reg}
|
& \multicolumn{3}{l|}{Cond.}
|
& \multicolumn{3}{l|}{Cond.}
|
& \multicolumn{21}{l|}{Operand B, imm. trucated to 6 bits}
|
& \multicolumn{21}{l|}{Operand B, imm. truncated to 6 bits}
|
& Yes \\\hline
|
& Yes \\\hline
|
ASR & \multicolumn{4}{l|}{4'he}
|
ASR & \multicolumn{4}{l|}{4'he}
|
& \multicolumn{4}{l|}{R. Reg}
|
& \multicolumn{4}{l|}{R. Reg}
|
& \multicolumn{3}{l|}{Cond.}
|
& \multicolumn{3}{l|}{Cond.}
|
& \multicolumn{21}{l|}{Operand B, imm. trucated to 6 bits}
|
& \multicolumn{21}{l|}{Operand B, imm. truncated to 6 bits}
|
& Yes \\\hline
|
& Yes \\\hline
|
LSR & \multicolumn{4}{l|}{4'hf}
|
LSR & \multicolumn{4}{l|}{4'hf}
|
& \multicolumn{4}{l|}{R. Reg}
|
& \multicolumn{4}{l|}{R. Reg}
|
& \multicolumn{3}{l|}{Cond.}
|
& \multicolumn{3}{l|}{Cond.}
|
& \multicolumn{21}{l|}{Operand B, imm. trucated to 6 bits}
|
& \multicolumn{21}{l|}{Operand B, imm. truncated to 6 bits}
|
& Yes \\\hline
|
& Yes \\\hline
|
\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 are the only instructions within one particular
|
NOOP and BREAK instructions are the only instructions within one particular
|
24--bit hole. This spaces are reserved for future enhancements. For example,
|
24--bit hole. This spaces are reserved for future enhancements. For example,
|
floating point operations, consisting of a 3-bit floating point operation,
|
floating point operations, consisting of a 3-bit floating point operation,
|
two 4-bit registers, no immediate offset, and a 3-bit condition would fit
|
two 4-bit registers, no immediate offset, and a 3-bit condition would fit
|
nicely into 14--bits of this address space--making it so that the floating
|
nicely into 14--bits of this address space--making it so that the floating
|
point bit in the CC register need not be used.
|
point bit in the CC register need not be used.
|
|
|
\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 cycle 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}
|
\begin{tabular}{p{1.4in}p{1.5in}p{3in}}\\\hline
|
\begin{tabular}{p{1.4in}p{1.5in}p{3in}}\\\hline
|
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
|
& \hbox{Mov.cond \$Addr+PC,PC}
|
& \hbox{MOV.cond \$Addr+PC,PC}
|
& Branch or jump on condition. Works for 15--bit
|
& Branch or jump on condition. Works for 15--bit
|
signed 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 sets the flags. \\\hline
|
BNC PC+\$Addr
|
BNC PC+\$Addr
|
& \parbox[t]{1.5in}{Test \$Carry,CC \\ MOV.Z PC+\$Addr,PC}
|
& \parbox[t]{1.5in}{Test \$Carry,CC \\ MOV.Z PC+\$Addr,PC}
|
& Example of a branch on an unsupported
|
& Example of a branch on an unsupported
|
condition, in this case a branch on not carry \\\hline
|
condition, in this case a branch on not carry \\\hline
|
BUSY & MOV \$-1(PC),PC & Execute an infinite loop \\\hline
|
BUSY & MOV \$-1(PC),PC & Execute an infinite loop \\\hline
|
CLRF.NZ Rx
|
CLRF.NZ Rx
|
& XOR.NZ Rx,Rx
|
& XOR.NZ Rx,Rx
|
& Clear Rx, and flags, if the Z-bit is not set \\\hline
|
& Clear Rx, and flags, if the Z-bit is not set \\\hline
|
CLR Rx
|
CLR Rx
|
& LDI \$0,Rx
|
& LDI \$0,Rx
|
& Clears Rx, leaves flags untouched. This instruction cannot be
|
& Clears Rx, leaves flags untouched. This instruction cannot be
|
conditional. \\\hline
|
conditional. \\\hline
|
EXCH.W Rx
|
EXCH.W Rx
|
& ROL \$16,Rx
|
& ROL \$16,Rx
|
& Exchanges the top and bottom 16'bit words of Rx \\\hline
|
& Exchanges the top and bottom 16'bit words of Rx \\\hline
|
HALT
|
HALT
|
& Or \$SLEEP,CC
|
& Or \$SLEEP,CC
|
& Executed while in interrupt mode. In user mode this is simply a
|
& Executed while in interrupt mode. In user mode this is simply a
|
wait until interrupt instructioon. \\\hline
|
wait until interrupt instruction. \\\hline
|
INT & LDI \$0,CC
|
INT & LDI \$0,CC
|
& Since we're using the CC register as a trap vector as well, this
|
& Since we're using the CC register as a trap vector as well, this
|
executes TRAP \#0. \\\hline
|
executes TRAP \#0. \\\hline
|
IRET
|
IRET
|
& OR \$GIE,CC
|
& OR \$GIE,CC
|
& Also an RTU instruction (Return to Userspace) \\\hline
|
& Also an RTU instruction (Return to Userspace) \\\hline
|
JMP R6+\$Addr
|
JMP R6+\$Addr
|
& MOV \$Addr(R6),PC
|
& MOV \$Addr(R6),PC
|
& \\\hline
|
& \\\hline
|
JSR PC+\$Addr
|
JSR PC+\$Addr
|
& \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. Note the required cleanup instruction after
|
& Jump to Subroutine. Note the required cleanup instruction after
|
returning. \\\hline
|
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
|
mandatory memory access of the other approach. \\\hline
|
mandatory memory access of the other approach. \\\hline
|
LDI.l \$val,Rx
|
LDI.l \$val,Rx
|
& \parbox[t]{1.5in}{LDIHI (\$val$>>$16)\&0x0ffff, Rx \\
|
& \parbox[t]{1.5in}{LDIHI (\$val$>>$16)\&0x0ffff, Rx \\
|
LDILO (\$val \& 0x0ffff)}
|
LDILO (\$val \& 0x0ffff)}
|
& Sadly, there's not enough instruction
|
& Sadly, there's not enough instruction
|
space to load a complete immediate value into any register.
|
space to load a complete immediate value into any register.
|
Therefore, fully loading any register takes two cycles.
|
Therefore, fully loading any register takes two cycles.
|
The LDIHI (load immediate high) and LDILO (load immediate low)
|
The LDIHI (load immediate high) and LDILO (load immediate low)
|
instructions have been created to facilitate this. \\\hline
|
instructions have been created to facilitate this. \\\hline
|
\end{tabular}
|
\end{tabular}
|
\caption{Derived Instructions}\label{tbl:derived-1}
|
\caption{Derived Instructions}\label{tbl:derived-1}
|
\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
|
Mapped & Actual & Notes \\\hline
|
Mapped & Actual & Notes \\\hline
|
LOD.b \$addr,Rx
|
LOD.b \$addr,Rx
|
& \parbox[t]{1.5in}{%
|
& \parbox[t]{1.5in}{%
|
LDI \$addr,Ra \\
|
LDI \$addr,Ra \\
|
LDI \$addr,Rb \\
|
LDI \$addr,Rb \\
|
LSR \$2,Ra \\
|
LSR \$2,Ra \\
|
AND \$3,Rb \\
|
AND \$3,Rb \\
|
LOD (Ra),Rx \\
|
LOD (Ra),Rx \\
|
LSL \$3,Rb \\
|
LSL \$3,Rb \\
|
SUB \$32,Rb \\
|
SUB \$32,Rb \\
|
ROL Rb,Rx \\
|
ROL Rb,Rx \\
|
AND \$0ffh,Rx}
|
AND \$0ffh,Rx}
|
& \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 in this document are 32-bit wordlength addresses.
|
all other addresses in this document are 32-bit wordlength addresses.
|
For this reason,
|
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 \\
|
LSL \$1,Rx \\
|
LSL \$1,Rx \\
|
OR.C \$1,Ry}
|
OR.C \$1,Ry}
|
& Logical shift left with carry. Note that the
|
& Logical shift left with carry. Note that the
|
instruction order is now backwards, to keep the conditions valid.
|
instruction order is now backwards, to keep the conditions valid.
|
That is, LSL sets the carry flag, so if we did this the othe way
|
That is, LSL sets the carry flag, so if we did this the other way
|
with Rx before Ry, then the condition flag wouldn't have been right
|
with Rx before Ry, then the condition flag wouldn't have been right
|
for an OR correction at the end. \\\hline
|
for an OR correction at the end. \\\hline
|
\parbox[t]{1.5in}{LSR \$1,Rx \\ LSRC \$1,Ry}
|
\parbox[t]{1.5in}{LSR \$1,Rx \\ LSRC \$1,Ry}
|
& \parbox[t]{1.5in}{CLR Rz \\
|
& \parbox[t]{1.5in}{CLR Rz \\
|
LSR \$1,Ry \\
|
LSR \$1,Ry \\
|
LDIHI.C \$8000h,Rz \\
|
LDIHI.C \$8000h,Rz \\
|
LSR \$1,Rx \\
|
LSR \$1,Rx \\
|
OR Rz,Rx}
|
OR Rz,Rx}
|
& Logical shift right with carry \\\hline
|
& Logical shift right with carry \\\hline
|
NEG Rx & \parbox[t]{1.5in}{XOR \$-1,Rx \\ ADD \$1,Rx} & \\\hline
|
NEG Rx & \parbox[t]{1.5in}{XOR \$-1,Rx \\ ADD \$1,Rx} & \\\hline
|
NOOP & NOOP & While there are many
|
NOOP & NOOP & While there are many
|
operations that do nothing, such as MOV Rx,Rx, or OR \$0,Rx, these
|
operations that do nothing, such as MOV Rx,Rx, or OR \$0,Rx, these
|
operations have consequences in that they might stall the bus if
|
operations have consequences in that they might stall the bus if
|
Rx isn't ready yet. For this reason, we have a dedicated NOOP
|
Rx isn't ready yet. For this reason, we have a dedicated NOOP
|
instruction. \\\hline
|
instruction. \\\hline
|
NOT Rx & XOR \$-1,Rx & \\\hline
|
NOT Rx & XOR \$-1,Rx & \\\hline
|
POP Rx
|
POP Rx
|
& \parbox[t]{1.5in}{LOD \$-1(SP),Rx \\ ADD \$1,SP}
|
& \parbox[t]{1.5in}{LOD \$-1(SP),Rx \\ ADD \$1,SP}
|
& Note
|
& Note
|
that for interrupt purposes, one can never depend upon the value at
|
that for interrupt purposes, one can never depend upon the value at
|
(SP). Hence you read from it, then increment it, lest having
|
(SP). Hence you read from it, then increment it, lest having
|
incremented it firost something then comes along and writes to that
|
incremented it first something then comes along and writes to that
|
value before you can read the result. \\\hline
|
value before you can read the result. \\\hline
|
PUSH Rx
|
PUSH Rx
|
& \parbox[t]{1.5in}{SUB \$1,SPa \\
|
& \parbox[t]{1.5in}{SUB \$1,SP \\
|
STO Rx,\$1(SP)}
|
STO Rx,\$1(SP)}
|
& \\\hline
|
& \\\hline
|
RESET
|
RESET
|
& \parbox[t]{1in}{STO \$1,\$watchdog(R12)\\NOOP\\NOOP}
|
& \parbox[t]{1in}{STO \$1,\$watchdog(R12)\\NOOP\\NOOP}
|
& \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),PC}
|
RET & \parbox[t]{1.5in}{LOD \$-1(SP),PC}
|
& Note that this depends upon the calling context to clean up the
|
& Note that this depends upon the calling context to clean up the
|
stack, as outlined for the JSR instruction. \\\hline
|
stack, as outlined for the JSR instruction. \\\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
|
RET & MOV R12,PC
|
RET & MOV R12,PC
|
& This is the high(er) speed version, that doesn't touch the stack.
|
& This is the high(er) speed version, that doesn't touch the stack.
|
As such, it doesn't suffer a stall on memory read/write to the stack.
|
As such, it doesn't suffer a stall on memory read/write to the stack.
|
\\\hline
|
\\\hline
|
STEP Rr,Rt
|
STEP Rr,Rt
|
& \parbox[t]{1.5in}{LSR \$1,Rr \\ XOR.C Rt,Rr}
|
& \parbox[t]{1.5in}{LSR \$1,Rr \\ XOR.C Rt,Rr}
|
& Step a Galois implementation of a Linear Feedback Shift Register, Rr,
|
& Step a Galois implementation of a Linear Feedback Shift Register, Rr,
|
using taps Rt \\\hline
|
using taps Rt \\\hline
|
STO.b Rx,\$addr
|
STO.b Rx,\$addr
|
& \parbox[t]{1.5in}{%
|
& \parbox[t]{1.5in}{%
|
LDI \$addr,Ra \\
|
LDI \$addr,Ra \\
|
LDI \$addr,Rb \\
|
LDI \$addr,Rb \\
|
LSR \$2,Ra \\
|
LSR \$2,Ra \\
|
AND \$3,Rb \\
|
AND \$3,Rb \\
|
SUB \$32,Rb \\
|
SUB \$32,Rb \\
|
LOD (Ra),Ry \\
|
LOD (Ra),Ry \\
|
AND \$0ffh,Rx \\
|
AND \$0ffh,Rx \\
|
AND \$-0ffh,Ry \\
|
AND \$-0ffh,Ry \\
|
ROL Rb,Rx \\
|
ROL Rb,Rx \\
|
OR Rx,Ry \\
|
OR Rx,Ry \\
|
STO Ry,(Ra) }
|
STO Ry,(Ra) }
|
& \parbox[t]{3in}{This CPU and it's bus are {\em not} optimized
|
& \parbox[t]{3in}{This CPU and it's bus are {\em not} optimized
|
for byte-wise operations.
|
for byte-wise operations.
|
|
|
Note that in this example, \$addr is a
|
Note that in this example, \$addr is a
|
byte-wise address, whereas in all of our other examples it is a
|
byte-wise address, whereas in all of our other examples it is a
|
32-bit word address. This also limits the address space
|
32-bit word address. This also limits the address space
|
of character accesses from 16 MB down to 4MB.F
|
of character accesses from 16 MB down to 4MB.F
|
Further, this instruction implies a byte ordering,
|
Further, this instruction implies a byte ordering,
|
such as big or little endian.} \\\hline
|
such as big or little endian.} \\\hline
|
SWAP Rx,Ry
|
SWAP Rx,Ry
|
& \parbox[t]{1.5in}{
|
& \parbox[t]{1.5in}{
|
XOR Ry,Rx \\
|
XOR Ry,Rx \\
|
XOR Rx,Ry \\
|
XOR Rx,Ry \\
|
XOR Ry,Rx}
|
XOR Ry,Rx}
|
& 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. The user will need to make certain
|
address. 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
|
TST Rx
|
TST Rx
|
& TST \$-1,Rx
|
& TST \$-1,Rx
|
& Set the condition codes based upon Rx. Could also do a CMP \$0,Rx,
|
& Set the condition codes based upon Rx. Could also do a CMP \$0,Rx,
|
ADD \$0,Rx, SUB \$0,Rx, etc, AND \$-1,Rx, etc. The TST and CMP
|
ADD \$0,Rx, SUB \$0,Rx, etc, AND \$-1,Rx, etc. The TST and CMP
|
approaches won't stall future pipeline stages looking for the value
|
approaches won't stall future pipeline stages looking for the value
|
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.
|
\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
|
\section{Pipeline Stages}
|
\section{Pipeline Stages}
|
As mentioned in the introduction, and highlighted in Fig.~\ref{fig:cpu},
|
As mentioned in the introduction, and highlighted in Fig.~\ref{fig:cpu},
|
the Zip CPU supports a five stage pipeline.
|
the Zip CPU supports a five stage pipeline.
|
\begin{enumerate}
|
\begin{enumerate}
|
\item {\bf Prefetch}: Read instruction from memory (cache if possible). This
|
\item {\bf Prefetch}: Read instruction from memory (cache if possible). This
|
stage is actually pipelined itself, and so it will stall if the PC
|
stage is actually pipelined itself, and so it will stall if the PC
|
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. This stage also determines whether the flags will
|
immediate offset. This stage also determines whether the flags will
|
be set or whether the result will be written back.
|
be set or whether the result will be written back.
|
\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. There is no means of detecting or flagging arithmetic overflow
|
them. There is no means of detecting or flagging arithmetic overflow
|
or carry when adding the immediate to the operand. This stage will
|
or carry when adding the immediate to the operand. This stage will
|
stall if any source operand is pending.
|
stall if any source operand is pending.
|
\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
|
read/write.
|
read/write.
|
\begin{itemize}
|
\begin{itemize}
|
\item Loads stall instructions that access the register until it is
|
\item Loads stall instructions that access the register until it is
|
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 entire pipeline. If the bus deadlocks, only a reset
|
stall the entire pipeline. If the bus deadlocks, only a reset
|
will release the CPU. (Watchdog timer, anyone?)
|
will release the CPU. (Watchdog timer, anyone?)
|
\item The Zip CPU currently has no means of reading and acting on any
|
\item The Zip CPU currently has no means of reading and acting on any
|
error conditions on the bus.
|
error conditions on the bus.
|
\end{itemize}
|
\end{itemize}
|
\item {\bf Write-Back}: Conditionally write back the result to the register
|
\item {\bf Write-Back}: Conditionally write back the result to the register
|
set, applying the condition. This routine is bi-re-entrant: either the
|
set, 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
|
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
|
unit stalls, every other instruction stalls. Memory stores, however, can take
|
place concurrently with ALU operations, although memory reads cannot.
|
place concurrently with ALU operations, although memory reads cannot.
|
|
|
|
\iffalse
|
|
|
\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}
|
|
|
I had originally hoped to implement delayed branching. However, what
|
I had originally hoped to implement delayed branching. My goal
|
happens in debug mode?
|
was that the compiler would handle any pipeline stall conditions so
|
That is, what happens when a debugger tries to single step an
|
that the pipeline logic could be simpler within the CPU. I ran into
|
instruction? While I can easily single step the computer in either
|
two problems with this.
|
user or supervisor mode from externally, this processor does not appear
|
|
able to step the CPU in user mode from within user mode--gosh, not even
|
The first problem has to deal with debug mode. When the debugger
|
from within supervisor mode--such as if a process had a debugger
|
single steps an instruction, that instruction goes to completion.
|
attached. As the processor exists, I would have one result stepping
|
This means that if the instruction moves a value to the PC register,
|
the CPU from a debugger, and another stepping it externally.
|
the PC register would now contain that value, indicating that the
|
|
next instruction would be on the other side of the branch. There's
|
|
just no easy way around this: the entire CPU state must be captured
|
|
by the registers, to include the program counter. What value should
|
|
the program counter be equal to? The branch? Fine. The address
|
|
you are branching to? Fine. The address of the delay slot? Problem.
|
|
|
|
The second problem with delayed branching is the idea of suspending
|
|
processing for an interrupt. Which address should the CPU return
|
|
to upon completing the interrupt processing? The branch? Good. The
|
|
address after the branch? Also good. The address of the delay slot?
|
|
Not so good.
|
|
|
|
If you then add into this mess the idea that, if the CPU is running
|
|
from a really slow memory such as the flash, the delay slot may never
|
|
be filled before the branch is determined, then this makes even less
|
|
sense.
|
|
|
This is unacceptable, and so this CPU does not support delayed
|
For all of these reasons, this CPU does not support delayed branching.
|
branching.
|
|
|
|
\item {\bf Register Result:} {\tt MOV R0,R1; MOV R1,R2 }
|
\item {\bf Register Result:} {\tt MOV R0,R1; MOV R1,R2 }
|
|
|
What value does
|
What value does R2 get, the value of R1 before the first move or the
|
R2 get, the value of R1 before the first move or the value of R0?
|
value of R0? The Zip CPU has been optimized so that neither of these
|
Placing the value of R0 into R1 requires a pipeline stall, and possibly
|
instructions require a pipeline stall--unless an immediate were to
|
two, as I have the pipeline designed.
|
be added to R1 in the second instruction.
|
|
|
The ZIP CPU architecture requires that R2 must equal R0 at the end of
|
The ZIP CPU architecture requires that R2 must equal R0 at the end of
|
this operation. Even better, such combinations do not (normally)
|
this operation. Even better, such combinations do not (normally)
|
stall the pipeline.
|
stall the pipeline.
|
|
|
\item {\bf Condition Codes Result:} {\tt CMP R0,R1;Mov.EQ \$x,PC}
|
\item {\bf Condition Codes Result:} {\tt CMP R0,R1;} {\tt MOV.EQ \$x,PC}
|
|
|
|
|
At issue is the same item as above, save that the CMP instruction
|
At issue is the same item as above, save that the CMP instruction
|
updates the flags that the MOV instruction depends
|
updates the flags that the MOV instruction depends upon.
|
upon.
|
|
|
|
The Zip CPU architecture requires that condition codes must be updated
|
The Zip CPU architecture requires that condition codes must be updated
|
and available immediately for the next instruction without stalling the
|
and available immediately for the next instruction without stalling the
|
pipeline.
|
pipeline.
|
|
|
\item {\bf Condition Codes Register Result:} {\tt CMP R0,R1; MOV CC,R2}
|
\item {\bf Condition Codes Register Result:} {\tt CMP R0,R1; MOV CC,R2}
|
|
|
At issue is the
|
At issue is the
|
fact that the logic supporting the CC register is more complicated than
|
fact that the logic supporting the CC register is more complicated than
|
the logic supporting any other register.
|
the logic supporting any other register.
|
|
|
The ZIP CPU will stall for a cycle cycle on this instruction.
|
The ZIP CPU will stall for a cycle cycle on this instruction.
|
|
\item {\bf Condition Codes Register Operand:} {\tt MOV R0,R1; MOV CC,R2}
|
|
|
\item {\bf Delayed Branching: } {\tt ADD \$x,PC; MOV R0,R1}
|
Unlike the previous case, this move prior to reading the {\tt CC}
|
|
register does not impact the {\tt CC} register. Therefore, this
|
At issues is whether or not the instruction following the jump will
|
does not stall the bus, whereas the previous one would.
|
take place before the jump. In other words, is the MOV to the PC
|
|
register handled differently from an ADD to the PC register?
|
|
|
|
In the Zip architecture, MOV'es and ADD's use the same logic
|
|
(simplifies the logic).
|
|
\end{itemize}
|
\end{itemize}
|
|
|
As I've studied this, I find several approaches to handling pipeline
|
As I've studied this, I find several approaches to handling pipeline
|
issues. These approaches (and their consequences) are listed below.
|
issues. These approaches (and their consequences) are listed below.
|
|
|
\begin{itemize}
|
\begin{itemize}
|
\item {\bf All All issued instructions complete, Stages stall individually}
|
\item {\bf All issued instructions complete, stages stall individually}
|
|
|
What about a slow pre-fetch?
|
What about a slow pre-fetch?
|
|
|
Nominally, this works well: any issued instruction
|
Nominally, this works well: any issued instruction
|
just runs to completion. If there are four issued instructions in the
|
just runs to completion. If there are four issued instructions in the
|
pipeline, with the writeback instruction being a write-to-PC
|
pipeline, with the writeback instruction being a write-to-PC
|
instruction, the other three instructions naturally finish.
|
instruction, the other three instructions naturally finish.
|
|
|
This approach fails when reading instructions from the flash,
|
This approach fails when reading instructions from the flash,
|
since such reads require N clocks to clocks to complete. Thus
|
since such reads require N clocks to clocks to complete. Thus
|
there may be only one instruction in the pipeline if reading from flash,
|
there may be only one instruction in the pipeline if reading from flash,
|
or a full pipeline if reading from cache. Each of these approaches
|
or a full pipeline if reading from cache. Each of these approaches
|
would produce a different response.
|
would produce a different response.
|
|
|
\item {\bf Issued instructions may be canceled}
|
For this reason, the Zip CPU works off of a different basis: All
|
|
instructions that enter either the ALU or the memory unit will
|
|
complete. Stages still stall individually.
|
|
|
Stages stall individually
|
\item {\bf Issued instructions may be canceled}
|
|
|
First problem:
|
The problem here is that
|
Memory operations cannot be canceled, even reads may have side effects
|
memory operations cannot be canceled: even reads may have side effects
|
on peripherals that cannot be canceled later. Further, in the case of
|
on peripherals that cannot be canceled later. Further, in the case of
|
an interrupt, it's difficult to know what to cancel. What happens in
|
an interrupt, it's difficult to know what to cancel. What happens in
|
a \hbox{\tt MOV.C \$x,PC} followed by a \hbox{\tt MOV \$y,PC}
|
a \hbox{\tt MOV.C \$x,PC} followed by a \hbox{\tt MOV \$y,PC}
|
instruction? Which get
|
instruction? Which get canceled?
|
canceled?
|
|
|
|
Because it isn't clear what would need to be canceled,
|
Because it isn't clear what would need to be canceled, the Zip CPU
|
this instruction combination is not recommended.
|
will not permit this combination. A MOV to the PC register will be
|
|
followed by a stall, and possibly many stalls, so that the second
|
|
move to PC will never be executed.
|
|
|
\item {\bf All issued instructions complete.}
|
\item {\bf All issued instructions complete.}
|
|
|
All stages are filled, or the entire pipeline stalls.
|
In this example, we try all issued instructions complete, but the
|
|
entire pipeline stalls if one stage is not filled. In this approach,
|
What about debug control? What about
|
though, we again struggle with the problems associated with
|
register writes taking an extra clock stage? MOV R0,R1; MOV R1,R2
|
delayed branching. Upon attempting to restart the processor, where
|
should place the value of R0 into R2. How do you restart the pipeline
|
do you restart it from?
|
after an interrupt? What address do you use? The last issued
|
|
instruction? But the branch delay slots may make that invalid!
|
|
|
|
Reading from the CPU debug port in this case yields inconsistent
|
|
results: the CPU will halt or step with instructions stuck in the
|
|
pipeline. Reading registers will give no indication of what is going
|
|
on in the pipeline, just the results of completed operations, not of
|
|
operations that have been started and not yet completed.
|
|
Perhaps we should just report the state of the CPU based upon what
|
|
instructions (PC values) have successfully completed? Thus the
|
|
debug instruction is the one that will write registers on the next
|
|
clock.
|
|
|
|
Suggestion: Suppose we load extra information in the two
|
|
CC register(s) for debugging intermediate pipeline stages?
|
|
|
|
The next problem, though, is how to deal with the read operand
|
|
pipeline stage needing the result from the register pipeline.
|
|
|
|
\item {\bf Memory instructions must complete}
|
\item {\bf Memory instructions must complete}
|
|
|
All instructions that enter into the memory module {\em must}
|
All instructions that enter into the memory module {\em must}
|
complete. Issued instructions from the prefetch, decode, or operand
|
complete. Issued instructions from the prefetch, decode, or operand
|
read stages may or may not complete. Jumps into code must be valid,
|
read stages may or may not complete. Jumps into code must be valid,
|
so that interrupt returns may be valid. All instructions entering the
|
so that interrupt returns may be valid. All instructions entering the
|
ALU complete.
|
ALU complete.
|
|
|
This looks to be the simplest approach.
|
This looks to be the simplest approach.
|
While the logic may be difficult, this appears to be the only
|
While the logic may be difficult, this appears to be the only
|
re-entrant approach.
|
re-entrant approach.
|
|
|
A {\tt new\_pc} flag will be high anytime the PC changes in an
|
A {\tt new\_pc} flag will be high anytime the PC changes in an
|
unpredictable way (i.e., it doesn't increment). This includes jumps
|
unpredictable way (i.e., it doesn't increment). This includes jumps
|
as well as interrupts and interrupt returns. Whenever this flag may
|
as well as interrupts and interrupt returns. Whenever this flag may
|
go high, memory operations and ALU operations will stall until the
|
go high, memory operations and ALU operations will stall until the
|
result is known. When the flag does go high, anything in the prefetch,
|
result is known. When the flag does go high, anything in the prefetch,
|
decode, and read-op stage will be invalidated.
|
decode, and read-op stage will be invalidated.
|
|
|
\end{itemize}
|
\end{itemize}
|
|
\fi
|
|
|
\section{Pipeline Stalls}
|
\section{Pipeline Stalls}
|
The processing pipeline can and will stall for a variety of reasons. Some of
|
The processing pipeline can and will stall for a variety of reasons. Some of
|
these are obvious, some less so. These reasons are listed below:
|
these are obvious, some less so. These reasons are listed below:
|
\begin{itemize}
|
\begin{itemize}
|
\item When the prefetch cache is exhausted
|
\item When the prefetch cache is exhausted
|
|
|
This should be obvious. If the prefetch cache doesn't have the instruction
|
This should be obvious. If the prefetch cache doesn't have the instruction
|
in memory, the entire pipeline must stall until enough of the prefetch cache
|
in memory, the entire pipeline must stall until enough of the prefetch cache
|
is loaded to support the next instruction.
|
is loaded to support the next instruction.
|
|
|
\item While waiting for the pipeline to load following any taken branch, jump,
|
\item While waiting for the pipeline to load following any taken branch, jump,
|
return from interrupt or switch to interrupt context (6 clocks)
|
return from interrupt or switch to interrupt context (6 clocks)
|
|
|
If the PC suddenly changes, the pipeline is subsequently cleared and needs to
|
If the PC suddenly changes, the pipeline is subsequently cleared and needs to
|
be reloaded. Given that there are five stages to the pipeline, that accounts
|
be reloaded. Given that there are five stages to the pipeline, that accounts
|
for five of the six delay clocks. The last clock is lost in the prefetch
|
for five of the six delay clocks. The last clock is lost in the prefetch
|
stage which needs at least one clock with a valid PC before it can produce
|
stage which needs at least one clock with a valid PC before it can produce
|
a new output. Hence, six clocks will always be lost anytime the pipeline needs
|
a new output. Hence, six clocks will always be lost anytime the pipeline needs
|
to be cleared.
|
to be cleared.
|
|
|
\item When reading from a prior register while also adding an immediate offset
|
\item When reading from a prior register while also adding an immediate offset
|
\begin{enumerate}
|
\begin{enumerate}
|
\item\ {\tt OPCODE ?,RA}
|
\item\ {\tt OPCODE ?,RA}
|
\item\ {\em (stall)}
|
\item\ {\em (stall)}
|
\item\ {\tt OPCODE I+RA,RB}
|
\item\ {\tt OPCODE I+RA,RB}
|
\end{enumerate}
|
\end{enumerate}
|
|
|
Since the addition of the immediate register within OpB decoding gets applied
|
Since the addition of the immediate register within OpB decoding gets applied
|
during the read operand stage so that it can be nicely settled before the ALU,
|
during the read operand stage so that it can be nicely settled before the ALU,
|
any instruction that will write back an operand must be separated from the
|
any instruction that will write back an operand must be separated from the
|
opcode that will read and apply an immediate offset by one instruction. The
|
opcode that will read and apply an immediate offset by one instruction. The
|
good news is that this stall can easily be mitigated by proper scheduling.
|
good news is that this stall can easily be mitigated by proper scheduling.
|
|
|
\item When writing to the CC or PC Register
|
\item When writing to the CC or PC Register
|
\begin{enumerate}
|
\begin{enumerate}
|
\item\ {\tt OPCODE RA,PC} {\em Ex: a branch opcode}
|
\item\ {\tt OPCODE RA,PC} {\em Ex: a branch opcode}
|
\item\ {\em (stall, even if jump not taken)}
|
\item\ {\em (stall, even if jump not taken)}
|
\item\ {\tt OPCODE RA,RB}
|
\item\ {\tt OPCODE RA,RB}
|
\end{enumerate}
|
\end{enumerate}
|
Since branches take place in the writeback stage, the Zip CPU will stall the
|
Since branches take place in the writeback stage, the Zip CPU will stall the
|
pipeline for one clock anytime there may be a possible jump. This prevents
|
pipeline for one clock anytime there may be a possible jump. This prevents
|
an instruction from executing a memory access after the jump but before the
|
an instruction from executing a memory access after the jump but before the
|
jump is recognized.
|
jump is recognized.
|
|
|
|
This stall cannot be mitigated through scheduling.
|
|
|
\item When reading from the CC register after setting the flags
|
\item When reading from the CC register after setting the flags
|
\begin{enumerate}
|
\begin{enumerate}
|
\item\ {\tt ALUOP RA,RB}
|
\item\ {\tt ALUOP RA,RB}
|
\item\ {\em (stall}
|
\item\ {\em (stall}
|
\item\ {\tt TST sys.ccv,CC}
|
\item\ {\tt TST sys.ccv,CC}
|
\item\ {\tt BZ somewhere}
|
\item\ {\tt BZ somewhere}
|
\end{enumerate}
|
\end{enumerate}
|
|
|
The reason for this stall is simply performance. Many of the flags are
|
The reason for this stall is simply performance. Many of the flags are
|
determined via combinatorial logic after the writeback instruction is
|
determined via combinatorial logic after the writeback instruction is
|
determined. Trying to then place these into the input for one of the operands
|
determined. Trying to then place these into the input for one of the operands
|
created a time delay loop that would no longer execute in a single 100~MHz
|
created a time delay loop that would no longer execute in a single 100~MHz
|
clock cycle. (The time delay of the multiply within the ALU wasn't helping
|
clock cycle. (The time delay of the multiply within the ALU wasn't helping
|
either \ldots).
|
either \ldots).
|
|
|
|
This stall may be eliminated via proper scheduling, by placing an instruction
|
|
that does not set flags in between the ALU operation and the instruction
|
|
that references the CC register. For example, {\tt MOV \$addr+PC,uPC}
|
|
followed by an {\tt RTU} ({\tt OR \$GIE,CC}) instruction will not incur
|
|
this stall, whereas an {\tt OR \$BREAKEN,CC} followed by an {\tt OR \$STEP,CC}
|
|
will incur the stall.
|
|
|
\item When waiting for a memory read operation to complete
|
\item When waiting for a memory read operation to complete
|
\begin{enumerate}
|
\begin{enumerate}
|
\item\ {\tt LOD address,RA}
|
\item\ {\tt LOD address,RA}
|
\item\ {\em (multiple stalls, bus dependent, 7 clocks best)}
|
\item\ {\em (multiple stalls, bus dependent, 7 clocks best)}
|
\item\ {\tt OPCODE I+RA,RB}
|
\item\ {\tt OPCODE I+RA,RB}
|
\end{enumerate}
|
\end{enumerate}
|
|
|
Remember, the ZIP CPU does not support out of order execution. Therefore,
|
Remember, the ZIP CPU does not support out of order execution. Therefore,
|
anytime the memory unit becomes busy both the memory unit and the ALU must
|
anytime the memory unit becomes busy both the memory unit and the ALU must
|
stall until the memory unit is cleared. This is especially true of a load
|
stall until the memory unit is cleared. This is especially true of a load
|
instruction, which will write its operand back to the register file. Store
|
instruction, which must still write its operand back to the register file.
|
instructions are different, since they can be busy with no impact on later
|
Store instructions are different, since they can be busy with no impact on
|
ALU write back operations. Hence, only loads stall the pipeline.
|
later ALU write back operations. Hence, only loads stall the pipeline.
|
|
|
This also assumes that the memory being accessed is a single cycle memory.
|
This also assumes that the memory being accessed is a single cycle memory.
|
Slower memories, such as the Quad SPI flash, will take longer--perhaps even
|
Slower memories, such as the Quad SPI flash, will take longer--perhaps even
|
as long as fourty clocks. During this time the CPU and the external bus
|
as long as forty clocks. During this time the CPU and the external bus
|
will be busy, and unable to do anything else.
|
will be busy, and unable to do anything else.
|
|
|
\item Memory operation followed by a memory operation
|
\item Memory operation followed by a memory operation
|
\begin{enumerate}
|
\begin{enumerate}
|
\item\ {\tt STO address,RA}
|
\item\ {\tt STO address,RA}
|
\item\ {\em (multiple stalls, bus dependent, 7 clocks best)}
|
\item\ {\em (multiple stalls, bus dependent, 7 clocks best)}
|
\item\ {\tt LOD address,RB}
|
\item\ {\tt LOD address,RB}
|
\item\ {\em (multiple stalls, bus dependent, 7 clocks best)}
|
\item\ {\em (multiple stalls, bus dependent, 7 clocks best)}
|
\end{enumerate}
|
\end{enumerate}
|
|
|
In this case, the LOD instruction cannot start until the STALL is finished.
|
In this case, the LOD instruction cannot start until the STALL is finished.
|
With proper scheduling, it is possible to do something in the ALU while the
|
With proper scheduling, it is possible to do something in the ALU while the
|
STO is busy, but otherwise this pipeline will stall waiting for it to complete.
|
STO is busy, but otherwise this pipeline will stall waiting for it to complete.
|
|
|
Note that even though the Wishbone bus can support pipelined accesses at
|
Note that even though the Wishbone bus can support pipelined accesses at
|
one access per clock, only the prefetch stage can take advantage of this.
|
one access per clock, only the prefetch stage can take advantage of this.
|
Load and Store instructions are stuck at one wishbone cycle per instruction.
|
Load and Store instructions are stuck at one wishbone cycle per instruction.
|
\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
|
While the previous chapter describes a CPU in isolation, the Zip System
|
includes a minimum set of peripherals as well. These peripherals are shown
|
includes a minimum set of peripherals as well. These peripherals are shown
|
in Fig.~\ref{fig:zipsystem}
|
in Fig.~\ref{fig:zipsystem}
|
\begin{figure}\begin{center}
|
\begin{figure}\begin{center}
|
\includegraphics[width=3.5in]{../gfx/system.eps}
|
\includegraphics[width=3.5in]{../gfx/system.eps}
|
\caption{Zip System Peripherals}\label{fig:zipsystem}
|
\caption{Zip System Peripherals}\label{fig:zipsystem}
|
\end{center}\end{figure}
|
\end{center}\end{figure}
|
and described here. They are designed to make
|
and described here. They are designed to make
|
the Zip CPU more useful in an Embedded Operating System environment.
|
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
|
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
|
controller. While the Zip CPU itself can only handle one interrupt, and has
|
only the one interrupt state: disabled or enabled, the interrupt controller
|
only the one interrupt state: disabled or enabled, the interrupt controller
|
can make things more interesting.
|
can make things more interesting.
|
|
|
The Zip System interrupt controller module supports up to 15 interrupts, all
|
The Zip System interrupt controller module supports up to 15 interrupts, all
|
controlled from one register. Bit~31 of the interrupt controller controls
|
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
|
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).
|
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
|
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.
|
bits~0--15 indicate whether or not an individual interrupt is active.
|
|
|
The interrupt controller has been designed so that bits can be controlled
|
The interrupt controller has been designed so that bits can be controlled
|
individually without having any knowledge of the rest of the controller
|
individually without having any knowledge of the rest of the controller
|
setting. To enable an interrupt, write to the register with the high order
|
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
|
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
|
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
|
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.
|
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
|
Zero's written to the register have no affect, save that a zero written to the
|
master enable will disable all interrupts.
|
master enable will disable all interrupts.
|
|
|
As an example, suppose you wished to enable interrupt \#4. You would then
|
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
|
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
|
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
|
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
|
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
|
disabling all interrupts, so a second write of {\tt 0x80000000} may be necessary
|
to re-enable any other interrupts.
|
to re-enable any other interrupts.
|
|
|
The Zip System currently hosts two interrupt controllers, a primary and a
|
The Zip System currently hosts two interrupt controllers, a primary and a
|
secondary. The primary interrupt controller has one interrupt line which may
|
secondary. The primary interrupt controller has one interrupt line which may
|
come from an external interrupt controller, and one interrupt line from the
|
come from an external interrupt controller, and one interrupt line from the
|
secondary controller. Other primary interrupts include the system timers,
|
secondary controller. Other primary interrupts include the system timers,
|
the jiffies interrupt, and the manual cache interrupt. The secondary interrupt
|
the jiffies interrupt, and the manual cache interrupt. The secondary interrupt
|
controller maintains an interrupt state for all of the processor accounting
|
controller maintains an interrupt state for all of the processor accounting
|
counters.
|
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
|
value.
|
value.
|
|
|
Eight counters are implemented in the Zip System for process accounting.
|
Eight counters are implemented in the Zip System for process accounting.
|
This may change in the future, as nothing as yet uses these counters.
|
This may change in the future, as nothing as yet uses these counters.
|
|
|
\section{Timer}
|
\section{Timer}
|
|
|
The Zip Timer is also very simple: it simply counts down to zero. When it
|
The Zip Timer is also very simple: it simply counts down to zero. When it
|
transitions from a one to a zero it creates an interrupt.
|
transitions from a one to a zero it creates an interrupt.
|
|
|
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). This reload capability also limits the
|
second (assuming a 100~MHz clock). This reload capability also limits the
|
maximum timer value to $2^{31}-1$, rather than $2^{32}-1$.
|
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
|
timer is tied to the reset line of the CPU. Hence writing a `1' to the
|
timer is tied to the reset line of the CPU. Hence writing a `1' to the
|
watchdog timer will always reset the CPU.
|
watchdog timer will always reset the CPU.
|
To stop the Watchdog timer, write a `0' to it. To start it,
|
To stop the Watchdog timer, write a `0' to it. To start it,
|
write any other number to it---as with the other timers.
|
write any other number to it---as with the other timers.
|
|
|
While the watchdog timer supports interval mode, it doesn't make as much sense
|
While the watchdog timer supports interval mode, it doesn't make as much sense
|
as it did with the other timers.
|
as it did with the other timers.
|
|
|
\section{Jiffies}
|
\section{Jiffies}
|
|
|
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 the 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 interrupt line 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
|
an interrupt. Unlike the other counters, the Jiffies register cannot be set.
|
an interrupt. Unlike the other counters, the Jiffies register cannot be set.
|
Writes to the jiffies register create an interrupt time. When the Jiffies
|
Writes to the jiffies register create an interrupt time. When the Jiffies
|
register later equals the value written to it, an interrupt will be asserted
|
register later equals the value written to it, an interrupt will be asserted
|
and the register then continues counting as though no interrupt had taken
|
and the register then continues counting as though no interrupt had taken
|
place.
|
place.
|
|
|
The purpose of this register is to support alarm times within a CPU. To
|
The purpose of this register is to support alarm times within a CPU. To
|
set an alarm for a particular process $N$ clocks in advance, read the current
|
set an alarm for a particular process $N$ clocks in advance, read the current
|
Jiffies value, and $N$, and write it back to the Jiffies register. The
|
Jiffies value, and $N$, and write it back to the Jiffies register. The
|
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 removed from the list of alarms, the list
|
when an `alarm' trips, it should be removed 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}
|
\section{Manual Cache}
|
|
|
The manual cache is an experimental setting that may not remain with the Zip
|
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
|
CPU for very long. It is designed to facilitate running from FLASH or ROM
|
memory, although the pipeline prefetch cache really makes this need obsolete.
|
memory, although the pipeline prefetch cache really makes this need obsolete.
|
The manual
|
The manual
|
cache works by copying data from a wishbone address (range) into the cache
|
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.
|
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
|
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 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
|
memory by the cache memory location. There is no transparency. It is perhaps
|
best described as a combination DMA controller and local memory.
|
best described as a combination DMA controller and local memory.
|
|
|
Worse, this cache is likely going to be removed from the ZipSystem. Having used
|
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
|
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.
|
cache. I will likely replace this peripheral with a proper DMA controller.
|
|
|
\chapter{Operation}\label{chap:ops}
|
\chapter{Operation}\label{chap:ops}
|
|
|
|
The Zip CPU, and even the Zip System, is not a System on a Chip (SoC). It
|
|
needs to be connected to its operational environment in order to be used.
|
|
Specifically, some per system adjustments need to be made:
|
|
\begin{enumerate}
|
|
\item The Zip System depends upon an external 32-bit Wishbone bus. This
|
|
must exist, and must be connected to the Zip CPU for it to work.
|
|
\item The Zip System needs to be told of its {\tt RESET\_ADDRESS}. This is
|
|
the program counter of the first instruction following a reset.
|
|
\item If you want the Zip System to start up on its own, you will need to
|
|
set the {\tt START\_HALTED} parameter to zero. Otherwise, if you
|
|
wish to manually start the CPU, that is if upon reset you want the
|
|
CPU start start in its halted, reset state, then set this parameter to
|
|
one.
|
|
\item The third parameter to set is the number of interrupts you will be
|
|
providing from external to the CPU. This can be anything from one
|
|
to nine, but it cannot be zero. (Wire this line to a 1'b0 if you
|
|
do not wish to support any external interrupts.)
|
|
\item Finally, you need to place into some wishbone accessible address, whether
|
|
RAM or (more likely) ROM, the initial instructions for the CPU.
|
|
\end{enumerate}
|
|
If you have enabled your CPU to start automatically, then upon power up the
|
|
CPU will immediately start executing your instructions.
|
|
|
|
This is, however, not how I have used the Zip CPU. I have instead used the
|
|
ZIP CPU in a more controlled environment. For me, the CPU starts in a
|
|
halted state, and waits to be told to start. Further, the RESET address is a
|
|
location in RAM. After bringing up the board I am using, and further the
|
|
bus that is on it, the RAM memory is then loaded externally with the program
|
|
I wish the Zip System to run. Once the RAM is loaded, I release the CPU.
|
|
The CPU then runs until its halt condition, at which point its task is
|
|
complete.
|
|
|
|
Eventually, I intend to place an operating system onto the ZipSystem, I'm
|
|
just not there yet.
|
|
|
|
|
\chapter{Registers}\label{chap:regs}
|
\chapter{Registers}\label{chap:regs}
|
|
|
The ZipSystem registers fall into two categories, ZipSystem internal registers
|
The ZipSystem registers fall into two categories, ZipSystem internal registers
|
accessed via the ZipCPU shown in Tbl.~\ref{tbl:zpregs},
|
accessed via the ZipCPU shown in Tbl.~\ref{tbl:zpregs},
|
\begin{table}[htbp]
|
\begin{table}[htbp]
|
\begin{center}\begin{reglist}
|
\begin{center}\begin{reglist}
|
PIC & \scalebox{0.8}{\tt 0xc0000000} & 32 & R/W & Primary Interrupt Controller \\\hline
|
PIC & \scalebox{0.8}{\tt 0xc0000000} & 32 & R/W & Primary Interrupt Controller \\\hline
|
WDT & \scalebox{0.8}{\tt 0xc0000001} & 32 & R/W & Watchdog Timer \\\hline
|
WDT & \scalebox{0.8}{\tt 0xc0000001} & 32 & R/W & Watchdog Timer \\\hline
|
CCHE & \scalebox{0.8}{\tt 0xc0000002} & 32 & R/W & Manual Cache Controller \\\hline
|
CCHE & \scalebox{0.8}{\tt 0xc0000002} & 32 & R/W & Manual Cache Controller \\\hline
|
CTRIC & \scalebox{0.8}{\tt 0xc0000003} & 32 & R/W & Secondary Interrupt Controller \\\hline
|
CTRIC & \scalebox{0.8}{\tt 0xc0000003} & 32 & R/W & Secondary Interrupt Controller \\\hline
|
TMRA & \scalebox{0.8}{\tt 0xc0000004} & 32 & R/W & Timer A\\\hline
|
TMRA & \scalebox{0.8}{\tt 0xc0000004} & 32 & R/W & Timer A\\\hline
|
TMRB & \scalebox{0.8}{\tt 0xc0000005} & 32 & R/W & Timer B\\\hline
|
TMRB & \scalebox{0.8}{\tt 0xc0000005} & 32 & R/W & Timer B\\\hline
|
TMRC & \scalebox{0.8}{\tt 0xc0000006} & 32 & R/W & Timer C\\\hline
|
TMRC & \scalebox{0.8}{\tt 0xc0000006} & 32 & R/W & Timer C\\\hline
|
JIFF & \scalebox{0.8}{\tt 0xc0000007} & 32 & R/W & Jiffies \\\hline
|
JIFF & \scalebox{0.8}{\tt 0xc0000007} & 32 & R/W & Jiffies \\\hline
|
MTASK & \scalebox{0.8}{\tt 0xc0000008} & 32 & R/W & Master Task Clock Counter \\\hline
|
MTASK & \scalebox{0.8}{\tt 0xc0000008} & 32 & R/W & Master Task Clock Counter \\\hline
|
MMSTL & \scalebox{0.8}{\tt 0xc0000009} & 32 & R/W & Master Stall Counter \\\hline
|
MMSTL & \scalebox{0.8}{\tt 0xc0000009} & 32 & R/W & Master Stall Counter \\\hline
|
MPSTL & \scalebox{0.8}{\tt 0xc000000a} & 32 & R/W & Master Pre--Fetch Stall Counter \\\hline
|
MPSTL & \scalebox{0.8}{\tt 0xc000000a} & 32 & R/W & Master Pre--Fetch Stall Counter \\\hline
|
MICNT & \scalebox{0.8}{\tt 0xc000000b} & 32 & R/W & Master Instruction Counter\\\hline
|
MICNT & \scalebox{0.8}{\tt 0xc000000b} & 32 & R/W & Master Instruction Counter\\\hline
|
UTASK & \scalebox{0.8}{\tt 0xc000000c} & 32 & R/W & User Task Clock Counter \\\hline
|
UTASK & \scalebox{0.8}{\tt 0xc000000c} & 32 & R/W & User Task Clock Counter \\\hline
|
UMSTL & \scalebox{0.8}{\tt 0xc000000d} & 32 & R/W & User Stall Counter \\\hline
|
UMSTL & \scalebox{0.8}{\tt 0xc000000d} & 32 & R/W & User Stall Counter \\\hline
|
UPSTL & \scalebox{0.8}{\tt 0xc000000e} & 32 & R/W & User Pre--Fetch Stall Counter \\\hline
|
UPSTL & \scalebox{0.8}{\tt 0xc000000e} & 32 & R/W & User Pre--Fetch Stall Counter \\\hline
|
UICNT & \scalebox{0.8}{\tt 0xc000000f} & 32 & R/W & User Instruction Counter\\\hline
|
UICNT & \scalebox{0.8}{\tt 0xc000000f} & 32 & R/W & User Instruction Counter\\\hline
|
% Cache & \scalebox{0.8}{\tt 0xc0100000} & & & Base address of the Cache memory\\\hline
|
% Cache & \scalebox{0.8}{\tt 0xc0100000} & & & Base address of the Cache memory\\\hline
|
\end{reglist}
|
\end{reglist}
|
\caption{Zip System Internal/Peripheral Registers}\label{tbl:zpregs}
|
\caption{Zip System Internal/Peripheral Registers}\label{tbl:zpregs}
|
\end{center}\end{table}
|
\end{center}\end{table}
|
and the two debug registers showin in Tbl.~\ref{tbl:dbgregs}.
|
and the two debug registers shown in Tbl.~\ref{tbl:dbgregs}.
|
\begin{table}[htbp]
|
\begin{table}[htbp]
|
\begin{center}\begin{reglist}
|
\begin{center}\begin{reglist}
|
ZIPCTRL & 0 & 32 & R/W & Debug Control Register \\\hline
|
ZIPCTRL & 0 & 32 & R/W & Debug Control Register \\\hline
|
ZIPDATA & 1 & 32 & R/W & Debug Data Register \\\hline
|
ZIPDATA & 1 & 32 & R/W & Debug Data Register \\\hline
|
\end{reglist}
|
\end{reglist}
|
\caption{Zip System Debug Registers}\label{tbl:dbgregs}
|
\caption{Zip System Debug Registers}\label{tbl:dbgregs}
|
\end{center}\end{table}
|
\end{center}\end{table}
|
|
|
|
\section{Peripheral Registers}
|
|
The peripheral registers, listed in Tbl.~\ref{tbl:zpregs}, are shown in the
|
|
CPU's address space. These may be accessed by the CPU at these addresses,
|
|
and when so accessed will respond as described in Chapt.~\ref{chap:periph}.
|
|
These registers will be discussed briefly again here.
|
|
|
|
The Zip CPU Interrupt controller has four different types of bits, as shown in
|
|
Tbl.~\ref{tbl:picbits}.
|
|
\begin{table}\begin{center}
|
|
\begin{bitlist}
|
|
31 & R/W & Master Interrupt Enable\\\hline
|
|
30\ldots 16 & R/W & Interrupt Enables, write '1' to change\\\hline
|
|
15 & R & Current Master Interrupt State\\\hline
|
|
15\ldots 0 & R/W & Input Interrupt states, write '1' to clear\\\hline
|
|
\end{bitlist}
|
|
\caption{Interrupt Controller Register Bits}\label{tbl:picbits}
|
|
\end{center}\end{table}
|
|
The high order bit, or bit--31, is the master interrupt enable bit. When this
|
|
bit is set, then any time an interrupt occurs the CPU will be interrupted and
|
|
will switch to supervisor mode, etc.
|
|
|
|
Bits 30~\ldots 16 are interrupt enable bits. Should the interrupt line go
|
|
ghile while enabled, an interrupt will be generated. To set an interrupt enable
|
|
bit, one needs to write the master interrupt enable while writing a `1' to this
|
|
the bit. To clear, one need only write a `0' to the master interrupt enable,
|
|
while leaving this line high.
|
|
|
|
Bits 15\ldots 0 are the current state of the interrupt vector. Interrupt lines
|
|
trip when they go high, and remain tripped until they are acknowledged. If
|
|
the interrupt goes high for longer than one pulse, it may be high when a clear
|
|
is requested. If so, the interrupt will not clear. The line must go low
|
|
again before the status bit can be cleared.
|
|
|
|
As an example, consider the following scenario where the Zip CPU supports four
|
|
interrupts, 3\ldots0.
|
|
\begin{enumerate}
|
|
\item The Supervisor will first, while in the interrupts disabled mode,
|
|
write a {\tt 32'h800f000f} to the controller. The supervisor may then
|
|
switch to the user state with interrupts enabled.
|
|
\item When an interrupt occurs, the supervisor will switch to the interrupt
|
|
state. It will then cycle through the interrupt bits to learn which
|
|
interrupt handler to call.
|
|
\item If the interrupt handler expects more interrupts, it will clear its
|
|
current interrupt when it is done handling the interrupt in question.
|
|
To do this, it will write a '1' to the low order interrupt mask,
|
|
such as writing a {\tt 32'h80000001}.
|
|
\item If the interrupt handler does not expect any more interrupts, it will
|
|
instead clear the interrupt from the controller by writing a
|
|
{\tt 32'h00010001} to the controller.
|
|
\item Once all interrupts have been handled, the supervisor will write a
|
|
{\tt 32'h80000000} to the interrupt register to re-enable interrupt
|
|
generation.
|
|
\item The supervisor should also check the user trap bit, and possible soft
|
|
interrupt bits here, but this action has nothing to do with the
|
|
interrupt control register.
|
|
\item The supervisor will then leave interrupt mode, possibly adjusting
|
|
whichever task is running, by executing a return from interrupt
|
|
command.
|
|
\end{enumerate}
|
|
|
|
Leaving the interrupt controller, we show the timer registers bit definitions
|
|
in Tbl.~\ref{tbl:tmrbits}.
|
|
\begin{table}\begin{center}
|
|
\begin{bitlist}
|
|
31 & R/W & Auto-Reload\\\hline
|
|
30\ldots 0 & R/W & Current timer value\\\hline
|
|
\end{bitlist}
|
|
\caption{Timer Register Bits}\label{tbl:tmrbits}
|
|
\end{center}\end{table}
|
|
As you may recall, the timer just counts down to zero and then trips an
|
|
interrupt. Writing to the current timer value sets that value, and reading
|
|
from it returns that value. Writing to the current timer value while also
|
|
setting the auto--reload bit will send the timer into an auto--reload mode.
|
|
In this mode, upon setting its interrupt bit for one cycle, the timer will
|
|
also reset itself back to the value of the timer that was written to it when
|
|
the auto--reload option was written to it. To clear and stop the timer,
|
|
just simply write a `32'h00' to this register.
|
|
|
|
The Jiffies register is somewhat similar in that the register always changes.
|
|
In this case, the register counts up, whereas the timer always counted down.
|
|
Reads from this register, as shown in Tbl.~\ref{tbl:jiffybits},
|
|
\begin{table}\begin{center}
|
|
\begin{bitlist}
|
|
31\ldots 0 & R & Current jiffy value\\\hline
|
|
31\ldots 0 & W & Value/time of next interrupt\\\hline
|
|
\end{bitlist}
|
|
\caption{Jiffies Register Bits}\label{tbl:jiffybits}
|
|
\end{center}\end{table}
|
|
always return the time value contained in the register. Writes greater than
|
|
the current Jiffy value, that is where the new value minus the old value is
|
|
greater than zero while ignoring truncation, will set a new Jiffy interrupt
|
|
time. At that time, the Jiffy vector will clear, and another interrupt time
|
|
may either be written to it, or it will just continue counting without
|
|
activating any more interrupts.
|
|
|
|
The Zip CPU also supports several counter peripherals, mostly in the way of
|
|
process accounting. This peripherals have a single register associated with
|
|
them, shown in Tbl.~\ref{tbl:ctrbits}.
|
|
\begin{table}\begin{center}
|
|
\begin{bitlist}
|
|
31\ldots 0 & R/W & Current counter value\\\hline
|
|
\end{bitlist}
|
|
\caption{Counter Register Bits}\label{tbl:ctrbits}
|
|
\end{center}\end{table}
|
|
Writes to this register set the new counter value. Reads read the current
|
|
counter value.
|
|
|
|
The current design operation of these counters is that of performance counting.
|
|
Two sets of four registers are available for keeping track of performance.
|
|
The first is a task counter. This just counts clock ticks. The second
|
|
counter is a prefetch stall counter, then an master stall counter. These
|
|
allow the CPU to be evaluated as to how efficient it is. The fourth and
|
|
final counter is an instruction counter, which counts how many instructions the
|
|
CPU has issued.
|
|
|
|
It is envisioned that these counters will be used as follows: First, every time
|
|
a master counter rolls over, the supervisor (Operating System) will record
|
|
the fact. Second, whenever activating a user task, the Operating System will
|
|
set the four user counters to zero. When the user task has completed, the
|
|
Operating System will read the timers back off, to determine how much of the
|
|
CPU the process had consumed.
|
|
|
|
\section{Debug Port Registers}
|
|
Accessing the Zip System via the debug port isn't as straight forward as
|
|
accessing the system via the wishbone bus. The debug port itself has been
|
|
reduced to two addresses, as outlined earlier in Tbl.~\ref{tbl:dbgregs}.
|
|
Access to the Zip System begins with the Debug Control register, shown in
|
|
Tbl.~\ref{tbl:dbgctrl}.
|
|
\begin{table}\begin{center}
|
|
\begin{bitlist}
|
|
31\ldots 14 & R & Reserved\\\hline
|
|
13 & R & CPU GIE setting\\\hline
|
|
12 & R & CPU is sleeping\\\hline
|
|
11 & W & Command clear PF cache\\\hline
|
|
10 & R/W & Command HALT, Set to '1' to halt the CPU\\\hline
|
|
9 & R & Stall Status, '1' if CPU is busy\\\hline
|
|
8 & R/W & Step Command, set to '1' to step the CPU\\\hline
|
|
7 & R & Interrupt Request \\\hline
|
|
6 & R/W & Command RESET \\\hline
|
|
5\ldots 0 & R/W & Debug Register Address \\\hline
|
|
\end{bitlist}
|
|
\caption{Debug Control Register Bits}\label{tbl:dbgctrl}
|
|
\end{center}\end{table}
|
|
|
\chapter{Wishbone Datasheet}\label{chap:wishbone}
|
The first step in debugging access is to determine whether or not the CPU
|
|
is halted, and to halt it if not. To do this, first write a '1' to the
|
|
Command HALT bit. This will halt the CPU and place it into debug mode.
|
|
Once the CPU is halted, the stall status bit will drop to zero. Thus,
|
|
if bit 10 is high and bit 9 low, the debug port is open to examine the
|
|
internal state of the CPU.
|
|
|
|
At this point, the external debugger may examine internal state information
|
|
from within the CPU. To do this, first write again to the command register
|
|
a value (with command halt still high) containing the address of an internal
|
|
register of interest in the bottom 6~bits. Internal registers that may be
|
|
accessed this way are listed in Tbl.~\ref{tbl:dbgaddrs}.
|
|
\begin{table}\begin{center}
|
|
\begin{reglist}
|
|
sR0 & 0 & 32 & R/W & Supervisor Register R0 \\\hline
|
|
sR1 & 0 & 32 & R/W & Supervisor Register R1 \\\hline
|
|
sSP & 13 & 32 & R/W & Supervisor Stack Pointer\\\hline
|
|
sCC & 14 & 32 & R/W & Supervisor Condition Code Register \\\hline
|
|
sPC & 15 & 32 & R/W & Supervisor Program Counter\\\hline
|
|
uR0 & 16 & 32 & R/W & User Register R0 \\\hline
|
|
uR1 & 17 & 32 & R/W & User Register R1 \\\hline
|
|
uSP & 29 & 32 & R/W & User Stack Pointer\\\hline
|
|
uCC & 30 & 32 & R/W & User Condition Code Register \\\hline
|
|
uPC & 31 & 32 & R/W & User Program Counter\\\hline
|
|
PIC & 32 & 32 & R/W & Primary Interrupt Controller \\\hline
|
|
WDT & 33 & 32 & R/W & Watchdog Timer\\\hline
|
|
CCHE & 34 & 32 & R/W & Manual Cache Controller\\\hline
|
|
CTRIC & 35 & 32 & R/W & Secondary Interrupt Controller\\\hline
|
|
TMRA & 36 & 32 & R/W & Timer A\\\hline
|
|
TMRB & 37 & 32 & R/W & Timer B\\\hline
|
|
TMRC & 38 & 32 & R/W & Timer C\\\hline
|
|
JIFF & 39 & 32 & R/W & Jiffies peripheral\\\hline
|
|
MTASK & 40 & 32 & R/W & Master task clock counter\\\hline
|
|
MMSTL & 41 & 32 & R/W & Master memory stall counter\\\hline
|
|
MPSTL & 42 & 32 & R/W & Master Pre-Fetch Stall counter\\\hline
|
|
MICNT & 43 & 32 & R/W & Master instruction counter\\\hline
|
|
UTASK & 44 & 32 & R/W & User task clock counter\\\hline
|
|
UMSTL & 45 & 32 & R/W & User memory stall counter\\\hline
|
|
UPSTL & 46 & 32 & R/W & User Pre-Fetch Stall counter\\\hline
|
|
UICNT & 47 & 32 & R/W & User instruction counter\\\hline
|
|
\end{reglist}
|
|
\caption{Debug Register Addresses}\label{tbl:dbgaddrs}
|
|
\end{center}\end{table}
|
|
Primarily, these ``registers'' include access to the entire CPU register
|
|
set, as well as the 16~internal peripherals. To read one of these registers
|
|
once the address is set, simply issue a read from the data port. To write
|
|
one of these registers or peripheral ports, simply write to the data port
|
|
after setting the proper address.
|
|
|
|
In this manner, all of the CPU's internal state may be read and adjusted.
|
|
|
|
As an example of how to use this, consider what would happen in the case
|
|
of an external break point. If and when the CPU hits a break point that
|
|
causes it to halt, the Command HALT bit will activate on its own, the CPU
|
|
will then raise an external interrupt line and wait for a debugger to examine
|
|
its state. After examining the state, the debugger will need to remove
|
|
the breakpoint by writing a different instruction into memory and by writing
|
|
to the command register while holding the clear cache, command halt, and
|
|
step CPU bits high, (32'hd00). The debugger may then replace the breakpoint
|
|
now that the CPU has gone beyond it, and clear the cache again (32'h500).
|
|
|
|
To leave this debug mode, simply write a `32'h0' value to the command register.
|
|
|
|
\chapter{Wishbone Datasheets}\label{chap:wishbone}
|
The Zip System supports two wishbone ports, a slave debug port and a master
|
The Zip System supports two wishbone ports, 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
|
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
|
Signal Names & \begin{tabular}{ll}
|
Signal Names & \begin{tabular}{ll}
|
Signal Name & Wishbone Equivalent \\\hline
|
Signal Name & Wishbone Equivalent \\\hline
|
{\tt i\_clk} & {\tt CLK\_I} \\
|
{\tt i\_clk} & {\tt CLK\_I} \\
|
{\tt i\_dbg\_cyc} & {\tt CYC\_I} \\
|
{\tt i\_dbg\_cyc} & {\tt CYC\_I} \\
|
{\tt i\_dbg\_stb} & {\tt STB\_I} \\
|
{\tt i\_dbg\_stb} & {\tt STB\_I} \\
|
{\tt i\_dbg\_we} & {\tt WE\_I} \\
|
{\tt i\_dbg\_we} & {\tt WE\_I} \\
|
{\tt i\_dbg\_addr} & {\tt ADR\_I} \\
|
{\tt i\_dbg\_addr} & {\tt ADR\_I} \\
|
{\tt i\_dbg\_data} & {\tt DAT\_I} \\
|
{\tt i\_dbg\_data} & {\tt DAT\_I} \\
|
{\tt o\_dbg\_ack} & {\tt ACK\_O} \\
|
{\tt o\_dbg\_ack} & {\tt ACK\_O} \\
|
{\tt o\_dbg\_stall} & {\tt STALL\_O} \\
|
{\tt o\_dbg\_stall} & {\tt STALL\_O} \\
|
{\tt o\_dbg\_data} & {\tt DAT\_O}
|
{\tt o\_dbg\_data} & {\tt DAT\_O}
|
\end{tabular}\\\hline
|
\end{tabular}\\\hline
|
\end{wishboneds}
|
\end{wishboneds}
|
\caption{Wishbone Datasheet for the Debug Interface}\label{tbl:wishbone-slave}
|
\caption{Wishbone Datasheet for the Debug Interface}\label{tbl:wishbone-slave}
|
\end{center}\end{table}
|
\end{center}\end{table}
|
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, single cycle or pipelined\\\hline
|
Type of interface & Master, Read/Write, single cycle or pipelined\\\hline
|
Address Width & 32--bit bits \\\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
|
Signal Names & \begin{tabular}{ll}
|
Signal Names & \begin{tabular}{ll}
|
Signal Name & Wishbone Equivalent \\\hline
|
Signal Name & Wishbone Equivalent \\\hline
|
{\tt i\_clk} & {\tt CLK\_O} \\
|
{\tt i\_clk} & {\tt CLK\_O} \\
|
{\tt o\_wb\_cyc} & {\tt CYC\_O} \\
|
{\tt o\_wb\_cyc} & {\tt CYC\_O} \\
|
{\tt o\_wb\_stb} & {\tt STB\_O} \\
|
{\tt o\_wb\_stb} & {\tt STB\_O} \\
|
{\tt o\_wb\_we} & {\tt WE\_O} \\
|
{\tt o\_wb\_we} & {\tt WE\_O} \\
|
{\tt o\_wb\_addr} & {\tt ADR\_O} \\
|
{\tt o\_wb\_addr} & {\tt ADR\_O} \\
|
{\tt o\_wb\_data} & {\tt DAT\_O} \\
|
{\tt o\_wb\_data} & {\tt DAT\_O} \\
|
{\tt i\_wb\_ack} & {\tt ACK\_I} \\
|
{\tt i\_wb\_ack} & {\tt ACK\_I} \\
|
{\tt i\_wb\_stall} & {\tt STALL\_I} \\
|
{\tt i\_wb\_stall} & {\tt STALL\_I} \\
|
{\tt i\_wb\_data} & {\tt DAT\_I}
|
{\tt i\_wb\_data} & {\tt DAT\_I}
|
\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
|
Rather, the debug port of the CPU should be accessible regardless of the state
|
of the master bus.
|
of the master bus.
|
|
|
You may wish to notice that neither the {\tt ERR} nor the {\tt RETRY} wires
|
You may wish to notice that neither the {\tt ERR} nor the {\tt RETRY} wires
|
have been implemented. What this means is that the CPU is currently unable
|
have been implemented. What this means is that the CPU is currently unable
|
to detect a bus error condition, and so may stall indefinitely (hang) should
|
to detect a bus error condition, and so may stall indefinitely (hang) should
|
it choose to access a value not on the bus, or a peripheral that is not
|
it choose to access a value not on the bus, or a peripheral that is not
|
yet properly configured.
|
yet properly configured.
|
|
|
\chapter{Clocks}\label{chap:clocks}
|
\chapter{Clocks}\label{chap:clocks}
|
|
|
This core is based upon the Basys--3 development board sold by Digilent.
|
This core is based upon the Basys--3 development board sold by Digilent.
|
The Basys--3 development board contains one external 100~MHz clock, which is
|
The Basys--3 development board contains one external 100~MHz clock, which is
|
sufficient to run the ZIP CPU core.
|
sufficient to run the ZIP CPU core.
|
\begin{table}[htbp]
|
\begin{table}[htbp]
|
\begin{center}
|
\begin{center}
|
\begin{clocklist}
|
\begin{clocklist}
|
i\_clk & External & 100~MHz & 100~MHz & System clock.\\\hline
|
i\_clk & External & 100~MHz & 100~MHz & System clock.\\\hline
|
\end{clocklist}
|
\end{clocklist}
|
\caption{List of Clocks}\label{tbl:clocks}
|
\caption{List of Clocks}\label{tbl:clocks}
|
\end{center}\end{table}
|
\end{center}\end{table}
|
I hesitate to suggest that the core can run faster than 100~MHz, since I have
|
I hesitate to suggest that the core can run faster than 100~MHz, since I have
|
had struggled with various timing violations to keep it at 100~MHz. So, for
|
had struggled with various timing violations to keep it at 100~MHz. So, for
|
now, I will only state that it can run at 100~MHz.
|
now, I will only state that it can run at 100~MHz.
|
|
|
|
|
\chapter{I/O Ports}\label{chap:ioports}
|
\chapter{I/O Ports}\label{chap:ioports}
|
|
The I/O ports to the Zip CPU may be grouped into three categories. The first
|
|
is that of the master wishbone used by the CPU, then the slave wishbone used
|
|
to command the CPU via a debugger, and then the rest. The first two of these
|
|
were already discussed in the wishbone chapter. They are listed here
|
|
for completeness in Tbl.~\ref{tbl:iowb-master}
|
|
\begin{table}
|
|
\begin{center}\begin{portlist}
|
|
{\tt o\_wb\_cyc} & 1 & Output & Indicates an active Wishbone cycle\\\hline
|
|
{\tt o\_wb\_stb} & 1 & Output & WB Strobe signal\\\hline
|
|
{\tt o\_wb\_we} & 1 & Output & Write enable\\\hline
|
|
{\tt o\_wb\_addr} & 32 & Output & Bus address \\\hline
|
|
{\tt o\_wb\_data} & 32 & Output & Data on WB write\\\hline
|
|
{\tt i\_wb\_ack} & 1 & Input & Slave has completed a R/W cycle\\\hline
|
|
{\tt i\_wb\_stall} & 1 & Input & WB bus slave not ready\\\hline
|
|
{\tt i\_wb\_data} & 32 & Input & Incoming bus data\\\hline
|
|
\end{portlist}\caption{CPU Master Wishbone I/O Ports}\label{tbl:iowb-master}\end{center}\end{table}
|
|
and~\ref{tbl:iowb-slave} respectively.
|
|
\begin{table}
|
|
\begin{center}\begin{portlist}
|
|
{\tt i\_wb\_cyc} & 1 & Input & Indicates an active Wishbone cycle\\\hline
|
|
{\tt i\_wb\_stb} & 1 & Input & WB Strobe signal\\\hline
|
|
{\tt i\_wb\_we} & 1 & Input & Write enable\\\hline
|
|
{\tt i\_wb\_addr} & 1 & Input & Bus address, command or data port \\\hline
|
|
{\tt i\_wb\_data} & 32 & Input & Data on WB write\\\hline
|
|
{\tt o\_wb\_ack} & 1 & Output & Slave has completed a R/W cycle\\\hline
|
|
{\tt o\_wb\_stall} & 1 & Output & WB bus slave not ready\\\hline
|
|
{\tt o\_wb\_data} & 32 & Output & Incoming bus data\\\hline
|
|
\end{portlist}\caption{CPU Debug Wishbone I/O Ports}\label{tbl:iowb-slave}\end{center}\end{table}
|
|
|
|
There are only four other lines to the CPU: the external clock, external
|
|
reset, incoming external interrupt line(s), and the outgoing debug interrupt
|
|
line. These are shown in Tbl.~\ref{tbl:ioports}.
|
|
\begin{table}
|
|
\begin{center}\begin{portlist}
|
|
{\tt i\_clk} & 1 & Input & The master CPU clock \\\hline
|
|
{\tt i\_rst} & 1 & Input & Active high reset line \\\hline
|
|
{\tt i\_ext\_int} & 1\ldots 6 & Input & Incoming external interrupts \\\hline
|
|
{\tt o\_ext\_int} & 1 & Output & CPU Halted interrupt \\\hline
|
|
\end{portlist}\caption{I/O Ports}\label{tbl:ioports}\end{center}\end{table}
|
|
The clock line was discussed briefly in Chapt.~\ref{chap:clocks}. We
|
|
typically run it at 100~MHz. The reset line is an active high reset. When
|
|
asserted, the CPU will start running again from its reset address in
|
|
memory. Further, depending upon how the CPU is configured and specifically on
|
|
the {\tt START\_HALTED} parameter, it may or may not start running
|
|
automatically. The {\tt i\_ext\_int} line is for an external interrupt. This
|
|
line may be as wide as 6~external interrupts, depending upon the setting of
|
|
the {\tt EXTERNAL\_INTERRUPTS} line. As currently configured, the ZipSystem
|
|
only supports one such interrupt line by default. For us, this line is the
|
|
output of another interrupt controller, but that's a board specific setup
|
|
detail. Finally, the Zip System produces one external interrupt whenever
|
|
the CPU halts to wait for the debugger.
|
|
|
% Appendices
|
% Appendices
|
% Index
|
% Index
|
\end{document}
|
\end{document}
|
|
|
|
|
|
|