% -*- Mode:Text -*- 
\chapter{System structure}\label{sect.structure}

The bulk of \step's data processing activity is uniformly distributed
over the \step\ \tdf{space}---an indefinitely-extended array of
``computationally active'' sites---as explained in \sect{geo},
\sect{source-dest}. This activity, however, is organized and
controlled, from a single point, by a conventional serial
computer---the host.  Here we outline the ``chain of command'' that
leads from the host to the \step\ space. Some optional ``lateral''
channels, devoted to real-time input/output, are grafted on this
chain; use of these channels is controlled by the host, but the
real-time data that they carry do not go through the host itself.


\section{From host to modules}\label{sect.chain-of-command}

The \step\ space is subdivided into equal portions called \tdf{sectors}
(\sect{geo}). Each sector is handled by a hardware \tdf{module} which
provides all the physical resources necessary to implement the sector's
logical activity; this includes lookup tables, hardware counters,
configuration parameters, data channels between adjacent sectors, and
interface with the chain of command.

The activity of the assembly of modules that make up a \step\ \tdf{machine}
is governed and monitored by a general-purpose computer called the
\tdf{host}. The host we are currently using is a \sun\
\sparcstation---which features a high-performance external bus called
the \tdf{\sbus}.

All exchanges between the host and the \step\ machine are mediated by the
\step\ \tdf{\ctrler} (\fig{two-buses}), which communicates with the host on
the \sbus and drives the modules via the \tdf{\bus}; the latter is a
tree-like bus having the \ctrler\ at its root and the individual modules at
its leaves. Physically, the \ctrler\ consists of a small board plugged into
one of the \sbus\ slots.

\medskip

In what follows, the \step\ \ctrler\ and the \step\ machine will simply
be called `the \ctrler' and `the machine'.

 \figonecol{two-buses}{
 \begin{picture}(224,88)(0,0)
	\thinlines
	\put(0,0){\framebox(96,80){}}
	\put(32,32){\framebox(48,32){\shortstack{\step\\\ctrler}}}
	\multiput(208,18)(0,16){4}{\framebox(12,12){}}
	\thicklines
	\put(16,8){\line(0,1){64}}

	\put(80,48){\line(1,0){64}}
	\put(144,48){\circle*{4}}
	\put(144,48){\line(2,1){32}}
	\put(144,48){\line(2,-1){32}}

	\multiput(176,32)(0,32){2}{\line(4,1){32}}
	\multiput(176,32)(0,32){2}{\line(4,-1){32}}
	\multiput(176,32)(0,32){2}{\circle*{4}}

	\put(16,48){\line(1,0){16}}
	\put(30,16){\makebox(0,0){\sbus}}
	\put(144,62){\makebox(0,0){\bus}}
	\put(0,0){\makebox(224,16)[r]{\step\ modules}}
	\put(0,80){\makebox(96,16){host}}
 \end{picture}
 }{The \step\ \ctrler\ drives the assembly of \step{} modules via the
tree-like \bus; it communicates with the host via the \sbus.}


\section{Boxes and cables}\label{sect.boxes}

As explained in \sect{block-structure}, it is convenient to group
sectors into \tdf{blocks}. Each block consists of eight sectors that
stand in a distinguished geometrical relationship with one another
within \step\ space. To this functional grouping there corresponds (in
the present implementation of \step) a discrete physical assembly,
called a \step\ \tdf{box}, consisting of eight modules, a backplane, an
enclosure, and some ancillary circuitry. 

Thus, from a practical viewpoint, a \step\ machine consists either of a
single box, or of an array of boxes (preferably a power of two) with cables
interconnecting adjacent boxes.  A short length of \bus\ cable---the
\tdf{host link}---leads from the \step\ \ctrler\ in the host to the ``corner
box'' of the array.


\section{Host/controller interaction}\label{sect.host/controller}

The ``program'' that the \ctrler\ executes consists of a sequence of
instructions, called \tdf{step list}, residing in the host's
memory.\footnote
	{The step list is analogous to the \emph{display list} routinely
used for interfacing a conventional processor to a specialized,
high-performance graphics processor.}
	The step-list instructions are translated by the controller
into commands to be broadcast on the \bus. Most commands entail
transfering a block of data from a memory buffer on the host to the
machine or viceversa; the data themselves pass through the \ctrler,
which is responsible for accessing host memory locations.

Typically, the step list and the associated data buffers will have
been constructed at leisure by a user program running under \unix,
without concern for real-time performance. On the other hand,
dependable real-time performance is expected of the \ctrler; to this
end, the \ctrler\ is given \emph{bus master} access to the \sbus\
memory when interpreting a step list.

To gain the attention of the host (for instance to tell that it has
reached the end of the current step list, or in order to respond to
exceptions signaled by the \step\ machine) the \ctrler\ may issue
\sbus\ interrupts.

\medskip

All other communication between the host and the \ctrler\ (for
instance, to start the \ctrler\ on a new step list, or to perform
initialization or readout functions) is initiated by the host. The
\ctrler\ contains a number of hardware registers, called \tdf{control
registers}, which are use to initialize, direct, and monitor its
operation (\sect{controller}). These registers, some parts of
which are read-only, some write-only, and others read/write, are
memory mapped on the \sbus\ as four consecutive 32-bit words. In this
mode of communication, the hosts acts as a bus master and accesses the
appropriate control registers.

\medskip

The fundamental cycle of interaction between the host and the \step\
\ctrler\ revolves around the {\sym Next List Pointer} register ({\sym
NLP})---which acts as a mailbox---as follows (\cf{NLP})
 \begin{enumerate}
	\item Whenever the host has a step list that it wishes to be
executed, it looks at the {\sym NLP}; as soon as it finds it empty, it
puts in it a pointer to this step list.
	\item Whenever the controller is idle, it looks at the {\sym
NLP}.  As soon as it finds a step list pointer in it, it takes it
(leaving the register empty) and starts executing the step list.
 \end{enumerate}


\section{Controller/module interaction}\label{sect.controller/module}

\subsection{\bus\ transactions}

The \step\ \ctrler\ communicates with the modules via the \bus.  From
the software viewpoint, little need be known about the physical
realization of this bus.  The entire \bus\ structure, from the
controller through the bus itself to the modules consists of 16
identical \tdf{slices} which operate in parallel and in lockstep.  The
description that follows refers to an individual slice.

Every \bus\ transaction can be thought of as an access (read or write)
to the \chip\ \tdf{register address space}, which consists of 32
locations (of which 29 are actually used).  The address, which is sent
first (and is the same for all slices), is monitored by all modules.
This address refers to a register location in \chip\ register address
space.  Though all modules map onto the same address space, only
selected modules will take part in the subsequent data exchange.  The
selection status of modules (individually, as members of a group, or
in their totality) is dynamically updated by a separate selection
mechanism involving the {\sym Module Select Register}
(\cf{modselect}).  On read transactions, one must insure that no more
than one module happens to be selected; write transactions, on the
other hand, may involve more than one module (most of them involve
\emph{all} modules).

\subsection{\STEP{}chip registers}\sectlabel{chip-regs}

The 29 \chip\ registers come in different lengths. Most of these
registers have a fixed length, ranging from 1 to 120 bits. Two
registers, however, namely the {\sym LUT I/O Register} (\sect{LIOR})
and the {\sym Scan I/O Register} (\sect{SIOR}), are actually serial
data ports used to download or upload selected regions of,
respectively, the \dram\ and \sram\ areas of a module.  For these two
registers, the length of the desired data transfer---which plays the
role of register length---must be explicitly programmed by the
\ctrler\ into the chip before the transfer itself takes place.

\medskip

Many of the \chip\ registers are logically collections of shorter
registers that have been put together under a single register address
for convenience and efficiency. For example, the six-bit {\sym Event
Counter Source Register} (\sect{ECSR}) consists of (a) a two-bit field
selecting one of four possible data sources for the event counter and
(b) a four-bit field specifying how this source is to be combined with
another fixed source.


\section{Real-time channels}\sectlabel{rt-channels}

In addition to communicating with the host, the \step\ machine can
communicate with the outside world through a \tdf{flywheel} bus that
sequentially addresses \step\ space sites as they are being scanned
\cf{scanner}. Different kinds of data associated with each site can be read
or written on-the-fly by any device having adequate real-time response.  A
distinguished output tap on the flywheel bus, called the \tdf{display} bus,
is typically dedicated to raster-scan display.

Special hardware is provided on each box to support real-time
input/output. Image data can be fed to a module from a video camera (the
video board provides 8-bit analog-to-digital conversion), and module data can
be displayed (directly or via a frame buffer) to a \vga-like monitor (the
video board provides a 256-color video palette followed by a triple 8-bit
digital-to-analog converter for red, green, and blue.  Both camera and \vga\
sync are provided, supporting a usable frame of 512\by512 pixels at 50 or 60
frames/sec.  The \vga\ output is accompanied by a \vga-to-video converter
(\ntsc\ or \pal\ format) with both composite output and separate
luminance and chrominance outputs (\tsc{s/vhs}).


\section{Software}\label{sect.software}

For the sake of programming discipline, all communication between host
software and the \step\ controller is routed through a dedicated,
low-level software interface called the \step\ \tdf{device driver}.
The \step\ driver is only of concern to systems sofware developers.
Its specifications are found in \appnd{driver}.

\medskip

The software resources available at present for the \step\ architecture do not
yet include high-level, applications-oriented languages; however, they are
sufficient to exercise and evaluate all of the architecture's features.  An
effort is in progress to augment and document the \step\ software, as well as
standardize and modularize it for the benefit of other program developers.

Besides the device driver, the resources currently available include:
 \begin{itemize}
	\item \emph{StepForth.}\quad This is a complete though rather spartan
programming environment for \step, based on a version of the Forth language
similar to that distributed as a machine monitor for the \sparcstation.  It
offers a wide range of constructs; some, intended for systems programming,
support direct register-level access, while others, useful for applications
programming, support various levels of modeling abstraction.
	\item \emph{C libraries.}\quad The software modules used by StepForth
and utilities are being recast as a collection of C libraries, in view
of having systems software completely written in C.
	\item \emph{\STEP\ simulator.}\quad An efficient, faithful software
simulator of the functional operation of a \step\ module is available. It
allows prospective users to familiarize themselves with the architecture, and
do initial program development even in the absence of \step\ hardware.
 \end{itemize}


\endinput


The current systems software, written in \forth, is a powerful,
flexible, and extendible interpretive assembler for \step's ``machine
language'' (\cf{machine-language}). It is provided for demonstration
purposes, and both as ``bootstrap'' and ``active documentation'' for
other software implementers.
