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

Subversion Repositories zipcpu

[/] [zipcpu/] [trunk/] [doc/] [src/] [spec.tex] - Blame information for rev 69

Go to most recent revision | Details | Compare with Previous | View Log

Line No. Rev Author Line
1 21 dgisselq
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
2
%%
3
%% Filename:    spec.tex
4
%%
5
%% Project:     Zip CPU -- a small, lightweight, RISC CPU soft core
6
%%
7
%% Purpose:     This LaTeX file contains all of the documentation/description
8 33 dgisselq
%%              currently provided with this Zip CPU soft core.  It supersedes
9 21 dgisselq
%%              any information about the instruction set or CPUs found
10
%%              elsewhere.  It's not nearly as interesting, though, as the PDF
11
%%              file it creates, so I'd recommend reading that before diving
12
%%              into this file.  You should be able to find the PDF file in
13
%%              the SVN distribution together with this PDF file and a copy of
14
%%              the GPL-3.0 license this file is distributed under.  If not,
15
%%              just type 'make' in the doc directory and it (should) build
16
%%              without a problem.
17
%%
18
%%
19
%% Creator:     Dan Gisselquist
20
%%              Gisselquist Technology, LLC
21
%%
22
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
23
%%
24
%% Copyright (C) 2015, Gisselquist Technology, LLC
25
%%
26
%% This program is free software (firmware): you can redistribute it and/or
27
%% modify it under the terms of  the GNU General Public License as published
28
%% by the Free Software Foundation, either version 3 of the License, or (at
29
%% your option) any later version.
30
%%
31
%% This program is distributed in the hope that it will be useful, but WITHOUT
32
%% ANY WARRANTY; without even the implied warranty of MERCHANTIBILITY or
33
%% FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
34
%% for more details.
35
%%
36
%% You should have received a copy of the GNU General Public License along
37
%% with this program.  (It's in the $(ROOT)/doc directory, run make with no
38
%% target there if the PDF file isn't present.)  If not, see
39
%% <http://www.gnu.org/licenses/> for a copy.
40
%%
41
%% License:     GPL, v3, as defined and found on www.gnu.org,
42
%%              http://www.gnu.org/licenses/gpl.html
43
%%
44
%%
45
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
46
\documentclass{gqtekspec}
47 68 dgisselq
\usepackage{import}
48 69 dgisselq
\usepackage{bytefield}
49 68 dgisselq
% \graphicspath{{../gfx}}
50 21 dgisselq
\project{Zip CPU}
51
\title{Specification}
52
\author{Dan Gisselquist, Ph.D.}
53
\email{dgisselq (at) opencores.org}
54 69 dgisselq
\revision{Rev.~0.7}
55
\definecolor{webred}{rgb}{0.5,0,0}
56
\definecolor{webgreen}{rgb}{0,0.4,0}
57 36 dgisselq
\usepackage[dvips,ps2pdf,colorlinks=true,
58 69 dgisselq
        anchorcolor=black,pdfpagelabels,hypertexnames,
59 36 dgisselq
        pdfauthor={Dan Gisselquist},
60
        pdfsubject={Zip CPU}]{hyperref}
61 69 dgisselq
\hypersetup{
62
        colorlinks = true,
63
        linkcolor  = webred,
64
        citecolor  = webgreen
65
}
66 21 dgisselq
\begin{document}
67
\pagestyle{gqtekspecplain}
68
\titlepage
69
\begin{license}
70
Copyright (C) \theyear\today, Gisselquist Technology, LLC
71
 
72
This project is free software (firmware): you can redistribute it and/or
73
modify it under the terms of  the GNU General Public License as published
74
by the Free Software Foundation, either version 3 of the License, or (at
75
your option) any later version.
76
 
77
This program is distributed in the hope that it will be useful, but WITHOUT
78
ANY WARRANTY; without even the implied warranty of MERCHANTIBILITY or
79
FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
80
for more details.
81
 
82
You should have received a copy of the GNU General Public License along
83
with this program.  If not, see \hbox{<http://www.gnu.org/licenses/>} for a
84
copy.
85
\end{license}
86
\begin{revisionhistory}
87 69 dgisselq
0.7 & 12/22/2015 & Gisselquist & New Instruction Set Architecture \\\hline
88 68 dgisselq
0.6 & 11/17/2015 & Gisselquist & Added graphics to illustrate pipeline discussion.\\\hline
89 39 dgisselq
0.5 & 9/29/2015 & Gisselquist & Added pipelined memory access discussion.\\\hline
90 36 dgisselq
0.4 & 9/19/2015 & Gisselquist & Added DMA controller, improved stall information, and self--assessment info.\\\hline
91 33 dgisselq
0.3 & 8/22/2015 & Gisselquist & First completed draft\\\hline
92 24 dgisselq
0.2 & 8/19/2015 & Gisselquist & Still Draft, more complete \\\hline
93 21 dgisselq
0.1 & 8/17/2015 & Gisselquist & Incomplete First Draft \\\hline
94
\end{revisionhistory}
95
% Revision History
96
% Table of Contents, named Contents
97
\tableofcontents
98 24 dgisselq
\listoffigures
99 21 dgisselq
\listoftables
100
\begin{preface}
101
Many people have asked me why I am building the Zip CPU. ARM processors are
102
good and effective. Xilinx makes and markets Microblaze, Altera Nios, and both
103
have better toolsets than the Zip CPU will ever have. OpenRISC is also
104 24 dgisselq
available, RISC--V may be replacing it. Why build a new processor?
105 21 dgisselq
 
106
The easiest, most obvious answer is the simple one: Because I can.
107
 
108
There's more to it, though. There's a lot that I would like to do with a
109
processor, and I want to be able to do it in a vendor independent fashion.
110 36 dgisselq
First, I would like to be able to place this processor inside an FPGA.  Without
111
paying royalties, ARM is out of the question.  I would then like to be able to
112
generate Verilog code, both for the processor and the system it sits within,
113
that can run equivalently on both Xilinx and Altera chips, and that can be
114
easily ported from one manufacturer's chipsets to another. Even more, before
115
purchasing a chip or a board, I would like to know that my soft core works. I
116
would like to build a test bench to test components with, and Verilator is my
117
chosen test bench. This forces me to use all Verilog, and it prevents me from
118
using any proprietary cores. For this reason, Microblaze and Nios are out of
119
the question.
120 21 dgisselq
 
121
Why not OpenRISC? That's a hard question. The OpenRISC team has done some
122
wonderful work on an amazing processor, and I'll have to admit that I am
123
envious of what they've accomplished. I would like to port binutils to the
124
Zip CPU, as I would like to port GCC and GDB. They are way ahead of me. The
125
OpenRISC processor, however, is complex and hefty at about 4,500 LUTs. It has
126
a lot of features of modern CPUs within it that ... well, let's just say it's
127
not the little guy on the block. The Zip CPU is lighter weight, costing only
128 32 dgisselq
about 2,300 LUTs with no peripherals, and 3,200 LUTs with some very basic
129 21 dgisselq
peripherals.
130
 
131
My final reason is that I'm building the Zip CPU as a learning experience. The
132
Zip CPU has allowed me to learn a lot about how CPUs work on a very micro
133
level. For the first time, I am beginning to understand many of the Computer
134
Architecture lessons from years ago.
135
 
136
To summarize: Because I can, because it is open source, because it is light
137
weight, and as an exercise in learning.
138
 
139
\end{preface}
140
 
141
\chapter{Introduction}
142
\pagenumbering{arabic}
143
\setcounter{page}{1}
144
 
145
 
146 36 dgisselq
The original goal of the Zip CPU was to be a very simple CPU.   You might
147 21 dgisselq
think of it as a poor man's alternative to the OpenRISC architecture.
148
For this reason, all instructions have been designed to be as simple as
149 69 dgisselq
possible, and the base instructions are all designed to be executed in one
150
instruction cycle per instruction, barring pipeline stalls.  Indeed, even the
151
bus has been simplified to a constant 32-bit width, with no option for more
152
or less.  This has resulted in the choice to drop push and pop instructions,
153
pre-increment and post-decrement addressing modes, and more.
154 21 dgisselq
 
155
For those who like buzz words, the Zip CPU is:
156
\begin{itemize}
157
\item A 32-bit CPU: All registers are 32-bits, addresses are 32-bits,
158
                instructions are 32-bits wide, etc.
159 24 dgisselq
\item A RISC CPU.  There is no microcode for executing instructions.  All
160
        instructions are designed to be completed in one clock cycle.
161 21 dgisselq
\item A Load/Store architecture.  (Only load and store instructions
162
                can access memory.)
163
\item Wishbone compliant.  All peripherals are accessed just like
164
                memory across this bus.
165
\item A Von-Neumann architecture.  (The instructions and data share a
166
                common bus.)
167
\item A pipelined architecture, having stages for {\bf Prefetch},
168 69 dgisselq
                {\bf Decode}, {\bf Read-Operand}, a
169
                combined stage containing the {\bf ALU},
170
                {\bf Memory}, {\bf Divide}, and {\bf Floating Point}
171
                units, and then the final {\bf Write-back} stage.
172
                See Fig.~\ref{fig:cpu}
173 24 dgisselq
\begin{figure}\begin{center}
174
\includegraphics[width=3.5in]{../gfx/cpu.eps}
175
\caption{Zip CPU internal pipeline architecture}\label{fig:cpu}
176
\end{center}\end{figure}
177
                for a diagram of this structure.
178 21 dgisselq
\item Completely open source, licensed under the GPL.\footnote{Should you
179
        need a copy of the Zip CPU licensed under other terms, please
180
        contact me.}
181
\end{itemize}
182
 
183 68 dgisselq
The Zip CPU also has one very unique feature: the ability to do pipelined loads
184
and stores.  This allows the CPU to access on-chip memory at one access per
185
clock, minus a stall for the initial access.
186
 
187
\section{Characteristics of a SwiC}
188
 
189
Here, we shall define a soft core internal to an FPGA as a ``System within a
190
Chip,'' or a SwiC.  SwiCs have some very unique properties internal to them
191
that have influenced the design of the Zip CPU.  Among these are the bus,
192
memory, and available peripherals.
193
 
194
Most other approaches to soft core CPU's employ a Harvard architecture.
195
This allows these other CPU's to have two separate bus structures: one for the
196 69 dgisselq
program fetch, and the other for the memory.  The Zip CPU is fairly unique in
197 68 dgisselq
its approach because it uses a von Neumann architecture.  This was done for
198
simplicity.  By using a von Neumann architecture, only one bus needs to be
199
implemented within any FPGA.  This helps to minimize real-estate, while
200
maintaining a high clock speed.  The disadvantage is that it can severely
201
degrade the overall instructions per clock count.
202
 
203
Soft core's within an FPGA have an additional characteristic regarding
204 69 dgisselq
memory access: it is slow.  While memory on chip may be accessed at a single
205
cycle per access, small FPGA's often have only a limited amount of memory on
206
chip.  Going off chip, however, is expensive.  Two examples will prove this
207
point.  On
208 68 dgisselq
the XuLA2 board, Flash can be accessed at 128~cycles per 32--bit word,
209
or 64~cycles per subsequent word in a pipelined architecture.  Likewise, the
210 69 dgisselq
SDRAM chip on the XuLA2 board allows a 6~cycle access for a write, 10~cycles
211 68 dgisselq
per read, and 2~cycles for any subsequent pipelined access read or write.
212
Either way you look at it, this memory access will be slow and this doesn't
213
account for any logic delays should the bus implementation logic get
214
complicated.
215
 
216
As may be noticed from the above discussion about memory speed, a second
217
characteristic of memory is that all memory accesses may be pipelined, and
218
that pipelined memory access is faster than non--pipelined access.  Therefore,
219
a SwiC soft core should support pipelined operations, but it should also
220
allow a higher priority subsystem to get access to the bus (no starvation).
221
 
222
As a further characteristic of SwiC memory options, on-chip cache's are
223
expensive.  If you want to have a minimum of logic, cache logic may not be
224
the highest on the priority list.
225
 
226
In sum, memory is slow.  While one processor on one FPGA may be able to fill
227
its pipeline, the same processor on another FPGA may struggle to get more than
228
one instruction at a time into the pipeline.  Any SwiC must be able to deal
229
with both cases: fast and slow memories.
230
 
231
A final characteristic of SwiC's within FPGA's is the peripherals.
232
Specifically, FPGA's are highly reconfigurable.  Soft peripherals can easily
233
be created on chip to support the SwiC if necessary.  As an example, a simple
234
30-bit peripheral could easily support reversing 30-bit numbers: a read from
235
the peripheral returns it's bit--reversed address.  This is cheap within an
236 69 dgisselq
FPGA, but expensive in instructions.  Reading from another 16--bit peripheral
237
might calculate a sine function, where the 16--bit address internal to the
238
peripheral was the angle of the sine wave.
239 68 dgisselq
 
240
Indeed, anything that must be done fast within an FPGA is likely to already
241 69 dgisselq
be done--elsewhere in the fabric.  This leaves the CPU with the simple role
242
of solely handling sequential tasks that need a lot of state.
243 68 dgisselq
 
244
This means that the SwiC needs to live within a very unique environment,
245
separate and different from the traditional SoC.  That isn't to say that a
246
SwiC cannot be turned into a SoC, just that this SwiC has not been designed
247
for that purpose.
248
 
249
\section{Lessons Learned}
250
 
251 21 dgisselq
Now, however, that I've worked on the Zip CPU for a while, it is not nearly
252
as simple as I originally hoped.  Worse, I've had to adjust to create
253
capabilities that I was never expecting to need.  These include:
254
\begin{itemize}
255 33 dgisselq
\item {\bf External Debug:} Once placed upon an FPGA, some external means is
256 21 dgisselq
        still necessary to debug this CPU.  That means that there needs to be
257
        an external register that can control the CPU: reset it, halt it, step
258 24 dgisselq
        it, and tell whether it is running or not.  My chosen interface
259
        includes a second register similar to this control register.  This
260
        second register allows the external controller or debugger to examine
261 21 dgisselq
        registers internal to the CPU.
262
 
263
\item {\bf Internal Debug:} Being able to run a debugger from within
264
        a user process requires an ability to step a user process from
265
        within a debugger.  It also requires a break instruction that can
266
        be substituted for any other instruction, and substituted back.
267
        The break is actually difficult: the break instruction cannot be
268
        allowed to execute.  That way, upon a break, the debugger should
269
        be able to jump back into the user process to step the instruction
270
        that would've been at the break point initially, and then to
271
        replace the break after passing it.
272
 
273 24 dgisselq
        Incidentally, this break messes with the prefetch cache and the
274
        pipeline: if you change an instruction partially through the pipeline,
275
        the whole pipeline needs to be cleansed.  Likewise if you change
276
        an instruction in memory, you need to make sure the cache is reloaded
277
        with the new instruction.
278
 
279 69 dgisselq
\item {\bf Prefetch Cache:} My original implementation, {\tt prefetch}, had
280
        a very simple prefetch stage.  Any time the PC changed the prefetch
281
        would go and fetch the new instruction.  While this was perhaps this
282
        simplest approach, it cost roughly five clocks for every instruction.
283
        This was deemed unacceptable, as I wanted a CPU that could execute
284
        instructions in one cycle.
285 21 dgisselq
 
286 69 dgisselq
        My second implementation, {\tt pipefetch}, attempted to make the most
287
        use of pipelined memory.  When a new CPU address was issued, it would
288
        start reading
289
        memory in a pipelined fashion, and issuing instructions as soon as they
290
        were ready.  This cache was a sliding window in memory.  This suffered
291
        from some difficult performance problems, though.  If the CPU was
292
        alternating between two diverse sections of code, both could never be
293
        in the cache at the same time--causing lots of cache misses.  Further,
294
        the extra logic to implement this window cost an extra clock cycle
295
        in the cache implementation, slowing down branches.
296 21 dgisselq
 
297 69 dgisselq
        The Zip CPU now has a third cache implementation, {\tt pfcache}.  This
298
        new implementation takes only a single cycle per access, but costs a
299
        full cache line miss on any miss.  While configurable, a full cache
300
        line miss might mean that the CPU needs to read 256~instructions from
301
        memory before it can execute the first one of them.
302
 
303 21 dgisselq
\item {\bf Operating System:} In order to support an operating system,
304
        interrupts and so forth, the CPU needs to support supervisor and
305
        user modes, as well as a means of switching between them.  For example,
306
        the user needs a means of executing a system call.  This is the
307
        purpose of the {\bf `trap'} instruction.  This instruction needs to
308
        place the CPU into supervisor mode (here equivalent to disabling
309
        interrupts), as well as handing it a parameter such as identifying
310
        which O/S function was called.
311
 
312 24 dgisselq
My initial approach to building a trap instruction was to create an external
313
peripheral which, when written to, would generate an interrupt and could
314
return the last value written to it.  In practice, this approach didn't work
315
at all: the CPU executed two instructions while waiting for the
316
trap interrupt to take place.  Since then, I've decided to keep the rest of
317
the CC register for that purpose so that a write to the CC register, with the
318
GIE bit cleared, could be used to execute a trap.  This has other problems,
319
though, primarily in the limitation of the uses of the CC register.  In
320
particular, the CC register is the best place to put CPU state information and
321
to ``announce'' special CPU features (floating point, etc).  So the trap
322
instruction still switches to interrupt mode, but the CC register is not
323
nearly as useful for telling the supervisor mode processor what trap is being
324
executed.
325 21 dgisselq
 
326
Modern timesharing systems also depend upon a {\bf Timer} interrupt
327 24 dgisselq
to handle task swapping.  For the Zip CPU, this interrupt is handled
328
external to the CPU as part of the CPU System, found in {\tt zipsystem.v}.
329
The timer module itself is found in {\tt ziptimer.v}.
330 21 dgisselq
 
331 69 dgisselq
\item {\bf Bus Errors:} My original implementation had no logic to handle
332
        what would happen if the CPU attempted to read or write a non-existent
333
        memory address.  This changed after I needed to troubleshoot a failure
334
        caused by a subroutine return to a non-existent address.
335
 
336
        My next problem bus problem was caused by a misbehaving peripheral.
337
        Whenever the CPU attempted to read from or write to this peripheral,
338
        the peripheral would take control of the wishbone bus and not return
339
        it.  For example, it might never return an {\tt ACK} to signal
340
        the end of the bus transaction.  This led to the implementation of
341
        a wishbone bus watchdog that would create a bus error if any particular
342
        bus action didn't complete in a timely fashion.
343
 
344 21 dgisselq
\item {\bf Pipeline Stalls:} My original plan was to not support pipeline
345
        stalls at all, but rather to require the compiler to properly schedule
346 24 dgisselq
        all instructions so that stalls would never be necessary.  After trying
347 21 dgisselq
        to build such an architecture, I gave up, having learned some things:
348
 
349 68 dgisselq
        First, and ideal pipeline might look something like
350
        Fig.~\ref{fig:ideal-pipeline}.
351
\begin{figure}
352
\begin{center}
353
\includegraphics[width=4in]{../gfx/fullpline.eps}
354
\caption{An Ideal Pipeline: One instruction per clock cycle}\label{fig:ideal-pipeline}
355
\end{center}\end{figure}
356
        Notice that, in this figure, all the pipeline stages are complete and
357
        full.  Every instruction takes one clock and there are no delays.
358
        However, as the discussion above pointed out, the memory associated
359
        with a SwiC may not allow single clock access.  It may be instead
360
        that you can only read every two clocks.  In that case, what shall
361
        the pipeline look like?  Should it look like
362
        Fig.~\ref{fig:waiting-pipeline},
363
\begin{figure}\begin{center}
364
\includegraphics[width=4in]{../gfx/stuttra.eps}
365
\caption{Instructions wait for each other}\label{fig:waiting-pipeline}
366
\end{center}\end{figure}
367
        where instructions are held back until the pipeline is full, or should
368
        it look like Fig.~\ref{fig:independent-pipeline},
369
\begin{figure}\begin{center}
370
\includegraphics[width=4in]{../gfx/stuttrb.eps}
371
\caption{Instructions proceed independently}\label{fig:independent-pipeline}
372
\end{center}\end{figure}
373
        where each instruction is allowed to move through the pipeline
374
        independently?  For better or worse, the Zip CPU allows instructions
375
        to move through the pipeline independently.
376 21 dgisselq
 
377 68 dgisselq
        One approach to avoiding stalls is to use a branch delay slot,
378
        such as is shown in Fig.~\ref{fig:brdelay}.
379
\begin{figure}\begin{center}
380
\includegraphics[width=4in]{../gfx/bdly.eps}
381
\caption{A typical branch delay slot approach}\label{fig:brdelay}
382
\end{center}\end{figure}
383
        In this figure, instructions
384
        {\tt BR} (a branch), {\tt BD} (a branch delay instruction),
385
        are followed by instructions after the branch: {\tt IA}, {\tt IB}, etc.
386
        Since it takes a processor a clock cycle to execute a branch, the
387
        delay slot allows the processor to do something useful in that
388
        branch.  The problem the Zip CPU has with this approach is, what
389
        happens when the pipeline looks like Fig.~\ref{fig:brbroken}?
390
\begin{figure}\begin{center}
391
\includegraphics[width=4in]{../gfx/bdbroken.eps}
392
\caption{The branch delay slot breaks with a slow memory}\label{fig:brbroken}
393
\end{center}\end{figure}
394
        In this case, the branch delay slot never gets filled in the first
395
        place, and so the pipeline squashes it before it gets executed.
396
        If not that, then what happens when handling interrupts or
397
        debug stepping: when has the CPU finished an instruction?
398
        When the {\tt BR} instruction has finished, or must {\tt BD}
399
        follow every {\tt BR}?  and, again, what if the pipeline isn't
400
        full?
401
        These thoughts killed any hopes of doing delayed branching.
402
 
403 21 dgisselq
        So I switched to a model of discrete execution: Once an instruction
404
        enters into either the ALU or memory unit, the instruction is
405
        guaranteed to complete.  If the logic recognizes a branch or a
406
        condition that would render the instruction entering into this stage
407 33 dgisselq
        possibly inappropriate (i.e. a conditional branch preceding a store
408 21 dgisselq
        instruction for example), then the pipeline stalls for one cycle
409
        until the conditional branch completes.  Then, if it generates a new
410 33 dgisselq
        PC address, the stages preceding are all wiped clean.
411 21 dgisselq
 
412 68 dgisselq
        This model, however, generated too many pipeline stalls, so the
413
        discrete execution model was modified to allow instructions to go
414
        through the ALU unit and be canceled before writeback.  This removed
415
        the stall associated with ALU instructions before untaken branches.
416
 
417
        The discrete execution model allows such things as sleeping, as
418
        outlined in Fig.~\ref{fig:sleeping}.
419
\begin{figure}\begin{center}
420
\includegraphics[width=4in]{../gfx/sleep.eps}
421
\caption{How the CPU halts when sleeping}\label{fig:sleeping}
422
\end{center}\end{figure}
423
        If the
424 24 dgisselq
        CPU is put to ``sleep,'' the ALU and memory stages stall and back up
425 21 dgisselq
        everything before them.  Likewise, anything that has entered the ALU
426
        or memory stage when the CPU is placed to sleep continues to completion.
427
        To handle this logic, each pipeline stage has three control signals:
428
        a valid signal, a stall signal, and a clock enable signal.  In
429
        general, a stage stalls if it's contents are valid and the next step
430
        is stalled.  This allows the pipeline to fill any time a later stage
431 68 dgisselq
        stalls, as illustrated in Fig.~\ref{fig:stacking}.
432
\begin{figure}\begin{center}
433
\includegraphics[width=4in]{../gfx/stacking.eps}
434
\caption{Instructions can stack up behind a stalled instruction}\label{fig:stacking}
435
\end{center}\end{figure}
436 69 dgisselq
        However, if a pipeline hazard is detected, a stage can stall in order
437
        to prevent the previous from moving forward.
438 21 dgisselq
 
439 68 dgisselq
        This approach is also different from other pipeline approaches.
440
        Instead of keeping the entire pipeline filled, each stage is treated
441 24 dgisselq
        independently.  Therefore, individual stages may move forward as long
442
        as the subsequent stage is available, regardless of whether the stage
443
        behind it is filled.
444 21 dgisselq
\end{itemize}
445
 
446
With that introduction out of the way, let's move on to the instruction
447
set.
448
 
449
\chapter{CPU Architecture}\label{chap:arch}
450
 
451 24 dgisselq
The Zip CPU supports a set of two operand instructions, where the second operand
452 21 dgisselq
(always a register) is the result.  The only exception is the store instruction,
453
where the first operand (always a register) is the source of the data to be
454
stored.
455
 
456 24 dgisselq
\section{Simplified Bus}
457
The bus architecture of the Zip CPU is that of a simplified WISHBONE bus.
458
It has been simplified in this fashion: all operations are 32--bit operations.
459 36 dgisselq
The bus is neither little endian nor big endian.  For this reason, all words
460 24 dgisselq
are 32--bits.  All instructions are also 32--bits wide.  Everything has been
461
built around the 32--bit word.
462
 
463 21 dgisselq
\section{Register Set}
464
The Zip CPU supports two sets of sixteen 32-bit registers, a supervisor
465 24 dgisselq
and a user set as shown in Fig.~\ref{fig:regset}.
466
\begin{figure}\begin{center}
467
\includegraphics[width=3.5in]{../gfx/regset.eps}
468
\caption{Zip CPU Register File}\label{fig:regset}
469
\end{center}\end{figure}
470
The supervisor set is used in interrupt mode when interrupts are disabled,
471
whereas the user set is used otherwise.  Of this register set, the Program
472
Counter (PC) is register 15, whereas the status register (SR) or condition
473
code register
474 21 dgisselq
(CC) is register 14.  By convention, the stack pointer will be register 13 and
475 24 dgisselq
noted as (SP)--although there is nothing special about this register other
476 69 dgisselq
than this convention.  Also by convention register~12 will point to a global
477
offset table, and may be abbreviated as the (GBL) register.
478 21 dgisselq
The CPU can access both register sets via move instructions from the
479
supervisor state, whereas the user state can only access the user registers.
480
 
481 36 dgisselq
The status register is special, and bears further mention.  As shown in
482
Fig.~\ref{tbl:cc-register},
483
\begin{table}\begin{center}
484
\begin{bitlist}
485 69 dgisselq
31\ldots 13 & R/W & Reserved for future uses\\\hline
486
12 & R & (Reserved for) Floating Point Exception\\\hline
487
11 & R & Division by Zero Exception\\\hline
488
10 & R & Bus-Error Flag\\\hline
489 36 dgisselq
9 & R & Trap, or user interrupt, Flag.  Cleared on return to userspace.\\\hline
490 68 dgisselq
8 & R & Illegal Instruction Flag\\\hline
491 36 dgisselq
7 & R/W & Break--Enable\\\hline
492
6 & R/W & Step\\\hline
493
5 & R/W & Global Interrupt Enable (GIE)\\\hline
494
4 & R/W & Sleep.  When GIE is also set, the CPU waits for an interrupt.\\\hline
495
3 & R/W & Overflow\\\hline
496
2 & R/W & Negative.  The sign bit was set as a result of the last ALU instruction.\\\hline
497
1 & R/W & Carry\\\hline
498
 
499
\end{bitlist}
500
\caption{Condition Code Register Bit Assignment}\label{tbl:cc-register}
501
\end{center}\end{table}
502
the lower 11~bits of the status register form
503
a set of CPU state and condition codes.  Writes to other bits of this register
504
are preserved.
505 21 dgisselq
 
506 33 dgisselq
Of the condition codes, the bottom four bits are the current flags:
507 21 dgisselq
                Zero (Z),
508
                Carry (C),
509
                Negative (N),
510
                and Overflow (V).
511 69 dgisselq
On those instructions that set the flags, these flags will be set based upon
512
the output of the instruction.  If the result is zero, the Z flag will be set.
513
If the high order bit is set, the N flag will be set.  If the instruction
514
caused a bit to fall off the end, the carry bit will be set.  Finally, if
515
the instruction causes a signed integer overflow, the V flag will be set
516
afterwards.
517 21 dgisselq
 
518 69 dgisselq
The next bit is a sleep bit.  Set this bit to one to disable instruction
519
        execution and place the CPU to sleep, or to zero to keep the pipeline
520
        running.  Setting this bit will cause the CPU to wait for an interrupt
521
        (if interrupts are enabled), or to completely halt (if interrupts are
522
        disabled).  In order to prevent users from halting the CPU, only the
523
        supervisor is allowed to both put the CPU to sleep and disable
524
        interrupts.  Any user attempt to do so will simply result in a switch
525
        to supervisor mode.
526 33 dgisselq
 
527 21 dgisselq
The sixth bit is a global interrupt enable bit (GIE).  When this
528 32 dgisselq
        sixth bit is a `1' interrupts will be enabled, else disabled.  When
529 21 dgisselq
        interrupts are disabled, the CPU will be in supervisor mode, otherwise
530
        it is in user mode.  Thus, to execute a context switch, one only
531
        need enable or disable interrupts.  (When an interrupt line goes
532
        high, interrupts will automatically be disabled, as the CPU goes
533 32 dgisselq
        and deals with its context switch.)  Special logic has been added to
534
        keep the user mode from setting the sleep register and clearing the
535
        GIE register at the same time, with clearing the GIE register taking
536
        precedence.
537 21 dgisselq
 
538 69 dgisselq
The seventh bit is a step bit.  This bit can be set from supervisor mode only.
539
        After setting this bit, should the supervisor mode process switch to
540
        user mode, it would then accomplish one instruction in user mode
541
        before returning to supervisor mode.  Then, upon return to supervisor
542
        mode, this bit will be automatically cleared.  This bit has no effect
543
        on the CPU while in supervisor mode.
544 21 dgisselq
 
545
        This functionality was added to enable a userspace debugger
546
        functionality on a user process, working through supervisor mode
547
        of course.
548
 
549
 
550 24 dgisselq
The eighth bit is a break enable bit.  This controls whether a break
551
instruction in user mode will halt the processor for an external debugger
552
(break enabled), or whether the break instruction will simply send send the
553
CPU into interrupt mode.  Encountering a break in supervisor mode will
554
halt the CPU independent of the break enable bit.  This bit can only be set
555
within supervisor mode.
556 21 dgisselq
 
557 32 dgisselq
% Should break enable be a supervisor mode bit, while the break enable bit
558
% in user mode is a break has taken place bit?
559
%
560
 
561 21 dgisselq
This functionality was added to enable an external debugger to
562
        set and manage breakpoints.
563
 
564 68 dgisselq
The ninth bit is an illegal instruction bit.  When the CPU
565 36 dgisselq
tries to execute either a non-existant instruction, or an instruction from
566 68 dgisselq
an address that produces a bus error, the CPU will (if implemented) switch
567 36 dgisselq
to supervisor mode while setting this bit.  The bit will automatically be
568
cleared upon any return to user mode.
569 21 dgisselq
 
570
The tenth bit is a trap bit.  It is set whenever the user requests a soft
571
interrupt, and cleared on any return to userspace command.  This allows the
572
supervisor, in supervisor mode, to determine whether it got to supervisor
573
mode from a trap or from an external interrupt or both.
574
 
575 69 dgisselq
\section{Instruction Format}
576
All Zip CPU instructions fit in one of the formats shown in
577
Fig.~\ref{fig:iset-format}.
578
\begin{figure}\begin{center}
579
\begin{bytefield}[endianness=big]{32}
580
\bitheader{0-31}\\
581
\begin{leftwordgroup}{Standard}\bitbox{1}{0}\bitbox{4}{DR}
582
                \bitbox[lrt]{5}{OpCode}
583
                \bitbox[lrt]{3}{Cnd}
584
                \bitbox{1}{0}
585
                \bitbox{18}{18-bit Signed Immediate} \\
586
\bitbox{1}{0}\bitbox{4}{DR}
587
                \bitbox[lrb]{5}{}
588
                \bitbox[lrb]{3}{}
589
                \bitbox{1}{1}
590
                \bitbox{4}{BR}
591
                \bitbox{14}{14-bit Signed Immediate}\end{leftwordgroup} \\
592
\begin{leftwordgroup}{MOV}\bitbox{1}{0}\bitbox{4}{DR}
593
                \bitbox[lrt]{5}{5'hf}
594
                \bitbox[lrt]{3}{Cnd}
595
                \bitbox{1}{A}
596
                \bitbox{4}{BR}
597
                \bitbox{1}{B}
598
                \bitbox{13}{13-bit Signed Immediate}\end{leftwordgroup} \\
599
\begin{leftwordgroup}{LDI}\bitbox{1}{0}\bitbox{4}{DR}
600
                \bitbox{4}{4'hb}
601
                \bitbox{23}{23-bit Signed Immediate}\end{leftwordgroup} \\
602
\begin{leftwordgroup}{NOOP}\bitbox{1}{0}\bitbox{3}{3'h7}
603
                \bitbox{1}{}
604
                \bitbox{2}{11}
605
                \bitbox{3}{xxx}
606
                \bitbox{22}{Ignored}
607
                \end{leftwordgroup} \\
608
\begin{leftwordgroup}{VLIW}\bitbox{1}{1}\bitbox[lrt]{4}{DR}
609
                \bitbox[lrt]{5}{OpCode}
610
                \bitbox[lrt]{3}{Cnd}
611
                \bitbox{1}{0}
612
                \bitbox{4}{Imm.}
613
                \bitbox{14}{---} \\
614
\bitbox{1}{1}\bitbox[lr]{4}{}
615
                \bitbox[lrb]{5}{}
616
                \bitbox[lr]{3}{}
617
                \bitbox{1}{1}
618
                \bitbox{4}{BR}
619
                \bitbox{14}{---}        \\
620
\bitbox{1}{1}\bitbox[lrb]{4}{}
621
                \bitbox{4}{4'hb}
622
                \bitbox{1}{}
623
                \bitbox[lrb]{3}{}
624
                \bitbox{5}{5'b Imm}
625
                \bitbox{14}{---}        \\
626
\bitbox{1}{1}\bitbox{9}{---}
627
                \bitbox[lrt]{3}{Cnd}
628
                \bitbox{5}{---}
629
                \bitbox[lrt]{4}{DR}
630
                \bitbox[lrt]{5}{OpCode}
631
                \bitbox{1}{0}
632
                \bitbox{4}{Imm}
633
                \\
634
\bitbox{1}{1}\bitbox{9}{---}
635
                \bitbox[lr]{3}{}
636
                \bitbox{5}{---}
637
                \bitbox[lr]{4}{}
638
                \bitbox[lrb]{5}{}
639
                \bitbox{1}{1}
640
                \bitbox{4}{Reg} \\
641
\bitbox{1}{1}\bitbox{9}{---}
642
                \bitbox[lrb]{3}{}
643
                \bitbox{5}{---}
644
                \bitbox[lrb]{4}{}
645
                \bitbox{4}{4'hb}
646
                \bitbox{1}{}
647
                \bitbox{5}{5'b Imm}
648
                \end{leftwordgroup} \\
649
\end{bytefield}
650
\caption{Zip Instruction Set Format}\label{fig:iset-format}
651
\end{center}\end{figure}
652
The basic format is that some operation, defined by the OpCode, is applied
653
if a condition, Cnd, is true in order to produce a result which is placed in
654
the destination register, or DR.  The Load 23--bit signed immediate instruction
655
is different in that it requires no conditions, and uses only a 4-bit opcode.
656
 
657
This is actually a second version of instruction set definition, given certain
658
lessons learned.  For example, the original instruction set had the following
659
problems:
660
\begin{enumerate}
661
\item No opcodes were available for divide or floating point extensions to be
662
        made available.  Although there was space in the instruction set to
663
        add these types of instructions, this instruction space was going to
664
        require extra logic to use.
665
\item The carveouts for instructions such as NOOP and LDIHI/LDILO required
666
        extra logic to process.
667
\item The instruction set wasn't very compact.  One bus operation was required
668
        for every instruction.
669
\end{enumerate}
670
This second version was designed with two criteria.  The first was that the
671
new instruction set needed to be compatible, at the assembly language level,
672
with the previous instruction set.  Thus, it must be able to support all of
673
the previous menumonics and more.  This was achieved with the sole exception
674
that instruction immediates are generally two bits shorter than before.
675
(One bit was lost to the VLIW bit in front, another from changing from 4--bit
676
to 5--bit opcodes.)  Second, the new instruction set needed to be a drop--in
677
replacement for the decoder, modifying nothing else.  This was almost achieved,
678
save for two issues: the ALU unit needed to be replaced since the OpCodes
679
were reordered, and some condition code logic needed to be adjusted since the
680
condition codes were renumbered as well.  In the end, maximum reuse of the
681
existing RTL (Verilog) code was achieved in this upgrade.
682
 
683
As of this second version of the Zip CPU instruction set, the Zip CPU also
684
supports a very long instruction word (VLIW) set of instructions.   These
685
instruction formats pack two instructions into a single instuction word,
686
trading immediate instruction space to do this, but in just about all other
687
respects these are identical to two standard instructions.  Other than
688
instruction format, the only basic difference is that the CPU will not switch
689
to interrupt mode in between the two instructions.  Likewise a new job given
690
to the assembler is that of automatically packing as many instructions as
691
possible into the VLIW format.  Where necessary to place both VLIW instructions
692
on the same line, they will be separated by a vertical bar.
693
 
694
\section{Instruction OpCodes}
695
With a 5--bit opcode field, there are 32--possible instructions as shown in
696
Tbl.~\ref{tbl:iset-opcodes}.
697
\begin{table}\begin{center}
698
\begin{tabular}{|l|l|l|c|} \hline \rowcolor[gray]{0.85}
699
OpCode & & Instruction &Sets CC \\\hline\hline
700
5'h00 & SUB & Subtract &   \\\cline{1-3}
701
5'h01 & AND & Bitwise And &   \\\cline{1-3}
702
5'h02 & ADD & Add two numbers &   \\\cline{1-3}
703
5'h03 & OR  & Bitwise Or & Y \\\cline{1-3}
704
5'h04 & XOR & Bitwise Exclusive Or &   \\\cline{1-3}
705
5'h05 & LSR & Logical Shift Right &   \\\cline{1-3}
706
5'h06 & LSL & Logical Shift Left &   \\\cline{1-3}
707
5'h07 & ASR & Arithmetic Shift Right &   \\\hline
708
5'h08 & LDIHI & Load Immediate High & N \\\cline{1-3}
709
5'h09 & LDILO & Load Immediate Low &  \\\hline
710
5'h0a & MPYU & Unsigned 16--bit Multiply &  \\\cline{1-3}
711
5'h0b & MPYS & Signed 16--bit Multiply & Y \\\cline{1-3}
712
5'h0c & BREV & Bit Reverse &  \\\cline{1-3}
713
5'h0d & POPC& Population Count &  \\\cline{1-3}
714
5'h0e & ROL & Rotate left &   \\\hline
715
5'h0f & MOV & Move register & N \\\hline
716
5'h10 & CMP & Compare & Y \\\cline{1-3}
717
5'h11 & TST & Test (AND w/o setting result) &   \\\hline
718
5'h12 & LOD & Load from memory & N \\\cline{1-3}
719
5'h13 & STO & Store a register into memory &  \\\hline\hline
720
5'h14 & DIVU & Divide, unsigned & Y \\\cline{1-3}
721
5'h15 & DIVS & Divide, signed &  \\\hline\hline
722
5'h16/7 & LDI & Load 23--bit signed immediate & N \\\hline\hline
723
5'h18 & FPADD & Floating point add &  \\\cline{1-3}
724
5'h19 & FPSUB & Floating point subtract &   \\\cline{1-3}
725
5'h1a & FPMPY & Floating point multiply & Y \\\cline{1-3}
726
5'h1b & FPDIV & Floating point divide &   \\\cline{1-3}
727
5'h1c & FPCVT & Convert integer to floating point &   \\\cline{1-3}
728
5'h1d & FPINT & Convert to integer &   \\\hline
729
5'h1e & & {\em Reserved for future use} &\\\hline
730
5'h1f & & {\em Reserved for future use} &\\\hline
731 39 dgisselq
\end{tabular}
732 69 dgisselq
\caption{Zip CPU OpCodes}\label{tbl:iset-opcodes}
733 39 dgisselq
\end{center}\end{table}
734 69 dgisselq
%
735
Of these opcodes, the {\tt BREV} and {\tt POPC} are experimental, and may be
736
replaced later, and two floating point instruction opcodes are reserved for
737
future use.
738 39 dgisselq
 
739 21 dgisselq
\section{Conditional Instructions}
740 69 dgisselq
Most, although not quite all, instructions may be conditionally executed.
741
The 23--bit load immediate instruction, together with the {\tt NOOP},
742
{\tt BREAK}, and {\tt LOCK} instructions are the only exception to this rule.
743
 
744
From the four condition code flags, eight conditions are defined for standard
745
instructions.  These are shown in Tbl.~\ref{tbl:conditions}.
746
\begin{table}\begin{center}
747 21 dgisselq
\begin{tabular}{l|l|l}
748
Code & Mneumonic & Condition \\\hline
749
3'h0 & None & Always execute the instruction \\
750 69 dgisselq
3'h1 & {\tt .LT} & Less than ('N' set) \\
751
3'h2 & {\tt .Z} & Only execute when 'Z' is set \\
752
3'h3 & {\tt .NZ} & Only execute when 'Z' is not set \\
753 21 dgisselq
3'h4 & {\tt .GT} & Greater than ('N' not set, 'Z' not set) \\
754 69 dgisselq
3'h5 & {\tt .GE} & Greater than or equal ('N' not set, 'Z' irrelevant) \\
755 21 dgisselq
3'h6 & {\tt .C} & Carry set\\
756
3'h7 & {\tt .V} & Overflow set\\
757
\end{tabular}
758
\caption{Conditions for conditional operand execution}\label{tbl:conditions}
759 69 dgisselq
\end{center}\end{table}
760
There is no condition code for less than or equal, not C or not V---there
761
just wasn't enough space in 3--bits.  Conditioning on a non--supported
762
condition is still possible, but it will take an extra instruction and a
763
pipeline stall.  (Ex: \hbox{\em (Stall)}; \hbox{\tt TST \$4,CC;} \hbox{\tt
764
STO.NZ R0,(R1)}) As an alternative, it is often possible to reverse the
765
condition, and thus recovering those extra two clocks.  Thus instead of
766
\hbox{\tt CMP Rx,Ry;} \hbox{\tt BNV label} you can issue a
767
\hbox{\tt CMP Ry,Rx;} \hbox{\tt BV label}.
768 21 dgisselq
 
769 69 dgisselq
Conditionally executed instructions will not further adjust the
770 68 dgisselq
condition codes, with the exception of \hbox{\tt CMP} and \hbox{\tt TST}
771
instructions.   Conditional \hbox{\tt CMP} or \hbox{\tt TST} instructions
772 69 dgisselq
will adjust conditions whenever they are executed.  In this way,
773 68 dgisselq
multiple conditions may be evaluated without branches.  For example, to do
774
something if \hbox{\tt R0} is one and \hbox{\tt R1} is two, one might try
775
code such as Tbl.~\ref{tbl:dbl-condition}.
776
\begin{table}\begin{center}
777
\begin{tabular}{l}
778
        {\tt CMP 1,R0} \\
779
        {;\em Condition codes are now set based upon R0-1} \\
780
        {\tt CMP.Z 2,R1} \\
781
        {;\em If R0 $\neq$ 1, conditions are unchanged.} \\
782
        {;\em If R0 $=$ 1, conditions are set based upon R1-2.} \\
783
        {;\em Now do something based upon the conjunction of both conditions.} \\
784
        {;\em While we use the example of a STO, it could be any instruction.} \\
785
        {\tt STO.Z R0,(R2)} \\
786
\end{tabular}
787
\caption{An example of a double conditional}\label{tbl:dbl-condition}
788
\end{center}\end{table}
789 36 dgisselq
 
790 69 dgisselq
In the case of VLIW instructions, only four conditions are defined as shown
791
in Tbl.~\ref{tbl:vliw-conditions}.
792
\begin{table}\begin{center}
793
\begin{tabular}{l|l|l}
794
Code & Mneumonic & Condition \\\hline
795
2'h0 & None & Always execute the instruction \\
796
2'h1 & {\tt .LT} & Less than ('N' set) \\
797
2'h2 & {\tt .Z} & Only execute when 'Z' is set \\
798
2'h3 & {\tt .NZ} & Only execute when 'Z' is not set \\
799
\end{tabular}
800
\caption{VLIW Conditions}\label{tbl:vliw-conditions}
801
\end{center}\end{table}
802
Further, the first bit is given a special meaning.  If the first bit is set,
803
the conditions apply to the second half of the instruction, otherwise the
804
conditions will only apply to the first half of a conditional instruction.
805 68 dgisselq
 
806 21 dgisselq
\section{Operand B}
807 69 dgisselq
Many instruction forms have a 19-bit source ``Operand B'' associated with them.
808
This ``Operand B'' is shown in Fig.~\ref{fig:iset-format} as part of the
809
standard instructions.  This Operand B is either equal to a register plus a
810
14--bit signed immediate offset, or an 18--bit signed immediate offset by
811
itself.  This value is encoded as shown in Tbl.~\ref{tbl:opb}.
812 21 dgisselq
\begin{table}\begin{center}
813 69 dgisselq
\begin{bytefield}[endianness=big]{19}
814
\bitheader{0-18}  \\
815
\bitbox{1}{0}\bitbox{18}{18-bit Signed Immediate} \\
816
\bitbox{1}{1}\bitbox{4}{Reg}\bitbox{14}{14-bit Signed Immediate}
817
\end{bytefield}
818 21 dgisselq
\caption{Bit allocation for Operand B}\label{tbl:opb}
819
\end{center}\end{table}
820 24 dgisselq
 
821 69 dgisselq
Fourteen and eighteen bit immediate values don't make sense for all
822
instructions.  For example, what is the point of an 18--bit immediate when
823
executing a 16--bit multiply?  Or a 16--bit load--immediate?  In these cases,
824
the extra bits are simply ignored.
825 24 dgisselq
 
826 69 dgisselq
VLIW instructions still use the same operand B, only there was no room for any
827
instruction plus immediate addressing.  Therefore, VLIW instructions have either
828
a register or a 4--bit signed immediate as their operand B.  The only exception
829
is the load immediate instruction, which permits a 5--bit signed operand
830
B.\footnote{Although the space exists to extend this VLIW load immediate
831
instruction to six bits, the 5--bit limit was chosen to simplify the
832
disassembler.  This may change in the future.}
833
 
834 21 dgisselq
\section{Address Modes}
835 36 dgisselq
The Zip CPU supports two addressing modes: register plus immediate, and
836 21 dgisselq
immediate address.  Addresses are therefore encoded in the same fashion as
837 69 dgisselq
Operand B's, shown above.  Practically, the VLIW instruction set only offers
838
register addressing, necessitating a non--VLIW instruction for most memory
839
operations.
840 21 dgisselq
 
841
A lot of long hard thought was put into whether to allow pre/post increment
842
and decrement addressing modes.  Finding no way to use these operators without
843 32 dgisselq
taking two or more clocks per instruction,\footnote{The two clocks figure
844
comes from the design of the register set, allowing only one write per clock.
845
That write is either from the memory unit or the ALU, but never both.} these
846
addressing modes have been
847 21 dgisselq
removed from the realm of possibilities.  This means that the Zip CPU has no
848
native way of executing push, pop, return, or jump to subroutine operations.
849 24 dgisselq
Each of these instructions can be emulated with a set of instructions from the
850
existing set.
851 21 dgisselq
 
852
\section{Move Operands}
853
The previous set of operands would be perfect and complete, save only that
854 24 dgisselq
the CPU needs access to non--supervisory registers while in supervisory mode.
855
Therefore, the MOV instruction is special and offers access to these registers
856
\ldots when in supervisory mode.  To keep the compiler simple, the extra bits
857
are ignored in non-supervisory mode (as though they didn't exist), rather than
858
being mapped to new instructions or additional capabilities.  The bits
859 69 dgisselq
indicating which register set each register lies within are the A-User, marked
860
`A' in Fig.~\ref{fig:iset-format}, and B-User bits, marked as `B'.  When set
861
to a one, these refer to a user mode register.  When set to a zero, these
862
refer to a register in the current mode, whether user or supervisor.  Further,
863
because a load immediate instruction exists, there is no move capability
864
between an immediate and a register: all moves come from either a register or
865
a register plus an offset.
866 21 dgisselq
 
867 69 dgisselq
This actually leads to a bit of a problem: since the {\tt MOV} instruction
868
encodes which register set each register is coming from or moving to, how shall
869
a compiler or assembler know how to compile a MOV instruction without knowing
870 24 dgisselq
the mode of the CPU at the time?  For this reason, the compiler will assume
871
all MOV registers are supervisor registers, and display them as normal.
872 69 dgisselq
Anything with the user bit set will be treated as a user register and displayed
873
special.  Since the CPU quietly ignores the supervisor bits while in user mode,
874
anything marked as a user register will always be specific.
875 21 dgisselq
 
876
\section{Multiply Operations}
877 36 dgisselq
The Zip CPU supports two Multiply operations, a 16x16 bit signed multiply
878 69 dgisselq
({\tt MPYS}) and a 16x16 bit unsigned multiply ({\tt MPYU}).  A 32--bit
879
multiply, should it be desired, needs to be created via software from this
880
16x16 bit multiply.
881 21 dgisselq
 
882 69 dgisselq
\section{Divide Unit}
883
The Zip CPU also has a divide unit which can be built alongside the ALU.
884
This divide unit provides the Zip CPU with its first two instructions that
885
cannot be executed in a single cycle: {\tt DIVS}, or signed divide, and
886
{\tt DIVU}, the unsigned divide.  These are both 32--bit divide instructions,
887
dividing one 32--bit number by another.  In this case, the Operand B field,
888
whether it be register or register plus immediate, constitutes the denominator,
889
whereas the numerator is given by the other register.
890 21 dgisselq
 
891 69 dgisselq
The Divide is also a multi--clock instruction.  While the divide is running,
892
the ALU, memory unit, and floating point unit (if installed) will be idle.
893
Once the divide completes, other units may continue.
894 21 dgisselq
 
895 69 dgisselq
Of course, divides can have errors: division by zero.  In the case of division
896
by zero, an exception will be caused that will send the CPU either from
897
user mode to supervisor mode, or halt the CPU if it is already in supervisor
898
mode.
899 32 dgisselq
 
900 69 dgisselq
\section{NOOP, BREAK, and Bus Lock Instruction}
901
Three instructions are not listed in the opcode list in
902
Tbl.~\ref{tbl:iset-opcodes}, yet fit in the NOOP type instruction format of
903
Fig.~\ref{fig:iset-format}.  These are the {\tt NOOP}, {\tt Break}, and
904
bus {\tt LOCK} instructions.  These are encoded according to
905
Fig.~\ref{fig:iset-noop}, and have the following meanings:
906
\begin{figure}\begin{center}
907
\begin{bytefield}[endianness=big]{32}
908
\bitheader{0-31}\\
909
\begin{leftwordgroup}{NOOP}
910
\bitbox{1}{0}\bitbox{3}{3'h7}\bitbox{1}{}
911
        \bitbox{2}{11}\bitbox{3}{001}\bitbox{22}{Ignored} \\
912
\bitbox{1}{1}\bitbox{3}{3'h7}\bitbox{1}{}
913
        \bitbox{2}{11}\bitbox{3}{001}\bitbox{22}{---} \\
914
\bitbox{1}{1}\bitbox{9}{---}\bitbox{3}{---}\bitbox{5}{---}
915
        \bitbox{3}{3'h7}\bitbox{1}{}\bitbox{2}{11}\bitbox{3}{001}
916
        \bitbox{5}{Ignored}
917
                \end{leftwordgroup} \\
918
\begin{leftwordgroup}{BREAK}
919
\bitbox{1}{0}\bitbox{3}{3'h7}
920
                \bitbox{1}{}\bitbox{2}{11}\bitbox{3}{010}\bitbox{22}{Ignored}
921
                \end{leftwordgroup} \\
922
\begin{leftwordgroup}{LOCK}
923
\bitbox{1}{0}\bitbox{3}{3'h7}
924
                \bitbox{1}{}\bitbox{2}{11}\bitbox{3}{100}\bitbox{22}{Ignored}
925
                \end{leftwordgroup} \\
926
\end{bytefield}
927
\caption{NOOP/Break/LOCK Instruction Format}\label{fig:iset-noop}
928
\end{center}\end{figure}
929 32 dgisselq
 
930 69 dgisselq
The {\tt NOOP} instruction is just that: an instruction that does not perform
931
any operation.  While many other instructions, such as a move from a register to
932
itself, could also fit these roles, only the NOOP instruction guarantees that
933
it will not stall waiting for a register to be available.   For this reason,
934
it gets its own place in the instruction set.
935 32 dgisselq
 
936 69 dgisselq
The {\tt BREAK} instruction is useful for creating a debug instruction that
937
will halt the CPU without executing.  If in user mode, depending upon the
938
setting of the break enable bit, it will either switch to supervisor mode or
939
halt the CPU--depending upon where the user wishes to do his debugging.
940 21 dgisselq
 
941 69 dgisselq
Finally, the {\tt LOCK} instruction was added in order to make a test and
942
set multi--CPU operation possible.  Following a LOCK instruction, the next
943
two instructions, if they are memory LOD/STO instructions, will execute without
944
dropping the wishbone {\tt CYC} line between the instructions.   Thus a
945
{\tt LOCK} followed by {\tt LOD (Rx),Ry} and a {\tt STO Rz,(Rx)}, where Rz
946
is initially set, can be used to set an address while guaranteeing that Ry
947
was the value before setting the address to Rz.   This is a useful instruction
948
while trying to achieve concurrency among multiple CPU's.
949 21 dgisselq
 
950 69 dgisselq
\section{Floating Point}
951
Although the Zip CPU does not (yet) have a floating point unit, the current
952
instruction set offers eight opcodes for floating point operations, and treats
953
floating point exceptions like divide by zero errors.  Once this unit is built
954
and integrated together with the rest of the CPU, the Zip CPU will support
955
32--bit floating point instructions natively.  Any 64--bit floating point
956
instructions will still need to be emulated in software.
957
 
958 21 dgisselq
\section{Derived Instructions}
959 36 dgisselq
The Zip CPU supports many other common instructions, but not all of them
960 24 dgisselq
are single cycle instructions.  The derived instruction tables,
961 36 dgisselq
Tbls.~\ref{tbl:derived-1}, \ref{tbl:derived-2}, \ref{tbl:derived-3}
962
and~\ref{tbl:derived-4},
963 21 dgisselq
help to capture some of how these other instructions may be implemented on
964 36 dgisselq
the Zip CPU.  Many of these instructions will have assembly equivalents,
965 21 dgisselq
such as the branch instructions, to facilitate working with the CPU.
966
\begin{table}\begin{center}
967
\begin{tabular}{p{1.4in}p{1.5in}p{3in}}\\\hline
968
Mapped & Actual  & Notes \\\hline
969 39 dgisselq
{\tt ABS Rx}
970
        & \parbox[t]{1.5in}{\tt TST -1,Rx\\NEG.LT Rx}
971 36 dgisselq
        & Absolute value, depends upon derived NEG.\\\hline
972 39 dgisselq
\parbox[t]{1.4in}{\tt ADD Ra,Rx\\ADDC Rb,Ry}
973
        & \parbox[t]{1.5in}{\tt Add Ra,Rx\\ADD.C \$1,Ry\\Add Rb,Ry}
974 21 dgisselq
        & Add with carry \\\hline
975 39 dgisselq
{\tt BRA.Cond +/-\$Addr}
976
        & \hbox{\tt MOV.cond \$Addr+PC,PC}
977 69 dgisselq
        & Branch or jump on condition.  Works for 13--bit
978 24 dgisselq
                signed address offsets.\\\hline
979 39 dgisselq
{\tt BRA.Cond +/-\$Addr}
980
        & \parbox[t]{1.5in}{\tt LDI \$Addr,Rx \\ ADD.cond Rx,PC}
981 21 dgisselq
        & Branch/jump on condition.  Works for
982
        23 bit address offsets, but costs a register, an extra instruction,
983 33 dgisselq
        and sets the flags. \\\hline
984 39 dgisselq
{\tt BNC PC+\$Addr}
985
        & \parbox[t]{1.5in}{\tt Test \$Carry,CC \\ MOV.Z PC+\$Addr,PC}
986 21 dgisselq
        & Example of a branch on an unsupported
987
                condition, in this case a branch on not carry \\\hline
988 39 dgisselq
{\tt BUSY } & {\tt MOV \$-1(PC),PC} & Execute an infinite loop \\\hline
989
{\tt CLRF.NZ Rx }
990
        & {\tt XOR.NZ Rx,Rx}
991 21 dgisselq
        & Clear Rx, and flags, if the Z-bit is not set \\\hline
992 39 dgisselq
{\tt CLR Rx }
993
        & {\tt LDI \$0,Rx}
994 21 dgisselq
        & Clears Rx, leaves flags untouched.  This instruction cannot be
995
                conditional. \\\hline
996 39 dgisselq
{\tt EXCH.W Rx }
997
        & {\tt ROL \$16,Rx}
998 21 dgisselq
        & Exchanges the top and bottom 16'bit words of Rx \\\hline
999 39 dgisselq
{\tt HALT }
1000
        & {\tt Or \$SLEEP,CC}
1001
        & This only works when issued in interrupt/supervisor mode.  In user
1002
        mode this is simply a wait until interrupt instruction. \\\hline
1003 69 dgisselq
{\tt INT } & {\tt LDI \$0,CC} & This is also known as a trap instruction\\\hline
1004 39 dgisselq
{\tt IRET}
1005
        & {\tt OR \$GIE,CC}
1006
        & Also known as an RTU instruction (Return to Userspace) \\\hline
1007
{\tt JMP R6+\$Addr}
1008
        & {\tt MOV \$Addr(R6),PC}
1009 21 dgisselq
        & \\\hline
1010 69 dgisselq
{\tt LJMP \$Addr}
1011
        & \parbox[t]{1.5in}{\tt LOD (PC),PC \\ {\em Address }}
1012
        & Although this only works for an unconditional jump, and it only
1013
        works in a Von Neumann architecture, this instruction combination makes
1014
        for a nice combination that can be adjusted by a linker at a later
1015
        time.\\\hline
1016 39 dgisselq
{\tt JSR PC+\$Addr  }
1017 69 dgisselq
        & \parbox[t]{1.5in}{\tt MOV \$1+PC,R0 \\ MOV \$addr+PC,PC}
1018
        & This is similar to the jump and link instructions from other
1019
        architectures, save only that it requires a specific link
1020
        instruction, also known as the {\tt MOV} instruction on the
1021
        left.\\\hline
1022
\end{tabular}
1023
\caption{Derived Instructions}\label{tbl:derived-1}
1024
\end{center}\end{table}
1025
\begin{table}\begin{center}
1026
\begin{tabular}{p{1.4in}p{1.5in}p{3in}}\\\hline
1027
Mapped & Actual  & Notes \\\hline
1028 39 dgisselq
{\tt LDI.l \$val,Rx }
1029
        & \parbox[t]{1.8in}{\tt LDIHI (\$val$>>$16)\&0x0ffff, Rx \\
1030
                        LDILO (\$val\&0x0ffff),Rx}
1031 69 dgisselq
        & \parbox[t]{3.0in}{Sadly, there's not enough instruction
1032 21 dgisselq
                space to load a complete immediate value into any register.
1033
                Therefore, fully loading any register takes two cycles.
1034
                The LDIHI (load immediate high) and LDILO (load immediate low)
1035 69 dgisselq
                instructions have been created to facilitate this.
1036
                \\
1037
        This is also the appropriate means for setting a register value
1038
        to an arbitrary 32--bit value in a post--assembly link
1039
        operation.}\\\hline
1040 39 dgisselq
{\tt LOD.b \$addr,Rx}
1041
        & \parbox[t]{1.5in}{\tt %
1042 21 dgisselq
        LDI     \$addr,Ra \\
1043
        LDI     \$addr,Rb \\
1044
        LSR     \$2,Ra \\
1045
        AND     \$3,Rb \\
1046
        LOD     (Ra),Rx \\
1047
        LSL     \$3,Rb \\
1048
        SUB     \$32,Rb \\
1049
        ROL     Rb,Rx \\
1050
        AND \$0ffh,Rx}
1051
        & \parbox[t]{3in}{This CPU is designed for 32'bit word
1052
        length instructions.  Byte addressing is not supported by the CPU or
1053
        the bus, so it therefore takes more work to do.
1054
 
1055
        Note also that in this example, \$Addr is a byte-wise address, where
1056 24 dgisselq
        all other addresses in this document are 32-bit wordlength addresses.
1057
        For this reason,
1058 21 dgisselq
        we needed to drop the bottom two bits.  This also limits the address
1059
        space of character accesses using this method from 16 MB down to 4MB.}
1060
                \\\hline
1061 39 dgisselq
\parbox[t]{1.5in}{\tt LSL \$1,Rx\\ LSLC \$1,Ry}
1062
        & \parbox[t]{1.5in}{\tt LSL \$1,Ry \\
1063 21 dgisselq
        LSL \$1,Rx \\
1064
        OR.C \$1,Ry}
1065
        & Logical shift left with carry.  Note that the
1066
        instruction order is now backwards, to keep the conditions valid.
1067 33 dgisselq
        That is, LSL sets the carry flag, so if we did this the other way
1068 21 dgisselq
        with Rx before Ry, then the condition flag wouldn't have been right
1069
        for an OR correction at the end. \\\hline
1070 39 dgisselq
\parbox[t]{1.5in}{\tt LSR \$1,Rx \\ LSRC \$1,Ry}
1071
        & \parbox[t]{1.5in}{\tt CLR Rz \\
1072 21 dgisselq
        LSR \$1,Ry \\
1073
        LDIHI.C \$8000h,Rz \\
1074
        LSR \$1,Rx \\
1075
        OR Rz,Rx}
1076
        & Logical shift right with carry \\\hline
1077 39 dgisselq
{\tt NEG Rx} & \parbox[t]{1.5in}{\tt XOR \$-1,Rx \\ ADD \$1,Rx} & \\\hline
1078
{\tt NEG.C Rx} & \parbox[t]{1.5in}{\tt MOV.C \$-1+Rx,Rx\\XOR.C \$-1,Rx} & \\\hline
1079
{\tt NOOP} & {\tt NOOP} & While there are many
1080 21 dgisselq
        operations that do nothing, such as MOV Rx,Rx, or OR \$0,Rx, these
1081
        operations have consequences in that they might stall the bus if
1082
        Rx isn't ready yet.  For this reason, we have a dedicated NOOP
1083
        instruction. \\\hline
1084 39 dgisselq
{\tt NOT Rx } & {\tt XOR \$-1,Rx } & \\\hline
1085
{\tt POP Rx }
1086 69 dgisselq
        & \parbox[t]{1.5in}{\tt LOD \$(SP),Rx \\ ADD \$1,SP}
1087
        & \\\hline
1088 36 dgisselq
\end{tabular}
1089
\caption{Derived Instructions, continued}\label{tbl:derived-2}
1090
\end{center}\end{table}
1091
\begin{table}\begin{center}
1092
\begin{tabular}{p{1.4in}p{1.5in}p{3in}}\\\hline
1093 39 dgisselq
{\tt PUSH Rx}
1094 69 dgisselq
        & \parbox[t]{1.5in}{\hbox{\tt SUB \$1,SP}
1095
        \hbox{\tt STO Rx,\$(SP)}}
1096 39 dgisselq
        & Note that for pipelined operation, it helps to coalesce all the
1097
        {\tt SUB}'s into one command, and place the {\tt STO}'s right
1098 69 dgisselq
        after each other.  Further, to avoid a pipeline stall, the
1099
        immediate value for the store must be zero.
1100
        \\\hline
1101 39 dgisselq
{\tt PUSH Rx-Ry}
1102 69 dgisselq
        & \parbox[t]{1.5in}{\tt SUB \$$n$,SP \\
1103
        STO Rx,\$(SP)
1104 36 dgisselq
        \ldots \\
1105 69 dgisselq
        STO Ry,\$$\left(n-1\right)$(SP)}
1106 36 dgisselq
        & Multiple pushes at once only need the single subtract from the
1107
        stack pointer.  This derived instruction is analogous to a similar one
1108
        on the Motoroloa 68k architecture, although the Zip Assembler
1109 39 dgisselq
        does not support this instruction (yet).  This instruction
1110
        also supports pipelined memory access.\\\hline
1111
{\tt RESET}
1112
        & \parbox[t]{1in}{\tt STO \$1,\$watchdog(R12)\\NOOP\\NOOP}
1113
        & This depends upon the peripheral base address being
1114 69 dgisselq
        preloaded into R12.
1115 21 dgisselq
 
1116
        Another opportunity might be to jump to the reset address from within
1117 39 dgisselq
        supervisor mode.\\\hline
1118 69 dgisselq
{\tt RET} & {\tt MOV R0,PC}
1119
        & This depends upon the form of the {\tt JSR} given on the previous
1120
        page that stores the return address into R0.
1121 21 dgisselq
        \\\hline
1122 39 dgisselq
{\tt STEP Rr,Rt}
1123
        & \parbox[t]{1.5in}{\tt LSR \$1,Rr \\ XOR.C Rt,Rr}
1124 21 dgisselq
        & Step a Galois implementation of a Linear Feedback Shift Register, Rr,
1125
                using taps Rt \\\hline
1126 39 dgisselq
{\tt STO.b Rx,\$addr}
1127
        & \parbox[t]{1.5in}{\tt %
1128 21 dgisselq
        LDI \$addr,Ra \\
1129
        LDI \$addr,Rb \\
1130
        LSR \$2,Ra \\
1131
        AND \$3,Rb \\
1132
        SUB \$32,Rb \\
1133
        LOD (Ra),Ry \\
1134
        AND \$0ffh,Rx \\
1135 39 dgisselq
        AND \~\$0ffh,Ry \\
1136 21 dgisselq
        ROL Rb,Rx \\
1137
        OR Rx,Ry \\
1138
        STO Ry,(Ra) }
1139
        & \parbox[t]{3in}{This CPU and it's bus are {\em not} optimized
1140
        for byte-wise operations.
1141
 
1142
        Note that in this example, \$addr is a
1143
        byte-wise address, whereas in all of our other examples it is a
1144
        32-bit word address. This also limits the address space
1145
        of character accesses from 16 MB down to 4MB.F
1146
        Further, this instruction implies a byte ordering,
1147
        such as big or little endian.} \\\hline
1148 39 dgisselq
{\tt SWAP Rx,Ry }
1149 69 dgisselq
        & \parbox[t]{1.5in}{\tt XOR Ry,Rx \\ XOR Rx,Ry \\ XOR Ry,Rx}
1150 21 dgisselq
        & While no extra registers are needed, this example
1151
        does take 3-clocks. \\\hline
1152 69 dgisselq
\end{tabular}
1153
\caption{Derived Instructions, continued}\label{tbl:derived-3}
1154
\end{center}\end{table}
1155
\begin{table}\begin{center}
1156
\begin{tabular}{p{1.4in}p{1.5in}p{3in}}\\\hline
1157 39 dgisselq
{\tt TRAP \#X}
1158
        & \parbox[t]{1.5in}{\tt LDI \$x,R0 \\ AND \~\$GIE,CC }
1159 36 dgisselq
        & This works because whenever a user lowers the \$GIE flag, it sets
1160
        a TRAP bit within the CC register.  Therefore, upon entering the
1161
        supervisor state, the CPU only need check this bit to know that it
1162
        got there via a TRAP.  The trap could be made conditional by making
1163
        the LDI and the AND conditional.  In that case, the assembler would
1164
        quietly turn the LDI instruction into an LDILO and LDIHI pair,
1165 37 dgisselq
        but the effect would be the same. \\\hline
1166 69 dgisselq
{\tt TS Rx,Ry,(Rz)}
1167
        & \hbox{\tt LDI 1,Rx}
1168
                \hbox{\tt LOCK}
1169
                \hbox{\tt LOD (Rz),Ry}
1170
                \hbox{\tt STO Rx,(Rz)}
1171
        & A test and set instruction.  The {\tt LOCK} instruction insures
1172
        that the next two instructions lock the bus between the instructions,
1173
        so no one else can use it.  Thus guarantees that the operation is
1174
        atomic.
1175
        \\\hline
1176 39 dgisselq
{\tt TST Rx}
1177
        & {\tt TST \$-1,Rx}
1178 21 dgisselq
        & Set the condition codes based upon Rx.  Could also do a CMP \$0,Rx,
1179
        ADD \$0,Rx, SUB \$0,Rx, etc, AND \$-1,Rx, etc.  The TST and CMP
1180
        approaches won't stall future pipeline stages looking for the value
1181 69 dgisselq
        of Rx. (Future versions of the assembler may shorten this to a
1182
        {\tt TST Rx} instruction.)\\\hline
1183 39 dgisselq
{\tt WAIT}
1184
        & {\tt Or \$GIE | \$SLEEP,CC}
1185
        & Wait until the next interrupt, then jump to supervisor/interrupt
1186
        mode.
1187 21 dgisselq
\end{tabular}
1188 36 dgisselq
\caption{Derived Instructions, continued}\label{tbl:derived-4}
1189 21 dgisselq
\end{center}\end{table}
1190 69 dgisselq
 
1191
\section{Interrupt Handling}
1192
The Zip CPU does not maintain any interrupt vector tables.  If an interrupt
1193
takes place, the CPU simply switches to interrupt mode.  The supervisor code
1194
continues in this interrupt mode from where it left off before, after
1195
executing a return to userspace {\tt RTU} instruction.
1196
 
1197
At this point, the supervisor code needs to determine first whether an
1198
interrupt has occurred, and then whether it is in interrupt mode due to
1199
an exception and handle each case appropriately.
1200
 
1201 21 dgisselq
\section{Pipeline Stages}
1202 32 dgisselq
As mentioned in the introduction, and highlighted in Fig.~\ref{fig:cpu},
1203
the Zip CPU supports a five stage pipeline.
1204 21 dgisselq
\begin{enumerate}
1205 36 dgisselq
\item {\bf Prefetch}: Reads instruction from memory and into a cache, if so
1206
        configured.  This
1207 21 dgisselq
        stage is actually pipelined itself, and so it will stall if the PC
1208
        ever changes.  Stalls are also created here if the instruction isn't
1209
        in the prefetch cache.
1210 36 dgisselq
 
1211 69 dgisselq
        The Zip CPU supports one of three prefetch methods, depending upon a
1212
        flag set at build time within the {\tt cpudefs.v} file.  The simplest
1213
        is a non--cached implementation of a prefetch.  This implementation is
1214
        fairly small, and ideal for users of the Zip CPU who need the extra
1215
        space on the FPGA fabric.  However, because this non--cached version
1216
        has no cache, the maximum number of instructions per clock is limited
1217
        to about one per five.
1218 36 dgisselq
 
1219
        The second prefetch module is a pipelined prefetch with a cache.  This
1220
        module tries to keep the instruction address within a window of valid
1221
        instruction addresses.  While effective, it is not a traditional
1222
        cache implementation.  One unique feature of this cache implementation,
1223
        however, is that it can be cleared in a single clock.  A disappointing
1224
        feature, though, was that it needs an extra internal pipeline stage
1225
        to be implemented.
1226
 
1227 69 dgisselq
        The third prefetch and cache module implements a more traditional cache.
1228
        While the resulting code tends to be twice as fast as the pipelined
1229
        cache architecture, this implementation uses a large amount of
1230
        distributed FPGA RAM to be successful.  This then inflates the Zip CPU's
1231
        FPGA usage statistics.
1232
 
1233
\item {\bf Decode}: Decodes an instruction into OpCode, register(s) to read,
1234
        and immediate offset.  This stage also determines whether the flags
1235
        will be set or whether the result will be written back.
1236
 
1237 21 dgisselq
\item {\bf Read Operands}: Read registers and apply any immediate values to
1238 24 dgisselq
        them.  There is no means of detecting or flagging arithmetic overflow
1239
        or carry when adding the immediate to the operand.  This stage will
1240
        stall if any source operand is pending.
1241 69 dgisselq
 
1242
\item Split into one of four tracks: An {\bf ALU} track which will accomplish
1243
        a simple instruction, the {\bf MemOps} stage which handles {\tt LOD}
1244
        (load) and {\tt STO} (store) instructions, the {\bf divide} unit,
1245
        and the {\bf floating point} unit.
1246 21 dgisselq
        \begin{itemize}
1247 69 dgisselq
        \item Loads will stall instructions in the decode stage until the
1248
                entire pipeline until complete, lest a register be read in
1249
                the read operands stage only to be updated unseen by the
1250
                Load.
1251
        \item Condition codes are available upon completion of the ALU,
1252
                divide, or FPU stage.
1253
        \item Issuing a non--pipelined memory instruction to the memory unit
1254
                while the memory unit is busy will stall the entire pipeline.
1255 21 dgisselq
        \end{itemize}
1256 32 dgisselq
\item {\bf Write-Back}: Conditionally write back the result to the register
1257 69 dgisselq
        set, applying the condition.  This routine is quad-entrant: either the
1258
        ALU, the memory, the divide, or the FPU may write back a register.
1259
        The only design rule is that no more than a single register may be
1260
        written back in any given clock.
1261 21 dgisselq
\end{enumerate}
1262
 
1263 24 dgisselq
The Zip CPU does not support out of order execution.  Therefore, if the memory
1264 69 dgisselq
unit stalls, every other instruction stalls.  The same is true for divide or
1265
floating point instructions--all other instructions will stall while waiting
1266
for these to complete.  Memory stores, however, can take place concurrently
1267
with non--memory operations, although memory reads (loads) cannot.
1268 24 dgisselq
 
1269 32 dgisselq
\section{Pipeline Stalls}
1270
The processing pipeline can and will stall for a variety of reasons.  Some of
1271
these are obvious, some less so.  These reasons are listed below:
1272
\begin{itemize}
1273
\item When the prefetch cache is exhausted
1274 21 dgisselq
 
1275 36 dgisselq
This reason should be obvious.  If the prefetch cache doesn't have the
1276 69 dgisselq
instruction in memory, the entire pipeline must stall until an instruction
1277
can be made ready.  In the case of the {\tt pipefetch} windowed approach
1278
to the prefetch cache, this means the pipeline will stall until enough of the
1279
prefetch cache is loaded to support the next instruction.  In the case
1280
of the more traditional {\tt pfcache} approach, the entire cache line must
1281
fill before instruction execution can continue.
1282 21 dgisselq
 
1283 32 dgisselq
\item While waiting for the pipeline to load following any taken branch, jump,
1284 69 dgisselq
        return from interrupt or switch to interrupt context (4 stall cycles)
1285 32 dgisselq
 
1286 68 dgisselq
Fig.~\ref{fig:bcstalls}
1287
\begin{figure}\begin{center}
1288
\includegraphics[width=3.5in]{../gfx/bc.eps}
1289 69 dgisselq
\caption{A conditional branch generates 4 stall cycles}\label{fig:bcstalls}
1290 68 dgisselq
\end{center}\end{figure}
1291
illustrates the situation for a conditional branch.  In this case, the branch
1292 69 dgisselq
instruction, {\tt BC}, is nominally followed by instructions {\tt I1} and so
1293 68 dgisselq
forth.  However, since the branch is taken, the next instruction must be
1294
{\tt IA}.  Therefore, the pipeline needs to be cleared and reloaded.
1295
Given that there are five stages to the pipeline, that accounts
1296 69 dgisselq
for the four stalls.  (Were the {\tt pipefetch} cache chosen, there would
1297
be another stall internal to the {\tt pipefetch} cache.)
1298 32 dgisselq
 
1299 36 dgisselq
The Zip CPU handles {\tt MOV \$X(PC),PC}, {\tt ADD \$X,PC}, and
1300
{\tt LDI \$X,PC} instructions specially, however.  These instructions, when
1301 69 dgisselq
not conditioned on the flags, can execute with only a single stall cycle,
1302
such as is shown in Fig.~\ref{fig:branch}.\footnote{Note that when using the
1303
{\tt pipefetch} cache, this requires an additional stall cycle due to that
1304
cache's implementation.}
1305 68 dgisselq
\begin{figure}\begin{center}
1306 69 dgisselq
\includegraphics[width=4in]{../gfx/bra.eps} %0.4in per clock
1307
\caption{An expedited branch costs a single stall cycle}\label{fig:branch}
1308 68 dgisselq
\end{center}\end{figure}
1309
In this example, {\tt BR} is a branch always taken, {\tt I1} is the instruction
1310
following the branch in memory, while {\tt IA} is the first instruction at the
1311
branch address.  ({\tt CLR} denotes a clear--pipeline operation, and does
1312
not represent any instruction.)
1313 36 dgisselq
 
1314 32 dgisselq
\item When reading from a prior register while also adding an immediate offset
1315
\begin{enumerate}
1316
\item\ {\tt OPCODE ?,RA}
1317
\item\ {\em (stall)}
1318
\item\ {\tt OPCODE I+RA,RB}
1319
\end{enumerate}
1320
 
1321
Since the addition of the immediate register within OpB decoding gets applied
1322
during the read operand stage so that it can be nicely settled before the ALU,
1323
any instruction that will write back an operand must be separated from the
1324
opcode that will read and apply an immediate offset by one instruction.  The
1325
good news is that this stall can easily be mitigated by proper scheduling.
1326 36 dgisselq
That is, any instruction that does not add an immediate to {\tt RA} may be
1327
scheduled into the stall slot.
1328 32 dgisselq
 
1329 69 dgisselq
This is also the reason why, when setting up a stack frame, the top of the
1330
stack frame is used first: it eliminates this stall cycle.  Hence, to save
1331
registers at the top of a procedure, one would write:
1332 32 dgisselq
\begin{enumerate}
1333 69 dgisselq
\item\ {\tt SUB 2,SP}
1334
\item\ {\tt STO R1,(SP)}
1335
\item\ {\tt STO R2,1(SP)}
1336 32 dgisselq
\end{enumerate}
1337 69 dgisselq
Had {\tt R1} instead been stored at {\tt 1(SP)} as the top of the stack,
1338
there would've been an extra stall in setting up the stack frame.
1339 32 dgisselq
 
1340
\item When reading from the CC register after setting the flags
1341
\begin{enumerate}
1342 69 dgisselq
\item\ {\tt ALUOP RA,RB} {\em ; Ex: a compare opcode}
1343 36 dgisselq
\item\ {\em (stall)}
1344 32 dgisselq
\item\ {\tt TST sys.ccv,CC}
1345
\item\ {\tt BZ somewhere}
1346
\end{enumerate}
1347
 
1348 68 dgisselq
The reason for this stall is simply performance: many of the flags are
1349
determined via combinatorial logic {\em during} the writeback cycle.
1350
Trying to then place these into the input for one of the operands for an
1351
ALU instruction during the same cycle
1352 32 dgisselq
created a time delay loop that would no longer execute in a single 100~MHz
1353
clock cycle.  (The time delay of the multiply within the ALU wasn't helping
1354
either \ldots).
1355
 
1356 33 dgisselq
This stall may be eliminated via proper scheduling, by placing an instruction
1357
that does not set flags in between the ALU operation and the instruction
1358
that references the CC register.  For example, {\tt MOV \$addr+PC,uPC}
1359
followed by an {\tt RTU} ({\tt OR \$GIE,CC}) instruction will not incur
1360
this stall, whereas an {\tt OR \$BREAKEN,CC} followed by an {\tt OR \$STEP,CC}
1361 68 dgisselq
will incur the stall, while a {\tt LDI \$BREAKEN|\$STEP,CC} will not since
1362 69 dgisselq
it doesn't read the condition codes before executing.
1363 33 dgisselq
 
1364 32 dgisselq
\item When waiting for a memory read operation to complete
1365
\begin{enumerate}
1366
\item\ {\tt LOD address,RA}
1367 36 dgisselq
\item\ {\em (multiple stalls, bus dependent, 4 clocks best)}
1368 32 dgisselq
\item\ {\tt OPCODE I+RA,RB}
1369
\end{enumerate}
1370
 
1371 36 dgisselq
Remember, the Zip CPU does not support out of order execution.  Therefore,
1372 32 dgisselq
anytime the memory unit becomes busy both the memory unit and the ALU must
1373 68 dgisselq
stall until the memory unit is cleared.  This is illustrated in
1374
Fig.~\ref{fig:memrd},
1375
\begin{figure}\begin{center}
1376 69 dgisselq
\includegraphics[width=5.6in]{../gfx/memrd.eps}
1377 68 dgisselq
\caption{Pipeline handling of a load instruction}\label{fig:memrd}
1378
\end{center}\end{figure}
1379
since it is especially true of a load
1380 69 dgisselq
instruction, which must still write its operand back to the register file.
1381
Further, note that on a pipelined memory operation, the instruction must
1382
stall in the decode operand stage, lest it try to read a result from the
1383
register file before the load result has been written to it.  Finally, note
1384
that there is an extra stall at the end of the memory cycle, so that
1385
the memory unit will be idle for two clocks before an instruction will be
1386
accepted into the ALU.  Store instructions are different, as shown in
1387
Fig.~\ref{fig:memwr},
1388 68 dgisselq
\begin{figure}\begin{center}
1389 69 dgisselq
\includegraphics[width=4in]{../gfx/memwr.eps}
1390 68 dgisselq
\caption{Pipeline handling of a store instruction}\label{fig:memwr}
1391
\end{center}\end{figure}
1392
since they can be busy with the bus without impacting later write back
1393
pipeline stages.  Hence, only loads stall the pipeline.
1394 32 dgisselq
 
1395 68 dgisselq
This, of course, also assumes that the memory being accessed is a single cycle
1396
memory and that there are no stalls to get to the memory.
1397 32 dgisselq
Slower memories, such as the Quad SPI flash, will take longer--perhaps even
1398 33 dgisselq
as long as forty clocks.   During this time the CPU and the external bus
1399 68 dgisselq
will be busy, and unable to do anything else.  Likewise, if it takes a couple
1400
of clock cycles for the bus to be free, as shown in both Figs.~\ref{fig:memrd}
1401
and~\ref{fig:memwr}, there will be stalls.
1402 32 dgisselq
 
1403
\item Memory operation followed by a memory operation
1404
\begin{enumerate}
1405
\item\ {\tt STO address,RA}
1406 36 dgisselq
\item\ {\em (multiple stalls, bus dependent, 4 clocks best)}
1407 32 dgisselq
\item\ {\tt LOD address,RB}
1408 36 dgisselq
\item\ {\em (multiple stalls, bus dependent, 4 clocks best)}
1409 32 dgisselq
\end{enumerate}
1410
 
1411 68 dgisselq
In this case, the LOD instruction cannot start until the STO is finished,
1412
as illustrated by Fig.~\ref{fig:mstld}.
1413
\begin{figure}\begin{center}
1414
\includegraphics[width=5.5in]{../gfx/mstld.eps}
1415
\caption{Pipeline handling of a store followed by a load instruction}\label{fig:mstld}
1416
\end{center}\end{figure}
1417 32 dgisselq
With proper scheduling, it is possible to do something in the ALU while the
1418 36 dgisselq
memory unit is busy with the STO instruction, but otherwise this pipeline will
1419 68 dgisselq
stall while waiting for it to complete before the load instruction can
1420
start.
1421 32 dgisselq
 
1422 39 dgisselq
The Zip CPU does have the capability of supporting pipelined memory access,
1423
but only under the following conditions: all accesses within the pipeline
1424
must all be reads or all be writes, all must use the same register for their
1425
address, and there can be no stalls or other instructions between pipelined
1426
memory access instructions.  Further, the offset to memory must be increasing
1427
by one address each instruction.  These conditions work well for saving or
1428 68 dgisselq
storing registers to the stack.  Indeed, if you noticed, both
1429
Fig.~\ref{fig:memrd} and Fig.~\ref{fig:memwr} illustrated pipelined memory
1430
accesses.
1431 36 dgisselq
 
1432 32 dgisselq
\end{itemize}
1433
 
1434
 
1435 21 dgisselq
\chapter{Peripherals}\label{chap:periph}
1436 24 dgisselq
 
1437
While the previous chapter describes a CPU in isolation, the Zip System
1438
includes a minimum set of peripherals as well.  These peripherals are shown
1439
in Fig.~\ref{fig:zipsystem}
1440
\begin{figure}\begin{center}
1441
\includegraphics[width=3.5in]{../gfx/system.eps}
1442
\caption{Zip System Peripherals}\label{fig:zipsystem}
1443
\end{center}\end{figure}
1444
and described here.  They are designed to make
1445
the Zip CPU more useful in an Embedded Operating System environment.
1446
 
1447 68 dgisselq
\section{Interrupt Controller}\label{sec:pic}
1448 24 dgisselq
 
1449
Perhaps the most important peripheral within the Zip System is the interrupt
1450
controller.  While the Zip CPU itself can only handle one interrupt, and has
1451
only the one interrupt state: disabled or enabled, the interrupt controller
1452
can make things more interesting.
1453
 
1454
The Zip System interrupt controller module supports up to 15 interrupts, all
1455
controlled from one register.  Bit~31 of the interrupt controller controls
1456
overall whether interrupts are enabled (1'b1) or disabled (1'b0).  Bits~16--30
1457 68 dgisselq
control whether individual interrupts are enabled (1'b1) or disabled (1'b0).
1458 24 dgisselq
Bit~15 is an indicator showing whether or not any interrupt is active, and
1459
bits~0--15 indicate whether or not an individual interrupt is active.
1460
 
1461
The interrupt controller has been designed so that bits can be controlled
1462
individually without having any knowledge of the rest of the controller
1463
setting.  To enable an interrupt, write to the register with the high order
1464
global enable bit set and the respective interrupt enable bit set.  No other
1465
bits will be affected.  To disable an interrupt, write to the register with
1466
the high order global enable bit cleared and the respective interrupt enable
1467
bit set.  To clear an interrupt, write a `1' to that interrupts status pin.
1468
Zero's written to the register have no affect, save that a zero written to the
1469
master enable will disable all interrupts.
1470
 
1471
As an example, suppose you wished to enable interrupt \#4.  You would then
1472
write to the register a {\tt 0x80100010} to enable interrupt \#4 and to clear
1473
any past active state.  When you later wish to disable this interrupt, you would
1474
write a {\tt 0x00100010} to the register.  As before, this both disables the
1475
interrupt and clears the active indicator.  This also has the side effect of
1476
disabling all interrupts, so a second write of {\tt 0x80000000} may be necessary
1477
to re-enable any other interrupts.
1478
 
1479
The Zip System currently hosts two interrupt controllers, a primary and a
1480 69 dgisselq
secondary.  The primary interrupt controller has one (or more) interrupt line(s)
1481
which may come from an external interrupt source, and one interrupt line from
1482
the secondary controller.  Other primary interrupts include the system timers,
1483
the jiffies interrupt, and the manual cache interrupt.  The secondary interrupt
1484
controller maintains an interrupt state for all of the processor accounting
1485
counters.
1486 24 dgisselq
 
1487 21 dgisselq
\section{Counter}
1488
 
1489
The Zip Counter is a very simple counter: it just counts.  It cannot be
1490
halted.  When it rolls over, it issues an interrupt.  Writing a value to the
1491
counter just sets the current value, and it starts counting again from that
1492
value.
1493
 
1494
Eight counters are implemented in the Zip System for process accounting.
1495
This may change in the future, as nothing as yet uses these counters.
1496
 
1497
\section{Timer}
1498
 
1499
The Zip Timer is also very simple: it simply counts down to zero.  When it
1500
transitions from a one to a zero it creates an interrupt.
1501
 
1502
Writing any non-zero value to the timer starts the timer.  If the high order
1503
bit is set when writing to the timer, the timer becomes an interval timer and
1504
reloads its last start time on any interrupt.  Hence, to mark seconds, one
1505
might set the timer to 100~million (the number of clocks per second), and
1506
set the high bit.  Ever after, the timer will interrupt the CPU once per
1507 24 dgisselq
second (assuming a 100~MHz clock).  This reload capability also limits the
1508 68 dgisselq
maximum timer value to $2^{31}-1$ (about 21~seconds using a 100~MHz clock),
1509
rather than $2^{32}-1$.
1510 21 dgisselq
 
1511
\section{Watchdog Timer}
1512
 
1513
The watchdog timer is no different from any of the other timers, save for one
1514
critical difference: the interrupt line from the watchdog
1515
timer is tied to the reset line of the CPU.  Hence writing a `1' to the
1516
watchdog timer will always reset the CPU.
1517 32 dgisselq
To stop the Watchdog timer, write a `0' to it.  To start it,
1518 21 dgisselq
write any other number to it---as with the other timers.
1519
 
1520
While the watchdog timer supports interval mode, it doesn't make as much sense
1521
as it did with the other timers.
1522
 
1523 68 dgisselq
\section{Bus Watchdog}
1524
There is an additional watchdog timer on the Wishbone bus.  This timer,
1525
however, is hardware configured and not software configured.  The timer is
1526
reset at the beginning of any bus transaction, and only counts clocks during
1527
such bus transactions.  If the bus transaction takes longer than the number
1528
of counts the timer allots, it will raise a bus error flag to terminate the
1529
transaction.  This is useful in the case of any peripherals that are
1530
misbehaving.  If the bus watchdog terminates a bus transaction, the CPU may
1531
then read from its port to find out which memory location created the problem.
1532
 
1533
Aside from its unusual configuration, the bus watchdog is just another
1534 69 dgisselq
implementation of the fundamental timer described above--stripped down
1535
for simplicity.
1536 68 dgisselq
 
1537 21 dgisselq
\section{Jiffies}
1538
 
1539
This peripheral is motivated by the Linux use of `jiffies' whereby a process
1540
can request to be put to sleep until a certain number of `jiffies' have
1541
elapsed.  Using this interface, the CPU can read the number of `jiffies'
1542
from the peripheral (it only has the one location in address space), add the
1543 69 dgisselq
sleep length to it, and write the result back to the peripheral.  The
1544
{\tt zipjiffies}
1545 21 dgisselq
peripheral will record the value written to it only if it is nearer the current
1546
counter value than the last current waiting interrupt time.  If no other
1547
interrupts are waiting, and this time is in the future, it will be enabled.
1548
(There is currently no way to disable a jiffie interrupt once set, other
1549 24 dgisselq
than to disable the interrupt line in the interrupt controller.)  The processor
1550 21 dgisselq
may then place this sleep request into a list among other sleep requests.
1551
Once the timer expires, it would write the next Jiffy request to the peripheral
1552
and wake up the process whose timer had expired.
1553
 
1554
Indeed, the Jiffies register is nothing more than a glorified counter with
1555
an interrupt.  Unlike the other counters, the Jiffies register cannot be set.
1556
Writes to the jiffies register create an interrupt time.  When the Jiffies
1557
register later equals the value written to it, an interrupt will be asserted
1558
and the register then continues counting as though no interrupt had taken
1559
place.
1560
 
1561
The purpose of this register is to support alarm times within a CPU.  To
1562
set an alarm for a particular process $N$ clocks in advance, read the current
1563
Jiffies value, and $N$, and write it back to the Jiffies register.  The
1564
O/S must also keep track of values written to the Jiffies register.  Thus,
1565 32 dgisselq
when an `alarm' trips, it should be removed from the list of alarms, the list
1566 69 dgisselq
should be resorted, and the next alarm in terms of Jiffies should be written
1567
to the register--possibly for a second time.
1568 21 dgisselq
 
1569 36 dgisselq
\section{Direct Memory Access Controller}
1570 24 dgisselq
 
1571 36 dgisselq
The Direct Memory Access (DMA) controller can be used to either move memory
1572
from one location to another, to read from a peripheral into memory, or to
1573
write from a peripheral into memory all without CPU intervention.  Further,
1574
since the DMA controller can issue (and does issue) pipeline wishbone accesses,
1575
any DMA memory move will by nature be faster than a corresponding program
1576
accomplishing the same move.  To put this to numbers, it may take a program
1577
18~clocks per word transferred, whereas this DMA controller can move one
1578 69 dgisselq
word in two clocks--provided it has bus access.  (The CPU gets priority over
1579
the bus.)
1580 24 dgisselq
 
1581 36 dgisselq
When copying memory from one location to another, the DMA controller will
1582
copy in units of a given transfer length--up to 1024 words at a time.  It will
1583
read that transfer length into its internal buffer, and then write to the
1584 69 dgisselq
destination address from that buffer.
1585 24 dgisselq
 
1586 36 dgisselq
When coupled with a peripheral, the DMA controller can be configured to start
1587 69 dgisselq
a memory copy when any interrupt line going high.  Further, the controller can
1588
be configured to issue reads from (or to) the same address instead of
1589
incrementing the address at each clock.  The DMA completes once the total
1590
number of items specified (not the transfer length) have been transferred.
1591 36 dgisselq
 
1592
In each case, once the transfer is complete and the DMA unit returns to
1593
idle, the DMA will issue an interrupt.
1594
 
1595
 
1596 21 dgisselq
\chapter{Operation}\label{chap:ops}
1597
 
1598 33 dgisselq
The Zip CPU, and even the Zip System, is not a System on a Chip (SoC).  It
1599
needs to be connected to its operational environment in order to be used.
1600
Specifically, some per system adjustments need to be made:
1601
\begin{enumerate}
1602
\item The Zip System depends upon an external 32-bit Wishbone bus.  This
1603
        must exist, and must be connected to the Zip CPU for it to work.
1604
\item The Zip System needs to be told of its {\tt RESET\_ADDRESS}.  This is
1605
        the program counter of the first instruction following a reset.
1606 69 dgisselq
\item To conserve logic, you'll want to set the {\tt ADDRESS\_WIDTH} parameter
1607
        to the number of address bits on your wishbone bus.
1608
\item Likewise, the {\tt LGICACHE} parameter sets the number of bits in
1609
        the instruction cache address.  This means that the instruction cache
1610
        will have $2^{\mbox{\tiny\tt LGICACHE}}$ locations within it.
1611 33 dgisselq
\item If you want the Zip System to start up on its own, you will need to
1612
        set the {\tt START\_HALTED} parameter to zero.  Otherwise, if you
1613
        wish to manually start the CPU, that is if upon reset you want the
1614
        CPU start start in its halted, reset state, then set this parameter to
1615 69 dgisselq
        one.  This latter configuration is useful for a CPU that should be
1616
        idle (i.e. halted) until given an explicit instruction from somewhere
1617
        else to start.
1618 33 dgisselq
\item The third parameter to set is the number of interrupts you will be
1619
        providing from external to the CPU.  This can be anything from one
1620 69 dgisselq
        to sixteen, but it cannot be zero.  (Set this to 1 and wire the single
1621
        interrupt line to a 1'b0 if you do not wish to support any external
1622
        interrupts.)
1623 33 dgisselq
\item Finally, you need to place into some wishbone accessible address, whether
1624
        RAM or (more likely) ROM, the initial instructions for the CPU.
1625
\end{enumerate}
1626
If you have enabled your CPU to start automatically, then upon power up the
1627 69 dgisselq
CPU will immediately start executing your instructions, starting at the given
1628
{\tt RESET\_ADDRESS}.
1629 33 dgisselq
 
1630
This is, however, not how I have used the Zip CPU.  I have instead used the
1631 36 dgisselq
Zip CPU in a more controlled environment.  For me, the CPU starts in a
1632 33 dgisselq
halted state, and waits to be told to start.  Further, the RESET address is a
1633
location in RAM.  After bringing up the board I am using, and further the
1634
bus that is on it, the RAM memory is then loaded externally with the program
1635
I wish the Zip System to run.  Once the RAM is loaded, I release the CPU.
1636 69 dgisselq
The CPU then runs until either its halt condition or an exception occurrs in
1637
supervisor mode, at which point its task is complete.
1638 33 dgisselq
 
1639
Eventually, I intend to place an operating system onto the ZipSystem, I'm
1640
just not there yet.
1641
 
1642 68 dgisselq
The rest of this chapter examines some common programming models, and how they
1643
might be applied to the Zip System, and then finish with a couple of examples.
1644 33 dgisselq
 
1645 68 dgisselq
\section{System High}
1646
The easiest and simplest way to run the Zip CPU is in the system high mode.
1647
In this mode, the CPU runs your program in supervisor mode from reboot to
1648
power down, and is never interrupted.  You will need to poll the interrupt
1649
controller to determine when any external condition has become active.  This
1650
mode is useful, and can handle many microcontroller tasks.
1651
 
1652
Even better, in system high mode, all of the user registers are available
1653
to the system high program as variables.  Accessing these registers can be
1654
done in a single clock cycle, which would move them to the active register
1655
set or move them back.  While this may seem like a load or store instruction,
1656
none of these register accesses will suffer from memory delays.
1657
 
1658
The one thing that cannot be done in supervisor mode is a wait for interrupt
1659
instruction.  This, however, is easily rectified by jumping to a user task
1660
within the supervisors memory space, such as Tbl.~\ref{tbl:shi-idle}.
1661
\begin{table}\begin{center}
1662
\begin{tabbing}
1663
{\tt supervisor\_idle:} \\
1664
\hbox to 0.25in{}\={\em ; While not strictly required, the following move helps to} \\
1665
\>      {\em ; ensure that the prefetch doesn't try to fetch an instruction} \\
1666
\>      {\em ; outside of the CPU's address space when it switches to user} \\
1667
\>      {\em ; mode.} \\
1668
\>      {\tt MOV supervisor\_idle\_continue,uPC} \\
1669
\>      {\em ; Put the processor into user mode and to sleep in the same} \\
1670
\>      {\em ; instruction. } \\
1671
\>      {\tt OR \$SLEEP|\$GIE,CC} \\
1672
{\tt supervisor\_idle\_continue:} \\
1673
\>      {\em ; Now, if we haven't done this inline, we need to return} \\
1674
\>      {\em ; to whatever function called us.} \\
1675
\>      {\tt RETN} \\
1676
\end{tabbing}
1677
\caption{Executing an idle from supervisor mode}\label{tbl:shi-idle}
1678
\end{center}\end{table}
1679
 
1680
\section{Traditional Interrupt Handling}
1681
Although the Zip CPU does not have a traditional interrupt architecture,
1682
it is possible to create the more traditional interrupt approach via software.
1683
In this mode, the programmable interrupt controller is used together with the
1684
supervisor state to create the illusion of more traditional interrupt handling.
1685
 
1686
To set this up, upon reboot the supervisor task:
1687
\begin{enumerate}
1688
\item Creates a (single) user context, a user stack, and sets the user
1689
        program counter to the entry of the user task
1690
\item Creates a task table of ISR entries
1691
\item Enables the master interrupt enable via the interrupt controller, albeit
1692
        without enabling any of the fifteen potential underlying interrupts.
1693
\item Switches to user mode, as the first part of the while loop in
1694
        Tbl.~\ref{tbl:traditional-isr}.
1695
\end{enumerate}
1696
\begin{table}\begin{center}
1697
\begin{tabbing}
1698
{\tt while(true) \{} \\
1699
\hbox to 0.25in{}\= {\tt rtu();}\\
1700
        \> {\tt if (trap) \{} {\em // Here, we allow users to install ISRs, or} \\
1701
        \>\hbox to 0.25in{}\= {\em // whatever else they may wish to do in supervisor mode.} \\
1702
        \> {\tt \} else \{} \\
1703
        \> \> {\tt volatile int *pic = PIC\_ADDRESS;} \\
1704
\\
1705
        \> \> {\em // Save the user context before running any ISRs.  This could easily be}\\
1706
        \> \> {\em // implemented as an inline assembly routine or macro}\\
1707
        \> \> {\tt SAVE\_PARTIAL\_CONTEXT; }\\
1708
        \> \> {\em // At this point, we know an interrupt has taken place:  Ask the programmable}\\
1709
        \> \> {\em // interrupt controller (PIC) which interrupts are enabled and which are active.}\\
1710
        \> \>   {\tt int        picv = *pic;}\\
1711
        \> \>   {\em // Turn off all active interrupts}\\
1712
        \> \>   {\em // Globally disable interrupt generation in the process}\\
1713
        \> \>   {\tt int        active = (picv >> 16) \& picv \& 0x07fff;}\\
1714
        \> \>   {\tt *pic = (active<<16);}\\
1715
        \> \>   {\em // We build a mask of interrupts to re-enable in picv.}\\
1716
        \> \>   {\tt picv = 0;}\\
1717
        \> \>   {\tt for(int i=0,msk=1; i<15; i++, msk<<=1) \{}\\
1718
        \> \>\hbox to 0.25in{}\={\tt if ((active \& msk)\&\&(isr\_table[i])) \{}\\
1719
        \> \>\>\hbox to 0.25in{}\= {\tt mov(isr\_table[i],uPC); }\\
1720
        \> \>\>\>       {\em // Acknowledge this particular interrupt.  While we could acknowledge all}\\
1721
        \> \>\>\>       {\em // interrupts at once, by acknowledging only those with ISR's we allow}\\
1722
        \> \>\>\>       {\em // the user process to use peripherals manually, and to manually check}\\
1723
        \> \>\>\>       {\em // whether or no those other interrupts had occurred.}\\
1724
        \> \>\>\>       {\tt *pic = msk; }\\
1725
        \> \>\>\>       {\tt rtu(); }\\
1726
        \> \>\>\>       {\em // The ISR will only exit on a trap in the Zip archtecture.  There is}\\
1727
        \> \>\>\>       {\em // no {\tt RETI} instruction.  Since the PIC holds all interrupts disabled,}\\
1728
        \> \>\>\>       {\em // there is no need to check for further interrupts.}\\
1729
        \> \>\>\>       {\em // }\\
1730
        \> \>\>\>       {\em // The tricky part is that, because of how the PIC is built, the ISR cannot}\\
1731
        \>\>\>\>        {\em // re-enable its own interrupt without re-enabling all interrupts.  Hence, we}\\
1732
        \>\>\>\>        {\em // look at R0 upon ISR completion to know if an interrupt needs to be }\\
1733
        \> \>\>\>       {\em // re-enabled. }\\
1734
        \> \>\>\>       {\tt mov(uR0,tmp); }\\
1735
        \> \>\>\>       {\tt picv |= (tmp \& 0x7fff) << 16; }\\
1736
        \> \>\>         {\tt \} }\\
1737
        \> \>   {\tt \} }\\
1738
        \> \>   {\tt RESTORE\_PARTIAL\_CONTEXT; }\\
1739
        \> \>   {\em // Re-activate all (requested) interrupts }\\
1740
        \> \>   {\tt *pic = picv | 0x80000000; }\\
1741
        \>{\tt \} }\\
1742
{\tt \}}\\
1743
\end{tabbing}
1744
\caption{Traditional Interrupt handling}\label{tbl:traditional-isr}
1745
\end{center}\end{table}
1746
 
1747
We can work through the interrupt handling process by examining
1748
Tbl.~\ref{tbl:traditional-isr}.  First, remember, the CPU is always running
1749
either the user or the supervisor context.  Once the supervisor switches to
1750
user mode, control does not return until either an interrupt or a trap
1751
has taken place.  (Okay, there's also the possibility of a bus error, or an
1752
illegal instruction such as an unimplemented floating point instruction---but
1753
for now we'll just focus on the trap instruction.)  Therefore, if the trap bit
1754
isn't set, then we know an interrupt has taken place.
1755
 
1756
To process an interrupt, we steal the user's stack: the PC and CC registers
1757
are saved on the stack, as outlined in Tbl.~\ref{tbl:save-partial}.
1758
\begin{table}\begin{center}
1759
\begin{tabbing}
1760
SAVE\_PARTIAL\_CONTEXT: \\
1761
\hbox to 0.25in{}\= {\em ; We save R0, CC, and PC only} \\
1762
\>        {\tt MOV -3(uSP),R3} \\
1763
\>        {\tt MOV uR0,R0} \\
1764
\>        {\tt MOV uCC,R1} \\
1765
\>        {\tt MOV uPC,R2} \\
1766 69 dgisselq
\>        {\tt STO R0,(R3)} {\em ; Exploit memory pipelining: }\\
1767
\>        {\tt STO R1,1(R3)} {\em ; All instructions write to stack }\\
1768
\>        {\tt STO R2,2(R3)} {\em ; All offsets increment by one }\\
1769 68 dgisselq
\>        {\tt MOV R3,uSP} {\em ; Return the updated stack pointer } \\
1770
\end{tabbing}
1771
\caption{Example Saving Minimal User Context}\label{tbl:save-partial}
1772
\end{center}\end{table}
1773
This is much cheaper than the full context swap of a preemptive multitasking
1774
kernel, but it also depends upon the ISR saving any state it uses.  Further,
1775
if multiple ISR's get called at once, this looses its optimality property
1776
very quickly.
1777
 
1778
As Sec.~\ref{sec:pic} discusses, the top of the PIC register stores which
1779
interrupts are enabled, and the bottom stores which have tripped.  (Interrupts
1780
may trip without being enabled, they just will not generate an interrupt to the
1781
CPU.)  Our first step is to query the register to find out our interrupt
1782
state, and then to disable any interrupts that have tripped.  To do
1783
that, we write a one to the enable half of the register while also clearing
1784
the top bit (master interrupt enable).  This has the consequence of disabling
1785
any and all further interrupts, not just the ones that have tripped.  Hence,
1786
upon completion, we re--enable the master interrupt bit again.   Finally,
1787
we keep track of which interrupts have tripped.
1788
 
1789
Using the bit mask of interrupts that have tripped, we walk through all fifteen
1790
possible interrupts.  If there is an ISR installed, we acknowledge and reset
1791
the interrupt within the PIC, and then call the ISR.  The ISR, however, cannot
1792
re--enable its interrupt without re-enabling the master interrupt bit.  Thus,
1793
to keep things simple, when the ISR is finished it places its interrupt
1794
mask back into R0, or clears R0.  This tells the supervisor mode process which
1795
interrupts to re--enable.  Any other registers that the ISR uses must be
1796
saved and restored.  (This is only truly optimal if only a single ISR is
1797
called.)  As a final instruction, the ISR clears the GIE bit executing a user
1798
trap.  (Remember, the Zip CPU has no {\tt RETI} instruction to restore the
1799
stack and return to userland.  It needs to go through the supervisor mode to
1800
get there.)
1801
 
1802
Then, once all interrupts are handled, the user context is restored in  a
1803
fashion similar to Tbl.~\ref{tbl:restore-partial}.
1804
\begin{table}\begin{center}
1805
\begin{tabbing}
1806
RESTORE\_PARTIAL\_CONTEXT: \\
1807
\hbox to 0.25in{}\= {\em ; We retore R0, CC, and PC only} \\
1808
\>        {\tt MOV uSP,R3} {\em ; Return the updated stack pointer } \\
1809 69 dgisselq
\>        {\tt LOD R0,(R3),R0} {\em ; Exploit memory pipelining: }\\
1810
\>        {\tt LOD R1,1(R3),R1} {\em ; All instructions write to stack }\\
1811
\>        {\tt LOD R2,2(R3),R2} {\em ; All offsets increment by one }\\
1812 68 dgisselq
\>        {\tt MOV R0,uR0} \\
1813
\>        {\tt MOV R1,uCC} \\
1814
\>        {\tt MOV R2,uPC} \\
1815
\>        {\tt MOV 3(R3),uSP} \\
1816
\end{tabbing}
1817
\caption{Example Restoring Minimal User Context}\label{tbl:restore-partial}
1818
\end{center}\end{table}
1819
Again, this is short and sweet simply because any other registers that needed
1820
saving were saved within the ISR.
1821
 
1822
There you have it: the Zip CPU, with its non-traditional interrupt architecture,
1823
can still process interrupts in a very traditional fashion.
1824
 
1825 36 dgisselq
\section{Example: Idle Task}
1826
One task every operating system needs is the idle task, the task that takes
1827
place when nothing else can run.  On the Zip CPU, this task is quite simple,
1828
and it is shown in assemble in Tbl.~\ref{tbl:idle-asm}.
1829
\begin{table}\begin{center}
1830
\begin{tabular}{ll}
1831
{\tt idle\_task:} \\
1832
&        {\em ; Wait for the next interrupt, then switch to supervisor task} \\
1833
&        {\tt WAIT} \\
1834
&        {\em ; When we come back, it's because the supervisor wishes to} \\
1835
&        {\em ; wait for an interrupt again, so go back to the top.} \\
1836
&        {\tt BRA idle\_task} \\
1837
\end{tabular}
1838
\caption{Example Idle Loop}\label{tbl:idle-asm}
1839
\end{center}\end{table}
1840
When this task runs, the CPU will fill up all of the pipeline stages up the
1841
ALU.  The {\tt WAIT} instruction, upon leaving the ALU, places the CPU into
1842
a sleep state where nothing more moves.  Sure, there may be some more settling,
1843
the pipe cache continue to read until full, other instructions may issue until
1844
the pipeline fills, but then everything will stall.  Then, once an interrupt
1845
takes place, control passes to the supervisor task to handle the interrupt.
1846
When control passes back to this task, it will be on the next instruction.
1847
Since that next instruction sends us back to the top of the task, the idle
1848
task thus does nothing but wait for an interrupt.
1849
 
1850
This should be the lowest priority task, the task that runs when nothing else
1851
can.  It will help lower the FPGA power usage overall---at least its dynamic
1852
power usage.
1853
 
1854
\section{Example: Memory Copy}
1855
One common operation is that of a memory move or copy.  Consider the C code
1856
shown in Tbl.~\ref{tbl:memcp-c}.
1857
\begin{table}\begin{center}
1858
\parbox{4in}{\begin{tabbing}
1859
{\tt void} \= {\tt memcp(void *dest, void *src, int len) \{} \\
1860
        \> {\tt for(int i=0; i<len; i++)} \\
1861
        \> \hspace{0.2in} {\tt *dest++ = *src++;} \\
1862
\}
1863
\end{tabbing}}
1864
\caption{Example Memory Copy code in C}\label{tbl:memcp-c}
1865
\end{center}\end{table}
1866
This same code can be translated in Zip Assembly as shown in
1867
Tbl.~\ref{tbl:memcp-asm}.
1868
\begin{table}\begin{center}
1869
\begin{tabular}{ll}
1870
memcp: \\
1871 69 dgisselq
&        {\em ; R0 = *dest, R1 = *src, R2 = LEN, R3 = return addr} \\
1872
&        {\em ; The following will operate in $12N+19$ clocks.} \\
1873
&        {\tt CMP 0,R2} \\ % 8 clocks per setup
1874
&        {\tt MOV.Z R3,PC} {\em ; A conditional return }\\
1875
&        {\tt SUB 1,SP} {\em ; Create a stack frame}\\
1876
&        {\tt STO R4,(SP)} {\em ; and a local variable}\\
1877
&        {\em ; (4 stalls, cannot be further scheduled away)} \\
1878
loop: \\ % 12 clocks per loop
1879
&        {\tt LOD (R1),R4} \\
1880 36 dgisselq
&        {\em ; (4 stalls, cannot be scheduled away)} \\
1881 69 dgisselq
&        {\tt STO R4,(R0)} {\em ; (4 schedulable stalls, has no impact now)} \\
1882
&        {\tt SUB 1,R2} \\
1883
&        {\tt BZ memcpend} \\
1884
&        {\tt ADD 1,R0} \\
1885 36 dgisselq
&        {\tt ADD 1,R1} \\
1886 69 dgisselq
&        {\tt BRA loop} \\
1887
&        {\em ; (1 stall on a BRA instruction)} \\
1888
memcpend: % 11 clocks
1889
&        {\tt LOD (SP),R4} \\
1890
&        {\em ; (4 stalls, cannot be further scheduled away)} \\
1891
&        {\tt ADD 1,SP} \\
1892
&        {\tt JMP R3} \\
1893
&        {\em ; (4 stalls)} \\
1894 36 dgisselq
\end{tabular}
1895
\caption{Example Memory Copy code in Zip Assembly}\label{tbl:memcp-asm}
1896
\end{center}\end{table}
1897
This example points out several things associated with the Zip CPU.  First,
1898
a straightforward implementation of a for loop is not the fastest loop
1899
structure.  For this reason, we have placed the test to continue at the
1900
end.  Second, all pointers are {\tt void} pointers to arbitrary 32--bit
1901
data types.  The Zip CPU does not have explicit support for smaller or larger
1902
data types, and so this memory copy cannot be applied at a byte level.
1903
Third, we've optimized the conditional jump to a return instruction into a
1904
conditional return instruction.
1905
 
1906 68 dgisselq
\section{Example: Context Switch}
1907 36 dgisselq
 
1908
Fundamental to any multiprocessing system is the ability to switch from one
1909
task to the next.  In the ZipSystem, this is accomplished in one of a couple
1910
ways.  The first step is that an interrupt happens.  Anytime an interrupt
1911
happens, the CPU needs to execute the following tasks in supervisor mode:
1912
\begin{enumerate}
1913 69 dgisselq
\item Check for a trap instruction, or other user exception such as a break,
1914
        bus error, division by zero error, or floating point exception.  That
1915
        is, if the user process needs attending then we may not wish to adjust
1916
        the context, check interrupts, or call the scheduler.
1917
        Tbl.~\ref{tbl:trap-check}
1918 36 dgisselq
\begin{table}\begin{center}
1919
\begin{tabular}{ll}
1920
{\tt return\_to\_user:} \\
1921
&       {\em; The instruction before the context switch processing must} \\
1922
&       {\em; be the RTU instruction that enacted user mode in the first} \\
1923
&       {\em; place.  We show it here just for reference.} \\
1924
&       {\tt RTU} \\
1925
{\tt trap\_check:} \\
1926
&       {\tt MOV uCC,R0} \\
1927 69 dgisselq
&       {\tt TST \$TRAP \textbar \$BUSERR \textbar \$DIVE \textbar \$FPE,R0} \\
1928 36 dgisselq
&       {\tt BNZ swap\_out} \\
1929
&       {; \em Do something here to execute the trap} \\
1930
&       {; \em Don't need to call the scheduler, so we can just return} \\
1931
&       {\tt BRA return\_to\_user} \\
1932
\end{tabular}
1933 69 dgisselq
\caption{Checking for whether the user task needs our attention}\label{tbl:trap-check}
1934 36 dgisselq
\end{center}\end{table}
1935
        shows the rudiments of this code, while showing nothing of how the
1936
        actual trap would be implemented.
1937
 
1938
You may also wish to note that the instruction before the first instruction
1939
in our context swap {\em must be} a return to userspace instruction.
1940
Remember, the supervisor process is re--entered where it left off.  This is
1941
different from many other processors that enter interrupt mode at some vector
1942
or other.  In this case, we always enter supervisor mode right where we last
1943
left.\footnote{The one exception to this rule is upon reset where supervisor
1944
mode is entered at a pre--programmed wishbone memory address.}
1945
 
1946
\item Capture user counters.  If the operating system is keeping track of
1947
        system usage via the accounting counters, those counters need to be
1948
        copied and accumulated into some master counter at this point.
1949
 
1950
\item Preserve the old context.  This involves pushing all the user registers
1951
        onto the user stack and then copying the resulting stack address
1952
        into the tasks task structure, as shown in Tbl.~\ref{tbl:context-out}.
1953
\begin{table}\begin{center}
1954
\begin{tabular}{ll}
1955
{\tt swap\_out:} \\
1956 39 dgisselq
&        {\tt MOV -15(uSP),R5} \\
1957
&        {\tt STO R5,stack(R12)} \\
1958
&        {\tt MOV uR0,R0} \\
1959
&        {\tt MOV uR1,R1} \\
1960
&        {\tt MOV uR2,R2} \\
1961
&        {\tt MOV uR3,R3} \\
1962
&        {\tt MOV uR4,R4} \\
1963 69 dgisselq
&        {\tt STO R0,(R5)} {\em ; Exploit memory pipelining: }\\
1964
&        {\tt STO R1,1(R5)} {\em ; All instructions write to stack }\\
1965
&        {\tt STO R2,2(R5)} {\em ; All offsets increment by one }\\
1966
&        {\tt STO R3,3(R5)} {\em ; Longest pipeline is 5 cycles.}\\
1967
&        {\tt STO R4,4(R5)} \\
1968 39 dgisselq
        & \ldots {\em ; Need to repeat for all user registers} \\
1969
\iffalse
1970
&        {\tt MOV uR5,R0} \\
1971
&        {\tt MOV uR6,R1} \\
1972
&        {\tt MOV uR7,R2} \\
1973
&        {\tt MOV uR8,R3} \\
1974
&        {\tt MOV uR9,R4} \\
1975 69 dgisselq
&        {\tt STO R0,5(R5) }\\
1976
&        {\tt STO R1,6(R5) }\\
1977
&        {\tt STO R2,7(R5) }\\
1978
&        {\tt STO R3,8(R5) }\\
1979
&        {\tt STO R4,9(R5)} \\
1980 39 dgisselq
\fi
1981
&        {\tt MOV uR10,R0} \\
1982
&        {\tt MOV uR11,R1} \\
1983
&        {\tt MOV uR12,R2} \\
1984
&        {\tt MOV uCC,R3} \\
1985
&        {\tt MOV uPC,R4} \\
1986 69 dgisselq
&        {\tt STO R0,10(R5)}\\
1987
&        {\tt STO R1,11(R5)}\\
1988
&        {\tt STO R2,12(R5)}\\
1989
&        {\tt STO R3,13(R5)}\\
1990
&        {\tt STO R4,14(R5)} \\
1991 36 dgisselq
&       {\em ; We can skip storing the stack, uSP, since it'll be stored}\\
1992
&       {\em ; elsewhere (in the task structure) }\\
1993
\end{tabular}
1994
\caption{Example Storing User Task Context}\label{tbl:context-out}
1995
\end{center}\end{table}
1996
For the sake of discussion, we assume the supervisor maintains a
1997
pointer to the current task's structure in supervisor register
1998
{\tt R12}, and that {\tt stack} is an offset to the beginning of this
1999
structure indicating where the stack pointer is to be kept within it.
2000
 
2001
        For those who are still interested, the full code for this context
2002
        save can be found as an assembler macro within the assembler
2003
        include file, {\tt sys.i}.
2004
 
2005
\item Reset the watchdog timer.  If you are using the watchdog timer, it should
2006
        be reset on a context swap, to know that things are still working.
2007
        Example code for this is shown in Tbl.~\ref{tbl:reset-watchdog}.
2008
\begin{table}\begin{center}
2009
\begin{tabular}{ll}
2010
\multicolumn{2}{l}{{\tt `define WATCHDOG\_ADDRESS 32'hc000\_0002}}\\
2011
\multicolumn{2}{l}{{\tt `define WATCHDOG\_TICKS 32'd1\_000\_000} {; \em = 10 ms}}\\
2012
&       {\tt LDI WATCHDOG\_ADDRESS,R0} \\
2013
&       {\tt LDI WATCHDOG\_TICKS,R1} \\
2014
&       {\tt STO R1,(R0)}
2015
\end{tabular}
2016
\caption{Example Watchdog Reset}\label{tbl:reset-watchdog}
2017
\end{center}\end{table}
2018
 
2019
\item Interrupt handling.  An interrupt handler within the Zip System is nothing
2020
        more than a task.  At context swap time, the supervisor needs to
2021
        disable all of the interrupts that have tripped, and then enable
2022
        all of the tasks that would deal with each of these interrupts.
2023
        These can be user tasks, run at higher priority than any other user
2024
        tasks.  Either way, they will need to re--enable their own interrupt
2025
        themselves, if the interrupt is still relevant.
2026
 
2027
        An example of this master interrut handling is shown in
2028
        Tbl.~\ref{tbl:pre-handler}.
2029
\begin{table}\begin{center}
2030
\begin{tabular}{ll}
2031
{\tt pre\_handler:} \\
2032
&       {\tt LDI PIC\_ADDRESS,R0 } \\
2033
&       {\em ; Start by grabbing the interrupt state from the interrupt}\\
2034
&       {\em ; controller.  We'll store this into the register R7 so that }\\
2035
&       {\em ; we can keep and preserve this information for the scheduler}\\
2036
&       {\em ; to use later. }\\
2037
&       {\tt LOD (R0),R1} \\
2038
&       {\tt MOV R1,R7 } \\
2039
&       {\em ; As a next step, we need to acknowledge and disable all active}\\
2040
&       {\em ; interrupts. We'll start by calculating all of our active}\\
2041
&       {\em ; interrupts.}\\
2042
&       {\tt AND 0x07fff,R1 } \\
2043
&       {\em ; Put the active interrupts into the upper half of R1} \\
2044
&       {\tt ROL 16,R1 } \\
2045
&       {\tt LDILO 0x0ffff,R1   } \\
2046
&       {\tt AND R7,R1}\\
2047
&       {\em ; Acknowledge and disable active interrupts}\\
2048
&       {\em ; This also disables all interrupts from the controller, so}\\
2049
&       {\em ; we'll need to re-enable interrupts in general shortly } \\
2050
&       {\tt STO R1,(R0) } \\
2051
&       {\em ; We leave our active interrupt mask in R7 so the scheduler can}\\
2052
&       {\em ; release any tasks that depended upon them. } \\
2053
\end{tabular}
2054
\caption{Example checking for active interrupts}\label{tbl:pre-handler}
2055
\end{center}\end{table}
2056
 
2057
\item Calling the scheduler.  This needs to be done to pick the next task
2058
        to switch to.  It may be an interrupt handler, or it may  be a normal
2059
        user task.  From a priority standpoint, it would make sense that the
2060
        interrupt handlers all have a higher priority than the user tasks,
2061
        and that once they have been called the user tasks may then be called
2062
        again.  If no task is ready to run, run the idle task to wait for an
2063
        interrupt.
2064
 
2065
        This suggests a minimum of four task priorities:
2066
        \begin{enumerate}
2067
        \item Interrupt handlers, executed with their interrupts disabled
2068
        \item Device drivers, executed with interrupts re-enabled
2069
        \item User tasks
2070
        \item The idle task, executed when nothing else is able to execute
2071
        \end{enumerate}
2072
 
2073
        For our purposes here, we'll just assume that a pointer to the current
2074
        task is maintained in {\tt R12}, that a {\tt JSR scheduler} is
2075
        called, and that the next current task is likewise placed into
2076
        {\tt R12}.
2077
 
2078
\item Restore the new tasks context.  Given that the scheduler has returned a
2079
        task that can be run at this time, the stack pointer needs to be
2080
        pulled out of the tasks task structure, placed into the user
2081
        register, and then the rest of the user registers need to be popped
2082
        back off of the stack to run this task.  An example of this is
2083
        shown in Tbl.~\ref{tbl:context-in},
2084
\begin{table}\begin{center}
2085
\begin{tabular}{ll}
2086
{\tt swap\_in:} \\
2087 39 dgisselq
&       {\tt LOD stack(R12),R5} \\
2088 36 dgisselq
&       {\tt MOV 15(R1),uSP} \\
2089 39 dgisselq
        & {\em ; Be sure to exploit the memory pipelining capability} \\
2090 69 dgisselq
&       {\tt LOD (R5),R0} \\
2091
&       {\tt LOD 1(R5),R1} \\
2092
&       {\tt LOD 2(R5),R2} \\
2093
&       {\tt LOD 3(R5),R3} \\
2094
&       {\tt LOD 4(R5),R4} \\
2095 39 dgisselq
&       {\tt MOV R0,uR0} \\
2096
&       {\tt MOV R1,uR1} \\
2097
&       {\tt MOV R2,uR2} \\
2098
&       {\tt MOV R3,uR3} \\
2099
&       {\tt MOV R4,uR4} \\
2100 36 dgisselq
        & \ldots {\em ; Need to repeat for all user registers} \\
2101 69 dgisselq
&       {\tt LOD 10(R5),R0} \\
2102
&       {\tt LOD 11(R5),R1} \\
2103
&       {\tt LOD 12(R5),R2} \\
2104
&       {\tt LOD 13(R5),R3} \\
2105
&       {\tt LOD 14(R5),R4} \\
2106 39 dgisselq
&       {\tt MOV R0,uR10} \\
2107
&       {\tt MOV R1,uR11} \\
2108
&       {\tt MOV R2,uR12} \\
2109
&       {\tt MOV R3,uCC} \\
2110
&       {\tt MOV R4,uPC} \\
2111
 
2112 36 dgisselq
&       {\tt BRA return\_to\_user} \\
2113
\end{tabular}
2114
\caption{Example Restoring User Task Context}\label{tbl:context-in}
2115
\end{center}\end{table}
2116
        assuming as before that the task
2117
        pointer is found in supervisor register {\tt R12}.
2118
        As with storing the user context, the full code associated with
2119
        restoring the user context can be found in the assembler include
2120
        file, {\tt sys.i}.
2121
 
2122
\item Clear the userspace accounting registers.  In order to keep track of
2123
        per process system usage, these registers need to be cleared before
2124
        reactivating the userspace process.  That way, upon the next
2125
        interrupt, we'll know how many clocks the userspace program has
2126
        encountered, and how many instructions it was able to issue in
2127
        those many clocks.
2128
 
2129
\item Jump back to the instruction just before saving the last tasks context,
2130
        because that location in memory contains the return from interrupt
2131
        command that we are going to need to execute, in order to guarantee
2132
        that we return back here again.
2133
\end{enumerate}
2134
 
2135 21 dgisselq
\chapter{Registers}\label{chap:regs}
2136
 
2137 24 dgisselq
The ZipSystem registers fall into two categories, ZipSystem internal registers
2138
accessed via the ZipCPU shown in Tbl.~\ref{tbl:zpregs},
2139
\begin{table}[htbp]
2140
\begin{center}\begin{reglist}
2141 32 dgisselq
PIC   & \scalebox{0.8}{\tt 0xc0000000} & 32 & R/W & Primary Interrupt Controller \\\hline
2142
WDT   & \scalebox{0.8}{\tt 0xc0000001} & 32 & R/W & Watchdog Timer \\\hline
2143 69 dgisselq
  & \scalebox{0.8}{\tt 0xc0000002} & 32 & R & Address of last bus error \\\hline
2144 32 dgisselq
CTRIC & \scalebox{0.8}{\tt 0xc0000003} & 32 & R/W & Secondary Interrupt Controller \\\hline
2145
TMRA  & \scalebox{0.8}{\tt 0xc0000004} & 32 & R/W & Timer A\\\hline
2146
TMRB  & \scalebox{0.8}{\tt 0xc0000005} & 32 & R/W & Timer B\\\hline
2147
TMRC  & \scalebox{0.8}{\tt 0xc0000006} & 32 & R/W & Timer C\\\hline
2148
JIFF  & \scalebox{0.8}{\tt 0xc0000007} & 32 & R/W & Jiffies \\\hline
2149
MTASK  & \scalebox{0.8}{\tt 0xc0000008} & 32 & R/W & Master Task Clock Counter \\\hline
2150
MMSTL  & \scalebox{0.8}{\tt 0xc0000009} & 32 & R/W & Master Stall Counter \\\hline
2151
MPSTL  & \scalebox{0.8}{\tt 0xc000000a} & 32 & R/W & Master Pre--Fetch Stall Counter \\\hline
2152
MICNT  & \scalebox{0.8}{\tt 0xc000000b} & 32 & R/W & Master Instruction Counter\\\hline
2153
UTASK  & \scalebox{0.8}{\tt 0xc000000c} & 32 & R/W & User Task Clock Counter \\\hline
2154
UMSTL  & \scalebox{0.8}{\tt 0xc000000d} & 32 & R/W & User Stall Counter \\\hline
2155
UPSTL  & \scalebox{0.8}{\tt 0xc000000e} & 32 & R/W & User Pre--Fetch Stall Counter \\\hline
2156
UICNT  & \scalebox{0.8}{\tt 0xc000000f} & 32 & R/W & User Instruction Counter\\\hline
2157 36 dgisselq
DMACTRL  & \scalebox{0.8}{\tt 0xc0000010} & 32 & R/W & DMA Control Register\\\hline
2158
DMALEN  & \scalebox{0.8}{\tt 0xc0000011} & 32 & R/W & DMA total transfer length\\\hline
2159
DMASRC  & \scalebox{0.8}{\tt 0xc0000012} & 32 & R/W & DMA source address\\\hline
2160
DMADST  & \scalebox{0.8}{\tt 0xc0000013} & 32 & R/W & DMA destination address\\\hline
2161 32 dgisselq
% Cache  & \scalebox{0.8}{\tt 0xc0100000} & & & Base address of the Cache memory\\\hline
2162 24 dgisselq
\end{reglist}
2163
\caption{Zip System Internal/Peripheral Registers}\label{tbl:zpregs}
2164
\end{center}\end{table}
2165 33 dgisselq
and the two debug registers shown in Tbl.~\ref{tbl:dbgregs}.
2166 24 dgisselq
\begin{table}[htbp]
2167
\begin{center}\begin{reglist}
2168
ZIPCTRL & 0 & 32 & R/W & Debug Control Register \\\hline
2169
ZIPDATA & 1 & 32 & R/W & Debug Data Register \\\hline
2170
\end{reglist}
2171
\caption{Zip System Debug Registers}\label{tbl:dbgregs}
2172
\end{center}\end{table}
2173
 
2174 33 dgisselq
\section{Peripheral Registers}
2175
The peripheral registers, listed in Tbl.~\ref{tbl:zpregs}, are shown in the
2176
CPU's address space.  These may be accessed by the CPU at these addresses,
2177
and when so accessed will respond as described in Chapt.~\ref{chap:periph}.
2178
These registers will be discussed briefly again here.
2179 24 dgisselq
 
2180 69 dgisselq
\subsection{Interrupt Controller(s)}
2181 33 dgisselq
The Zip CPU Interrupt controller has four different types of bits, as shown in
2182
Tbl.~\ref{tbl:picbits}.
2183
\begin{table}\begin{center}
2184
\begin{bitlist}
2185
31 & R/W & Master Interrupt Enable\\\hline
2186 69 dgisselq
30\ldots 16 & R/W & Interrupt Enables, write `1' to change\\\hline
2187 33 dgisselq
15 & R & Current Master Interrupt State\\\hline
2188 69 dgisselq
15\ldots 0 & R/W & Input Interrupt states, write `1' to clear\\\hline
2189 33 dgisselq
\end{bitlist}
2190
\caption{Interrupt Controller Register Bits}\label{tbl:picbits}
2191
\end{center}\end{table}
2192
The high order bit, or bit--31, is the master interrupt enable bit.  When this
2193
bit is set, then any time an interrupt occurs the CPU will be interrupted and
2194
will switch to supervisor mode, etc.
2195
 
2196
Bits 30~\ldots 16 are interrupt enable bits.  Should the interrupt line go
2197 69 dgisselq
hi while enabled, an interrupt will be generated.  (All interrupts are positive
2198
edge triggered.)  To set an interrupt enable bit, one needs to write the
2199
master interrupt enable while writing a `1' to this the bit.  To clear, one
2200
need only write a `0' to the master interrupt enable, while leaving this line
2201
high.
2202 33 dgisselq
 
2203
Bits 15\ldots 0 are the current state of the interrupt vector.  Interrupt lines
2204
trip when they go high, and remain tripped until they are acknowledged.  If
2205
the interrupt goes high for longer than one pulse, it may be high when a clear
2206
is requested.  If so, the interrupt will not clear.  The line must go low
2207
again before the status bit can be cleared.
2208
 
2209
As an example, consider the following scenario where the Zip CPU supports four
2210
interrupts, 3\ldots0.
2211
\begin{enumerate}
2212
\item The Supervisor will first, while in the interrupts disabled mode,
2213
        write a {\tt 32'h800f000f} to the controller.  The supervisor may then
2214
        switch to the user state with interrupts enabled.
2215
\item When an interrupt occurs, the supervisor will switch to the interrupt
2216
        state.  It will then cycle through the interrupt bits to learn which
2217
        interrupt handler to call.
2218
\item If the interrupt handler expects more interrupts, it will clear its
2219
        current interrupt when it is done handling the interrupt in question.
2220 69 dgisselq
        To do this, it will write a `1' to the low order interrupt mask,
2221
        such as writing a {\tt 32'h0000\_0001}.
2222 33 dgisselq
\item If the interrupt handler does not expect any more interrupts, it will
2223
        instead clear the interrupt from the controller by writing a
2224 69 dgisselq
        {\tt 32'h0001\_0001} to the controller.
2225 33 dgisselq
\item Once all interrupts have been handled, the supervisor will write a
2226 69 dgisselq
        {\tt 32'h8000\_0000} to the interrupt register to re-enable interrupt
2227 33 dgisselq
        generation.
2228
\item The supervisor should also check the user trap bit, and possible soft
2229
        interrupt bits here, but this action has nothing to do with the
2230
        interrupt control register.
2231
\item The supervisor will then leave interrupt mode, possibly adjusting
2232
        whichever task is running, by executing a return from interrupt
2233
        command.
2234
\end{enumerate}
2235
 
2236 69 dgisselq
\subsection{Timer Register}
2237
 
2238 33 dgisselq
Leaving the interrupt controller, we show the timer registers bit definitions
2239
in Tbl.~\ref{tbl:tmrbits}.
2240
\begin{table}\begin{center}
2241
\begin{bitlist}
2242
31 & R/W & Auto-Reload\\\hline
2243
30\ldots 0 & R/W & Current timer value\\\hline
2244
\end{bitlist}
2245
\caption{Timer Register Bits}\label{tbl:tmrbits}
2246
\end{center}\end{table}
2247
As you may recall, the timer just counts down to zero and then trips an
2248
interrupt.  Writing to the current timer value sets that value, and reading
2249
from it returns that value.  Writing to the current timer value while also
2250
setting the auto--reload bit will send the timer into an auto--reload mode.
2251
In this mode, upon setting its interrupt bit for one cycle, the timer will
2252
also reset itself back to the value of the timer that was written to it when
2253
the auto--reload option was written to it.  To clear and stop the timer,
2254
just simply write a `32'h00' to this register.
2255
 
2256 69 dgisselq
\subsection{Jiffies}
2257
 
2258 33 dgisselq
The Jiffies register is somewhat similar in that the register always changes.
2259
In this case, the register counts up, whereas the timer always counted down.
2260
Reads from this register, as shown in Tbl.~\ref{tbl:jiffybits},
2261
\begin{table}\begin{center}
2262
\begin{bitlist}
2263
31\ldots 0 & R & Current jiffy value\\\hline
2264
31\ldots 0 & W & Value/time of next interrupt\\\hline
2265
\end{bitlist}
2266
\caption{Jiffies Register Bits}\label{tbl:jiffybits}
2267
\end{center}\end{table}
2268
always return the time value contained in the register.  Writes greater than
2269
the current Jiffy value, that is where the new value minus the old value is
2270
greater than zero while ignoring truncation, will set a new Jiffy interrupt
2271
time.  At that time, the Jiffy vector will clear, and another interrupt time
2272
may either be written to it, or it will just continue counting without
2273
activating any more interrupts.
2274
 
2275 69 dgisselq
\subsection{Performance Counters}
2276
 
2277 33 dgisselq
The Zip CPU also supports several counter peripherals, mostly in the way of
2278
process accounting.  This peripherals have a single register associated with
2279
them, shown in Tbl.~\ref{tbl:ctrbits}.
2280
\begin{table}\begin{center}
2281
\begin{bitlist}
2282
31\ldots 0 & R/W & Current counter value\\\hline
2283
\end{bitlist}
2284
\caption{Counter Register Bits}\label{tbl:ctrbits}
2285
\end{center}\end{table}
2286
Writes to this register set the new counter value.  Reads read the current
2287
counter value.
2288
 
2289
The current design operation of these counters is that of performance counting.
2290
Two sets of four registers are available for keeping track of performance.
2291
The first is a task counter.  This just counts clock ticks.  The second
2292
counter is a prefetch stall counter, then an master stall counter.  These
2293
allow the CPU to be evaluated as to how efficient it is.  The fourth and
2294
final counter is an instruction counter, which counts how many instructions the
2295
CPU has issued.
2296
 
2297
It is envisioned that these counters will be used as follows: First, every time
2298
a master counter rolls over, the supervisor (Operating System) will record
2299
the fact.  Second, whenever activating a user task, the Operating System will
2300
set the four user counters to zero.  When the user task has completed, the
2301
Operating System will read the timers back off, to determine how much of the
2302 69 dgisselq
CPU the process had consumed.  To keep this accurate, the user counters will
2303
only increment when the GIE bit is set to indicate that the processor is
2304
in user mode.
2305 33 dgisselq
 
2306 69 dgisselq
\subsection{DMA Controller}
2307
 
2308 36 dgisselq
The final peripheral to discuss is the DMA controller.  This controller
2309
has four registers.  Of these four, the length, source and destination address
2310
registers should need no further explanation.  They are full 32--bit registers
2311
specifying the entire transfer length, the starting address to read from, and
2312
the starting address to write to.  The registers can be written to when the
2313
DMA is idle, and read at any time.  The control register, however, will need
2314
some more explanation.
2315
 
2316
The bit allocation of the control register is shown in Tbl.~\ref{tbl:dmacbits}.
2317
\begin{table}\begin{center}
2318
\begin{bitlist}
2319
31 & R & DMA Active\\\hline
2320 39 dgisselq
30 & R & Wishbone error, transaction aborted.  This bit is cleared the next time
2321
        this register is written to.\\\hline
2322 69 dgisselq
29 & R/W & Set to `1' to prevent the controller from incrementing the source address, `0' for normal memory copy. \\\hline
2323
28 & R/W & Set to `1' to prevent the controller from incrementing the
2324
        destination address, `0' for normal memory copy. \\\hline
2325 36 dgisselq
27 \ldots 16 & W & The DMA Key.  Write a 12'hfed to these bits to start the
2326
        activate any DMA transfer.  \\\hline
2327 69 dgisselq
27 & R & Always reads `0', to force the deliberate writing of the key. \\\hline
2328 36 dgisselq
26 \ldots 16 & R & Indicates the number of items in the transfer buffer that
2329
        have yet to be written. \\\hline
2330 69 dgisselq
15 & R/W & Set to `1' to trigger on an interrupt, or `0' to start immediately
2331 36 dgisselq
        upon receiving a valid key.\\\hline
2332
14\ldots 10 & R/W & Select among one of 32~possible interrupt lines.\\\hline
2333
9\ldots 0 & R/W & Intermediate transfer length minus one.  Thus, to transfer
2334
        one item at a time set this value to 0. To transfer 1024 at a time,
2335
        set it to 1024.\\\hline
2336
\end{bitlist}
2337
\caption{DMA Control Register Bits}\label{tbl:dmacbits}
2338
\end{center}\end{table}
2339
This control register has been designed so that the common case of memory
2340
access need only set the key and the transfer length.  Hence, writing a
2341
\hbox{32'h0fed03ff} to the control register will start any memory transfer.
2342
On the other hand, if you wished to read from a serial port (constant address)
2343
and put the result into a buffer every time a word was available, you
2344
might wish to write \hbox{32'h2fed8000}--this assumes, of course, that you
2345
have a serial port wired to the zero bit of this interrupt control.  (The
2346
DMA controller does not use the interrupt controller, and cannot clear
2347
interrupts.)  As a third example, if you wished to write to an external
2348
FIFO anytime it was less than half full (had fewer than 512 items), and
2349
interrupt line 2 indicated this condition, you might wish to issue a
2350
\hbox{32'h1fed8dff} to this port.
2351
 
2352 33 dgisselq
\section{Debug Port Registers}
2353
Accessing the Zip System via the debug port isn't as straight forward as
2354
accessing the system via the wishbone bus.  The debug port itself has been
2355
reduced to two addresses, as outlined earlier in Tbl.~\ref{tbl:dbgregs}.
2356
Access to the Zip System begins with the Debug Control register, shown in
2357
Tbl.~\ref{tbl:dbgctrl}.
2358
\begin{table}\begin{center}
2359
\begin{bitlist}
2360 69 dgisselq
31\ldots 14 & R & External interrupt state.  Bit 14 is valid for one
2361
        interrupt only, bit 15 for two, etc.\\\hline
2362 33 dgisselq
13 & R & CPU GIE setting\\\hline
2363
12 & R & CPU is sleeping\\\hline
2364
11 & W & Command clear PF cache\\\hline
2365 69 dgisselq
10 & R/W & Command HALT, Set to `1' to halt the CPU\\\hline
2366
9 & R & Stall Status, `1' if CPU is busy (i.e., not halted yet)\\\hline
2367
8 & R/W & Step Command, set to `1' to step the CPU, also sets the halt bit\\\hline
2368
7 & R & Interrupt Request Pending\\\hline
2369 33 dgisselq
6 & R/W & Command RESET \\\hline
2370
5\ldots 0 & R/W & Debug Register Address \\\hline
2371
\end{bitlist}
2372
\caption{Debug Control Register Bits}\label{tbl:dbgctrl}
2373
\end{center}\end{table}
2374
 
2375
The first step in debugging access is to determine whether or not the CPU
2376 69 dgisselq
is halted, and to halt it if not.  To do this, first write a `1' to the
2377 33 dgisselq
Command HALT bit.  This will halt the CPU and place it into debug mode.
2378
Once the CPU is halted, the stall status bit will drop to zero.  Thus,
2379
if bit 10 is high and bit 9 low, the debug port is open to examine the
2380
internal state of the CPU.
2381
 
2382
At this point, the external debugger may examine internal state information
2383
from within the CPU.  To do this, first write again to the command register
2384
a value (with command halt still high) containing the address of an internal
2385
register of interest in the bottom 6~bits.  Internal registers that may be
2386
accessed this way are listed in Tbl.~\ref{tbl:dbgaddrs}.
2387
\begin{table}\begin{center}
2388
\begin{reglist}
2389
sR0 & 0 & 32 & R/W & Supervisor Register R0 \\\hline
2390
sR1 & 0 & 32 & R/W & Supervisor Register R1 \\\hline
2391
sSP & 13 & 32 & R/W & Supervisor Stack Pointer\\\hline
2392
sCC & 14 & 32 & R/W & Supervisor Condition Code Register \\\hline
2393
sPC & 15 & 32 & R/W & Supervisor Program Counter\\\hline
2394
uR0 & 16 & 32 & R/W & User Register R0 \\\hline
2395
uR1 & 17 & 32 & R/W & User Register R1 \\\hline
2396
uSP & 29 & 32 & R/W & User Stack Pointer\\\hline
2397
uCC & 30 & 32 & R/W & User Condition Code Register \\\hline
2398
uPC & 31 & 32 & R/W & User Program Counter\\\hline
2399
PIC & 32 & 32 & R/W & Primary Interrupt Controller \\\hline
2400
WDT & 33 & 32 & R/W & Watchdog Timer\\\hline
2401 69 dgisselq
BUS & 34 & 32 & R & Last Bus Error\\\hline
2402 33 dgisselq
CTRIC & 35 & 32 & R/W & Secondary Interrupt Controller\\\hline
2403
TMRA & 36 & 32 & R/W & Timer A\\\hline
2404
TMRB & 37 & 32 & R/W & Timer B\\\hline
2405
TMRC & 38 & 32 & R/W & Timer C\\\hline
2406
JIFF & 39 & 32 & R/W & Jiffies peripheral\\\hline
2407
MTASK & 40 & 32 & R/W & Master task clock counter\\\hline
2408
MMSTL & 41 & 32 & R/W & Master memory stall counter\\\hline
2409
MPSTL & 42 & 32 & R/W & Master Pre-Fetch Stall counter\\\hline
2410
MICNT & 43 & 32 & R/W & Master instruction counter\\\hline
2411
UTASK & 44 & 32 & R/W & User task clock counter\\\hline
2412
UMSTL & 45 & 32 & R/W & User memory stall counter\\\hline
2413
UPSTL & 46 & 32 & R/W & User Pre-Fetch Stall counter\\\hline
2414
UICNT & 47 & 32 & R/W & User instruction counter\\\hline
2415 39 dgisselq
DMACMD & 48 & 32 & R/W & DMA command and status register\\\hline
2416
DMALEN & 49 & 32 & R/W & DMA transfer length\\\hline
2417
DMARD & 50 & 32 & R/W & DMA read address\\\hline
2418
DMAWR & 51 & 32 & R/W & DMA write address\\\hline
2419 33 dgisselq
\end{reglist}
2420
\caption{Debug Register Addresses}\label{tbl:dbgaddrs}
2421
\end{center}\end{table}
2422
Primarily, these ``registers'' include access to the entire CPU register
2423 36 dgisselq
set, as well as the internal peripherals.  To read one of these registers
2424 33 dgisselq
once the address is set, simply issue a read from the data port.  To write
2425
one of these registers or peripheral ports, simply write to the data port
2426
after setting the proper address.
2427
 
2428
In this manner, all of the CPU's internal state may be read and adjusted.
2429
 
2430
As an example of how to use this, consider what would happen in the case
2431
of an external break point.  If and when the CPU hits a break point that
2432
causes it to halt, the Command HALT bit will activate on its own, the CPU
2433
will then raise an external interrupt line and wait for a debugger to examine
2434
its state.  After examining the state, the debugger will need to remove
2435
the breakpoint by writing a different instruction into memory and by writing
2436
to the command register while holding the clear cache, command halt, and
2437
step CPU bits high, (32'hd00).  The debugger may then replace the breakpoint
2438
now that the CPU has gone beyond it, and clear the cache again (32'h500).
2439
 
2440
To leave this debug mode, simply write a `32'h0' value to the command register.
2441
 
2442
\chapter{Wishbone Datasheets}\label{chap:wishbone}
2443 32 dgisselq
The Zip System supports two wishbone ports, a slave debug port and a master
2444 21 dgisselq
port for the system itself.  These are shown in Tbl.~\ref{tbl:wishbone-slave}
2445
\begin{table}[htbp]
2446
\begin{center}
2447
\begin{wishboneds}
2448
Revision level of wishbone & WB B4 spec \\\hline
2449
Type of interface & Slave, Read/Write, single words only \\\hline
2450 24 dgisselq
Address Width & 1--bit \\\hline
2451 21 dgisselq
Port size & 32--bit \\\hline
2452
Port granularity & 32--bit \\\hline
2453
Maximum Operand Size & 32--bit \\\hline
2454
Data transfer ordering & (Irrelevant) \\\hline
2455 69 dgisselq
Clock constraints & Works at 100~MHz on a Basys--3 board, and 80~MHz on a
2456
                XuLA2--LX25\\\hline
2457 21 dgisselq
Signal Names & \begin{tabular}{ll}
2458
                Signal Name & Wishbone Equivalent \\\hline
2459
                {\tt i\_clk} & {\tt CLK\_I} \\
2460
                {\tt i\_dbg\_cyc} & {\tt CYC\_I} \\
2461
                {\tt i\_dbg\_stb} & {\tt STB\_I} \\
2462
                {\tt i\_dbg\_we} & {\tt WE\_I} \\
2463
                {\tt i\_dbg\_addr} & {\tt ADR\_I} \\
2464
                {\tt i\_dbg\_data} & {\tt DAT\_I} \\
2465
                {\tt o\_dbg\_ack} & {\tt ACK\_O} \\
2466
                {\tt o\_dbg\_stall} & {\tt STALL\_O} \\
2467
                {\tt o\_dbg\_data} & {\tt DAT\_O}
2468
                \end{tabular}\\\hline
2469
\end{wishboneds}
2470 22 dgisselq
\caption{Wishbone Datasheet for the Debug Interface}\label{tbl:wishbone-slave}
2471 21 dgisselq
\end{center}\end{table}
2472
and Tbl.~\ref{tbl:wishbone-master} respectively.
2473
\begin{table}[htbp]
2474
\begin{center}
2475
\begin{wishboneds}
2476
Revision level of wishbone & WB B4 spec \\\hline
2477 24 dgisselq
Type of interface & Master, Read/Write, single cycle or pipelined\\\hline
2478 69 dgisselq
Address Width & (Zip System parameter, can be up to 32--bit bits) \\\hline
2479 21 dgisselq
Port size & 32--bit \\\hline
2480
Port granularity & 32--bit \\\hline
2481
Maximum Operand Size & 32--bit \\\hline
2482
Data transfer ordering & (Irrelevant) \\\hline
2483 69 dgisselq
Clock constraints & Works at 100~MHz on a Basys--3 board, and 80~MHz on a
2484
                XuLA2--LX25\\\hline
2485 21 dgisselq
Signal Names & \begin{tabular}{ll}
2486
                Signal Name & Wishbone Equivalent \\\hline
2487
                {\tt i\_clk} & {\tt CLK\_O} \\
2488
                {\tt o\_wb\_cyc} & {\tt CYC\_O} \\
2489
                {\tt o\_wb\_stb} & {\tt STB\_O} \\
2490
                {\tt o\_wb\_we} & {\tt WE\_O} \\
2491
                {\tt o\_wb\_addr} & {\tt ADR\_O} \\
2492
                {\tt o\_wb\_data} & {\tt DAT\_O} \\
2493
                {\tt i\_wb\_ack} & {\tt ACK\_I} \\
2494
                {\tt i\_wb\_stall} & {\tt STALL\_I} \\
2495 69 dgisselq
                {\tt i\_wb\_data} & {\tt DAT\_I} \\
2496
                {\tt i\_wb\_err} & {\tt ERR\_I}
2497 21 dgisselq
                \end{tabular}\\\hline
2498
\end{wishboneds}
2499 22 dgisselq
\caption{Wishbone Datasheet for the CPU as Master}\label{tbl:wishbone-master}
2500 21 dgisselq
\end{center}\end{table}
2501
I do not recommend that you connect these together through the interconnect.
2502 24 dgisselq
Rather, the debug port of the CPU should be accessible regardless of the state
2503
of the master bus.
2504 21 dgisselq
 
2505 69 dgisselq
You may wish to notice that neither the {\tt LOCK} nor the {\tt RTY} (retry)
2506
wires have been connected to the CPU's master interface.  If necessary, a
2507
rudimentary {\tt LOCK} may be created by tying the wire to the {\tt wb\_cyc}
2508
line.  As for the {\tt RTY}, all the CPU recognizes at this point are bus
2509
errors---it cannot tell the difference between a temporary and a permanent bus
2510
error.
2511 21 dgisselq
 
2512
\chapter{Clocks}\label{chap:clocks}
2513
 
2514 32 dgisselq
This core is based upon the Basys--3 development board sold by Digilent.
2515
The Basys--3 development board contains one external 100~MHz clock, which is
2516 36 dgisselq
sufficient to run the Zip CPU core.
2517 21 dgisselq
\begin{table}[htbp]
2518
\begin{center}
2519
\begin{clocklist}
2520
i\_clk & External & 100~MHz & 100~MHz & System clock.\\\hline
2521
\end{clocklist}
2522
\caption{List of Clocks}\label{tbl:clocks}
2523
\end{center}\end{table}
2524
I hesitate to suggest that the core can run faster than 100~MHz, since I have
2525
had struggled with various timing violations to keep it at 100~MHz.  So, for
2526
now, I will only state that it can run at 100~MHz.
2527
 
2528 69 dgisselq
On a SPARTAN 6, the clock can run successfully at 80~MHz.
2529 21 dgisselq
 
2530
\chapter{I/O Ports}\label{chap:ioports}
2531 33 dgisselq
The I/O ports to the Zip CPU may be grouped into three categories.  The first
2532
is that of the master wishbone used by the CPU, then the slave wishbone used
2533
to command the CPU via a debugger, and then the rest.  The first two of these
2534
were already discussed in the wishbone chapter.  They are listed here
2535
for completeness in Tbl.~\ref{tbl:iowb-master}
2536
\begin{table}
2537
\begin{center}\begin{portlist}
2538
{\tt o\_wb\_cyc}   &  1 & Output & Indicates an active Wishbone cycle\\\hline
2539
{\tt o\_wb\_stb}   &  1 & Output & WB Strobe signal\\\hline
2540
{\tt o\_wb\_we}    &  1 & Output & Write enable\\\hline
2541
{\tt o\_wb\_addr}  & 32 & Output & Bus address \\\hline
2542
{\tt o\_wb\_data}  & 32 & Output & Data on WB write\\\hline
2543
{\tt i\_wb\_ack}   &  1 & Input  & Slave has completed a R/W cycle\\\hline
2544
{\tt i\_wb\_stall} &  1 & Input  & WB bus slave not ready\\\hline
2545
{\tt i\_wb\_data}  & 32 & Input  & Incoming bus data\\\hline
2546 69 dgisselq
{\tt i\_wb\_err}   &  1 & Input  & Bus Error indication\\\hline
2547 33 dgisselq
\end{portlist}\caption{CPU Master Wishbone I/O Ports}\label{tbl:iowb-master}\end{center}\end{table}
2548
and~\ref{tbl:iowb-slave} respectively.
2549
\begin{table}
2550
\begin{center}\begin{portlist}
2551
{\tt i\_wb\_cyc}   &  1 & Input & Indicates an active Wishbone cycle\\\hline
2552
{\tt i\_wb\_stb}   &  1 & Input & WB Strobe signal\\\hline
2553
{\tt i\_wb\_we}    &  1 & Input & Write enable\\\hline
2554
{\tt i\_wb\_addr}  &  1 & Input & Bus address, command or data port \\\hline
2555
{\tt i\_wb\_data}  & 32 & Input & Data on WB write\\\hline
2556
{\tt o\_wb\_ack}   &  1 & Output  & Slave has completed a R/W cycle\\\hline
2557
{\tt o\_wb\_stall} &  1 & Output  & WB bus slave not ready\\\hline
2558
{\tt o\_wb\_data}  & 32 & Output  & Incoming bus data\\\hline
2559
\end{portlist}\caption{CPU Debug Wishbone I/O Ports}\label{tbl:iowb-slave}\end{center}\end{table}
2560 21 dgisselq
 
2561 33 dgisselq
There are only four other lines to the CPU: the external clock, external
2562
reset, incoming external interrupt line(s), and the outgoing debug interrupt
2563
line.  These are shown in Tbl.~\ref{tbl:ioports}.
2564
\begin{table}
2565
\begin{center}\begin{portlist}
2566
{\tt i\_clk} & 1 & Input & The master CPU clock \\\hline
2567
{\tt i\_rst} & 1 & Input &  Active high reset line \\\hline
2568 69 dgisselq
{\tt i\_ext\_int} & 1\ldots 16 & Input &  Incoming external interrupts, actual
2569
                value set by implementation parameter \\\hline
2570 33 dgisselq
{\tt o\_ext\_int} & 1 & Output & CPU Halted interrupt \\\hline
2571
\end{portlist}\caption{I/O Ports}\label{tbl:ioports}\end{center}\end{table}
2572
The clock line was discussed briefly in Chapt.~\ref{chap:clocks}.  We
2573 69 dgisselq
typically run it at 100~MHz, although we've needed to slow it down to 80~MHz
2574
for some implementations.  The reset line is an active high reset.  When
2575 33 dgisselq
asserted, the CPU will start running again from its reset address in
2576 69 dgisselq
memory.  Further, depending upon how the CPU is configured and specifically
2577
based upon how the {\tt START\_HALTED} parameter is set, the CPU may or may
2578
not start running automatically following a reset.  The {\tt i\_ext\_int}
2579
line is for an external interrupt.  This line may actually be as wide as
2580
16~external interrupts, depending upon the setting of
2581
the {\tt EXTERNAL\_INTERRUPTS} parameter.  Finally, the Zip System produces one
2582
external interrupt whenever the entire CPU halts to wait for the debugger.
2583 33 dgisselq
 
2584 36 dgisselq
\chapter{Initial Assessment}\label{chap:assessment}
2585
 
2586
Having now worked with the Zip CPU for a while, it is worth offering an
2587
honest assessment of how well it works and how well it was designed. At the
2588
end of this assessment, I will propose some changes that may take place in a
2589
later version of this Zip CPU to make it better.
2590
 
2591
\section{The Good}
2592
\begin{itemize}
2593 69 dgisselq
\item The Zip CPU can be configured to be relatively light weight and fully
2594
        featured as it exists today. For anyone who wishes to build a general
2595
        purpose CPU and then to experiment with building and adding particular
2596
        features, the Zip CPU makes a good starting point--it is fairly simple.
2597
        Modifications should be simple enough.  Indeed, a non--pipelined
2598
        version of the bare ZipBones (with no peripherals) has been built that
2599
        only uses 1.1k~LUTs.  When using pipelining, the full cache, and all
2600
        of the peripherals, the ZipSystem can top 5~k LUTs.  Where it fits
2601
        in between is a function of your needs.
2602 36 dgisselq
\item The Zip CPU was designed to be an implementable soft core that could be
2603
        placed within an FPGA, controlling actions internal to the FPGA. It
2604
        fits this role rather nicely. It does not fit the role of a system on
2605
        a chip very well, but then it was never intended to be a system on a
2606
        chip but rather a system within a chip.
2607
\item The extremely simplified instruction set of the Zip CPU was a good
2608
        choice. Although it does not have many of the commonly used
2609
        instructions, PUSH, POP, JSR, and RET among them, the simplified
2610
        instruction set has demonstrated an amazing versatility. I will contend
2611
        therefore and for anyone who will listen, that this instruction set
2612
        offers a full and complete capability for whatever a user might wish
2613
        to do with two exceptions: bytewise character access and accelerated
2614
        floating-point support.
2615
\item This simplified instruction set is easy to decode.
2616
\item The simplified bus transactions (32-bit words only) were also very easy
2617
        to implement.
2618 68 dgisselq
\item The pipelined load/store approach is novel, and can be used to greatly
2619
        increase the speed of the processor.
2620 36 dgisselq
\item The novel approach of having a single interrupt vector, which just
2621
        brings the CPU back to the instruction it left off at within the last
2622
        interrupt context doesn't appear to have been that much of a problem.
2623
        If most modern systems handle interrupt vectoring in software anyway,
2624
        why maintain hardware support for it?
2625
\item My goal of a high rate of instructions per clock may not be the proper
2626
        measure. For example, if instructions are being read from a SPI flash
2627
        device, such as is common among FPGA implementations, these same
2628
        instructions may suffer stalls of between 64 and 128 cycles per
2629
        instruction just to read the instruction from the flash. Executing the
2630
        instruction in a single clock cycle is no longer the appropriate
2631
        measure. At the same time, it should be possible to use the DMA
2632
        peripheral to copy instructions from the FLASH to a temporary memory
2633
        location, after which they may be executed at a single instruction
2634
        cycle per access again.
2635
\end{itemize}
2636
 
2637
\section{The Not so Good}
2638
\begin{itemize}
2639
\item The CPU has no character support. This is both good and bad.
2640
        Realistically, the CPU works just fine without it. Characters can be
2641
        supported as subsets of 32-bit words without any problem. Practically,
2642
        though, it will make compiling non-Zip CPU code difficult--especially
2643
        anything that assumes sizeof(int)=4*sizeof(char), or that tries to
2644
        create unions with characters and integers and then attempts to
2645
        reference the address of the characters within that union.
2646
 
2647
\item The Zip CPU does not support a data cache. One can still be built
2648
        externally, but this is a limitation of the CPU proper as built.
2649
        Further, under the theory of the Zip CPU design (that of an embedded
2650
        soft-core processor within an FPGA, where any ``address'' may reference
2651
        either memory or a peripheral that may have side-effects), any data
2652
        cache would need to be based upon an initial knowledge of whether or
2653
        not it is supporting memory (cachable) or peripherals. This knowledge
2654
        must exist somewhere, and that somewhere is currently (and by design)
2655
        external to the CPU.
2656
 
2657
        This may also be written off as a ``feature'' of the Zip CPU, since
2658
        the addition of a data cache can greatly increase the LUT count of
2659
        a soft core.
2660
 
2661 68 dgisselq
        The Zip CPU compensates for this via its pipelined load and store
2662
        instructions.
2663
 
2664 36 dgisselq
\item Many other instruction sets offer three operand instructions, whereas
2665
        the Zip CPU only offers two operand instructions. This means that it
2666
        takes the Zip CPU more instructions to do many of the same operations.
2667
        The good part of this is that it gives the Zip CPU a greater amount of
2668
        flexibility in its immediate operand mode, although that increased
2669
        flexibility isn't necessarily as valuable as one might like.
2670
 
2671
\item The Zip CPU doesn't support out of order execution. I suppose it could
2672
        be modified to do so, but then it would no longer be the ``simple''
2673
        and low LUT count CPU it was designed to be. The two primary results
2674
        are that 1) loads may unnecessarily stall the CPU, even if other
2675
        things could be done while waiting for the load to complete, 2)
2676
        bus errors on stores will never be caught at the point of the error,
2677
        and 3) branch prediction becomes more difficult.
2678
 
2679
\item Although switching to an interrupt context in the Zip CPU design doesn't
2680
        require a tremendous swapping of registers, in reality it still
2681
        does--since any task swap still requires saving and restoring all
2682
        16~user registers. That's a lot of memory movement just to service
2683
        an interrupt.
2684
 
2685
\item The Zip CPU is by no means generic: it will never handle addresses
2686
        larger than 32-bits (16GB) without a complete and total redesign.
2687
        This may limit its utility as a generic CPU in the future, although
2688
        as an embedded CPU within an FPGA this isn't really much of a limit
2689
        or restriction.
2690
 
2691
\item While the Zip CPU has its own assembler, it has no linker and does not
2692
        (yet) support a compiler. The standard C library is an even longer
2693
        shot. My dream of having binutils and gcc support has not been
2694
        realized and at this rate may not be realized. (I've been intimidated
2695
        by the challenge everytime I've looked through those codes.)
2696
\end{itemize}
2697
 
2698
\section{The Next Generation}
2699 69 dgisselq
This section could also be labeled as my ``To do'' list.  Today's list is
2700
much different than it was for the last version of this document, as much of
2701
the prior to do list (such as VLIW instructions, and a more traditional
2702
instruction cache) has now been implemented.  The only things really and
2703
truly waiting on my list today are assembler support for the VLIW instruction
2704
set, linker and compiler support.
2705 36 dgisselq
 
2706 69 dgisselq
Stay tuned, these are likely to be coming next.
2707 36 dgisselq
 
2708 21 dgisselq
% Appendices
2709
% Index
2710
\end{document}
2711
 
2712 68 dgisselq
%
2713
%
2714
% Symbol table relocation types:
2715
%
2716
% Only 3-types of instructions truly need relocations: those that modify the
2717
% PC register, and those that access memory.
2718
%
2719
% -     LDI     Addr,Rx         // Load's an absolute address into Rx, 24 bits
2720
%
2721
% -     LDILO   Addr,Rx         // Load's an absolute address into Rx, 32 bits
2722
%       LDIHI   Addr,Rx         //   requires two instructions
2723
%
2724
% -     JMP     Rx              // Jump to any address in Rx
2725
%                       // Can be prefixed with two instructions to load Rx
2726
%                       // from any 32-bit immediate
2727
% -     JMP     #Addr           // Jump to any 24'bit (signed) address, 23'b uns
2728
%
2729
% -     ADD     x,PC            // Any PC relative jump (20 bits)
2730
%
2731
% -     ADD.C   x,PC            // Any PC relative conditional jump (20 bits)
2732
%
2733
% -     LDIHI   Addr,Rx         // Load from any 32-bit address, clobbers Rx,
2734
%       LOD     Addr(Rx),Rx     //    unconditional, requires second instruction
2735
%
2736
% -     LOD.C   Addr(Ry),Rx     // Any 16-bit relative address load, poss. cond
2737
%
2738
% -     STO.C   Rx,Addr(Ry)     // Any 16-bit rel addr, Rx and Ry must be valid
2739
%
2740
% -     FARJMP  #Addr:          // Arbitrary 32-bit jumps require a jump table
2741
%       BRA     +1              // memory address.  The BRA +1 can be skipped,
2742
%       .WORD   Addr            // but only if the address is placed at the end
2743
%       LOD     -2(PC),PC       // of an executable section
2744
%

powered by: WebSVN 2.1.0

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