Subversion Repositories s6soc

\documentclass{gqtekspec}

\usepackage{import}

\usepackage{bytefield}

\project{CMod S6 SoC}

\title{Specification}

\author{Dan Gisselquist, Ph.D.}

\email{dgisselq (at) opencores.org}

\revision{Rev.~0.2}

\begin{document}

\pagestyle{gqtekspecplain}

\titlepage

\begin{license}

Copyright (C) \theyear\today, Gisselquist Technology, LLC

This project is free software (firmware): you can redistribute it and/or

modify it under the terms of  the GNU General Public License as published

by the Free Software Foundation, either version 3 of the License, or (at

your option) any later version.

This program is distributed in the hope that it will be useful, but WITHOUT

ANY WARRANTY; without even the implied warranty of MERCHANTIBILITY or

FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License

for more details.

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.

\end{license}

\begin{revisionhistory}

0.1 & 4/22/2016 & Gisselquist & First Draft \\\hline

\end{revisionhistory}

% Revision History

% Table of Contents, named Contents

\tableofcontents

\listoffigures

\listoftables

\begin{preface}

The Zip CPU was built with the express purpose of being an area optimized,

32--bit FPGA soft processor.

The S6~SoC is designed to prove that the ZipCPU has met this goal.

\end{preface}

\chapter{Introduction}

\pagenumbering{arabic}

\setcounter{page}{1}

This project is ongoing.  Any and all files, to include this one, are subject

to change without notice.

This project comes from my desire to demonstrate the Zip CPU's utility in a

challenging environment.  The CMod~S6 board fits this role nicely.

\begin{enumerate}

\item The Spartan--6 LX4 FPGA is very limited in it's resources:

        It only has 2,400 look--up tables (LUTs), and can only support

        a 4,096~Word RAM memory (16 kB).

\item With only 4kW RAM, the majority of any program will need to be placed into

        and run from flash.  (The chip will actually support more, just not

        8k RAM.)

\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,

        wishbone command access from the UART, pipelined CPU operations, and

        more.  Other solutions will need to be found.

\end{enumerate}

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

expensive, it is still an order of magnitude greater than it's CPU competitors

in price.  This includes such CPU's as the Raspberry Pi Zero, or even the

TeensyLC.

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 project

will demonstrate that utility and possibility.  Alternatively, if you wish to

study how to get a CPU to work in a small, constrained environment, this project

may be what you are looking for.

\chapter{Architecture}

Fig.~\ref{fig:architecture}

\begin{figure}\begin{center}

\includegraphics[width=5in]{../gfx/s6bones.eps}

\caption{CMod S6 SoC Architecture: ZipCPU and

        Peripherals}\label{fig:architecture}

\end{center}\end{figure}

shows the basic internal architecture of the S6~SoC.  In summary, it consists of a CPU

coupled with a variety of peripherals for the purpose of controlling the

external peripherals of the S6: flash, LEDs, buttons, and GPIO.  External

devices may also be added on, such as an audio device, an external serial

port, an external keypad, and an external display.  All of these devices

are then available for the CPU to interact with.

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

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.

Further, the ZipCPU has no ability to write to flash memory.  For this reason,

there exists an alternate CMod S6~SoC architecture, as shown in

Fig.~\ref{fig:altarchitecture}.

\begin{figure}\begin{center}

\includegraphics[width=5in]{../gfx/altbones.eps}

\caption{Alternate CMod S6 SoC Architecture: Peripherals, with no

        CPU}\label{fig:altarchitecture}

\end{center}\end{figure}

Using this alternate architecture, it should be possible to test the peripherals

and program the flash memory.  Both architectures may be loaded into the flash,

together with the programming code for the Zip CPU.

The basic approach is simple: up and until the software works, the S6 will

power up into the alternate architecture of Fig.~\ref{fig:altarchitecture}.

While in this state, the flash may be examined and programmed.  Once complete,

a UART command to the ICAPE port will tell the S6 to load the (primary)

FPGA configuration from an alternate flash location.  This alternate location

will contain a configuration image containing the CPU.  The CPU will then begin

following the instructions given to it from the flash.

\chapter{Operation}

\chapter{Registers}

There are several address regions on the S6~SoC, as shown in

Tbl.~\ref{tbl:memregions}.

\begin{table}[htbp]

\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

\scalebox{0.9}{\tt 0x000100} & \scalebox{0.9}{\tt 0x000107} & R/W & Peripheral I/O Control \\\hline

\scalebox{0.9}{\tt 0x000200} & \scalebox{0.9}{\tt 0x000201} & R/(W) & Debugging scope\\\hline

\scalebox{0.9}{\tt 0x000400} & \scalebox{0.9}{\tt 0x00043f} & R/W & Internal Configuration Access Port\\\hline

\scalebox{0.9}{\tt 0x000800} & \scalebox{0.9}{\tt 0x000803} & R/W & RTC Clock (if present)\\\hline

\scalebox{0.9}{\tt 0x002000} & \scalebox{0.9}{\tt 0x002fff} & R/W & 16kB On-Chip Block RAM \\\hline

\scalebox{0.9}{\tt 0x400000} & \scalebox{0.9}{\tt 0x7fffff} & R & 16~MB SPI Flash memory\\\hline

\end{tabular}

\caption{Address Regions}\label{tbl:memregions}

\end{center}\end{table}

In general, the address regions that are made up of RAM or flash act like

memory.  The RAM can be read and written, and the flash acts like read only

memory.

This isn't quite so true with the other address regions.  Accessing the I/O

region, while it may be read/write, may have side-effects.  For example, reading

from the debugging scope device's data port will read a word from the scope's

buffer and advance the buffer pointer.

\section{Debugging Scope}

The debugging scope consists of two registers, a control register and a data

register.  It needs to be internally wired to 32--wires, internal to the S6

SoC, that will be of interest later.  For further details on how to configure

and use this scope, please see the {\tt WBSCOPE} project on OpenCores.

\section{Internal Configuration Access Port}

The Internal Configuration Access Port (ICAP) provides access to the internal

configuration details of the FPGA.  This access was designed so as to provide

the CPU with the capability to command a different FPGA load.  In particular,

the code in Fig.~\ref{fig:reload} should reconfigure the FPGA from any given

Quad SPI {\tt address}.\footnote{According to Xilinx's technical support, this

will only work if the JTAG port is not busy.}

\begin{figure}\begin{center}\begin{tabbing}

{\tt warmboot(uint32 address) \{} \\

\hbox to 0.25in{}\={\tt uint32\_t *icape6 = (volatile uint32\_t *)0x{\em <ICAPE port address>};}\\

 \>{\tt icape6[13] = (address<<2)\&0x0ffff;}\\

 \>{\tt icape6[14] = ((address>>14)\&0x0ff)|((0x03)<<8);}\\

 \>{\tt icape6[4] = 14;}\\

 \>{\em // The CMod~S6 is now reconfiguring itself from the new address.}\\

 \>{\em // If all goes well, this routine will never return.}\\

{\tt \}}

\end{tabbing}

\caption{Spartan--6 ICAPE Usage}\label{fig:reload}

\end{center}\end{figure}

For further details, please see either the {\tt WBICAPETWO} project on OpenCores

as well as Xilinx's ``Spartan-6 FPGA Configuration User Guide''.

\section{Real--Time Clock}

The Real Time Clock will be included if there is enough area to support it.

The four registers correspond to a clock, a timer, a stopwatch, and an alarm.

If space is tight, the timer and stopwatch, or indeed the entire clock, may be

removed from the design.  For further details regarding how to set and use this

clock, please see the {\tt RTCCLOCK} project on OpenCores.

\section{I/O Peripherals}

Tbl.~\ref{tbl:ioregs}

\begin{table}[htbp]

\begin{center}\begin{reglist}

PIC    &\scalebox{0.8}{\tt 0x0100} & 32 & R/W & Interrupt Controller \\\hline

BUSERR &\scalebox{0.8}{\tt 0x0101} & 32 & R & Last Bus Error Address\\\hline

TIMA   &\scalebox{0.8}{\tt 0x0102} & 32 & R/W & ZipTimer A\\\hline

TIMB   &\scalebox{0.8}{\tt 0x0103} & 32 & R/W & ZipTimer B\\\hline

PWM    &\scalebox{0.8}{\tt 0x0104} & 32 & R/W & PWM Audio Controller\\\hline

KYPAD  &\scalebox{0.8}{\tt 0x0105} & 32 & R/W & Special Purpose I/O, Keypad, LED Controller \\\hline

GPIO   &\scalebox{0.8}{\tt 0x0106} & 32 & R/W & GPIO Controller \\\hline

UART   &\scalebox{0.8}{\tt 0x0107} & 32 & R/W & UART data\\\hline

\end{reglist}

\caption{I/O Peripheral Registers}\label{tbl:ioregs}

\end{center}\end{table}

shows the addresses of various I/O peripherals included as part of the SoC.

The interrupt controller is identical to the one found with the ZipSystem.

Please read the ZipSystem documentation for how to control this.

The Bus Error peripheral simply records the address of the last bus error.

This can be useful when debugging.  While the peripheral may only be read,

setting it is really as easy as creating a bus error and trapping the result.

The two ZipTimer's are ZipSystem timer's, placed onto this peripheral bus.

They are available for the CPU to use.  Common uses might include I2C or SPI

speed control, or multi--tasking task-swap control.  For further details, please

see the ZipSystem documentation.

Audio Controller

Register {\tt KYPAD}, as shown in Fig.~\ref{fig:spioreg},

\begin{figure}\begin{center}

\begin{bytefield}[endianness=big]{32}

\bitheader{0-31} \\

\begin{leftwordgroup}{Read}\bitbox[lrt]{16}{Zeros}

        \bitbox[lrt]{4}{Kpad}

        \bitbox[lrt]{4}{Kpad}

        \bitbox[lrt]{2}{00}

        \bitbox[lrt]{2}{Btn}

        \bitbox[lrt]{4}{LED} \\

\bitbox[lrb]{16}{}

        \bitbox[lrb]{4}{Col Out}

        \bitbox[lrb]{4}{Row In}

        \bitbox[lrb]{2}{}

        \bitbox[lrb]{2}{}

        \bitbox[lrb]{4}{}\end{leftwordgroup} \\

\begin{leftwordgroup}{Write}\bitbox[lrt]{16}{Ignored}

        \bitbox[lrt]{4}{Col}

        \bitbox[lrt]{4}{Col}

        \bitbox[lrt]{4}{LED}

        \bitbox[lrt]{4}{LED} \\

\bitbox[lrb]{16}{}

        \bitbox[lrb]{4}{Out}

        \bitbox[lrb]{4}{Enable}

        \bitbox[lrb]{4}{Enable}

        \bitbox[lrb]{4}{}\end{leftwordgroup} \\

\end{bytefield}

\caption{SPIO Control Register}\label{fig:spioreg}

\end{center}\end{figure}

is a Special Purpose Input/Output (SPIO) register. It is

designed to control the on-board LED's, buttons, and keypad.  Upon any read,

the register reads the current state of the keypad column output, the keypad

row input, the buttons and the LED's.  Writing is more difficult, in order to

make certain that parts of these registers can be modified atomically.

Specifically, to change an LED, write the new value as well as a `1' to the

corresponding LED change enable bit.  The same goes for the keypad column

output, a `1' needs to be written to the change enable bit in order for a

new value to be accepted.

The controller will generate a keypad interrupt whenever any row input is

zero, and a button interrupt whenever any button value is a one.

The General Purpose Input and Output (GPIO) control register, shown in

Fig.~\ref{fig:gpioreg},

\begin{figure}\begin{center}

\begin{bytefield}[endianness=big]{32}

\bitheader{0-31} \\

\bitbox[lrtb]{16}{Current Input Vals (x16)}\bitbox[lrt]{16}{Current Output} \\

\bitbox[lrtb]{16}{Output Change Enable}\bitbox[lrb]{16}{Values (16-outs)}

\end{bytefield}

\caption{GPIO Control Register}\label{fig:gpioreg}

\end{center}\end{figure}

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 being placed on the 16--output GPIO pins.  To change a GPIO pin,

write the new pins value to this register, together with setting the

corresponding pin in the upper 16--bits.  For example, to set output pin 0,

write a {\tt 0x010001} to the GPIO device.  To clear output pin 0, write a

{\tt 0x010000}.  This makes it possible to adjust some output pins independent

of the others.

The GPIO controller, like the keypad or SPIO controller, will also generate

an interrupt.  The GPIO interrupt is generated whenever a GPIO input line

changes.

Of the 16 GPIO inputs and the 16 GPIO outputs, two lines have been taken for

I2C support.  GPIO line zero, for both input and output, is an I2C data line,

and GPIO line one is an I2C clock line.  If the output of either of these

lines is set to zero, the GPIO controller will drive the line.  Otherwise,

the line is pulled up with a weak resistor so that other devices may

pull it low.  If either line is low, when the output control bit is high,

it is an indicator that another device is sending data across these wires.

Moving on to the UART \ldots

although the UART module 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.

There is a single byte data buffer, so reading from the port has a real--time

requirement associated with it.

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}

indicating that fact.  In a similar fashion, writes to this port will send

the lower 8--bits of the write out the serial port.  If the port is already

busy, a single byte will be buffered.

\chapter{Clocks}

The S6~SoC is designed to run off of one master clock.  This clock is derived

from the 8~MHz input clock on the board, by multiplying it up to 80~MHz.

\chapter{IO Ports}

See Table.~\ref{tbl:ioports}.

\begin{table}[htbp]

\begin{center}

\begin{portlist}

i\_clk\_8mhz & 1 & Input & Clock\\\hline

o\_qspi\_cs\_n & 1 & Output & Quad SPI Flash chip select\\\hline

o\_qspi\_sck & 1 & Output & Quad SPI Flash clock\\\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

o\_led & 4 & Output & Outputs controlling the four on-board LED's\\\hline

o\_pwm & 1 & Output & Audio output, via pulse width modulator\\\hline

\multicolumn{2}{|l|}{o\_pwm\_shutdown\_n, 1}& Output & Audio output shutdown control\\\hline

o\_pwm\_gain & 1 & Output & Audio output 20~dB gain enable\\\hline

i\_uart & 1 & Input &  UART receive input\\\hline

o\_uart & 1 & Output & UART transmit output\\\hline

i\_uart\_cts & 1 & Input &  \\\hline

o\_uart\_rts & 1 & Output & \\\hline

i\_kp\_row & 4 & Output & Four wires to activate the four rows of the keypad\\\hline

o\_kp\_col & 4 & Output & Return four wires, from the keypads columns \\\hline

i\_gpio & 14 & Output & General purpose logic input lines\\\hline

o\_gpio & 14 & Output & General purpose logic output lines\\\hline

io\_scl & 1 & Input/Output & I2C clock port\\\hline

io\_sda & 1 & Input/Output & I2C data port\\\hline

\end{portlist}

\caption{List of IO ports}\label{tbl:ioports}

\end{center}\end{table}

\begin{table}

\begin{center}

\includegraphics[height=7in]{../gfx/pinout.eps}

\caption{Physical Locations of Device I/O Ports}\label{tbl:physicalio}

\end{center}\end{table}

% Appendices

% Index

\end{document}