Is a spatial architecture the same as the Spatial programming language?

No. The architecture is a broader hardware concept; Spatial is a named accelerator-design language and compiler.

Does spatial execution remove scheduling?

No. Operations and data transfers still have timing and dependency constraints.

Can higher throughput coexist with several cycles of item latency?

Yes. Different items can occupy different pipeline stages at the same time.

AI Glossary / Data engineering and architecture / Advanced

Spatial architecture

Definition

A spatial architecture is a computing organization that distributes operations across connected processing elements, mapping a computation's dataflow onto hardware resources. Intermediate values can pass between elements, and local storage can support reuse. The term concerns how computation is arranged in hardware, not the design of buildings or augmented-reality experiences. Its value depends on how well the workload fits the available computation, communication and memory resources.

What it means

A program describes operations and relationships between their inputs and outputs. A spatial implementation gives parts of that computation places in a hardware organization, so several operations or stages can work concurrently. This does not eliminate time: operations still need schedules, operands must arrive when required, and resources may be reused across cycles. The useful distinction is the explicit mapping of computation and communication across hardware. Merely counting processing units is insufficient to explain performance; their connections, storage and assigned work determine whether they can remain productively occupied.

How it works

A mapping assigns operations and data movement to processing elements, storage and communication paths. Designers consider which values stay local, which move between elements and which must reach external memory. Eyeriss provides a research example: its row-stationary dataflow targets reuse and reduced data movement in convolutional neural networks. Separately, the Spatial language and compiler research demonstrates higher-level descriptions of accelerators, including pipelines and memory organization. That named language is a tool for accelerator design, not a synonym for the entire architecture category. Practical mappings must respect dependencies and finite hardware resources.

Three practical examples

A neural-network accelerator distributes multiply-and-accumulate work across processing elements while considering where weights, activations and partial sums reside.
A streaming signal-processing design maps successive operations to connected stages so several input items can be in flight together.
A hardware design exercise compares two mappings of the same calculation, checking communication demands as well as arithmetic capacity.

Think of it this way

Imagine a workshop with separate stations for measuring, cutting and inspection. Products move between stations, and different products can occupy different stations simultaneously. Adding workstations helps only when materials arrive, handoffs work and no stage becomes a bottleneck. Hardware is more constrained than the workshop, but the analogy shows why placement, movement and timing belong in the same explanation.

Worked example

Consider an original simplified three-stage hardware pipeline. Stage A adds 1 to an input, stage B multiplies the result by 2, and stage C subtracts 3. Assume each stage takes one cycle, all handoffs are available, and a new input can enter every cycle. Input x = 4 produces (4 + 1) times 2 minus 3 = 7 after three cycles. For four inputs, the first result appears at the end of cycle 3 and the fourth at the end of cycle 6. A single non-overlapping execution resource taking three cycles per item would need 12 cycles under the stated comparison. The pipeline therefore takes half as many cycles for this batch, not one-third. Its initial filling time matters. This is illustrative arithmetic, not a performance claim about a particular chip or every spatial mapping.

Illustrative case study

In a fictional industrial-camera project, engineers map an image-processing workload onto an accelerator. Their first estimate multiplies the number of arithmetic units by a nominal operation rate. A prototype evaluation reveals that some units wait for input data. The team revises the memory organization and tests alternative mappings, measuring complete-frame latency as well as sustained throughput. It also verifies that outputs match the intended numerical behavior. The scenario illustrates why available computation does not automatically become delivered application performance. It reports no measured result from Eyeriss or the Spatial compiler and does not claim that a particular mapping is universally best.

Common misconceptions and mistakes

Spatial architecture does not mean geographic computing or necessarily a three-dimensional chip layout. It also does not imply that every operation receives a permanently dedicated unit. Designs can combine spatial distribution with reuse over time. Another mistake is equating throughput with latency: in the toy pipeline, outputs can follow one cycle apart after filling, while each item still traverses three stages. Finally, the number of processing elements alone cannot establish energy efficiency or speed. Moving operands, storing intermediate values and feeding the computation remain part of the system's cost.

Business use

The concept helps teams evaluate accelerator claims in terms of actual workloads. Ask which operations map efficiently, what shapes and sizes are supported, and whether memory traffic limits useful performance. For an AI application, compare numerical outputs and model behavior alongside latency, throughput and energy measurements. Include transfers and preparation when the business requirement concerns end-to-end response time. A favorable result on one kernel should remain scoped to that measurement. Changes in model structure or input dimensions may require a new mapping or a fresh evaluation rather than an assumption that earlier performance carries over.

Check your understanding

What result does the toy pipeline produce for x = 4?

Answer: Seven.

When does the first result appear under the stated assumptions?

Answer: At the end of cycle 3.

When does the fourth appear?

Answer: At the end of cycle 6.

Why is counting arithmetic units inadequate in the fictional camera project?

Answer: Units can wait for operands, so their existence does not establish useful completed work.

Related terms

Pipelining
Dataflow architecture
processing element
hardware accelerator
systolic array
local data reuse

Learn next

Draw a three-operation computation and assign each operation to a hypothetical hardware stage. Trace four inputs cycle by cycle. Then make one stage accept an input only every second cycle and reconsider throughput. State which resources or buffering assumptions would need to change before claiming that the original schedule remains feasible.

Sources

Yu-Hsin Chen, Joel Emer and Vivienne Sze, Eyeriss: A Spatial Architecture for Energy-Efficient Dataflow for Convolutional Neural Networks, 2016, MIT repository record and abstract: https://dspace.mit.edu/entities/publication/f6342515-2b7d-411c-a8ad-a9edb23dd394 David Koeplinger and colleagues, Spatial: A Language and Compiler for Application Accelerators, 2018: https://ppl.stanford.edu/papers/spatial18.pdf The pipeline calculation, workshop analogy and camera scenario are original educational illustrations. Historical research results are not presented as current product benchmarks.

Previous: Spatial Analysis of Principal Components Next: Spatial embedding