Neura: A Unified Framework for Hierarchical and Adaptive CGRAs

Cheng Tan, Miaomiao Jiang, Yuqi Sun, Ruihong Yin, Yanghui Ou, Qing Zhong and 2 others

A CGRA is a grid of small compute units you reconfigure to accelerate a program's hot loops cheaply, but they stay niche because three things fail to scale — the compiler that maps a loop onto the grid chokes as the grid grows, the fixed grid is too rigid, and it cannot juggle several programs at once; this paper (Cheng Tan, Jeff Zhang, and colleagues) presents Neura, an open-source framework whose hierarchical grid plus migration-aware mapping let it place, move, and share multiple kernels dynamically, improving throughput 1.64 to 3.85 times over a conventional grid of the same size.

The argument in one glance

Problem

CGRAs are efficient but do not scale up to wide adoption

A Coarse-Grained Reconfigurable Array (CGRA) is a grid of small processing elements — little compute units, each an arithmetic unit — connected by a reconfigurable network. You can quickly rewire the grid to match the compute-heavy inner loops of a program, which makes CGRAs a promising, energy-efficient way to accelerate many different kinds of workloads without building fixed-function hardware for each one. The trouble is that CGRAs have stayed a niche technology rather than being widely adopted, and the paper traces this to three linked scalability problems. First, mapping scalability: to run a loop on a CGRA, a compiler has to map the loop's operations onto the grid's processing elements and route the data between them, and existing mapping algorithms struggle to find feasible, let alone optimal, placements as the design grows more complex. Second, architectural limitations: the mapping granularity is rigid and memory access is restricted, which caps how flexibly the array can be used and how much performance it can reach. Third, dynamic multi-kernel support: running several kernels dynamically and simultaneously on one array is barely explored, so CGRAs fall short in the complex, multi-kernel scenarios real systems present. Together these mean that simply making a CGRA bigger does not make it more useful.
What people did

Scale a conventional flat CGRA up and map kernels onto it as usual

The natural response to wanting more performance is to build a bigger conventional CGRA — a larger flat grid of processing elements — and keep using existing mapping algorithms to place each kernel onto it. Each kernel is compiled to a mapping that pins its operations to specific processing elements and its data to specific routes, one kernel at a time, on a uniform array. The hope is that a larger array offers more compute and can therefore run larger or more kernels.
Why it fell short

A bigger flat array is harder to map, too rigid, and left underused

Scaling a flat CGRA runs straight into all three problems at once. As the grid grows, the mapping problem — placing operations and routing data across the array — grows dramatically harder, so mapping algorithms fail to find feasible or optimal solutions and the extra hardware cannot actually be put to good use. The array's rigid mapping granularity and restricted memory access mean kernels that do not match its fixed shape waste resources. And because a conventional CGRA has no real support for running several kernels dynamically and simultaneously, a large array handed a multi-kernel workload cannot flexibly divide itself among the kernels or shift resources as demand changes — so much of it sits idle. The missing capability is a CGRA that is organized so that mapping stays tractable at scale, whose resources can be allocated at a flexible granularity, and that can place, move, and share multiple kernels across the array at runtime to keep it busy. Without that, a bigger CGRA is harder to program and ends up underutilized.
This paper's idea

A hierarchical array plus migration-aware mapping that moves and shares kernels

Neura is an open-source, unified framework built to make CGRAs scalable, and it attacks the three problems together with two co-designed pieces. The first is a hierarchical spatial-temporal CGRA architecture: instead of one flat uniform grid, the array is organized hierarchically and supports both spatial mapping (spreading a computation across processing elements) and temporal mapping (time-multiplexing the same elements across steps), which relaxes the rigid granularity and memory-access limits and keeps mapping tractable as the design grows. The second is a migration-aware mapping algorithm: a mapper that plans placements with the possibility of moving kernels in mind. This combination is what uniquely enables dynamic resource allocation and kernel migration — the framework can allocate portions of the array to kernels at runtime, and move a running kernel to a different region — so multiple kernels can execute dynamically and simultaneously while the array stays well utilized. Across different scenarios, the paper reports Neura improves throughput by 1.64 to 3.85 times, with significantly higher utilization, over a conventional CGRA at the same scale.

Why this problem is worth solving

CGRAs sit in an attractive but hard-to-reach spot between fixed accelerators and general processors, and unlocking their scalability is what would let them be widely used.

A Coarse-Grained Reconfigurable Array promises much of the energy efficiency of custom hardware with much of the flexibility of a programmable processor: you reconfigure one grid of compute units to accelerate whatever inner loop matters right now, across many application domains, instead of taping out a new chip per workload. That is exactly the kind of efficient, reusable acceleration modern systems need as general-purpose scaling slows. But the promise only pays off if CGRAs scale — if a larger array is actually more capable and more useful. The paper’s point is that today they do not scale, and for a concrete, structural reason: the compiler cannot map well onto a big array, the array is too rigid, and it cannot juggle several kernels at once. So the barrier to CGRAs graduating from a niche technique to a broadly adopted one is precisely these scalability limits. Removing them is what would let a single reconfigurable fabric serve many kernels efficiently, which is the whole reason to prefer a CGRA over fixed hardware in the first place.

The deeper realization is that scale is not just about having more processing elements — it is about being able to allocate, move, and share them among kernels.

It is tempting to equate a bigger CGRA with a better one, but the paper’s framing shows why that is wrong. Adding processing elements only helps if the compiler can map work onto them and if the array can be kept busy; a large flat array that the mapper cannot handle, or that can only run one rigidly-shaped kernel at a time, wastes most of its silicon. The scarce resource is therefore utilization under realistic, multi-kernel workloads, not the transistor count. That reframing is what points to the solution: rather than just growing the grid, you need an architecture whose resources can be carved up at a flexible granularity and a mapping strategy that can dynamically place several kernels and migrate them as demand shifts, so the array actually stays occupied. This is why Neura pairs a hierarchical, spatial-temporal architecture with a migration-aware mapper — the two together turn extra hardware into extra useful throughput. Measuring success by throughput and utilization across multi-kernel scenarios, rather than by peak array size, is what makes the problem tractable and the gains real.

What people did before, and where it broke

Map each kernel onto a flat CGRA with existing algorithms. Compile one kernel at a time, pinning operations to processing elements and routing its data. Where it broke. As the array grows, the mapping problem explodes and existing algorithms fail to find feasible or optimal solutions, so the extra hardware cannot be used well.
Just build a bigger, uniform array. Add more processing elements in the same flat, rigid organization. Where it broke. Rigid mapping granularity and restricted memory access mean kernels that do not fit the fixed shape waste resources, and mapping only gets harder.
Run one kernel at a time. Treat the CGRA as dedicated to a single kernel for the duration. Where it broke. Real workloads have multiple kernels; a single-kernel array cannot serve them together and leaves most of the fabric idle whenever a kernel does not fill it.
Ignore dynamic, simultaneous multi-kernel execution. Assume kernels arrive and finish in a static, non-overlapping schedule. Where it broke. Dynamic and simultaneous multi-kernel execution is barely supported, so CGRAs fall short exactly in the complex scenarios that matter, and cannot reallocate as demand changes.
The gap. No approach combined an architecture whose resources scale and subdivide flexibly with a mapper that can place, move, and share multiple kernels at runtime — so CGRAs stayed hard to map, rigid, and underused.

How Neura works

From a rigid flat array to a hierarchical fabric that shares and migrates kernels

↓ →
new
↓ →
new
↓ →
new
↓ →
new
↓ →
new

The idea

Reorganize the fabric so it can flex to the workload instead of forcing the workload to fit. Neura’s first move is architectural: replace the rigid flat grid with a hierarchical spatial-temporal array that supports both spreading work across elements and time-multiplexing them, loosening the fixed granularity and memory-access constraints that made a conventional CGRA inflexible. Designing a reconfigurable accelerator whose organization can adapt to the shape and needs of different computations, rather than pinning every workload to one fixed dataflow, is the same idea the work on a flexible accelerator that supports multiple dataflows for sparse matrix multiplication (Flexagon) covered elsewhere on this site pursues, matching the hardware to the kernel instead of the reverse. Neura brings that adaptivity to the whole CGRA fabric and its mapping granularity.

Make the mapping smart about scale and movement, not just correct. Neura’s second move is a migration-aware mapping algorithm — a compiler pass that plans where each kernel goes while accounting for the possibility of moving it later, so mapping stays tractable as the array grows and placements can be reshuffled at runtime. Treating the compiler’s mapping and scheduling decisions as a first-class optimization that the hardware’s behavior depends on, rather than a fixed lowering step, is the same principle the work on learning a workload-aware co-optimization of the data format and the schedule (WACO) covered elsewhere on this site is built on, where getting the mapping right is what unlocks the hardware’s efficiency. Neura applies that mindset to placing and migrating kernels on a reconfigurable array.

Share one fabric among many kernels dynamically to keep it busy. Neura’s payoff is dynamic multi-kernel execution: allocating parts of the hierarchical array to different kernels at runtime and migrating kernels as demand changes, so the array serves several workloads at once and stays utilized. Managing one shared piece of hardware among multiple simultaneous, changing workloads — deciding on the fly who gets what and moving work to keep everything busy — is the same challenge the work on a dynamic scheduler for dynamic, real-time, multi-model workloads (DREAM) covered elsewhere on this site addresses, adapting the allocation as the mix of work shifts. Neura does this in space on a reconfigurable fabric, using migration to rebalance the array across kernels.

Following a multi-kernel workload through Neura

Placing, running, and migrating several kernels on one hierarchical CGRA

An illustration, drawn from the paper's description, of how Neura keeps a large array busy across multiple kernels. Internal mechanism details are the paper's.

Step 1 of 5

Several kernels arrive to run on one array

A realistic workload presents multiple compute kernels that should run on the same CGRA, potentially at overlapping times, rather than one kernel monopolizing the fabric.

This is the dynamic multi-kernel scenario conventional CGRAs barely support.

Why it works

Hierarchy keeps mapping tractable as the array grows. A flat array makes placement and routing explode with size → but organizing the fabric hierarchically and mapping within it → so the mapper can find good placements at a scale where a flat CGRA cannot.
Spatial-temporal flexibility relaxes the rigidity that wasted resources. Fixed granularity and restricted memory access force kernels into shapes that fit poorly → but supporting both spatial spreading and temporal time-multiplexing → so a kernel can be mapped in the form that suits it instead of wasting elements.
Migration-aware mapping turns a static placement into a movable one. A mapping pinned once cannot adapt when demand changes → but planning placements with migration in mind → so a running kernel can be relocated and the array rebalanced without remapping from scratch.
Dynamic multi-kernel sharing is what fills the fabric. One kernel rarely fills a large array, leaving most of it idle → but allocating regions to several kernels and running them simultaneously → so the extra hardware becomes parallel useful work instead of dead silicon.
Utilization, not raw size, is what raises throughput. Simply adding processing elements does nothing if they sit unused → but keeping the array busy across kernels through allocation and migration → so throughput rises 1.64 to 3.85 times over a same-scale conventional CGRA.

What it costs (trade-offs and scope)

A hierarchical spatial-temporal array is more complex than a flat one. Neura’s flexibility comes from a more elaborate architecture and interconnect than a uniform grid, which is additional design and hardware complexity that a simple flat CGRA avoids.
Migration-aware mapping and runtime migration add machinery. Planning placements for movement and actually migrating live kernels requires mapper support and runtime mechanism that a one-shot, single-kernel flow does not need, and migration itself has a cost.
The gains are largest in multi-kernel scenarios. Neura’s advantages — dynamic allocation and migration — pay off most when there are several kernels to share and rebalance; a single kernel that already fills the array benefits less from the multi-kernel machinery.
It is a framework and architecture, not a drop-in for existing CGRAs. The benefits rest on adopting Neura’s hierarchical architecture together with its mapper; they are not obtained by running the idea on a conventional flat CGRA unchanged.
Reported figures are the paper’s, across specific scenarios. The 1.64 to 3.85 times throughput improvement and higher utilization are measured against a conventional CGRA at the same scale across the paper’s chosen scenarios; the exact gains depend on the workloads, the baseline, and the array configuration.

The comparison

Handling a multi-kernel workload on a CGRA

Property	Conventional flat CGRA	Bigger flat CGRA	Neura
Array organization
Mapping at scale
Multiple kernels at once
Utilization
Throughput (same scale)

A comparison of ways to run a multi-kernel workload on a CGRA. By reorganizing the fabric hierarchically with spatial and temporal mapping and pairing it with a migration-aware mapper, Neura can dynamically allocate and migrate multiple kernels, reporting 1.64 to 3.85 times higher throughput and significantly higher utilization than a conventional CGRA at the same scale. Exact figures and mechanisms should be read from the paper.Underlined values explain themselves when clicked.

Where this stops working

What to keep in mind

This explainer is based on the paper’s abstract and public metadata, not its full text, which was not available at the time of writing. The high-level claims are the authors’: Neura is an open-source, unified framework for scalable CGRAs that addresses three named problems — mapping scalability, architectural limitations (rigid mapping granularity and restricted memory access), and dynamic multi-kernel support — by combining a hierarchical spatial-temporal CGRA architecture with a migration-aware mapping algorithm, which together enable dynamic resource allocation and kernel migration; the paper reports a throughput improvement of 1.64 to 3.85 times and significantly higher utilization over a conventional CGRA at the same scale. The background above on what a CGRA is (a grid of processing elements with a reconfigurable interconnect), on mapping a kernel as placing operations and routing data, and on spatial versus temporal mapping is standard reconfigurable-computing context provided to make the approach intuitive. The Flow, the step-by-step walkthrough, and the “Why it works” reasoning are illustrations built from the abstract’s description of the mechanism, not detailed accounts from the paper — the internal workings of the hierarchical architecture and the migration-aware mapper, and the full evaluation, should be read from the paper itself. Do not treat specific procedural details here as established beyond what the abstract states.

Background

Why reconfigurable accelerators live or die by their compiler and their sharing

It helps to place Neura in a longer line of work on reconfigurable acceleration. A CGRA offers a tempting deal — the efficiency of custom hardware with the reusability of a programmable fabric — but that deal has always been gated by two hard things: getting a compiler to map real programs onto the array well, and getting the array to be worth its area by keeping it busy. Much of the field’s progress is about designing the fabric and its toolchain together so that both hold: an architecture the compiler can actually target, and a way to fill the hardware with useful work. Neura is a clean instance of tackling both at once — it reshapes the architecture to be hierarchical and flexible so mapping stays tractable and granularity is not wasted, and it makes the mapper migration-aware so several kernels can share and move across the fabric to keep it utilized. That co-design of the reconfigurable array and the framework that realizes it onto silicon is the same terrain the work on a systematic framework for realizing heterogeneous CGRAs (REVAMP) covered elsewhere on this site occupies, treating the architecture and its generation toolchain as one problem. Neura’s particular contribution is to push that co-design toward scale and dynamic multi-kernel use — showing that a hierarchical fabric plus migration-aware mapping can turn a larger CGRA from harder-to-use into meaningfully faster and better-utilized at the same size.

If you remember only three things

1. A Coarse-Grained Reconfigurable Array (CGRA) is a grid of small processing elements wired by a reconfigurable network — an energy-efficient way to accelerate a program's hot loops without building fixed hardware. But CGRAs have stayed niche because they do not scale, for three linked reasons the paper names: mapping scalability (as the array grows, the compiler that places operations and routes data cannot find good mappings), architectural limitations (rigid mapping granularity and restricted memory access make the fabric inflexible), and dynamic multi-kernel support (running several kernels dynamically and simultaneously is barely explored). So simply building a bigger flat array makes it harder to program and leaves it underused.
2. Neura is an open-source, unified framework that attacks all three together with two co-designed pieces: a hierarchical spatial-temporal CGRA architecture — organizing the fabric in a hierarchy and supporting both spatial mapping (spreading work across elements) and temporal mapping (time-multiplexing elements) to relax the rigid granularity and keep mapping tractable — and a migration-aware mapping algorithm that plans placements knowing kernels may be moved. Together these uniquely enable dynamic resource allocation and kernel migration, so multiple kernels can run simultaneously, each given part of the array, with running kernels migrated as demand shifts to keep the fabric busy.
3. Across different scenarios, the paper reports Neura improves throughput by 1.64 to 3.85 times and achieves significantly higher utilization than a conventional CGRA at the same scale — turning extra hardware into extra useful work rather than idle silicon. The trade-offs: a hierarchical spatial-temporal fabric and a migration-aware mapper are more complex than a flat array and a one-shot single-kernel flow, the gains are largest in genuine multi-kernel scenarios, and the benefits require adopting Neura's architecture and framework rather than running the idea on a conventional CGRA unchanged. This explainer is based on the paper's abstract; exact mechanisms and full results should be confirmed in the paper.

Check yourself

Check your understanding

1. What are the three scalability problems that keep CGRAs from wider adoption, according to the paper?
2. What two co-designed pieces does Neura combine, and what do they together enable?
3. Why does dynamic multi-kernel support and migration matter for utilization?
4. What does Neura report achieving, and what are the limits of the claim in this explainer?

Sources

The paper is “Neura: A Unified Framework for Hierarchical and Adaptive CGRAs” by Cheng Tan, Miaomiao Jiang, Yuqi Sun, Ruihong Yin, Yanghui Ou, Qing Zhong, Lei Ju, and Jeff Zhang, published at ASPLOS 2026 (the 31st ACM International Conference on Architectural Support for Programming Languages and Operating Systems), DOI 10.1145/3779212.3790193.

This explainer is written from the paper’s abstract and public metadata; the full text was not available at the time of writing, so the page is marked a draft. As reported there, Neura is an open-source, unified framework for scalable CGRAs that addresses mapping scalability, architectural limitations (rigid mapping granularity and restricted memory access), and dynamic multi-kernel support by combining a hierarchical spatial-temporal CGRA architecture with a migration-aware mapping algorithm, which together enable dynamic resource allocation and kernel migration. The paper reports a throughput improvement of 1.64 to 3.85 times and significantly higher utilization over a conventional CGRA at the same scale. Background on CGRAs, on mapping as operation placement and data routing, and on spatial versus temporal mapping is standard reconfigurable-computing context. The specific numbers are the paper’s own; the internal mechanisms and full evaluation should be confirmed in the paper.