 % -*- Mode:Text -*-

\chapter{\Cam\ machine and controller}\label{sect.machine}

\section{Overview}\label{sect.machine-overview}

A complete \cam\ system consists of a three-dimensional array of \cam\
{\em boxes} driven by a {\em host} via a tree-shaped network
called the {\em \bus}, as sketched in \fig{cam-system} (where only two
dimensions of the array are shown).

\figonegiven{cam-system}{\psfig{file=fig/cam-system.ps}}{A \cam\ system
consists of an array of \cam\ boxes ({\em \cam\ machine}) driven
by a \sparcstation\ ({\em host\/}). The {\em \cam\ controller} interfaces the
host's Sbus with the machine's \bus.}

\noindent In the current implementation, the host is a \sun\ \sparcstation,
which features a high-performance external bus called the \sbus.  The
\bus\ is driven at the root by the \cam\ {\em controller}---a small
custom board plugged into one of the \sbus\ slots. From this board, a
short cable---which represents the \bus\ {\em trunk}---leads
directly to one of the boxes, located on a corner of the array. From
this {\em corner box} the \bus\ branches out through the rest of the array.
We shall call \cam\ {\em machine} the interconnected array of \cam\ boxes,
when viewed as distinct from the host and the \cam\ controller.

\section{Hardware hierarchy}\label{sect.hierarchy}

Each box of the \cam\ machine array realizes, by means of eight
identical printed-circuit boards called {\em modules}, a functional
{\em block} of eight sectors (see \chapt{block-structure}). Besides,
the box provides mechanical and electrical support (motherboard,
enclosure, power supply and cooling) to the modules themselves, as
well as \bus\ routing and buffering and some other support circuitry.

In turn, each module contains, besides conventional \dram\ and \sram\
chips, sixteen copies of the {\em \chip}---a custom {\sc vlsi} chip
that one may view as embodying the \cam\ architecture. In fact, each
\chip\ has complete control over one \dram\ chip's data and
control lines; and, collectively, the sixteen \chip{}s have complete
control over the \sram\ chips' data and control lines---as well as
over transactions over the \bus. Thus, the \chip{}s repesent the
``glue'' that turns plain electronic commodities into sophisticated
computing resources.

\medskip

The present Part II discusses the \cam\
system at four levels of the design hierarchy, namely,
 \begin{enumerate}
	\item the \cam\ machine with its controller (this chapter),
	\item the \cam\ box (\chapt{box}),
	\item the \cam\ module (\chapt{module}), and
	\item the \chip\ (\chapt{chip}).
 \end{enumerate}
	For each level, formal interface specifications
(pinout and signal description) with the level above it are given.

\medskip

The \chip\ (Level 4) is seen by the programmer as a set of registers
accessible via the \bus. Part III expands \chapt{chip} by giving a
complete programmer's model of the \chip: it systematically describes
structure and functions of these registers, giving, whenever appropriate,
a functional model of the hardware controlled by the registers themselves.

\medskip

One may view the host \sparcstation\ as representing Level 0 of
the hierarchy.  Its relevant hardware and system-software aspects are
documented by \sun\ Microsystems. \Cam-specific software is
documented in the \cam\ {\em Programmer's guide} and {\em User's
guide}.


\section{The \cam\ controller}\label{sect.controller}

The \cam\ controller is a small board with, on one edge, a connector
that plugs into one of the \sbus\ slots. At the opposite edge of the
card, a connector that shows through the rear of the \sparcstation\
represents the root of the \bus.

\medskip

The main {\em raison d'\^etre} of this piece of hardware is to provide
an interface between the two buses, and to do so in such a way as to
lessen the requirements for real-time response from the host.

While the \sbus\ and the \bus\ are both synchronous, and at present
have roughly comparable bandwidths, they are timed by independent
clocks which are typically running at different rates.  Moreover, the
number and nature of the control and data lines, the protocols, and
the signals' electrical specifications are quite different in the two
buses.

	The \cam\ controller requires bus-master as well as bus-slave
capabilities.\footnote
	{On the \sparcstation-1, one of the three \sbus\ slots only
offers bus-slave capabilities, and cannot be used for this purpose.
At any rate, this slot is typically dedicated to the graphics interface.}
	In fact, in order to decouple \cam\ from the poor and rather
impredictable real-time response of standard {\sc unix}, the
controller's normal operating mode is to act as a bus master and
interpret according to the \cam\ machine's timing requirements a list
of commands ({\em \steplist}) directly off the \sparcstation's memory,
without going through the {\sc cpu}. These commands would previously have
been written to memory by the {\sc cpu} at its own leisure.

The controller is addressed as a slave only at initialization time or
to recover from runaway situations.
 
Depending on specific implementation choices, clocking for the \cam\
machine may be generated by the controller or by
the machine itself. (A clock line running along the \bus\ trunk
will carry a clock reference signal from the controller to the machine
or vice versa.) In either case
 \begin{itemize}
	\item The interface between circuitry
clocked by the \sbus\ and circuitry clocked by the \bus\ lies within
the controller, which has provisions for arbitrating between
the two clocks.
	\item Tight synchronism (within a small fraction of the
clock period) between logically contiguous modules is achieved by
local phase-locked loops.
 \end{itemize}

See \sect{} for details of clock
distribution and synchronization.  

\medskip

The principles of operation of the \cam\ controller (i.e., how it
interprets a ``script'' consisting of \steplist\ commands, initiating and
supervising any \sbus\ or \bus\ transactions that may be called for)
are explained in \chapt{host}.


\subsection{\sbus\ signals}

The \cam\ controller interfaces with the \sbus\ by means of a standard
\sbus\ connector. Signal description and pinout can be found in {\em
The \sbus\ Specification} (specifically, Tables 2-1 and 3-8 of that
manual). The following \sbus\ signals are not used by the controller:
\memo{Any unused signals?}


\subsection{\bus\ signals}\label{sect.controller-bus-signals}

The \bus\ runs from the \cam\ controller to the corner box
(\sect{corner-box}) and thence outwards from box to box (cf.\
\fig{cam-system} and \fig{2x2x2}) on short lengths of cable called
{\em hops}. Each hop consists of a bundle of tranmission lines
(\cf{interbox}) carrying the following signals
 \begin{equation}\label{eq.machine-bus}
	\input bus-signals
 \end{equation}
	\noindent The hop that runs from the \cam\ controller to the
corner box is called the \bus\ {\em trunk}.

Within a box, the \bus\ is further distributed by
the motherboard to the eight modules according to the pinout of table
\eq{module-bus-local}, and from there to the sixteen chips of each
module according to the pinout of table \eq{chip-bus}.

The various \bus\ lines are discussed in detail in
\chapt{bus}.

\medskip

The inner end of a hop (the one closer to the tree root) plugs into
one of a box's three {\sym \bus\ branch} connectors (that's where a
new \bus\ branch is grafted onto the tree); the outer end plugs into a
box's {\sym \bus\ root} connector (that's where the box faces towards
the tree root).  According to this terminology, the connector through
which the \cam\ controller drives the \bus\ trunk is a {\sym \bus\
branch} connector.  Its pinout is the following
 \input mod-pin-types
 \begin{pinout}{controller-tbus}{...}{{\sym \bus\ branch} connector}
	\input bus-branch
 \end{pinout}

In the \bus\ trunk (\sect{controller-bus-signals}), the {\sym Scan*}
line carries master-clock (\sect{}) rather than scan-in-progress
(\sect{}) information.


\subsection{\bus\ Sync}\label{sect.bus-sync}

The \bus\ {\sym Sync} line carries, encoded as 5-bit bursts on a
background of all zeros, messages
used for achieving synchronization between sweeps and scans of the
\cam\ machine (\sect{}) and, respectively, horizontal and vertical
scans of a \crt\ monitor (or similar external equipment). The possible
messages are tabulated in \eq{sync-messages}.
 \figonegiven{sync-messages}{
	\begin{tabular}{|c@{$\;$}c@{$\;$}c@{$\;$}c|l|l|}\hline
 	\multicolumn{4}{|c|}{code} & \multicolumn{1}{c|}{message} 
& \multicolumn{1}{c|}{recipient}\\\hline\hline
 	1&00&1&0 & \sym HMON & {\sc crt} monitor\\
 	1&01&0&0 & \sym VMON & {\sc crt} monitor\\\hline
	1&10&0&0 & \sym HCAM & \cam\ machine\\
 	1&11&1&0 & \sym VCAM & \cam\ machine\\\hline \end{tabular}
 }{The above codes, transmitted on a background of all zeroes, signal
the appropriate times for a \crt\ monitor to start horizontal and
vertical scans, and for the \cam\ machine to start sweeps and scans.
Each message consist of a start bit (`1'), a two-bit field carrying
the intelligence of the message, a parity bit, and a stop bit (`0').}
 
The above messages are generated on the \cam\ controller as follows.
Two ganged programmable counters, namely, the {\em horizontal counter}
and the {\em vertical counter} (the latter is clocked by the rising
edge of the former), produce the waveforms of \fig{sync-counters}. For
each counter, ``mark'' and ``space'' lengths are independently
programmable; as a consequence, one can independently set the period
and the duty-cycle. {\sym HCAM}, {\sym VCAM}, {\sym HMON}, and {\sym
VMON} are issued at the rising and falling edges of these waveforms,
as indicated in \fig{sync-counters}.

\figonegiven{sync-counters}{\psfig{file=fig/sync.ps}}{Sync messages
are issued on the rising and falling edges of the waveforms generated
by the horizontal and vertical counters.}

\noindent The {\sym HCAM} message that would occur concurrently with a
{\sym VCAM} is superseded by the latter; the \chip\ will infer an
{\sym HCAM} from the presence of a {\sym VCAM}.

While the coincidence of {\sym VCAM} with an {\sym HCAM} is a logical
necessity, the fact that also {\sym VMON} exactly coincides with an
{\sym HCAM} (and supersedes the latter) is a nonessential feature of
the present version of the \cam\ controller.\footnote
	{Note that the \cam\ controller could be replaced by,
say, a video camera as a source of sync messages, in order to
have video-on-video.}
	Since the \chip\ does not respond to {\sym HMON} and
{\sym VMON} messages,\footnote
	{Each \chip\ monitors the integrity of all sync messages, by
checking the parity bit, but otherwise ignores messages directed
to the {\sc crt} monitor.}
	a \cam\ scan that extends past {\sym VMON} and is synchronized
to {\sym HCAM} (\cf{RMR}) will be suspended for one horizontal counter
period when {\sym VMON} occurs.


\section{The \cam\ machine}\label{sect.box-array}

The \cam\ machine is an assembly of \cam\ {\em boxes} physically
arranged and interconnected as a three-dimensional array. The three
dimensions are labeled $x$, $y$, and $z$, and along
each dimension the elements of the box array are sequentially numbered
from 0 upwards.  Thus, the {\em corner box} (\sect{machine-overview}), located
at the origin of the box array, has coordinates $\langle
0,0,0\rangle$, and in a system of 2\by3\by5 boxes the box on the
opposite corner would have coordinates $\langle 1,2,4\rangle$.

Along any of the three dimensions, the array need not extend for more
than one box. In particular, machines consisting of a single box
are viable (and we expect that they will be in quite common use).

\medskip

A box interfaces to the outside world through three groups of signals,
namely {\em glue} signals and {\em \bus} signals, which travel between
boxes on transmission lines (\sect{interbox}) and turn the collection
of boxes into a tightly-knit whole, and {\em data stream} signals,
which offer optional access to the box's internal data stream. In
addition, there are a small number of signals used for configuration
and test purposes. All these signals are described in detail in
Chapters \ref{sect.} and \ref{sect.}

\medskip

The glue signals exchange, in real time, site data between adjacent
sectors, according to the current data-transport specifications for
each layer (cf.\ \sect{kicking}). Six glue ports are provided---each
port corresponding to one of the six ``faces'' of the box, i.e., the
six spatial directions in which a box can interconnect with other
boxes, denoted by {\sym XM} (``x minus''), {\sym XP} (``x plus''), and
similarly {\sym YM}, {\sym YP}, and {\sym ZM}, {\sym ZP}.  Besides
the data lines, each glue port includes two lines that exchange
clock-phase information between adjacent boxes (\sect{clock-sync}).

\medskip

The \bus\ signals ultimately connect the boxes to the host. Each box
has one {\em root} port, facing inside (that is, towards the host),
and three {\em branch} ports, facing outside in the positive $x$, $y$,
and $z$ directions. The root port is always used: the one on the
corner box connects directly to the \bus\ trunk, the others, to bus
hops that come from intermediate boxes. On the other hand, a branch
port is used only if the box is the root of a subtree . Thus, for
example, in a machine of size 2\by2\by2 boxes (see \fig{2x2x2}), the
corner box $\langle 0,0,0\rangle$ uses all three branch ports, box
$\langle 0,0,1\rangle$ uses only $x$ and $y$, boxes $\langle
0,1,0\rangle$ and $\langle 0,1,1\rangle$ use only $x$, and the
remaining four boxes, with addresses of the form $\langle
1,y,z\rangle$, use none, since they are at the leaves of the tree.

 \figonegiven{2x2x2}{
 \setlength{\unitlength}{0.75pt}
 \begin{picture}(224,240)(-72,-152)
    \thicklines
\put(0,0){\circle*{8}}\put(8,16){\makebox(0,0){$\langle0,0,0\rangle$}}
    \put(0,0){\vector(4,1){32}}\put(32,-4){\makebox(0,0){$x$}}
    \put(0,0){\line(4,1){128}}
    \put(0,0){\vector(0,-1){32}}\put(12,-32){\makebox(0,0){$y$}}
    \put(0,0){\line(0,-1){128}}
    \put(0,0){\vector(-3,2){16}}\put(-16,-2){\makebox(0,0){$z$}}
    \put(0,0){\line(-3,2){48}}
    \put(-48,32){\circle*{8}}\put(-48,48){\makebox(0,0){$\langle0,0,1\rangle$}}
    \put(-48,32){\vector(4,1){32}}\put(-16,28){\makebox(0,0){$x$}}
    \put(-48,32){\line(4,1){128}}
    \put(-48,32){\vector(0,-1){32}}\put(-36,0){\makebox(0,0){$y$}}
    \put(-48,32){\line(0,-1){128}}

    \put(0,-128){\circle*{8}}\put(0,-144){\makebox(0,0){$\langle0,1,0\rangle$}}
    \put(0,-128){\vector(4,1){32}}\put(32,-132){\makebox(0,0){$x$}}
    \put(0,-128){\line(4,1){128}}

    \put(-48,-96){\circle*{8}}\put(-48,-112){\makebox(0,0){$\langle0,1,1\rangle$}}
    \put(-48,-96){\vector(4,1){32}}\put(-16,-100){\makebox(0,0){$x$}}
    \put(-48,-96){\line(4,1){128}}

    \put(128,32){\circle*{8}}\put(128,48){\makebox(0,0){$\langle1,0,0\rangle$}}
    \put(128,-96){\circle*{8}}\put(128,-112){\makebox(0,0){$\langle1,1,0\rangle$}}
    \put(80,64){\circle*{8}}\put(80,80){\makebox(0,0){$\langle1,0,1\rangle$}}
    \put(80,-64){\circle*{8}}\put(80,-80){\makebox(0,0){$\langle1,1,1\rangle$}}
 \end{picture}
}{\bus\ port usage in a 2\by2\by2 box machine. The dots represent boxes;
the arcs, \bus\ hops. The $x$, $y$, $z$ labels indicate to which
branch port of a box the inner end of a hop is connected.}


Unlike glue signals and \bus\ signals, the data stream signals that
appear on each box do not connect to other boxes; in fact, they do not
need to be connected to anything in particular for the \cam\ machine
to operate properly.

Through the {\sym Flywheel} ports, external
equipment can selectively extract any of the data involved in the
simulation and optionally replace them with arbitrary new data; these
lines are thus used for something like ``local open-brain surgery''
(it is unlikely that even the most advanced user will connect external
equipment to more than one box).

Through the {\sym Video} port, one can send to a color monitor and
view in real time the contents of a selected \cam\ sector.


\section{Clock distribution and synchronization}\label{sect.clock-sync}

The current \cam\ implementation consists entirely of {\em
synchronous} digital circuitry.  Each box has its own {\em local
master clock}, which drives the clock distribution tree for the entire
box.  The issue discussed here is the mutual synchronization of the
local masters within prescribed tolerances.

\medskip

Though the \cam\ array may extend arbitrarily in all three dimensions,
its elements (the boxes, in the present context) are only {\em
locally} interconnected. Thus, all that matters is that the clock
phase difference between a box and each of its six neighbors (the ones
with which the box exchanges {\em glue} data) be within tolerances.
There will be no harm if, in moving from one box to the next along a given
direction, these differences add up---leading perhaps to a cumulative
phase difference of several clock cycles between widely separated
boxes.

In \cam, local master clocks in adjacent boxes keep within
tolerances with respect to one another by exchanging clock-phase
information. This provides the feedback by which the phase of each
individual clock is dynamically adjusted according to a {\em
phase-locked loop} scheme: i.e., this phase is continually made
to track (according to a suitable response function)
the mean of the phases of its six neighbors.

\medskip

{\small

\memo{Revise and partially scrap this} 
Usually, at the heart of a phase-locked loop there is a
variable-frequency oscillator (VFO). The phase difference between the
oscillator and the reference signal is used to pull the oscillator's
frequency in such a direction as to reduce this difference. However,
since the phase is proportional to the integral of the frequency
rather than the frequency itself, one obtains in this way a {\em
second-order} loop; such a loop imposes certain trade-offs between
stability and agility of response.\footnote
	{Intuitively, in a second-order loop the phase has {\em
inertia} that needs to be damped. If is overdamped, it will never
reach the mark; if it is underdamped, it will overshhot it.}
	On the other hand, suppose that a signal having the desired
{\em frequency} were distributed to all boxes, reaching each box with
a different phase (owing to propagation delays through the
distribution network). Then the secondary master could match its phase
to that of its neighbors by means of a {\em first-order} loop where
the phase is adjusted directly (rather than indirectly through the
frequency), with improved response characteristics. Alternatively, the
distributed reference frequency could be used to adjust the VFO
natural frequency, so as to minimize the amount of error feedback
needed to pull the oscillator into phase lock.

Though the details of the local masters' strategy for achieving phase
lock are left unspecified, a single reference frequency may be made
available to all boxes through a \bus\ {\sym Master Clock} signal
originating from the \cam\ controller.  This signal could be used
directly as the local master clock by the corner box, which would
ignore phase feedback from its neighbors and would thus force them to
do all the necessary adjusting.  By directly using a copy of the {\sym
Master Clock} as a local master, ``bare bones'' boxes designed to
work only in small machines (one to eight boxes) could dispense with
the phase-locked loop altogether.

\medskip

It may be decided at a later time to use the oscillator of the corner
box as the primary master. In this case, on the \bus\ trunk the {\em
Master Clock} signal would run from the corner box to the controller
(rather than the other way around).

}% end \small


\section{Interbox communication}\label{sect.interbox}

Within a box, signals run short distances; they have a stable and
uniform voltage reference provided by the modules' and the
motherboard's ground plane; they are shielded from one another by the
close proximity of the ground plane, and from external fields by the
box's enclosure. In this environment, a signal line, even though it
may extend and branch out over several inches, can still be usefully
treated as a voltage node.

Communication between boxes takes place in a rather different environment.
The physical length of the lines from driver to receiver may run up to
a few feet; glue lines run in parallel bundles of over a hundred
lines each;\footnote
	{Sixteen layers times eight strands gives 128 lines, to which
one must add two clock-phase feedback lines.}
	each box is the source or destination of about a thousand
30-Mbit/sec signals; and boxes will typically be tied together by a
mesh of ground bars or ground strips several inches in length rather
than by a continuous copper plane. For these reasons, it is desirable
to have interbox signals travel on well-characterized {\em
transmission lines}, which feature low dispersion and (when properly
terminated) low reflections, good common-mode noise rejection, and
good decoupling between adjacent signals.

\medskip

Though implementation details for transmission-lines, line-drivers,
and line-receivers are left, for the moment, unspecified, we shall
assume that each transmission line consists of a {\em pair} of wires
(such as the two elements of a twisted-pair line, or core and shield
in a coaxial cable). Accordingly, for each signal handled in this
way we shall provide two separate pins on the connectors where the
transmission lines terminate (\cf{mod-pin-types}).


\section{Corner box}\label{sect.corner-box}

Because of its unique position---at the origin of the \cam\ box array
and at the origin of the \bus\ distribution tree---the \cam\ machine's
corner box plays a distinguished role in certain setup and housekeeping
functions.

\medskip

The \cam\ modules come out of power-up with all activity on their {\em
\bus\ branch} ports disabled (see \sect{MPCR}); thus, while the
controller can communicate with the corner box, all other boxes are
cut off from the \bus\ for the time being. Moreover, module 0 of a box
is physically distinguished from the other modules of the same box by
having the {\sym Multipurpose Pin A} of \chip\ 0 pulled down by an
external resistor, so that its module ID at power up will be {\tt
FFFE} rather than {\tt FFFF}.\memo{Norm, confirm this}

Taking advantage of the above features, the host runs an
initialization procedure that systematically assigns module IDs,
starting with {\tt 0000} for module 0 of box 0 (\cf{id-init}). Once
the corner box's privileged geographical position has been recorded in
distingushed IDs for its modules, the other boxes are gradually
brought into communication with the \bus, proceeding outwards from
the corner box.

\medskip

The local master clock of the corner box ignores clock-phase
information coming from the adjacent boxes (\cf{}), and thus forces
the latter to match their phases with its own.

If a reference clock signal is distributed along the
\bus\ (cf.\ end of \sect{interbox}), the corner box may send rather
than receive this signal on its \bus\ root port, thus clocking the
\cam\ controller rather than being clocked by it.
 

\section{Block wiring}\label{sect.block-wiring}

In the present realization, a \step{} module consists
of a {\em board} having all of its connectors on one edge, as in \fig{board},
and a \step{} block will consist of a {\em box} containing a card
cage with a backplane where eight of these boards can be plugged in.

 \figonegiven{board}{
 \setlength{\unitlength}{1.25pt}
 \begin{picture}(184,56)(-16,-8)
	\thicklines
	\put(-8,24){\oval(16,48)[l]}	% left oval side
	\put(160,24){\oval(16,48)[r]}	% left oval side
	\put(-8,48){\line(1,0){168}}	% top edge
	\multiput(0,0)(56,0){3}{\line(0,-1){4}}
	\multiput(16,0)(56,0){3}{\line(0,-1){4}}
	\multiput(24,0)(56,0){3}{\line(0,-1){4}}
	\multiput(40,0)(56,0){3}{\line(0,-1){4}}
	\multiput(-8,0)(56,0){3}{\line(1,0){8}}
	\multiput(16,0)(56,0){3}{\line(1,0){8}}
	\multiput(40,0)(56,0){3}{\line(1,0){8}}
	\multiput(0,-4)(56,0){3}{\line(1,0){16}}
	\multiput(24,-4)(56,0){3}{\line(1,0){16}}
	\put(8,0){\makebox(0,0){$\;x_-$}}
	\put(32,0){\makebox(0,0){$\;x_+$}}
	\put(64,0){\makebox(0,0){$\;y_-$}}
	\put(88,0){\makebox(0,0){$\;y_+$}}
	\put(120,0){\makebox(0,0){$\;z_-$}}
	\put(144,0){\makebox(0,0){$\;z_+$}}
 \end{picture}}
 {\Step{} module board, showing the six glue port connectors.}

\noindent For such a realization of a \step{} block, table
\eq{block-ports} can be interpreted as a template for the backplane,
indicating the eight slots (horizontal rows) and, for each slot, the
position of the six glue-port connectors.

Using this template, \fig{naive-wiring} shows in its essentials the
actual wiring between boxes. We only show the wiring for strand 0, and
then only for the $x$ and $y$ dimensions (the wiring for the $z$
dimension would go ``through the page'').

 \figonegivenp{naive-wiring}{\psfig{file=fig/naive-wiring.ps,height=2.5in}}
{Backplane wiring for an indefinitely extended array of \step{} boxes,
with no wraparound. Four boxes are shown, and only the wiring for
strand 0. The arrow direction goes from a `$+$' port to a `$-$' port
(cf.\ table \protect\eq{block-ports}).}
 \figonegivenp{naive-wrap}{\psfig{file=fig/naive-wrap.ps,height=2.5in}}{How
strands are connected at the edges of the array to form loops.}

Still using template \eq{block-ports}, \fig{naive-wrap} shows the
actual placement of the shorting plugs (cf.\ \fig{wrap-block}) at the
edges of the array (using an array that is two blocks deep in both
the $x$ and $y$ dimensions; as in \fig{naive-wiring}, the $z$
interconnections are not shown). With these plugs, strand 0 forms a
single loop with strand 1 in the $x$ dimension, and with strand 2 in
the $y$ dimensions (in the $z$ dimension, it would loop back as strand
4).


\subsection{Single-block wiring}

For a small \step{} system consisting of just one block
(eight modules), each dimension exhausts itself within
the block, as indicated by the following diagram for just the $x$
dimension
 $$
 \begin{picture}(124,64)(-112,-44)
	\thicklines
	\multiput(-88,16)(96,0){1}{\line(1,0){32}}
	\multiput(-88,16)(96,0){1}{\line(0,-1){32}}
	\multiput(-88,-16)(96,0){1}{\line(1,0){32}}
	\multiput(-56,16)(96,0){1}{\line(0,-1){32}}
	\multiput(-96,0)(96,0){1}{\line(1,0){8}}
	\multiput(-56,0)(96,0){1}{\line(1,0){56}}

	\multiput(-40,-8)(96,0){1}{\line(1,0){32}}
	\multiput(-40,-8)(96,0){1}{\line(0,-1){32}}
	\multiput(-40,-40)(96,0){1}{\line(1,0){32}}
	\multiput(-8,-8)(96,0){1}{\line(0,-1){32}}
	\multiput(-96,-24)(96,0){1}{\line(1,0){56}}
	\multiput(-8,-24)(96,0){1}{\line(1,0){8}}

	\put(-96,-12){\oval(24,24)[l]}
	\put(0,-12){\oval(24,24)[r]}
	\multiput(-88,-4)(96,0){1}{\makebox(32,8)[tl]{$\;x_-$}}
	\multiput(-88,-4)(96,0){1}{\makebox(32,8)[tr]{$x_+$}}
	\multiput(-40,-28)(96,0){1}{\makebox(32,8)[tl]{$\;x_+$}}
	\multiput(-40,-28)(96,0){1}{\makebox(32,8)[tr]{$x_-$}}
	\thinlines
	\multiput(-92,-44)(96,0){1}{\dashbox{2}(88,64){}}
 \end{picture},
 $$

\noindent and the complete wiring diagram will appear as in
\fig{naive-one-block}.

 \figonegiven{naive-one-block}{
 \setlength{\unitlength}{1.5pt}
 \begin{picture}(72,72)(0,0)
	\thicklines
	\multiput(0,8)(24,0){3}{	% the dots
	 	\multiput(8,0)(0,8){8}{\circle*{2}}
		\multiput(16,0)(0,8){8}{\circle*{2}}}
	\multiput(8,8)(0,16){4}{\line(1,1){8}}
	\multiput(8,16)(0,16){4}{\line(1,-1){8}}

	\multiput(32,8)(0,8){2}{\line(1,2){8}}
	\multiput(32,24)(0,8){2}{\line(1,-2){8}}
	\multiput(32,40)(0,8){2}{\line(1,2){8}}
	\multiput(32,56)(0,8){2}{\line(1,-2){8}}

	\multiput(56,8)(0,8){4}{\line(1,4){8}}
	\multiput(56,40)(0,8){4}{\line(1,-4){8}}

	\thinlines
	\put(0,0){\dashbox{2}(72,72){}}
 \end{picture}}
 {Complete backplane wiring for a \step{} system consisting of a single
block.}

\sbox{\toy}{}

\subsection{Block wiring, improved}\label{sect.block-improved}

Each of the ``wires'' shown in \fig{naive-wiring} or
\fig{naive-one-block} is actually a collection of 16 lines (one per
layer), and typically will be implemented by a shielded flat cable.
Since such cables are stiff and bulky, it is desirable to route them
as neatly as possible, trying to keep them flat and parallel and
avoiding repeated crossings.

By systematically rearranging the order of modules within a box and
the order of ports within a module it is possible to arrive,
for a single block, at the wiring pattern of \fig{clever-one-block},
to be constrasted with that of \fig{naive-one-block}.
The improved wiring is arrived at as follows.

\medskip

\parhead{Port swapping} \fig{wrap-block} suggests that, if strand 0
loops back as strand 1 in the $x$ dimension, it would be more
convenient if the modules of strand 1 had their $x_+$, $x_-$ ports
arranged in the opposite order as those of strand 0. More generally,
a similar argument holds for the $u$-dimension ports ($u=x,y,z$) of
any pair of strands whose labels differ only in the $s_u$ digit
(cf.\ \eq{block-ports}).

In order to respond to design requirements of the above kind, in a
\step{} module the correspondence between logical ports ($x_+$,$x_-$,
etc.) and physical ports (the six connectors at the bottom of
\fig{board}) is software assignable rather than hardwired (cf.\
\sect{GPCR}). Taking advantage of this feature, one can
make the two $x$ ports appear on the edge of the board in the order
$x_-,x_+$ or $x_+,x_-$, depending on whether the $s_x$ bit is 0 or 1
(and similarly for $y$ and $z$), leading to the following backplane
template

 \begin{equation}\label{eq.block-ports-better}
 \begin{array}{|cc||c@{}c|c@{}c|c@{}c|}\hline
	\multicolumn{2}{|c||}{\rm strand} & \multicolumn{6}{c|}{{\rm ports}}\\
	s_xs_ys_z& S & \multicolumn{2}{c}{x} & \multicolumn{2}{c}{y}
		& \multicolumn{2}{c|}{z}\\\hline\hline
	000 & 0 & - & + & - & + & - & +\\
	100 & 1 & + & - & - & + & - & +\\
	010 & 2 & - & + & + & - & - & +\\
	110 & 3 & + & - & + & - & - & +\\
	001 & 4 & - & + & - & + & + & -\\
	101 & 5 & + & - & - & + & + & -\\
	011 & 6 & - & + & + & - & + & -\\
	111 & 7 & + & - & + & - & + & -\\\hline
 \end{array}
 \end{equation}

\medskip

\parhead{Strand swapping} Finally, we shall permute the boards
in the backplane's eight slots so that the strand labels $S$
are ordered according to {\em Gray code} rather than straight
{\em binary} code:

 \begin{equation}\label{eq.block-ports-best}
 \begin{array}{|cc||c@{}c|c@{}c|c@{}c|}\hline
	\multicolumn{2}{|c||}{\rm strand} & \multicolumn{6}{c|}{{\rm ports}}\\
	s_xs_ys_z& S & \multicolumn{2}{c}{x} & \multicolumn{2}{c}{y}
		& \multicolumn{2}{c|}{z}\\\hline\hline
	000 & 0 & - & + & - & + & - & +\\
	100 & 1 & + & - & - & + & - & +\\
	110 & 3 & + & - & + & - & - & +\\
	010 & 2 & - & + & + & - & - & +\\
	011 & 6 & - & + & + & - & + & -\\
	111 & 7 & + & - & + & - & + & -\\
	101 & 5 & + & - & - & + & + & -\\
	001 & 4 & - & + & - & + & + & -\\\hline
 \end{array}
 \end{equation}

\medskip

It is easy to verify that the port-and-strand arrangement of template
\eq{block-ports-best} indeed leads to the improved backplane wiring
pattern given in \fig{clever-one-block}. Similar methods can be used
to streamline backplane wiring in more complex situations, such as
that of \fig{naive-wrap}.

 \figonegiven{clever-one-block}{
 \setlength{\unitlength}{1.5pt}
 \begin{picture}(72,72)(0,0)
	\thicklines
	\multiput(0,8)(24,0){3}{	% the dots
	 	\multiput(8,0)(0,8){8}{\circle*{2}}
		\multiput(16,0)(0,8){8}{\circle*{2}}}
	\multiput(0,8)(0,16){4}{
		\multiput(8,0)(8,0){2}{\line(0,1){8}}}
	\multiput(0,16)(0,32){2}{
		\multiput(32,0)(8,0){2}{\line(0,1){8}}}
	\multiput(0,20)(0,32){2}{
		\multiput(32,0)(8,0){2}{\oval(8,24)[l]}}
	\multiput(56,36)(8,0){2}{\oval(4,24)[l]\oval(8,40)[l]\oval(12,56)[l]}
	\multiput(56,32)(8,0){2}{\line(0,1){8}}
	\thinlines
	\put(0,0){\dashbox{2}(72,72){}}
 \end{picture}}
 {Improved backplane wiring for a \step{} system consisting of a single
block.}

