URL https://opencores.org/ocsvn/s6soc/s6soc/trunk

# Subversion Repositoriess6soc

## [/] [s6soc/] [trunk/] [doc/] [src/] [spec.tex] - Diff between revs 50 and 54

Rev 50 Rev 54
Line 36... Line 36...
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%
%%
%%
%%
\usepackage{import}
\usepackage{import}
\usepackage{bytefield}
\usepackage{bytefield}

\usepackage{listings}
\project{CMod S6 SoC}
\project{CMod S6 SoC}
\title{Specification}
\title{Specification}
\author{Dan Gisselquist, Ph.D.}
\author{Dan Gisselquist, Ph.D.}
\email{dgisselq (at) opencores.org}
\email{dgisselq (at) ieee.org}
\revision{Rev.~0.3}
\revision{Rev.~0.4}
\begin{document}
\begin{document}
\pagestyle{gqtekspecplain}
\pagestyle{gqtekspecplain}
\titlepage
\titlepage
\begin{license}
\begin{license}
Copyright (C) \theyear\today, Gisselquist Technology, LLC
Copyright (C) \theyear\today, Gisselquist Technology, LLC
Line 61... Line 62...
 
 
You should have received a copy of the GNU General Public License along
You should have received a copy of the GNU General Public License along
with this program.  If not, see \texttt{http://www.gnu.org/licenses/} for a copy.
with this program.  If not, see \texttt{http://www.gnu.org/licenses/} for a copy.
\end{license}
\end{license}
\begin{revisionhistory}
\begin{revisionhistory}
0.5 & 2/13/2017 & Gisselquist & Draft updates to support the 8-bit byte ZipCPU
0.4 & 3/22/2017 & Gisselquist & Updated to support the 8-bit byte ZipCPU
                \\\hline
                \\\hline
0.3 & 5/23/2016 & Gisselquist & Draft for comment, includes ZipOS and PMod
0.3 & 5/23/2016 & Gisselquist & Draft for comment, includes ZipOS and PMod
                pin mapping\\\hline
                pin mapping\\\hline
0.2 & 5/14/2016 & Gisselquist & Updated Draft, still not complete \\\hline
0.2 & 5/14/2016 & Gisselquist & Updated Draft, still not complete \\\hline
0.1 & 4/22/2016 & Gisselquist & First Draft \\\hline
0.1 & 4/22/2016 & Gisselquist & First Draft \\\hline
Line 77... Line 78...
\listoftables
\listoftables
\begin{preface}
\begin{preface}
The Zip CPU was built with the express purpose of being an area optimized,
The Zip CPU was built with the express purpose of being an area optimized,
32--bit FPGA soft processor.
32--bit FPGA soft processor.
 
 
The S6~SoC is designed to prove that the Zip~CPU has met this goal.
The S6~SoC is designed to prove that the ZipCPU has met this goal.
 
 
There are two side--effects to this.  First, the project proves how capable a
There are two side--effects to this.  First, the project proves how capable a
CMod--S6 is, and second, this project provides demonstration implementations
very small FPGA, such as the Spartan~6/LX4 on the CMod--S6, can be and second,
of how to interact with a variety of PMod devices: the audio amplifier,
this project provides demonstration implementations of how to interact with a
the serial 2--line LCD display, the USBUART, and the 16--character numeric
variety of PMod devices: the audio amplifier, the serial 2--line LCD display,
keypad.
the USBUART, and the 16--character numeric keypad.
\end{preface}
\end{preface}
 
 
\chapter{Introduction}
\chapter{Introduction}
\pagenumbering{arabic}
\pagenumbering{arabic}
\setcounter{page}{1}
\setcounter{page}{1}
 
 
% What is old
% What is old
The Zip~CPU is a soft core CPU designed to fit within an FPGA, to use a minimum
The ZipCPU is a soft core Central Processing Unit (CPU) designed to fit within
amount of the FPGA's resources, and yet to provide the services of a fully
an FPGA, to use a minimum amount of the FPGA's resources, and yet to still
capable 32--bit computer.  It is based upon a Von~Neumann architecure and so a
provide the services of a fully capable 32--bit computer.  It is based upon a
single 32--bit wishbone bus provides it with access to both peripherals and
Von~Neumann architecture and so a single 32--bit wishbone bus provides it with
memory.
access to both peripherals and memory.
 
 
% What does the old lack?
% What does the old lack?
Previous demonstrations of the Zip~CPU have focused on larger FPGAs, such as
Previous demonstrations of the ZipCPU have focused on larger FPGAs, such as
the Spartan--6 LX9 and LX25 and the Artix--7 35T.  On these FPGA's,
the Spartan--6 LX9 and LX25 and the Artix--7 35T.  On these FPGA's,
the Zip~CPU runs in a pipelined configuration where it is tightly integrated
the ZipCPU runs in a pipelined configuration where it is tightly integrated
with a prefetch/instruction cache.  While these demonstrations have shown that
with a prefetch/instruction cache.  While these demonstrations have shown that
the Zip~CPU can act as a very simple CPU in these environments, they really
the ZipCPU can act as a very simple CPU in these environments, they really
haven't demonstrated the ability of the Zip~CPU to use only a minimum amount
haven't demonstrated the ability of the ZipCPU to use only a minimum amount
of the FPGA's resources.
of the FPGA's resources.
 
 
% What is new
% What is new
The CMod~S6 board provides the opportunity for that demonstration rather nicely.
The CMod~S6 board provides the opportunity for that demonstration rather nicely.
% What does the new have that the old lacks
% What does the new have that the old lacks
\begin{enumerate}
\begin{enumerate}
\item The Spartan--6 LX4 FPGA is very limited in its resources:
\item The Spartan--6 LX4 FPGA is very limited in its resources:
        It only has 2,400 look--up tables (LUTs), and can only support
        It only has 2,400 look--up tables (LUTs), and can only support
        a 4,096~Word RAM memory (16 kB).
        a 16~kB RAM memory.
\item With only 4kW RAM, the majority of any program will need to be placed into
\item With only 16kB RAM, the majority of any program will need to be placed
        and run from flash.
        into and run from the flash.
\item While the chip has enough area for the CPU, it doesn't have enough area
\item While the chip has enough area for the CPU, it doesn't have enough area
        to include the CPU and \ldots write access to the flash, debug access,
        to include the CPU and \ldots write access to the flash, debug access,
        wishbone command access from the UART, pipelined CPU operations,
        wishbone command access from the UART, pipelined CPU operations,
        a prefetch cache and more.  Other solutions will need to be found.
        a prefetch cache and more.  Other solutions will need to be found as

        part of this project.
\end{enumerate}
\end{enumerate}
 
 
Of course, if someone just wants the functionality of a small, cheap, CPU,
Of course, if someone just wants the functionality of a small, cheap, CPU,
this project does not fit that role very well.  While the S6 is not very
this project does not fit that role very well.  While the S6 is not very
expensive at nearly \$70, it is still an order of magnitude greater than it's expensive at nearly \$70, it is still an order of magnitude greater than it's
Line 131... Line 133...
 
 
% What performance gain can be expected?
% What performance gain can be expected?
 
 
If, on the other hand, what you want is a small, cheap, CPU that can be
If, on the other hand, what you want is a small, cheap, CPU that can be
embedded within an FPGA without using too much of the FPGA's resources, this
embedded within an FPGA without using too much of the FPGA's resources, this
project will demonstrate that possibility as well as some utility.
project will demonstrate that possibility as well as showing that the CPU even
Alternatively, if you wish to study how to get a CPU to work in a small,
has some utility.  Alternatively, if you wish to study how to get a CPU to
constrained environment, this project may be what you are looking for.
work in a small, constrained environment, this project may be what you are

looking for.  Likewise, if you are a software developer forced to get something

running on an FPGA, such as the CMod-S6, you may have just found your answer.
 
 
Finally, because the Zip~CPU and the included ZipOS are as small and simple as
Finally, because the ZipCPU and the included ZipOS are as small and simple as
they are, the code base found here will be simpler to understand than the
they are, the code base found here will be simpler to understand than the
code bases for some of these other projects.  For example, the Zip~CPU
code bases for some of these other projects.  For example, the ZipCPU
instruction set is very simple.  With less than 40 instructions, it is much
instruction set is very simple.  With only 29~instructions, it is much
easier to understand and learn than the ARM instruction set.  Further, unlike
easier to understand and learn than the ARM instruction set.  Further, unlike
the ARM, the entire specification for and description of the Zip~CPU is
the ARM, the entire specification for and description of the ZipCPU is
publicly available.  Likewise, an operating system such as the ZipOS that has
publicly available.  Likewise, an operating system such as the ZipOS that has
less than \hbox{3,000} lines of code will be much easier to understand than any
less than \hbox{3,000} lines of code will be much easier to understand than any
Linux operating system--even if it has much less functionality.
Linux operating system--even if it has much less functionality.\footnote{I'm

still entertaining thoughts of placing Linux onto this device.}
 
 
\chapter{Architecture}
\chapter{Architecture}
Fig.~\ref{fig:architecture}
Fig.~\ref{fig:architecture}
\begin{figure}\begin{center}
\begin{figure}\begin{center}
\includegraphics[width=5in]{../gfx/s6bones.eps}
\includegraphics[width=5in]{../gfx/s6bones.eps}
\caption{CMod S6 SoC Architecture: Zip~CPU and
\caption{CMod S6 SoC Architecture: ZipCPU and
        Peripherals}\label{fig:architecture}
        Peripherals}\label{fig:architecture}
\end{center}\end{figure}
\end{center}\end{figure}
shows the basic internal architecture of the S6~SoC.  In summary, it consists
shows the basic internal architecture of the S6~SoC.  In summary, it consists
of a CPU
of a CPU
coupled with a variety of peripherals for the purpose of controlling the
coupled with a variety of peripherals for the purpose of controlling the
Line 163... Line 168...
external display.  All of these devices are then available for the CPU to
external display.  All of these devices are then available for the CPU to
interact with.
interact with.
 
 
If you are familiar with the Zip CPU, you'll notice this architecture provides
If you are familiar with the Zip CPU, you'll notice this architecture provides
no access to the Zip CPU debug port.  There simply wasn't enough room on the
no access to the Zip CPU debug port.  There simply wasn't enough room on the
device.  Debugging the Zip~CPU will instead need to take place via other means,
device.  Debugging the ZipCPU will instead need to take place via other means,
such as dumping all registers and/or memory to the serial port on any reboot.
such as dumping all registers and/or memory to the serial port on any reboot,
 
and making judicious use of the internal scope.
Further, the Zip~CPU has no ability to write to flash memory.  For this reason,
 
there exists an alternate CMod S6~SoC architecture, shown in
Further, the read/write flash controller couldn't fit in the design along
Fig.~\ref{fig:altarchitecture}.
with the ZipCPU, leaving the ZipCPU with a simpler read--only flash controller

and no ability to write to flash memory.  For this reason, there exists an

alternate CMod S6~SoC architecture, shown in Fig.~\ref{fig:altarchitecture}.
\begin{figure}\begin{center}
\begin{figure}\begin{center}
\includegraphics[width=5in]{../gfx/altbones.eps}
\includegraphics[width=5in]{../gfx/altbones.eps}
\caption{Alternate CMod S6 SoC Architecture: Peripherals, with no
\caption{Alternate CMod S6 SoC Architecture: Peripherals, with no
        CPU}\label{fig:altarchitecture}
        CPU}\label{fig:altarchitecture}
\end{center}\end{figure}
\end{center}\end{figure}
Using this alternate architecture, it should be possible to test the peripherals
Using this alternate architecture, it is be possible to test the peripherals
and program the flash memory.  Both architectures may be loaded into the flash,
and program the flash memory.
together with the programming code for the Zip CPU.

 
 
The basic approach to loading the board is actually quite simple.  Using the
The basic approach to loading the board is actually quite simple.  Using the
Digilent ADEPT JTAG configuration program, {\tt djtgcfg}, the alternate
Digilent ADEPT JTAG configuration program, {\tt djtgcfg}, the alternate
configuration may be written directly to the device.  Once this alternate
configuration may be written directly to the device.  Once this alternate
configuration has been loaded, the flash may be examined and programmed using
configuration has been loaded, the flash may be examined and programmed using
the {\tt zipload} utility.  This utility uses Digilent's Asynchronous Parallel
the {\tt zipload} utility.  This utility uses Digilent's Asynchronous Parallel
Port interface (DEPP) to communicate with the device, and in particular to
Port interface (DEPP) to communicate with the device, and in particular to
tell the device what to write to the flash.  When writing to the flash,
tell the device what to write to the flash.  When writing to the flash,
the {\tt zipload} utility will program both a primary and an alternate
the {\tt zipload} utility can program the FPGA configuration into the
FPGA configuration into the configuration section of the flash, as well as
configuration section of the flash, as well as computer code into the rest of
computer code into the rest of the flash.  Once complete, the system may then be
the flash.  Once complete, the system may then be reloaded, either by power
reloaded with the primary configuration file which will contain an image of
down/up or via {\tt djtgcfg}, with the primary configuration file which will
the CPU.  The CPU will then begin following the instructions found in flash
contain an image of the CPU.  The CPU will then begin following the
memory.
instructions found in flash memory.
 
 
 
 
\chapter{Getting Started}
\chapter{Getting Started}

\section{Building the Xilinx BIT file(s)}

The S6SoC nearly fills the CMod-S6 part, so building the BIT files can be a

little tricky, and there are a couple steps to doing this.

 

The first step is to built a Xilinx project, such as in Fig.~\ref{fig:new-prj}.

\begin{figure}

\begin{center}

\includegraphics[width=6in]{../gfx/newprj.eps}

\caption{Create a New Project}\label{fig:new-prj}

\end{center}\end{figure}

So, once you've downloaded the

repository, create a new project.  We'll call it s6soc'', and declare

the working directory of this project and the xilinx project directory to

be in a {\tt xilinx} subdirectory of the main repository.  (You may notice

that bit files already exist in that directory.  You can use those, or

continue here.)

 

As this is a new project, you'll need to configure your project as in

Fig.~\ref{fig:projopts}

\begin{figure}

\begin{center}

\includegraphics[width=6in]{../gfx/projopts.eps}

\caption{Create a New Project}\label{fig:projopts}

\end{center}\end{figure}

so as to configure for the proper part.  In this case, the proper part comes

from the CMod--S6 schematic, and is shown in the figure.

 

At this point, you'll want to include the Verilog files into the ISE project.

These files can be found in the {\tt rtl/} project subdirectory.  While not

all Verilog files are used in all configurations, including unused files is

not a problem.  I recommend just including all of them.

 

Once these Verilog files have been included, there are two possible top level

files.  The first is the main {\tt toplevel.v} file, used by the SoC itself.

This file includes the ZipCPU as the master of all the peripherals.  The

second top level module is found in the {\tt alttop.v} file.  This second file

can be used both to test the CMod--S6 hardware as well as to program the flash

with any programs we wish to run in the S6--SoC.

 

Two more files need to be included: {\tt cmod.ucf} and {\tt cmodtop.ucf}.  The

first of these, {\tt cmod.ucf}, is the constraint file for the alternate top

file, {\tt alttop.v}.  The latter file, {\tt cmodtop.v}, is the constraint file

for the main top level file, {\tt toplevel.v}.  You'll want to associate these

two files with their respected top level at this time.

 

Once you have these files included, the next step will be to configure how the

project will be synthesized.  To set these options, first select one of the

two top levels to be the top level, and then right click on the

Synthesize--XST'' to bring up a process properties menu.  This menu contains

three sub--screens.  If you look at

Figures~\ref{fig:xstopts},

\begin{figure}

\begin{center}

\includegraphics[width=6in]{../gfx/xstopts.eps}

\caption{Synthesis options for low area}\label{fig:xstopts}

\end{center}\end{figure}

%

\ref{fig:hdlopts},

%

\begin{figure}

\begin{center}

\includegraphics[width=6in]{../gfx/hdlopts.eps}

\caption{HDL optimization options for the S6SoC}\label{fig:hdlopts}

\end{center}\end{figure}

%

and~\ref{fig:xpropts},

%

\begin{figure}

\begin{center}

\includegraphics[width=6in]{../gfx/xpropts.eps}

\caption{Xilinx specific options}\label{fig:xpropts}

\end{center}\end{figure}

you can see how I have made these choices to guarantee a minimum LUT count.

 

%

%

%

 

Once you finish configuring the synthesizer, it's time to configure the map

process.  This particular menu is within the Implement Design menu, Process

Properties option.  Selecting this menu option brings up a dialog, such as

Fig.~\ref{fig:mapopts}.

\begin{figure}

\begin{center}

\includegraphics[width=6in]{../gfx/mapopts.eps}

\caption{Map parameters necessary to optimize the S6SoC}\label{fig:mapopts}

\end{center}\end{figure}

From Fig.~\ref{fig:mapopts}, you can see what optimization settings were

necessary for getting the S6SoC to fit within the CMod--S6 device.

 

Two configuration screens remain.  The first, shown in

Fig.~\ref{fig:configopts},

\begin{figure}

\begin{center}

\includegraphics[width=6in]{../gfx/configopts.eps}

\caption{Configuration Options}\label{fig:configopts}

\end{center}\end{figure}

controls how the FPGA will be configured.  Important on this screen is the

fact that the CMod--S6 has a Quad SPI flash, and that it can be run from a

clock as fast as 108~MHz.  Here, we choose 16~MHz although I know of no reason

why the clock speed could not be made faster.

 

As a final configuration screen, there are options for generating the

programming (bit) file.  These are shown in Fig.~\ref{fig:bitfopts}.

\begin{figure}

\begin{center}

\includegraphics[width=6in]{../gfx/bitfopts.eps}

\caption{Programming file (Bit-File) generation options}\label{fig:bitfopts}

\end{center}\end{figure}

From the standpoint of the CMod--S6, the important configuration item here is

that we would like to compress the bit file, so that we can pack as much

information into our flash device as possible.

 

Having gone through all of your configuration options, you may now build the

two configurations, {\tt toplevel.bit} and {\tt alttop.bit} which are used in

this distribution.

 

{\tt make axload} in the main directory (assuming the Digilent ADEPT utilities

are installed) will load the alternate configuration into the flash, while

{\tt make xload} will load the main configuration into the flash.  For our

purposes, and until you have a compiled program to run, you will want to load

the alternate configuration into the flash.

 
\section{Building the Compiler}
\section{Building the Compiler}

 

The ZipCPU compiler comes as source from the ZipCPU distribution.  To build

this compiler, clone the ZipCPU distribution and follow the build and

installation instructions within it.  Ever afterwards, you'll want the ZipCPU

toolchain, {\tt zip-gcc}, {\tt zip-as}, {\tt zip-ld}, etc., in your

path.\footnote{You may need to install several packages to do this, such as:

flex, bison, libbison-dev, libgmp10, libgmp-dev, libmpfr-dev, libmpc-dev,

libelf-dev, ncurses-dev, libelf-dev, and verilator.}

 
%% git clone
%% git clone
%% Setting zip_param_cis to zero
%% Setting zip_param_cis to zero
%% Setting ZIP_DIVIDE to zero
%% Setting ZIP_DIVIDE to zero
%% Setting ZIP_PIPELINED to zero        -- Disables the ZIP_ATOMIC instructions
%% Setting ZIP_PIPELINED to zero        -- Disables the ZIP_ATOMIC instructions
%% Setting ZIP_THUMB to zero            -- Disables the CIS instructions
%% Setting ZIP_THUMB to zero            -- Disables the CIS instructions

 

 
\section{Building the ADEPT Utilities}
\section{Building the ADEPT Utilities}
% Install the digilent adept utilities
 

You will also need a copy of Digilent's ADEPT software installed on your

system in order to use the CMod--S6.  This includes not only the ADEPT

utilities, but also ADEPT software development kit and it's runtime environment.

We'll need these pieces of software to provide both the {\tt djtgcfg} program

to load the FPGA with our designs, as well as the {\tt DEPP} port, provided by

both the SDK and the runtime environment, necessary to communicate with our

board.

 

% Install the Digilent ADEPT utilities
%   Expand the tar file
%   Expand the tar file
%   tar -xvzf digilent.adept.utilities_2.2.1-x86_64.tar.gz
%   tar -xvzf digilent.adept.utilities_2.2.1-x86_64.tar.gz
%   Install them
%   Install them
%   cd digilent.adept.utilities_2.2.1-x86_64.tar.gz
%   cd digilent.adept.utilities_2.2.1-x86_64.tar.gz
%   sudo ./install.sh
%   sudo ./install.sh
Line 216... Line 365...
% Answer Y to install system binaries into /usr/sbin
% Answer Y to install system binaries into /usr/sbin
% Answer Y to install data into /usr/share/digilent/adept/data
% Answer Y to install data into /usr/share/digilent/adept/data
% Answer Y to install runtime configuration data files into /etc
% Answer Y to install runtime configuration data files into /etc
%
%
\section{Building and Running the Host Software}
\section{Building and Running the Host Software}
\section{Building the Board Software}
 
\section{Building the ZipOS}
Once you have the ADEPT utilities installed, you may then build the software

in the {\tt sw/host} project subdirectory.  The makefile in this directory

has a reference to the location of ADEPT include files, which you may need to

update according to where you have installed ADEPT.  You may also need to

adjust the library path, so that it properly references the ADEPT libraries.

(The library path is currently hard coded into the Makefile.)

 

\section{Building the ZipCPU Software}

 

Once you have the ZipCPU toolchain built, you may then build the ZipCPU software

which will be placed onto the board.  This software may be found in the

{\tt sw/dev} directory.  The ZipOS example can be found in the {\tt sw/zipos}

directory.  A {\tt make} command executed in each of these directories should

build the ZipCPU software for the board.

 

\section{Connecting the PMods to your board}

The S6~SoC supports four PMods: The PModUSBUART, the PModAMP2 pwm to audio

amplifier, the PModCLS two line LCD display, and the PModKYPD sixteen

character keypad.  These need to be wired up to the CMod~S6 as shown in

Fig.~\ref{fig:pmodplaces} on page~\pageref{fig:pmodplaces}.

 

\section{Loading Software onto your SoC}

Once you have all the software loaded, you may wish to try a simple LED

program.  You may find the {\tt sw/dev/blinky.c} program suitable for this

purpose.  To run this program, you will need to follow a series of steps:

\begin{enumerate}

\item Build the {\tt sw/dev/blinky} program.

\item Build both Xilinx configurations, {\tt alttop.bit} and {\tt toplevel.bit}.

        The main makefile will look for these files in the {\tt xilinx/}

        project subdirectory that you made when you created the project.

\item From the main project subdirectory, run {\tt make axload} to load

        the alternate configuration onto your board.  (You do have your board

        plugged in, right?)

\item Then you can run the {\tt zipload} program found in the {\tt sw/host}

        directory.  {\tt zipload} takes one or two arguments.  In this

        example, we'll give it a first argument of the {\tt xilinx/toplevel.bit}

        file, and a second argument of the program we would like to run,

        {\tt sw/dev/blinky}.

\item Assuming {\tt zipload} completed successfully, you can then either run

        {\tt make xload} from the main directory, or you may remove and

        reconnect power to your board.

\item A blinking light demonstration should now be running on your board.

\end{enumerate}
 
 
\chapter{Software}
\chapter{Software}
This chapter provides an overview of the software that is available to support
This chapter provides an overview of the software that is available to support
the S6~SoC.  This includes not only the RTL, the Makefiles, and the software
the S6~SoC.  This includes not only the RTL, the Makefiles, and the software
that will run on the Zip~CPU within the S6~SoC, but also the support software
that will run on the ZipCPU within the S6~SoC, but also the support software
necessary for communicating with the S6~SoC in its alternate configuration.
necessary for communicating with the S6~SoC in its alternate configuration.
 
 
\section{Directory Structure}
\section{Directory Structure}
\begin{itemize}
\begin{itemize}
\item[{\tt trunk/bench}] Contains software for emulating the S6 without the S6
\item[{\tt sim/verilator/}] Contains software for emulating the S6~SoC
        present.
        without the S6 present.
  \begin{itemize}

        \item[{\tt trunk/bench/cpp}]  All of the bench testing software is

                written in C++, so it is found in this directory.  Primary

                among these programs is the {\tt zip\_sim} program which will

                simulate the Zip~CPU within the S6~SoC.  Specifically, it

                simulates everything at or below the {\tt busmaster.v} level.

 

                Some, although not all, of the peripherals have been simulated

                and made a part of this simulation.  These include the

                Quad--SPI flash, the UART, and the LED's.

 
 
  \end{itemize}
        All of the bench testing software is written in C++, so it is found in
\item[{\tt trunk/doc}] All of the documentation for the S6~SoC project may be
        this directory.  Primary among these programs is the {\tt zip\_sim}

        program which will simulate the ZipCPU within the S6~SoC.  Specifically,

        it simulates everything at or below the {\tt busmaster.v} level.

 

        Some, although not all, of the peripherals have been simulated and

        made a part of this simulation.  These include the Quad--SPI flash,

        the UART, the LED's and the GPIOs.

 

\item[{\tt doc/}] All of the documentation for the S6~SoC project may be
        found in this documentation directory.  Specifically, I would commend
        found in this documentation directory.  Specifically, I would commend
        your attention to anything with a {\tt .pdf} extension, as these
        your attention to anything with a {\tt .pdf} extension, as these
        are the completed documents.  Among these you should find a copy of the
        are the completed documents.  Among these you should find a copy of the
        GPL copyright under which this software is released, as well as a
        GPL copyright under which this software is released, as well as a
        pre--built copy of this document.
        pre--built copy of this document.
  \begin{itemize}
  \begin{itemize}
        \item[{\tt trunk/doc/gfx}] Here is where the graphics are located in
        \item[{\tt doc/gfx/}] Here is where the graphics are located in
                support of this specification document.
                support of this specification document.
        \item[{\tt trunk/doc/src}] And here is where the \LaTeX files are
        \item[{\tt doc/src/}] And here is where the \LaTeX files are
                kept that were used in building both this document as well as
                kept that were used in building both this document as well as
                the GPL copyright.
                the GPL copyright.
  \end{itemize}
  \end{itemize}
\item[{\tt trunk/rtl}] Verilog files.  The two top--level files are
\item[{\tt rtl/}] Verilog files.  The two top--level files are
        {\tt toplevel.v} for the primary top level module, and
        {\tt toplevel.v} for the primary top level module, and {\tt alttop.v}
        {\tt alttop.v} for the alternate load.
        for the alternate load.
  \begin{itemize}
  \begin{itemize}
        \item[{\tt trunk/rtl/cpu}]      Verilog files containing the Zip~CPU
        \item[{\tt rtl/cpu}] Verilog files containing the ZipCPU core and
                core and peripherals.  The toplevel file here is the
                peripherals.  The toplevel file here is the {\tt zipbones.v}
                {\tt zipbones.v} file, although some of the peripherals, such
                file, although some of the peripherals, such as the
                as the {\tt ziptimer.v} are referenced independently.
                {\tt ziptimer.v} are referenced independently.
  \end{itemize}
  \end{itemize}
\item[{\tt trunk/sw}] The main software directory, primarily a repository
\item[{\tt sw/}] The main software directory, primarily a repository
        for software subdirectories beneath it.
        for software subdirectories beneath it.
  \begin{itemize}
  \begin{itemize}
        \item[{\tt trunk/sw/dev}]  This directory holds a variety of
        \item[{\tt sw/dev/}]  This directory holds a variety of
                simple programs for the Zip~CPU, such as {\tt helloworld},
                simple programs for the ZipCPU, such as {\tt blinky},
                {\tt doorbell} and {\tt doorbell2}, as well as software drivers
                {\tt helloworld}, {\tt doorbell} and {\tt doorbell2}, as well
                for various peripherals, such as the real--time clock simulator,
                as software drivers for various peripherals, such as the
                and the keypad and display device drivers.
                real--time clock simulator, and the keypad and display device
        \item[{\tt trunk/sw/host}]  This directory holds support software which
                drivers.

 

                One key file in this directory is the {\tt cputest.c} file,

                which provides a basic test of the CPU and its capabilities.

 

        \item[{\tt sw/host/}]  This directory holds support software which
                can be built on and run on the host machine.  Building this
                can be built on and run on the host machine.  Building this
                software will involve adjusting the Makefile so that it knows
                software will involve adjusting the Makefile so that it knows
                where your local ADEPT installation directory is.\footnote{Many
                where your local ADEPT installation directory is.  Once built,
                of the programs also depend upon the serial number of my CMod
                you will find a variety of very useful programs within here.
                S6 device.  This will need to be adjusted in any new install.}
        \item[{\tt sw/zipos/}]  This directory contains the source code for
                Once built, you will find a variety of very useful programs
                a rudimentary, very basic, pre-emptive multitasking operating
                within here.
                system that I call the ZipOS.
        \item[{\tt trunk/sw/zipos}]  This directory contains the source code for

                        a rudimentary, very basic, operating system that I

                        call the ZipOS.

  \end{itemize}
  \end{itemize}
\end{itemize}
\end{itemize}
 
 
\section{Zip CPU Tool Chain}
\section{Zip CPU Tool Chain}
To build programs for the Zip~CPU, you will need the Zip~CPU toolchain.  You
To build programs for the ZipCPU, you will need the ZipCPU toolchain.  You
can find this as part of the Zip~CPU project, available at OpenCores.  Building
can find this as part of the ZipCPU project, available at OpenCores.  Building
the Zip~CPU project should result in a set of binaries in the
the ZipCPU project should result in a set of binaries in the
\hbox{\tt zipcpu/trunk/sw/install/cross-tools/bin} directory.  Make this
\hbox{\tt sw/install/cross-tools/bin/} subdirectory of your ZipCPU project

directory.  Make this
directory a part of your path, and you should be able to build the CMod S6
directory a part of your path, and you should be able to build the CMod S6
Zip~CPU software.  Specifically, you will need to use {\tt zip-gcc},
ZipCPU software.  Specifically, you will need to use {\tt zip-gcc},
{\tt zip-as}, {\tt zip-ld}, and {\tt zip-cpp}.  Other tools, such as
{\tt zip-as}, {\tt zip-ld}, and {\tt zip-cpp}.  Other tools, such as
{\tt zip-objdump} and {\tt zip-readelf}, may also prove to be very useful when
{\tt zip-objdump} and {\tt zip-readelf}, may also prove to be very useful when
trying to figure out what is going on within the SoC.
trying to debug what is going on within the SoC.
 
 
\section{Bench Test Software}
\section{Bench Test Software}
 
 
Bench testing software currently consists of the {\tt zip\_sim} program found
Bench testing software currently consists of the {\tt zip\_sim} program found
within {\tt trunk/bench/cpp}.  This program requires Verilator to run, and
within {\tt sim/verilator}.  This program requires Verilator to run, and
simulates in a cycle accurate fashion, the entire S6~SoC from {\tt busmaster.v}
simulates in a cycle accurate fashion, the entire S6~SoC from {\tt busmaster.v}
on down.  Further, the external Quad--SPI flash memory, UART, and LED's are
on down.  Further, the external Quad--SPI flash memory, UART, and LED's are
also simulated, although the 2--line display, audio, and keypad are not.
also simulated, although the 2--line display, audio, and keypad are not.
 
 
\section{Host Software}
\section{Host Software}
Several software programs have been built to support the S6~SoC from a nearby
Several software programs have been built to support the S6~SoC from a nearby
host.  These programs include:
host.  These programs include:
\begin{itemize}
\begin{itemize}
\item {\tt dumpuart}: My current approach to debugging involves
\item {\tt dumpuart}: My current approach to debugging involves dumping the
        dumping the state of the registers and memory to the
        state of the registers and memory to the UART upon reboot.  The
        UART upon reboot.  The dumpuart command found here is
        dumpuart command found here is designed to make certain that the UART
        designed to make certain that the UART is first set
        is first set up correctly at 9600~Baud, and second that everything
        up correctly at 9600~Baud, and second that everything
        read from the UART is directly sent to both a file and to the screen.
        read from the UART is directly sent to both a file and
        In this fashion, it is similar to the UNIX {\tt tee} program, save for
        to the screen.  In this fashion, it is similar to the
        its serial port attachment.
        UNIX {\tt tee} program, save for its serial port
\item {\tt readflash}: As I am loathe to remove anything from a device that
        attachment.
        came factory installed, the {\tt readflash} program reads the original
\item {\tt readflash}: As I am loathe to remove anything from
        installed configuration from the flash and dumps it to a file.
        a device that came factory installed, the

        {\tt readflash} program reads the original installed

        configuration from the flash and dumps it to a file.

 
 
        This program is only useful when the alternate configuration is loaded.
        This program is only useful when the alternate configuration is loaded.
 
 
\item {\tt wbregs}: This program offers a capability very similar to the
\item {\tt wbregs}: This program offers a capability very similar to the
        PEEK and POKE capability Apple user's may remember from before the
        PEEK and POKE capability Apple user's may remember from before the
Line 341... Line 530...
        I/O register, and {\tt wbregs gpio 0xffffffff} will set all output
        I/O register, and {\tt wbregs gpio 0xffffffff} will set all output
        GPIO ports high while {\tt wbregs gpio 0xffff0000} will set all
        GPIO ports high while {\tt wbregs gpio 0xffff0000} will set all
        output GPIO ports to ground.
        output GPIO ports to ground.
 
 
        This program is only useful when the alternate configuration is loaded.
        This program is only useful when the alternate configuration is loaded.

        When the primary {\tt toplevel.v} configuration is loaded, the ZipCPU

        will be able to read and write these registers in a similar fashion.
 
 
\item {\tt zipload}: This is the primary program you will need to get your
\item {\tt zipload}: This is the primary program you will need to get your
        software loaded on the CMod.  It takes three arguments.  The first is
        software loaded on the CMod.  It takes two arguments.  The first is
        the name of the primary Xilinx configuration file, the second is the
        the name of the primary Xilinx configuration file, and the second is
        name of an alternate Xilinx configuration file, and the third is the
        the name of the ZipCPU program you wish to write to Flash memory.
        name of the Zip~CPU program you wish to write to Flash memory.
 
 
        Each of these arguments is optional.  For example, if a configuration
        Each of these arguments is optional.  For example, if only one
        file is given, the loader will load the primary configuration.  If
        configuration file is given, the loader will load the primary
        a ZipCPU program is given, the program will be loaded into the program
        configuration.  If only one Zip~CPU program is given, the program will
        memory area and the configuration file areas will be left untouched.
        be loaded into the program memory area and the configuration file areas

        will be left untouched.

 
 
        This program is only useful when the alternate configuration is loaded.
        As with {\tt wbregs}, this program is only useful when the alternate

        configuration is loaded.
\end{itemize}
\end{itemize}
\section{Zip CPU Programs}
\section{Zip CPU Programs}
The following are a list of simple, independent, single-task example programs
The following are a list of simple, independent, single-task example programs
that will run on the S6~SoC:
that will run on the S6~SoC:
\begin{itemize}
\begin{itemize}

\item {\tt blinky}: This is a very simple program similar to hello world, with

        the difference that the lights have a bit of a different response, the

        hello world message is written slower, and interrupts are used to

        accomplish this purpose.
\item {\tt helloworld}: The first program any programmer should build,
\item {\tt helloworld}: The first program any programmer should build,
        Hello, world!''  This program sends the string, Hello, world!''
        Hello, world!''  This program sends the string, Hello, world!''
        over the UART connection once per second.  It is a very valuable
        over the UART connection once per second.  It is a very valuable
        program because, if you can get this program running, you know you have
        program because, if you can get this program running, you know you have
        a lot of things working and working correctly.  For example, running
        a lot of things working and working correctly.  For example, running
        this program means you can run the {\tt zip-gcc} compiler, load
        this program means you can run the {\tt zip-gcc} compiler, load
        the auxiliary configuration, load the program info flash memory, load
        the auxiliary configuration, load the program info flash memory, load
        the primary configuration, and read from the UART port.  It also means
        the primary configuration, and read from the UART port.  It also means
        that you must have the UART port properly configured and wired to your
        that you must have the UART port properly configured and wired to your
        CMod board.
        CMod board.

 

        Unlike other versions of Hello World that you may be familiar with,

        this one does not use the C--library.  It programs the hardware

        directly.

\item {\tt cputest}: This is a simple test of the CPU and all of its

        functionality.

        The functionality proven is primarily assembly

        level, but it does require the C compiler to put its framework

        together.

        {\tt cputest} is actually one of two programs built from the same

        source.  The other is named {\tt cputestcis}, and specifically

        allows the complex instruction set (CIS) instructions whereas

        {\tt cputest} specifically disallows them.  The difference, therefore,

        is in the command line parameters given to the assembler (via the

        compiler).
\item {\tt doorbell}: This annoying program verifies the functionality of the
\item {\tt doorbell}: This annoying program verifies the functionality of the
        audio device by playing a doorbell sound to the audio port.  It will
        audio device by playing a doorbell sound to the audio port.  It will
        then wait ten seconds, and play the doorbell sound again (and again,
        then wait ten seconds, and play the doorbell sound again (and again,
        and again).  (It gets old after a while ...)
        and again).  (It gets old after a while ...)
\item {\tt doorbell2}: This adds to the functionality of the {\tt doorbell}
\item {\tt doorbell2}: This adds to the functionality of the {\tt doorbell}
        program a wait for keypress, and a display of the current time on the
        program a wait for keypress, and a display of the current time on the
        2--line display.  While almost our fully functional program, this
        2--line display.  While almost our fully functional ZipOS program, this
        does not include any menus to configure the device or set time, since
        does not include any menus to configure the device or set time, since
        it doesn't include any keypad functionality.
        it doesn't include any keypad functionality.
\item {\tt kptest}: A test of whether or not they keypad driver works.  When
\item {\tt kptest}: A test of whether or not they keypad driver works.  When
        run, anytime a key is pressed, the key's associated printable character
        run, anytime a key is pressed, the key's associated printable character
        will be sent to the UART.  Further, pressing an F' on the keypad will
        will be sent to the UART.  Further, pressing an F' on the keypad will
Line 398... Line 607...
however, handle interrupts, support multiple pre--emptive tasks in a
however, handle interrupts, support multiple pre--emptive tasks in a
multitasking, timesharing fashion, and it supports some very basic and
multitasking, timesharing fashion, and it supports some very basic and
rudimentary system calls.  In a similar fashion, it does contain just about all
rudimentary system calls.  In a similar fashion, it does contain just about all
of the functionality necessary for a multi--tasking microcontroller built
of the functionality necessary for a multi--tasking microcontroller built
around a do--forever loop.  For its size, I consider it an impressive
around a do--forever loop.  For its size, I consider it an impressive
achievement.  You are welcome to disagree with me, however.
achievement.  You are welcome to disagree with me.
 
 
This version of the ZipOS starts in the {\tt resetdump.s} code, so that upon
This version of the ZipOS starts in the {\tt resetdump.s} code, so that upon
any startup the ZipOS will dump register contents, the BusError register, and
any startup the ZipOS will dump register contents, the BusError register, and
any scope contents to the UART.  This can take some time, so you may wish to
any scope contents to the UART--assuming that the scope had been triggered.
configure what you really wish to send--if anything.  If desired,
This can take some time, so you may wish to configure what you really wish to
{\tt resetdump} can also be configured to also dump the entire memory as well
send--if anything.  If desired, {\tt resetdump} can be configured to also
while only using 9~memory locations.  All of this is quite useful in case the
dump the entire memory as well while only using ten memory locations in its own
Zip~CPU encounters a bus error or other sort of error that causes it to hang,
support.  All of this is quite useful in case the

ZipCPU encounters a bus error or other sort of error that causes it to hang,
stall, or reboot, as the CPU registers are very carefully not touched prior to
stall, or reboot, as the CPU registers are very carefully not touched prior to
being sent to the UART output port.  This extends to all registers save the
being sent to the UART output port.  This extends to all registers save the
supervisor PC and CC registers, which would've been reset by a reboot anyway.
supervisor PC and CC registers, which would've been reset by a reboot anyway.
 
 
{\tt resetdump.s} then calls a rudimentary bootloader, to load the parts of
{\tt resetdump.s} then calls a rudimentary bootloader, to load the parts of
Line 554... Line 764...
in the order they were created, as long as they are available to be executed.
in the order they were created, as long as they are available to be executed.
If no tasks are available to be run, the Scheduler will run the idle task which
If no tasks are available to be run, the Scheduler will run the idle task which
puts the CPU to sleep while waiting for an interrupt.
puts the CPU to sleep while waiting for an interrupt.
 
 
\chapter{Operation}
\chapter{Operation}
The {\tt doorbell} program has been built to illustrate the operation of both
The {\tt doorbell} program found in {\tt sw/zipos|} has been built to
the Zip~CPU, the ZipOS, as well as showing off how all of the various
illustrate the operation of both the ZipCPU the ZipOS, as well as showing off
peripherals work.  It was envisioned after my family and I experienced an
how all of the various peripherals work.  It was envisioned after my family
unexpected visitor during the wee hours of the morning.  The {\tt doorbell}
and I experienced an unexpected visitor during the wee hours of the morning.
program is designed to couple the doorbell and the exterior lights to a
The {\tt doorbell} program is designed to couple the doorbell and the exterior
single button.  Hence, when the doorbell to the house is pressed, the exterior
lights to a single button.  Hence, when the doorbell to the house is pressed,
light is turned on for a half an hour.  This, then, would make it difficult
the exterior light (an LED in the demo) is turned on for a half an hour.  This,
for someone to see inside during this time.
then, would make it difficult for someone to see inside during this time.
 
 
This chapter will present an example of how the {\tt doorbell} program works.
This chapter will present a discussion of how that {\tt doorbell} program works.
 
 
To run the {\tt doorbell} program, you will first need to build the various
To run the {\tt doorbell} program, you will first need to build the various
RTL and software support programs just to get the {\tt doorbell} program on
RTL and software support programs just to get the {\tt doorbell} program on
the device:
the device:
\begin{enumerate}
\begin{enumerate}
\item First build the primary and alternate .bit files by building
\item First build the primary and alternate .bit files by building with
        with {\tt toplevel.v} and then {\tt alttop.v} as your top--level
        {\tt toplevel.v} and then {\tt alttop.v} as your top--level RTL files.
        RTL files.  I like to place my Xilinx work directoy into
        I like to place my Xilinx work directory into a {\tt xilinx/} project
        {\tt trunk/xilinx}, and if you do the same the load scripts that
        subdirectory, and if you do the same the load scripts that are
        are referenced next will work.
        referenced next will work.
 
 
        Before going on, double check that both configuration .bit files were
        Before going on, double check that both configuration .bit files were
        created, that they each fit within the device (there would be errors
        created, and that they each fit within the device (there would be errors
        if they did not), and that they met their respective timing
        if they did not), and that they met their respective timing
        requirements.
        requirements.
 
 
\item Then, load the alternate bit file into the S6~SoC.  You will need
\item Then, load the alternate bit file into the S6~SoC.  You will need
        the Digilent tools installed in order to do this.  Having done so,
        the Digilent tools installed in order to do this.  Having done so,
        you may run {\tt make axload} from the {\tt trunk/} directory.
        you may run {\tt make axload} from the main project directory.
        If you didn't run the Xilinx ISE from within {\tt tunk/xilinx},
        If you didn't run the Xilinx ISE from within a {\tt xilinx/} project

        subdirectory,
        you may need to find your .bit files and adjust where they load
        you may need to find your .bit files and adjust where they load
        from, but this should be fairly straight--forward from the instructions
        from, but this should be fairly straight--forward from the instructions
        within the Makefile.
        within the Makefile.
\item Build the software found in the host directory.  This sotware depends
\item Build the software found in the host directory.  This software depends
        upon Digilent's ADEPT toolsuite, so you will need to adjust the
        upon Digilent's ADEPT toolsuite, so you will need to adjust the
        Makefile so that it references the toolsuite.
        Makefile so that it references the toolsuite.
 
 
        {\em Note:} Currently, the host software is serial--number locked to

        my own CMod--S6.  Until I fix this and make it more user friendly,

        you'll want to switch your software to reference your own CMod.

        To do this, look for the {\tt "SN:\ldots"} lines within the *.cpp'
 
        files.  Currently, there is one such line within wbregs, another
 
        within readflash, and the last within zipload.  To find our your own
 
        device's serial number, type {\tt djtgcfg enum}.  It should find one
 
        (or more) CMod devices connected to your system, and list each of
 
        their serial numbers.
 
 
 
        Once you've done this, you should have a working set of host support
 
        programs: readflash, wbregs, and zipload.
 
 
 
\item Using {\tt wbregs}, you may now test your configuration.  {\tt wbregs}
\item Using {\tt wbregs}, you may now test your configuration.  {\tt wbregs}
        works like the peek and poke programs from a generation ago.
        works like the peek and poke programs from a generation ago.
        {\tt wbregs <address>} will return the value of the memory (or
        {\tt wbregs <address>} will return the value of the memory (or
        peripheral) found at the {\tt <address>}.  Some addresses have names,
        peripheral) found at the {\tt <address>}.  Some addresses have names,
        such as {\tt UART}, {\tt SPIO}, {\tt GPIO}, {\tt PIC}, and so forth.
        such as {\tt UART}, {\tt SPIO}, {\tt GPIO}, {\tt PIC}, and so forth.
        These names are found in {\tt trunk/sw/host/regdefs.cpp}, and their
        These names are found in {\tt sw/host/regdefs.cpp}, and their
        mappings in {\tt trunk/sw/host/regdefs.h}.
        mappings in {\tt sw/host/regdefs.h}.
 
 
        As examples, if you type {\tt wbregs version} you should be able
        As examples, if you type {\tt wbregs version} you should be able
        to read the version (a.k.a. build date) from the currently installed
        to read the version (a.k.a. build date) from the currently installed
        .bit file.  Likewise if you type {\tt wbregs uart 65}, you should see
        .bit file.  Likewise if you type {\tt wbregs uart 65}, you should see
        an A' (i.e. a 65) sent from the S6~SoC over the serial port.
        an A' (i.e. a 65) sent from the S6~SoC over the serial port.
Line 633... Line 831...
        that came with your device, you may read it out using {\tt readflash}.
        that came with your device, you may read it out using {\tt readflash}.
        This will dump the contents of you flash onto {\tt qspiflash.bin}.
        This will dump the contents of you flash onto {\tt qspiflash.bin}.
        You may then wish to change the name of this file, lest you overwrite
        You may then wish to change the name of this file, lest you overwrite
        it by running {\tt readflash} again later.
        it by running {\tt readflash} again later.
 
 
\item At this point, it's time to build the programs for the Zip~CPU.  To do
        If you wish to restore this bitfile later, load the alternate
        this, you will first need to download the Zip~CPU project.  When
        configuration and run {\tt zipload qspiflash.bin}.
 
 
 
\item At this point, it's time to build the programs for the ZipCPU.  To do
 
        this, you will first need to download the ZipCPU project.  When
        building that project, it will create a directory of programs
        building that project, it will create a directory of programs
        (including its compiler) in
        (including its compiler) in the {\tt sw/install/cross-tools/bin/}
        {\tt zipcpu/trunk/sw/install/cross-tools/bin}.
        subdirectory of the ZipCPU project directory.
        Include this directory into your path.
        Include this directory into your path.
 
 
\item Change into {\tt trunk/sw/dev} to build some device testing files.
\item Change into the {\tt sw/dev} project subdirectory to build some device
        {\tt make} by itself should build some of these.
        testing files.  {\tt make} by itself should build some of these.
 
 
        You should now be ready to run some basic tests on the S6~SoC.
        You should now be ready to run some basic tests on the S6~SoC.
 
 
\item Let's test the UART first: back out to the main directory {\tt trunk/},
\item Let's test the UART first: back out to the main project directory,
        and run\break
        and run\break
        {\tt sw/host/zipload sw/dev/helloworld} and then {\tt make xload}.
        {\tt sw/host/zipload sw/dev/helloworld} and then {\tt make xload}.
        Now, examine your UART port.  (You do have the PModUSBUART installed
        Now, examine your UART port.  (You do have the PModUSBUART installed
        and connected, right?)  You should see Hello, world!'' printed
        and connected, right?)  You should see Hello, World!'' printed
        over and over again once each second.
        over and over again once each second.
 
 
\item You may try other test files in a similar manner, such as
\item You may try other test files in a similar manner, such as
        {\tt trunk/sw/dev/doorbell} and\break
        {\tt sw/dev/doorbell} and\break
        {\tt trunk/sw/dev/doorbell2}.  The first of these will just play the
        {\tt sw/dev/doorbell2}.  The first of these will just play the
        doorbell over and over again, whereas the second one will wait for a
        doorbell over and over again, whereas the second one will wait for a
        button press before playing the doorbell sound.
        button press before playing the doorbell sound.
 
 
\item Now let's go and build the ZipOS together with it's user files.  To do
\item Now let's go and build the ZipOS together with it's user files.  To do
        this, enter into the {\tt trunk/sw/zipos} directory and type
        this, enter into the {\tt sw/zipos/} directory and type
        {\tt make}.  If all goes well, you should now have a program named
        {\tt make}.  If all goes well, you should now have a program named
        {\tt trunk/sw/zipos/doorbell} which you can load into your S6~SoC as
        {\tt sw/zipos/doorbell} which you can load into your S6~SoC as
        well.
        well.
 
 
\item A final load, and we'll be done.  To do this, make {\tt axload} again,
\item A final load, and we'll be done.  To do this, make {\tt axload} again,
        and this time {\tt sw/host/zipload xilinx/toplevel.bit sw/zipos/doorbell}.
        and this time
 
        {\tt sw/host/zipload xilinx/toplevel.bit sw/zipos/doorbell}.
        When you power on your device the next time, or after you
        When you power on your device the next time, or after you
        {\tt make xload}, you'll find the ZipOS running on the Zip~CPU.
        {\tt make xload}, you'll find the ZipOS running on the ZipCPU.
 
 
\item To test the doorbell, press one of the buttons.  You should hear a
\item To test the doorbell, press one of the buttons.  You should hear a
        doorbell coming out of the PModAMP2 audio port.
        doorbell coming out of the PModAMP2 audio port.
 
 
\item You should also be able to read the time on the LCD display.  It will be
\item You should also be able to read the time on the LCD display.  It will be
        the wrong time (the number of seconds since power on \ldots).  To set
        the wrong time (the number of seconds since power on \ldots) initially.
        the correct time, press A' on the keypad and then type in the 6--digit
        To set the correct time, press A' on the keypad and then type in the
        time: HHMMSS.
        6--digit time: HHMMSS.
 
 
        If you make a mistake, the C' key can be used for a backspace.
        If you make a mistake, the C' key can be used for a backspace.
 
 
\item You can also set the time of dawn'' by pressing a B' on the keypad
\item You can also set the time of dawn'' by pressing a B' on the keypad
        and then typing in the time dawn'' should be at.  The same is
        and then typing in the time dawn'' should be at.  The same is
        true for dusk, only you'll need to start that by pressing a C' on the
        true for dusk, only you'll need to start that by pressing a C' on the
        keypad.
        keypad.
 
 
\item Now, when the doorbell rings, the LCD will show the time the doorbell
\item Now, when the doorbell rings, the LCD will show the time the doorbell
        was pressed.  If the time is at night, the ourdoor light (oops, I
        was pressed.  If the time is at night, the outdoor light (oops, I
        mean LED\#3) will turn on for a half an hour (currently set to
        mean LED\#3) will turn on for a half an hour (currently set to
        30~seconds, since I don't have the patience to wait a half hour while
        30~seconds, since I don't have the patience to wait a half hour while
        testing).
        testing).
\end{enumerate}
\end{enumerate}
 
 
Line 713... Line 915...
memory.  The RAM can be read and written, and the flash acts like read only
memory.  The RAM can be read and written, and the flash acts like read only
memory.\footnote{The Flash can be written, but only by an external command
memory.\footnote{The Flash can be written, but only by an external command
while in the alternate configuration.}  Furthermore, {\em only} the RAM offers
while in the alternate configuration.}  Furthermore, {\em only} the RAM offers
the capability of byte-wise writes across the bus.
the capability of byte-wise writes across the bus.
 
 
This isn't quite true with the other address regions.  Accessing the I/O
This isn't quite true with the other address regions.  For example, accesses to
region, while it will act like a memory, it may also have side-effects.  For
the I/O region may also have side-effects--even though this region is accessed
example, reading from the debugging scope device's data port will read a word
just like memory.  For example, reading from the debugging scope device's data
from the scope's buffer and advance the buffer pointer.  (More on that later.)
port will read a word from the scope's buffer and advance the buffer pointer.
 
(More on that later.)
 
 
Finally, to keep the address decoder simple, many of these addresses are
Finally, to keep the address decoder simple, many of these addresses are
multiply mapped.  Hence you may find the I/O peripherals mapped throughout the
multiply mapped.  Hence you may find the I/O peripherals mapped throughout the
{\tt 0x0400}--{\tt 0x07ff} address region.  Other memory addresses are similarly
{\tt 0x0400}--{\tt 0x07ff} address region.  Other memory addresses are similarly
overmapped.  This overmapping was a resource minimization feature, to get the
overmapped.  This overmapping was a resource minimization feature, to get the
Line 734... Line 937...
\begin{table}[htbp]
\begin{table}[htbp]
\begin{center}\begin{reglist}
\begin{center}\begin{reglist}
PIC    &\scalebox{0.8}{\tt 0x0400} & 32 & R/W & Interrupt Controller \\\hline
PIC    &\scalebox{0.8}{\tt 0x0400} & 32 & R/W & Interrupt Controller \\\hline
BUSERR &\scalebox{0.8}{\tt 0x0404} & 32 & R & Last Bus Error Address\\\hline
BUSERR &\scalebox{0.8}{\tt 0x0404} & 32 & R & Last Bus Error Address\\\hline
TIMER   &\scalebox{0.8}{\tt 0x0408} & 32 & R/W & ZipTimer\\\hline
TIMER   &\scalebox{0.8}{\tt 0x0408} & 32 & R/W & ZipTimer\\\hline
WDOG   &\scalebox{0.8}{\tt 0x040c} & 32 & R/W & Watchdog Timer\\\hline
WATCHDOG &\scalebox{0.8}{\tt 0x040c} & 32 & R/W & Watchdog Timer\\\hline
PWM    &\scalebox{0.8}{\tt 0x0410} & 32 & R/W & PWM Audio Controller\\\hline
PWM    &\scalebox{0.8}{\tt 0x0410} & 32 & R/W & PWM Audio Controller\\\hline
SPIO   &\scalebox{0.8}{\tt 0x0414} & 32 & R/W & Special Purpose I/O, Keypad, LED Controller \\\hline
SPIO   &\scalebox{0.8}{\tt 0x0414} & 32 & R/W & Special Purpose I/O, Keypad, LED Controller \\\hline
GPIO   &\scalebox{0.8}{\tt 0x0418} & 32 & R/W & GPIO Controller \\\hline
GPIO   &\scalebox{0.8}{\tt 0x0418} & 32 & R/W & GPIO Controller \\\hline
UART   &\scalebox{0.8}{\tt 0x041c} & 32 & R/W & UART data\\\hline
UART   &\scalebox{0.8}{\tt 0x041c} & 32 & R/W & UART data\\\hline
VERSION &\scalebox{0.8}{\tt 0x0420} & 32 & R & Build date\\\hline
VERSION &\scalebox{0.8}{\tt 0x0420} & 32 & R & Build date\\\hline
Line 760... Line 963...
        \bitbox{15}{Currently Active Ints}
        \bitbox{15}{Currently Active Ints}
        \\
        \\
\end{bytefield}
\end{bytefield}
\caption{Programmable Interrupt Control (PIC) Register}\label{fig:picreg}
\caption{Programmable Interrupt Control (PIC) Register}\label{fig:picreg}
\end{center}\end{figure}
\end{center}\end{figure}
This controller supports up to fifteen interrupts, however only twelve are
This controller supports up to fifteen interrupts, however only eleven are
defined within the SoC.  These are listed in Tbl.~\ref{tbl:hw-ints}.
defined within the SoC, and of those only nine are defined in the primary
 
configuration.  All of these interrupts are listed in Tbl.~\ref{tbl:hw-ints}.
\begin{table}[htbp]
\begin{table}[htbp]
\begin{center}\begin{tabular}{|p{0.9in}|p{0.75in}|p{3.75in}|}\hline
\begin{center}\begin{tabular}{|p{0.9in}|p{0.75in}|p{3.75in}|}\hline
\rowcolor[gray]{0.85} Name & Bit Mask & Description \\\hline\hline
\rowcolor[gray]{0.85} Name & Bit Mask & Description \\\hline\hline
INT\_BUTTON & 0x001 & A Button has been pressed. \\\hline
INT\_BUTTON & 0x001 & A Button has been pressed. \\\hline
INT\_BUSERR & 0x002 & A Wishbone bus error has taken place\\\hline
INT\_BUSERR & 0x002 & A Wishbone bus error has taken place\\\hline
INT\_SCOPE  & 0x004 & The Scope has completed its collection\\\hline
INT\_SCOPE  & 0x004 & The Scope has completed its collection\\\hline
INT\_RTC    & 0x008 & An alarm or timer has taken place (assuming the RTC
%INT\_RTC    & 0x008 & An alarm or timer has taken place (assuming the RTC
                is installed, and includes both alarm or timer)\\\hline
%               is installed, and includes both alarm or timer)\\\hline
INT\_TIMA   & 0x010 & Timer-A has reached zero\\\hline
INT\_TIMER   & 0x010 & Timer-A has reached zero\\\hline
INT\_TIMB   & 0x020 & Timer-B has reached zero\\\hline
INT\_TIMB   & 0x020 & Timer-B has reached zero.  (Alternate config only.)
 
                \\\hline
INT\_UARTRX & 0x040 & A character has been received via the UART\\\hline
INT\_UARTRX & 0x040 & A character has been received via the UART\\\hline
INT\_UARTTX & 0x080 & The transmit UART is idle, and ready for its next
INT\_UARTTX & 0x080 & The transmit UART is idle, and ready for its next
                character.\\\hline
                character.\\\hline
INT\_KEYPAD & 0x100 & One of the keypad wires has been pulled low. \\\hline
INT\_KEYPAD & 0x100 & One of the keypad wires has been pulled low. \\\hline
INT\_AUDIO  & 0x200 & The audio device is ready for its next sample\\\hline
INT\_AUDIO  & 0x200 & The audio device is ready for its next sample\\\hline
Line 809... Line 1014...
Hence writing a {\tt 0x80010000} will enable interrupt line zero
Hence writing a {\tt 0x80010000} will enable interrupt line zero
({\tt INT\_BUTTON}), while also enabling all previously enabled interrupts.
({\tt INT\_BUTTON}), while also enabling all previously enabled interrupts.
To disable a specific interrupt, disable all interrupts and write a one to the
To disable a specific interrupt, disable all interrupts and write a one to the
enable line of the interrupt you wish to disable.  In this fashion, writing a
enable line of the interrupt you wish to disable.  In this fashion, writing a
{\tt 0x00010000} will disable all interrupts and leave interrupt line zero
{\tt 0x00010000} will disable all interrupts and leave interrupt line zero
disabled when the interrupts are re--enabled later, whereas {\tt 0x07fff0000}
disabled when the interrupts are re--enabled later, whereas {\tt 0x7fff0000}
will disable all specific interrupts.
will not only disable all interrupts, it will leave all all specific interrupts
 
disabled when interrupts are enabled again later.
 
 
Interrupts are acknowledged in a fashion similar to enabling interrupts.  By
Interrupts are acknowledged in a fashion similar to enabling interrupts.  By
writing a 1' to the active bit mask, the interrupt will be acknowledged and
writing a 1' to the active bit mask, the interrupt will be acknowledged and
reset, whereas writing a 0' leaves the interrupt untouched.  In this fashion,
reset, whereas writing a 0' leaves the interrupt untouched.  In this fashion,
as individual interrupts are handled, a 1' may be written to this bottom mask
as individual interrupts are handled, a 1' may be written to this bottom mask
Line 842... Line 1048...
causes it to stop.
causes it to stop.
 
 
The general purpose ZipTimer can be set to auto reload by setting the top bit
The general purpose ZipTimer can be set to auto reload by setting the top bit
as well as the interval.  When so set, the timer will automatically
as well as the interval.  When so set, the timer will automatically
load it's last set value upon reaching zero and interrupting the CPU.  This
load it's last set value upon reaching zero and interrupting the CPU.  This
effectively turns it into an interrupt timer if desired.  To set this feature,
effectively turns it into an interval timer.  To set this feature,
write to the timer the number of clock ticks before an interrupt, but also set
write to the timer the number of clock ticks before an interrupt, but also set
the high order bit.  In this fashion, writing a {\tt 0x8001387f} will interrupt
the high order bit.  In this fashion, writing a {\tt 0x8001387f} will interrupt
the CPU every millisecond, starting one millisecond after the write takes place
the CPU every millisecond, starting one millisecond after the write takes place
(assuming an 80~MHz system clock).\footnote{Note that, since the timer spends
(assuming an 80~MHz system clock).\footnote{Note that, since the timer spends
a cycle at zero, setting it for a 80,000 cycle period requires setting the
a cycle at zero, setting it for a 80,000 cycle period requires setting the
Line 860... Line 1066...
cause the CPU to reboot if for any reason it locked up and failed to interrupt
cause the CPU to reboot if for any reason it locked up and failed to interrupt
at the general timer interrupt request time.
at the general timer interrupt request time.
 
 
The ZipOS uses the ZipTimer for task swapping.  By setting the timer for
The ZipOS uses the ZipTimer for task swapping.  By setting the timer for
1~ms, the ZipOS examines every task for a potential task swap every millisecond.
1~ms, the ZipOS examines every task for a potential task swap every millisecond.
Of course, if the various tasks are running from Flash at 52~clocks per
Of course, if the various tasks are running from Flash at 17~clocks per
instruction, this means that as few as 1,538~instructions may be executed
instruction, this means that as few as \hbox{4,705~instructions} may be executed
between timer interrupts, but this can be tuned if necessary for better
between timer interrupts, but this can be tuned if necessary for better
performance.
performance.
 
 
\subsection{PWM Audio Controller}
\subsection{PWM Audio Controller}
The bit fields of the PWM Audio controller are shown in Fig.~\ref{fig:pwmreg}.
The bit fields of the PWM Audio controller are shown in Fig.~\ref{fig:pwmreg}.
Line 882... Line 1088...
\end{bytefield}
\end{bytefield}
\caption{PWM Audio Controller Bitfields}\label{fig:pwmreg}
\caption{PWM Audio Controller Bitfields}\label{fig:pwmreg}
\end{center}\end{figure}
\end{center}\end{figure}
This controller has been designed for easy writing.  To send a sample to the
This controller has been designed for easy writing.  To send a sample to the
PWM audio controller, simply write the sample to the controller and clear the
PWM audio controller, simply write the sample to the controller and clear the
PWM audio interrupt---{\em in that order}.  When the audio interrupts the CPU
PWM audio interrupt---{\em in that order}.  When the audio controller interrupts
again, it is ready for the next sample.  Do note, however, that the audio
the CPU again, it is ready for the next sample.
 
Do note, however, that the audio
interrupt can only be cleared once a new sample has been written to it.
interrupt can only be cleared once a new sample has been written to it.
Attempts to clear it prior to that will have no effect.  (This is why the
Attempts to clear it prior to that will have no effect.  (This is why the
order matters.)
order matters.)
 
 
The audio sample rate has been fixed at 8~kHz.  While changing this rate is
The audio sample rate has been fixed at 8~kHz.  This rate may be easily
easy to do within {\tt busmaster.v}, the rate itself takes some work to keep
changed within {\tt busmaster.v} by simply setting the number of clocks between
up with, so I wouldn't recommend going faster.
samples (currently set to \hbox{10,000}) and rebuilding the primary
 
configuration.  Whether or not the CPU can keep up with a higher rate might
 
be application dependent.
 
 
The audio controller supports two additional functionalities, however.  The
The audio controller supports two additional functionalities, however.  The
first is that the {\tt E} bit will be set upon any read when or if the audio
first is that the {\tt E} bit will be set upon any read when or if the audio
controller is ready for another sample and the Audio interrupt has been
controller is ready for another sample and the Audio interrupt has been
asserted.  By polling this bit, for example, the audio driver can be run without
asserted.  By polling this bit, for example, the audio driver can be run without
Line 954... Line 1163...
will turn LED0 on and then off again respectively.
will turn LED0 on and then off again respectively.
 
 
The keypad is a little bit tricker.  To wait for a keypad interrupt, one needs
The keypad is a little bit tricker.  To wait for a keypad interrupt, one needs
to set the column outputs to zero.  To do this, write a {\tt 0x0f00} to the
to set the column outputs to zero.  To do this, write a {\tt 0x0f00} to the
{\tt SPIO} register.  When a user then presses a key, one of the row inputs
{\tt SPIO} register.  When a user then presses a key, one of the row inputs
will go low and an interrupt will be asserted.  The key must then be debounced,
will go low and an interrupt will be asserted.  The key must then be debounced
and the ZipOS debounces keys for 5~ms.  Once debounced, the key may be read.
in software.  The ZipOS accomplishes this by waiting for 5ms.
 
Once debounced, the key may be read.
To do this, set half of the columns to zero, such as by writing a {\tt 0x0cf00}
To do this, set half of the columns to zero, such as by writing a {\tt 0x0cf00}
to the {\tt SPIO} register.  If one of the row values is still zero, then
to the {\tt SPIO} register.  If one of the row values is still zero, then
one of the two columns tested corresponded with the key.  This can then be
one of the two columns tested corresponded with the key.  This can then be
repeated until the correct column has been determined, at which point the
repeated until the correct column has been determined, at which point the
row can be read and the key known.
row can be read and the key known.
 
 
 
All of this functionality may be checked and tested by loading the alternate
 
configuration and either reading, {\tt wbregs spio}, or writing
 
{\tt wbregs spio <value>}.
 
 
The controller will generate a keypad interrupt whenever any row input is
The controller will generate a keypad interrupt whenever any row input is
zero, and a button interrupt whenever any button value is a one.  This is a
zero, and a button interrupt whenever any button value is a one.  This is a
level triggered interrupt, not edge triggered.  What that means is that,
level triggered interrupt, not edge triggered.  What that means is that,
once generated, the interrupt will need to be disabled until the key or button
once generated, the interrupt will need to be disabled until the key or button
is released---there will be no interrupt for the release, that part will need
is released---there will be no interrupt for the release, that part will need
Line 985... Line 1199...
is quite simple to use: when read, the top 16--bits indicate
is quite simple to use: when read, the top 16--bits indicate
the value of the 16--input GPIO pins, whereas the bottom 16--bits indicate
the value of the 16--input GPIO pins, whereas the bottom 16--bits indicate
the value being placed on the 16--output GPIO pins.  To change a GPIO pin,
the value being placed on the 16--output GPIO pins.  To change a GPIO pin,
write the new pin's value to this register, together with setting the
write the new pin's value to this register, together with setting the
corresponding pin in the bit-mask represented by the upper 16--bits.  For
corresponding pin in the bit-mask represented by the upper 16--bits.  For
example, to set output pin 0, write a {\tt 0x010001} to the GPIO device.  To
example, to set output pin zero, write a {\tt 0x010001} to the GPIO device.  To
clear output pin 0, write a {\tt 0x010000}.  Likewise pin two may be set by
clear output pin zero, write a {\tt 0x010000}.  Likewise pin one may be set by
writing a {\tt 0x020002}, and both pins may be set by writing {\tt 0x030003},
writing a {\tt 0x020002}, and both pins may be set by writing {\tt 0x030003},
etc.  This makes it possible to adjust some output pins independent of the
etc.  This makes it possible to adjust some output pins independent of the
others.
others.
 
 
The GPIO controller, like the keypad or SPIO controller, will also generate
The GPIO controller, like the keypad or SPIO controller, will also generate
Line 998... Line 1212...
changes.  The interrupt is not selective: if any line changes, a GPIO interrupt
changes.  The interrupt is not selective: if any line changes, a GPIO interrupt
will be generated.  There are no do not care'' lines (although the GPIO
will be generated.  There are no do not care'' lines (although the GPIO
controller could be easily adjusted to make such do-not-care'' lines if
controller could be easily adjusted to make such do-not-care'' lines if
necessary \ldots).
necessary \ldots).
 
 
Of the 16 GPIO inputs and the 16 GPIO outputs, two lines have been taken for
Of the 16~GPIO inputs and the 16~GPIO outputs, two lines have been taken for
I2C support, and a third has been stolen to make the PMod's fit on the
I2C support, and a third has been stolen to make the PMod's fit on the
board.  GPIO line zero, for both input and output, is an I2C data line,
board.  GPIO line zero, for both input and output, is an I2C data line,
{\tt io\_sda}, and GPIO line one is an I2C clock line, {\tt io\_scl}.  If the
{\tt io\_sda}, and GPIO line one is an I2C clock line, {\tt io\_scl}.  If the
output of either of these lines is set to zero, the GPIO controller will pull
output of either of these lines is set to zero, the GPIO controller will pull
the line low.  Otherwise, the line is pulled up so that other devices may pull
the line low.  Otherwise, the line is pulled up so that other devices may pull
Line 1014... Line 1228...
\subsection{UART Data Register}
\subsection{UART Data Register}
Moving on to the UART \ldots although the UART module itself
Moving on to the UART \ldots although the UART module itself
within the S6~SoC is highly configurable, as built
within the S6~SoC is highly configurable, as built
the UART can only handle 9600~Baud, 8--data bits, no parity, and one stop bit.
the UART can only handle 9600~Baud, 8--data bits, no parity, and one stop bit.
Changing this involves changing the constant {\tt UART\_SETUP} within
Changing this involves changing the constant {\tt UART\_SETUP} within
{\tt toplevel.v}.  Further,  the UART has only a single byte data buffer, so
{\tt toplevel.v}.
 
Further,  the UART has only a single byte data buffer, so
reading from the port has a real--time requirement associated with it: the
reading from the port has a real--time requirement associated with it: the
data buffer must be emptied before the next value is read.
data buffer must be emptied before the next value is read.
Attempts to read from this port will either return an 8--bit data value from
Attempts to read from this port will either return an 8--bit data value from
the port, or if no values are available it will return an {\tt 0x0100}
the port, or if no values are available it will return an {\tt 0x0100}
indicating that fact.  In general, reading from the UART port involves first
indicating that fact.  In general, reading from the UART port involves first
Line 1040... Line 1255...
OpenCores.
OpenCores.
 
 
\section{On-Chip Block RAM}
\section{On-Chip Block RAM}
 
 
The block RAM is the fastest memory available to the processor.  It is also
The block RAM is the fastest memory available to the processor.  It is also
the {\em only} writeable memory available to the processor.  Hence all
the {\em only} writable memory available to the processor.  Hence all
non-constant program data {\em must} be placed into block RAM.  The Zip~CPU
non-constant program data {\em must} be placed into block RAM.  The ZipCPU
can also run instructions from the block RAM if extra speed is desired.  When
can also run instructions from the block RAM if extra speed is desired.  When
runnning from block RAM, the Zip~CPU will nominally take 8~clocks per
running from block RAM, the ZipCPU will nominally take 6~clocks per
instruction, for an effective rate of 10~MIPS.  Loads or stores to block RAM
instruction, for an effective rate of 13~MIPS.  Loads or stores to block RAM
will take one clock longer.
will take one clock longer.
 
 
\section{Flash Memory}
\section{Flash Memory}
The flash memory has been arbitrarily sectioned into three sections, one for
The flash memory has been arbitrarily sectioned into three sections, one for
a primary configuration, a second section for an alternate configuration file,
a primary configuration, a second section for an alternate configuration file,
Line 1056... Line 1271...
Tbl.~\ref{tbl:flash-addresses}.
Tbl.~\ref{tbl:flash-addresses}.
\begin{table}[htbp]
\begin{table}[htbp]
\begin{center}\begin{tabular}{|p{0.75in}|p{0.75in}|p{0.5in}|p{3.0in}|}\hline
\begin{center}\begin{tabular}{|p{0.75in}|p{0.75in}|p{0.5in}|p{3.0in}|}\hline
\rowcolor[gray]{0.85} Start & End & & Purpose \\\hline\hline
\rowcolor[gray]{0.85} Start & End & & Purpose \\\hline\hline
\scalebox{0.9}{\tt 0x1000000} & \scalebox{0.9}{\tt 0x10fffff} & R & Primary configuration space\\\hline
\scalebox{0.9}{\tt 0x1000000} & \scalebox{0.9}{\tt 0x10fffff} & R & Primary configuration space\\\hline
\scalebox{0.9}{\tt 0x1100000} & \scalebox{0.9}{\tt 0x11fffff} & R & Alternate configuration space\\\hline
% \scalebox{0.9}{\tt 0x1100000} & \scalebox{0.9}{\tt 0x11fffff} & R & Alternate configuration space\\\hline
\scalebox{0.9}{\tt 0x1200000} & \scalebox{0.9}{\tt 0x1ffffff} & R & Zip~CPU program memory\\\hline
\scalebox{0.9}{\tt 0x1200000} & \scalebox{0.9}{\tt 0x1ffffff} & R & ZipCPU program memory\\\hline
\end{tabular}
\end{tabular}
\caption{Flash Address Regions}\label{tbl:flash-addresses}
\caption{Flash Address Regions}\label{tbl:flash-addresses}
\end{center}\end{table}
\end{center}\end{table}
The host program {\tt zipload} can be used to load a Zip~CPU program and
The host program {\tt zipload} can be used to load a ZipCPU program and
configuration files into this address space.  To use it, first load the
configuration files into this address space.  To use it, first load the
alternate configuration into the FPGA.  Then pass it, as arguments, the
alternate configuration into the FPGA.  Then pass it, as arguments, the
primary, and alternate (if desired), configuration files followed by the
primary, and alternate (if desired), configuration files followed by the
Zip~CPU program file.  Then, when the primary configuration is loaded again,
ZipCPU program file.  Then, when the primary configuration is loaded again,
perhaps upon power up, the Zip~CPU will automatically start running from it's
perhaps upon power up, the ZipCPU will automatically start running from it's
{\tt RESET\_ADDRESS}, {\tt 0x480000}.
{\tt RESET\_ADDRESS}, {\tt 0x1200000}.
 
 
When running from Flash memory, the Zip~CPU will nominally take 52~clocks per
When running from Flash memory, the ZipCPU will nominally take 17~clocks per
instruction, for an effective speed of about 1.5~MIPS.
instruction, for an effective speed of about 4.7~MIPS.
 
 
When using {\tt zipload}, the first bit file argument will load the first
When using {\tt zipload}, the first bit file argument will load the first
configuration space, the second bit file argument will load the second
configuration space, the second bit file argument will load the second
configuration space, and the third argument will load the Zip~CPU program
configuration space, and the third argument will load the ZipCPU program
into its space.
into its space.
 
 
\chapter{Clocks}
\chapter{Clocks}
 
 
The S6~SoC is designed to run off of one master clock.  This clock is derived
The S6~SoC is designed to run off of one master clock.  This clock is derived
Line 1089... Line 1304...
 
 
Table.~\ref{tbl:ioports}
Table.~\ref{tbl:ioports}
\begin{table}[htbp]
\begin{table}[htbp]
\begin{center}
\begin{center}
\begin{portlist}
\begin{portlist}
i\_clk\_8mhz & 1 & Input & Clock\\\hline
i\_clk\_8mhz & 1 & Input & 8~MHz Input Clock\\\hline
o\_qspi\_cs\_n & 1 & Output & Quad SPI Flash chip select\\\hline
o\_qspi\_cs\_n & 1 & Output & Quad SPI Flash chip select\\\hline
o\_qspi\_sck & 1 & Output & Quad SPI Flash clock\\\hline
o\_qspi\_sck & 1 & Output & Quad SPI Flash clock\\\hline
io\_qspi\_dat & 4 & Input/Output & Four-wire SPI flash data bus\\\hline
io\_qspi\_dat & 4 & Input/Output & Four-wire SPI flash data bus\\\hline
i\_btn & 2 & Input  & Inputs from the two on-board push-buttons\\\hline
i\_btn & 2 & Input  & Inputs from the two on-board push-buttons\\\hline
o\_led & 4 & Output & Outputs controlling the four on-board LED's\\\hline
o\_led & 4 & Output & Outputs controlling the four on-board LED's\\\hline`