FPGA array vs CPU — scaling outlook

Where a mesh-of-RISC-V-cores simulator beats a CPU, as a function of design size — measured anchor points (dots) plus clearly-labeled model lines (dashes). This replaces an earlier "linear scaling validated" chart whose data was projected, not measured.

101 102 103 104 105 106 107 108 109 102 103 104 105 106 107 108 109 design size (synthesized cells, log) simulated throughput (DUT cycles/s, log) xorshift · x86 1-thread bet FIFO · x86 bet FIFO · A53 (on ZCU104) bet FIFO · Verilator+TB x86 xorshift · 1 array core xorshift · 64 independent sims (aggregate) SHA-256 · 1 array core (~4k cells est.) ZCU104 array full ~64k cells ≈ 0.06% of a 100M-gate IC D5005 array full ~0.5M cells ≈ 0.5% of IC ≈ one x86 LLC (CPU cache cliff) full 100M-gate IC (emulator / multi-FPGA territory) crossover: design partitions across ≥64 cores → array wins CPU, 1 thread, compiled model (model) ZCU104 8×8 array, partitioned (model) D5005-class array (projection) measured run (○ = aggregate of 64 sims)

How to read it

Both platforms slow down linearly as the design grows — more cells to evaluate per simulated cycle — so on a log-log plot every simulator is a descending line, and what matters is (a) the line’s height (cell-evaluations per second) and (b) where it ends (capacity). A single CPU thread is individually much faster than one soft core (measured: 258 M vs 9.96 M evals/s on the same tiny design — 26×). The array wins by width, not height: 64 cores with all state in local memory. Left of the crossover a design can’t use enough cores to close that 26× gap (measured: the bet FIFO tops out at ~1.9× over one core no matter how many are offered). Right of it, the aggregate line sits ~2.7× above the CPU (ZCU104) or ~7× (projected D5005-class), until the array runs out of room.

The capacity markers are the honest part: a full ZCU104 holds ≈ 0.06% of a 100M-gate IC and a D5005-class part ≈ 0.5%. Full-chip simulation on this architecture means racks of FPGAs — the same math that makes commercial emulators the size they are. The realistic near-term claims are the shaded band (blocks and subsystems up to ~0.5M cells) and the aggregate-throughput case (64 independent sims at once, measured 637 M evals/s = 2.47× one x86 thread).

What is measured vs modeled

ElementBasis
All dotsMeasured wall-clock runs (ZCU104 silicon, x86, A53); outputs checked against references
CPU lineModel: ~3 G cell-evals/s per thread in-cache (anchored on the xorshift and bet-FIFO compiled runs), 10× cliff past ~1M cells when state exceeds the last-level cache
ZCU104 array lineModel: 64 cores × ~250 M cell-evals/s each (anchored on xorshift 9.96 M evals/s and SHA-256 122 k cyc/s measurements, URAM cost included) × 0.5 partition efficiency — cross-core settling measured functional in sim, efficiency factor is an estimate, silicon partitioned-throughput run still TBD
D5005 lineProjection: ~450 cores from measured per-core area (~2k ALM-equiv), 1.5× clock, same efficiency — labeled projection, no silicon
Capacity marks~1k cells/core from measured program+state footprints (SHA-256 ≈ 1.4k words in 16 KB/core)
What would move these lines: a measured partitioned-design silicon run (fixes the 0.5 efficiency guess), a real cell count for the SHA-256 netlist (the ~4k estimate), and per-core memory scaling (more URAM per core trades core count for capacity). All three are planned measurements, not unknowns of principle.