---
kind: concept
slug: dataflow-mapping
title: Dataflow mapping
summary: >-
  Deciding which operands stay on chip and get reused, and in what order work runs, in a DNN accelerator. Four dataflow styles (weight-, output-, row-stationary, no-local-reuse) trade control simplicity against buffer bandwidth. MAESTRO and Timeloop estimate a mapping before hardware exists. The only source is one FPGA survey that quotes numbers from other works.
tags: [fpga, dataflow, dnn-accelerator, edge-ai, hardware]
papers: ["2505.08992"]
related: [arithmetic-intensity, low-precision-arithmetic, hardware-aware-training]
status: draft
updated_at: 2026-10-25
---

## Overview

A DNN accelerator has far less on-chip memory than a network has data, so
operands must be moved in pieces. Dataflow mapping is the choice of which
operand stays put in a local buffer and gets reused, and in what loop order
the work runs [arxiv:2505.08992 §I] [arxiv:2505.08992 §II]. The invariant
every variant shares is that the computed result does not change; only the
movement of weights, activations and partial sums does. The survey frames the
design space as two questions: which operands are reused on chip (dataflow),
and how large tensors are cut to fit the on-chip memories (tiling)
[arxiv:2505.08992 §I].

## Variants

### Weight-stationary

Each processing element (PE) keeps its filter weights locally, while input
activations and partial sums stream past. The weights are reused across the
spatial positions of the output [arxiv:2505.08992 §II.A]. The survey's
analytical example uses this style for both of its tools [arxiv:2505.08992 §III].
Card: [Dataflow & Tiling Strategies in Edge-AI FPGA Accelerators](/papers/2505.08992).

### Output-stationary

Partial sums for one output element stay in local registers until every input
channel has been accumulated. The finished result is then written out
[arxiv:2505.08992 §II.B]. The survey gives no quantitative comparison of this
style with the others.

### Row-stationary

A row (strip) of activations and partial sums stays on each PE, so filter
weights can be reused across that row [arxiv:2505.08992 §II.C]. The survey
credits Eyeriss with this style. Its own text also describes Eyeriss v1 as
output-stationary-like for many convolution layers, see
[Contradictions](#contradictions).

### No-local-reuse

PEs keep almost no local state. Every operand is read from a large shared
buffer or from off-chip memory. The paper says this simplifies control but
raises the bandwidth demand on that buffer [arxiv:2505.08992 §II.D].

### Analytical frameworks

Two tools estimate cycles, energy and buffer use for a given mapping without
building hardware. MAESTRO takes a data-centric description with reuse
directives, and the user supplies the tiling factors. Timeloop enumerates loop
nests and searches for tilings itself [arxiv:2505.08992 tab. 1]. The survey's
single worked case, a 3×3 convolution with 64 input and 64 output channels on a
hypothetical 256-PE array, reports reuse, traffic and energy figures from both
tools [arxiv:2505.08992 §III]. The two tools disagree on the cycle count, about
5×10⁵ for MAESTRO against about 4.5×10⁵ for Timeloop, and the survey does not
explain the gap [arxiv:2505.08992 §III].

### Reported case-study designs

The survey describes four FPGA accelerators and the dataflow each one uses,
in its own words [arxiv:2505.08992 §V]:

- **FINN**: binarised networks as a streaming pipeline, with weights held in
  LUT arrays [arxiv:2505.08992 §V.A]. [Card](/papers/2505.08992).
- **FINN-R**: extends FINN to 2 to 8-bit quantised networks, with an automated
  flow that picks unroll and tiling parameters [arxiv:2505.08992 §V.B].
- **FlightLLM**: transformers on an Alveo U280 with HBM and sparse DSP chains,
  skipping zero weights [arxiv:2505.08992 §V.C].
- **SSR**: a spatial-sequential hybrid on Versal ACAP, with transformer layers
  split across accelerators [arxiv:2505.08992 §V.D].

The survey's throughput and efficiency figures for these designs are quoted
from the original works, and the units differ by row [arxiv:2505.08992 tab. 2].
Use the original papers before acting on any of them.

## When to use which

The survey gives trade-offs, not a decision rule. Each row below is what the
cited text supports.

| Situation | Use | Why |
|---|---|---|
| You want the simplest control logic and can afford high buffer bandwidth | No-local-reuse | Simpler control, higher buffer demand [arxiv:2505.08992 §II.D] |
| Weights are reused across many spatial positions | Weight-stationary | Weights stay in the PE [arxiv:2505.08992 §II.A] |
| Result must be accumulated over all input channels before it is written | Output-stationary | Partial sums stay in local registers until done [arxiv:2505.08992 §II.B] |
| Filter reuse across a row matters most | Row-stationary | Filters reused along the row [arxiv:2505.08992 §II.C] |
| You want to specify tiling factors yourself | MAESTRO-style analysis | The user supplies tiling [arxiv:2505.08992 tab. 1] |
| You want the tool to search the mapping space | Timeloop-style analysis | Mapper finds tilings [arxiv:2505.08992 tab. 1] |
| Binarised network on a small FPGA | FINN-style streaming | Weights on chip, 1-bit activations [arxiv:2505.08992 §V.A] |
| Quantised 2 to 8-bit network, want automated unroll and tiling | FINN-R-style flow | Automated parameter choice [arxiv:2505.08992 §V.B] |

Tile sizing has three rules in the survey: the tile must fit the on-chip
buffer, its dimensions should match the number of parallel multipliers, and it
should be large enough to amortise transfer cost [arxiv:2505.08992 §IV.A]. The
survey gives no numeric threshold for any of them. Treat them as heuristics.

For the implementation language, the survey compares HLS, a domain-specific
language and hand-written RTL on code size, compile time, productivity and
resource overhead [arxiv:2505.08992 tab. 3]. Those cells carry no source and are
qualitative. Do not use them as evidence in a decision.

## Implementation sketch

The common core is a tiled loop: outer tiles are fetched from off-chip
memory, inner tiles are processed completely, and double buffering overlaps
the next fetch with the current compute [arxiv:2505.08992 §IV.A]
[arxiv:2505.08992 §IV.C]. Where the variants differ is which operand sits in
the inner loop's local buffer. The sketch below does not follow any one
design. The paper's own double-buffer listing has no stop condition and no
initial fill step, so a real version must add both.

```pseudocode
# Tiled dataflow over one layer  [arxiv:2505.08992 §IV.A, §IV.C]
# The stationary operand is chosen by the variant, not by this loop.

def tiled_layer(outer_tiles, stationary):
    # Fill the first buffer before the loop; the paper gives no prologue
    buf_a = load_tile(outer_tiles[0])
    # Visit each outer tile in turn  [§IV.A]
    for i in range(len(outer_tiles)):
        has_next = i + 1 < len(outer_tiles)
        # Prefetch the next tile while this one computes  [§IV.C]
        if has_next:
            buf_b = load_tile(outer_tiles[i + 1])
        # Keep the stationary operand local; stream the rest  [§II]
        for item in streamed_operands(buf_a, stationary):
            # Accumulate into the output, locally or in a shared buffer  [§II]
            accumulate(item, stationary)
        # Swap the roles of the two buffers  [§IV.C]
        if has_next:
            buf_a = buf_b
    return collect_outputs()
```

## Contradictions

- **Eyeriss labelling.** The survey credits Eyeriss with row-stationary
  [arxiv:2505.08992 §II.C], and also describes Eyeriss v1 as using an
  output-stationary-like scheme for many convolution layers
  [arxiv:2505.08992 §II.B]. The survey does not resolve this.
- **Dataflow labels for case studies.** The survey calls FlightLLM "partly
  output-stationary" and SSR "row-stationary inside each AIE cluster"
  [arxiv:2505.08992 §V]. The text cites no source for either label, so treat
  them as the survey's reading.
- **Timeloop mapping claim.** The survey reports that the weight-stationary
  mapping is energy-optimal with up to 11× energy variance across tilings, and
  cites Sparseloop for it [arxiv:2505.08992 §III]. The tool-comparison table
  cites Accelergy for a MAESTRO claim [arxiv:2505.08992 tab. 1]. The sources
  may support the claims, but the survey's own citations do not show it.
- **Cycle counts.** MAESTRO reports about 5×10⁵ cycles for the worked layer,
  Timeloop about 4.5×10⁵ [arxiv:2505.08992 §III]. Both are analytical
  estimates for the same hypothetical array, and the survey does not explain
  the gap.

## Papers

- [FPGA dataflow survey, arXiv:2505.08992](/papers/2505.08992): covers four dataflow styles, two analytical tools, two-level and multi-level tiling, and four FPGA case studies. It runs no new experiments.