---
title: Adaptive Compute Acceleration Platforms (ACAPs)
url: https://www.emergentmind.com/topics/adaptive-compute-acceleration-platforms-acaps
type: topic
---

# Adaptive Compute Acceleration Platforms (ACAPs)

Searching arXiv for the cited ACAP-related papers to ground the article in the latest available preprints.
arXiv search results located for Versal ACAP, AI Engine, and ACAP accelerator frameworks, including works on CNNs, Transformers, GNNs, communication-avoiding algorithms, and precision-adaptive accelerators.
Adaptive Compute Acceleration Platforms (ACAPs) are a heterogeneous class of reconfigurable systems that extend classical LUT/DSP-centric FPGAs and SoC FPGAs with a third accelerator domain oriented toward AI workloads. In the Versal family, this domain is centered on AI Engines (AIEs or AIE-ML), and is integrated with programmable logic (PL), processing subsystems (PS), high-throughput on-chip interconnects, and multi-level memory. Across recent studies, ACAPs are characterized by deterministic streaming dataflow, mixed-precision support, hardware/software co-design, and workload-specific partitioning across AIE, PL, and PS. They have been used for CNN inference, Transformer acceleration, GNN processing, arbitrary-precision integer arithmetic, communication-avoiding kernels, and precision-adaptive edge AI, with the exact balance between programmability, specialization, and efficiency depending on the architecture and runtime model [2509.04153][2409.09689][2506.08785].

## 1. Architectural model and defining features

ACAPs are presented in the literature as a distinct tier in the FPGA landscape. A survey of FPGA-based CNN systems describes them as “the newest tier in the FPGA landscape,” adding “a third, hard-accelerator domain specifically tuned for AI” beyond programmable logic and SoC-style processing subsystems [2509.04153]. In AMD Versal devices, this domain is implemented through SIMD VLIW AI Engines, while PL supplies custom dataflow IP and PS supplies orchestration, I/O, and control.

A recurring architectural decomposition is the triad of **AIE + PL + PS**, tied together by an on-chip NoC. CAT, a Transformer framework on Versal ACAP, describes an ACAP as integrating “a high-throughput AI Engine array of tiles, a rich Programmable Logic (PL) fabric, and a general-purpose Processing System (PS), all tied together by an on-chip Network-on-Chip (NoC) and fed by external memory” [2409.09689]. AIM frames the same structure as “Scalar Engines,” “AI Engines,” and “Programmable Logic,” emphasizing that heterogeneity enables an explicit partition of dense arithmetic, streaming and reduction logic, and host control [2309.12275].

The AI Engine array is the architectural feature most often used to distinguish ACAPs from both GPUs and traditional FPGAs. Surveyed Versal devices expose vector registers over native types including `int8/16/32`, `uint8/16/32`, `BF16`, `FP16`, and complex integer and floating-point types, with group widths of `128/256/512/1024 bits per cycle` [2509.04153]. CAT reports AIE local Windows, dedicated DMA engines, PLIO streams, and graph-based programming support, while DPUV4E describes first-generation AIE tiles as SIMD VLIW cores with `32 KB` local scratchpad memory per tile, two load units, one store unit, and support for cascade streams that move partial sums “in flight” [2409.09689][2506.11441].

This heterogeneous organization is not merely additive. The literature repeatedly treats ACAPs as platforms in which the performance-critical question is **where** an operation runs and **how** data is staged between engines. A common misconception is that ACAPs are simply FPGAs with extra fixed-function AI blocks. The more precise view in the literature is that they are programmable heterogeneous systems whose efficiency depends on compiler scheduling, tile placement, stream topology, and memory orchestration rather than on AI Engine peak throughput alone [2407.05621][2605.17683].

## 2. Interconnect, memory hierarchy, and deterministic dataflow

ACAP research places unusual emphasis on on-chip communication. The survey paper attributes ACAP suitability for edge vision to “tight latency bounds for batch‑1 pipelines,” enabled by the cascade-stream interface and compile-time scheduling across AIE tiles and DPU blocks [2509.04153]. In that account, AIE tiles include local SRAM, a cascade-stream interface for deterministic partial-sum movement, and programmable AXI4-Stream interconnect for non-adjacent communication, while the global NoC links the AIE array, PL, PS, DDR, PCIe, GTY transceivers, and, in some variants, HBM.

Several papers quantify this communication hierarchy at fine granularity. μ-ORCA, which targets microsecond-scale inference on Versal VEK280, distinguishes three datapaths: a `512 bits/cycle` cascade FIFO, a `256 bits/cycle` adjacent shared local memory connection, and `32 bits/cycle` DMA/PLIO channels via the NoC [2605.17683]. Its core argument is that for small layers, the standard layerwise cycle of compute, DMA, synchronization, and re-launch can make communication and fixed overheads comparable to or larger than computation. It therefore forwards inter-layer activations directly across AIE tiles by cascade, bypassing shared memory tiles and PL for intermediates.

Memory hierarchy is correspondingly central. DPUV4E identifies off-chip DDR bandwidth as the limiting factor on Versal VCK5000, reporting `≈102.4 GB/s` DDR4-DIMM bandwidth against aggregate PL↔AIE bandwidths of `≈1.3 TB/s` from PL to AIE and `≈1.0 TB/s` from AIE to PL, but noting that this on-chip bandwidth is shared among hundreds of AIEs and constrained by interface topology [2506.11441]. H-GCN makes a similar point in a GNN context, preferring PL-side data movement because “theoretical PL–AIE bandwidth can reach `1.3 TB/s`, whereas AIE–NoC bandwidth is only around `12 GB/s`” [2206.13734].

The consequence is that ACAP performance is often governed by arithmetic intensity and data reuse rather than raw MAC count. The survey paper states this explicitly with the proxy $I=\mathrm{FLOPs}/\mathrm{bytes\ moved}$, and ties ACAP efficiency to keeping multi-scale feature maps, shared weights, and activation FIFOs on chip [2509.04153]. EA4RCA generalizes the same idea for communication-avoiding algorithms, arguing that batched DMA transfers and stream aggregation decouple communication from compute and raise effective AIE utilization [2407.05621].

## 3. Workload mapping across AIE, PL, and PS

ACAPs are used across a wide workload spectrum, but the mapping pattern is strikingly consistent: matrix-heavy regular kernels go to AIE, memory-bound or irregular kernels go to PL, and scheduling, I/O, and host interaction go to PS.

For CNNs, the survey describes MAC-heavy layers such as convolution, depthwise convolution, pointwise convolution, and GEMM as natural fits for AIE tiles; PL implements custom dataflows, DPU overlays, pre/post-processing, and fusion logic; PS handles scheduling and control-heavy tasks such as DMA setup and, when not offloaded, NMS [2509.04153]. DPUV4E refines this mapping into two AIE-based PE types: a Conv PE for regular convolution and GEMM-like layers, and a DWC PE for depthwise and pointwise convolutions. It further moves activation, elementwise operations, and pooling into AIE “ACC/NL” cores to reduce PL DSP pressure [2506.11441].

For Transformers, CAT decomposes each layer into an Encoder/Decoder Processing Unit with serial Multi-Head Attention and Feed-Forward stages. Large and moderate-sized matrix multiplications are executed on AIE MM processing units, while nonlinear operators such as Softmax, LayerNorm, and GELU, as well as send/receive functions and stage controllers, are placed in PL near buffers [2409.09689]. CAT’s central design move is to aggregate Q/K/V linear projections across heads so that AIE executes larger matmuls, improving utilization and PLIO reuse relative to naively head-split kernels.

For GNNs, H-GCN uses graph heterogeneity as the placement criterion. It partitions reordered graphs into three density regimes: tightly clustered regions with density `> 50%`, loosely clustered regions with `1% < density ≤ 50%`, and scattered nodes with density `≤ 1%`. These are then mapped to dense AIE systolic tensor arrays, sparse AIE systolic tensor arrays, and PL SpMM engines respectively [2206.13734]. This is an explicit example of ACAP heterogeneity being exploited by data characteristics rather than by operator type alone.

The same architectural pattern appears beyond neural networks. AIM maps arbitrary-precision integer multiplication onto Versal ACAP by running vectorized `31-bit`-limb multiply-accumulate on AIE tiles, using cascade streams for row-wise accumulator forwarding, and implementing carry propagation and stream orchestration in PL [2309.12275]. EA4RCA, targeting regular communication-avoiding kernels such as Filter2D, MM, and FFT, organizes AIE “processing structures” and PL “data engines” so that task decomposition, aggregation, and stream servicing happen in PL while vector kernels execute in AIE [2407.05621].

This breadth suggests that ACAPs are not specialized for a single operator family. A more accurate characterization is that they favor workloads whose compute kernels can be regularized into vectorized tile computations and whose communication patterns can be made predictable enough for explicit scheduling.

## 4. Precision adaptation, arithmetic formats, and runtime reconfiguration

One line of recent work extends ACAP principles from spatial mapping to arithmetic reconfiguration. POLARON presents a “precision-aware, runtime-reconfigurable edge-AI accelerator” built around PARV-CE, a SIMD-enabled multiprecision MAC engine that supports `Var-FxP4/8/16`, `FP8 (E5M2, E4M3)`, `FP16 (E5M10, E6M9)`, `BF16`, and `Posit-8/16` in a unified datapath [2506.08785]. Its five-stage pipeline performs input pre-processing, runtime-adaptive SIMD multiplication, two-stage accumulation, and normalization and formatting with a Leading-Zero Anticipator and `RoundTowardPositive` rounding.

The ACAP relevance of POLARON lies in how it operationalizes runtime adaptability. The same multiplier fabric and CSA trees are time- and space-shared across formats, while mode-dependent front-end unpacking and back-end normalization are reconfigured at run time. The SIMD width scales with precision, delivering “up to `16×` throughput for Var-FxP4 and FP8; `4×` for Var-FxP8, Posit-8, BF16; `1×` for Var-FxP16, Posit-16, FP16,” which the paper explicitly identifies as ACAP-like adaptivity, heterogeneity, and reconfigurability [2506.08785].

Its precision policy is layer-adaptive. For layer $l$, the low-precision sensitivity is defined as
$$
S(l)=s_l=\max_k s_{l,\mathrm{sc},k},
$$
and precision assignment chooses
$$
p(l)\in\{4,8,16,\mathrm{FP8},\mathrm{FP16},\mathrm{BF16},\mathrm{Posit\text{-}8},\mathrm{Posit\text{-}16}\}
$$
to minimize layerwise energy subject to an accuracy constraint
$$
\mathrm{Acc}(\{p(l)\}) \ge \mathrm{Acc}_{\mathrm{FP32}}-\delta,
$$
with $\delta \approx 1.8\%$ as the empirically observed accuracy loss bound [2506.08785]. WILD-QLite and PACT are used to support quantization-aware execution, and metadata emitted by the runtime configures per-layer precision, scaling parameters, saturation bounds, and activation selection.

This precision-adaptive direction complements the mixed-precision perspective in the ACAP survey, which emphasizes INT8, FP16/BF16, and sparsity support in deployed Versal systems [2509.04153]. A plausible implication is that ACAP adaptivity is increasingly understood not only as spatial reconfiguration across engines, but also as runtime control over number systems, vector widths, and accumulation modes.

## 5. Programmability, toolchains, and hardware/software co-design

ACAP usability depends heavily on toolchains. The survey identifies Vitis AI, Vitis HLS, Vivado, the AI Engine API, graph compilers, and FINN as the main software layers for Versal-class deployment [2509.04153]. A typical CNN flow begins with TensorFlow, PyTorch, or ONNX models, quantizes to INT8 through Vitis AI, compiles to `.xmodel`, and runs through VART/XRT on embedded DPUs and AIE kernels. The same survey notes an important limitation: Vitis AI currently expects `FP32` inputs for quantization and unsupported operators may require substitutions, exemplified by `SiLU → Leaky ReLU` for YOLOv5 on Versal.

Research frameworks often add a layer-specific design-space exploration and code generation system on top of this vendor stack. CAT uses `aiecompiler`, `v++`, `aiesimulator`, Vitis Analyzer, XRT, and an internal graph code generator that emits AIE MM kernels of different shapes and maps them onto AIE tiles under PLIO and window-capacity constraints [2409.09689]. EA4RCA provides an “AIE Graph Code Generator” that takes a graph configuration file and emits a compile-ready AIE project, instantiating DAC, CC, and DCC components and integrating them with Xilinx backend tools [2407.05621]. AIM similarly includes DSE and automatic code generation for AIE kernels, AIE graph mappings, PL modules, and ARM host code [2309.12275].

At the runtime level, multiple studies emphasize prefetching, double buffering, and explicit metadata-driven reconfiguration. POLARON uses AXI-Lite for mode/configuration writes, AXI-DMA/Stream for tensors, and a runtime control engine whose metadata configures PARV-CE without stalling the pipeline at layer boundaries [2506.08785]. μ-ORCA exposes a DSE that chooses layer mappings, placements, and cascade enablement to minimize end-to-end latency under AIE tile, PLIO, and topology constraints, with ingress and egress handled by PLIO and inter-layer communication kept inside the AIE array when possible [2605.17683].

The literature therefore treats programmability on ACAPs as a co-design problem rather than a pure compiler problem. Model structure, tile geometry, buffer sizes, PLIO availability, NoC routing, operator support, and quantization policy all enter the effective programming model.

## 6. Performance record, misconceptions, and open problems

Reported performance spans multiple domains and should be interpreted in context rather than as a single ACAP-wide benchmark.

| System and workload | Reported result | Paper |
|---|---|---|
| Versal VCK190, YOLOv5 on RarePlanes `640×640` | `244.49 FPS` with `F1 score 0.852` after substituting `SiLU` with `Leaky ReLU` | [2509.04153] |
| VCK5000, BERT-Base EDPU | `35.194 TOPS`, `0.118 ms` latency per layer, `520.968 GOPS/W` | [2409.09689] |
| VEK280, 6-layer real-world DeepSets | `0.93 μs` end-to-end latency | [2605.17683] |
| VC1902, ResNet50 | `4569 FPS` for DPUV4E `8PE` | [2506.11441] |
| VCK5000, Reddit GCN inference | `T=4.18E4 μs`, `E=2.46E2 graphs/kJ` | [2206.13734] |
| Virtex-7 / 28 nm evaluations of POLARON | up to `2×` PDP improvement, `3×` reduction in resource usage, accuracy generally within `<1.8%` of FP32 baseline | [2506.08785] |

These numbers support several recurring conclusions. First, ACAPs can deliver strong throughput and energy efficiency when the workload is sufficiently regular for AIE vectorization and the dataflow is engineered to maximize on-chip reuse. CAT reports throughput gains of `2.41×`, `49.50×`, and `1.32×` over Nvidia A10G, AMD ZCU102, and a Versal VC190 baseline respectively, with energy-efficiency gains of `7.80×`, `6.19×`, and `1.15×` [2409.09689]. AIM reports up to `12.6×` energy-efficiency gain over a Xeon Ice Lake CPU and `2.1×` over an Nvidia A5000 GPU for large integer multiplication [2309.12275].

Second, a common misconception is that ACAP performance is compute-bound by default because AI Engines expose high nominal TOPS. Multiple papers argue the opposite. DPUV4E identifies insufficient memory bandwidth as the factor preventing full AIE utilization on Versal [2506.11441]. μ-ORCA shows that for small layers, synchronization, DMA setup, and VLIW prologue/epilogue become first-order terms [2605.17683]. H-GCN shows that density-aware placement is decisive: PL SpMM is faster than AIE SpMM below `1%` density, while dense AIE kernels become preferable above roughly `50%` density [2206.13734].

Third, ACAP deployment still involves substantive constraints. The survey notes toolchain maturity issues and operator compatibility limits; unsupported ops may require architectural substitutions [2509.04153]. CAT highlights buffer-capacity limits, PLIO service constraints, and padding overhead when sequence length is not a multiple of the AIE block size [2409.09689]. μ-ORCA is limited by one-input/one-output cascade ports and east/south-only cascade connections, which restrict arbitrary inter-layer graphs [2605.17683]. POLARON identifies unified-datapath trade-offs such as area overhead for broad-format support, control complexity for posit encode/decode, and possible accuracy cliffs if the sensitivity metric underestimates layer importance [2506.08785].

Future directions in the cited literature are correspondingly pragmatic. They include broader sparsity support, native handling of Transformer-style contractions, automated mixed-precision mapping, partial reconfiguration, HBM-backed scaling, finer-grained intra-layer precision control, and runtime telemetry for adaptive throttling [2509.04153][2506.08785]. Taken together, these suggest that ACAP research is moving from proof-of-concept accelerator kernels toward integrated systems in which dataflow, precision policy, and compiler/runtime orchestration are co-optimized around the heterogeneous substrate.

Source: https://www.emergentmind.com/topics/adaptive-compute-acceleration-platforms-acaps