MemPool: Manycore Shared-L1 Architecture

Updated 6 July 2026

MemPool is an open-source, RISC-V-based manycore architecture featuring low-latency shared L1 memory, scalable from tens to hundreds of processing elements.
It employs a hierarchical interconnect and hybrid addressing that achieves end-to-end access latencies as low as 5 cycles and sustains up to 0.38 request/core/cycle.
The platform supports multiple programming models—including bare-metal C, OpenMP, and DSLs—demonstrating high performance in matrix multiplication, convolution, and other compute kernels.

MemPool is principally the name of an open-source, RISC-V-based manycore architecture organized around a low-latency shared L1 memory, developed to scale shared-L1 clusters from a few tens to hundreds of processing elements while retaining a global memory view and a productive programming model (Riedel et al., 2023). In separate systems literature, the same capitalized name also denotes the elastic memory pool inside MemServe for disaggregated LLM serving, and it should be distinguished from the lowercase blockchain “mempool,” which denotes the per-node pool of pending transactions awaiting block inclusion (Hu et al., 2024, Fardno et al., 12 May 2026).

1. Origins and design objective

MemPool emerged from the problem of scaling shared-L1 many-core clusters without abandoning low-latency access to tightly coupled memory. The 2020 design presented MemPool as a 32-bit many-core system with 256 fast RV32IMA “Snitch” cores, a 1 MiB L1 scratchpad memory pool, and a processor-to-L1-memory interconnect engineered so that the shared memory remains accessible within at most five cycles (Cavalcante et al., 2020). The 2023 architecture refined this line by presenting a manycore system with 256 RV32IMAXpulpimg “Snitch” cores, an optimized instruction path, a powerful DMA engine, and multiple runtimes, while emphasizing that tightly coupled shared-L1 clusters need not stop at a few tens of processing elements (Riedel et al., 2023).

The later “MemPool Flavors” work repositioned MemPool as a broader open-source research platform for shared-L1-memory clusters, explicitly spanning a design space between versatility and specialization and scaling up to 1024 processing elements in later variants (Mazzola et al., 21 Mar 2025). This places MemPool at the intersection of architecture research, physical-aware interconnect design, and software/runtime co-design.

2. Baseline organization of the manycore cluster

In the 2023 implementation, MemPool comprises 256 processing elements arranged as 4 Groups of 16 Tiles each. One Tile holds 4 PEs, a private L0 instruction cache, 16 $\times$ 1 KiB L1-SPM banks, one AXI port, and 4 remote-SPM ports, yielding a total shared L1 scratchpad of 1 MiB organized as 1,024 banks of 1 KiB (Riedel et al., 2023).

The processing element is the “Snitch” core, a single-stage 32-bit RISC-V core implementing RV32IMAXpulpimg. Its microarchitecture includes an integer ALU, a PC+branch unit, a scoreboard supporting up to 8 outstanding memory operations, an accelerator port driving a pipelined IPU with MAC and related operations, and a register file extended to 3 read and 2 write ports. The instruction path couples a per-core L0 instruction SCM with a shared per-tile L1 instruction cache, and the software toolchain schedules around L1 and IPU latencies. This organization preserves independent execution at the core level while exposing a single shared-L1 namespace to the cluster as a whole.

3. Interconnect, memory semantics, and locality control

A defining property of MemPool is its explicit treatment of the processor-to-memory path as the central scalability constraint. Within a tile, a fully connected crossbar links the 4 PEs and incoming traffic to the 16 local banks. At higher levels, MemPool uses group-level 16 $\to$ 16 crossbars and point-to-point 16 $\to$ 16 crossbars between groups. In the absence of conflicts, the end-to-end access latency is summarized as

$L_{\text{access}} = L_{\text{crossbar(tile)}}+ L_{\text{router(group\_in)}}+ L_{\text{router(group\_out)}}+ L_{\text{crossbar(tile)}}+ L_{\text{bank}} \approx 5 \text{ cycles},$

with intra-group accesses shortening to approximately 3 cycles (Riedel et al., 2023).

The earlier interconnect study compared three candidate topologies and selected the hierarchical design, denoted $_H$ , because it matched the throughput of a four-butterfly alternative while remaining physically feasible. In that study, $_H$ saturated at approximately $0.38$ request/core/cycle and kept the average round-trip latency below 6 cycles up to an injection load of $0.33$ request/core/cycle (Cavalcante et al., 2020). The 2023 evaluation similarly reported that the network sustains up to about $0.35$ request/core/cycle per core before queuing blow-up and saturates near $0.4$ request/core/cycle.

MemPool also introduced a lightweight hybrid addressing scheme to bias private data toward local banks. In the 2020 design, this mapping ensured that core-private data such as stacks could be placed in memory banks accessible within one cycle, producing performance gains of up to 20% in signal-processing benchmarks. The same work reported that local-bank accesses consume only half of the energy required to access remote banks, with representative 32-bit load energies of approximately $\to$ 0 pJ for local loads and $\to$ 1 pJ for remote loads (Cavalcante et al., 2020). This locality mechanism is significant because it preserves a flat global address space while exploiting structured placement.

4. Programming model and measured system performance

MemPool is explicitly designed to be programmed at multiple abstraction levels. The 2023 system provides a bare-metal C runtime, an OpenMP environment based on RISC-V atomics, fences, and sleep/wake stores for barriers, and a Halide DSL backend that generates RISC-V and IPU code (Riedel et al., 2023). This software stack is paired with a DMA subsystem whose front-end decodes high-level transfers and whose back-ends fan out bank-aligned sub-transfers through a hierarchical AXI tree.

The reported evaluation covers kernels such as matrix multiplication, 2D convolution, DCT, axpy, and dot product. In post-layout results at 600 MHz in TT/0.8 V/25 °C, MemPool achieved up to 229 GOPS or 180 GOPS/W, with less than 2% of execution stalls. Under double-buffered streaming, 2D convolution reached 381 op/cycle, 228.6 GOPS, and 180 GOPS/W, while matrix multiplication reached 306 op/cycle and 183.6 GOPS (Riedel et al., 2023). The execution breakdown for compute kernels assigned roughly 60% of cycles to compute operations, around 30% to control, less than 2% to LSU stalls, less than 1% to RAW stalls, and about 4% to barrier idle.

Scaling behavior is likewise reported in differentiated form. Compute-bound workloads achieved 95–100% of ideal linear speedup up to 256 cores, whereas memory-bound workloads achieved 75–80% of ideal speedup (Riedel et al., 2023). This suggests that MemPool’s central architectural claim is not merely low latency in isolation, but low latency sustained under large-scale MIMD execution.

5. Architectural variants, vectorization, and 3D integration

The MemPool research line diversified into several “flavors,” each preserving the shared-L1 cluster model while changing the balance between programmability and specialization. For a 32-bit matrix-multiplication kernel, the “MemPool Flavors” work reports a peak single-precision throughput of $\to$ 2 GFLOP/s at 800 MHz in GlobalFoundries 12 nm FinFET, and uses utilization values to compare the main variants (Mazzola et al., 21 Mar 2025).

Flavor	Architectural change	Reported trade-off
Baseline MemPool	256 scalar Snitch cores, 1 MiB shared L1 SPM	$\to$ 3; $\to$ 4 GFLOP/s
Systolic MemPool	Implicit queue mapped into L1 banks for push/pop dataflow	$\to$ 5; area $\to$ 6; $\to$ 7 GFLOP/s
Vectorial MemPool	1 scalar Snitch core + 1 RVV-compliant Spatz vector accelerator per tile	$\to$ 8; area $\to$ 9; $\to$ 0 GFLOP/s

The Spatz work makes the vectorial direction explicit. Spatz is a compact vector processing unit integrated into MemPool through an extended CORE-V X-Interface. In the evaluated configuration, a Spatz-based cluster with four MACUs consumes $\to$ 1 pJ per 32-bit integer multiply-accumulate, and the resulting 64 $\to$ 2Spatz $\to$ 3 MemPool system reaches 285 GOPS and 266 GOPS/W on a $\to$ 4 integer matrix multiplication, compared with 167 GOPS and 128 GOPS/W for a 256-Snitch baseline (Cavalcante et al., 2022). The corresponding roofline model is written as

$\to$ 5

with compute throughput and memory bandwidth both scaling linearly in the number of vector lanes and cluster instances.

A separate line of work explored 3D integration. MemPool-3D partitions the tile across a logic die and a memory die, connected through face-to-face micro-bumps, and studies scratchpad capacities of 1 MiB, 2 MiB, 4 MiB, and 8 MiB. For the 4 MiB scratchpad point, the 3D design reports a 9.1% performance gain on matrix multiplication relative to the 2D counterpart, a 15% smaller energy budget than that 2D counterpart, and even a 3.7% smaller energy budget than the 1 MiB 2D instance (Cavalcante et al., 2021). This suggests that MemPool is not a fixed microarchitecture so much as a reusable cluster template whose central invariant is low-latency shared-L1 access.

6. Other uses of the name and the distinction from blockchain mempools

In LLM serving, “MemPool” names a different system component. MemServe embeds a MemPool library into every serving instance and uses it as an elastic memory pool over GPU HBM and CPU DRAM. In that context, MemPool manages both active and historical KV caches, exposes primitives for memory allocation, index management, and cross-instance transfer, and uses radix trees plus global prompt trees to support locality-aware scheduling. The reported results show that this MemPool-based design improves end-to-end serving metrics, including average JCT and TTFT reductions across ShareGPT, LooGLE, and ReAct workloads (Hu et al., 2024).

The capitalized name should also be separated from the generic lowercase “mempool” in blockchain research. There, a mempool is a per-node data structure that holds all pending transactions before block inclusion, typically ordered by effective gas price or fee rate (Hossain et al., 9 Jun 2025). Research on blockchain mempools studies transaction scheduling, pricing, fairness, accountability, synchronization, and DoS resilience. One Ethereum formulation models the mempool as an MDP with state $\to$ 6 and actions corresponding to block prices, then computes policies with Natural Policy Gradient (Fardno et al., 12 May 2026). Accountability-oriented work such as LØ instead treats the mempool as a cryptographically committed log built from a Bloom Clock and a Minisketch to detect reordering, injection, and censorship (Nasrulin et al., 2023).

Across these usages, the common abstraction is a managed pool of transient state. In MemPool the manycore architecture, that state is a low-latency shared L1 scratchpad; in MemServe it is distributed KV-cache memory; and in blockchain systems it is the set of pending transactions. The shared name therefore reflects a recurring systems idea, but not a single unified technical object.