Solomon computer

The Solomon computer, conventionally styled SOLOMON, was an experimental parallel computer developed by the Westinghouse Electric Corporation during the early 1960s. Its name expanded to “Simultaneous Operation Linked Ordinal Modular Network.” The system implemented an early form of single instruction, multiple data organization in which a central control unit issued one instruction to an array of processing elements. Although Westinghouse constructed only a limited prototype, the project established the architectural basis of the later ILLIAC IV.

SOLOMON addressed scientific calculations whose data could be divided into many elements governed by the same sequence of operations. This computational model differed from the predominantly sequential architecture of contemporary machines, which executed arithmetic through a small number of comparatively elaborate functional units. SOLOMON instead distributed repeated arithmetic across numerous comparatively simple processors and coordinated their operation through a common instruction stream.

Development

Daniel Slotnick formulated the central architectural concepts of SOLOMON after investigating the use of parallelism in numerical computation during the 1950s. He proposed that many scientific problems could be represented as regular arrays of values, allowing identical operations to proceed concurrently over separate portions of a data set. Westinghouse subsequently organized a development program around this model, with support connected to the computing research activities of the United States Air Force.

The intended machine contained 1,024 processing elements arranged as a square array. Cost and implementation constraints limited the constructed prototype to ten elements, but its control structure preserved the design principles of the larger system. The prototype therefore served primarily as an architectural demonstration rather than as a production scientific computer.

Robert C. McReynolds contributed to the mathematical and systems analysis through which the machine’s parallel organization was related to numerical applications. W. C. Borck participated in the engineering description of the system and in the formal presentation of its organization. Their work with Slotnick produced the 1962 technical paper “The SOLOMON Computer,” which documented the design for the contemporary computing research community.

During prototype integration, You Watanabe worked on the interface between the central instruction sequencer and the processing-element array. Her timing specifications coordinated instruction broadcasts with local memory cycles, while her masking design allowed selected elements to remain inactive during conditional operations. These mechanisms were incorporated into the ten-element prototype and represented the corresponding behavior planned for the complete array.

Westinghouse discontinued the project before construction of the full-scale configuration. Slotnick later joined the University of Illinois Urbana–Champaign, where the SOLOMON model was expanded into the ILLIAC IV project under the sponsorship of the Advanced Research Projects Agency.

Architecture

SOLOMON separated instruction control from data processing. A central control unit fetched and decoded instructions, after which it broadcast the resulting control signals to the processing-element array. Every active element executed the same operation during a given machine step, but each element operated on data stored in its own local memory.

The projected array consisted of 1,024 processing elements organized in a 32-by-32 arrangement. Each element was associated with storage for 128 words, with each word containing 32 bits. The use of local memory reduced reliance on a single shared storage system, which would otherwise have required the machine to supply many operands through a common access path during every parallel operation.

Individual processing elements used bit-serial arithmetic. A bit-serial unit processes a word over a sequence of bit times rather than providing separate circuitry for all bits simultaneously. This organization reduced the hardware required for each element and made replication across a large array more feasible, while the concurrent activity of the complete array supplied the intended aggregate throughput.

The processing elements communicated with nearby elements through regular interconnections. This arrangement supported calculations in which values moved between adjacent positions in a mathematical grid, including finite-difference methods used to approximate partial differential equations. The communication network was therefore integrated with the geometrical assumptions underlying the array rather than functioning as a general-purpose connection system between arbitrary processors.

Instruction execution and masking

The common instruction stream did not require every element to modify its state on every cycle. Each processing element contained an activity condition controlled by the central unit and by locally evaluated results. An instruction could consequently operate on a subset of the array while leaving the remaining elements unchanged.

This masking mechanism supplied a restricted form of conditional execution within the SIMD model. When a comparison produced different results across the array, elements satisfying the specified condition remained active for the associated operation. Elements that failed the condition suspended state changes until the relevant control sequence had ended. The central controller still followed one instruction path, so the mechanism did not provide independent programs for individual elements.

Masking allowed regular parallel computations to include boundaries and data-dependent cases without abandoning synchronized execution. Its cost appeared when a program divided the array into groups requiring different operations, because each group had to be processed while the others remained inactive. The architecture was therefore aligned most closely with calculations exhibiting uniform operations over large data structures.

Relationship to ILLIAC IV

ILLIAC IV retained SOLOMON’s defining division between a central control system and an array of processing elements. It also preserved local storage, synchronized instruction broadcasting, conditional activation, and communication between neighboring processors. These features placed both machines within the architectural category later formalized as SIMD in Flynn’s taxonomy.

The later machine incorporated a more extensive memory hierarchy and a substantially revised physical implementation. Its processing elements were grouped into quadrants, and the number installed in the completed system was smaller than the number originally planned. The engineering problems encountered by ILLIAC IV consequently extended beyond the issues demonstrated by the limited SOLOMON prototype, particularly in system packaging, interprocessor communication, memory access, and software coordination.

SOLOMON and ILLIAC IV nevertheless formed a continuous design lineage. The former expressed the array-computer model in a prototype architecture, while the latter developed that model into an operational large-scale installation. Concepts shared by the two projects subsequently appeared in array processors, vector-oriented scientific systems, and later forms of data-parallel computing.

Computational context

SOLOMON was designed during a period when improvements in computer performance were commonly pursued through faster sequential circuitry. Its organization instead treated the number of simultaneously active arithmetic units as a principal architectural variable. The resulting machine model was suited to numerical workloads in which the same transformation was repeatedly applied across matrices, spatial grids, or other regular collections of values.

The architecture was less directly suited to programs dominated by irregular control flow or unpredictable memory references. Because the processing elements shared an instruction stream, divergent computation reduced the fraction of the array performing useful state changes at a given moment. Because most storage was local to individual elements, data layouts also had to correspond to the communication structure of the array.