Adaptive Compute Acceleration Platforms (ACAPs)

• Adaptive Compute Acceleration Platforms (ACAPs) are heterogeneous systems combining AI Engines, programmable logic, and processing subsystems specifically designed to accelerate AI workloads.
• They leverage deterministic streaming dataflow, mixed-precision support, and hardware/software co-design to optimize performance and energy efficiency.
• ACAPs enable precise workload mapping and runtime reconfiguration, addressing challenges like bandwidth limitations and architectural constraints across CNNs, Transformers, and GNNs.

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 (Sali et al., 4 Sep 2025, Zhang et al., 2024, Lokhande et al., 10 Jun 2025).

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 (Sali et al., 4 Sep 2025). 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” (Zhang et al., 2024). 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 (Yang et al., 2023).

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 (Sali et al., 4 Sep 2025). 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” (Zhang et al., 2024, Li et al., 13 Jun 2025).

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 (Zhang et al., 2024, Ji et al., 17 May 2026).

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 (Sali et al., 4 Sep 2025). 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 (Ji et al., 17 May 2026). 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 (Li et al., 13 Jun 2025). 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” (Zhang et al., 2022).

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 (Sali et al., 4 Sep 2025). 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 (Zhang et al., 2024).

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 (Sali et al., 4 Sep 2025). 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 (Li et al., 13 Jun 2025).

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 (Zhang et al., 2024). 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 (Zhang et al., 2022). 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 (Yang et al., 2023). 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 (Zhang et al., 2024).

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 (Lokhande et al., 10 Jun 2025). 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 (Lokhande et al., 10 Jun 2025).

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 (Lokhande et al., 10 Jun 2025). 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 (Sali et al., 4 Sep 2025). 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 (Sali et al., 4 Sep 2025). 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 (Zhang et al., 2024). 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 (Zhang et al., 2024). AIM similarly includes DSE and automatic code generation for AIE kernels, AIE graph mappings, PL modules, and ARM host code (Yang et al., 2023).

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 (Lokhande et al., 10 Jun 2025). μ-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 (Ji et al., 17 May 2026).

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	(Sali et al., 4 Sep 2025)
VCK5000, BERT-Base EDPU	35.194 TOPS, 0.118 ms latency per layer, 520.968 GOPS/W	(Zhang et al., 2024)
VEK280, 6-layer real-world DeepSets	0.93 μs end-to-end latency	(Ji et al., 17 May 2026)
VC1902, ResNet50	4569 FPS for DPUV4E 8PE	(Li et al., 13 Jun 2025)
VCK5000, Reddit GCN inference	T=4.18E4 μs, E=2.46E2 graphs/kJ	(Zhang et al., 2022)
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	(Lokhande et al., 10 Jun 2025)

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× (Zhang et al., 2024). 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 (Yang et al., 2023).

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 (Li et al., 13 Jun 2025). μ-ORCA shows that for small layers, synchronization, DMA setup, and VLIW prologue/epilogue become first-order terms (Ji et al., 17 May 2026). 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 (Zhang et al., 2022).

Third, ACAP deployment still involves substantive constraints. The survey notes toolchain maturity issues and operator compatibility limits; unsupported ops may require architectural substitutions (Sali et al., 4 Sep 2025). CAT highlights buffer-capacity limits, PLIO service constraints, and padding overhead when sequence length is not a multiple of the AIE block size (Zhang et al., 2024). μ-ORCA is limited by one-input/one-output cascade ports and east/south-only cascade connections, which restrict arbitrary inter-layer graphs (Ji et al., 17 May 2026). 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 (Lokhande et al., 10 Jun 2025).

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 (Sali et al., 4 Sep 2025, Lokhande et al., 10 Jun 2025). 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.