Dataflow & Tiling Strategies in Edge-AI FPGA Accelerators: A Comprehensive Literature Review

In plain words

Running a neural network on a small, power-limited device is hard. An FPGA is a chip whose circuits you can wire into a custom design, so you can build a machine that does exactly the network's arithmetic. Two design choices decide how fast and how efficient that machine is. The first is the order in which numbers are moved and reused on the chip, the dataflow. The second is how big chunks of the data are cut so that they fit in the small memories on the chip, the tiling.

This paper is a survey of those two choices. It explains four common dataflow styles and two tools that estimate how a design will behave before it is built. It then describes how to cut the data and unroll loops, and it looks at four existing FPGA accelerators to see how they combine these choices. It ends with the trade-offs between writing the design in high-level synthesis, in a domain-specific language or by hand in hardware description code.

TL;DR

This is a literature review, not a new method. Use it to learn the vocabulary and trade-offs of FPGA dataflow and tiling for edge DNN inference. It fixes one terminology for four dataflow styles and gives a worked analytical example for a single ResNet-50 convolution layer §III. Every number in the card comes from the cited works, not from new experiments. Design-effort ratios in §VI have no source.

Problem

Deep networks need more on-chip memory and bandwidth than a small FPGA provides, so the data must be moved in pieces. The survey frames the design space as two questions. Which operands stay on chip and are reused, which is the dataflow §I §II? How are large tensors partitioned so each piece fits in the on-chip memories, which is the tiling §I §IV? The paper assumes the target is an edge device with tight power and resource budgets §I.

Method

The paper is a survey. Its content is organised as follows. Section numbers follow the rendered IEEEtran layout (Roman numerals for sections, letters for subsections) and were counted from the LaTeX source, not checked against a PDF. Figures are numbered in source order fig. 1 to fig. 4. The algorithms are numbered in source order alg. 1 to alg. 6. The paper has no numbered equations.

1. Dataflow taxonomy §II. Four styles are defined, each with a short algorithm, a diagram and an example design:

   • Weight-Stationary (WS) §II.A fig. 1 alg. 1. Each processing element (PE) keeps its filter weights locally, and activations and partial sums stream past them. The weights are reused across the spatial positions.
   • Output-Stationary (OS) §II.B fig. 2 alg. 2. Partial sums for an output element stay in local registers until all input channels are accumulated, then the result is written out.
   • Row-Stationary (RS) §II.C fig. 3 alg. 3. A row (strip) of activations and partial sums stays on each PE, so filters can be reused across the row. The paper credits Eyeriss with this style.
   • No-Local-Reuse (NLR) §II.D fig. 4 alg. 4. PEs keep almost no local state, and every operand is read from a large shared buffer or HBM. This simplifies control and raises buffer bandwidth demand.

2. Analytical frameworks §III. MAESTRO and Timeloop both explore loop order, tiling factors and reuse to estimate cycles, energy and buffer use without building hardware tab. 1. They differ in how the mapping is given: MAESTRO takes a data-centric description with explicit reuse directives and needs the user to provide tiling factors, while Timeloop enumerates loop nests and searches for tilings itself tab. 1. The paper's comparison table is summarised in the Results section below.

3. Two-level tiling §IV.A. Outer tiles stay in DRAM or HBM, and inner tiles stay in BRAM or LUTRAM. Each inner tile is fully processed before the next is fetched. The paper gives three sizing rules: the tile must fit the on-chip buffer, its dimensions should match the number of parallel multipliers, and it should be large enough that the transfer cost is amortised.

4. Loop unrolling and pipelining §IV.B alg. 5. Unrolling duplicates hardware for inner-loop iterations, so throughput grows with the unroll factor until LUT or DSP resources run out. Pipelining aims at an initiation interval of one, meaning a new iteration starts every cycle. The paper states that the interval goes from above one to one when dependencies are resolved, and that memory partitioning and tree-shaped accumulation help. This is shown as an unnumbered relation, II(naive) > 1 becomes II(optimised) = 1 §IV.B.

5. Buffer hierarchy and double buffering §IV.C alg. 6. The paper lists four on-chip tiers: registers and LUTRAM, BRAM, UltraRAM and HBM §IV.C. Double buffering fetches tile n+1 into a spare buffer while tile n is being computed, which hides memory latency.

   PseudocodeCopy

   # Double-buffering loop  [alg. 6]
   # The paper's loop has no stop condition and no initial fill step.
   
   def double_buffer_flow():
       # Repeat; the paper gives no stop condition  [alg. 6, line 1]
       while True:
           # Fetch the next tile into the spare buffer  [alg. 6, line 2]
           load_into(buffer_b, tile_n_plus_1)
           # Compute the current tile from the active buffer  [alg. 6, line 3]
           compute(buffer_a)
           # Swap the roles of the two buffers  [alg. 6, line 4]
           buffer_a, buffer_b = buffer_b, buffer_a

6. Multi-level tiling §IV.D. The paper extends the two-level scheme to three or more tiers, for example HBM for the outermost tile, URAM or BRAM for intermediate tiles and registers or LUTRAM for the innermost sub-tile. It names Versal and Alveo U280 as devices where this matters §IV.D. No algorithm is given.

7. Case studies §V. Four designs are described in words, each with a small diagram in the source:

   • FINN §V.A: binarised networks as a streaming pipeline. Weights stay in LUT arrays and 1-bit activations slide through a window. The paper calls this weight-stationary.
   • FINN-R §V.B: generalises FINN to 2 to 8-bit quantised networks, with an automated flow that picks unroll and tiling parameters from throughput and resource goals. The paper calls the dataflow streaming with partial weight-stationary blocks.
   • FlightLLM §V.C: transformers on an Alveo U280 with HBM and sparse DSP chains. Zero weights are skipped, and the dataflow is described as partly output-stationary, combined with weight streaming from HBM.
   • SSR §V.D: a spatial-sequential hybrid on Versal ACAP. Transformer layers are split across several accelerators, with AI engines for matrix multiply and programmable logic for normalisation and activations. The paper calls the dataflow row-stationary inside each AIE cluster.

8. Design automation §VI. HLS, DSL and hand-written RTL are compared on code size, compile time, productivity and resource overhead tab. 3. A callout box summarises the trade-off and suggests that future flows combine a DSL for the coarse architecture with hand-tuned kernels §VI.

9. Future directions §VII. Three directions are named: switching dataflow between layers, partial reconfiguration of the fabric per layer, and domain-specific compilers built on MAESTRO and Timeloop §VII.

# Weight-stationary dataflow  [alg. 1]
# Input:  activation tiles; one weight per PE
# Output: one partial-sum result per PE

def weight_stationary(tiles, weights):
    # Visit each tile of input activations  [alg. 1, line 1]
    for tile in tiles:
        # Load the tile into a local buffer  [alg. 1, line 2]
        local_buffer = load(tile)
        # Each PE accumulates weight x activation over the tile  [alg. 1, lines 3-9]
        for pe in array:
            partial_sum = 0
            for element in local_buffer:
                partial_sum += weights[pe] * element
            # Write the PE's result  [alg. 1, line 9]
            output[pe] = partial_sum
    return output

Hyperparameters

The survey has no training. The numbers below are the parameters the paper uses for its examples, all of them stated in the text or tables.

Results

Author-reported. This survey runs no experiments. The rows below are quoted from the cited works as the survey presents them.

Analytical case study §III: a 3×3 convolution layer on the hypothetical 256-PE accelerator above, WS dataflow.

The Timeloop row for mapping exploration cites Sparseloop, not Timeloop (see Pitfalls).

Feature comparison of the two tools tab. 1, in the survey's categories:

Source: tab. 1, which cites the tools' own papers in each cell.

Four case-study accelerators tab. 2, quoted as the survey tabulates them. Units differ between rows: FINN counts binary operations, the others count TOPS or GOPS at other precisions.

Source: tab. 2. The paper gives no per-cell citations beyond the accelerator name.

Design automation tab. 3. Qualitative ranges; the table has no source.

The callout box §VI restates a design-time reduction of about 5× against RTL, at about 30% more LUT use, with no source given.

Paper vs code

No official code. The paper is a literature review and links no repository. Checks: the arXiv metadata and LaTeX source carry no code link [raw/src/2505.08992/IEEE_draft.tex]; a GitHub repository search for the author name with FPGA dataflow returned no results.

Pitfalls

• No new experiments. Every figure is quoted from another paper or tool. Use the original works for any number you act on, and check the units, which are not consistent across the rows of tab. 2.
• Citation mismatches to verify. The Timeloop mapping claim of "weight-stationary energy-optimal, up to 11× variance" is cited to Sparseloop §III. The MAESTRO row "integration into DSE loops" in tab. 1 is cited to Accelergy. The sources may still support the claims, but the source list does not show it.
• Internal inconsistency on Eyeriss. Row-stationary is attributed to Eyeriss §II.C, but Eyeriss v1 is also described as using an output-stationary-like scheme for many conv layers §II.B.
• Dataflow labels for case studies are the survey's own. FlightLLM as "partly output-stationary", and SSR as "row-stationary inside each AIE cluster" §V, are not backed by a cited source in the text. Treat them as the survey's reading, not as the designs' documented dataflow.
• WS pseudocode is a sketch. alg. 1 writes the output of each PE over every tile, so later tiles overwrite earlier results. The paper does not say how partial results from different tiles combine. Also, the weight-stationary reuse described in words §II.A is not visible in the loop structure. Check against the cited FINN or Eyeriss work before implementing.
• RS pseudocode is incomplete. alg. 3 contains a placeholder line "(e.g., update filter chunk or control)" and does not define the filter chunk loop.
• Double-buffer loop has no stop, no prologue. alg. 6 is an unbounded loop. A real implementation must fill the first buffer before the loop starts and handle the last tile; the paper shows neither.
• Unroll "algorithm" is a pragma. alg. 5 is an HLS directive applied to a loop, not a sequence of operations. Its effect depends on the tool and the resources.
• Tile-size and resource rules are heuristics. The three sizing rules §IV.A and the II-to-1 relation §IV.B have no quantitative threshold and no source. Assume they hold only when the stated conditions do.
• Design-effort numbers are unsourced. tab. 3 and the callout box §VI give ratios with no reference. Do not use them as evidence in a decision.
• Reported FINN throughput is not in the table. The text gives "10k+ fps on CIFAR-10" §V.A with no source and no setup; the table does not repeat it.
• Author name differs between sources. The arXiv metadata used for this card lists "Richie Li". The LaTeX author block lists "Zhaoqin Li" with the same institution. The card uses the arXiv name, as the metadata does. Check the published PDF before citing the author.
• Figures are described only by reference. fig. 1 to fig. 4 are diagrams of the four dataflows. This card does not reproduce them and does not describe their content beyond the labels.

Lineage

• Builds on: the dataflow vocabulary of Eyeriss [Chen2016] for row-stationary, and the FINN and FINN-R frameworks [Umuroglu2017, Blott2018] for binarised and quantised streaming designs. The paper cites Kwon et al. for the dataflow definition §II.
• Analytical tools compared: MAESTRO [Kwon2020] and Timeloop [Parashar2019timeloop], with Accelergy [Wu2019] and Sparseloop [Wu2021] as extensions.
• Case studies: FlightLLM [Zeng2024] and SSR [Zhuang2024] are the survey's examples for transformer inference.
• Superseded by: not stated.