 % -*- Mode:Text -*- 

\chapter{Input/Output}

\section{The \cam\ host}

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

\section{The \cam\ controller}

All exchanges between host and \cam\ are mediated by the \cam\ {\em
controller} (\fig{two-buses}), which communicates with the host on the
\sbus, and drives the modules via the {\em \cbus}---a tree-like bus
having the controller at its root and the individual modules at its
leaves.  Physically, the \cam\ controller consists of a small board
plugged into one of the \sbus\ slots.\footnote
	{The \cam\ controller requires bus-master capabilities, which
are offered by only two of the three slots available in the
\sparcstation-1. The third slot, which only offers bus-slave
capabilities, is typically used for the graphics interface.}

 \figonegiven{two-buses}{
 \begin{picture}(224,88)(0,0)
	\thinlines
	\put(0,0){\framebox(96,80){}}
	\put(32,32){\framebox(48,32){\shortstack{\cam\\controller}}}
	\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(112,48){\vector(-1,0){0}}
	\put(128,48){\vector(1,0){0}}

	\put(144,48){\circle*{4}}

	\put(144,48){\line(2,1){32}}
	\put(152,52){\vector(-2,-1){0}}
	\put(168,60){\vector(2,1){0}}

	\put(144,48){\line(2,-1){32}}
	\put(152,44){\vector(-2,1){0}}
	\put(168,36){\vector(2,-1){0}}

	\multiput(176,32)(0,32){2}{\line(4,1){32}}
	\multiput(184,34)(0,32){2}{\vector(-4,-1){0}}
	\multiput(200,38)(0,32){2}{\vector(4,1){0}}

	\multiput(176,32)(0,32){2}{\line(4,-1){32}}
	\multiput(184,30)(0,32){2}{\vector(-4,1){0}}
	\multiput(200,26)(0,32){2}{\vector(4,-1){0}}

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

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

The \sbus\ and the \cbus\ are both synchronous, and at present
have roughly comparable bandwidths.\footnote
	{The \cbus\ is about twice as fast.}
	However, 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 main {\em raison d'\^etre} of the \cam\
controller 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.

\section{The \cbus}

The \cbus\ is a tree-like, synchronous, pipelined, bidirectional
communication channel having the controller at its root and \cam's
individual modules at its leaves.

The special structure of the \cbus\ is dictated by the nature of the
\cam\ architecture. In fact, a \cam\ unit can in principle consist of
an arbitrarily large number of modules; as a consequence, the physical
distance between the host and a module---and consequently the transit
time of both data and control signals---can be unboundedly large.  In
order to achieve a modular bus design whose technological parameters
(clock rate, drive capability of line drivers, etc.) are independent
of the number of \cam\ modules, an appropriate number of stages of
fan-out and of signal regeneration must be provided for.

\medskip

In the \cbus, control and data states are {\em distributed}, and are
propagated by {\em local} means. This design permits maximum bus
throughput at a constant clock rate when both source and destination
are capable of sustaining this rate. At the same time, this design
makes it possible for the bus to automatically adjust to situations
where either source or destination become incapable of sustaining the
maximum rate, or where the data direction is changed (bus {\em
turnaround\/}, \sect{turnaround}).

What, of course, cannot be avoided is bus {\em latency}, which is
proportional to bus {\em length} (distance from node to leaves);
in turn, bus length is roughly proportional to the third root of the number
of modules---since modules will be physically arranged in a three-dimensional
array. \cbus\ latency has no effect on \cam\ throughput when the modules
are driven by the host in a ``blind reckoning'' mode---the most common
situation during a simulation run.  However, latency becomes important
when feedback from the modules is desired. In particular, latency
determines the bus turnaround time---during which the bus's
effective thoughput drops to zero.

In practice, owing to the third-root dependency on size, \cbus\
latency is negligible (a few clock cycles) up to sizes of a few
hundred modules. Even in an extremely large \cam\ unit (say, 64K
modules) the \cbus\ latency will not be greater than a few dozen clock
cycles.  Moreover, special hardware is provided to avoid
frequent bus turnaround in the most common situation requiring
feedback from the modules, i.e., the readout of real-time
counters (see \sect{sequential-read}).

\section{Signal direction}

Each segment of the \cbus\ tree consists of sixteen {\em data} lines
and a number of {\em control} lines (see \sect{cbus-signals} for
details). Control lines are unidirectional. Data lines are
bidirectional, in the sense that they can carry information in one
direction or the other, but not both at the same time (this style of
communication is called {\em half-duplex}).

\medskip

For sake of clarity, it will be convenient to introduce the following
terminology.

The terms {\em in} and {\em out}---as well as {\em input} and {\em
output}---refer to signals that respectively enter or leave a node.
Thus, an output pin is one that drives the associated line, while an
input pin is one that senses it. (The same pin may be used as input or
output at different moments.)

The {\em proximal} side of a node is the one facing towards the host;
the {\em distal}, towards the modules. The \cam\ controller acts
as a node having only a distal side, and each module as a node
having only a proximal side.

The terms {\em inbound} and {\em outbound} refer to the absolute
direction of travel: outbound signals travel from the host towards
the modules, and vice versa for inbound signals. Thus, an output pin
on the proximal side of a node will be driving an inbound signal.

Finally, the terms {\em upstream} and {\em downstream} refer
to the current direction of travel; upstream is where the data come
from, downstream, where they go to.

\section{Fan-out and fan-in}\label{sect.fanout}

The bus nodes (cf.\ \fig{two-buses}) act as repeaters, allowing a
signal to propagate over an arbitrary distance; wherever the tree
branches out, they also act as {\em fan-out} or {\em fan-in}
elements---according to the direction of the signal. The following
discussion applies to each of the data lines individually.

Outbound data travel along the branches of the tree towards the
modules, with a delay of one clock cycle between one node and the
next. Fan-out occurs by each node copying its proximal data to all its
distal data lines, as in \fig{fan}a.  Thus, outbound data eventually reach
all the modules; it is the responsibility of each module, as
instructed by previous commands, to accept or ignore the broadcast
data (cf.\ \sect{modselect}).

Inbound data proceed along tree branches toward the root, with a delay
of one clock cycle between one node and the next.  Inbound data
originate from only one module at a time; previous commands will have
specified which module is selected for this purpose at any particular
time (cf.\ \sect{modselect}). The unselected modules send 0s as their
data.\footnote
	{This sending of dummy data is done in order to retain
data synchronization between all modules; cf.\ sect{}.}
	Fan-in of inbound data occurs by each node {\sc or}ing the
data from all distal lines and putting the result on the proximal
line; since the 0s contributed by unselected modules are ignored by
the {\sc or} operation, in effect the data coming from the selected
module---denoted by $x$ in \fig{fan}b---are routed unchanged through the
node no matter which branch they come from.

\figonegiven{fan}{
 \setlength{\unitlength}{0.9pt}
 \begin{picture}(132,112)(-16,-8)
	\put(8,8){\makebox(0,0){(a)}}
	\thicklines
	\put(48,48){\circle*{4}}
	\put(0,48){\line(1,0){48}}	\put(24,48){\vector(1,0){0}}
	\put(48,48){\line(1,1){48}}	\put(72,72){\vector(1,1){0}}
	\put(48,48){\line(3,1){48}}	\put(72,56){\vector(3,1){0}}
	\put(48,48){\line(3,-1){48}}	\put(72,40){\vector(3,-1){0}}
	\put(48,48){\line(1,-1){48}}	\put(72,24){\vector(1,-1){0}}

	\put(-8,48){\makebox(0,0){$x$}}
	\put(104,96){\makebox(0,0){$x$}}
	\put(104,64){\makebox(0,0){$x$}}
	\put(104,32){\makebox(0,0){$x$}}
	\put(104,0){\makebox(0,0){$x$}}
 \end{picture}
 \quad\quad
 \begin{picture}(128,112)(-16,-8)
	\put(8,8){\makebox(0,0){(b)}}
	\thicklines
	\put(48,48){\circle*{4}}
	\put(0,48){\line(1,0){48}}	\put(24,48){\vector(-1,0){0}}
	\thinlines
	\put(48,48){\line(1,1){48}}	\put(72,72){\vector(-1,-1){0}}
	\thicklines
	\put(48,48){\line(3,1){48}}	\put(72,56){\vector(-3,-1){0}}
	\thinlines
	\put(48,48){\line(3,-1){48}}	\put(72,40){\vector(-3,1){0}}
	\put(48,48){\line(1,-1){48}}	\put(72,24){\vector(-1,1){0}}

	\put(-8,48){\makebox(0,0){$x$}}
	\put(104,96){\makebox(0,0){$0$}}
	\put(104,64){\makebox(0,0){$x$}}
	\put(104,32){\makebox(0,0){$0$}}
	\put(104,0){\makebox(0,0){$0$}}
 \end{picture}
}{Fan-out of outbound data (a), and fan-in of inbound data (b) on the
\cbus.}

Fan-out or fan-in of control signals occur in analogous ways.

\section{\cbus\ signals}\label{sect.cbus-signals}

Each \cbus\ {\em segment}---terminated by a node at each end---consists
of sixteen {\em data} lines ({\sym Data(0:15)}) and five
{\em control} lines, as in \fig{bus-segment}, 

\figonegiven{bus-segment}{
 \def\sig{\small\sym}
 \def\dist{88}	% \def\dist{88}
 \def\prox{84}	% \def\prox{88}
 \def\far{162}	% \def\far{152}
 \def\diff{74}	% \def\diff{64}
 \def\zerom{-4}
 \def\distm{86}
 \def\farm{162}
 \begin{picture}(246,154)(0,-16)
	\thinlines
	\put(\dist,0){\line(0,1){128}}
	\put(\far,0){\line(0,1){128}}
	\put(0,0){\line(1,0){\dist}}
	\put(0,128){\line(1,0){\dist}}
	\put(\far,0){\line(1,0){\prox}}
	\put(\far,128){\line(1,0){\prox}}
	\put(36,132){\makebox(0,0)[b]{\large node}}
	\put(\dist,130){\makebox(0,0)[b]{distal side}}
	\put(210,132){\makebox(0,0)[b]{\large node}}
	\put(\far,130){\makebox(0,0)[b]{proximal side}}
	\put(44,-16){\vector(0,1){16}}
	\put(202,-16){\vector(0,1){16}}
	\put(46,-8){\makebox(0,0)[l]{\sig Clock}}
	\put(204,-8){\makebox(0,0)[l]{\sig Clock}}

	\put(\zerom,112){\makebox(\dist,0)[r]{\sig Distal Data(0:15)}}
	\put(\farm,112){\makebox(\prox,0)[l]{\sig Proximal Data(0:15)}}
	\put(\distm,116){\makebox(\diff,0)[b]{\sig Data(0:15)}}
	\put(\dist,112){\vector(1,0){\diff}}
	\put(\dist,112){\vector(-1,0){0}}
	\put(152,112){\makebox(0,0){/}}
	\put(152,118){\makebox(0,0)[b]{\small 16}}

	\put(\zerom,88){\makebox(\dist,0)[r]{\sig Outbound Ready Out}}
	\put(\farm,88){\makebox(\prox,0)[l]{\sig Outbound Ready In}}
	\put(\distm,92){\makebox(\diff,0)[b]{\sig Outbound Ready}}
	\put(\dist,88){\vector(1,0){\diff}}

	\put(\zerom,72){\makebox(\dist,0)[r]{\sig Inbound Ready In}}
	\put(\farm,72){\makebox(\prox,0)[l]{\sig Inbound Ready Out}}
	\put(\distm,76){\makebox(\diff,0)[b]{\sig Inbound Ready}}
	\put(\far,72){\vector(-1,0){\diff}}

	\put(\zerom,48){\makebox(\dist,0)[r]{\sig Frame Out}}
	\put(\farm,48){\makebox(\prox,0)[l]{\sig Frame In}}
	\put(\distm,52){\makebox(\diff,0)[b]{\sig Frame}}
	\put(\dist,48){\vector(1,0){\diff}}

	\put(\zerom,32){\makebox(\dist,0)[r]{\sig Reset Out}}
	\put(\farm,32){\makebox(\prox,0)[l]{\sig Reset In}}
	\put(\distm,36){\makebox(\diff,0)[b]{\sig Reset}}
	\put(\dist,32){\vector(1,0){\diff}}

	\put(\zerom,16){\makebox(\dist,0)[r]{\sig Status In}}
	\put(\farm,16){\makebox(\prox,0)[l]{\sig Status Out}}
	\put(\distm,20){\makebox(\diff,0)[b]{\sig Status}}
	\put(\far,16){\vector(-1,0){\diff}}
 \end{picture}
}{Makeup of a \cbus\ segment.}

\noindent At any node where the \cbus\ branches out into two or more segments,
the node's distal side will provide terminations as in
\fig{bus-segment} for each of these segments. The details of this
branching will be discussed in \sect{}; until then, the issue of bus
branching can be ignored.

All \cbus\ signals are sensed at the rising edge of a common \cam\
{\em clock} which is made available to all \cam\ modules and \cbus\
nodes, as well as to the \cam\ controller. We shall not be concerned
at this moment with details of clock distribution.

\medskip

The direction of the data lines is not directly governed by a ``Read/Write''
control signal, but is established by a protocol discussed in
\sect{frames} and \sect{}.

The two {\em readiness} lines ({\sym Outbound Ready} and {\sym Inbound Ready})
regulate the rate of flow of data on the data lines, as explained
in \sect{data-readiness}.

The {\sym Frame} line is used to tell whether the data lines
carry address or data information, as explained in \sect{frames}.

The {\sym Reset} signal is originated by the controller, and is used to reset
\cam\ modules and \cbus\ nodes to a known state after the occurrence
of errors or other unanticipated conditons.

By the {\sym Status} line, modules or nodes send to the controller
real-time status information, namely interrupt requests and ``scan in
progress'' reports (see \sect{} and \sect{}).

\medskip

We mentioned that a \cam\ module acts as a \cbus\ node having only a
proximal side (since it is located at the end of a branch).  Besides
one bidirectional data pin, each \cam\ chip has one pin for each of
the \cbus\ control signals (\sect{cbus-interface}). When sixteen \cam\
chips are assembled together in a module, their sixteen data pins
provide the terminations {\sym Proximal Data(0:15)} of
\fig{bus-segment}.  The sixteen chips' {\sym Reset} inputs are tied
together, so as to present a single {\sym Reset In} termination to the
\cbus\ {\sym Reset} line---and similarly for the other outbound
control signals. On the other hand, the sixteen chips' {\sym Status}
outputs are {\sc or}ed together in order to present a single {\sym
Status Out} termination to the \cbus\ {\sym Status} line---and
similarly for the other inbound control signals.

\medskip

All of the \cbus\ signals are {\em pipelined}, i.e., each node
samples a signal coming from upstream at the rising edge of the clock,
it logically combines the sampled signal with other sampled signals
and internal states, and puts out the result downstream early enough
during the clock cycle for this result to reach the next node
downstream in time to be sampled by the next rising edge of the clock.

In addition, the data signals are {\em double-buffered}, as explained
in \sect{data-readiness}.

\section{Data readiness}\label{sect.data-readiness}

Each of the sixteen data lines of the \cbus\ is double-buffered as it
passes through a node. The double-buffering mechanism, which is
essentially a 2-bit {\sc fifo}, allows a node to use the readiness
lines to regulate the rate of data flow.

Normally a node holds only one bit, which is passed on to the next
node downstream.  The node is capable of retaining this bit for an
indefinite length of time when the downstream traffic is
backed up (typically because of a momentary inability of the
destination to accept data at the full bus rate).  Moreover, even
while holding this bit, the node is able to accept from the upstream
traffic and hold one additional bit.\footnote
	{\label{foot.squeeze}Traffic on the pipeline has some
``inertia,'' i.e., it cannot be stopped all at once by
action-at-a-distance. Since there is one clock cycle of delay from the
time a node realizes that traffic downstream is backed up to the time
this information is communicated to the node immediately upstream,
room must be available to accomodate the bit received during that
cycle.}

On the other hand, when the source is unable to provide data at the
full bus rate, traffic will become sparse and valid data bits will be
separated by gaps in which no valid data are present. In this situation,
a node may hold no data bits at all.

\medskip

Of the two {\em readiness} lines, one is used to signal when a node is
ready to accept new data, and the other when it is ready to provide
new data; which line has which role depends on the current data
direction.\footnote
	{The terms `inbound' and `outbound' for the readiness signals
refer to the directions of the signals themselves---not the direction
of the data to which they are associated.}

For instance, on an outbound transaction, if a module is busy (say,
because of \dram\ refresh) and temporarily cannot accept data, it will
unassert the {\sym Inbound Ready} line) (via the {\sym Inbound Ready
Out} pin on its proximal side). On sensing (via the {\sym Inbound
Ready In} pin on its distal side) that the {\sym Inbound Ready} signal
is unasserted, the transmitting module will hold the current values on
the data lines until {\sym Inbound Ready} is asserted again,
signifying that those data have been accepted.  At the same time, it
will propagate this unasserted state to its own proximal side ({\sym
Inbound Ready Out} pin), to tell the previous node to suspend
transmission. Since this propagation will take one clock cycle, the
node must be responsible for accepting the bit that might have been
passed on to it during that cycle (cf.\ \foot{squeeze}).  The
accumulated bits will be transmitted downstream, in a first-in,
first-out fashion, as soon as the readiness signal from downstream is
re-asserted.

Similarly, if the \cam\ controller is temporarily unable to send new
data, it will unassert the {\sym Outbound Ready} line, signaling to
the next node that no new values will appear on the {\sym Data} lines
in the current clock cycle.

The roles described above for the readiness signals in
an outbound transaction are exchanged in an inbound transaction; that
is, {\sym Inbound Ready} will signify that there are new data
available on the data lines, and {\sym Outbound Ready} will signify
that any available data are going to be accepted.

\section{\cbus\ frames}\label{sect.frames}

Data on the \cbus\ are transmitted in the form of self-contained {\em
frames}, delimited by the {\sym Frame} signal as in \fig{frame}.
A frame consists of three phases:
 \begin{itemize}
	\item An {\em address} phase of variable length (down to zero
length). The string transmitted during this phase specifies the
address of one of the \cam\ chip's I/O registers (see
\sect{io-registers}) and the direction of the requested data transfer
(see \sect{} for details). The address phase is terminated by
unasserting {\sym Frame}.
	\item A {\em data} phase, during which the controller either
writes data to that register or reads data from it; the length of this
phase depends on the register that is being accessed (cf.\ \sect{io-registers}).
The data phase is terminated by reasserting {\sym Frame}.
	\item A {\em parity} phase, of exactly one bit, where the controller
transmits the parity of the frame.
 \end{itemize}

\figonegiven{frame}{
 \def\sig{\small\sym}
 \begin{picture}(224,40)(-40,0)
	\thinlines
	\put(-40,8){\makebox(0,0)[l]{\sig Data}}
	\put(0,0){\line(1,0){184}}
	\put(0,16){\line(1,0){184}}
	\put(48,0){\line(0,1){16}}
	\put(160,0){\line(0,1){16}}
	\put(176,0){\line(0,1){16}}
	\put(24,8){\makebox(0,0){address}}
	\put(104,8){\makebox(0,0){data}}
	\put(168,6){\makebox(0,0){p}}

	\put(-40,32){\makebox(0,0)[l]{\sig Frame}}
	\put(0,40){\line(1,0){48}}
	\put(48,40){\line(0,-1){16}}
	\put(48,24){\line(1,0){112}}
	\put(160,24){\line(0,1){16}}
	\put(160,40){\line(1,0){24}}
 \end{picture}}{Framing of address, data, and parity on the {\sym
Data} lines.}

\fig{frame} represents the {\em sequence} of valid bits on a data line, not
the actual {\em timing\/}; depending on the status of the readiness signals,
valid bits may be separated by idle clock cycles. Typically, several
idle cycles will elapse between the parity bit at the end of one frame
and the address at the beginning of the next.

\medskip

Note that writing or reading are done in parallel, via the sixteen data
lines, to or from all sixteen \cam\ chips that belong to a module;
thus, the data flowing on the data lines during the data phase may
(and typically will) be different for each of the sixteen chips.
Similarly, sixteen different parity bits, one for each of the sixteen
\cam\ chips of a module, are transmitted in parallel on the sixteen
data lines.

On the other hand, during the address phase the {\em same} address and
data direction are sent on all sixteen data lines (even though in
principle it would be possible to send different values), so that
homologous I/O registers will be accessed (all read or all written) on
all sixteen chips of a module simultaneously.

\medskip

The entire frame will be called a {\em write} or a {\em read} frame
according to the direction of data movement (outbound or inbound) for
the data phase---which, as we have seen, is specified during
the address phase.


\section{Bus turnaround}\label{sect.turnaround}

The default data direction for the \cbus\ is `write'.  The direction
turns to `read' only during the data phase of a read frame.

Data direction changes propagate from the controller toward
the modules at the rate of one bus segment per clock cycle, with one
exception. If a change from write to read reaches a segment where
outbound data are being held up (waiting for the {\sym Inbound Ready}
signal to be asserted), the propagation of this change will be held up
too, so as not to overcome the stretch of write data still in the
pipeline.

On the other hand, a change from read to write will propagate at full
speed regardless of whether there are inbound data still in the
pipeline.  These data will be lost, and the new role of the readiness
lines, which now accompany outgoing data (cf.\ \sect{data-readiness}),
will override the readiness information that accompanied the incoming
data.

\medskip

\cbus data direction and bus turnaround are discussed in more detail
in \sect{}.

\section{Implementation notes}\label{sect.implementation-notes}

[Disucussion on possible ways to implement the \cbus\ tree:
Either as a logarithmic tree, superposed to but physically distinct from
the three-dimentional array of modules, or as a three-dimensional
tree directly embedded in the array of modules. Modify
\sect{run-reg} as needed]

{\small ({\sc To be revised})\quad One possibility is to have the
\cam\ modules themselves act as bus nodes, with data latched and
reclocked before being passed on from one group of modules to the
next.  In this way, the pipeline delay between the host interface and
different \cam\ modules is not constant.  This doesn't matter: each
module examines the serial data stream as it goes by, putting each bit
of data into the appropriate registers and passing it along to the
next module, to process at a slightly later moment. (Only the
initiation of an updating scan of the space needs to be globally
synchronized).\par}


\section{CAM chip I/O registers}\label{sect.io-registers}

As mentioned in \sect{frames}, the \cbus\ represents the medium
through which the \cam\ controller writes data to or reads data from a
number of I/O registers located on the \cam\ chips (these registers
are detailed in \sect{io-regs}). During the address phase of
a \cbus\ frame, a particular I/O register is addressed and the data
direction for the ensuing tranfer is established; during the
data phase, data are serially written to this register from a \cbus\
data line, or serially read from this register to the same data line.
This process goes on in parallel for the sixteen chips of a module and
the corresponding sixteen data lines.

The \cam\ chip I/O registers come in different lengths. Most registers
have a fixed length (ranging from 1 to 120 bits). Two registers,
however, namely the {\sym DRAM Data Port} and the {\sym LUT Data
Port}, are actually serial 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 play the role of ``register length''---must be
explicitly programmed by the controller into the chip before the
transfer itself takes place.

\medskip

Many of the \cam\ chip's I/O registers are logically collections
of shorter registers that have been put together under a single register
address for convenience and efficiency. Thus, the three-bit
{\sym Selection Register} mentioned in \sect{modselect} consists
of a two-bit {\sym Target Register} and a one-bit {\sym Module/Group
Flag}. 

\medskip

For I/O purposes, the I/O registers proper (as distinguished from the
data ports) are organized as circular shift registers with an
input/output tap at a distinguished position. A register is written by
serially shifting new bits into it via the input tap, while the register's
entire contents rotates one bit-position at a time; similarly, a register
is read by rotating it entire contents one bit-position at a time, letting
its bits serially appear at the output tap.

With this mechanism, it is clear that a read operation must clock out
of a register a number of bits equal to the register's length, in
order to leave the register in the original alignment at the end of the
operation; an equal number of bits must be clocked into the
register by a write operation, in order for each bit to have reached
its proper destination in the register at the end of the operation.

The length of each register is explicitly known to both the \cam\ chip
and the host. This length is one of the parameters that is passed by
the host to the \cam\ controller in order to set up the transfer of a
frame of data, and is used by the controller to know when to terminate
the data phase (cf.\ \sect{frames}) and proceed to the transmission of
the parity bit (cf.\ \sect{frames} and \sect{frame-parity}).

[The only exception is the {\sym Event Counter Buffer
Register} ({\sym ECBR}): the {\sym Event Count Length
Register} ({\sym ECLR}) specifies the number of bits of this register
that will be read.]

\medskip

[In assigning addresses to the registers, we take advantage of the
fact that leading zeros in the register address need not be
transmitted on the Cbus, so that low addresses can be transmitted more
quickly than high addresses. Of course, the lowest addresses are
assigned to the most frequently used registers.]


\section{\cbus\ usage}\label{sect.cbus-usage}

[The most bandwidth-intensive use of the Cbus is to broadcast data
simultaneously to all of the \sram\ Lookup Tables (\lut{}s).  These tables
are double-buffered within each module, so that one table can be used
for sequentially updating all of the cells of the space while the
other is being loaded in preparation for the next updating step.  The
other major use of the bus is for reading back data from event
counters within each module; here too we double-buffer, so that the
event counts from one updating step can be read, from each module in turn,
while the next step proceeds.]

[{\sc I/o} to the \dram, which contains the cell state data, is less
frequent.  Normal updating is halted while such \io\ proceeds.  Note
that the \cam\ display hardware doesn't make use of the \cbus: data is
sent directly to the display as it is being accessed for updating.  If
necessary, it is possible to use the \cbus\ to read \dram\ data to the
host for display on the host's monitor even while updating is in
progress; in this case, however, updating will be slowed down by the
\sbus's lower data rate, and inbound display data will compete with
any outbound \lut\ data for \cbus\ bandwidth.]

[The remaining registers are not double-buffered, since they are short
or written infrequently.  These registers configure the machine
and control details of the updating, and normally are read back
by the host only for testing and error-recovery purposes.]

[Double-buffered tables ... This makes it possible to have a different
rule running during each successive scan, with a minimum of time
overhead.]



\section{Frame parity}\label{sect.frame-parity}

The {\em parity} of a \cbus\ frame is a single bit obtained by {\sc
xor}ing together the frame's address and data bits. This parity
is computed independently by the \cam\ controller and by the
individual \cam\ chips.  At the end of the frame, the controller
broadcast its version of the parity bit (\fig{frame}); it is the
responsibility of each \cam\ chip that was selected for that frame to
compare this bit with its own parity bit, and generate a parity
interrupt in case of mismatch (\sect{****}).

[Pointer to details of when the parity flags in the controller and
the chips are cleared in preparation for a new frame.]

\medskip

The parity bit is handled in a similar way but with a somewhat different
meaning in sequential-read transactions (\sect{sequential-read}).

\section{Interrupts}\label{sect.cbus-interrupts}

\section{Module selection}\label{sect.modselect}

During the data phase of a write frame, data are physically fanned-out
by the \cbus\ to {\em all} \cam\ modules. In most cases, these data
are intended for use by all modules; in certain cases, however, it is
desirable that only certain modules be enabled as active listeners,
either on an individual basis or as members of a certain group of
modules.

During the data phase of a read frame, it is essential for the proper
functioning of the fan-in mechanism (cf. \sect{fanout}) that only {\em one}
module be enabled as a talker on the \cbus.

\Cam's module selection mechanism, described here, allows each
module to decide whether or not it should take active part in a given
write or read transaction. The unit of selection handled by this
mechanism is an entire module. Finer-grained selection, such as
write-enabling of individual layers within a module, is achieved by
other methods.

\medskip

We have seen that a \cam\ unit consists of an arbitrary number of
modules, and each module consists of sixteen layers each served by a
separate \cam\ chip. In most respects, these sixteen chips act
independently of one another; they manage to achieve coordinated
action not because they exchange coordinating information between one
another, but because they are separately instructed by the host to
play in lockstep appropriately correlated roles.

However, the sixteen chips of a module act as a unit for the
purpose of deciding whether that module is {\em selected}, i.e., will
accept the data broadcast by the host on the \cbus\ during a write
frame, or will put its own data on the \cbus\ during a read frame.

\medskip

The decision of whether or not a module is currently selected is based
upon a match between an {\em internal name} and a {\em target name}.
Both of these names are sixteen bits long (one bit per chip).  For
each of the sixteen positions, internal- and target-name bits
are (directly or indirectly) specified by a three-bit {\em selection
code}, which is broadcast by the host and written to the {\sym Module
Select Register} ({\sym MSR}) of all modules.\footnote
	{The {\sym MSR} is exceptional in the sense that data addressed to
it are accepted by {\em every} module regardless of the
module's current selection status.}

\medskip

There are two primary sources available for the internal-name bit. The
{\em module ID}, stored in the {\sym Module ID Register} ({\sym MIDR})
is used to uniquely identify the module, and is assigned once and for
all at initialization time (\sect{id-init}); the {\em group ID},
stored in the {\sym Group ID Register} ({\sym GIDR}) is used for
grouping modules as needed for the convenience of particular
operations, and may be reassigned by the host from time to time. Both
IDs are sixteen bits long, with one bit contributed by each chip.
A third source is the {\sym Glue-AND} bit, used only at initialization
time (\sect{id-init}).

For the target-name bit, the selection code may supply directly a 0, a
1, or a `dont care'; or it may specify that the bit should be taken
from the {\sym LUT/Module Address Counter} ({\sym LMAC}). The fourth
option is used during a special {\em sequential read} mode
(\sect{sequential-read}).

\medskip

The following table lists what sources the different selection codes
specify for the internal bit and the target bit\footnote
	{The values 000, 010, and 111, which are probably the most
commonly used, happen to be of a form that can be packed as immediate
data in a step-list frame (cf.\ \sect{}).}
 \begin{equation}\label{eq.selection-codes}
 \begin{tabular}{|c|l|l|}\hline
	\small selection code   & \multicolumn{2}{c|}{bits to be matched}\\
	(\sym MSR) & internal & target\\\hline\hline
	000 & \sym MIDR & 0 \\
	010 & \sym MIDR & 1 \\
	100 & \sym MIDR & \sym LMAC \\
	110 & \sym Glue-AND & 0 \\\hline
	001 & \sym GIDR & 0 \\
	011 & \sym GIDR & 1 \\
	101 & \sym GIDR & \sym LMAC \\
	111 & \multicolumn{2}{c|}{don't care} \\\hline
 \end{tabular}\;.
 \end{equation}

Of course, the individual \cam\ chip will be able to detect a match
between internal name and target name only in one of the sixteeen
bit positions. The overall name match is obtained by {\sc and}ing
together the sixteen partial matches.  This logical operation is
physically performed by a wired-{\sc and} line that ties together all
sixteen chips' {\sym ModSel} pins (\sect{wired-and}), collecting the
arguments of the {\sc and} from the individual chips and returning the
result to all chips. In this way, the individual chip not only gives
its contribution to the selection decision, but is also made aware of
the collective decision's outcome.

The above comparison between internal name and target name is made at
the end of the data phase of each frame (\fig{frame}), and
the result (`selected' or `not selected') remains valid
for the entire duration of the following frame.

\section{Module ID initialization}\label{sect.id-init}

As mentioned in \sect{modselect}, before a \cam\ unit can function properly
each module must be given a distinct module ID. This initial
naming task presents a challenge, because there are no intrinsic
features in the architecture that distinguish one module from another.
In fact, (a) the modules are structurally identical and are physically
interconnected in a uniform way (i.e., they form a three-dimensional
torus), and (b) at system reset all modules are set to an identical
internal state.

To break the symmetry, it is sufficient to ``tag'' one module.
Then, every other module remains uniquely identified by its $x$, $y$,
and $z$ displacements (in the torus coordinates) relative to the
distinguished one.  As we shall explain in a moment, tagging is
performed at power-up; immediately after that the host will run
a module ID initialization procedure which, starting from the
tagged module and taking advantage of the
glue lines that connect modules in the $x$, $y$, and $z$ directions,
successively steps from module to module, selecting and uniquely
naming each module in turn.

\medskip

The \cam\ chip is provided with a {\sym Multipurpose Input} ({\sym
MI}) pin (\sect{misc-pins}), which, as the name implies, is used for
different purposes by the sixteen chips of a module; specifically, the
one on chip 0 is used for tagging a module.  Since it is pulled up
internally, the {\sym MI} pin will sense a logical 1 when left
floating.

On power-up, the sixteen bits of the module ID (\sect{modselect},
\andsect{module-id-reg}) are initialized to whatever values appear on
these sixteen pins.  What breaks the symmetry between modules is that
the {\sym MI} pin of chip 0 is left floating in all modules {\em
except one}, in which it is shorted to ground (logical 0).

Thus, on power-up one module is distinguished by having a 0 rather
than a 1 as the low-order bit of its module ID. By appropriate use of
the 000, 010, and 111 selection codes (table \eq{selection-codes}), the host
will select just this module and give it a name consisting of all 0s
({\tt 0000} in hexadecimal notation), and then select all the other
modules at once and give them, for the moment, a name consisting of
all 1s (hexadecimal {\tt FFFF}).

\medskip

We shall now describe how naming information is propagated through
the array of modules by the initialization procedure.

Let us recall that, for each of the sixteen data layers, each module
has six glue pins which connect it, via as many glue lines, to the
six adjacent modules (\fig{glue-and}a).

 \figonegiven{glue-and}{
 \setlength{\unitlength}{0.75pt}
 \def\sig{\small\sym}
 \begin{picture}(144,128)(-72,-64)
	\thicklines
	\put(-40,-16){\line(0,1){48}} % the three vertical sides
	\put(-8,-32){\line(0,1){48}}
	\put(40,-32){\line(0,1){48}}
	\put(-40,32){\line(1,0){48}} % the three horizontal lines
	\put(-8,16){\line(1,0){48}}
	\put(-8,-32){\line(1,0){48}}
	\put(-40,32){\line(2,-1){32}} % the three diagonal lines
	\put(-40,-16){\line(2,-1){32}}
	\put(8,32){\line(2,-1){32}}
	\put(-72,0){\line(1,0){48}} % the y lines
	\put(40,0){\line(1,0){32}}
	\put(0,-64){\line(0,1){32}} % the z lines
	\put(0,24){\line(0,1){40}}
	\put(-64,32){\line(2,-1){24}} % the x lines
	\put(16,-8){\line(2,-1){48}}

	\put(56,-40){\makebox(0,0){\sig X0}}
	\put(-56,40){\makebox(0,0){\sig X1}}
	\put(64,8){\makebox(0,0){\sig Y0}}
	\put(-64,8){\makebox(0,0){\sig Y1}}
	\put(12,56){\makebox(0,0){\sig X0}}
	\put(12,-60){\makebox(0,0){\sig Z1}}

	\put(-64,-64){\makebox(0,0){(a)}}
 \end{picture}
 \quad
 \begin{picture}(120,144)(-16,-24)
	\thinlines
	\put(16,-24){\line(0,1){128}}
	\put(16,-24){\line(1,0){64}}
	\put(16,104){\line(1,0){64}}
	\thicklines
	\multiput(-16,0)(0,16){6}{\line(1,0){48}}
	\put(32,-4){\line(0,1){88}}
	\put(32,40){\oval(64,88)[r]}
	\put(64,40){\line(1,0){56}}
	\put(0,2){\makebox(0,0)[b]{\sig Z1}}
	\put(0,18){\makebox(0,0)[b]{\sig Z0}}
	\put(0,34){\makebox(0,0)[b]{\sig Y1}}
	\put(0,50){\makebox(0,0)[b]{\sig Y0}}
	\put(0,66){\makebox(0,0)[b]{\sig X1}}
	\put(0,82){\makebox(0,0)[b]{\sig X0}}

	\put(92,42){\makebox(0,0)[b]{\sig Glue-AND}}
	\put(48,40){\makebox(0,0){\sc and}}

	\put(-8,-16){\makebox(0,0){(b)}}
 \end{picture}}{(a) The six glue lines that connect one module
to its neighboring modules. (b) The module ID initialization sequence
makes use of the {\sc and} of the six glue lines.}

\noindent At power-up, the six glue pins of all modules are programmed
as inputs; these inputs are internally {\sc and}ed together into a
signal call {\sym Glue-AND} (\fig{glue-and}b). Since the glue inputs
are internally pulled up by resistors to logical 1, {\sym Glue-AND}
will have a value of 1.

We'll now turn the {\sym X0} pin of module {\tt 0000}, layer 0, into
an output, and put a 0 on it. This 0 will travel on a glue line and
reach pin {\sym X1} of an adjacent module, forcing its {\sym Glue-AND}
to 0.  Making appropriate use of selection code 110, corresponding to
{\sym Glue-AND}=0 (cf.\ table \eq{selection-codes}), we can select
just this adjacent module,\footnote
	{With the present naming procedure, the only two modules
having {\sym Glue-AND}=0 are the module that emits 0 and the one that
senses it. But the former will already have been named, while the
latter still has the default name {\tt FFFF}. Since selection code 110
is only used with one of the sixteen chips, the remaining fifteen
name positions can use code 010 to discriminate between the emitting
module and the receiving module. (This scheme does not allow one to
discriminate between the last two modules in a 64K-module machine, but
in this case the last module does not have to be named, since it already
has the correct name {\tt FFFF}.}
	and write {\tt 0001} as its module ID.
At this point we'll ask module {\tt 0000} to turn
pin {\sym X0} of layer 0 back into an input, and module {\tt 0001}
to put a 0 on one of its glue pins, so as to ``touch'' another module.
We will name the new module {\tt 0002}, and so on until all modules
of the \cam\ unit have been given unique IDs.


\section{Sequential read}\label{sect.sequential-read}

[not up-to-date yet]

Note that an optimized, sequential mode of data access is provided for
use in reading back event counts.  This normally makes use of the
{\sym Module ID Register} in order to select each module in turn for reading
back data (although the {\sym Group ID Register} can also be used).  Each
module is activated, its data is read, and then the next module is
activated.  The last bit of data sent by each \cam\ chip is a parity bit
(even parity) needed by the error checking hardware.

This sequential module activation makes use of the {\sym LUT/Module
Address Counter} ({\sym LMAC}).  All {\sym LMAC}s initially have the
same value, and all are incremented simultaneously to maintain this
property. However, 

 Within each module, the 16-bit {\sym LMAC} address is
compared with the (primary) ID register, in order to select a single
module.  The comparison is carried out cooperatively by the 16 \cam\
chips in a module: each has a complete copy of the {\sym LMAC}, and
performs one bit of the comparison (see {\sym LMAPR}).  The {\sym
ECLR} determines how long each module will be activated, before all
the {\sym LMAC}s are incremented and the next selection is performed.


\section{Wired-AND/wired-OR}\label{sect.wired-and}

\section{scrap}

...
 



\endinput

The \cam\ chip and the \cam\ controller.
Knowledge of register length is used for deciding when the data phase
of a \cbus\ frame can be terminated (\sect{}) and an appropriate value
for the frame's parity bit issued (\sect{}).


