p-DCIM: A 28nm Probabilistic SRAM DCIM based Ising Machine for Near-Memory Context Selection in LLM-RAG Pipeline

What it claims

p-DCIM is a fabricated 28 nm SRAM digital compute-in-memory Ising machine. It replaces LLM-based set-wise reranking in a RAG pipeline with QUBO optimization over retrieved candidates. The macro is a 64×64 logical array of signed 8-bit coefficients (32 Kb across 512 physical wordlines), runs at 500 MHz and draws about 0.41 mW in probabilistic mode. At the evaluated operating point, one context selection takes about 2.2 ms and 0.9 µJ. Answer quality on HotpotQA is reported as competitive with LLM-based set-selection baselines. The authors are from Georgia Tech and UC Santa Barbara (corresponding author Shimeng Yu). The paper was posted in October 2026.

How it works

The selection objective follows prior requirement-aware RAG work. An LLM first decomposes the query into weighted requirements. Each candidate passage gets a binary selection variable, a relevance score and a 0/1 relevance flag per requirement. Pairwise redundancy and complementarity scores, both normalized to [0,1], form the quadratic terms. A per-passage cost λ and a budget of K passages limit context size. The coverage and budget inequalities become squared penalties through binary slack variables, which yields a standard QUBO.

One array serves two modes:

1. Deterministic mode. Candidate embeddings stream through the array. Query-passage and passage-passage dot products, O(N²) in candidate count, populate the QUBO coefficients.
2. Probabilistic mode. The quantized coefficients are stored in the same array. The same signed accumulation datapath computes per-spin Hamiltonian differences for sequential updates.

Noise comes from SRAM pseudo-read errors at a fixed reduced supply voltage, so no LFSR or external RNG is needed. The voltage-to-error curve has a narrow transition region that is hard to regulate. Temperature is therefore set digitally. Magnitude bit-planes are protected from disturbance one by one as annealing proceeds, and the sign bit is always protected. This gives a discrete cooling schedule.

The proposed system places p-DCIM on the logic base die of a high-bandwidth flash (HBF) stack, next to HAVEN-style near-storage vector retrieval:

flowchart LR
  subgraph HBF stack base die
    R[Near-storage retrieval] --> E[Candidate embeddings]
    E --> C[QUBO construction]
    C --> A[Annealing]
  end
  G[GPU: query info] --> C
  A -->|passage IDs only| L[GPU: LLM answer]

Only the query-side data enters the stack. Only the selected passage IDs leave it, so the pairwise embedding work never crosses the package interconnect.

Evidence

The chip is characterized on an FPGA/AXI platform that handles coefficient loading, spin control and readout. Small QUBO instances run on silicon. The headline figures are a selection energy more than six orders of magnitude below the LLM selector and 67% lower total energy per query. Both are macro-normalized estimates. The fetched text cuts off in Section III, so the results tables, the baseline LLM's identity, the F1 values and the example count are not available here.

Limits

• Larger HotpotQA instances are not run on the chip. They use a behavioral model parametrized by measured pseudo-read statistics and datapath precision.
• The 64×64 array bounds on-chip problem size. That size has to cover passages plus coverage and slack variables.
• The HBM/HBF base-die integration is a proposal, not a built system.
• An LLM is still needed to decompose the query into requirements. The pipeline removes the selection pass, not every LLM call.
• The 67% energy and F1 claims cover only "the evaluated examples," per the authors.