% -*- Mode:Text -*- 
\chapter{Introduction}\sectlabel{intro}

\Step\ is an indefinitely scalable multiprocessor architecture
optimized for the fine-grained simulations of physical systems.  From
a functional viewpoint, the \step\ architecture can be thought of as
a spatially-extended, uniform, fine-grained medium of a rather general
and abstract nature.  Specific behavior is obtained by specifying the
medium's connectivity and dynamical properties, and assigning its
initial state.  In this sense, \step\ embodies the metaphor of
``programmable matter.''

\medskip

The present \AR\ discusses those functional and structural aspects of \step's
hardware that are of interest to the planner, the programmer, and the
sophisticated user.  It does not address issues of modeling
methodology. Issues of digital design or electronic engineering are dealt
with only insofar as they clarify the reasons for certain design choices, and
thus have tutorial or mnemonic value.


\section{System overview}\label{sect.system-overview}

In the \step\ architecture, the system being modeled is represented by a
collection of discrete \tdf{cells} arranged in a regular \tdf{lattice}.
This lattice may have more or fewer than three dimensions, it may have an
arbitrary crystallographic structure\footnote
	{Cf.\ Neil \tsc{Ashcroft} and David \tsc{Mermin}, {\sl Solid
State Physics}, Saunders College (1976).}
	(in particular, it need not be a cubic lattice), and may or
may not be wrapped around.

An equal amount of data storage capacity is allocated to every lattice
cell, for representing in a distributed way the system's state
variables, its parameters, and other information useful for processing
and analyzing the system's state. Depending on the nature of the
system, the appropriate cell capacity may range from a few bits to
thousands of bits.

\medskip

For processing purposes, the entire volume comprising the lattice is divided
into a number of identical \tdf{sectors}; each sector is handled by a
separate hardware processor called a \tdf{module}, which contains all the
resources---\emph{state variables} and \emph{updating machinery}---needed to
implement the system's dynamics for that sector.

A \step\ machine consists of a three-dimensional array of \emph{modules},
which are functionally arranged on a three-dimensional torus (the actual
physical arrangement is somewhat different). That is, each dimensions wraps
around on itself; the number of modules along each dimension, though finite,
can be arbitrarily large.  The modules all work in parallel and in lockstep,
directly exchanging information only with contiguous modules.

\medskip

Cells within each sector are updated serially: on each updating scan through
the sector a single processor is time-shared between the cells in such a way
as to simulate the parallel operation of an equivalent number of identical
virtual processors. A complete update of the lattice, in which all cell state
components are appropriately updated, may require several scans.  Since the
results of each scan are, in ordinary circumstances, independent of the order
in which the cells are accessed, the scanning order itself can be chosen so
as to accomodate particular display or analysis needs.  Moreover, the
updating algorithm may change from one update operation to the next, so as to
implement a \emph{time-dependent} dynamics.

Data communication between cells during each updating pass is not restricted
to the immediate neighbors in the lattice. Indeed, one of the features that
distinguish the \step\ architecture from more ``obvious'' cellular automata
architectures is that essentially instantaneous communication can be achieved
between cells that are hundreds or thousands of positions apart. Thus, short-
and long-range interactions are efficiently handled at the same time by the
updating machinery.

Pipelining of address arithmetic, read, update, and write operations,
together with ``flash'' updating based on lookup tables, yield a high rate of
serial updating: for 16-bit cells, 25 Megacells/sec per module in the current
implementation.

The \step\ machine is controlled by a \tdf{host} computer through a
\tdf{controller} board that sits on the host's bus. The controller
communicates with the array of modules via a special tree-shaped bus, called
the \tdf{\bus}, which distributes commands and data to the modules and
collects status reports and data from them.

\medskip

In the current implementation, the physical building block of a \step\
machine is not a single module but an assembly of eight modules called a
\emph{box}. The box provides mechanical and electrical support (backplane,
enclosure, power, cooling) to the eight modules.  A board called the \tdf{box
interface}, plugged in the backplane alongside the modules, provides some
box-wide inteface functions such as clock regeneration/distribution and \bus\
buffering. This board may also contain a frame buffer, \vga\ output, and
video \io\ circuitry, in which case it is called the \tdf{video board}.

Boxes are physically stacked in a three-dimensional array, and exchange
information only with adjacent boxes.  The smallest viable \step\ machine
consists of a single box populated by a single module. Conceptually, there is
no upper limit to machine size; in practice, a limit is set by economic
factors sooner than by engineering constraints.  Installations consisting of
hundreds or thousands of modules are feasible and, in terms of useful
modeling applications, desirable.

\medskip

Within each module, ordinary dynamic \tsc{ram} chips (\dram) are used to
store cell data. The sytem's dynamics is defined by lookup tables, which are
stored in ordinary static \tsc{ram} chips (\sram). The ``glue'' that turns
these generic commodities into a powerful and flexible modeling environment
is represented by a custom \vlsi\ chip---called the \tdf{\chip}---of which
there are a set of sixteeen in each module.  This set works as a tightly
integrated team, and is indeed called a \chip\ \emph{\team}.

\medskip

A faithful and efficient software simulator for the \step\
architecture is available. The current version runs on a
\sparcstation, but is easily portable to other platforms. For many
applications, a viable approach is to develop an experiment on the
software simulator---on a lattice of only tens of thousands of
sites---and then run the \emph{identical} experiment on a lattice of
millions or billions of sites on a \step\ machine.


\section{\Step's machine language}\label{sect.machine-language}

The \step\ architecture gives one great flexibility in specifying the
features of the conceptual model that is the object of the simulation.
Subject to a single quantitative constraint, i.e., the number of
\step\ modules available, the user has great latitude in choosing the
dimensionality of the lattice, its crystallographic group, and its
extension in each of the dimensions; the size and the internal
structure of the cells, as well as the interconnectivity of the cells
within the lattice; the sequencing of updating steps and algorithmic
details of each step; and, finally, the strategies for real-time data
analysis and display and the related input/output tactics.

It must be understood that this great variety of high-level features are
synthesized from a basic set of low-level, native features of the
\step\ architecture---a simple, well-structured, highly orthogonal
set of machine primitives.

The main goal of this manual is to provide a ``programmer's model'' of
\step\ appropriate to this synthesis taks. That is, our chief concern
will be to introduce, explain, and document those aspects of the
hardware that are meant to be visible to the programmer.  In this
respect, we shall deal with primitive concepts such as \emph{sites} and
\emph{layers}, \emph{kicks} and \emph{glue}, \emph{lookup tables} and {\em
events}. Common \step-programming constructs such as \emph{lattice},
\emph{cells}, and \emph{steps} will be mentioned, but they properly
belong to the application-language rather than machine-language level.

Ultimately, \step\ programming is reduced to writing to (and
occasionally reading from) a set of hardware registers. Only about a
dozen of these registers are of direct concern to the user, when
programming at the machine-language level. Even if programming is done
through a compiler, the user should be generally aware of the existence
and function of these registers. The other registers---used for setup,
interrupt control, and diagnostics---are handled by system calls and
are of concern only to systems programmers.


\section{Organization of this manual}\sectlabel{manual}

\chapt{structure} describes the overall structure of the \step\
system and highlights its chain of command.

Though commands are passed down to and interpred by different
levels of the hardware hierarchy, the \step\ programmer, as the
commander, need only speak one language---that of the ``control
room;'' this is described in \chapt{control}.

Of course, the commands must refer to data structures and processing
mechanims available within the \step\ machine. The remaining chapters
give a ``programmer's model'' of these structures and mechanisms, and
provide motivation, explanation, and examples.

\chapt{geo} presents the basic geometrical and kinematical
aspects of \step's data organization, data movement, and data
interaction. \chapt{stream} discusses the data streams within a module
and the way they are steered. \chapt{io} describes real-time input/output
resources. \chapt{addressing} describes the way
modules are interconnected, and how they are addressed.

\appnd{driver} is the reference for the \step\ driver.  \appnd{regs}
describes in detail the \chip\ registers, which are the explicit
target of all \step\ commands; thus, this appendix can be used as a
concise but comprehensive reference for all \step\ programming.

\medskip

A companion volume, \step\ \emph{Hardware Reference}, describes the
four levels of the \step\ hardware hierarchy, namely, \emph{machine},
\emph{box}, \emph{module}, and \emph{\chip}, specifying in detail
the physical interface between adjacent levels.


\section{Conventions}\sectlabel{conventions}

\input ../+conventions
