A coarse-grained reconfigurable array or coarse-grained reconfigurable architecture (CGRA) is a class of spatial computing hardware built from a relatively large number of processing elements (PEs) connected through a programmable, statically or dynamically reconfigurable on-chip interconnect. By reconfiguring both the operation of each PE and the routing between PEs, a CGRA can be specialized to implement the dataflow graph of a computation, most often the body of a performance-critical loop. It sits between the adaptability of software-programmable processors and the energy efficiency of custom hardware.
The building blocks of a CGRA are fixed at the word level and reconfigured at a coarse granularity, distinguishing it from a field-programmable gate array (FPGA). FPGAs are reconfigurable at the level of individual bits and logic gates, which yields great flexibility at the cost of increased area, power, and configuration time overheads. General-purpose processors (CPUs and GPUs) are also highly flexible, but pay the energy cost of fetching and decoding an instruction stream for every operation, whereas an application-specific integrated circuit (ASIC) is the most energy-efficient option precisely because it is specialized to a single application and therefore the least flexible. By operating at word granularity, a CGRA retains much of the spatial, energy-efficient parallelism of custom hardware while remaining reprogrammable in software.
CGRAs were first envisioned in 1960 and took their modern shape in the mid-1990s. Since then, they have been applied to signal processing, wireless communication, and machine learning, and they appear in both academic prototypes and commercial silicon. Running a program on a CGRA depends on a specialized compiler that maps the program’s dataflow graph onto the array, a step that remains one of the main obstacles to wider adoption.
Background Interest in CGRAs comes from a widening gap in the hardware landscape. As the end of Dennard scaling and the slowing of Moore’s law reduce the performance gains that general-purpose processors once delivered automatically, computer architecture turned toward specialization to keep improving performance per watt, pushed in part by demanding workloads such as neural networks. At one extreme, fixed-function ASICs achieve the highest efficiency but incur high non-recurring engineering costs and cannot be changed after fabrication. At the other end, von Neumann processors are fully programmable but energy-inefficient, with FPGAs sitting in a flexible but costly middle ground. As dataflow architecture is reconfigurable at the word level, CGRAs try to combine near-ASIC efficiency with post-fabrication programmability.
History The idea of a machine whose structure can be reconfigured for a computation dates to the "fixed-plus-variable structure computer" proposed by Gerald Estrin in 1960. Coarse-grained arrays in the modern sense emerged in the mid-1990s, when several groups replaced the bit-level cells of an FPGA with word-level processing elements. The KressArray introduced a two-dimensional mesh of reconfigurable datapath units; MATRIX combined a word-level datapath with a configurable interconnect; RaPiD and PipeRench organized their cells as reconfigurable pipelines, with PipeRench reaching silicon; and MorphoSys paired a reconfigurable-cell mesh with a control processor for data-parallel media workloads.
Through the 2000s, the designs grew larger and more tightly integrated. ADRES coupled a VLIW processor with a reconfigurable matrix; TRIPS explored a polymorphous array capable of exploiting instruction-, thread-, and data-level parallelism; and PACT XPP offered a self-reconfiguring commercial fabric. From the 2010s onward, research emphasized data movement and system integration: HyCUBE introduced a single-cycle multi-hop interconnect, Plasticine organized computation around pattern compute and pattern memory units, and the stream-dataflow (Softbrain) model decoupled memory streaming from the spatial datapath. The same period saw an open-source ecosystem take shape, including ultra-low-power edge arrays such as OpenEdgeCGRA, which is integrated with the X-HEEP RISC-V microcontroller in the HEEPsilon platform to give a complete flow from C code to hardware.
A handful of CGRAs have reached commercial silicon. Samsung’s Reconfigurable Processor (SRP), derived from ADRES, has appeared in systems-on-chip and in ultra-low-power biomedical variants; SambaNova commercialized its reconfigurable dataflow unit (RDU), a large dataflow accelerator built from pattern compute and pattern memory units and aimed at machine-learning training and inference.
Architecture A CGRA fabric is typically organized as a two-dimensional array of processing elements, each built around an arithmetic logic unit (ALU) or functional unit, a small local register file or set of pipeline registers, and one or more configuration registers that determine, on a per-PE basis, which operation to execute and how operands are routed. The PEs are connected by a programmable interconnect (commonly a mesh, a torus, or, for smaller arrays, a crossbar switch) that lets operands produced by one PE reach its neighbors or, in richer designs, more distant PEs. Most CGRAs are not standalone; the array is coupled to a host or control processor, a role historically filled by a VLIW or ARM core and, in many recent open-source designs, by a RISC-V core. Depending on how closely the array is bound to the host, a CGRA is described as tightly coupled, sitting inside the processor datapath and invoked as a custom instruction, or loosely coupled, acting as a separate accelerator that communicates over an on-chip interconnect. The loosely coupled arrangement is the more common one in larger modern systems.
Programming a CGRA means loading a configuration into the array’s configuration memory: for each PE, the configuration specifies its operation (for example, add, multiply, shift, or compare) and the routing of its inputs and outputs. Because this configuration is coarse-grained, a dedicated CGRA can switch to a new configuration in nanoseconds, orders of magnitude faster than an FPGA can reconfigure. A single configuration yields a single spatial "snapshot" of the dataflow graph (DFG) being executed. In spatial-only CGRAs, the DFG of a kernel is unrolled once across the array, and each PE keeps the same configuration for the whole execution, similar in spirit to a systolic array. In temporal or spatio-temporal CGRAs, each PE instead cycles through a short sequence of configurations held in local configuration memory, time-multiplexing several DFG nodes onto the same physical PE across successive cycles.
The literature further classifies CGRA execution by the number of configurations and data streams a PE array handles at once: single-configuration, single-data (SCSD); single-configuration, multiple-data (SCMD), in which one configuration is applied across the array; and multiple-configuration, multiple-data (MCMD), in which several distinct configurations run concurrently.
+Comparison of CGRAs with other computing architectures Architecture Flexibility Computation form Execution mechanism Temporal Spatial Reconfiguration time Configuration-driven Dataflow-driven Instruction-driven CGRA Domain ns–μs AI engine (a) Domain ns–μs FPGA General (1) ms–s ASIC Fixed (2) CPU General GPU General Multi-core processor General Notes: (a) "AI engine" here denotes a domain-specific AI/ML accelerator built as a spatial array of VLIW-SIMD vector tiles connected by a programmable AXI-stream interconnect and local memories (for example, the AMD/Xilinx Versal AI Engine). Unlike an FPGA or a CGRA fabric, the AI-engine array and each tile’s datapath are fixed at the time of fabrication. What is programmable at run time is the software executed by each tile (so it is instruction-driven) and the stream and dataflow connectivity between tiles (so it is configuration- and dataflow-driven). (1) FPGAs can perform temporal computation, but doing so is not practical given the overhead involved. (2) ASICs do not support reconfiguration, although configuration codes may still exist. The reconfiguration-time entry is marked "not applicable" for CPUs, GPUs, and multi-core processors, since these are instruction-driven machines that do not reconfigure a fabric; their per-operation latency reflects instruction issue, not reconfiguration.
A further architectural distinction concerns whether the PEs across the array are identical or specialized. In a homogeneous CGRA, every PE supports the same set of operations, which simplifies placement and routing during compilation. In a heterogeneous CGRA, the PEs are specialized (for instance, only some implement a multiplier or a memory load/store unit, while the rest handle simpler arithmetic and logic operations). This reduces area and power for a given target workload, but at the cost of a harder mapping problem, since the compiler must place each operation on a PE that actually supports it. The homogeneous-versus-heterogeneous axis is independent of the spatial-versus-spatio-temporal distinction, giving a two-dimensional design space that runs from simple, easy-to-compile homogeneous-spatial arrays to complex, highly specialized heterogeneous-spatio-temporal ones.
Programming and compilation
Because a CGRA executes a spatial dataflow graph rather than a sequential instruction stream, its compiler must turn a program into a placed-and-routed configuration rather than into machine instructions. A typical flow starts from a high-level language, usually C or C++, identifies the performance-critical loops, and lowers each of them to a dataflow graph, commonly through an LLVM-based front end, despite some novel methodology uses MLIR. Loops that contain conditionals are made spatial by converting control dependencies into data dependencies through predication, whether partial or full, so that both sides of a branch are computed, and the correct result is then selected.
The core of the flow is the mapping problem: binding each DFG node to a PE and routing every data dependency through the interconnect, subject to the PEs’ operational capabilities, the interconnect topology, and timing constraints. This problem is NP-complete and is usually split into two coupled sub-problems: scheduling, which assigns each operation a time slot, and placement-and-routing, which binds operations to PEs and reserves interconnect resources. For pipelined loops, the key quality metric is the initiation interval (II), the number of cycles between the start of successive loop iterations, which sets the throughput. Software pipelining by modulo scheduling searches for a valid mapping at the smallest achievable II, raising the II and rescheduling whenever mapping fails. Mappers described in the literature use heuristics, simulated annealing, integer linear programming, graph-theoretic formulations such as maximal-clique search, and, more recently, learning-based and hierarchical methods.