| Line 42... |
Line 42... |
%% http://www.gnu.org/licenses/gpl.html
|
%% http://www.gnu.org/licenses/gpl.html
|
%%
|
%%
|
%%
|
%%
|
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
\documentclass{gqtekspec}
|
\documentclass{gqtekspec}
|
|
\usepackage{import}
|
|
% \graphicspath{{../gfx}}
|
\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.5}
|
\revision{Rev.~0.6}
|
\definecolor{webred}{rgb}{0.2,0,0}
|
\definecolor{webred}{rgb}{0.2,0,0}
|
\definecolor{webgreen}{rgb}{0,0.2,0}
|
\definecolor{webgreen}{rgb}{0,0.2,0}
|
\usepackage[dvips,ps2pdf,colorlinks=true,
|
\usepackage[dvips,ps2pdf,colorlinks=true,
|
anchorcolor=black,pagecolor=webgreen,pdfpagelabels,hypertexnames,
|
anchorcolor=black,pagecolor=webgreen,pdfpagelabels,hypertexnames,
|
pdfauthor={Dan Gisselquist},
|
pdfauthor={Dan Gisselquist},
|
| Line 74... |
Line 76... |
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.6 & 11/17/2015 & Gisselquist & Added graphics to illustrate pipeline discussion.\\\hline
|
0.5 & 9/29/2015 & Gisselquist & Added pipelined memory access discussion.\\\hline
|
0.5 & 9/29/2015 & Gisselquist & Added pipelined memory access discussion.\\\hline
|
0.4 & 9/19/2015 & Gisselquist & Added DMA controller, improved stall information, and self--assessment info.\\\hline
|
0.4 & 9/19/2015 & Gisselquist & Added DMA controller, improved stall information, and self--assessment info.\\\hline
|
0.3 & 8/22/2015 & Gisselquist & First completed draft\\\hline
|
0.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
|
| Line 165... |
Line 168... |
\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}
|
|
|
|
The Zip CPU also has one very unique feature: the ability to do pipelined loads
|
|
and stores. This allows the CPU to access on-chip memory at one access per
|
|
clock, minus a stall for the initial access.
|
|
|
|
\section{Characteristics of a SwiC}
|
|
|
|
Here, we shall define a soft core internal to an FPGA as a ``System within a
|
|
Chip,'' or a SwiC. SwiCs have some very unique properties internal to them
|
|
that have influenced the design of the Zip CPU. Among these are the bus,
|
|
memory, and available peripherals.
|
|
|
|
Most other approaches to soft core CPU's employ a Harvard architecture.
|
|
This allows these other CPU's to have two separate bus structures: one for the
|
|
program fetch, and the other for thememory. The Zip CPU is fairly unique in
|
|
its approach because it uses a von Neumann architecture. This was done for
|
|
simplicity. By using a von Neumann architecture, only one bus needs to be
|
|
implemented within any FPGA. This helps to minimize real-estate, while
|
|
maintaining a high clock speed. The disadvantage is that it can severely
|
|
degrade the overall instructions per clock count.
|
|
|
|
Soft core's within an FPGA have an additional characteristic regarding
|
|
memory access: it is slow. Memory on chip may be accessed at a single
|
|
cycle per access, but small FPGA's have a limited amount of memory on chip.
|
|
Going off chip, however, is expensive. Two examples will prove this point. On
|
|
the XuLA2 board, Flash can be accessed at 128~cycles per 32--bit word,
|
|
or 64~cycles per subsequent word in a pipelined architecture. Likewise, the
|
|
SDRAM chip on the XuLA2 board allows 6~cycle access for a write, 10~cycles
|
|
per read, and 2~cycles for any subsequent pipelined access read or write.
|
|
Either way you look at it, this memory access will be slow and this doesn't
|
|
account for any logic delays should the bus implementation logic get
|
|
complicated.
|
|
|
|
As may be noticed from the above discussion about memory speed, a second
|
|
characteristic of memory is that all memory accesses may be pipelined, and
|
|
that pipelined memory access is faster than non--pipelined access. Therefore,
|
|
a SwiC soft core should support pipelined operations, but it should also
|
|
allow a higher priority subsystem to get access to the bus (no starvation).
|
|
|
|
As a further characteristic of SwiC memory options, on-chip cache's are
|
|
expensive. If you want to have a minimum of logic, cache logic may not be
|
|
the highest on the priority list.
|
|
|
|
In sum, memory is slow. While one processor on one FPGA may be able to fill
|
|
its pipeline, the same processor on another FPGA may struggle to get more than
|
|
one instruction at a time into the pipeline. Any SwiC must be able to deal
|
|
with both cases: fast and slow memories.
|
|
|
|
A final characteristic of SwiC's within FPGA's is the peripherals.
|
|
Specifically, FPGA's are highly reconfigurable. Soft peripherals can easily
|
|
be created on chip to support the SwiC if necessary. As an example, a simple
|
|
30-bit peripheral could easily support reversing 30-bit numbers: a read from
|
|
the peripheral returns it's bit--reversed address. This is cheap within an
|
|
FPGA, but expensive in instructions.
|
|
|
|
Indeed, anything that must be done fast within an FPGA is likely to already
|
|
be done--elsewhere in the fabric. This leaves the CPU with the role of handling
|
|
sequential tasks that need a lot of state.
|
|
|
|
This means that the SwiC needs to live within a very unique environment,
|
|
separate and different from the traditional SoC. That isn't to say that a
|
|
SwiC cannot be turned into a SoC, just that this SwiC has not been designed
|
|
for that purpose.
|
|
|
|
\section{Lessons Learned}
|
|
|
Now, however, that I've worked on the Zip CPU for a while, it is not nearly
|
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 External Debug:} Once placed upon an FPGA, some external means is
|
\item {\bf External Debug:} Once placed upon an FPGA, some external means is
|
| Line 237... |
Line 305... |
\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
|
First, and ideal pipeline might look something like
|
stepping, the CPU needs to know what instructions have finished, and
|
Fig.~\ref{fig:ideal-pipeline}.
|
which have not. In other words, it needs to know where it can restart
|
\begin{figure}
|
the pipeline from. Once restarted, it must act as though it had
|
\begin{center}
|
never stopped. This killed my idea of delayed branching, since what
|
\includegraphics[width=4in]{../gfx/fullpline.eps}
|
would be the appropriate program counter to restart at? The one the
|
\caption{An Ideal Pipeline: One instruction per clock cycle}\label{fig:ideal-pipeline}
|
CPU was going to branch to, or the ones in the delay slots? This
|
\end{center}\end{figure}
|
also makes the idea of compressed instruction codes difficult, since,
|
Notice that, in this figure, all the pipeline stages are complete and
|
again, where do you restart on interrupt?
|
full. Every instruction takes one clock and there are no delays.
|
|
However, as the discussion above pointed out, the memory associated
|
|
with a SwiC may not allow single clock access. It may be instead
|
|
that you can only read every two clocks. In that case, what shall
|
|
the pipeline look like? Should it look like
|
|
Fig.~\ref{fig:waiting-pipeline},
|
|
\begin{figure}\begin{center}
|
|
\includegraphics[width=4in]{../gfx/stuttra.eps}
|
|
\caption{Instructions wait for each other}\label{fig:waiting-pipeline}
|
|
\end{center}\end{figure}
|
|
where instructions are held back until the pipeline is full, or should
|
|
it look like Fig.~\ref{fig:independent-pipeline},
|
|
\begin{figure}\begin{center}
|
|
\includegraphics[width=4in]{../gfx/stuttrb.eps}
|
|
\caption{Instructions proceed independently}\label{fig:independent-pipeline}
|
|
\end{center}\end{figure}
|
|
where each instruction is allowed to move through the pipeline
|
|
independently? For better or worse, the Zip CPU allows instructions
|
|
to move through the pipeline independently.
|
|
|
|
One approach to avoiding stalls is to use a branch delay slot,
|
|
such as is shown in Fig.~\ref{fig:brdelay}.
|
|
\begin{figure}\begin{center}
|
|
\includegraphics[width=4in]{../gfx/bdly.eps}
|
|
\caption{A typical branch delay slot approach}\label{fig:brdelay}
|
|
\end{center}\end{figure}
|
|
In this figure, instructions
|
|
{\tt BR} (a branch), {\tt BD} (a branch delay instruction),
|
|
are followed by instructions after the branch: {\tt IA}, {\tt IB}, etc.
|
|
Since it takes a processor a clock cycle to execute a branch, the
|
|
delay slot allows the processor to do something useful in that
|
|
branch. The problem the Zip CPU has with this approach is, what
|
|
happens when the pipeline looks like Fig.~\ref{fig:brbroken}?
|
|
\begin{figure}\begin{center}
|
|
\includegraphics[width=4in]{../gfx/bdbroken.eps}
|
|
\caption{The branch delay slot breaks with a slow memory}\label{fig:brbroken}
|
|
\end{center}\end{figure}
|
|
In this case, the branch delay slot never gets filled in the first
|
|
place, and so the pipeline squashes it before it gets executed.
|
|
If not that, then what happens when handling interrupts or
|
|
debug stepping: when has the CPU finished an instruction?
|
|
When the {\tt BR} instruction has finished, or must {\tt BD}
|
|
follow every {\tt BR}? and, again, what if the pipeline isn't
|
|
full?
|
|
These thoughts killed any hopes of doing delayed branching.
|
|
|
So I switched to a model of discrete execution: Once an instruction
|
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 preceding 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 preceding are all wiped clean.
|
PC address, the stages preceding are all wiped clean.
|
|
|
The discrete execution model allows such things as sleeping: if the
|
This model, however, generated too many pipeline stalls, so the
|
|
discrete execution model was modified to allow instructions to go
|
|
through the ALU unit and be canceled before writeback. This removed
|
|
the stall associated with ALU instructions before untaken branches.
|
|
|
|
The discrete execution model allows such things as sleeping, as
|
|
outlined in Fig.~\ref{fig:sleeping}.
|
|
\begin{figure}\begin{center}
|
|
\includegraphics[width=4in]{../gfx/sleep.eps}
|
|
\caption{How the CPU halts when sleeping}\label{fig:sleeping}
|
|
\end{center}\end{figure}
|
|
If the
|
CPU is put to ``sleep,'' the ALU and memory stages stall and back up
|
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, as illustrated in Fig.~\ref{fig:stacking}.
|
|
\begin{figure}\begin{center}
|
|
\includegraphics[width=4in]{../gfx/stacking.eps}
|
|
\caption{Instructions can stack up behind a stalled instruction}\label{fig:stacking}
|
|
\end{center}\end{figure}
|
|
|
This approach is also different from other pipeline approaches. Instead
|
This approach is also different from other pipeline approaches.
|
of keeping the entire pipeline filled, each stage is treated
|
Instead 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
|
| Line 334... |
Line 461... |
\begin{table}\begin{center}
|
\begin{table}\begin{center}
|
\begin{bitlist}
|
\begin{bitlist}
|
31\ldots 11 & R/W & Reserved for future uses\\\hline
|
31\ldots 11 & R/W & Reserved for future uses\\\hline
|
10 & R & (Reserved for) Bus-Error Flag\\\hline
|
10 & R & (Reserved for) Bus-Error Flag\\\hline
|
9 & R & Trap, or user interrupt, Flag. Cleared on return to userspace.\\\hline
|
9 & R & Trap, or user interrupt, Flag. Cleared on return to userspace.\\\hline
|
8 & R & (Reserved for) Illegal Instruction Flag\\\hline
|
8 & R & Illegal Instruction Flag\\\hline
|
7 & R/W & Break--Enable\\\hline
|
7 & R/W & Break--Enable\\\hline
|
6 & R/W & Step\\\hline
|
6 & R/W & Step\\\hline
|
5 & R/W & Global Interrupt Enable (GIE)\\\hline
|
5 & R/W & Global Interrupt Enable (GIE)\\\hline
|
4 & R/W & Sleep. When GIE is also set, the CPU waits for an interrupt.\\\hline
|
4 & R/W & Sleep. When GIE is also set, the CPU waits for an interrupt.\\\hline
|
3 & R/W & Overflow\\\hline
|
3 & R/W & Overflow\\\hline
|
| Line 399... |
Line 526... |
%
|
%
|
|
|
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 an illegal instruction bit. When the CPU
|
The ninth bit is an illegal instruction bit. When the CPU
|
tries to execute either a non-existant instruction, or an instruction from
|
tries to execute either a non-existant instruction, or an instruction from
|
an address that produces a bus error, the CPU will (once implemented) switch
|
an address that produces a bus error, the CPU will (if implemented) switch
|
to supervisor mode while setting this bit. The bit will automatically be
|
to supervisor mode while setting this bit. The bit will automatically be
|
cleared upon any return to user mode.
|
cleared upon any return to user mode.
|
|
|
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
|
| Line 416... |
Line 543... |
\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 returning 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 & Illegal instruction error flag \\\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
|
| Line 452... |
Line 579... |
\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. Conditioning on a non--supported condition
|
I ran out of space in 3--bits. Conditioning on a non--supported condition
|
is still possible, but it will take an extra instruction and a pipeline stall. (Ex: \hbox{\em (Stall)}; \hbox{\tt TST \$4,CC;} \hbox{\tt STO.NZ R0,(R1)})
|
is still possible, but it will take an extra instruction and a pipeline stall. (Ex: \hbox{\em (Stall)}; \hbox{\tt TST \$4,CC;} \hbox{\tt STO.NZ R0,(R1)})
|
|
As an alternative, the condition may often be reversed, recovering those
|
|
extra two clocks. Thus instead of \hbox{\tt CMP Rx,Ry;}
|
|
\hbox{\tt BNV label} you can issue a \hbox{\tt CMP Ry,Rx;} \hbox{\tt BV label}.
|
|
|
Conditionally executed ALU instructions will not further adjust the
|
Conditionally executed ALU instructions will not further adjust the
|
condition codes.
|
condition codes, with the exception of \hbox{\tt CMP} and \hbox{\tt TST}
|
|
instructions. Conditional \hbox{\tt CMP} or \hbox{\tt TST} instructions
|
|
will adjust conditions whenever their conditionals are true. In this way,
|
|
multiple conditions may be evaluated without branches. For example, to do
|
|
something if \hbox{\tt R0} is one and \hbox{\tt R1} is two, one might try
|
|
code such as Tbl.~\ref{tbl:dbl-condition}.
|
|
\begin{table}\begin{center}
|
|
\begin{tabular}{l}
|
|
{\tt CMP 1,R0} \\
|
|
{;\em Condition codes are now set based upon R0-1} \\
|
|
{\tt CMP.Z 2,R1} \\
|
|
{;\em If R0 $\neq$ 1, conditions are unchanged.} \\
|
|
{;\em If R0 $=$ 1, conditions are set based upon R1-2.} \\
|
|
{;\em Now do something based upon the conjunction of both conditions.} \\
|
|
{;\em While we use the example of a STO, it could be any instruction.} \\
|
|
{\tt STO.Z R0,(R2)} \\
|
|
\end{tabular}
|
|
\caption{An example of a double conditional}\label{tbl:dbl-condition}
|
|
\end{center}\end{table}
|
|
|
|
\section{Traditional Interrupt Handling}
|
|
|
\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
|
| Line 999... |
Line 1149... |
prefetch cache is loaded to support the next instruction.
|
prefetch cache 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 (5 stall cycles)
|
return from interrupt or switch to interrupt context (5 stall cycles)
|
|
|
If the PC suddenly changes, the pipeline is subsequently cleared and needs to
|
Fig.~\ref{fig:bcstalls}
|
be reloaded. Given that there are five stages to the pipeline, that accounts
|
\begin{figure}\begin{center}
|
for four of the five stalls. The stall cycle is lost in the pipelined prefetch
|
\includegraphics[width=3.5in]{../gfx/bc.eps}
|
stage which needs at least one clock with a valid PC before it can produce
|
\caption{A conditional branch generates 5 stall cycles}\label{fig:bcstalls}
|
a new output.
|
\end{center}\end{figure}
|
|
illustrates the situation for a conditional branch. In this case, the branch
|
|
instruction, {\tt BC}, is nominally followed by instructions {\tt I0} and so
|
|
forth. However, since the branch is taken, the next instruction must be
|
|
{\tt IA}. Therefore, the pipeline needs to be cleared and reloaded.
|
|
Given that there are five stages to the pipeline, that accounts
|
|
for four of the five stalls. The last stall cycle is lost in the pipelined
|
|
prefetch stage which needs at least one clock with a valid PC before it can
|
|
produce a new output. {\Large\bf Note: When I did this myself, I counted
|
|
six stall cycles, for a total of seven cycles for this instruction. Is five
|
|
really the right answer?}
|
|
|
The Zip CPU handles {\tt MOV \$X(PC),PC}, {\tt ADD \$X,PC}, and
|
The Zip CPU handles {\tt MOV \$X(PC),PC}, {\tt ADD \$X,PC}, and
|
{\tt LDI \$X,PC} instructions specially, however. These instructions, when
|
{\tt LDI \$X,PC} instructions specially, however. These instructions, when
|
not conditioned on the flags, can execute with only 3~stall cycles.
|
not conditioned on the flags, can execute with only 2~stall cycles, such as
|
|
is shown in Fig.~\ref{fig:branch}.\footnote{Note that this behavior is
|
|
slated to be improved upon in subsequent releases. With a better prefetch,
|
|
it should be possible to drop this down to one or zero stall cycles.}
|
|
\begin{figure}\begin{center}
|
|
\includegraphics[width=4in]{../gfx/bra.eps}
|
|
\caption{An expedited delay costs only 2~stall cycles}\label{fig:branch}
|
|
\end{center}\end{figure}
|
|
In this example, {\tt BR} is a branch always taken, {\tt I1} is the instruction
|
|
following the branch in memory, while {\tt IA} is the first instruction at the
|
|
branch address. ({\tt CLR} denotes a clear--pipeline operation, and does
|
|
not represent any instruction.)
|
|
|
\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)}
|
| Line 1024... |
Line 1195... |
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.
|
That is, any instruction that does not add an immediate to {\tt RA} may be
|
That is, any instruction that does not add an immediate to {\tt RA} may be
|
scheduled into the stall slot.
|
scheduled into the stall slot.
|
|
|
\item When any write to either the CC or PC Register is followed by a memory
|
\item When any (conditional) write to either the CC or PC Register is followed
|
operation
|
by a memory operation
|
\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 LOD \$X(RA),RB}
|
\item\ {\tt LOD \$X(RA),RB}
|
\end{enumerate}
|
\end{enumerate}
|
|
A timing diagram of this pipeline situation is shown in Fig.~\ref{fig:bcmem},
|
|
\begin{figure}\begin{center}
|
|
\includegraphics[width=2in]{../gfx/bcmem.eps}
|
|
\caption{A (not taken) conditional branch followed by a memory operation}\label{fig:bcmem}
|
|
\end{center}\end{figure}
|
|
for a conditional branch, {\tt BC}, a memory operation, {\tt Mem} (which
|
|
must be a load here), and ALU instructions {\tt I1} and so forth.
|
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--forcing the
|
|
memory operation to stay in the operand decode stage. 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 may be mitigated by shuffling the operations immediately following
|
This stall may be mitigated by shuffling the operations immediately following
|
a potential branch so that an ALU operation follows the branch instead of a
|
a potential branch so that an ALU operation follows the branch instead of a
|
| Line 1048... |
Line 1227... |
\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 {\em during} the writeback cycle.
|
determined. Trying to then place these into the input for one of the operands
|
Trying to then place these into the input for one of the operands for an
|
|
ALU instruction during the same cycle
|
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
|
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 does not set flags in between the ALU operation and the instruction
|
that references the CC register. For example, {\tt MOV \$addr+PC,uPC}
|
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
|
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}
|
this stall, whereas an {\tt OR \$BREAKEN,CC} followed by an {\tt OR \$STEP,CC}
|
will incur the stall, while a {\tt LDI \$BREAKEN|\$STEP,CC} will not.
|
will incur the stall, while a {\tt LDI \$BREAKEN|\$STEP,CC} will not since
|
|
it doesn't read the condition codes.
|
|
|
\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, 4 clocks best)}
|
\item\ {\em (multiple stalls, bus dependent, 4 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 illustrated in
|
|
Fig.~\ref{fig:memrd},
|
|
\begin{figure}\begin{center}
|
|
\includegraphics[width=5in]{../gfx/memrd.eps}
|
|
\caption{Pipeline handling of a load instruction}\label{fig:memrd}
|
|
\end{center}\end{figure}
|
|
since it is especially true of a load
|
instruction, which must still write its operand back to the register file.
|
instruction, which must still write its operand back to the register file.
|
Store instructions are different, since they can be busy with no impact on
|
Note that there is an extra stall at the end of the memory cycle, so that
|
later ALU write back operations. Hence, only loads stall the pipeline.
|
the memory unit will be idle for one clock before an instruction will be
|
|
accepted into the ALU.
|
|
Store instructions are different, as shown in Fig.~\ref{fig:memwr},
|
|
\begin{figure}\begin{center}
|
|
\includegraphics[width=5in]{../gfx/memwr.eps}
|
|
\caption{Pipeline handling of a store instruction}\label{fig:memwr}
|
|
\end{center}\end{figure}
|
|
since they can be busy with the bus without impacting later write back
|
|
pipeline stages. Hence, only loads stall the pipeline.
|
|
|
This also assumes that the memory being accessed is a single cycle memory.
|
This, of course, also assumes that the memory being accessed is a single cycle
|
|
memory and that there are no stalls to get to the 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 forty 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. Likewise, if it takes a couple
|
|
of clock cycles for the bus to be free, as shown in both Figs.~\ref{fig:memrd}
|
|
and~\ref{fig:memwr}, there will be stalls.
|
|
|
\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, 4 clocks best)}
|
\item\ {\em (multiple stalls, bus dependent, 4 clocks best)}
|
\item\ {\tt LOD address,RB}
|
\item\ {\tt LOD address,RB}
|
\item\ {\em (multiple stalls, bus dependent, 4 clocks best)}
|
\item\ {\em (multiple stalls, bus dependent, 4 clocks best)}
|
\end{enumerate}
|
\end{enumerate}
|
|
|
In this case, the LOD instruction cannot start until the STO is finished.
|
In this case, the LOD instruction cannot start until the STO is finished,
|
|
as illustrated by Fig.~\ref{fig:mstld}.
|
|
\begin{figure}\begin{center}
|
|
\includegraphics[width=5.5in]{../gfx/mstld.eps}
|
|
\caption{Pipeline handling of a store followed by a load instruction}\label{fig:mstld}
|
|
\end{center}\end{figure}
|
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
|
memory unit is busy with the STO instruction, but otherwise this pipeline will
|
memory unit is busy with the STO instruction, but otherwise this pipeline will
|
stall waiting for it to complete.
|
stall while waiting for it to complete before the load instruction can
|
|
start.
|
|
|
The Zip CPU does have the capability of supporting pipelined memory access,
|
The Zip CPU does have the capability of supporting pipelined memory access,
|
but only under the following conditions: all accesses within the pipeline
|
but only under the following conditions: all accesses within the pipeline
|
must all be reads or all be writes, all must use the same register for their
|
must all be reads or all be writes, all must use the same register for their
|
address, and there can be no stalls or other instructions between pipelined
|
address, and there can be no stalls or other instructions between pipelined
|
memory access instructions. Further, the offset to memory must be increasing
|
memory access instructions. Further, the offset to memory must be increasing
|
by one address each instruction. These conditions work well for saving or
|
by one address each instruction. These conditions work well for saving or
|
storing registers to the stack.
|
storing registers to the stack. Indeed, if you noticed, both
|
|
Fig.~\ref{fig:memrd} and Fig.~\ref{fig:memwr} illustrated pipelined memory
|
|
accesses.
|
|
|
\item When waiting for a conditional memory read operation to complete
|
\item When waiting for a conditional memory read operation to complete
|
\begin{enumerate}
|
\begin{enumerate}
|
\item\ {\tt LOD.Z address,RA}
|
\item\ {\tt LOD.Z address,RA}
|
\item\ {\em (multiple stalls, bus dependent, 7 clocks best)}
|
\item\ {\em (multiple stalls, bus dependent, 7 clocks best)}
|
| Line 1132... |
Line 1338... |
\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}\label{sec:pic}
|
|
|
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'b1) 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
|
| Line 1165... |
Line 1371... |
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 (perhaps
|
come from an external interrupt controller, and one interrupt line from the
|
more if you configure it for more) which may come from an external interrupt
|
secondary controller. Other primary interrupts include the system timers,
|
controller, and one interrupt line from the secondary controller. Other
|
the jiffies interrupt, and the manual cache interrupt. The secondary interrupt
|
primary interrupts include the system timers, the jiffies interrupt, and the
|
controller maintains an interrupt state for all of the processor accounting
|
manual cache interrupt. The secondary interrupt controller maintains an
|
counters.
|
interrupt state for all of the processor accounting counters.
|
|
|
\section{Counter}
|
\section{Counter}
|
|
|
The Zip Counter is a very simple counter: it just counts. It cannot be
|
The Zip Counter is a very simple counter: it just counts. It cannot be
|
halted. When it rolls over, it issues an interrupt. Writing a value to the
|
halted. When it rolls over, it issues an interrupt. Writing a value to the
|
| Line 1193... |
Line 1399... |
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$ (about 21~seconds using a 100~MHz clock),
|
|
rather than $2^{32}-1$.
|
|
|
\section{Watchdog Timer}
|
\section{Watchdog Timer}
|
|
|
The watchdog timer is no different from any of the other timers, save for one
|
The watchdog timer is no different from any of the other timers, save for one
|
critical difference: the interrupt line from the watchdog
|
critical difference: the interrupt line from the watchdog
|
| Line 1207... |
Line 1414... |
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{Bus Watchdog}
|
|
There is an additional watchdog timer on the Wishbone bus. This timer,
|
|
however, is hardware configured and not software configured. The timer is
|
|
reset at the beginning of any bus transaction, and only counts clocks during
|
|
such bus transactions. If the bus transaction takes longer than the number
|
|
of counts the timer allots, it will raise a bus error flag to terminate the
|
|
transaction. This is useful in the case of any peripherals that are
|
|
misbehaving. If the bus watchdog terminates a bus transaction, the CPU may
|
|
then read from its port to find out which memory location created the problem.
|
|
|
|
Aside from its unusual configuration, the bus watchdog is just another
|
|
implementation of the fundamental timer described above.
|
|
|
\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'
|
| Line 1305... |
Line 1525... |
complete.
|
complete.
|
|
|
Eventually, I intend to place an operating system onto the ZipSystem, I'm
|
Eventually, I intend to place an operating system onto the ZipSystem, I'm
|
just not there yet.
|
just not there yet.
|
|
|
The rest of this chapter examines some common programming constructs, and
|
The rest of this chapter examines some common programming models, and how they
|
how they might be applied to the Zip System.
|
might be applied to the Zip System, and then finish with a couple of examples.
|
|
|
|
\section{System High}
|
|
The easiest and simplest way to run the Zip CPU is in the system high mode.
|
|
In this mode, the CPU runs your program in supervisor mode from reboot to
|
|
power down, and is never interrupted. You will need to poll the interrupt
|
|
controller to determine when any external condition has become active. This
|
|
mode is useful, and can handle many microcontroller tasks.
|
|
|
|
Even better, in system high mode, all of the user registers are available
|
|
to the system high program as variables. Accessing these registers can be
|
|
done in a single clock cycle, which would move them to the active register
|
|
set or move them back. While this may seem like a load or store instruction,
|
|
none of these register accesses will suffer from memory delays.
|
|
|
|
The one thing that cannot be done in supervisor mode is a wait for interrupt
|
|
instruction. This, however, is easily rectified by jumping to a user task
|
|
within the supervisors memory space, such as Tbl.~\ref{tbl:shi-idle}.
|
|
\begin{table}\begin{center}
|
|
\begin{tabbing}
|
|
{\tt supervisor\_idle:} \\
|
|
\hbox to 0.25in{}\={\em ; While not strictly required, the following move helps to} \\
|
|
\> {\em ; ensure that the prefetch doesn't try to fetch an instruction} \\
|
|
\> {\em ; outside of the CPU's address space when it switches to user} \\
|
|
\> {\em ; mode.} \\
|
|
\> {\tt MOV supervisor\_idle\_continue,uPC} \\
|
|
\> {\em ; Put the processor into user mode and to sleep in the same} \\
|
|
\> {\em ; instruction. } \\
|
|
\> {\tt OR \$SLEEP|\$GIE,CC} \\
|
|
{\tt supervisor\_idle\_continue:} \\
|
|
\> {\em ; Now, if we haven't done this inline, we need to return} \\
|
|
\> {\em ; to whatever function called us.} \\
|
|
\> {\tt RETN} \\
|
|
\end{tabbing}
|
|
\caption{Executing an idle from supervisor mode}\label{tbl:shi-idle}
|
|
\end{center}\end{table}
|
|
|
|
\section{Traditional Interrupt Handling}
|
|
Although the Zip CPU does not have a traditional interrupt architecture,
|
|
it is possible to create the more traditional interrupt approach via software.
|
|
In this mode, the programmable interrupt controller is used together with the
|
|
supervisor state to create the illusion of more traditional interrupt handling.
|
|
|
|
To set this up, upon reboot the supervisor task:
|
|
\begin{enumerate}
|
|
\item Creates a (single) user context, a user stack, and sets the user
|
|
program counter to the entry of the user task
|
|
\item Creates a task table of ISR entries
|
|
\item Enables the master interrupt enable via the interrupt controller, albeit
|
|
without enabling any of the fifteen potential underlying interrupts.
|
|
\item Switches to user mode, as the first part of the while loop in
|
|
Tbl.~\ref{tbl:traditional-isr}.
|
|
\end{enumerate}
|
|
\begin{table}\begin{center}
|
|
\begin{tabbing}
|
|
{\tt while(true) \{} \\
|
|
\hbox to 0.25in{}\= {\tt rtu();}\\
|
|
\> {\tt if (trap) \{} {\em // Here, we allow users to install ISRs, or} \\
|
|
\>\hbox to 0.25in{}\= {\em // whatever else they may wish to do in supervisor mode.} \\
|
|
\> {\tt \} else \{} \\
|
|
\> \> {\tt volatile int *pic = PIC\_ADDRESS;} \\
|
|
\\
|
|
\> \> {\em // Save the user context before running any ISRs. This could easily be}\\
|
|
\> \> {\em // implemented as an inline assembly routine or macro}\\
|
|
\> \> {\tt SAVE\_PARTIAL\_CONTEXT; }\\
|
|
\> \> {\em // At this point, we know an interrupt has taken place: Ask the programmable}\\
|
|
\> \> {\em // interrupt controller (PIC) which interrupts are enabled and which are active.}\\
|
|
\> \> {\tt int picv = *pic;}\\
|
|
\> \> {\em // Turn off all active interrupts}\\
|
|
\> \> {\em // Globally disable interrupt generation in the process}\\
|
|
\> \> {\tt int active = (picv >> 16) \& picv \& 0x07fff;}\\
|
|
\> \> {\tt *pic = (active<<16);}\\
|
|
\> \> {\em // We build a mask of interrupts to re-enable in picv.}\\
|
|
\> \> {\tt picv = 0;}\\
|
|
\> \> {\tt for(int i=0,msk=1; i<15; i++, msk<<=1) \{}\\
|
|
\> \>\hbox to 0.25in{}\={\tt if ((active \& msk)\&\&(isr\_table[i])) \{}\\
|
|
\> \>\>\hbox to 0.25in{}\= {\tt mov(isr\_table[i],uPC); }\\
|
|
\> \>\>\> {\em // Acknowledge this particular interrupt. While we could acknowledge all}\\
|
|
\> \>\>\> {\em // interrupts at once, by acknowledging only those with ISR's we allow}\\
|
|
\> \>\>\> {\em // the user process to use peripherals manually, and to manually check}\\
|
|
\> \>\>\> {\em // whether or no those other interrupts had occurred.}\\
|
|
\> \>\>\> {\tt *pic = msk; }\\
|
|
\> \>\>\> {\tt rtu(); }\\
|
|
\> \>\>\> {\em // The ISR will only exit on a trap in the Zip archtecture. There is}\\
|
|
\> \>\>\> {\em // no {\tt RETI} instruction. Since the PIC holds all interrupts disabled,}\\
|
|
\> \>\>\> {\em // there is no need to check for further interrupts.}\\
|
|
\> \>\>\> {\em // }\\
|
|
\> \>\>\> {\em // The tricky part is that, because of how the PIC is built, the ISR cannot}\\
|
|
\>\>\>\> {\em // re-enable its own interrupt without re-enabling all interrupts. Hence, we}\\
|
|
\>\>\>\> {\em // look at R0 upon ISR completion to know if an interrupt needs to be }\\
|
|
\> \>\>\> {\em // re-enabled. }\\
|
|
\> \>\>\> {\tt mov(uR0,tmp); }\\
|
|
\> \>\>\> {\tt picv |= (tmp \& 0x7fff) << 16; }\\
|
|
\> \>\> {\tt \} }\\
|
|
\> \> {\tt \} }\\
|
|
\> \> {\tt RESTORE\_PARTIAL\_CONTEXT; }\\
|
|
\> \> {\em // Re-activate all (requested) interrupts }\\
|
|
\> \> {\tt *pic = picv | 0x80000000; }\\
|
|
\>{\tt \} }\\
|
|
{\tt \}}\\
|
|
\end{tabbing}
|
|
\caption{Traditional Interrupt handling}\label{tbl:traditional-isr}
|
|
\end{center}\end{table}
|
|
|
|
We can work through the interrupt handling process by examining
|
|
Tbl.~\ref{tbl:traditional-isr}. First, remember, the CPU is always running
|
|
either the user or the supervisor context. Once the supervisor switches to
|
|
user mode, control does not return until either an interrupt or a trap
|
|
has taken place. (Okay, there's also the possibility of a bus error, or an
|
|
illegal instruction such as an unimplemented floating point instruction---but
|
|
for now we'll just focus on the trap instruction.) Therefore, if the trap bit
|
|
isn't set, then we know an interrupt has taken place.
|
|
|
|
To process an interrupt, we steal the user's stack: the PC and CC registers
|
|
are saved on the stack, as outlined in Tbl.~\ref{tbl:save-partial}.
|
|
\begin{table}\begin{center}
|
|
\begin{tabbing}
|
|
SAVE\_PARTIAL\_CONTEXT: \\
|
|
\hbox to 0.25in{}\= {\em ; We save R0, CC, and PC only} \\
|
|
\> {\tt MOV -3(uSP),R3} \\
|
|
\> {\tt MOV uR0,R0} \\
|
|
\> {\tt MOV uCC,R1} \\
|
|
\> {\tt MOV uPC,R2} \\
|
|
\> {\tt STO R0,1(R3)} {\em ; Exploit memory pipelining: }\\
|
|
\> {\tt STO R1,2(R3)} {\em ; All instructions write to stack }\\
|
|
\> {\tt STO R2,3(R3)} {\em ; All offsets increment by one }\\
|
|
\> {\tt MOV R3,uSP} {\em ; Return the updated stack pointer } \\
|
|
\end{tabbing}
|
|
\caption{Example Saving Minimal User Context}\label{tbl:save-partial}
|
|
\end{center}\end{table}
|
|
This is much cheaper than the full context swap of a preemptive multitasking
|
|
kernel, but it also depends upon the ISR saving any state it uses. Further,
|
|
if multiple ISR's get called at once, this looses its optimality property
|
|
very quickly.
|
|
|
|
As Sec.~\ref{sec:pic} discusses, the top of the PIC register stores which
|
|
interrupts are enabled, and the bottom stores which have tripped. (Interrupts
|
|
may trip without being enabled, they just will not generate an interrupt to the
|
|
CPU.) Our first step is to query the register to find out our interrupt
|
|
state, and then to disable any interrupts that have tripped. To do
|
|
that, we write a one to the enable half of the register while also clearing
|
|
the top bit (master interrupt enable). This has the consequence of disabling
|
|
any and all further interrupts, not just the ones that have tripped. Hence,
|
|
upon completion, we re--enable the master interrupt bit again. Finally,
|
|
we keep track of which interrupts have tripped.
|
|
|
|
Using the bit mask of interrupts that have tripped, we walk through all fifteen
|
|
possible interrupts. If there is an ISR installed, we acknowledge and reset
|
|
the interrupt within the PIC, and then call the ISR. The ISR, however, cannot
|
|
re--enable its interrupt without re-enabling the master interrupt bit. Thus,
|
|
to keep things simple, when the ISR is finished it places its interrupt
|
|
mask back into R0, or clears R0. This tells the supervisor mode process which
|
|
interrupts to re--enable. Any other registers that the ISR uses must be
|
|
saved and restored. (This is only truly optimal if only a single ISR is
|
|
called.) As a final instruction, the ISR clears the GIE bit executing a user
|
|
trap. (Remember, the Zip CPU has no {\tt RETI} instruction to restore the
|
|
stack and return to userland. It needs to go through the supervisor mode to
|
|
get there.)
|
|
|
|
Then, once all interrupts are handled, the user context is restored in a
|
|
fashion similar to Tbl.~\ref{tbl:restore-partial}.
|
|
\begin{table}\begin{center}
|
|
\begin{tabbing}
|
|
RESTORE\_PARTIAL\_CONTEXT: \\
|
|
\hbox to 0.25in{}\= {\em ; We retore R0, CC, and PC only} \\
|
|
\> {\tt MOV uSP,R3} {\em ; Return the updated stack pointer } \\
|
|
\> {\tt LOD R0,1(R3),R0} {\em ; Exploit memory pipelining: }\\
|
|
\> {\tt LOD R1,2(R3),R1} {\em ; All instructions write to stack }\\
|
|
\> {\tt LOD R2,3(R3),R2} {\em ; All offsets increment by one }\\
|
|
\> {\tt MOV R0,uR0} \\
|
|
\> {\tt MOV R1,uCC} \\
|
|
\> {\tt MOV R2,uPC} \\
|
|
\> {\tt MOV 3(R3),uSP} \\
|
|
\end{tabbing}
|
|
\caption{Example Restoring Minimal User Context}\label{tbl:restore-partial}
|
|
\end{center}\end{table}
|
|
Again, this is short and sweet simply because any other registers that needed
|
|
saving were saved within the ISR.
|
|
|
|
There you have it: the Zip CPU, with its non-traditional interrupt architecture,
|
|
can still process interrupts in a very traditional fashion.
|
|
|
\section{Example: Idle Task}
|
\section{Example: Idle Task}
|
One task every operating system needs is the idle task, the task that takes
|
One task every operating system needs is the idle task, the task that takes
|
place when nothing else can run. On the Zip CPU, this task is quite simple,
|
place when nothing else can run. On the Zip CPU, this task is quite simple,
|
and it is shown in assemble in Tbl.~\ref{tbl:idle-asm}.
|
and it is shown in assemble in Tbl.~\ref{tbl:idle-asm}.
|
| Line 1379... |
Line 1779... |
data types. The Zip CPU does not have explicit support for smaller or larger
|
data types. The Zip CPU does not have explicit support for smaller or larger
|
data types, and so this memory copy cannot be applied at a byte level.
|
data types, and so this memory copy cannot be applied at a byte level.
|
Third, we've optimized the conditional jump to a return instruction into a
|
Third, we've optimized the conditional jump to a return instruction into a
|
conditional return instruction.
|
conditional return instruction.
|
|
|
\section{Context Switch}
|
\section{Example: Context Switch}
|
|
|
Fundamental to any multiprocessing system is the ability to switch from one
|
Fundamental to any multiprocessing system is the ability to switch from one
|
task to the next. In the ZipSystem, this is accomplished in one of a couple
|
task to the next. In the ZipSystem, this is accomplished in one of a couple
|
ways. The first step is that an interrupt happens. Anytime an interrupt
|
ways. The first step is that an interrupt happens. Anytime an interrupt
|
happens, the CPU needs to execute the following tasks in supervisor mode:
|
happens, the CPU needs to execute the following tasks in supervisor mode:
|
| Line 2049... |
Line 2449... |
\item The Zip CPU is light weight and fully featured as it exists today. For
|
\item The Zip CPU is light weight and fully featured as it exists today. For
|
anyone who wishes to build a general purpose CPU and then to
|
anyone who wishes to build a general purpose CPU and then to
|
experiment with building and adding particular features, the Zip CPU
|
experiment with building and adding particular features, the Zip CPU
|
makes a good starting point--it is fairly simple. Modifications should
|
makes a good starting point--it is fairly simple. Modifications should
|
be simple enough.
|
be simple enough.
|
\item As an estimate of the ``weight'' of this implementation, the CPU has
|
|
cost me less than 150 hours to implement from its inception.
|
|
\item The Zip CPU was designed to be an implementable soft core that could be
|
\item The Zip CPU was designed to be an implementable soft core that could be
|
placed within an FPGA, controlling actions internal to the FPGA. It
|
placed within an FPGA, controlling actions internal to the FPGA. It
|
fits this role rather nicely. It does not fit the role of a system on
|
fits this role rather nicely. It does not fit the role of a system on
|
a chip very well, but then it was never intended to be a system on a
|
a chip very well, but then it was never intended to be a system on a
|
chip but rather a system within a chip.
|
chip but rather a system within a chip.
|
| Line 2067... |
Line 2465... |
to do with two exceptions: bytewise character access and accelerated
|
to do with two exceptions: bytewise character access and accelerated
|
floating-point support.
|
floating-point support.
|
\item This simplified instruction set is easy to decode.
|
\item This simplified instruction set is easy to decode.
|
\item The simplified bus transactions (32-bit words only) were also very easy
|
\item The simplified bus transactions (32-bit words only) were also very easy
|
to implement.
|
to implement.
|
|
\item The pipelined load/store approach is novel, and can be used to greatly
|
|
increase the speed of the processor.
|
\item The novel approach of having a single interrupt vector, which just
|
\item The novel approach of having a single interrupt vector, which just
|
brings the CPU back to the instruction it left off at within the last
|
brings the CPU back to the instruction it left off at within the last
|
interrupt context doesn't appear to have been that much of a problem.
|
interrupt context doesn't appear to have been that much of a problem.
|
If most modern systems handle interrupt vectoring in software anyway,
|
If most modern systems handle interrupt vectoring in software anyway,
|
why maintain hardware support for it?
|
why maintain hardware support for it?
|
| Line 2096... |
Line 2496... |
Still, \ldots it's not bad, it's just not astonishingly good.
|
Still, \ldots it's not bad, it's just not astonishingly good.
|
|
|
\item The fact that the instruction width equals the bus width means that the
|
\item The fact that the instruction width equals the bus width means that the
|
instruction fetch cycle will always be interfering with any load or
|
instruction fetch cycle will always be interfering with any load or
|
store memory operation, with the only exception being if the
|
store memory operation, with the only exception being if the
|
instruction is already in the cache. {\em This has become the
|
instruction is already in the cache.
|
fundamental limit on the speed and performance of the CPU!}
|
|
Those familiar with the Von--Neumann approach of sharing a bus
|
|
between data and instructions will not be surprised by this assessment.
|
|
|
|
This could be fixed in one of three ways: the instruction set
|
This could be fixed in one of three ways: the instruction set
|
architecture could be modified to handle Very Long Instruction Words
|
architecture could be modified to handle Very Long Instruction Words
|
(VLIW) so that each 32--bit word would encode two or more instructions,
|
(VLIW) so that each 32--bit word would encode two or more instructions,
|
the instruction fetch bus width could be increased from 32--bits to
|
the instruction fetch bus width could be increased from 32--bits to
|
| Line 2144... |
Line 2541... |
|
|
This may also be written off as a ``feature'' of the Zip CPU, since
|
This may also be written off as a ``feature'' of the Zip CPU, since
|
the addition of a data cache can greatly increase the LUT count of
|
the addition of a data cache can greatly increase the LUT count of
|
a soft core.
|
a soft core.
|
|
|
|
The Zip CPU compensates for this via its pipelined load and store
|
|
instructions.
|
|
|
\item Many other instruction sets offer three operand instructions, whereas
|
\item Many other instruction sets offer three operand instructions, whereas
|
the Zip CPU only offers two operand instructions. This means that it
|
the Zip CPU only offers two operand instructions. This means that it
|
takes the Zip CPU more instructions to do many of the same operations.
|
takes the Zip CPU more instructions to do many of the same operations.
|
The good part of this is that it gives the Zip CPU a greater amount of
|
The good part of this is that it gives the Zip CPU a greater amount of
|
flexibility in its immediate operand mode, although that increased
|
flexibility in its immediate operand mode, although that increased
|
| Line 2369... |
Line 2769... |
|
|
% Appendices
|
% Appendices
|
% Index
|
% Index
|
\end{document}
|
\end{document}
|
|
|
|
%
|
|
%
|
|
% Symbol table relocation types:
|
|
%
|
|
% Only 3-types of instructions truly need relocations: those that modify the
|
|
% PC register, and those that access memory.
|
|
%
|
|
% - LDI Addr,Rx // Load's an absolute address into Rx, 24 bits
|
|
%
|
|
% - LDILO Addr,Rx // Load's an absolute address into Rx, 32 bits
|
|
% LDIHI Addr,Rx // requires two instructions
|
|
%
|
|
% - JMP Rx // Jump to any address in Rx
|
|
% // Can be prefixed with two instructions to load Rx
|
|
% // from any 32-bit immediate
|
|
% - JMP #Addr // Jump to any 24'bit (signed) address, 23'b uns
|
|
%
|
|
% - ADD x,PC // Any PC relative jump (20 bits)
|
|
%
|
|
% - ADD.C x,PC // Any PC relative conditional jump (20 bits)
|
|
%
|
|
% - LDIHI Addr,Rx // Load from any 32-bit address, clobbers Rx,
|
|
% LOD Addr(Rx),Rx // unconditional, requires second instruction
|
|
%
|
|
% - LOD.C Addr(Ry),Rx // Any 16-bit relative address load, poss. cond
|
|
%
|
|
% - STO.C Rx,Addr(Ry) // Any 16-bit rel addr, Rx and Ry must be valid
|
|
%
|
|
% - FARJMP #Addr: // Arbitrary 32-bit jumps require a jump table
|
|
% BRA +1 // memory address. The BRA +1 can be skipped,
|
|
% .WORD Addr // but only if the address is placed at the end
|
|
% LOD -2(PC),PC // of an executable section
|
|
%
|
|
|
No newline at end of file
|
No newline at end of file
|
