 % -*- Mode:TeX -*- 
\documentstyle{article}
\input cam8form.tex

\begin{document}
\input notecomm.tex
\input notemath.tex

\let\sym\sf	    % symbols done in sans serif
%\let\sym\tt	    % symbols done in \tt
\newcommand{\symdex}[1]{{\sym #1}}

\newcommand{\cam}{{\sc cam}}
\newcommand{\Cam}{{\sc Cam}}
\newcommand{\dram}{{\sc dram}}
\newcommand{\Dram}{{\sc Dram}}
\newcommand{\sram}{{\sc sram}}
\newcommand{\Sram}{{\sc Sram}}

\newcommand{\Land}{{\sc and}}
\newcommand{\HI}{{\sc hi}}
\newcommand{\LO}{{\sc lo}}

\title{Module selection}

\maketitle


\begin{history}
	\item DH 12 Oct 89 wrote original material
	\item TT 12 Dec 89 total rewriting based on that material
\end{history}
     
\section{Module selection}

From the host's viewpoint, all data transactions with \cam\ take place
through a single 16-bit-wide parallel port, which sits at the root
of the tree-shaped Tbus.

On {\em write} transactions (host to \cam), the data are physically
fanned-out by the Tbus to {\em all} \cam\ modules, which sit at the
leaves of the Tbus. 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.

On {\em read} transactions (\cam\ to host), it is essential for the
proper working of the Tbus that only {\em one} module be allowed to
``speak'' on the bus, i.e., to actively drive its data lines.

\medskip

\Cam's {\em 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.

\subsection{Selection modes}\label{selection modes}

The unit of selection handled by the module selection mechanism is an
entire module. Finer-grained addressing, such as write-enabling of
individual bit-slices within a module, is handled by other mechanisms.

The decision of whether or not a module should take active part in a
given write or read transaction is based upon a match between an {\em
internal name}, stored within the module, and an {\em external name},
broadcast by the host.

A module has two internal names, each consisting of a 16-bit integer.
The {\em ID name} is used to uniquely identify the module, and is
assigned once and for all at initialization time; the {\em group
name}, which may be changed from time to time, is used for grouping
modules as needed for the convenience of particular operations.

\medskip

Each Tbus data transaction intrinsically belongs to one of five
{\em module-selection modes}\/:
	\begin{itemize}
	\item \parhead{Broadcast write} All modules are
involved, regardless of their ID or group name.
	\item \parhead{Group write} The host sends a group name ahead
of the data to be written; unless this name matches a module's own
group name, the module will ignore the rest of the transaction.
	\item \parhead{Individual write} The host sends an ID name
ahead of the data to be written; unless this name matches a module's
own ID name, the module will ignore the rest of the transaction.
	\item \parhead{Individual read} The host sends an ID name, and
then listens to the Tbus. Only the module (if any) having the matching
ID will place the expected data on the bus.
	\item \parhead{Sequential read} This is an optimized
variant of the above individual read; it used for certain operations
where data have to be read in sequence from a number of modules having
ID names lying in a consecutive range of integers. The host only sends
the first value of the range; this value is stored by each module in a
counter that is incremented by 1 after each transaction of the
sequence. When this value (which still plays the role of {\em
external} name) happens to match a given module's ID name, that module
puts its data on the Tbus.
	\end{itemize}


\subsection{Selection-code match detection}

From the above discussion, it is clear that each module needs a number
of 16-bit registers,\footnote
	{Viz., to store its ID and group names, and to latch as needed
and possibly increment the external name.}
	as well as a 16-bit comparator to detect a match between
external and internal names.

We shall recall, however, that the entire 16-bit ``width'' of a module
is actually distributed over 16 physically separate bit-slices; each
slice has its one hearth chip, which handles one data line of the Tbus
and the corresponding bit of, say, the ID-name register.  Thus, within
this chip one bit of the external name and the corresponding bit of
the internal name are available for comparison---but to detect a full
16-bit-wide match the 16 one-bit-wide comparisons must \Land{}ed
together. Instead of using, for this function, a separate active
device straddling the 16 slices, we make recourse to the so called
``wired-\Land'' technique (see \sect{wired-or} for implementation
details), whereby 16 pins, one from each heart chip (specifically, the
\symdex{ModSel} pin, listed in \sect{pinout}) are electrically tied
together; each chip brings to this tie-point its own contribution to
the \Land\ function, and reads from it the overall result. More
specifically, the point is by default at a logic \HI; if any chip
detects a name mismatch within its own bit-slice, it will pull this
point down, to a logic \LO. Thus, the tie-point will remain \HI\ if
and only if internal and external names match at every bit position.

The \symdex{ModSel} pin the associated wired-\Land\ function are also
used for ID-name initialization, as discussed in \sect{id init}.

\subsection{ID-name initialization}\label{id init}

Before \cam\ can function properly, each module must be given a
distinct ID name. 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 is uniquely identified by its $x$, $y$, and $z$
displacement (in the torus coordinates) relative to the tagged module.

Indeed, in exactly one module in the entire \cam\ machine their is a
special hardware provision that allows the module's \symdex{ModSel} to
be externally pulled down under host control. The module thus selected
as the ``origin of coordinates'' is used as the source of a signal
that propagates along the glue lines, as directed by the host,
successively touching each other module and marking it as the one to
be named in turn.

\bigskip

[The modules will be provided with the capacity to be enabled if
their open collector selector bit is a `1' or if the same bit is `0'.
The exact value that will be used for selection will be specifed by an
Invert bit register in the I/O section of the modules.

   Normally, modules are selected when the bit is a `1'. During
initialization, the host broadcasts to all modules and writes an ID
number of 0 to them.  It also specifies the Invert bit value of `0' as
the selection condition.  The hardware is arranged so that the host is
tied to the open collector network of one of the space modules.  Now
the host selects on the module with ID number of 0.  Of course, all
modules are deselected since their open collector lines will remain
high.  The host, however, pulls the open collector line that it is
connected to low and thereby selects one of the space modules.  The
correct ID number is written to this module and the host instructs the
module to send a `1' across its glue line to the module to its right.

     Next, a broadcast occurs, and the host indicates a selection of
the module which receives a `1' on the glue lines from its left
neighbor.  The Invert bit selection condition is redefined as when the
selector bit is a `1'.  A new module is selected, and its ID is
updated.  Now the host broadcasts that all modules should send a `0'
over their glue lines.  The host reselects the last ID updated module
and programs it to write a `1' to its right neighbor.  A selection is
now done on the module receiving a `1' from its right neighbor, and
that ID number is written.  The procedure continues until each module
in the entire sea of space modules is uniquely labelled.]

\subsection{Sequential read mode}

In a typical course of operations, after running a certain number of
\cam\ steps one would want to read out the accumulated sums in the
event counters. Such a readout entails sequentially accessing all the
modules, but reading only a very small amount of information out of
each.

Using the individual-read mode (\sect{selection modes}) in these
circumstances would entail substantial overhead, in particular since
the bus direction must be reversed twice for each
transaction.\footnote
	{As explained in \sect{}, changing the bus direction in a
pipelined bus such as the Tbus holds up the bus for a time equal to
the pipeline latency---which increases with the number of bus levels.}



\bigskip

[It is therefore preferable that special hardware
be designed to handle this situation more effectively.

     At the start of a sequential access as described above, we clear
the address counters of the Lookup Tables.  We also position the event
counter to occupy 25 consecutive bit locations in the memory mapped
I/O register space.  At the end of an event counter read, we jump back
to the starting address of the event counter and simultaneously
increment the Lookup Table address counter by one.  The output of this
address counter is compared with the ID register of the space module.
The module is selected if there is a match.  This procedure will
automatically allow for sequential transmission of event counter
information from the space modules to the host.  Although the Lookup
Table counters in all modules count simultaneously, only the selected
space module will drive data to the host.]

\section{Hardware Implementation}

     A logic diagram of the possible hardware implementation of the
Module Select circuitry is shown on the attached page.  The top of the
diagram shows four bit comparators which will be used to compare the
ID bit with a specified ID bit; the ID bit with a Lookup Table Address
bit; the Group bit with a specified Group bit; and a Glue compare bit
with an incoming glue bit.  The result of these comparisons will be
used to determine whether the module is selected.

     The first three of the above four comparisons require interaction
with the other chips in the same space module.  Thus, depending on the
Selection Opcode value, one of these comparison outputs drives the
open collector Select pin of the chip.  The wired OR result of the
comparisons of all the chips in the space module is compared with the
Invert bit.  This specifies whether to select a module if the wired OR
comparison is a `0' or `1'.

     Finally, depending on the value of the Selection Opcode, the
result of the final comparison with the Invert bit or the Glue bit
comparison is used to select the module.  Note that the Broadcast line
to the chip will always enable the module when it is active.

     The hardware implementation shown here has several important
characteristics.  First note that the Selection Opcode register is
necessary in order to allow the user the different comparisons with
which to select the module.  However, once written, the Selection
Opcode register need not be rewritten unless a different comparison is
required for module selection.  For example, suppose the modules have
been programmed for ID selection, and the host wishes to select a new
module with a different ID.  Then, the host simply broadcasts the new
ID number to the modules without having to modify the Selection
Opcode.

     Also, if a module or group of modules is presently selected, the
host can broadcast anything to all the modules and automatically
default to reselecting that module or group at the end of the
broadcast\footnote{That is, when the broacast line goes low.}.  This,
of course, requires that the host not modify the parameters used to
select the module or group.

\end{document}