The Dataflow Landscape: How I Learned to Place NextSilicon Among Its Neighbors

The mistake I made first

When I started trying to understand NextSilicon, I did what the marketing invites you to do: I studied the one chip in a vacuum — its benchmarks, its architecture diagram, its claims. That got me nowhere useful, and for a specific reason I only saw later: the idea of computing by laying operations out in space, rather than streaming instructions past one ALU, is not new. It is roughly fifty years old. Maverick-2 is a genuinely interesting machine (I took its internals apart in Inside the Fabric), but I couldn't tell what was actually novel about it until I stopped staring at it and drew a map of its neighborhood.

This post is that map — the one I built for myself. The thing that made it finally cohere was giving up on "how fast" and "how many FLOPs" and asking a structural question instead: when is it decided which operation runs on which cell? That single axis, from fully dynamic to fully fixed, sorted the whole confusing field into a spectrum, and once I could place a machine on it I could predict most of its tradeoffs without reading another benchmark. Here's the analogy that made the axis stick for me: it's the difference between a rigid assembly line (everything scheduled in advance, unchangeable, blazing fast at the one job it's built for) and an adaptive kitchen (figuring out on the fly what to cook next based on what's actually being ordered). Every machine below lives somewhere between those two.

The scheduling spectrum

Every spatial architecture has to answer one question: when is it decided which operation runs on which cell? The answers form a spectrum, and where a machine falls on it determines almost everything else — how general it is, how much overhead it pays, and what kind of code it can run.

The pattern is monotone: more scheduling dynamism = more generality, at the cost of more overhead. NextSilicon sits at the dynamic end and pays for it (see the reconfiguration "Configuration Wall" roofline in Inside the Fabric); the TPU sits at the fixed end and is unbeatable at exactly one thing.

The commercial field

The academic taxonomy (from the ACM CGRA survey) names the scheduling classes precisely — SSE (static-scheduled sequential), SSD (static-scheduled static-dataflow), DSD (dynamic-scheduled static-dataflow), DDD (dynamic-scheduled dynamic-dataflow). NextSilicon lives at the DSD/DDD end (dynamic scheduling + runtime-reconfigured dataflow); Groq is the clean SSD opposite. Here are the machines worth knowing:

NextSilicon Maverick-2 — reconfigurable dataflow, "mill cores," CGRA-class. Dynamic, telemetry-driven runtime reconfiguration. Its differentiator is what nobody else in this list does: runs unmodified general HPC code (C/C++/Fortran/CUDA), not just AI graphs, and targets DOE/HPC (Sandia) rather than AI inference. Lead exemplar of this lane.

SambaNova RDU — the closest architectural cousin. Its Reconfigurable Dataflow Unit descends directly from Stanford's Plasticine (the same Prabhakar/Olukotun lineage), and it maps model graphs onto a mesh of Pattern Compute Units and Pattern Memory Units via the SambaFlow compiler. The key difference from NextSilicon: SambaNova is AI-model-graph focused and reconfigures at compile time, not continuously from runtime telemetry.

Groq LPU / TSP — the deliberate opposite of NextSilicon. Groq's tensor-streaming processor is statically scheduled and fully deterministic: the compiler schedules every cycle, there is no dynamic reordering, no runtime remap. That makes it exceptional at low-latency inference with predictable timing — and gives it exactly zero of NextSilicon's runtime adaptivity. The cleanest contrast axis in the whole field.

Cerebras WSE-3 — dataflow at wafer scale (900k+ cores, tens of GB of on-wafer SRAM). Weight/activation streaming across an enormous spatial fabric. The scaling answer is "don't leave the wafer," which sidesteps the memory wall differently than NextSilicon's HBM-fed grid.

Tenstorrent — a grid of Tensix cores plus a network-on-chip with explicit, software-managed inter-core data movement. Programmable, AI-focused, more conventional many-core than pure dataflow.

The academic substrate NextSilicon productizes

The honest framing of any commercial dataflow chip is that its fabric has deep precedent; the novelty is usually in the runtime, the compiler, or the productization. NextSilicon's three most direct ancestors:

• Plasticine (Prabhakar et al., ISCA 2017) — a CGRA organized around parallel patterns, with two tile types: a Pattern Compute Unit (a pipeline of functional units) and a Pattern Memory Unit (a banked scratchpad with a datapath dedicated to address computation). That PCU/PMU split — compute cells fed by decoupled address-generating memory cells — is exactly the "ALU grid plus memory-entry-point column" pattern NextSilicon ships, and it is the direct lineage to SambaNova.

• TRIPS / EDGE (Burger & Keckler, UT Austin) — Explicit Data Graph Execution, a post-RISC ISA where the compiler emits a dataflow graph and the microarchitecture maps it onto a distributed execution substrate, with results flowing producer→consumer instead of through a register file. This is the general-purpose (not AI-specific) precedent for "compiler maps arbitrary code onto a spatial ALU grid."

• WaveScalar (Swanson et al., UW, 2003) — solved the hard problem for running imperative code on a dataflow fabric: memory ordering. Its wave-ordered memory gave ordinary C a total load/store order on a dataflow machine, and its execution pipeline's Match/Dispatch stages prefigure the dispatch front-ends of modern reconfigurable chips.

And behind all of them sits the systolic array (Kung & Leiserson, 1978) — rhythmic spatial pipelines, fixed-function — whose most successful descendant is the Google TPU's matrix unit. Which sets up the one takeaway that most complicates the reconfigurable-dataflow story.

Three things I understand now that I didn't before

1. The scheduling spectrum is the real story. Dynamic/runtime-reconfigured (NextSilicon) → compile-time reconfigurable (SambaNova, FPGA) → static-deterministic (Groq) → fixed systolic (TPU). Every step toward dynamism buys generality and costs overhead. This one axis explains more of the field than any benchmark table.

2. NextSilicon's cell is nearly empty. It is the only architecture here that is both runtime-reconfigurable and runs unmodified general HPC code. Everyone else is either AI-graph-specific (SambaNova, Cerebras, Groq, TPU) or a static/compile-time substrate (FPGA, Versal). That empty cell is the whole bet — and also why independent HPC benchmarks matter so much for evaluating it (there is no neighbor doing the same thing to compare against).

3. The most successful "dataflow" chip is the least reconfigurable. The TPU's fixed systolic array — no runtime scheduling, no reconfiguration, no generality — is the dataflow idea that actually dominates production. That is the fact that keeps me honest: reconfigurability is a real capability, but it is not obviously what wins at scale, and my understanding of NextSilicon has to sit with the reality that the market's biggest spatial-computing success went the other direction. When I catch myself getting excited about the runtime-remap trick, this is the row I re-read.

That's the map as I currently hold it. It's a learner's map, not a market analyst's — I've placed these machines by the one axis that made them make sense to me, and I'd expect someone closer to any single vendor to sharpen (or correct) where I've put it.

Adjacent, same memory-wall motive, different mechanism: processing-in-memory (UPMEM, Samsung HBM-PIM, SK Hynix AiM) and analog in-memory compute (Mythic) attack data movement by computing at or in the memory itself — a different answer to the same problem this whole landscape is trying to solve. Capability and performance claims throughout are vendor positioning, not independent benchmarks; verify per row before citing.