185 lines
19 KiB
Markdown
185 lines
19 KiB
Markdown
# Systems and Methods for Executing Memory-Image-Defined Computation on a Cellular Automaton Computing Substrate
|
|
|
|
## Cross-Reference To Related Applications
|
|
|
|
[To be completed.]
|
|
|
|
## Field
|
|
|
|
The disclosure relates to cellular automata, reconfigurable computing, processing-in-memory, accelerator architectures, nonlinear simulation, reversible or information-conserving computation, and memory-image-defined computational substrates.
|
|
|
|
## Background
|
|
|
|
Conventional digital processors execute programs primarily as sequences of instructions interpreted by fixed processor hardware. General-purpose processors provide substantial flexibility, but their performance and energy efficiency may be limited for workloads involving large numbers of local nonlinear interactions, spatial propagation, collision dynamics, particle-like behavior, wave-like behavior, or other computations that are naturally expressed as local evolution over a spatial domain.
|
|
|
|
Special-purpose accelerators may improve performance for selected workloads, but the hardware behavior of such accelerators is generally fixed after fabrication. Field-programmable gate arrays provide reconfigurability, but reconfiguration may be costly, may require specialized hardware-description flows, and may not provide a native model for computations expressible as local nonlinear dynamics.
|
|
|
|
Cellular automata provide a model of computation in which cell states evolve according to local transition rules. Certain cellular automata exhibit persistent propagating structures, collision behavior, and universal computation. However, known cellular-automaton computation systems often emphasize theoretical universality, software simulation, or isolated demonstrations of logic, rather than a practical computing substrate in which executable machines and simulation engines are loaded as spatial memory images and evolved by fixed high-speed update circuitry.
|
|
|
|
There remains a need for a computing architecture in which a fixed local evolution rule is implemented efficiently in hardware while effective processor architectures, accelerators, and nonlinear simulation machines are updated by loading different cellular automaton state images.
|
|
|
|
## Summary
|
|
|
|
In one aspect, a computing system comprises a memory array configured to store cell states of a cellular automaton and update circuitry configured to repeatedly apply a fixed local evolution function to the cell states. An executable computation is encoded as a cellular automaton state image loaded into the memory array. The state image may include persistent propagating structures, interaction regions, routing structures, emitter structures, detector structures, register regions, memory-interface regions, and output regions. Computational results are obtained by reading predetermined output regions after one or more update cycles.
|
|
|
|
In some embodiments, the fixed local evolution function is a protected evolution function `F` operating on compact multi-bit cell states. In some embodiments, each cell state comprises a 6-bit value. Multiple independent cellular automaton cores may be packed into wider memory words, such as ten 6-bit cell states in a 64-bit word with additional bits used for metadata, parity, cyclic redundancy checking, error detection, or other integrity functions.
|
|
|
|
In some embodiments, the cellular automaton state image defines an effective hardware architecture, such as a virtual processor, special-purpose accelerator, signal-routing fabric, or logic network. Loading a different state image changes the effective hardware behavior without modifying the physical update circuitry that implements the evolution function.
|
|
|
|
In other embodiments, the cellular automaton state image directly defines a nonlinear simulation engine, such as a particle simulator, radiation transport simulator, plasma wakefield simulator, field propagation engine, collision cascade model, nonlinear wave computation engine, or spatial constraint solver. Such direct image programs may use the native dynamics of the evolution function rather than emulating a conventional sequential processor.
|
|
|
|
In some embodiments, the update circuitry implements a deterministic pull-based update in which each cell computes its own next state from its current state and a bounded neighborhood, thereby avoiding nondeterministic multi-writer conflicts. Simultaneous neighbor influences may be resolved by a symmetry-preserving transition rule, by producing collision states, or by a deterministic priority orientation distributed across the lattice according to a balanced spatial pattern to compensate directional bias.
|
|
|
|
In some embodiments, outputs from multiple cellular automaton cores are validated by comparison, parity, cyclic redundancy checking, or execution of mirrored, rotated, coordinate-transformed, or otherwise transformed versions of a state image.
|
|
|
|
## Brief Description Of The Drawings
|
|
|
|
Figure 1 illustrates an example computing system comprising a host processor, memory array, image loader, cellular automaton update engine, output reader, and validation module.
|
|
|
|
Figure 2 illustrates an example packed memory word storing multiple compact cellular automaton cell states and additional integrity bits.
|
|
|
|
Figure 3 illustrates a local evolution function computing a next state from a central cell and a bounded neighborhood.
|
|
|
|
Figure 4 illustrates a pull-based race-free cellular automaton update.
|
|
|
|
Figure 5 illustrates symmetry-preserving conflict resolution in which simultaneous neighbor influences are collected as a local pattern.
|
|
|
|
Figure 6 illustrates a bias-compensated deterministic orientation pattern distributed across cells, rows, planes, tiles, or cores.
|
|
|
|
Figure 7 illustrates loading different cellular automaton state images to define different effective hardware architectures or simulation engines.
|
|
|
|
Figure 8 illustrates persistent propagating structures and interaction regions.
|
|
|
|
Figure 9 illustrates designated output regions from which computational results are read.
|
|
|
|
Figure 10 illustrates redundant or transformed cellular automaton cores for validation.
|
|
|
|
## Detailed Description
|
|
|
|
### Overview
|
|
|
|
The disclosed system provides a reconfigurable cellular automaton computing substrate. A physical substrate stores cell states in memory and repeatedly applies a fixed local evolution function `F`. Rather than executing only a conventional sequential instruction stream, the system loads computation as one or more cellular automaton state images. The image evolves under `F`, and computational output is read from designated memory regions.
|
|
|
|
The physical update hardware may remain unchanged while the effective machine executed by the substrate changes. A first loaded image may define a virtual processor. A second loaded image may define a particle simulator. A third loaded image may define a plasma wakefield simulation engine. A fourth loaded image may define a collision-based logic network or special-purpose accelerator. Thus, the system provides mutable effective hardware on a fixed physical rule engine.
|
|
|
|
### Cellular Automaton State
|
|
|
|
The cellular automaton comprises a plurality of cells arranged on a lattice. The lattice may be one-dimensional, two-dimensional, three-dimensional, or higher-dimensional. In a preferred class of embodiments, the lattice is three-dimensional and each cell has a bounded neighborhood, such as axial neighbors, diagonal neighbors, a Moore neighborhood, a von Neumann neighborhood, or another fixed local neighborhood.
|
|
|
|
Each cell stores a cell state. The cell state may be a compact multi-bit value. In one embodiment, each cell state comprises a 6-bit value, providing 64 possible states. The bits may encode one or more of a core state, cell type, phase, direction, parity, interaction state, collision state, or auxiliary state. The precise interpretation of the bits may be defined by the evolution function `F` and by the image program loaded into the substrate.
|
|
|
|
In some embodiments, the evolution function `F` is cell-type-count preserving. In some embodiments, `F` conserves one or more quantities associated with cell states. In some embodiments, `F` is information-conserving or reversible. In other embodiments, `F` is deterministic but not fully reversible.
|
|
|
|
### Fixed Local Evolution Function
|
|
|
|
The update circuitry applies a fixed local evolution function `F` to compute next cell states. For a cell `c`, the next state may be expressed as:
|
|
|
|
```text
|
|
next(c) = F(state(c), states(N(c)))
|
|
```
|
|
|
|
where `N(c)` is a bounded neighborhood of `c`.
|
|
|
|
The function `F` is local, deterministic, and closed over the cell-state alphabet. In embodiments designed for highly parallel hardware, each cell computes and writes only its own next state. This pull-based update avoids nondeterministic write conflicts that may occur when multiple neighboring cells attempt to write to the same destination cell.
|
|
|
|
The function `F` may be embodied in combinational logic, a lookup table, microcoded update circuitry, FPGA logic, GPU kernels, SIMD instructions, near-memory update circuitry, processing-in-memory circuitry, or an application-specific integrated circuit.
|
|
|
|
### Persistent Propagating Structures
|
|
|
|
In some embodiments, the evolution function `F` supports persistent propagating structures. Such structures may include gliders, localized wave packets, particle-like configurations, or other coherent patterns that propagate through the lattice while preserving recognizable identity or information.
|
|
|
|
Persistent propagating structures may be used as signals, information carriers, particle analogues, routing elements, timing structures, or components of logic gates. Compared with fragile propagating structures in some cellular automata, the persistent structures contemplated here may be robust under the protected evolution function and may support reliable routing, collision, emission, detection, or computation.
|
|
|
|
### Image Programs
|
|
|
|
An image program is a cellular automaton state image configured to perform a computation by evolving under `F`. The image may include initial states, maintained boundary regions, emitter regions, detector regions, interaction regions, routing paths, memory regions, register regions, and output regions.
|
|
|
|
Image programs may be loaded into the memory array by a host processor, direct memory access engine, image loader, external device, or another subsystem. Once loaded, the update circuitry repeatedly applies `F`. The computation proceeds as the state image evolves. Results may be read from predetermined output regions after a specified number of update cycles, upon satisfaction of a stopping condition, or continuously during evolution.
|
|
|
|
The image program may define an effective hardware architecture. For example, a state image may define a virtual processor comprising register regions, instruction-processing structures, memory-interface regions, routing paths, control structures, and output regions. The virtual processor may use persistent propagating structures as signals and collision regions as logic or control elements.
|
|
|
|
Alternatively, the image program may directly define a nonlinear simulation. In such embodiments, the CA evolution itself performs the simulation, and the system need not emulate a conventional processor. The state image may represent particles, fields, emitters, detectors, boundary conditions, media properties, interaction regions, or measurement regions.
|
|
|
|
### Effective Hardware Updated By Loading Images
|
|
|
|
The system separates the physical update rule from the effective machine. The physical circuitry implements `F`. The loaded image defines how `F` is used.
|
|
|
|
Loading a different image may alter the effective hardware architecture without changing the physical update circuitry. For example, after deployment, the same device may be reconfigured from a particle simulation engine to a virtual processor, from a virtual processor to a special-purpose accelerator, or from one accelerator topology to another accelerator topology by replacing the loaded CA state image.
|
|
|
|
This is distinct from merely loading different data into a conventional processor. In the disclosed system, the loaded image may define the machine structure itself, including signal paths, interaction regions, emitters, detectors, registers, gates, memory interfaces, and output regions.
|
|
|
|
### Packed Multi-Core Representation
|
|
|
|
In some embodiments, multiple CA cores are packed into a wider memory word. For example, a 64-bit memory word may store ten 6-bit cell states, leaving four additional bits. The additional bits may be used for parity, cyclic redundancy checking, error detection, metadata, phase information, boundary tags, addressing information, or other integrity or control information.
|
|
|
|
The packed representation may enable parallel execution of multiple independent CA cores. The cores may execute identical images, different images, redundant images, mirrored images, rotated images, coordinate-transformed images, or images representing different simulation parameters.
|
|
|
|
### Validation And Redundancy
|
|
|
|
The system may include validation circuitry or software configured to compare outputs from multiple CA cores. Redundant cores may execute identical images. Alternatively, transformed cores may execute mirrored, rotated, coordinate-inverted, or otherwise transformed versions of a state image. Outputs may be mapped to a common interpretation and compared.
|
|
|
|
Validation may include equality checks, threshold comparisons, parity checks, CRC checks, statistical checks, conservation-law checks, or domain-specific output checks. Such validation may detect hardware faults, memory corruption, update faults, radiation-induced errors, or divergent computation.
|
|
|
|
### Conflict Resolution
|
|
|
|
Parallel CA updates may encounter simultaneous neighbor influences. A push-based update in which cells attempt to write to neighbors may create races or nondeterministic multi-writer conflicts. The disclosed system may instead use pull-based updates in which each cell reads its neighborhood and computes only its own next state.
|
|
|
|
In some embodiments, `F` resolves simultaneous influences by collecting all relevant neighbor influences into a local pattern and mapping that local pattern to a next state. The mapping may avoid selecting a winning neighbor according to a fixed global priority direction.
|
|
|
|
In some embodiments, `F` is equivariant under selected lattice transformations. For a selected transformation `T`, the function may satisfy:
|
|
|
|
```text
|
|
F(T(neighborhood)) = T(F(neighborhood))
|
|
```
|
|
|
|
This property may reduce artificial directional bias and may support mirrored or transformed redundancy.
|
|
|
|
In other embodiments, deterministic local priority is used, but the priority orientation varies across the lattice. For example, cells, rows, planes, tiles, or cores may be assigned orientation classes corresponding to different priority directions. The orientation classes may be distributed according to a balanced pattern such that no lattice direction is globally preferred. The orientation class may be hardcoded in ASIC layout, stored in metadata, derived from low-order address bits, or determined by a repeating supercell.
|
|
|
|
### Native Nonlinear Computation
|
|
|
|
The CA substrate may be particularly useful for computations naturally expressible as local nonlinear evolution. In such workloads, the CA tick itself performs useful computation. Unlike conventional particle or field simulation approaches that calculate interactions explicitly as pairwise or matrix operations, the disclosed substrate may represent interacting structures within the state image and allow interactions to arise through repeated local application of `F`.
|
|
|
|
For a fixed lattice region and representable density, the update cost may be determined primarily by the number of cells updated rather than by the number of pairwise interactions represented within the image. This may provide advantages for dense local dynamics, propagation, collision, or field-like computation.
|
|
|
|
Example native workloads include particle simulation, radiation transport, plasma wakefield simulation, nonlinear field propagation, wave dynamics, collision cascades, cellular materials, spatial Bayesian propagation, event detection, and local constraint solving.
|
|
|
|
### Virtual Processor Embodiment
|
|
|
|
In one embodiment, the loaded state image comprises a virtual processor. The virtual processor may include register regions, control regions, memory access structures, instruction decoding structures, routing paths, clocking or phase structures, and output regions. Persistent propagating structures may function as signals. Interactions between propagating structures may implement logic, branching, memory access, synchronization, or control flow.
|
|
|
|
The virtual processor embodiment demonstrates that the substrate may host general-purpose computation. However, the substrate is not limited to virtual processor images. Direct simulation images and special-purpose accelerator images may use the CA dynamics more directly and may avoid overhead associated with emulating conventional instruction execution.
|
|
|
|
### Hardware Implementations
|
|
|
|
The update circuitry may be implemented using one or more of an ASIC, FPGA, GPU, CPU SIMD engine, vector processor, near-memory processor, processing-in-memory array, memory controller, or dedicated co-processor. In an ASIC embodiment, the update circuitry may be configured to read fixed neighborhoods, compute next states according to `F`, and write next states at high speed. Double buffering, phase buffering, tile buffering, streaming update, or other memory-management techniques may be used.
|
|
|
|
The memory array may include SRAM, DRAM, embedded DRAM, high-bandwidth memory, stacked memory, nonvolatile memory, or another storage medium capable of storing CA cell states. The update circuitry may be located adjacent to, integrated with, or distributed within the memory array.
|
|
|
|
## Example Embodiments
|
|
|
|
### Example 1: Reconfigurable CA Processor
|
|
|
|
A host loads a state image defining a virtual processor into a high-speed memory array. The update engine applies `F` for a predetermined number of ticks. The virtual processor writes results to designated output regions. The host reads the output regions and may load a different image to change the effective processor architecture.
|
|
|
|
### Example 2: Particle Transport Image
|
|
|
|
A state image encodes particle-like structures, emitters, detectors, and interaction regions. The update engine applies `F`, causing persistent structures to propagate and interact. Detector regions accumulate output values corresponding to transport, scattering, absorption, or arrival events.
|
|
|
|
### Example 3: Plasma Wakefield Image
|
|
|
|
A state image encodes beam-like structures, field-like regions, boundary conditions, and measurement zones. Applying `F` evolves the image to approximate or compute nonlinear propagation and wakefield interactions. Output regions store measurements of field intensity, particle arrival, or other quantities.
|
|
|
|
### Example 4: Bias-Compensated ASIC Update
|
|
|
|
Each cell has an orientation class derived from low-order address bits. The orientation class determines a deterministic priority order for local conflict resolution. A repeating supercell assigns equal numbers of orientation classes corresponding to opposing and orthogonal lattice directions. The resulting update remains deterministic and hardware-simple while reducing global directional drift.
|
|
|
|
### Example 5: Mirrored Core Validation
|
|
|
|
Ten 6-bit CA cores are packed into a 64-bit memory word. Several cores execute mirrored or rotated versions of the same state image. Output regions are transformed back to a common coordinate frame and compared. Divergence indicates a possible memory error, hardware fault, or invalid computation.
|
|
|
|
## Claims
|
|
|
|
[See `claims.md` for the working claim set.]
|
|
|