Norman Margolus Tommaso Toffoli

STEP: a SpaceTime Event Processor

Architecture Reference

(version 1.1.6)

MIT Laboratory for Computer Science Cambridge, MA 02139

Copyright \begin{matrix}c \\ ◯ \end{matrix} 1993, 1994, 1995 by Norman Margolus and Tommaso Toffoli

STEP Architecture Reference

/im/cam8/ref/arch/man.toc

Copyright \begin{matrix}c \\ ◯ \end{matrix} 1995 T. Toffoli DRAFT, January 6, 1995

Contents

1 Introduction 1 1.1 System overview . . . . . . . . . . . . . . 1 1.2 Step’s machine language . . . . . . . . . 2 1.3 Organization of this manual . . . . . . . . 2 1.4 Conventions . . . . . . . . . . . . . . . . . 2

1.4.1 Number representation . . . . . . . 2 1.4.2 Data and variable ordering …. 3 1.4.3 Signal polarity . . . . . . . . . . . 3

2 System structure 4 2.1 From host to modules . . . . . . . . . . . 4 2.2 Boxes and cables . . . . . . . . . . . . . . 4 2.3 Host/controller interaction . . . . . . . . . 4 2.4 Controller/module interaction . . . . . . . 5

2.4.1 CBus transactions . . . . . . . . . 5 2.4.2 STEPchip registers . . . . . . . . . 5

2.5 Real-time channels . . . . . . . . . . . . . 5 2.6 Software . . . . . . . . . . . . . . . . . . . 5

3 Geometry and scanning 7 3.1 Sites and layers . . . . . . . . . . . . . . . 7 3.2 Updating . . . . . . . . . . . . . . . . . . 7 3.3 Sectors, modules . . . . . . . . . . . . . . 8 3.4 Dimensions . . . . . . . . . . . . . . . . . 8 3.5 Block structure . . . . . . . . . . . . . . . 10

3.5.1 Glue ports . . . . . . . . . . . . . . 10 3.5.2 Wraparound . . . . . . . . . . . . 11

3.6 Blocks and strands . . . . . . . . . . . . . 12 3.7 Scanning . . . . . . . . . . . . . . . . . . . 13 3.8 Scan index . . . . . . . . . . . . . . . . . . 14 3.9 Scan permuter . . . . . . . . . . . . . . . 16 3.10 Kicking . . . . . . . . . . . . . . . . . . . 18 3.11 Gluing . . . . . . . . . . . . . . . . . . . . 18

4 Data streams 21 4.1 Sources and destinations . . . . . . . . . . 21 4.2 Event Counter . . . . . . . . . . . . . . . 22 4.3 Unglued and glued data . . . . . . . . . . 22 4.4 Data flywheel . . . . . . . . . . . . . . . . 22

5 Real-time input/output 24

6 Module interconnection and addressing 24 6.1 Module selection . . . . . . . . . . . . . . 24 6.2 Module ID initialization . . . . . . . . . . 25 6.3 Corner box . . . . . . . . . . . . . . . . . 25 6.4 Block wiring . . . . . . . . . . . . . . . . . 26

6.4.1 Single-block wiring . . . . . . . . . 26 6.4.2 Block wiring, improved . . . . . . 26 7 Command structure and interpretation 28

7.1 Step lists . . . . . . . . . . . . . . . . . . 28 7.1.1 Instruction format . . . . . . . . . 28 7.1.2 Instruction fetching . . . . . . . . 28

7.2 Step controller . . . . . . . . . . . . . . . 29 7.2.1 Next List Pointer . . . . . . . . . . 29 7.2.2 Interrupt Status/Control Registers 29 7.2.3 Current Instruction Pointer …. 30 7.2.4 Previous Instruction Pointer …. 31 7.2.5 Display Scan/Blank Length …. 31 7.2.6 Remarks . . . . . . . . . . . . . . . 31

R STEPchip registers 32 R.0 Module Select Register . . . . . . . . . . . 34 R.1 Run Mode Register . . . . . . . . . . . . . 34 R.2 Kick Register . . . . . . . . . . . . . . . . 35 R.3 Site Address Bit Select Register . . . . . . 36 R.4 LUT Address Source Register . . . . . . . 36 R.5 Flywheel Output Source Register . . . . . 36 R.6 Site Data Source Register . . . . . . . . . 36 R.7 Event Counter Source Register . . . . . . 36 R.8 Display Source Register . . . . . . . . . . 36 R.9 Show Scan Register . . . . . . . . . . . . . 37 R.10 Event Count Register . . . . . . . . . . . 37 R.11 LUT Index Register . . . . . . . . . . . . 37 R.12 LUT Index Permutation Register . . . . . 37 R.13 LUT I/O Register . . . . . . . . . . . . . 38 R.14 Scan Index Register . . . . . . . . . . . . 38 R.15 Scan Index Permutation Register . . . . . 38 R.16 Scan I/O Register . . . . . . . . . . . . . 39 R.17 Scan Format Register . . . . . . . . . . . 39 R.18 Offset Register . . . . . . . . . . . . . . . 40 R.19 Dimension Register . . . . . . . . . . . . . 40 R.20 Hardware Environment Register . . . . . 40 R.21 Multipurpose Pin Control Register …. 41 R.22 Glue Pin Connectivity Register . . . . . . 43 R.23 Module ID Register . . . . . . . . . . . . 43 R.24 Group ID Register . . . . . . . . . . . . . 43 R.25 Interrupt Enable Register . . . . . . . . . 44 R.26 Interrupt Flags Register . . . . . . . . . . 44 R.27 Verify Write Register . . . . . . . . . . . . 44 R.28 DRAM Ones Count Register . . . . . . . 45

STEP Architecture Reference

/im/cam8/ref/arch/_intro

Copyright \begin{matrix}c \\ ◯ \end{matrix} 1995 T. Toffoli DRAFT, January 6, 1995

1 Introduction

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

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

1.1 System overview

In the step architecture, the system being modeled is represented by a collection of discrete cells arranged in a regular lattice. This lattice may have more or fewer than three dimensions, it may have an arbitrary crystallographic structure^{1} (in particular, it need not be a cubic lattice), and may or may not be wrapped around.

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

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

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

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

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

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

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

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

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

1Cf. Neil Ashcroft and David Mermin, Solid State Physics, Saunders College (1976).

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

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

1.2 Step’s machine language

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

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

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

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

1.3 Organization of this manual

Chapter 2 describes the overall structure of the step system and highlights its chain of command.

Though commands are passed down to and interpred by different levels of the hardware hierarchy, the step programmer, as the commander, need only speak one language—that of the “control room;” this is described in Chapter 7.

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

Chapter 3 presents the basic geometrical and kinematical aspects of step’s data organization, data movement, and data interaction. Chapter 4 discusses the data streams within a module and the way they are steered. Chapter 5 describes real-time input/output resources. Chapter 6 describes the way modules are interconnected, and how they are addressed.

Appendix ?? is the reference for the step driver. Appendix R describes in detail the stepchip registers, which are the explicit target of all step commands; thus, this appendix can be used as a concise but comprehensive reference for all step programming.

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

1.4 Conventions

Here we list a number of general conventions followed throughout this manual.

1.4.1 Number representation

Numerals in typewriter font are in base sixteen; thus 40=64 and FF=255.

1.4.2 Data and variable ordering

In listings, tables, and figures, we had to fight a hard struggle to reconcile conflicting conventions concerning the ordering of items and the orientation of axes.

There are two basic sources of conflict. One conflict is between the “most significant first” approach, typified by the way we write a number such as ‘1992’ starting with the thousands and ending with the units, and the “first causes first” approach, typified by the way the electronic engineer draws the stages of digital counter, starting with the units stage on the left and making the carry propagate left-to-right. The other conflict is between the way a mathematician would write an i, j array, with j increasing left-to-rigth and i top-to-bottom, in agreement with western-style writing, and the way a physicist would draw an x, y or an x, t diagram on the page, with x pointing rightwards but y or t pointing upwards. Note that the “mathematician’s” approach is also the one used in scanning an ordinary crt monitor—left-to-right and then top-to-bottom.

After much soul-searching, we took the responsibility to enforce a consistent, universal convention: in any enumeration, the natural ordering of the items (i.e., increasing values of the enumeration index) will be reflected by the typographical ordering (left-to-right, and, for a second index, top-to-bottom).

Thus, an array indexed by x and y will be displayed with x increasing from left to right and y from top to bottom, as in the following diagram

[figure: x; y; z]

Here, the diagram’s third axis, z, is represented as pointing into the page).

Note that, with these conventions, the “handedness” of the (x, y, z) frame is the same as that that results from the more conventional ordering of axes, illustrated by the following diagram

[figure: x; z; y]

Similarly, a 16-bit computer register will invariably be represented as follows

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

and a text description of this register will list individual bits or fields in same order, as in the following example:

0–6 ASCII character
7 Parity bit
8–15 Not used

When the contents of the register is interpreted as a binary-encoded integer by the computer’s arithmeticlogic unit or its address-arithmetic unit, bit 0 will represent the least significant binary digit (units), and in general bit n will represent the coefficient of 2^{n}.

The above ordering convention will be broken in only one circumstance. In deference to universally ingrained practice, ordinary numerals in the text will be written as usual with the most significant digit first. Thus, the number represented by the following register contents

1 0 0 0 1 1 1 1 0 0 0 0 0 0 0 0
0  15

will be written, in text form, as hexadecimal 00F1 or decimal 237.

1.4.3 Signal polarity

Signal names, typeset in sans-serif face, are chosen so as to have appropriate mnemonic value. For instance, the CBus Reset signal has a value of 1 (logical true) when the step machine is being reset, and 0 (logical false otherwise.

Physically, on the the CBus wires, this signal travels in complemented form, indicated by Reset*. However, we shall usually mention the signal in its native form, saying, for instance, that “in certain conditions Reset is asserted”; this implies that, in those conditions, the physical signal Reset* is negated.

The complemented form, Reset*, would be used only when tabulating the pinout of a chip or connector, to make it clear that the physical signal present on that pin is the complement of Reset.

STEP Architecture Reference

/im/cam8/ref/arch/_struct

Copyright \begin{matrix}c \\ ◯ \end{matrix} 1995 T. Toffoli DRAFT, January 6, 1995

2 System structure

The bulk of step’s data processing activity is uniformly distributed over the step space—an indefinitelyextended array of “computationally active” sites—as explained in §3, §4.1. 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.

2.1 From host to modules

The step space is subdivided into equal portions called sectors (§3). Each sector is handled by a hardware 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 machine is governed and monitored by a general-purpose computer called the host. The host we are currently using is a sun sparcstation—which features a high-performance external bus called the SBus.

All exchanges between the host and the step machine are mediated by the step controller (Fig. 2.1), which communicates with the host on the SBusand drives the modules via the CBus; the latter is a tree-like bus having the controller at its root and the individual modules at its leaves. Physically, the controller consists of a small board plugged into one of the SBus slots.

In what follows, the step controller and the step machine will simply be called ‘the controller’ and ‘the machine’.

step controller

[figure] [figure] [figure] [figure] [figure] [figure]

SBus CBus

step modules host

2.2 Boxes and cables

As explained in §3.5, it is convenient to group sectors into 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 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 CBus cable—the host link— leads from the step controller in the host to the “corner box” of the array.

2.3 Host/controller interaction

The “program” that the controller executes consists of a sequence of instructions, called step list, residing in the host’s memory.^{1} The step-list instructions are translated by the controller into commands to be broadcast on the CBus. 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 controller, 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 controller; to this end, the controller is given 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 controller may issue SBus interrupts.

All other communication between the host and the controller (for instance, to start the controller on a new step list, or to perform initialization or readout functions) is initiated by the host. The controller contains a number of hardware registers, called control registers, which are use to initialize, direct, and monitor its operation (§7.2).

Figure 2.1: The step controller drives the assembly of step modules via the tree-like CBus; it communicates with the host via the SBus.

1The step list is analogous to the display list routinely used for interfacing a conventional processor to a specialized, highperformance graphics processor.

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.

The fundamental cycle of interaction between the host and the step controller revolves around the Next List Pointer register (NLP)—which acts as a mailbox—as follows (cf. §7.2.1)

1. Whenever the host has a step list that it wishes to be executed, it looks at the NLP; as soon as it finds it empty, it puts in it a pointer to this step list.

2. Whenever the controller is idle, it looks at the 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.

2.4 Controller/module interaction

2.4.1 CBus transactions

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

Every CBus transaction can be thought of as an access (read or write) to the stepchip 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 stepchip 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 Module Select Register (cf. §6.1). 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 all modules).

2.4.2 STEPchip registers

The 29 stepchip registers come in different lengths. Most of these registers have a fixed length, ranging from 1 to 120 bits. Two registers, however, namely the LUT I/O Register (§R.13) and the Scan I/O Register (§R.16), 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 controller into the chip before the transfer itself takes place.

Many of the stepchip 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 Event Counter Source Register (§R.7) 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.

2.5 Real-time channels

In addition to communicating with the host, the step machine can communicate with the outside world through a flywheel bus that sequentially addresses step space sites as they are being scanned cf. §3.7. Different kinds of data associated with each site can be read or written onthe-fly by any device having adequate real-time response. A distinguished output tap on the flywheel bus, called the 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×512 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 (s/vhs).

2.6 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 device driver. The step driver is only of concern to systems sofware developers. Its specifications are found in Appendix ??.

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:

• StepForth. 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 registerlevel access, while others, useful for applications programming, support various levels of modeling abstraction.

• C libraries. The software modules used by Step-Forth and utilities are being recast as a collection of C libraries, in view of having systems software completely written in C.

• STEP simulator. 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.

STEP Architecture Reference

/im/cam8/ref/arch/_geo

Copyright \begin{matrix}c \\ ◯ \end{matrix} 1995 T. Toffoli DRAFT, January 6, 1995

3 Geometry and scanning

In this chapter we present the basic geometrical and kinematical aspects of step’s data organization, data movement, and data interaction.

3.1 Sites and layers

Step’s main business is the fine-grained simulation of spatially-extended systems; this is achieved by the iterated updating of a large collection of bit-sized state variables according to laws that are, by and large, local and uniform.

One may visualize these bits as arranged in a multidimensional array—which we shall call step space—that plays in the simulated system a role somewhat analogous to that of ordinary physical space. Each element of the array consist of a collection of bits, which play a role somewhat analogous to that of state-components in ordinary physics. This arrangement is illustrated in Fig. 3.1, where dots represent bits. In this figure the array is two-dimensional, and the different state-components are drawn on separate planes for clarity.

We shall formalize the above concepts by saying that each state-variable bit in a step machine is uniquely identified by a combination of two labels, namely a site address (“which array element”) and a layer number (“which state-component”). If we fix the site address and let the layer number run through all its possible values, we obtain a data structure called a site (the vertical “pile” of bits in Fig. 3.1). If we fix the layer number and let the site address run through all its possible values, we obtain a data structure called a layer (the horizontal “sheet” of bits in the same figure). The present implementation of step uses sixteen layers, numbered 0 through 15 or, where hexadecimal is more convenient, 0 through F.

[figure: site; layer]

Figure 3.1: State-variable bits in step are arranged in layers and sites.

Step layers can extend indefinitely in one, two, or three dimensions called extendible dimensions. By “indefinitely” we mean that no limits are set by the architecture: an arbitrary extension along any of these dimensions can be achieved by connecting end-to-end an appropriate number of step modules. The last module of the chain will be connected to the first, so as to achieve wraparound (see Chapter 3.5 for more details). Thus, the three extendible dimensions of step space have the structure of a three-dimensional torus (3-torus).

Additional wrapped-around dimensions, called internal dimensions, are possible, but the number and extension of the internal dimensions are subject to certain implementation-dependent tradeoffs, since these internal dimensions are assembled out of the finite resources contained within a module.^{1}

Though the internal dimensions are naturally arranged as a multidimensiona torus much as the extendible dimensions, no spatial interpretation need to associated to this arrangement. In particular, the space spanned by the internal-dimensions coordinates can be treated as the address space of a “heap” of data associated with each site (cf. §??).

3.2 Updating

The entire array of step sites (or a selected subarray if desired) is made to evolve in time by repeated applications of a basic procedure, called a scan, conceptually consisting of two stages:

• Data transport. Each of the sixteen layers is independently shifted as a whole by an arbitrary number of positions in an arbitrary direction. We still end up with a pile of bits at each site, but with a new make-up.

• Data interaction. We now take each pile of bits and we send it to a 16-input, 16-output lookup table; the lookup table returns a new pile, which we put in place of the original one.

Two remarks are in order. At the data-transport stage, the shift performed on each layer is a uniform and datablind operation (each bit is moved by a fixed offset, independently of its position and its value); in a suitable implementation, this can be achieved by simply shifting the frame of reference (i.e., incrementing a pointer) rather than moving the data themselves. At the data-interaction stage, each site is processed independently: sites do not

1Basically, the volume of the hyperspace spanned by the internal dimensions cannot exceed the site capacity of a step module.

need to look at one another, and the order in which they are processed is irrelevant. Thus, the implementation is free to use any combination of serial an parallel processing.

Most of the rest of this manual can be thought of as a description of how the above conceptual updating scheme is implemented by the step architecture.

3.3 Sectors, modules

Functionally, a step machine consists of a number of identical modules interconnected as a three-dimensional array (cf. Fig. 3.2). Each dimension is wrapped around on itself (for example, in Fig. 3.2, the side facing in the positive x direction joins the side facing in the negative x direction), yielding the structure of a three-dimensional torus (the canonical way to achieve this wraparound is discussed in Chapter 3.5).

Each module is responsible for storing and updating a portion, called a sector, of the entire array of sites. The number of sites in a sector is a fixed power of two (2^{n}, where n equals 22 or 24 in the present implementation, depending on the size of the dram chips used), while there is no design limit on the number of sectors (in practice, a limit is set by economic factors sooner than by engineering constraints).

The site address consists of two parts: the first tells where in a sector a site lies, while the second identifies the sector itself (cf. Fig. 3.4). When dealing with an individual module, there will be no danger of confusion if we use the term ‘site address’ just for the first part, i.e., for the address within the sector served by the module; similarly, the meaning of ‘layer’ will be restricted to that portion of a layer which is contained within the sector.

3.4 Dimensions

For definiteness, let us consider a step machine consisting of 2^{6}=64 modules physically arranged in a 4×4×4 array, using 16-Mbit dram chips (2^{24} bits) to store the layers within each module. Suppose further that each sector of 2^{24} sites has been configured, as will be explained in a moment, as a parallelepiped of 1024×128×128 sites (2^{10}×2^{7}×2^{7}). In this situation, illustrated in Fig. 3.2, a full site address will consist of a string of 24+6 bits having the format of Fig. 3.4, where address bits are grouped and labeled x, y, and z according to the dimension they refer to—with x′, y′, and z′ denoting those portions of the site address that spill over the sector address. Thus, the total size of the site array will be 4096 (1024×4) in the x dimension and 512

[figure: x; y; z]

Figure 3.2: Sixty-four sectors (each realized by one step module) arranged in a 4×4×4 array. Each sector has been configured as a three-dimensional array of 1024×128×128 sites, with the longer side along the x dimension.

(128×4) in both the y and z dimensions, for a total of 1 Gigasite.

full site address

\overbrace{x  y  z_{0  23}}^{position within sector} \overbrace{x′ y′ z′_{0  5}}^{sector}

Figure 3.3: Representation of full site address. The 24+6 address bits have been grouped according to whether they encode x, y, or z coordinates. Primed letters denote bits devoted to the sector address.

How does one establish the number of dimensions and the number of address bits devoted to each dimension? The structure of the sector address (right portion of Fig. 3.4) is essentially determined by how many modules are present and how they are wired together.^{2} Moreover, the typical mode of operation for the machine is for all sectors to operate in parallel carrying out identical orders; clearly, when programming the parameters of a such a mode of operation, the sector address is not a relevant variable.

0  Dimension Cut Mask  22
•  •
↓  ↓

For the above reasons, here we shall restrict our attention to the site address within a sector. Since this is a 24-bit string, there are 23 points where one can “cut” it. By actually cutting the string at two of these places, as in Fig. 3.4, one obtains three separate strings corresponding to the three address slices denoted by x, y, and z in Fig. 3.4. The cut points are specified by a 23-bit^{3} Dimension Cut Mask (§R.19); each ‘1’ in this register specifies a cut at the correponding position. Each of the resulting three slices will be treated by the step machinery as a separate component of a site’s spatial coordinates, corresponding to a separate dimension.

0  9 10  16 17  23 Figure 3.4: Each ‘•’, representing a ‘1’ in the Dimension Cut Mask, introduces a cut (indicated by a thick band) in the corresponding position of the site address. The resulting slices of the site address represent separate components (one for each dimension) of a site’s spatial coordinates.

2Quite a bit of flexibility still remains even at this stage, since the fixed interconnecting wires can be used in different ways to achieve different configurations, as discussed in Chapter 6.

More generally, by cutting the site-address string (and other registers of the same format associated with address arithmetic) at d−1 two places, one obtains d address slices of various lengths (the sum of these lengths will, of course, total 24). The actual effect of the “cutting” is that arithmetic carries and borrows are prevented from propagating across the cutpoints, thus making addressarithmetic operations performed on one slice independent of those performed on the adjacent slices.

In this way, the 2^{n} sites of a sector are formally arranged into a d-dimensional parallelepiped of sides 2^{n_{1}}, 2^{n_{2}}, …, 2^{n_{d}}, where n_{1}, …, n_{d} are the lengths of the d site-address slices.

In the following figures, it will not be necessary to explicitly show the Dimension Cut Mask; the position of the cuts will simply be indicated by dark bands as in Fig. 3.4. Shifting the positions of the cuts from (a) to (b) to (c) in Fig. 3.5 changes the aspect ratio of a sector from 4:\frac{1}{2}:\frac{1}{2} to 1:1:1 to 1:2:\frac{1}{2}, as in (a), (b), and (c) of Fig. 3.6.

(a) _{0  9 10  16 17  23}

(b) _{0  7 8  15 16  23}

(c) _{0  7 8  16 17  23}

Figure 3.5: Different sets of cuts in the site-address string, as in (a), (b), and (c), yield different aspect ratios for a sector, as in Fig. 3.6.

As explained above, the Dimension Cut Mask determines the number of dimensions of a sector and their aspect ratio, but does not specify which (if any) of these dimensions should be associated with the x, y, and z axes along which the sectors themselves are arranged in step space. This is done by the three Dimension Cut Pointers (XDCP, YDCP, and ZDCP; §R.19), each of which points to the high end (i.e., the carry position out of the most

Figure 3.6: Different sector aspect ratios, namely 4: \frac{1}{2} : \frac{1}{2} in (a), 1:1:1 in (b), and 1:2: \frac{1}{2} in (c), arise from different sets of cuts in the site-address string (cf. Fig. 3.5).

significant bit) of one of the above dimension slices—as indicated in Fig. 3.7.

Figure 3.7: The three Dimension Cut Pointers tell which dimension slices are to be associated with the array axes x, y, or z. Any dimension thus marked becomes an extendible dimension: the dimension marked x, say, is continued from one sector to the next along the x axis instead of wrapping around within each sector. The present arrangement of pointers corresponds to the situation depicted in Fig. 3.2 and Fig. 3.4).

In Fig. 3.8 we illustrate a more general situation. The site-address string is cut into five slices by the Dimension Cut Mask. Of these, three are identified as extendible dimensions x, y, and z by the Dimension Cut Pointers (note that the order is different from Fig. 3.7). The remaining two slices, labeled u and v, represent the address components for additional internal dimensions—which wrap around within each sector rather than extend from one sector to the next.

Figure 3.8: Here the site address is partitioned into five slices by the Dimension Cut Mask. Of these, three have been associated with the x, y, and z axes by the Dimension Cut Pointers; the remaining two slices, labeled u (address bits 10–13) and v (address bits 20–23) correspond to nonextendible or internal dimensions.

3This register actually consists of 24 bits, but the last bit is not used.

With reference to Fig. 3.2, where all three extendible dimensions are used, each sector is in contact with the six adjacent sectors through its six faces, which will be labeled in an obvious way x_{−}, x_{+}, …, z_{−}, z_{+}, as in Fig. 3.9. (Note that sectors wrap around in each dimension, so that no faces remain exposed.)

[figure: x_{−}; x_{+}; y_{−}; y_{+}; z_{−}; z_{+}]

Figure 3.9: Labeling of a sector’s faces, with respect to the orientation of the coordinate axes x, y, and z of step space (cf. Fig. 3.2).

3.5 Block structure

In the step architecture, the minimal functional unit is the individual module: realizations of arbitrary size can be built by simple iteration of this basic unit.

However, for reasons of concrete interconnection geometry it is desirable to introduce a larger “prefabricated” structure, called a block, consisting of eight sectors that stand in a distinguished geometrical relationship with one another within step space. This logical grouping of sectors is reflected in the implementation, where the eight modules that realize the eight sectors of a block are housed in the same physical box (cf. §1.1 and §6.4).

We have seen (§3.1) that the topology of the three extendible dimensions of step space is that of a 3-torus. The block structure discussed here provides a systematic way to embed the 3-torus into ordinary 3-space (threedimensional space) in such a way that

• Boxes can be stacked in a straightforward threedimensional array (no circular arrangement of boxes to make opposite ends of the array meet).

• No matter what size the array, modules that realize logically contiguous sectors are found in adjacent boxes. This arrangement avoids size-dependent propagation delays.

3.5.1 Glue ports

As mentioned in §3.3, each step module is responsible for storing and updating the dynamical variables associated with a sector, i.e., a parallelepiped-shaped portion of simulation space. A sector exchanges information with contiguous sectors, along the three extendible dimensions x, y, and z, through its six faces—labeled x_{−}, x_{+}, …, z_{−}, z_{+} as in Fig. 3.9.

Since a module scans the sites of its sector sequentially (cf. §3.7), data communication between contiguous modules is handled serially by serial glue ports, using a modest number of pins. For the purposes of the present chapter, a glue port’s detailed structure and the direction of data flow (in or out of a module) on a particular port line at a given moment are irrelevant; all that matters is that the glue ports handle the flow of information in and out of a sector’s faces.

The assignment of a specific glue port to a specific face is software-reconfigurable. Here, by ‘glue port x_{−}’, say, we shall mean whatever port has been assigned to face x_{−}.

3.5.2 Wraparound

In some applications, the simulation volume represented by an array of step sectors arranged as in Fig. 3.2 will correspond to a similarly shaped volume of the system under study. The exposed faces which delimit this volume represent the interface between the simulated portion of the system and the rest of the system which surrounds it; the latter is not explicitly modeled within the step machine. In these circumstances, it is up to the experimenter to feed appropriate boundary conditions (e.g., constant, random) to the exposed faces so as to approximate the influence of the surroundings.^{4}

Figure 3.10: Two-dimensional array wrapped around in one dimension (cylinder).

However, in most applications (and chiefly in those of a more conceptual nature) the experimenter will prefer to model a self-contained system having no distinguished boundaries. To this purpose, one can bend the stepspace volume back onto itself, directly connecting each exposed face to the corresponding one on the opposite side.^{5} Fig. 3.10 shows a two-dimensional array wrapped around in one dimension (cylinder), while Fig. 3.11 shows a two-dimensional array wrapped around in both dimensions (torus).

4This can be done in a variety of ways, as explained elsewhere.

5Physicist often use the term ‘periodic boundary conditions’ for such an arrangement.

Figure 3.11: Two-dimensional array wrapped around in two dimensions (torus).

With step, the most demanding situation is when a three-dimensional array as that of Fig. 3.2 is to be wrapped around in all three dimensions, yielding a 3torus. That is, how is this functional wraparound going to be achieved physically?

A simple way is to arrange the modules in straight rows as in Fig. 3.2, and join ports at opposite ends with long “return” cables, as shown in Fig. 3.12 for one dimension.

[figure: x_{−}; x_{−}; x_{−}; x_{−}; x_{+}; x_{+}; x_{+}; x_{+}]

Figure 3.12: Wraparound of modules, in one dimension.

However, as the number of modules in a row increases, such an arrangement would lead to proportionally longer propagation delays, and the clock rate would have to be slowed down correspondingly.

3.6 Blocks and strands

Let us consider now the interleaved arrangement of Fig. 3.13, where both legs of a round trip are evenly strewn with modules. In this arrangement the physical distance between logically contiguous sectors is somewhat greater than in Fig. 3.12, but the need for a return wire of unbounded length is eliminated.

[figure: x_{−}; x_{−}; x_{+}; x_{+}; x_{+}; x_{+}; x_{−}; x_{−}]

Figure 3.13: Interleaved wraparound, in one dimension.

Fig. 3.13 suggests that in the interleaved arrangements individual modules may be left in essentially the same physical position as in Fig. 3.12 (and, in three dimensions, as in Fig. 3.2); only their interconnection is modified. While the new interconnection may entail a longer propagation delay, the extra delay is a fixed one, independent of the number of modules in the chain.^{6}

The interleaved arrangement of Fig. 3.13 consists of two parallel strands of modules, one with the x_{+} ports facing rightward and one leftward (and conversely for x_{−}). With this arrangement, the minimal repetitive unit is no longer the individual module, but a block of two modules—one from each strand—as shown in Fig. 3.14. Though in close physical proximity, the two modules of a block are not connected to one another within the block itself.

[figure: x_{−}; x_{−}; x_{+}; x_{+}; x_{+}; x_{+}; x_{−}; x_{−}]

Figure 3.14: With interleaved wraparound, the minimal repetitive unit is a two-module block.

In step, the above doubling up and interleaving of module chains is carried out for all three dimensions, leading to a minimal repetitive unit consisting of an eightmodule block. A block can be thought of as a sector-size “window” on the eight three-dimensional strands that run parallel to one another when the 3-torus is “squashed” onto ordinary 3-space. Figures 3.15 and 3.16 illustrate the analogous situation in two dimensions.

Note that, just as in the one-dimensional case there are two separate strands of one-dimensional space that run parallel to one another but with opposite orientations within a block (cf. Fig. 3.14), and in the two-dimensional case there are four separate strands of two-dimensional space (Fig. 3.16), thus in three dimensions each block is traversed by eight separate strands of 3-space, one for each of the eight possible orientations.

These eight strand orientations (and thus the eight sectors within a block) will be labeled by three binary parameters, s_{x}, s_{y}, and s_{z}, defined as follows. For a given strand, we’ll let s_{x}=0 if the x_{+} ports of that strand face in the positive x direction of physical space, and s_{x}=1 if they face in the opposite direction (cf. Fig. 3.14); and similarly for s_{y} and s_{z}. To each of the eight strands there will correspond a different value of the triplet ⟨s_{x}, s_{y}, s_{z}⟩, which can also be interpreted in an obvious way as an

6A closer packing of modules in the given dimension is of course possible, but that only at the cost of building up thickness—and thus propagation delays—in another dimension.

Figure 3.15: A two-dimensional torus, which is usually visualized as embedded in three-dimensions, here is shown in the process of being “squashed” onto two-dimensions. Like a folded handkerchief, the resulting structure has a “thickness” of four two-dimensional layers, or strands.

Figure 3.16: In the squashed torus of Fig. 3.15, a block is a sector-size window cutting through all four two-dimensional strands.

integer S in the range 0–7, as in the following table

\begin{matrix}s_{x}s_{y}s_{z} & S \\ 000 & 0 \\ 100 & 1 \\ 010 & 2 \\ 110 & 3 \\ 001 & 4 \\ 101 & 5 \\ 011 & 6 \\ 111 & 7 \end{matrix} .  (3.1)

To each of the eight strands the block contributes a six-ported module, for a total of 8 modules and 48 ports in each block, as detailed in the following table (3.2)

strand  ports
s_{x}s_{y}s_{z} S x_{−}x_{+} y_{−}y_{+} z_{−}z_{+}
000 0 • • • • • •
100 1 • • • • • •
010 2 • • • • • •
110 3 • • • • • •
001 4 • • • • • •
101 5 • • • • • •
011 6 • • • • • •
111 7 • • • • • •

(3.2)

Each of a blocks’s 48 glue ports, represented here by black dots, is uniquely identified by a face label (x_{−}, x_{+}, …, z_{+}) and a strand label (S = 0, …, 7). It is possible to physically arrange a block’s glue ports so that adjacent blocks directly mate both mechanically and electrically.

Block wiring (between blocks and within blocks) is discussed in §6.4.

3.7 Scanning

While the step modules operate in parallel (and it is in this sense that step is a parallel processor), sites within each sector are accessed serially. Here we are concerned with the scanning mechanism that determines which sites are accessed and in what order.

Scanning is concerned with a site’s address—rather than its contents and what is done with it. Thus, though the following considerations are coached in terms of siteupdating—where the mode of access is read-modify-write, they apply equally well to the read-only and write-only access modes, which are used in a variety of situations involving display, analysis, and input/output of site data.

In the most basic mode of operation of step, an identical updating procedure is used for each sector, so that there is complete symmetry between the sectors. The procedure itself is applied in turn to every site of the sector.^{7} (or of whatever portion of the sector one wishes to restrict one’s attention; cf. below). Thus, within each sector certain sites are updated before others. However, the functional symmetry between the sites of a sector is not destroyed by this ordering, because the results of updating are independent of the actual sequential order of site access. This invariance leaves one free to manipulate the order of access for other purposes, such as producing a display of a given format (e.g., quadruple-interlaced) or accessing sites in the most convenient order for accumulating site statistics (cf. §4.2).

Many variations of the above basic mode are possible. In some situations, one may want to restrict the updating activity within each module to just a fraction of a sector, so as to have more frequent updates. In other situations, a sector is divided into a number of subsectors, and the parameters for the updating procedure are changed from one subsector to the next (e.g., one may use different lookup tables).

7This is done in parallel on all sectors, so that homologous sites in different sectors are affected at the same moment.

From the host’s viewpoint, the primitive hardware function used by step for sequentially accessing sites is called a scan; this is an indivisible, uninterruptible sequence of site-accesses, autonomously performed and timed by the module.^{8} After setting the desired scan parameters within a given module the host schedules a scan; this scan will be started by the module at the earliest appropriate moment and will proceed to completion without host assistance (§R.1). The module will then notify the host that the scan machinery is available for a new scan.

Fig. 3.17 gives a simplified view of the scan generator. Duch greater detail is shown in Fig. 3.18; details will be expanded in the following sections.

The prime mover of the entire address-generation chain is the Scan Index Register (§R.14)—a straightforward 24-bit binary counter which during a scan is normally incremented at the system clock rate, thus converting the steady passage of time into an ascending sequence of integers.

Let us for a moment identify the contents of this register, or scan index, with the site address: as the scan index increments during a scan, the space of all possible 2^{24} site addresses within a sector is traversed in the most straightforward fashion. For instance, if the site address has been partitioned into three slices corresponding to dimensions x, y, and z, as in Fig. 3.7, regular incrementing of the scan index would scan this space as if by three nested loops, the x dimension corresponding to the inner loop and being scanned fastest.

In reality, the step scan generator provides a programmable conversion stage, called the scan index permuter, between the scan index and the site address (Fig. 3.17); by this means, the regular ascending order of the scan index can be transformed into a variety of more complex access patterns at the site-address level (§3.9). Another programmable stage, the offset adder, converts the site address into a dram address, taking into account “kick” information (§3.10)—which is in general different from layer to layer. The dram address is the ultimate offspring of the scan generator, and points directly at a physical bit in the dram chip.

Besides controlling the dram, the scan generator also controls the glue circuitry that regulates the exchange of scanned data between adjacent sectors; in a sense, this section of the scan generator interfaces the “site-within-sector” portion of the site address with the “sector” portion (cf. Fig. 3.4).

scan index

[figure]

scan index permuter

site address

offset

kick

[figure] − [figure] +

[figure]

dram address

glue control

Figure 3.17: Simplified view of the step scan generator. Square boxes indicate registers (for instance, ‘kick’ denotes the contents of the Kick Register); round boxes, combinational logic. Though the scan index increments steadily during a scan, the corresponding site-address sequence may be more complex, since through the permuter the twenty-four bits of the scan index may undergo an arbitrary permutation. By adding a constant to the site address, the ⊕ box shifts the spatial origin of a layer, resulting in a virtual shift of the layer’s contents. The offset specifies the current value of this constant, while the kick specifies by how much the offset should be modified between one scan and the next. (Not shown in the figure, the kick is subtracted from the offset before the new scan; during the scan itself, both kick and offset remain constant.) Data carry-over from one sector to the next resulting from this offset change is handled by the glue-control machinery, to which the ⊖ box supplies the relevant information.

3.8 Scan index

The scan index steadily increments by one unit at a time during a scan, cycling back to 0 after reaching its maximum value, 2^{24} − 1, or, in hexadecimal, FFFFFF.

In the most basic situation, the scan index will start from 0 and traverse the entire range in a single scan. However, one can request shorter scans, spanning a submultiple (by a power of 2, and boundary-aligned on the same power of 2) of this range. In any case, the next scan will start where the previous one left off (unless, of course, in the intervening time the host writes a different value in the Scan Index Register).

8Within each module, each of the sixteen layers is served by a separate stepchip, which contains a full implementation of the scanning mechanism. In principle, while accessing in a given layer the bit located at site address i, one may access in another layer the bit located at a different site address j. Unless explicitly stated, we shall assume that the same site address is generated by all sixteen stepchips of a module.

Figure 3.18: Block diagram of the basic scanning/gluing/updating circuit. The little white circles denote data taps from which signals are made available to additional circuitry not shown in the figure. Conversely, each of the little boxes labeled mix indicates a place where several signals, besides the main one shown in the figure, are available for use. In particular, the data path from glued data to site source through the lut can be complemented by one going through an external coprocessor; the latter may span several modules.

For example, if the starting value is 000100 and the scan length (as determined by the End-of-Scan Pointer, §R.17) is 40, on the next four scans the scan index will step through the following values (columnwise)

       000100  000140  000180  0001C0 000101  000141  000181  0001C1 000102  000142  000182  0001C2 ⋮  ⋮  ⋮  ⋮ 00013E  00017E  0001BE  0001FE 00013F  00017F  0001BF  0001FF ,  (3.3)

coming to rest on the value of 000200.

3.9 Scan permuter

In the most basic situation, the scan index is used directly as a site address, so that the site-address space itself is traversed in a steadily ascending fashion (cf. §3.8). In many circumstances, however, it is desirable to access sites in a more complex order. The scan index permuter (§R.15) provides a certain class of scan-index-to-site-address transformations; these include arbitrary permutations of the scan-index bits.

We shall introduce the scan index permuter by giving a simple example of its use.

Let us first consider the basic situation. Suppose we have a system of 256K sites arranged as a two-dimensional array of 512×512, or 2^{9} × 2^{9}. As shown in the following diagram

,

the low-order 9 bits of the site address span the x dimension; the following 9 bits span the y dimension; the remaining 6 bits are not used (and are not shown in the diagram).

A step module is able to update an array of this size in less than 1/60 sec. We shall arrange for the updating scan to match the format and timing requirements of a vga-like crt monitor (namely, a horizontal rate rate of about 31 KHz and a vertical rate of about 60 Hz), so that the evolution of the system can be displayed in real time on the monitor, formatted as in Fig. 3.19, without the need for a frame buffer.

Since the scan index is incremented sequentially, so that higher order bits correspond to coarser time divisions, the low-order 9-bit slice of the scan index, labeled h in Fig. 3.20, will be associated with the monitor’s horizontal sweep, which takes place at the faster rate. In other words, as h increments from 0 to 511, the crt beam will

0  511 0 511  x ⟶ y ; ↓

Figure 3.19: A 512×512 array can be updated at 60 frames/sec and displayed in real time on a vga-like crt monitor. The corresponding arrangement of the scan permuter is given in Fig. 3.20.

sweep a horizontal line, displaying 512 pixels corresponding to the contents of whatever sites are traversed by the site address during that time. Since we want a horizontal sweep to correspond to the array’s x dimension, the x slice of the site address will be derived directly from the h slice of the scan index, as shown in Fig. 3.20.

Figure 3.20: When the bits that make up the scan index are used in their natural order to make up the site address, the least significant bits of the site address (those associated with the x dimension, in this case) are incremented at the fastest rate. The label h denotes that section of the scan index that cycles at a rate compatible with a crt’s horizontal sweep, while v corresponds to a vertical sweep. The resulting crt display format is shown in Fig. 3.19.

Similarly, the y slice of the site address will be derived directly from the v slice of the scan index, so that the y address will steadily increase with time as the crt beam performs a vertical sweep.

Of course, in order to display a complete picture, incrementing of the scan index will be suspended during horizontal and vertical retraces (cf. Scan Sync Mode in §R.1).

Let us consider now a more complex scanning situation. We have a system of 256K sites as in the previous example, but consisting of a three-dimensional array of 64×64×64, or 2^{6} × 2^{6} × 2^{6}. As shown in the following diagram

,

the site address consists of three 6-bit slices, corresponding to the x, y, and z dimensions (the 6 unused bits are not shown in the diagram).

One way to display this system on a crt monitor is to show 64 two-dimensional slices, arranged side-by-side on an 8×8 array as in Fig. 3.21.

0 ··· 63 ^{0 ··· 63} ^{0 ··· 63} ^{0 ··· 63} ^{0 ··· 63} ^{0 ··· 63} ^{0 ··· 63} ^{0 ··· 63}^{63}^{63}^{63}^{63}^{63}^{63}^{63}^{63}^{⋮}^{⋮}^{⋮}^{⋮}^{⋮}^{⋮}^{⋮}^{⋮}^{0}^{0}^{0}^{0}^{0}^{0}^{0}^{0} x ⟶ y ; ↓ z ⟶^{0}  ^{1}  ^{2}  ^{3}  ^{4}  ^{5}  ^{6}  ^{7}^{8}  ^{9}  ^{10} ^{11} ^{12} ^{13} ^{14} ^{15}^{56} ^{57} ^{58} ^{59} ^{60} ^{61} ^{62} ^{63}

Figure 3.21: A 64×64×64 array can be updated at 60 frames/sec and displayed in real time on a vga-like crt monitor by showing 64 two-dimensional slices arranged side-by-side on an 8×8 array. The corresponding arrangement of the scan permuter is given in Fig. 3.22.

In order to produce this arrangement on the crt screen,^{9} sites have to be scanned in nested loops as follows (starting with the innermost loop)

loop slice length width site-address slice 64  6  x 8  3  z (lower half) 64  6  y 8  3  z (upper half) .  (3.4)

This scanning order is achieved by permuting the scan index lines so that the low three bits of the site-address z slice are driven by the high three bits of the scan-index h slice, and the high three bits of the z slice by the high three bits of the v slice, as shown in Fig. 3.22.

Figure 3.22: Here some of the scan-index bits appear in the site address in a permuted order. Namely, the coarser portions of the h and v sections control the scanning of the z dimension. The resulting crt display format is shown in Fig. 3.21.

In general, the scan index permuter is programmed by specifying, as a source for each of the 24 site-address bits, any of the 24 scan-index bits or the contants 0 and 1 (cf. §R.15). The transformations thus obtainable include all the combinations with repetition of the 24 scan-index bits—of which the permutations form a subset. In practice, however, permutations are all that we are generally interested in.

The use of constants as sources of site-address bits during a scan is illustrated by the following example. Starting from the situation of Fig. 3.19 and Fig. 3.20, suppose we want to display on the crt screen a magnified view of just a portion of the system. By modifying the scan index permuter arrangement as in Fig. 3.23, each site of the array will be displayed four times, on four consecutive pixels (since the two least significant bits of the scan index are ignored), and similarly each row will be scanned four times, thus giving a linear magnification of 4×.

The values of the constant site-address bits determine which columns and rows are repeatedly scanned. With the values shown in Fig. 3.23 on positions 7–8 and 16–17, the magnified display will show the upper-right portion

9Note that the least significant half of the z address increments at a faster rate than y, while the most significant half increments at a slower rate than y.

Figure 3.23: By ignoring the two least significant bits of the scan index, the same site will reappear on four consecutive pixels, yielding a linear magnification of 4×; similarly, by ignoring two higher bits, the same row of the array will reappear on four consecutive scan lines, yielding a vertical magnification of 4×. The constants on positions 7–8 and 16–17 select which portion of the array will be displayed in this magnified fashion.

(128×128 sites) of the frame of Fig. 3.19. Note that no updating must be taking places during the magnified display.

3.10 Kicking

Kicking is the technique by which the data-transport stage (§3.2) is realized in step. In this section we shall restrict our discussion to a simplified situation involving a single module. The gluing of modules in a multi-module machine is discussed in §3.11.

As mentioned at the end of §3.7 (also cf. Fig. 3.17), the dram address of a state-variable bit (§3.1) is obtained by adding to its site address an offset specified by the Offset Register (§R.18); both site address and offset are ddimensional vectors, with the number d of dimensions and the number of bits devoted to each dimension determined by the Dimension Cut Mask, as explained in §3.4.

The offset specifies where the origin of the bit array (site address ⟨0, 0, …⟩) is located in dram. The operation of modifying this offset, and thus shifting the origin of the array, is called a kick. Kicking, of course, does not by itself physically shift any data; however, it modifies the relative timing with which data bits from different layers are fetched from dram during a scan. Bits that on the previous scan were fetched from dram at the same time— i.e., bits that belonged to the same “bit pile” (cf. §3.2)— will, because of the change of offset, be fetched at different times on the next scan; on the other hand, certain bits that used to belong to different piles will now be part of the same pile: they will be fetched from dram together and will interact with one another by going together go through the lookup table.

Kicking is done by subtracting from the Offset Register (§R.18) a d-dimensional vector specified by the Kick Amount field of the Kick Register (§R.2). Further aspects of kicking can only be appreciated in the context of intermodule gluing, discussed in the next section. In particular, the other fields of the Kick Register are only relevant in that context. For more technical details, see also §R.2.

3.11 Gluing

By modifying the offset, a kick influences the order in which the bits of a layer are fetched from dram. If we restricted our attention to a single, isolated sector, the net effect of a kick would be just a virtual “circular shift” of layer data within the sector. Because of address wraparaound, any data that shift out of, say, the right edge of the sector are shifted back into the left edge of the same sector (note that all this happens along each of the d dimensions separately, and typically with a different value of the kick for each layer).

However, sectors are not isolated. After a bit has been shifted out of one edge and before it is injected into the opposite edge, a process called gluing switches the bit in question from the control of the given module to that of an adjacent one, so that, in the above example, the bit will be injected into the left edge of the sector immediately to the right of the given sector. This happens in a coordinated way on all right/left edges,^{10} effectively gluing homologous layers from all the sectors into a single, machine-wide “conveyor belt.”

With gluing, some data actually move from one physical place to another, i.e., from a certain dram address in one module to the identical dram address in an adjacent module. Let us examine the process in more detail, using, for sake of illustration, the case of a one-dimensional array of length 8; the site address within each sector will consist of three bits and will run from 0 through 7.

We shall assume that the lookup table contains the identity function (i.e., the bit coming out of layer n is returned unaltered to layer n), so that no interaction between layers takes place. In this way, it will be sufficient to analyze the kicking and gluing of just one layer.^{11}

Restricting our consideration to this layer, let us fix our attention on three adjacent sectors, a, b, and c. In Fig. 3.24a, the sites are labeled by the site address (0 through 7); the initial values of the bits contained in the three sectors are denoted by a_{0}, …, a_{7}, b_{0}, …, b_{7}, and

10Using, as we shall see in a moment, the information contained in the Kick Sign and Kick Max Flag fields of the Kick Register (§R.2).

11This data movement in one layer is significant, of course, only relative to the other layers with which it will eventually interact. For simplicity, let us view the movement as taking place relative to an unkicked layer.

Figure 3.24: (a) Initial contents of three adjacent sectors a, b, and c. (b) Actual layout of the data in dram, assuming a value of 5 for the Offset Register; this value is indicated by the position of the dial pointer.

c_{0}, …, c_{7}. We want to shift the layer data by 3 positions to the right, with the results shown in Fig. 3.27a.

Now, let us look “under the hood” to see how this is actually done in step. In the dram that implements sector b, the eight bits b_{0}, …, b_{7} are found stored consecutively, but not necessarily starting from dram address 0. If the current offset is, say, 5, that means that bit b_{0} happens to be in dram address 5, as shown in Fig. 3.24b. Similar considerations apply to sectors a and c.

We shall assume that a complete scan of the site array will always run through site addresses 0–7 in that order.^{12} In the absence of a kick, the next scan will pick up bits b_{0}, …, b_{7} in that order, that is, in the same order as they had been deposited by the previous scan. In order to shift data by 3 positions to the right, we’ll give a kick of +3; this kick will be subtracted from the offset, resulting in an offset of 2 (=5−3). In moving from the value of 5 to the value of 2, the offset pointer will “sweep” over a certain fraction of the dram circle, as indicated in Fig. 3.25.

Figure 3.25: In moving from the value 5 to the value 2, the offset pointer swept over the shaded dram locations 4, 3, and 2.

The next scan will start picking up data bits from where the offset is pointing now, i.e., dram address 2 (Fig. 3.25), and thus will successively get ata bits

b_{5} b_{6} b_{7} b_{0} b_{1} b_{2} b_{3} b_{4}

from sector b (cf. Fig. 3.26a), and similarly for a and c). During the scan, each bit is eventually deposited back to some dram in the same order as it was picked up.

No gluing. In the absence of gluing, the scan would deposit each bit in the same dram, a, b, or c, where it found it, leaving the situation as in Fig. 3.26. Thus, with no gluing all that physically changes is the offset; however the interpretation in terms of site contents is now that of Fig. 3.26a: i.e., the data have been rotated within each sector.

Figure 3.26: Changing the offset without doing any gluing is equivalent to a rotation of data independently within each sector. In this case, a kick of +3 has moved the offset (sector origin in dram) three places counterclockwise, equivalent to moving the data three places clockwise.

Gluing. Let us go back to the situation of Fig. 3.24, and this time apply the same kick of +3 but with gluing. The new scan starts with dram and offset as in Fig. 3.26b, and picks up data bits as before, in parallel for the three sectors a, b, and c, in the order

\begin{matrix}a & b & c \\ a_{5} & b_{5} & c_{5} \\ a_{6} & b_{6} & c_{6} \\ a_{7} & b_{7} & c_{7} \\ a_{0} & b_{0} & c_{0} \\ a_{1} & b_{1} & c_{1} \\ a_{2} & b_{2} & c_{2} \\ a_{3} & b_{3} & c_{3} \\ a_{4} & b_{4} & c_{4} \end{matrix} .

And now the critical step. Before depositing a bit back to dram (in the same dram address where it came from), if the bit came from the shaded area in Fig. 3.25 we will hand it to the sector just to the right, and we will use in its place the homologous bit that is handed to us at the same moment by the sector just to the left, as follows

12If the scan index permuter (§3.9) specifies other than the identity permutation, site addresses may be accessed in a different order, but the overall results would be identical tho those described here.

\begin{aligned}a & b & c \\ & a_{5} & b_{5} & c_{5} \\ & a_{6} & b_{6} & c_{6} \\ & a_{7} & b_{7} & c_{7} \\ a_{0} & b_{0} & c_{0} \\ a_{1} & b_{1} & c_{1} \\ a_{2} & b_{2} & c_{2} \\ a_{3} & b_{3} & c_{3} \\ a_{4} & b_{4} & c_{4} \end{aligned} .

For example, just as module b hands bit b_{5} to module c, it receives bits a_{5} from module a, and that is the bit that gets deposited in dram address 2 in place of bit b_{5}. Thus, while bits b_{0}–b_{4} go back to their original places, bits b_{5}–b_{7} will end up in sector c, where they will take the place of bits c_{5}–c_{7}, while their place will be taken by bits a_{5}–a_{7} from sector a, as shown in Fig. 3.27.

Figure 3.27: (a) Same sector contents as in Fig. 3.24, but shifted three places to the right. (b) This has been achieved by moving the offset pointer three places to the left, sweeping over dram locations 4, 3, 2 (shaded areas). During the subsequent scan, the gluing process moved the contents of these three locations in dram a to the corresponding locations in dram b (and similarly between b and c).

In conclusion, bits coming from the shaded area of Fig. 3.25 move one sector to the right before going back to dram, while bits coming from the clear area remain in their sector; in either case, the dram address of each bit remains unchanged.

Negative kick. Let us consider now a kick of −5 rather than +3. Since the sector is of size 8, arithmetic is done modulo-8. The Kick Amount (cf. §R.2) is the same in both cases, nad the offset pointer will land on the same position as in Fig. 3.25. However, the Kick Sign filed of the Kick Register keeps track of the fact that the pointer swept clockwise over dram locations 5, 6, 7, 0, 1 (Fig. 3.28), rather than counterclockwise over 4, 3, 2.

As long as no gluing takes place, the results are the same as those of Fig. 3.26. However, with gluing turned on, it is the data in the new shaded areas (Fig. 3.28) that hop from sector to sector during the scan; moreover, as

Figure 3.28: The shaded area represents the fraction of dram swept over by the offset pointer for a kick of −5 (cf. Fig. 3.25).

directed by the Kick Sign, they will be handed by each sector to the sector immediately to the left, with the results of Fig. 3.29.

Figure 3.29: The result of a −5 kick with gluing, starting from the situation of Fig. 3.24. The shaded area in (b) is complementary to that of Fig. 3.27; bits in the shaded areas move to the sector immediately to the left of their sector, and the results in terms of sector contents (b) are a wholesale shift of 5 places to the left.

If n is the number of site address bits assigned to a certain dimension by the Dimension Cut Mask (cf. Fig. 3.4), then any kick value from 2^{−n} to 2^{+n} is admissible.

The two end-points of this range are only relevant for an extendible dimension, and when gluing is in force. A kick of 2^{−n} corresponds to copying the entire sector to the one before it along that dimension; similarly a kick of 2^{+n} copies each sector to the one after it. If the dimension is not extendible, or if gluing is turned off, then both these extreme values for the kick coincide with a kick of 0.

The gluing process explained above takes place independently for each of the extendible dimensions.

STEP Architecture Reference

/im/cam8/ref/arch/_stream

Copyright \begin{matrix}c \\ ◯ \end{matrix} 1995 T. Toffoli DRAFT, January 6, 1995

4 Data streams

4.1 Sources and destinations

Central to the step updating and analysis process are five internal inputs within each stepchip which we shall call destinations:

• LUT Address (§R.4). The lut Address bit contributed by the stepchip. Collectively, the sixteen lut Address bits contributed by a stepchip set make up the address used, at every site of a scan, for lookup in the active lut.

• Flywheel Output (§R.5). The bit to be placed on the stepchip’s Flywheel Data Output pin (§4.4)— perhaps to be modified and returned through the Flywheel Data Input pin.

• Site Data (§R.6). The Site Data bit contributed by the stepchip. Collectively, the sixteen Site Data bits contributed by a stepchip set make up the new value to be written in the site being scanned (cf. Fig. 3.1).

• Event Counter (§R.7). The bit to be fed to the stepchip’s Event Counter (see §4.2). Each of the sixteen stepchips of a module has a separate event counter.

• Display Data (§R.8) The data to be displayed on the dedicated monitor, or read back by the host during scan i/o (§R.16).

Each destination independently can be fed, under software control, with data derived from a number of sources. Separate registers (the Site Address Bit Select Register mentioned above and the registers described in the next few sections) determine the data sources that are used for each of these destinations. In all cases, source selection and combination is made in two stages, using a two-bit select register and a four-bit map register, as sketched in Fig. 4.1.

The select register selects one source out of four, namely,

[figure: mux; s; g; f; lut Output; Flywheel Input; CBus Data; Unglued Data; Glued Data; select; map; x Source Register]

Figure 4.1: Source selection and combination network. Each of the five destinations has its own network, driven by the corresponding source register (x stands for one of the possible five destinations). The last input to the multiplexer is lut Output (as shown in the figure) for the three destinations Site Data, Event Counter, and Display. For the other two destinations, i.e., lut Address and Flywheel Output, it is the bit specified by the Site Address Bit Select Register. For g and s, cf. table (4.2).

select source 0  Unglued Data bit (§4.3). 1  CBus Data bit (§R.14, §R.14). 2  Flywheel Input bit (§4.4). 3  When the destination is either the lut address bit or the fly- wheel output bit: one bit of the site address, as specified by the Site Address Bit Select Register. For all other destinations: the lut output. . (4.1)

The selected source is combined with another source, namely, Glued Data, by a two-input, one-output Boolean function f. The map register (Fig. 4.1) specifies which of the sixteen possible Boolean functions is to be used for f according to the following table (where g denotes the Glued Data source and s denotes the source chosen by the select register)

map Boolean function
0 0
1 \overline{g or s}
2 g and \overline{s}
3 \overline{s}
4 \overline{g} and s
5 \overline{g}
6 g ≠ s
7 \overline{g and s}
8 g and s
9 g = s
10 g
11 g or \overline{s}
12 s
13 \overline{g} or s
14 g or s
15 1

(4.2)

4.2 Event Counter

With a maximum space size of 2^{24} sites in a module, the event counter must be able to store the 2^{24}+1 possible values for the count, from 0 to 2^{24}. Thus, we need a 25-bit counter and a 25-bit buffer.

4.3 Unglued and glued data

4.4 Data flywheel

... are taps on the data streams that circulate within each stepchip. For each layer, all the data accessed during a scan are streamed past an output tap and an input tap. Thus, when provided with appropriate synchronization, external hardware can, through these taps, selectively extract any of the data involved in the simulation, and can optionally replace them with arbitrary new data. The sixteen Flywheel Output and the sixteen Flywheel Input lines of each module, together with the control lines that decide whether external injection of data is going to take place, are simply brought out to connectors on the motherboard; they are mainly intended for experimental use of the machine. (It is unlikely that even the most advanced user will connect external equipment to more than one box.)

STEP Architecture Reference

/im/cam8/ref/arch/_io

Copyright \begin{matrix}c \\ ◯ \end{matrix} 1995 T. Toffoli DRAFT, January 6, 1995

5 Real-time input/output

STEP Architecture Reference

/im/cam8/ref/arch/_addr

Copyright \begin{matrix}c \\ ◯ \end{matrix} 1995 T. Toffoli DRAFT, January 6, 1995

6 Module interconnection and addressing

♠ [Write an introduction here.] [This chapter is under construction]

6.1 Module selection

During the data phase of a write frame, it is the step controller that talks into the CBus. Data are physically fanned-out by the CBus to all step 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, the controller acts as a listener, and it is essential that no more than one module be selected to talk into the CBus.

Step’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, may be achieved by other methods (cf. §R.27).

We have seen that a step machine consists of an arbitrary number of modules, and each module consists of sixteen layers each served by a separate stepchip. In most respects, the sixteen chips of a set 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 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.

The decision of whether or not a module is currently selected is based upon a match between an internal name and a 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 selection code, which is broadcast by the host and written to the Module Select Register (§R.0) of all modules.^{1}

There are two primary sources available for the internal-name bit. The module ID, stored in the Module ID Register (MIDR) is used to uniquely identify a module, and is assigned once and for all at initialization time (§6.2); the group ID, stored in the Group ID Register (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 Glue-AND bit, used only at initialization time (§6.2).

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 LUT Index Register (§R.11). This fourth option is used during a special sequential-read mode (§??).

The following table lists what sources the different selection codes specify for the internal bit and the target bit^{2}

selection code bits to be matched (MSR)  internal  target 000  MIDR  0 010  MIDR  1 100  MIDR  LIR 110  Glue-AND 0 001  GIDR  0 011  GIDR  1 101  GIDR  LIR 111  don’t care .  (6.1)

Of course, the individual stepchip 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 anding together the sixteen partial matches. This logical operation is physically performed by a wired-and line that ties together all sixteen chips’ ModSel pins (§??), collecting the arguments of the 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.

it are accepted by every module regardless of the module’s current selection status.

2The 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. §??).

1This register is exceptional in the sense that data addressed to

The above comparison between internal name and target name is made at the end of the data phase of each frame (Fig. ??), and the result (‘selected’ or ‘not selected’) remains valid for the entire duration of the following frame.

6.2 Module ID initialization

As mentioned in §6.1, before a step machine 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 threedimensional torus), and (b) at system reset all modules are set to an identical internal state.

To break this symmetry between modules, it is sufficient to “tag” one module; this is done at power up, as explained in §??. Once the symmetry is broken, every module is in principle uniquely identifiable by its x, y, and z displacements (in the torus coordinates) relative to the tagged one. This fact is exploited by the module ID initialization procedure described below (which the host will run immediately after power up): starting from the tagged module and taking advantage of the glue lines that connect modules in the x, y, and z directions, this procedure successively steps from module to module, selecting and uniquely naming each one in turn.

What distinguishes the tagged module at power up is that it it is accessible on the CBus(only the modules in the corner box—cf. §??—are initially accessible) and has a 1 rather than a 0 as the least-significant bit of its

♠ module ID. [Update the following procedure] By appropriate use of the 000, 010, and 111 selection

codes (table (6.1)), the host will select just this module and give it a name consisting of all 0s (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 FFFF).

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. 6.1a). At power-up, the six glue pins of all modules are programmed as inputs; these inputs are internally anded together into a signal call Glue-AND (Fig. 6.1b). Since the glue inputs are internally pulled up by resistors to logical 1, Glue-AND will have a value of 1.

[figure: XP; XM; YP; YM; XP; ZM; (a); ZP; ZM; YP; YM; XP; XM; Glue-AND; and; (b)]

Figure 6.1: (a) The six glue lines that connect one module to its neighboring modules. (b) The module ID initialization sequence makes use of the and of the six glue lines.

We’ll now turn the XP pin of module 0000, layer 0, into an output^{3} and put a 0 on it. This 0 will travel on a glue line and reach pin XM of an adjacent module, forcing its Glue-AND to 0. Making appropriate use of selection code 110, corresponding to Glue-AND=0 (cf. table (6.1)), we can select just this adjacent module,^{4} and write 0001 as its module ID. At this point we’ll ask module 0000 to turn pin XP of layer 0 back into an input, and module 0001 to put a 0 on one of its glue pins, so as to “touch” another module. We will name the new module 0002, and so on until all modules of the step machine have been given unique IDs.

6.3 Corner box

Because of its unique position—at the origin of the step box array and at the origin of the CBus distribution tree—the step machine’s corner box plays a distinguished role in certain setup and housekeeping functions.

The step modules come out of power-up with all activity on their CBus branch ports disabled (see §R.21); thus, while the controller can communicate with the corner box, all other boxes are cut off from the CBus for the time being. Moreover, module 0 of a box is physically distinguished from the other modules of the same box by having the Multipurpose Pin A of stepchip 0 pulled down by an external resistor, so that its module ID at power up will be FFFE rather than FFFF.[Norm, confirm this] ♠ Taking advantage of the above features, the host runs

3By appropriately setting the sign of the kick register; cf. §??. 4With the present naming procedure, the only two modules having 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 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 FFFF.

an initialization procedure that systematically assigns module IDs, starting with 0000 for module 0 of box 0 (cf. §6.2). 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 CBus, proceeding outwards from the corner box.

6.4 Block wiring

Refer to §?? for the definition of block and strand. In the present realization of the step architecture, a module consists of a board having all of its connectors on one edge, as in Fig. 6.2, and a block consists of a box with a backplane where eight of these boards can be plugged in.

[figure: x_{−}; x_{+}; y_{−}; y_{+}; z_{−}; z_{+}]

Figure 6.2: Step module board, showing the six glue port connectors.

For such a realization of a block, table (3.2) 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. 6.3 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”).

Still using template (3.2), Fig. 6.4 shows the actual placement of the shorting plugs (cf. Fig. 3.14) at the edges of the array (using an array that is two blocks deep in both the x and y dimensions; as in Fig. 6.3, 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).

6.4.1 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

[figure: x_{−}; x_{+}; x_{+}; x_{−}],

Figure 6.3: 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 (3.2)).

Figure 6.4: How strands are connected at the edges of the array to form loops.

and the complete wiring diagram will appear as in Fig. 6.5.

6.4.2 Block wiring, improved

Each of the “wires” shown in Fig. 6.3 or Fig. 6.5 is actually a flat cable consisting of a collection of 16 twisted pairs (one per layer). 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

[figure]

Figure 6.5: Complete backplane wiring for a step system consisting of a single block.

of Fig. 6.6, to be constrasted with that of Fig. 6.5. The improved wiring is arrived at as follows.

Port swapping. Fig. 3.14 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. (3.2)).

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. 6.2) is software assignable rather than hardwired (cf. §R.22). 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

strand  ports
s_{x}s_{y}s_{z} S x  y  z
000 0 −+ −+ −+
100 1 +− −+ −+
010 2 −+ +− −+
110 3 +− +− −+
001 4 −+ −+ +−
101 5 +− −+ +−
011 6 −+ +− +−
111 7 +− +− +−

(6.2)

Strand swapping. Finally, we shall permute the boards in the backplane’s eight slots so that the strand labels S are ordered according to Gray code rather than straight binary code:

strand  ports
s_{x}s_{y}s_{z} S x  y  z
000 0 −+ −+ −+
100 1 +− −+ −+
110 3 +− +− −+
010 2 −+ +− −+
011 6 −+ +− +−
111 7 +− +− +−
101 5 +− −+ +−
001 4 −+ −+ +−

(6.3)

It is easy to verify that the port-and-strand arrangement of template (6.3) indeed leads to the improved backplane wiring pattern given in Fig. 6.6. Similar methods can be used to streamline backplane wiring in more complex situations, such as that of Fig. 6.4.

[figure]

Figure 6.6: Improved backplane wiring for a step system consisting of a single block.

STEP Architecture Reference

/im/cam8/ref/arch/_contr

Copyright \begin{matrix}c \\ ◯ \end{matrix} 1995 T. Toffoli DRAFT, January 6, 1995

7 Command structure and interpretation

Commands to the step machine are given by writing in host memory instructions for the step controller, and appropriately directing to controller to locate and interpret these instructions. Here we describe (a) the format of these instructions; (b) the protocol by which the controller is called to execute them and by which it acknowledges completion—or signals exceptions encountered during execution; and (c) the basic procedure followed by the controller in decoding the instructions and supervising their execution throughout the step machine.

7.1 Step lists

The “program” that the controller executes consists of a sequence of instructions, called step list, residing in the host’s memory.^{1} Typically, the step list and the associated data buffers will have been constructed at leisure by a user program running under unix, without much concern for real-time performance. On the other hand, dependable real-time performance is expected of the controller; to this end, the controller is given bus master access to the SBus when interpreting the step list (cf. §2.3).

The data buffers provide designated areas for transfering data to and from the step array. A typical data buffer would be a lut buffer, i.e., a memory image of a step lookup table (§4).

The step lists and the associated data buffers reside in an area of host memory that is shared beween the host and the controller. Several step lists (with the associated sets of data buffers) may be present in shared memory at the same time, ready to be executed in turn. In the sparcstation, this shared memory is mapped simultaneously into the kernel’s virtual address space (where it is seen by the controller) and into the user’s address space (where it is seen by the user’s program). All shared memory is allocated in multiples of four 32-bit words (16 bytes).

7.1.1 Instruction format

Each step-list instruction consists of exactly four 32-bit words named as follows

opcode buffer pointer register length link to next instruction .  (7.1)

Typically, an instruction makes reference to some associated data. These data can be in an inline buffer, immediately following the instruction, or in a separately allocated buffer. In either case, the buffer pointer field in (7.1) points to the origin of this buffer. Small amounts of data can also be encoded in immediate form, i.e., within the instruction itself; in this case no data buffer is used. Scanning of a step list proceeds sequentially from the beginning to the end of the list—there are no flow-control instructions such as ifs, jumps, or gotos.

7.1.2 Instruction fetching

Writing a memory address to the Next List Pointer tells the controller that a step list is present in memory at the given address and that the controller should start executing it as soon as it is done with the list (if any) which it is currently executing cf. §2.3. The exact sequence of events will depend on the current state of the controller. For the purposes of writes to the NLP, the controller can be in one of three states: execute, wait-for-host, and error-wait-for-host.

In the execute state, the controller is still executing the previous step list. Assuming that no errors are encountered, the controller will start executing the new list as soon as the previous one is finished.

In the wait-for-host state, the controller is idle. As soon as the NLP is written to, the controller immediately starts execution of the given list.

In the error-wait-for-host state, besides writing to the NLP it is necessary to indicate—through the “enabledvma” option—to resume execution; simply writing to the NLP is not sufficient. The reason for this is to prevent execution from continuing when the interface receives an error during the write to the NLP, in which case execution of the new step list should not commence.

1The step list is analogous to the “display list” routinely used for interfacing a conventional processor to a specialized, highperformance graphics processor.

7.2 Step controller

The step controller was introduced in Chapter 2. Its main function is to interpret step lists, which reside in the host’s memory, traslating them into sequences of transactions between data buffers in host memory and stepchip registers in the modules.

The controller contains a number of hardware registers, called control registers, which are use to initialize, direct, and monitor its operation. 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 which are accessed as SBus slaves.

Specifically, the registers comprise one read/write register (the Next List Pointer), three read-only registers, and three write-only registers. Read-only and write-only registers share the same three memory locations. Thus, when read from, the controller’s control registers have the following description

controller’s registers (read) NLP Next List Pointer ISR Interrupt Status Register CIP Current Instruction Pointer PIP Previous Instruction Pointer ,  (7.2)

and when written to they have the following description

controller’s registers (write) NLP Next List Pointer ICR Interrupt Control Register DSL Display Scan Length DBL Display Blank Length .  (7.3)

In the three pointers above (NLP, CIP, and PIP), the low four bits have a special use. Since the addresses to which the pointers refer are always 16-byte aligned, the pointers’ low four bits are predictably 0s and need not be explicitly given. In their stead, those four bit positions are used as read-only windows on certain status bits (writes to the same bit positions are ignored.)

7.2.1 Next List Pointer

The Next List Pointer is a read/write register. Bits 4–31 (next list) represent the starting address (without the low four bits, which are understood to be 0s) of the step list to be executed next. Bits 0–3 are read-only status bits with the following meaning

Next List Pointer status bits bit  name  function 0 nlp written       the controller is still ex- ecuting the previous dis- play list, and has not yet made use of the NLP. 1 exception status  the controller has seen an exception (timeout or step interrupt). 2 wait for host      the controller is in “wait- for-host” mode. 3 interface halted  the controller is currently halted. .

(7.4)

[As soon as the controller is free (it might have been ♠ executing another step list), it looks at the NLP and starts executing the step list pointed to by it. At the same time, it signals to the host (by means of an nlp int interrupt) that the current step-list pointer value has been read from the NLP register, and a new value can be written in it.]

[revise this paragraph] Bit 3 is a status bit which is ♠ set if CAM is currently scanning. Bit 2 is set if the interface is in the “DMA Active” mode, meaning that it is performing, or ready to perform the execution of step list. Bit 1 is set if the interface is in “wait-for-host” mode, and bit 0 is set if the current NLP has not yet been processed by the interface (meaning that the interface is still working on the previous display list.)

7.2.2 Interrupt Status/Control Registers

The Interrupt Status Register (Fig. 7.1) and the Interrupt Control Register (Fig. 7.2) are used to monitor, enable, or disable interrupts generated by the controller. The latter register is is also used to reset, halt, and restart the controller, and to reset the step array.

The controller can place on the SBus five kinds of interrupts, namely,

controller interrupts name  description soft int     Software interrupt. cam int      step-originated interrupt. sbus int     The controller detected an SBus error. timeout int  Timeout in communicating with the step array. nlp int      Next List Pointer interrupt: the controller has started executing the step list indicated by the Next List Pointer; a new step list can be scheduled by writing a new ad- dress to the Next List Pointer. .

(7.5)

To each of these interrupts the controller associates an interrupt enable bit and an interrupt flag bit, whose functions will be explained in a moment. The five enable bits and the five flag bits are directly readable respectively in positions 0–4 and 8–12 of the Interrupt Status Register.

The five flag bits cannot be directly written by the host. Each of these bits is set by the occurrence of the corresponding interrupt condition (e.g., timeout interrupt); they are collectively cleared by any read operation performed on the Interrupt Status Register.

Whether a flagged interrupt actually generates an interrupt on the SBus depends on whether that particular interrrupt is enabled. The five enable bits of the Interrupt Status Register are not writable in a conventional way. They are set by writing a 1 to respectively bits 8, 9, 10, 11, and 12 of the Interrupt Control Register, and cleared by writing a 1 to, respectively, bits 0, 1, 2, 3, and 4 of the same register.

The occurence of a cam int or a timeout int suspends the list scanning activity of the controller, regardless of whether these interrupts are enabled (and thus reported to the host as SBus interrupts). However, these interrupts can be masked at an earlier stage, so that they will not be seen at all by the controller. This is done by two more enable bits, namely cam exception and timeout exception, which can be set or cleared in a way similar to the other enable bits, by writing a 1 to, respectively, bits 5 and 6 or bits 13 and 14 of the Interrupt Control Register.

Finally, as shown in Fig. 7.2, four more control functions are performed by writing a 1 to bits 12, 13, 16, and 31 of the Interrupt Control Register.^{2} Interrupt Status Register

bit  name
0 soft int flag
1 cam int flag
2 sbus int flag
3 timeout int flag
4 nlp int flag
5–7 —
8 soft int enable
9 cam int enable
10 sbus int enable
11 timeout int enable
12 nlp int enable
13–31 —

Figure 7.1: Structure of the Interrupt Status Register. Bits 0–4 (interrupt flags) are set by the occurrence of the appropriate interrupt conditions, and are automatically cleared by any read of this register. Bits 8–11 are set by writing 1s to bits 8–11 of the Interrupt Control Register, and cleared by writing 1s to bits 0–5 of the same register.

Interrupt Control Register

bit  effect of writing a 1
0 soft int disable
1 cam int disable
2 sbus int disable

                                                             3 timeout int disable

4 nlp int disable

                                                             5 cam exception disable
                                                             6 timeout exception disable

7 —

                                                             8 soft int enable

9 cam int enable
10 sbus int enable

                                                             11 timeout int enable

12 nlp int enable

also: Clear fault

                                                             13 cam exception enable

also: Clear exception

                                                             14 timeout exception enable

16 Halt the controller.
17–30 —
31 Reset the controller.

Figure 7.2: Structure of the Interrupt Control Register.

7.2.3 Current Instruction Pointer

The Current Instruction Pointer is a read-only register (writes to this location affect the Display Scan Length; §7.2.5). Bits 4–31 (curr inst) represent the address (without the low four bits, which are understood to be 0s) of the step-list instruction currently being executed. Bits 0–3 are read-only status bits (cf. §7.2) with the following meaning

2Bits 12 and 13 also happen to affect exception control (see “also” entries in Fig. 7.2); this is an oversight—fortunately a harmless one—and will be fixed with the next release of the controller chip set.

Current Instruction Pointer status bits bit  name  function 0 sbus error     The controller is sus- pended because of SBus error. 1 partial write  Owing to an SBus er- ror, only a partial write was performed by the controller. 2 done status    controller is not relaying to step. 3 —  Reserved. .

(7.6)

♠ [Edit bit 2.]

7.2.4 Previous Instruction Pointer

The Previous Instruction Pointer is a read-only register (writes to this location affect the Display Blank Length; §7.2.5). Bits 4–31 (prev inst) represent the address (without the low four bits, which are understood to be 0s) of the step-list instruction executed before the current one. Bits 0–3 are read-only status bits (cf. §7.2) with the following meaning

Previous Instruction Pointer status bits bit  name  function 0 cam int active  This bit reflects the sta- tus of the Interrupt signal of the CBus, resynchro- nized to the SBus clock. It allows the host to di- rectly see whether there is an interrupt on the CBus. 1 cam scanning    step is scanning 2  (Reserved  for sparcstation-2 bit.) 3  (Reserved.) .

♠ (7.7)

Bit 2 (?) of the previous instruction register indicates if the long-burst transfer mode supported on the sparcstation-2 is being used by the interface board.

7.2.5 Display Scan/Blank Length

7.2.6 Remarks

♠ [understand and drop in place the following remarks.] wait-for-host is fixed by writing to the NLP all error interrupts except new-list (NLP) and soft

cause dvma-inactive and wait-for-host mode.

cam-error: parity and verify-write errors are not signalled until end of transfer, this interrupt will always be in the “next” instruction.

current-instruction: generally this is the current instruction if “stop” is received. This instruction should have been attempted, the previous instruction has generally been completed.

Check the state that interface and cam are in when a hardware interrupt is received. do not assume that interface is in some “clean” state.

STEP Architecture Reference

/im/cam8/ref/arch/_regs

Copyright \begin{matrix}c \\ ◯ \end{matrix} 1995 T. Toffoli DRAFT, January 6, 1995

R STEPchip registers

This chapter systematically presents (see §2.4.2 for an overview) the registers that make up the stepchip register address space. This address space is directly accessible by the CBus. Other on-chip data structures are accessed only in an indirect way (for instance, the Event Counter is read by the user via a register called the Event Count Register), or are of no immediate relevance to the step user.

Each register is presented in a separate section; the section number itself (e.g., the ‘23’ in §R.23) coincides with the register’s address (§2.4.2). The makeup of each register is summarized in tabular form immediately below the section title. The register’s length in bits is given, followed by the register’s mnemonic and its full name. Often, a register is actually a collection of logically separate components; in such cases the components themselves are individually listed, starting from the one at the least-significant-digit end of the register. For example, the 30 bits of the Kick Register (§R.2) comprise a 24-bit Kick Amount (whose least significant bit is the least significant bit of the entire Kick Register), three one-bit Kick Signs, and three one-bit Kick Max Flags. This listing order corresponds to the order in which bits are transmitted to or received from a register, i.e., least-significant bit first.

All registers are both readable and writable, although most would only be read for error recovery or test purposes. At power-on reset, all registers except the Module ID Register are cleared to zero (see §R.23); a host-initiated soft reset is similar, but leaves the dram contents and several registers (OSR, IR and DOCR) unchanged.

As mentioned in §2.4.2, the two I/O registers, namely the Scan I/O Register and the LUT I/O Register, follow their own conventions concerning length of transfers. Moreover, the Event Count Register, whose full length is 25 bits, may be read or written for only part of its length, as specified by the Event Counter Length component of the Scan Format Register.

For reference, a summary description of step registers is given immediately below; detailed descriptions follow.

0 3 MSR

Module Select Register

1 6 RMR

Run Mode Register

2 SSM

Scan Sync Mode

1 RT Run Type

1 ECT

Event Count Transfer

1 RPK

Repeat Previous Kick

1 ALT

Active LUT Toggle

2 30 KR

Kick Register

24 KA  Kick Amount
1 XKS  X-Kick Sign
1 YKS  Y-Kick Sign
1 ZKS  Z-Kick Sign

1 XKMF

X-Kick Max Flag

1 YKMF

Y-Kick Max Flag

1 ZKMF Z-Kick Max Flag 12

3

5

SABSR

Site Address Bit Select Register 4

6

LASR

LUT Address Source Register 2

LAS

LUT Address Select 4

LAM

LUT Address Map 5

6

FOSR

Flywheel Output Source Register 2

FOS

Flywheel Output Select 4

FOM

Flywheel Output Map 6

6

SDSR

Site Data Source Register 2

SDS

Site Data Select 4

SDM

Site Data Map 7

6

ECSR

Event Counter Source Register 2

ECS

Event Counter Select 4

ECM

Event Counter Map 8

6

DSR

Display Source Register 2

DDS

Display Data Select 4

DDM

Display Data Map 9

1

SSR

Show Scan Register 10

---

ECR

Event Count Register 11

16

LIR

LUT Index Register

5 LIPR

LUT Index Permutation Register

13 --- LIOR

LUT I/O Register

14 24 SIR

Scan Index Register

15 120 SIPR

Scan Index Permutation Register

5 SSA0

Select Site Address 0

5 SSA1

Select Site Address 1

. . .

5 SSA23

Select Site Address 23

16 --- SIOR

Scan I/O Register

17 35 SFR

Scan Format Register

2 SM  Scan Mode
5 ESC  End-of-Scan

4 ESW

End-of-Sweep

4 EST

End-of-Stretch

5 SBRC

Sweeps Between Refresh Cycles

8 RCL

Refresh Cycle Length

5 ECL

Event Counter Length

2 STM

Stretch Magnification

18 24 OSR

Offset Register

19 38 DR

Dimension Register

23 DCM

Dimension Cut Mask

5 XDCP

X-Dimension Cut Pointer

5 YDCP

Y-Dimension Cut Pointer

5 ZDCP

Z-Dimension Cut Pointer

20 16 HER

Hardware Environment Register

1 LPL

LUT Pipeline Length

1 FPL

Flywheel Pipeline Length

1 DCS

DRAM Column Size

6 TBD

Tree Balancing Delay

4 TMS

Test Mode Select

1 NBF

Node Bypass Flag

1 SRE

Select Read Enable

1 ALS

Active LUT Select

21 10 MPCR

Multipurpose Pin Control Register

5 MAFS

Multipurpose A Function Select

5 MBFS Multipurpose B Function Select

18 GPCR

Glue Pin Connectivity Register

3 XMPC

XM-Pin Connect

3 XPPC

XP-Pin Connect

3 YMPC

YM-Pin Connect

3 YPPC

YP-Pin Connect

3 ZMPC

ZM-Pin Connect

3 ZPPC

ZP-Pin Connect

23 1 MIDR

Module ID Register

24 1 GIDR

Group ID Register

25 10 IER

Interrupt Enable Register

1 BPIE

Bus Parity Interrupt Enable

1 BCIE

Bus Contention Interrupt Enable

1 GCIE

Glue Contention Interrupt Enable

1 MAIE

Multi-A Contention Interrupt Enable

1 MBIE

Multi-B Contention Interrupt Enable

1 SSIE

Skewed Scan Interrupt Enable

1 XHIE

External Hardware Interrupt Enable

1 RLIE

Register Length Interrupt Enable

1 URIE

Unknown Register Interrupt Enable

1 ISIE

Invalid SYNC Interrupt Enable

26 10 IFR

Interrupt Flags Register

1 BPIF

Bus Parity Interrupt Flag

1 BCIF

Bus Contention Interrupt Flag

1 GCIF

Glue Contention Interrupt Flag

1 MAIF

Multi-A Contention Interrupt Flag

1 MBIF

Multi-B Contention Interrupt Flag

1 SSIF

Skewed Scan Interrupt Flag

1 XHIF

External Hardware Interrupt Flag

1 RLIF

Register Length Interrupt Flag

1 URIF

Unknown Register Interrupt Flag

1 ISIF

Invalid SYNC Interrupt Flag

27 3 VWR

Verify Write Register

1 VWE

Verify Write Enable

1 VWIE

Verify Write Interrupt Enable

1 VWIF

Verify Write Interrupt Flag

28 16 DOCR

DRAM Ones Count Register

8 LDOC

Low DRAM Ones Count

8 HDOC High DRAM Ones Count

R.0 Module Select Register

3 MSR

Module Select Register

In order for a step module to be enabled to accept the data broadcast by the host on the CBus during a write frame or put its own data on the CBus during a read frame, the module must be selected, as explained in §6.1. The parameters upon which this selection depends are specified by a three-bit selection code written to the Module Select Register. Selection codes (see table (R.1)) specify which internal register should match which target value. For the selection to be successful. all stepchips in the module must simultaneously indicate a match between their selected registed and their target.

selection code bits to be matched
(MSR)  internal  target
000  MIDR  0
010  MIDR  1
100  MIDR  LIR
110  Glue-AND 0
001  GIDR  0
011  GIDR  1
101  GIDR  LIR
111  don’t care

(R.1)

Owing to its special role in the selection mechanism, the Module Select Register “escapes selection,” in the sense that data written to it by the CBus are accepted by every module regardless of the module’s current selection status. The selection status of a module (i.e., selected or not) is latched when this register is written, and remains in force until this register is written again.

The Module Select Register also escapes normal selection on reads: read operations require a single module to be selected, and so the normal selection mechanism wouldn’t allow us to read back the current selection status of step if more than one module happened to be currently selected! Since the Module Select Registers of all modules are always written simultaneously, it doesn’t matter which module responds to a read of the MSR, as long as only one does: a bit in the Hardware Environment Register (§R.20) is used to single out one particular module for this “honor.”

R.1 Run Mode Register

6 RMR

Run Mode Register

2 SSM

Scan Sync Mode

1 RT Run Type

1 ECT

Event Count Transfer

1 RPK

Repeat Previous Kick

1 ALT Active LUT Toggle Writing a nonzero value to the Scan Sync Mode schedules a scan (cf. §3.7), i.e., instructs the stepchip to start a new scan as soon as possible; the specific value written in the register determines to what extent the scan itself and the individual sweeps that make it up must be synchronized— as detailed in table (R.2)—with the VCAM and HCAM pulses that travel on the CBus Sync line (§??). At the end of the scan, this register is automatically cleared.

SSM  Scan Sync Mode

0 Standby. No scan scheduled.

1 Frame sync. The starting of individual sweeps of the scan will wait for a horizontal sync pulse, HCAM; the first sweep of the scan (and thus the entire scan) will wait for a vertical sync pulse, VCAM (which also acts as an HCAM pulse).

2 Line sync. Individual sweeps of the scan will wait for HCAM. VCAM is treated as equivalent to HCAM. 3 Free run. The scan will start im-

mediately, and sweeps will follow one another without any gaps.

(R.2)

The HCAM and VCAM pulses appear on the same CBus Sync line on which the HMON and VMON pulses appear, and are in a definite phase relationship with them. The latter are sent to the crt monitor to which video data are fed (§R.8). Thus, in a scan of sync mode 1 a sector may be scanned in lockstep with the scanning of the crt monitor. A sync mode 2 scan typically consists of a single sweep; this is used when one intends to change some of the registers (e.g., the Kick Register) from one sweep to the next. A sync mode 3 scan, in which the timing of the scanning is not constrained by real-time display considerations, yields, of course, the fastest scanning rate.

In all cases, the actual start of each sweep is shifted in time by the amount specified by the Tree Balancing Delay (§R.20), to insure that modules placed at different distances from the CBus root will all scan in lockstep (cf. §??).

The Scan-in-Progress signal is defined as the logical or of the two bits of the Run Mode Register, and has a value of 1 from the moment a scan is scheduled to the moment the scan itself ends. This signal is made available to the step interface via the Status line (cf. §??, §R.17), to allow the interface to determine when a scan is finished, and thus when operations that must wait for end-of-scan (such as the scheduling of a new scan) can proceed.

Although the Run Mode Register isn’t double buffered, the delay between the end of one scan and the beginning of the next need not be longer than a few cycles. In fact, the data to be sent to this register to schedule a new scan can be loaded into the step interface during the current scan, ready to be broadcast to the step modules as soon as the Scan-in-Progress signal is no longer asserted (cf. §??). (As explained in §R.10, the event counts for the current scan are double-buffered and can be read at leisure after the new scan has started.)

Several other actions associated with scheduling a scan are controlled by the Run Mode Register, and occur (if indicated) when this register is written.

The Run Type is used to label a scan with some extra “type” information (one bit per stepchip). This information is made visible to external hardware during the scan via multipurpose pins (see §R.21, Run Type). The Run Type is then reset to zero at the end of the scan. If, for example, a Frame Buffer is attached to the CAM display, and a multipurpose pin is configured appropriately, we could signal which scans should be captured for display by appropriately setting a Run Type bit whenever we write the Run Mode Register.

The Event Count Transfer bit controls whether to copy the value accumulated in the Event Counter (over perhaps several scans) into the Event Count Register. Whenever a transfer occurs, the Event Counter itself is automatically cleared. Thus, as we start a new scan, the count from the previous scan can be made available to be read back by the host during the new scan (§R.10).

The Repeat Previous Kick bit is an optimization. Normally, the Offset Register is decremented by the Kick Amount whenever the Kick Register is written. If the kick for the next scan is the same as that just used, we can avoid rewriting the Kick Register by simply reusing its current value, and again decrementing the offset. Note that if we want a kick of zero, we must explicitly change the kick to zero (by writing the Kick Register); it is not enough to simply fail to set the Repeat Previous Kick bit.

Special care must be taken when the scanning of a sector is broken up into several subscans. Kicks sent (or repeated) on each subscan would accumulate, which usually is not what we want. On the other hand, sending a kick of zero for all subscans except the first would produce the right results as far as the offset is concerned, but would deprive the gluing machinery of the relevant information. The correct approach when gluing is involved is, before each subscan after the first, to “undo” the previous kick (by sending its complement) and then send the desired kick afresh.

The Active LUT Toggle switches the roles of active and inactive lut between lut 0 and lut 1. The active lut is the one that will be used as the main processing element in the data stream (cf. Fig. ??). The other, or inactive, lut is accessible to the CBus via the LUT I/O Register (cf. §R.11); specifically, it can be loaded with new contents even while a scan is in progress (cf. §??).

One can find out which of the two luts is the active one by reading the Active LUT Select bit in the Hardware Environment Register (§R.20). By writing that bit, one can force a specific lut (rather than just “the other one”) to be the active one.

R.2 Kick Register

30 KR

Kick Register

24 KA  Kick Amount
1 XKS  X-Kick Sign
1 YKS  Y-Kick Sign
1 ZKS  Z-Kick Sign

1 XKMF

X-Kick Max Flag

1 YKMF

Y-Kick Max Flag

1 ZKMF

Z-Kick Max Flag

The basic philosophy of “kicking” is explained in §3.10.

The bits of the Kick Amount constitute a d-component vector, k⃗, representing a displacement in a d-dimensional space. The structure of this vector (number d of components and number of bits devoted to each component) is determined by the Dimension Register, as explained in §3.4. As soon as it is sent, this vector is subtracted from the Offset Register (§R.18)—another vector with the same structure which keeps track of the current position of the origin of coordinates of step space.

Subtraction of the Kick Amount from the Offset Register, and, in general, all site-address arithmetic is performed independently on the separate site-address slices determined by Dimension Cut Mask in the Dimension Register. Each slice of the Kick Amount specifies the size of the kick for the corresponding dimension. For the three extendible dimensions x, y, and z the Kick Amount is further qualified by a Kick Sign and a Kick Max Flag; the information contained in all three registers is used during a scan by the glue machinery.

If n is the number of site address bits assigned to a certain dimension by the Dimension Cut Mask (cf. Fig. 3.4), then the Kick Amount for that dimension ranges from 0 thru 2^{n} − 1 (2^{n} distinct choices).

For each of the three extendible dimensions, the corresponding Kick Amount component is extended by a Kick Sign bit and a Kick Max Flag bit. With the help of these two bits, the range of the kick is extended to the interval [2^{−n},2^{+n}] (overall, 2^{n+1} + 1 distinct choices). Jointly, Kick Amount and Kick Sign express the value of the kick in two’s complement notation, from 2^{−n} through 2^{+n} − 1 (i.e., 2^{n+1} choices). The last value of the interval, namely 2^{+n}, is distinguished from the value of 0 by writing a 1 in the Kick Max Flag.

In the following discussion, we’ll use, for definiteness, n = 8. Then the Kick Amount component ranges from 00 to FF (in hex). A kick of 01 will circularly shift (within the sector boundaries) the layer’s data by one position in the positive direction; a kick of FF will shift the data by 255 positions in the positive direction, or, which is equivalent, by one position in the negative direction.

For each of the three extendible dimensions, the shift specified by the Kick Amount affects the layer as a whole (rather than each sector being independently circularly shifted), and the Kick Sign is used as the most significant bit in the two’s complement notation. One obtains in this way a kick range from −256 to +255; the value +256 is also possible using only data from nearest neighboring modules, and is indicated by setting the corresponding Kick Max Flag. The entire range of cases, for an 8-bit slice, is summarized by the following table (using the x dimension for definiteness)

XKMF XKS  KA
Max flag sign amount Actual shift
1  0  00  +256
0  0  FF  +255
0  0  FE  +254
⋮  ⋮  ⋮  ⋮
0  0  02  +2
0  0  01  +1
0  0  00  0
0  1  FF  −1
0  1  FE  −2
⋮  ⋮  ⋮  ⋮
0  1  02  −254
0  1  01  −255
0  1  00  −256

(R.3)

Note that if the Kick Sign and Kick Max Flags are both fixed at zero, and the Dimension Cut Pointers (§R.19) are set appropriately (a value of 31), then x, y, and z can be used as internal dimensions: they will be internally wrapped around and no use will be made of glue.

R.3 Site Address Bit Select Register

5 SABSR

Site Address Bit Select Register

This register selects one of the Site Address’s 24 bits as part of the data to be sent to a given destination, when source 3 is selected (cf. §4.1). Specifically, routing siteaddress information to the lookup table is one way to make the dynamics space-dependent.

R.4 LUT Address Source Register

6 LASR

LUT Address Source Register

2 LAS

LUT Address Select

4 LAM

LUT Address Map

LUT Address Select and LUT Address Map are used to construct the source for the LUT Address destination signal (cf. §4.1).

R.5 Flywheel Output Source Register

6 FOSR

Flywheel Output Source Register

2 FOS

Flywheel Output Select

4 FOM

Flywheel Output Map

Flywheel Output Select and Flywheel Output Map are used to construct the source for the Flywheel Output destination signal (cf. §4.1).

R.6 Site Data Source Register

6 SDSR

Site Data Source Register

2 SDS

Site Data Select

4 SDM

Site Data Map

Site Data Select and Site Data Map are used to construct the source for the Site Data destination signal (cf. §4.1).

R.7 Event Counter Source Register

6 ECSR

Event Counter Source Register

2 ECS

Event Counter Select

4 ECM

Event Counter Map

Event Counter Select and Event Counter Map are used to construct the source for the Event Counter destination signal (cf. §4.1).

R.8 Display Source Register

6 DSR

Display Source Register

2 DDS

Display Data Select

4 DDM

Display Data Map

The Display Source Register controls the relationship of the step unit to a dedicated video display, and also controls which data is read back during a scan i/o operation (cf. §R.16).

The Display Data Select and the Display Data Map are used to construct the source for the Display Data destination signal (cf. §4.1).

Note: Display Data signals output a value of zero during any clock when there is no valid display bit available.

R.9 Show Scan Register

1 SSR

Show Scan Register

The step interface must wait for an end-of-scan condition before it proceeds to read or write a register involved in the scan. Since it is possible that not all modules are performing identical scans (e.g., one distinguished module may be acting as a frame buffer), we explicitly choose which module is to provide feedback on the state of the scan. Note that, on the selected module, this information is normally combined with the Interrupt signal coming from outer modules to produce the Status signal.

More specifically, when Show Scan is set, the Scanin-Progress signal generated by the stepchip (§R.1) is multiplexed onto the CBus Status line, which also carries the CBus Interrupt* signal: the Scan-in-Progress signal is chopped (anded with a signal that toggles at the clock rate), inverted, and anded with CBus Interrupt*.

R.10 Event Count Register

--- ECR

Event Count Register

The Event Count Register is used as a buffer for the stepchip’s event counter (§4.2), to permit reading the count from the previous scan even as a new count is accumulating during the current scan. It has the same physical length of 25 bits as the event counter, and is loaded with the contents of the latter at the moment that the Run Mode Register’s Event Count Transfer bit is set (§R.1).

The event count is the most likely quantity that will be read from all modules at possibly frequent intervals during a simulation. Two provisions are made to optimize this readback.

With short scans, new event counts will be available with great frequency;^{1} on the other hand, in this situation the maximum possible value recorded by the event counter will be small, so that the effectively used length of this counter may reduce to just a few bits. The Event Counter Length (§R.17) specifies this effective length, instructing the stepchip to transmit only that many bits during the read-out of the Event Count Register. Note that registers are read by circularly shifting their contents past an output tap; when less than 25 bits are read from this register, the data will be left in the register with a different alignment than before the read operation. If a reread of the same data is desired, one must be aware of the new alignment.

By making use of the sequential-read mode (§??), it is possible to read all event counters in a single CBus frame, with automatic switchover of bus control from one module to the next. This allows all event counters to be read without repeatedly changing bus direction to explicitly select each module in turn.

Although the Event Count Register is normally only read, like all other registers it can also be written. To facilitate testing, when this register is written, the same value is also written into the event-counter itself. Reading this register or performing a verify write on it leaves the counter unaffected.

R.11 LUT Index Register

16 LIR

LUT Index Register

The LUT Index Register indicates which entry of the inactive lut (§R.1) is to be accessed. The pointer autoincrements each time an entry is read or written, thus pointing to the next entry to be accessed. A data transfer to this register is presumed to be finished when the pointer increments to zero.

The same register does double duty in a different context. When event counters are read back in sequentialread mode (§R.10, §??), the LUT Index Register provides the target name specifying which module is to be selected in turn. The pointer autoincrements each time Event Count Length number of bits have been read, thus pointing to the next module to be selected.

In principle, each stepchip is responsible for only one bit of the pointer. For both hardware convenience and increased flexibility, the entire counter is repeated within each stepchip, and each chip of a set is instructed by its LUT Index Permutation Register (§R.12) to use a different bit of this counter.

R.12 LUT Index Permutation Register

5 LIPR

LUT Index Permutation Register

As mentioned in §R.11, each stepchip has its own copy of the entire LUT Index Register but uses only one bit of it. The LUT Index Permutation Register specifies which of the LUT Index Register’s 16 bits is to be used by a given stepchip during table downloading.

Normally, stepchip 0 will use the bit in position 0, stepchip 1 that in position 1, etc., to compose the load address. However, it is possible to specify a different correspondence between stepchip numbers and bit positions. This feature can be used to download a given table with the roles of its inputs permuted. One can also bypass the LUT Index Register and send instead a constant of 0 or 1. This feature is used to download a specified portion of the lut.

1In fact, short scans are usually set up in order to measure totals or averages separately over small patches of space rather than over an entire sector.

The available choices are summarized in the following table

LIPR  lut address bit source
0  bit 0 of LUT Index Register
1  bit 1 of LUT Index Register
2  bit 2 of LUT Index Register
⋮  ⋮
15  bit 15 of LUT Index Register
16–29 not used
30  0
31  1

(R.4)

R.13 LUT I/O Register

--- LIOR

LUT I/O Register

As mentioned in §2.4.2, the LUT I/O Register is used for writing data to the inactive lut (§R.1) or reading data from it, and does not have an intrinsic length.

The data transfer starts from the location initially specified by the LUT Index Register (§R.11), which will have been set up previously, and continues upwards (this pointer is autoincrementing). The transfer ends when the LUT Index Register reaches its terminal count; whereupon, on a read frame the stepchip quits sending bits, while on a write frame it signals an error by setting the Register Length Interrupt Flag (cf. §R.26) if additional bits are received. After an error-free transfer the LUT Index Register contains a value of zero.

If the Verify Write Flag (§R.27) is set, any portion of the inactive lut may of course be checked instead of written. Note that, unlike all other registers, it is not possible to use the verify write mode to perform writeper-bit (see §R.27) to the LUT I/O Register.

R.14 Scan Index Register

24 SIR

Scan Index Register

The Scan Index Register is an autoincrementing pointer which specifies the sequential place, within a scan, of the currently accessed site. At the beginning of an experiment this pointer will normally be initialized by writing a value of 0 to it. Since the length of a scan is always a power of two (see End-of-Scan Pointer, §R.17)—say, 2^{n}—the n low-order bits of the SIR will return to zero at the end of each scan. Thus, this register does not ordinarily need to be cleared between scans.

Since the SIR ultimately points to a dram bit (cf. Fig. 3.17), its clocking rate is geared to the accessibility of that bit as a source and/or a destination; on data transfers between the host and step, it is further constrained by the accessibility of the corresponding host bit. In the fastest scanning modes (modes 2 and 3 in §R.17), the SIR peak clock rate equals the system clock rate; in modes 0 and 1, it drops to one quarter that rate (since only one bit per dram nybble is effectively usable). During host i/o via the Scan I/O Register, operation of the scan circuitry (including the Scan Index Register) is enabled by the CBus handshake signals (cf. §??).

R.15 Scan Index Permutation Register

120 SIPR

Scan Index Permutation Register

5 SSA0

Select Site Address 0

5 SSA1

Select Site Address 1 . . .

5 SSA23

Select Site Address 23

As explained in §3.9, the order in which sites are accessed during a scan is derived from the Scan Index Register, which is incremented by one for each scanned site. When the 24 scan index bits are directly used in their natural order as site address bits, then the entire module is scanned as if by series of nested loops in which the first dimension corresponds to the innermost loops and the last to the outermost loop (cf. §3.4, §R.19).

However, this order can be significantly altered by permuting the scan index bits before using them as site address bits. The source of each of the 24 site address bits is specified by the value of a five-bit Select Site Address n pointer^{2} according to the following table

SSA  site-address bit source 0  bit 0 of the Scan Index Register 1  bit 1 of the Scan Index Register 2  bit 2 of the Scan Index Register ⋮  ⋮ 23  bit 23 of the Scan Index Register 24–29 not used 30  0 31  1 . (R.5)

Note that the constant values 0 and 1 are among the possible sources. This is important for scanning less than the whole space: in this case the unused address bits are set to a constant that specifies which part of the space is being scanned (cf. §3.7).

R.16 Scan I/O Register

--- SIOR

Scan I/O Register

As mentioned in §2.4.2, the Scan I/O Register is used for accessing all or part of the dram chip connected to a given stepchip, and does not have an intrinsic length. By setting up a scan of a certain size and shape (see §R.17), data may be read from or written to the scanned area through the Scan I/O Register.

Addressing the Scan I/O Register starts a scan^{3} that is clocked by data transfer across the CBus (cf. §R.14). By appropriately setting the Source Registers (§R.4–§R.7), host-generated data may be integrated into this CBusdriven scan. This not only allows host data to be combined with current dram data, but, depending on the options selected, it also allows the host to do read/write operations that are not associated with scanned sites. For example, the host can write to the event counter (for testing), or put data on the video bus so as to download a new color palette to the crt interface (cf. §??). In a similar way, a CBus read transaction with the Scan I/O Register makes a module scan (and possibly update) its data with a timing that takes into account the SBus’s moment-by-moment availability to accept data. All Scan I/O read operations get their data from what is fed to the Display Data destination (cf. §R.8).

If the Verify Write Flag (§R.27) is set, any portion of the dram may of course be checked instead of written.

R.17 Scan Format Register

35 SFR

Scan Format Register

2 SM  Scan Mode
5 ESC  End-of-Scan

4 ESW

End-of-Sweep

4 EST

End-of-Stretch

5 SBRC

Sweeps Between Refresh Cycles

8 RCL

Refresh Cycle Length

5 ECL

Event Counter Length

2 STM

Stretch Magnification

The Scan Format Register is used, in conjunction with the Scan Index Permutation Register, to set the scan format.

The Scan Mode selects one of the four basic scan modes: mode 0 (open sweep, no row break), mode 1 (closed sweep, no row break), mode 2 (open sweep, 1 row break allowed), mode 3 (closed sweep, 1 row break allowed). These modes are explained in detail in §??–??. The software should select the fastest of these four modes of scan that is compatible with the selected permutation (allowing a row break adds overhead to the scan, even if no row break actually occurs). All chips operating in the same mode with the same format parameters are guaranteed to have the same scan timing.

The End-of-Scan holds the log (to base two) of the length of the scan: the number of updates that each module will perform without waiting for further instructions from the host (cf. §??). The hardware derives its endof-scan signal by using this value as a pointer to a carry position in the Scan Index Register.

Similarly, End-of-Sweep determines the length of accesses that the hardware should assume lie within a single dram row, and End-of-Stretch determines the number of bits that the hardware can assume will be accessed from consecutive locations. As with End-of-Scan, the actual End signal is derived by interpreting these values as pointers to carry positions within the Scan Index Register.

Sweeps Between Refresh Cycles is the number of sweeps to perform between each refresh cycle; the Refresh Cycle Length indicates the number of refreshes to perform during each refresh cycle (refreshes are continuously performed when scanning isn’t taking place).

The Event Counter Length specifies the effective length of the event counter, which may be less than 25 bits (see §R.10). This length will depend on the number of sites to be counted between readings, and typically is set whenever the scan size is changed.

The Stretch Magnification is used when the Scan Index Permutation Register is configured to achieve a readback or display with magnification (i.e., zoom). Up to a factor of 4, this value is the log of the magnification – above 4 it should have a value of 3. The Stretch Magnification applies only to the component of the magnification that affects the stretch, and is needed by the DRAM address control circuitry to set up the nibble access pattern.

2These registers actually allow one to have all possible combinations with repetition, of which permutations form a subset. In practice, however, permutations are all that we are generally interested in.

3At the moment of initiating a dram i/o operation via this register, the Scan Sync Mode (§R.1) will normally be found to be 0, indicating that no internally-clocked scan is in progress or scheduled; nevertheless, typically one will explicitly write to it before performing dram i/o, in order to transfer the event count from the previous scan into the Event Count Register.

R.18 Offset Register

24 OSR

Offset Register

As explained in §??, the Offset Register of a stepchip records (modulo the size of each dimension) by how much the origin of the associated layer has shifted with respect to its initial reference position under the cumulative action of previous kicks.

The layer offset is added (separately for each dimension, as specified by the Dimension Cut Mask, §R.19) to the site address (which normally is the same for all layers) to yield the Physical Address (in dram) of the bit belonging to the currently scanned site and to the layer in question.

To implement the gluing algorithm (§??), this dram bit is made available to the data stream (§??) together with the homologous bits coming from the six adjacent modules. Which of these six bits is actually used depends on the x, y, and z carries from the above addition, in conjunction with the corresponding kick signs (§R.2).

The Offset Register is not cleared by a soft (interfaceinitiated) stepchip-reset. This is done to facilitate error recovery (see IR and DOCR).

R.19 Dimension Register

38 DR

Dimension Register

23 DCM

Dimension Cut Mask

5 XDCP

X-Dimension Cut Pointer

5 YDCP

Y-Dimension Cut Pointer

5 ZDCP

Z-Dimension Cut Pointer

The Dimension Register is used to indicate how the simulation space is shaped into a multidimensional array.

Specifically, the 23-bit Dimension Cut Mask is used to cut the site-address arithmetic chain into up to 24 slices, each corresponding to a distinct dimension (cf. §3.4).

The X-Dimension Cut Pointer specifies which of those dimensions is to be identified with the extendible dimension x. As indicated in the following table

XDCP X-Wrap source 0  carry from bit 0 1  carry from bit 1 2  carry from bit 2 ⋮  ⋮ 23  carry from bit 23 24–29 not used 30  0 31  1 ,  (R.6)

this pointer selects, as the source for the X-Wrap signal, the borrow (out of the corresponding slice) resulting from subtracting the x-component of the kick from the x-component of the site address. Values 30 and 31 of the Dimension Cut Pointers substitute for this borrow a constant value of 0 or 1; this is useful for testing, or for suppressing external gluing and allowing an extendible dimension to be wrapped around within the module (cf. §R.2).

Analogous considerations apply to the y and z dimensions and the associated Dimension Cut Pointer s. Note that external gluing is controlled by the Kick Signs and Kick Max Flags, as well as by the Cut pointers.

R.20 Hardware Environment Register

16 HER

Hardware Environment Register

1 LPL

LUT Pipeline Length

1 FPL

Flywheel Pipeline Length

1 DCS

DRAM Column Size

6 TBD

Tree Balancing Delay

4 TMS

Test Mode Select

1 NBF

Node Bypass Flag

1 SRE

Select Read Enable

1 ALS

Active LUT Select

The Hardware Environment Register contains information about the hardware connected to the stepchip: the size of the dram, the configuration of the CBus, pipelining information about the updating circuitry, etc.

If the LUT Pipeline Length is set, five bits of pipeline delay are expected between the sram address pins and the sram data pins (§??); otherwise, only one bit of delay is expected. What is normally connected between these two sets of pins is a sram lookup table which operates in a single clock cycle.

Similarly, if the Flywheel Pipeline Length is set, five bits of pipeline delay (rather than one) are expected in any hardware connected between the flywheel data output pins and the flywheel data input pins (§??).

The stepchip can work with drams with two column address sizes: 10 bits or 11 bits. 4 Mbit, nibble-wide drams have a 10 bit column address and a 10 bit row address (10+10); 16 Meg drams come in both 10+12 and 11+11. The DCS bit is used to tell the chip the width of the column address, according to the following table

DCS column address width 0  10 1  11 .  (R.7)

In the 10-bit mode, for chip test purposes, the two unused column-address lines carry the two least significant bit of the dram address, i.e., the address bits that select a bit within a nibble.

If the CBus tree is not implemented as a balanced tree (cf. §??), bus data will reach certain modules earlier than others. The Tree Balancing Delay specifies how much closer the given module is to the root than the farthest module in the tree. Since modules that are closer to the root receive their commands earlier (by one clock cycle per tree segment), a corresponding delay is inserted by the stepchip hardware before the start of a sweep (cf. §R.1) so as to allow all modules to sweep in lockstep. Note that this delay is not inserted during scan-io (§R.16), and so no use of glue should occur during this mode, since modules will not be scanned in lockstep.

Test Mode Select is used to put the stepchip into special test modes. Each of the 16 TMS values selects not only a test mode, but also a single output value that can be made available through Multipurpose Pins (cf. §R.21).

♠ The choices are [is this table final?]

TMS test mode  signal name
0 none

1 none

End Of Stretch Pulse

2 none

End Of Sweep Pulse

3 none

End Of Scan Pulse

4 5 6 7 8 9 10 11 12 13 14 15

(R.8)

A value of 1 for the Node Bypass Flag indicates that CBus signals and data entering the node on this chip from the inner (host) side should be used directly by the i/o circuitry, without first passing through the node. A value of 0 for this flag indicates that these bus signals are first reclocked by the node, and only then used (by the rest of the chip) after passing through the node. Use of this flag (provided bus timing constraints allow it) makes it easier to construct a balanced version of the CBus.

The Select Read Enable bit is used when register 0, the Module Select Register, is read. On such a read, the current selection state of the stepchip is ignored, and only stepchips that have the Select Read Enable bit set will respond (see §R.0).

According to its value, 0 or 1, the Active LUT Select bit tells which of the two luts (0 or 1) is currently active (cf. Active LUT Toggle in the Run Mode Register, §R.1). Writing this bit forces a specific lut to become the active one.

R.21 Multipurpose Pin Control Register

10 MPCR

Multipurpose Pin Control Register

5 MAFS

Multipurpose A Function Select

5 MBFS

Multipurpose B Function Select

The Multipurpose pins (§??) are used for input or output signals that need appear only once per module rather than once per stepchip. Each chip of a set will handle two different signals through its two Multipurpose pins, as instructed by the Multipurpose Pin Control Register. We provide two of these pins per chip so that even a module with a small number of stepchips will have enough multipurpose pins to provide all essential signals. This is convenient for constructing low-budget step machines, and also for reducing the number of stepchips needed to perform a complete simulation or test of a working system.

There are 32 choices for the function of each of the Multipurpose Pins. For simplicity, we have exactly the same choices available on both pins: the first four choices use the pin for input, the rest of the choices are outputs. The four input choices are:

MFS  Signal

0 External Input 1 External Interrupt

2 Scan Input
3 Status Input

(R.9)

The External Input allows an external signal to be delayed or inverted and come out on the other Multipurpose Pin, if it is suitably configured as an output; the External Interrupt allows external hardware connected to the module to signal an interrupt (see IER); the Scan Input makes it possible to check for intermodule scan-synchronization errors (see IER); and the Status Input (coming from a module farther out on the bus tree) is combined with the internally generated status signal to produce the Status output (see below).

The rest of the Multipurpose Function Select values indicate that the corresponding Multipurpose Pin is configured as an output. Each stepchip generates all of the module signals that might be needed; which signal is ouput to the pin is established by the Multipurpose Function Select according to the following table.

MFS  Signal

4 Status (Int/Scan)

5 Node LSOUT
6 Node IOSEL
7 Node RSOUT

8 Box Data Enable 9 SYNC (delayed) 10 Node Data Direction 11 Node Data Enable 12 Scan Is Active 13 Latch Glue Direction 14 LUT0 Chip Select 15 LUT0 Write Enable 16 LUT1 Chip Select 17 LUT1 Write Enable 18 Site Output Data Valid 19 Unglued Data Bit 20 Host Supplied Bit 21 SABSR Selected Bit 22 Display Output Data Valid

23 Run Type

24 Active LUT Select 25 Active LUT Output 26 CAM Interrupt 27 Scan In Progress 28 External Input Inverted 29 External Input Delayed

30 Constant of 0
31 Constant of 1

(R.10)

Choices 4–11 are CBus signals that are needed only once per module; they are documented in §??. Scan Is Active (choice 12) can be used in conjunction with Scan Input (choice 2) from another module to test that periods of active scanning occur at the same time in both modules (for this test, the scan is not considered to be active during Scan I/O, cf. §R.16). Latch Glue Direction (choice 13) is a pulse (intended for use by external glue signal buffers) that occurs just before active scanning begins; at this time, glue lines are either pulled up to indicate inputs, or actively driven low to indicate outputs. Choices 14– 17 control the SRAMs that constitute the two LUTs in a module. Data Valid (choice 18) is used in conjunction with choices 19–21, and also the LUT Address and the Flywheel Output to mark valid data bits. Display Valid (choice 22) has a slightly later timing, and is used to indicate when the Display Output has valid data. This timing is the same as that of the active LUT’s outputs, and the Flywheel input (except when used as an input to LUT and FLY). Run Type (choice 23) reflects the value of the third bit of the Run Mode Register; it is used in conjunction with choice 22 to indicate valid display output that occurs during a run of a particular type – for example, one that is meant to be sampled by a frame buffer. Similarly, Active LUT Select (choice 24) reflects the value of the last bit of the Hardware Environment Register, which indicates which of the two available LUTs is currently active for updating. Active LUT Output (choice 25) is a reclocked version of the actual output bit from the currently active LUT. CAM Interrupt and Scan Requested (choices 26 and 27) repeat the same information encoded in the Status signal (choice 4), but as two separate signals. External Input Inverted (choice 28) reflects the value (inverted) of an External Input (choice 0) if such an input was selected at the other Multipurpose Pin of this stepchip; similarly, External Input Delayed (choice 29) reflects an External Input that has been clocked through a single delay element.The Test MUX Output (choice 29) is an output that is determined by the current test mode (see Test Mode Select in §R.20). Finally, constants of 0 and 1 can be selected as choices 30 and 31 respectively.

At reset time, the Multipurpose pins are always configured as inputs (choice 0), and the Module ID Register is set from Multipurpose Pin A. This is used to distinguish one step module from all of the others in a given box (§6.3), using pullups and pulldowns. After reset, in an unbalanced tree, all boxes except the one at the root (corner) of the tree are cut off from the CBus until the root’s Multipurpose Pins are configured.^{4} This distinguishes the root box from all other boxes, and is useful in establishing a distinguished module to use as the origin for numbering the rest (i.e., the distinguished module in the corner box).

4The point in a CBus frame at which the new value of the Multipurpose Pin selections become enabled is chosen to make enabling the CBus work properly.

R.22 Glue Pin Connectivity Register

18 GPCR

Glue Pin Connectivity Register

3 XMPC

XM-Pin Connect

3 XPPC

XP-Pin Connect

3 YMPC

YM-Pin Connect

3 YPPC

YP-Pin Connect

3 ZMPC

ZM-Pin Connect

3 ZPPC

ZP-Pin Connect

The Glue Pin Connectivity Register is written at setup time in order to determine what logical interconnection should be associated with the physical interconnection provided by each of the six glue pins (§??).

One use of this configuration flexibility is described in §6.4.2. More drastic reconfigurations are possible. Normally the glue pins define a three-dimensional array of modules, interconnected as described in Chapter 3.5. However, by appropriately arranging the connectivity between modules, one can connect them as a twodimensional array (physically folded back-and-forth over itself, with the folds piling up in the third dimension), or even as a one-dimensional chain (§??).

♠

[make sure the terminology agrees] Each of the six connectivity registers corresponds to a physical glue port (stepchip pins XM, XP, YM, YP, ZM, ZP) and associates with it a logical glue port (x_{−}, x_{+}, y_{−}, y_{+}, z_{−}, z_{+}, as explained in §??) or one of the constants 0 and 1.

Whenever the kick sign for dimension x is positive, thus indicating that logical port x_{+} should be an output (cf. §??), then any physical port that has been associated with x_{+} by the Glue Pin Connectivity Register will be configured as an output and will display the value of x_{+}; if more than one physical port is associated with the same logical port, they will all behave alike.

When the kick sign is negative, thus indicating that logical port x_{+} should be an input, then any physical port associated with x_{+} will be configured as an input and will contribute a source of data for x_{+}: if more than one physical port is associated with x_{+}, their values will be ored before being passed on to x_{+}.

Finally, if a physical port is associated with a constant, then it will always be an output and display that constant. The constants are used during initialization for determining the physical connectivity of the machine and initializing each module’s ID (§6.2).

♠

[Read and understand; maybe add a diagram] The value of XM-Pin Connect determines the logical glue ports (or the constant) associated with the corresponding to physical port XM according to the following table (and similarly for the other five ports)

XMPC logical port
octal binary or constant
0  00 0  x_{−}
1  00 1  x_{+}
2  01 0  y_{−}
3  01 1  y_{+}
4  10 0  z_{−}
5  10 1  z_{+}
6  11 0  0
7  11 1  1

(R.11)

Each glue pin is internally pulled up by a resistor to a logical 1, so that, when configured as an input and not otherwise driven, it will sense a logical 1; this feature is used during module ID initialization (§6.2).

Any glue pin which is not configured as a constant will act as an input whenever the scan is not active.

R.23 Module ID Register

1 MIDR

Module ID Register

Each step module has a unique module ID, which is primarily used for module selection (§6.1); this ID is assigned during hardware initialization (§6.2). Each of the 16 stepchips of a set holds one bit of the module ID, in the Module ID Register (MIDR).

At reset, the MIDR is set to the value of the Multipurpose Pin A (see §6.2 for details).

R.24 Group ID Register

1 GIDR

Group ID Register

Besides the module ID, which is unique for each chip (§R.23), each step module has also a group ID, which is primarily used for module selection (see §6.1) when one wants to address a whole group of modules rather than a single one (see §6.1). Each of the 16 stepchips of a set holds one bit of the group ID, in the Group ID Register ( GIDR).

Note that by using the don’t care selection code (see table (R.1)) in some positions of the Module Select Register (§??), one can select different groups of modules based on data contained in different portions of the GIDR.

R.25 Interrupt Enable Register

10 IER

Interrupt Enable Register

1 BPIE

Bus Parity Interrupt Enable

1 BCIE

Bus Contention Interrupt Enable

1 GCIE

Glue Contention Interrupt Enable

1 MAIE Multi-A Contention Interrupt Enable

1 MBIE Multi-B Contention Interrupt Enable

1 SSIE

Skewed Scan Interrupt Enable

1 XHIE External Hardware Interrupt Enable

1 RLIE

Register Length Interrupt Enable

1 URIE Unknown Register Interrupt Enable

1 ISIE

Invalid SYNC Interrupt Enable

The Interrupt Enable Register is a collection of bits that individually enable the interrupts described in the following section, devoted to the Interrupt Flags Register. An interrupt will be recognized only if the corresponding IER bit is set. Since these interrupts all signal error conditions, their enables should normally all be on. Even in chips which don’t have External Hardware or Scan Input attached, the corresponding interrupts should not signal an error, and so can be left enabled.

An additional interrupt enable flag, associated with the verify-write mode, is discussed in §R.27.

R.26 Interrupt Flags Register

10 IFR

Interrupt Flags Register

1 BPIF

Bus Parity Interrupt Flag

1 BCIF

Bus Contention Interrupt Flag

1 GCIF

Glue Contention Interrupt Flag

1 MAIF

Multi-A Contention Interrupt Flag

1 MBIF

Multi-B Contention Interrupt Flag

1 SSIF

Skewed Scan Interrupt Flag

1 XHIF

External Hardware Interrupt Flag

1 RLIF

Register Length Interrupt Flag

1 URIF

Unknown Register Interrupt Flag

1 ISIF

Invalid SYNC Interrupt Flag

The Interrupt Flags Register is a collection of one bit flags, each of which is set when the corresponding error condition is detected (see §?? for details).

When an interrupt condition is detected by the stepchip hardware, if the corresponding enable flag is set (§R.25) an interrupt will be sent via the CBus to the step interface, which in turn will interrupt the host. Once the interrupt reaches the interface, further interface operation is suspended until the host restarts it.

An additional interrupt flag, associated with the verify-write mode, is discussed in §R.27.

The contention interrupts indicate that a signal sampled at the output of a bussed or bidirectional pin did not agree with the value that was being driven.

A Bus Parity error is indicated if the last completed CBus transaction didn’t have overall odd parity, including the final Parity bit that was sent.

A Skewed Scan interrupt is signalled if the Scan Input is used, and disagrees with the internally generated Scan is Active signal.

An External Hardware Interrupt is signalled if the External Interrupt Input is used, and it goes low.

A Register Length Interrupt is signalled if a Register is written by the host with an incorrect length, or if a register is read by the host with too short a length.

An Unkown Register Interrupt occurs if an attempt is made by the host to access registers 29, 30, or 31.

An Invalid SYNC Interrupt is signalled when one of the 4-bit packets of video-SYNC timing information (see §R.1) coming in on the SYNC input of the stepchip (cf. §??) fails to have even parity.

Note: the Interrupt Flags Register is not cleared by a soft (interface-initiated) stepchip-reset. This is done to facilitate error recovery (see OSR and DOCR).

R.27 Verify Write Register

3 VWR

Verify Write Register

1 VWE

Verify Write Enable

1 VWIE

Verify Write Interrupt Enable

1 VWIF

Verify Write Interrupt Flag

With an ordinary write frame, the transmitted data overwrite the contents of the addressed register (or the contents of the addressed dram or sram area, if the register is an I/O register). The Verify Write Register allows one to control a special verify-write mode, where the transmitted data are simply compared with this contents without changing it. This mode is enabled by turning on the Verify Write Enable. Verify write is always disabled while writing to the VWE register itself, to make it possible to turn the mode on and off.

In verify-write mode, an interrupt condition is signaled—by setting the Verify Write Interrupt Flag—if data written to a register disagree with its contents. Verify-write errors are only signaled at the end of a data transfer (see the discussion of data transfer errors in §??).

Setting the Verify Write Interrupt Enable allows the interrupt condition to generate an actual interrupt. Enabling the verify-write mode on a given stepchip without enabling the corresponding interrupt provides a way of disabling the writing of data on that chip. In this way, one can “write-protect” one or more of the sixteen layers, to change registers on some chips in the module and not on others. Note that this write-per-bit technique cannot be used with the luts.

R.28 DRAM Ones Count Register

16 DOCR

DRAM Ones Count Register

8 LDOC

Low DRAM Ones Count

8 HDOC

High DRAM Ones Count

A dram ones counter is an up/down counter that is cleared, together with the dram, at initialization time. From then on, each time a 0 in the dram is changed to a 1, the counter is incremented; each time 1 goes to 0, decremented; otherwise, it remains unchanged. Thus the counter should always reflect the number of ones in the dram (modulo the counter’s size).

By using the event counter to occasionally count all locations in the dram, and comparing this count with that recoreded by the ones counter, it should be possible to detect (with a high probability) soft errors in the dram.

Each stepchip has one dram chip attached to it. The DRAM Ones Count Register consists of two independent DRAM Ones Counts (LDOC and HDOC) that are associated repectively with the low and high halves of this dram.

By having separate counts for the two halves of the dram, it becomes possible to effectively handle errors on a large machine. We split the machine into two halves, each employing half of each dram chip, and both performing the same computation. In the case of a miscompare between the operation of the two halves, the DRAM Ones Counts make it likely that we can resolve which of the two halves got an error, and then correct the errorneous data from the other half.

The DRAM Ones Count Register is not cleared by a soft (interface-initiated) stepchip-reset. This is done to facilitate error recovery (cf. OSR (§R.18) and IFR (§R.26)).